* kube-controller-manager は、クラスターの状態を制御する一連のコントローラーを実行します。
* 正確な抜粋 (Kubernetes ドキュメント):「kube-controller-manager は、Kubernetes の中核となるコントローラーを実行します。コントローラーの例としては、ノード コントローラー、レプリケーション コントローラー、エンドポイント コントローラー、名前空間コントローラー、ServiceAccounts コントローラーなどがあります。」
* D が正しい理由: リストされているものはすべて、kube-controller-manager 内の実際のコントローラーです。
* 他の人が間違っている理由:
* A:Job および CronJob コントローラーは kube-controller-manager によって管理されますが、DaemonSet コントローラーは kube-scheduler/deployment ロジックによって管理されます。
* B:Pod、Service、Ingress コントローラーは kube-controller-manager の一部ではありません。
* C:ConfigMap と Secret には専用のコントローラーがありません。
参考文献:
Kubernetes ドキュメント - kube-controller-manager: https://kubernetes.io/docs/reference/command-line-tools- reference/kube-controller-manager/

* etcd はクラスター状態の Kubernetes のキー値ストアです。
* 保存対象: ConfigMap、シークレット、ポッド定義、デプロイメント、RBAC ポリシー、メタデータ。
* 正確な抜粋 (Kubernetes ドキュメント - etcd):
* 「etcd は、Kubernetes のすべてのクラスター データのバッキング ストアとして使用される、一貫性があり可用性の高いキー値ストアです。」
* 説明:
* B: ログ/メトリックは、etcd ではなく、ログ記録/監視ソリューションによって処理されます。
* C: 秘密はここに保存されますが、base64 でエンコードされており、主な用途として特に「ユーザー名/パスワード」に使用されません。
* D: 永続ボリュームは外部ストレージであり、etcd には保存されません。
参考文献:
Kubernetes ドキュメント - etcd: https://kubernetes.io/docs/concepts/overview/components/#etcd

* ポッドセキュリティ標準 (PSS):
* Kubernetes は、ポリシーに基づいてセキュリティ制御を実施するための Pod Security Admission (PSA) を提供します。
* 公式抜粋：「Pod セキュリティ標準は、Pod のさまざまな分離レベルを定義します。この標準は、Pod が実行できる操作とアクセスできる内容を制限することに重点を置いています。」
* 標準プロファイルは次の 3 つです。
* 特権: 制限なし (非推奨)。
* ベースライン: 最小限の制限。
* 制限付き: 厳しく制限され、最小限の権限が適用されます。
* オプションCが正しい理由:
* YAML でポッド セキュリティ標準を適用すると、ポッドが次のようなベスト プラクティスに準拠することが保証されます。
* ルートユーザーはいません。
* ホストアクセスが制限されています。
* 権限昇格はありません。
* Seccomp/AppArmor プロファイル。
* これにより、セキュリティ リスクが直接最小限に抑えられます。
* 他の人が間違っている理由:
* A:機密データを共有すると、漏洩のリスクが高まります。
* B: 昇格した権限で実行すると、最小権限の原則に反します。
* D:ランダムなポッド名はセキュリティに貢献しません。
参考文献:
Kubernetes ドキュメント - ポッド セキュリティ標準: https://kubernetes.io/docs/concepts/security/pod-security- standards/ Kubernetes ドキュメント - ポッド セキュリティ入場: https://kubernetes.io/docs/concepts/security/pod-security- admission/

* Kubernetes は、RuntimeClass リソースを介してノード上で複数のコンテナ ランタイムをサポートします。
* ランタイムを選択するには、PodのYAMLマニフェストのruntimeClassNameフィールドを指定します。例:
* APIバージョン: v1
* 種類: ポッド
* メタデータ:
* 名前: 例
* 仕様:
* ランタイムクラス名: gvisor
* コンテナ:
* - 名前: アプリ
* 画像: nginx
* 誤ったオプション:
* (A) kubectl コマンドラインフラグを使用してコンテナのランタイムを指定することはできません。
* (B) Docker デーモンの設定を変更しても、Kubernetes Pod はランタイムに誘導されません。
* (C) Pod 仕様内の環境変数はコンテナのランタイムを制御しません。
参考文献:
Kubernetes ドキュメント - RuntimeClass
CNCF セキュリティ ホワイトペーパー - セキュリティを強化するために、さまざまなランタイム (gVisor、Kata など) を介してワークロードを分離します。

* NetworkPolicies は、Pod が相互に通信したり外部エンドポイントと通信したりする方法を定義します。
* ただし、Kubernetes自体はNetworkPolicyを適用しません。適用方法は、使用するCNIプラグイン（Calico、Cilium、Kube-Router、Weave Netなど）によって異なります。
* クラスターが NetworkPolicy をサポートしていないネットワーク プラグインを使用している場合、NetworkPolicy オブジェクトを作成しても効果はありません。
参考文献:
Kubernetes ドキュメント - ネットワークポリシー
CNCF セキュリティ ホワイトペーパー - プラットフォーム セキュリティ セクション: セキュリティの適用は CNI 機能に依存していることを説明しています。