etcdスナップショットをリストアした後、クラスターを再起動する際の正しい手順は何ですか？

A) スナップショットリストア後、既存のdata-dirをそのまま使用する B) スナップショットリストア時に新しいdata-dirを指定し、etcd設定でdata-dirパスを変更してから再起動する C) スナップショットリストア後、全ノードでkubeletのみ再起動する D) スナップショットリストアは自動的にetcdを再起動する

正解: B

etcdutl snapshot restoreコマンドは新しいdata-dirにデータをリストアします。リストア後、etcdの設定ファイル（またはstatic podマニフェスト）でdata-dirパスを新しいパスに変更してetcdを再起動する必要があります。既存のdata-dirを上書きするとデータ破損のリスクがあります。

etcdctl snapshot saveコマンドでバックアップする際に必須で指定する証明書関連フラグの組み合わせは？

A) --cacert, --cert, --key B) --ca-fileと--cert-fileのみ C) --tls-certのみ D) 証明書なしでもバックアップ可能

正解: A

etcdがTLSで保護されている場合、etcdctlに--cacert（CA証明書）、--cert（クライアント証明書）、--key（クライアントキー）をすべて指定する必要があります。さらに--endpointsフラグでetcdエンドポイントも指定する必要があります。

3ノードetcdクラスターで1メンバーを削除した後、同じノードを再追加する際に必ず行うべき作業は？

A) 既存のdata-dirをそのまま維持して再起動のみ行う B) 既存のdata-dirを削除し、etcdctl member addで新メンバーとして追加した後、initial-cluster-stateをexistingに設定する C) etcdctl member updateのみ実行すればよい D) クラスター全体を再起動する必要がある

正解: B

削除されたメンバーを再追加する際は、既存のデータディレクトリを必ず削除する必要があります。その後、etcdctl member addで新メンバーを登録し、initial-cluster-state=existingに設定して既存クラスターに参加させます。

3ノードetcdクラスターで2ノードが同時に障害を起こしクォーラムが喪失しました。リカバリ方法は？

A) 残りの1ノードで自動的にリカバリされる B) 残りの1ノードでetcdctl snapshot save後、--force-new-clusterフラグで単一ノードクラスターを作成し、残りのメンバーを追加する C) 3ノードすべて再起動すれば自動リカバリされる D) etcdctl defragのみ実行すればよい

正解: B

クォーラムが喪失すると正常な読み書きが不可能になります。残存ノードでスナップショットを保存した後、--force-new-clusterオプションで単一ノードクラスターを新たに構成し、その後残りのメンバーを一つずつ追加してクラスターを再構成する必要があります。

etcdのパフォーマンスが低下した際に優先的に確認すべきメトリクスは？

A) etcd_server_proposals_committed_total B) etcd_disk_wal_fsync_duration_secondsおよびetcd_disk_backend_commit_duration_seconds C) etcd_network_client_grpc_received_bytes_total D) etcd_server_version

正解: B

etcdパフォーマンス低下の最も一般的な原因はディスクレイテンシーです。WAL fsyncレイテンシー（etcd_disk_wal_fsync_duration_seconds）とバックエンドコミットレイテンシー（etcd_disk_backend_commit_duration_seconds）を最初に確認すべきです。これらの値が高い場合、SSDの使用やディスクI/Oの最適化が必要です。

kubeadmを使用してクラスターを1.29から1.30にアップグレードする際の正しい順序は？

A) ワーカーノードを先にアップグレードしてからコントロールプレーンをアップグレード B) kubeadmアップグレード -> kubelet、kubectlアップグレード -> ワーカーノードアップグレードの順で、コントロールプレーンから開始 C) kubectlのみアップグレードすれば残りは自動的に行われる D) すべてのノードで同時にkubeadm upgrade applyを実行する

正解: B

正しい順序は: 1) コントロールプレーンでkubeadmを先にアップグレード、2) kubeadm upgrade planで確認、3) kubeadm upgrade applyでコントロールプレーンコンポーネントをアップグレード、4) kubeletとkubectlをアップグレードして再起動、5) ワーカーノードをdrain後同様の手順を繰り返します。

ワーカーノードをdrainする際にDaemonSet Podのために失敗します。どう解決すべきですか？

A) DaemonSetを先に削除する B) --ignore-daemonsetsフラグを追加してdrainを実行する C) --forceフラグのみ追加する D) drainなしで直接アップグレードする

正解: B

kubectl drainコマンドに--ignore-daemonsetsフラグを追加すると、DaemonSetで管理されるPodを無視してdrainを進行します。DaemonSet Podはノードに常に存在する必要があるため、退去対象から除外するのが正しい方法です。

kubeadm upgrade apply後にkubeletが起動しません。最も可能性が高い原因は？

A) kube-proxy設定エラー B) kubeletパッケージがまだ以前のバージョンでバージョン不一致が発生した C) CNIプラグインの問題 D) etcdが停止している

正解: B

kubeadm upgrade applyはコントロールプレーンコンポーネントのみアップグレードします。kubeletとkubectlは別途パッケージをアップグレードする必要があります。バージョン不一致が発生するとkubeletが正常に起動しない場合があります。

3つのコントロールプレーンノードがあるHAクラスターをアップグレードする際の正しい方法は？

A) すべてのコントロールプレーンで同時にkubeadm upgrade applyを実行する B) 最初のコントロールプレーンでkubeadm upgrade applyを実行し、残りはkubeadm upgrade nodeを実行する C) どのノードでもkubeadm upgrade applyを実行すればよい D) ワーカーノードを先にアップグレードしてからコントロールプレーンをアップグレードする

正解: B

HAクラスターでは最初のコントロールプレーンノードでのみkubeadm upgrade applyを実行します。残りのコントロールプレーンノードではkubeadm upgrade nodeを実行してローカルkubelet設定と証明書を更新します。

etcdのデータが増え続けて容量不足の警告が出ています。自動コンパクションを設定するには？

A) etcd起動オプションに--auto-compaction-retention=1 --auto-compaction-mode=periodicを追加する B) etcdctl compactコマンドを手動で実行するしかない C) etcdは自動的にコンパクションされるため別途設定は不要 D) boltdbを手動で交換する必要がある

正解: A

etcdに--auto-compaction-mode=periodicと--auto-compaction-retentionオプションを設定すると、指定された周期で自動コンパクションが実行されます。periodicモードでretentionが1の場合、1時間ごとにコンパクションされます。revisionモードも使用可能です。コンパクション後はdefragも併せて実行することをお勧めします。

devネームスペースのPodのみ読み取り可能で、すべてのネームスペースのNode情報を読み取れる権限を設定するには？

A) 1つのClusterRoleにすべての権限を入れてClusterRoleBindingでバインドする B) Pod読み取り用のRoleをdevネームスペースに作成してRoleBindingで接続、Node読み取り用のClusterRoleを作成してClusterRoleBindingで接続する C) 1つのRoleにPodとNodeの権限をすべて入れる D) ServiceAccountに直接権限を付与する

正解: B

ネームスペーススコープのリソース（Pod）はRole + RoleBindingで、クラスタースコープのリソース（Node）はClusterRole + ClusterRoleBindingでそれぞれ設定する必要があります。Roleは特定のネームスペースにのみ適用され、NodeはネームスペースのないクラスターリソースなのでClusterRoleが必要です。

aggregationRuleが設定されたClusterRoleの動作について正しい説明は？

A) 他のClusterRoleのルールを自動的にマージして1つのClusterRoleにする B) 複数のネームスペースのRoleを合わせる C) ClusterRoleの権限を自動的に縮小する D) ServiceAccountを自動的に作成する

正解: A

aggregationRuleはラベルセレクターを使用して他のClusterRoleのルールを自動的にマージします。admin、edit、viewなどのビルトインClusterRoleがこのメカニズムを使用しています。新しいCRDを追加する際に適切なラベルが付いたClusterRoleを作成すると、既存のロールに自動的に権限が追加されます。

セキュリティのために特定のPodでServiceAccountトークンが自動マウントされないようにするには？

A) ServiceAccountを削除する B) Pod specまたはServiceAccountでautomountServiceAccountTokenをfalseに設定する C) RBAC権限をすべて削除する D) ネームスペースを削除する

正解: B

Pod specのautomountServiceAccountTokenフィールドをfalseに設定するか、ServiceAccount自体にそのフィールドをfalseに設定できます。Podレベルの設定がServiceAccountレベルの設定より優先されます。これにより/var/run/secrets/kubernetes.io/serviceaccountにトークンがマウントされなくなります。

productionネームスペースで実行中のPodがmonitoringネームスペースのPodからのみトラフィックを受信するようにするには？

A) ingressルールでnamespaceSelectorでmonitoringネームスペースを選択する B) egressルールのみ設定する C) すべてのトラフィックを許可するポリシーを作成する D) Podのlabelのみ変更する

正解: A

NetworkPolicyのingressルールでnamespaceSelectorを使用してmonitoringネームスペースのラベルを選択します。この時monitoringネームスペースに適切なラベルが設定されている必要があります。namespaceSelectorとpodSelectorを併用するとより細かい制御が可能です。

NetworkPolicy ingressルールで次の2つの設定の違いは何ですか？

設定A: from配列にnamespaceSelectorとpodSelectorを同じ項目に入れる 設定B: from配列にnamespaceSelectorとpodSelectorを別々の項目で入れる

A) 違いはない B) 設定AはAND条件（両条件を満たす必要あり）、設定BはOR条件（一方を満たせば許可） C) 設定AがOR条件である D) 両方ともOR条件である

正解: B

同じfrom項目内にnamespaceSelectorとpodSelectorを一緒に入れるとAND条件です（両条件を満たすPodのみ許可）。別々のfrom項目に分離するとOR条件です（いずれかを満たせば許可）。この違いはNetworkPolicyで非常に重要で、試験でも頻出します。

特定のネームスペースですべてのingressトラフィックをデフォルト拒否するには？

A) NetworkPolicyなしでデフォルトですべてのトラフィックが拒否される B) podSelectorを空にして（すべてのPodを選択）、ingressルールを空にしたNetworkPolicyを作成する C) egressルールのみ空にすればよい D) ネームスペースにannotationを追加する

正解: B

podSelectorを空の値に設定するとネームスペースのすべてのPodを選択します。policyTypesにIngressを指定してingressルールを定義しなければ、すべてのインバウンドトラフィックが拒否されます。これがデフォルト拒否ポリシーの標準パターンです。

NetworkPolicyを適用したがPod間通信がまだ可能です。最も可能性が高い原因は？

A) NetworkPolicyが多すぎて適用されている B) CNIプラグインがNetworkPolicyをサポートしていない（例: Flannel） C) Podが再起動されていない D) kube-proxyが停止している

正解: B

Flannelなどの一部CNIプラグインはNetworkPolicyをサポートしていません。Calico、Cilium、Weave Netなど NetworkPolicyをサポートするCNIを使用する必要があります。NetworkPolicyリソースを作成してもCNIがサポートしていなければ効果がありません。

ユーザーにimpersonate動詞の権限を付与するとどのようなことが可能になりますか？

A) 他のユーザーのパスワードを変更できる B) 他のユーザー、グループ、またはServiceAccountになりすましてAPIリクエストを行える C) ユーザーアカウントを削除できる D) すべてのSecretにアクセスできる

正解: B

impersonate権限はkubectlコマンドで--as、--as-groupフラグを使用して他のユーザーやグループになりすますことを可能にします。RBACポリシーのテストやデバッグに有用ですが、強力な権限であるため慎重に付与する必要があります。

Podから特定の外部IP帯域（10.0.0.0/8）へのみegressを許可するには？

A) ingressルールにCIDRを設定する B) egressルールでipBlockにcidr: 10.0.0.0/8を指定する C) ServiceのexternalIPsを設定する D) PodのhostNetworkをtrueに設定する

正解: B

NetworkPolicyのegressルールでipBlockを使用するとCIDRブロックベースで外部トラフィックを制御できます。exceptフィールドを使用すると特定のサブネットを除外することもできます。この方法はクラスター外部のサービスへのトラフィックを制限する際に有用です。

特定のConfigMap1つにのみ読み取り権限を付与するには？

A) すべてのConfigMapに対するget権限を付与する B) Roleでresourcesにconfigmapsを指定し、resourceNamesに特定のConfigMap名を明示する C) ConfigMapにannotationを追加する D) ネームスペースを分離する

正解: B

RoleのrulesでresourceNamesフィールドを使用すると特定名のリソースにのみ権限を制限できます。例えばresources: configmaps、verbs: get、resourceNames: my-configと設定するとmy-configというConfigMapにのみ読み取り権限が付与されます。

CSI（Container Storage Interface）ドライバーの主要な構成要素は？

A) Controller Pluginのみあればよい B) Controller Plugin（プロビジョニング、アタッチ）とNode Plugin（マウント、フォーマット）で構成される C) kubeletがCSI機能を内蔵している D) kube-proxyがストレージを管理する

正解: B

CSIドライバーはController PluginとNode Pluginで構成されます。Controller Pluginはボリューム作成/削除、アタッチ/デタッチを担当し、通常Deploymentでデプロイされます。Node Pluginはボリュームマウント/アンマウント、フォーマットを担当し、DaemonSetでデプロイされます。

kubeletのeviction-hard設定でmemory.availableが100Mi未満に設定されている場合の動作は？

A) ノードが自動的に再起動される B) 使用可能メモリが100Mi未満になるとkubeletが優先度の低いPodから退去させる C) 新しいPodのスケジューリングのみブロックする D) ノードのすべてのPodが同時に終了する

正解: B

kubeletのeviction-hard閾値に達するとkubeletはPodを退去させてリソースを回収します。QoSクラス（BestEffort、Burstable、Guaranteedの順）とリソース使用量を基準に退去対象を選定します。ノードにはMemoryPressureなどのコンディションが追加されます。

static Podについての正しい説明は？

A) kubectlで直接削除できる B) kubeletが直接管理し、特定ディレクトリのマニフェストファイルを監視して作成/削除する C) ReplicaSetによって管理される D) etcdに直接保存される

正解: B

static PodはkubeletがAPIサーバー指定されたディレクトリ（デフォルト: /etc/kubernetes/manifests）のYAMLファイルを監視して直接管理します。APIサーバーにはmirror Podが作成されて照会は可能ですが、kubectl deleteで削除してもkubeletが再作成します。コントロールプレーンコンポーネントが主にstatic Podとして実行されます。

Kubernetes APIサーバー監査ポリシー（Audit Policy）のログレベルのうちRequestResponseについての説明は？

A) イベントメタデータのみ記録する B) リクエストメタデータとリクエストボディを記録する C) リクエストメタデータ、リクエストボディ、レスポンスボディをすべて記録する D) 何も記録しない

正解: C

監査ポリシーのレベルはNone（記録なし）、Metadata（メタデータのみ）、Request（メタデータ+リクエストボディ）、RequestResponse（メタデータ+リクエストボディ+レスポンスボディ）です。RequestResponseは最も詳細なレベルで、Secretアクセスや重要なAPI呼び出しの追跡に有用ですが、ログボリュームが非常に大きくなります。

SecretリソースへのアクセスのみRequestResponseレベルで監査ログに記録するには？

A) すべてのリソースをRequestResponseに設定する B) 監査ポリシーのrulesでresourcesにsecretsを指定し、levelをRequestResponseに設定する C) kube-apiserverの--audit-log-pathのみ設定すればよい D) etcdで直接ログを設定する

正解: B

監査ポリシーファイルのrulesセクションでresourcesグループとリソース名を指定して、特定リソースに対するログレベルを設定できます。ルールは上から下に評価され、最初にマッチしたルールが適用されます。

kubeadmでインストールしたクラスターのコントロールプレーン証明書がまもなく期限切れになります。更新方法は？

A) 証明書は自動的に永久なので更新は不要 B) kubeadm certs renew allコマンドで更新した後、コントロールプレーンコンポーネントを再起動する C) 証明書を手動で削除すれば自動再生成される D) 新しいクラスターをインストールする必要がある

正解: B

kubeadm certs renew allコマンドですべての証明書を更新できます。更新後kube-apiserver、kube-controller-manager、kube-scheduler、etcdのstatic Podを再起動する必要があります。kubeadmはデフォルトで1年有効期間の証明書を発行します。

kubeadm certs check-expirationコマンドが表示する情報は？

A) kubelet証明書のみ表示する B) kubeadmが管理するすべての証明書の有効期限、残り有効期間、CA情報を表示する C) 外部CA証明書の情報を表示する D) TLS Secretの有効期限情報を表示する

正解: B

kubeadm certs check-expirationはAPIサーバー、コントローラーマネージャー、スケジューラー、etcdなどの証明書有効期限、残り有効期間、発行CA情報をテーブル形式で表示します。証明書管理計画を立てる際に有用です。

デフォルトスケジューラーに加えてカスタムスケジューラーをデプロイするには？

A) デフォルトスケジューラーを修正する必要がある B) 別のスケジューラーをDeploymentでデプロイし、Pod specのschedulerNameフィールドにそのスケジューラー名を指定する C) すべてのPodが自動的にカスタムスケジューラーを使用する D) kubelet設定を変更する

正解: B

カスタムスケジューラーは別のDeploymentとしてデプロイできます。Podが特定のスケジューラーを使用するには、spec.schedulerNameフィールドにカスタムスケジューラー名を指定します。指定しないPodはデフォルトスケジューラー（default-scheduler）が処理します。

BestEffort QoS Podにのみリソースクォータを適用するには？

A) すべてのPodに同じクォータを適用する B) ResourceQuotaにscopeSelectorを使用してBestEffortスコープを指定する C) PriorityClassのみで制限できる D) LimitRangeのみ使用する

正解: B

ResourceQuotaのscopeSelectorまたはscopesフィールドを使用すると、BestEffort、NotBestEffort、Terminating、NotTerminatingなどのスコープで特定条件のPodにのみクォータを適用できます。例えばBestEffortスコープを指定するとリソースリクエスト/リミットのないPodにのみクォータが適用されます。

LimitRangeとResourceQuotaの主な違いは？

A) 両方ともネームスペース全体の総リソースを制限する B) LimitRangeは個別Pod/コンテナのデフォルト値と最大/最小リソースを設定し、ResourceQuotaはネームスペース全体の総リソース使用量を制限する C) ResourceQuotaは個別コンテナにのみ適用される D) LimitRangeはクラスター全体に適用される

正解: B

LimitRangeは個別コンテナまたはPodレベルでデフォルトリソースリクエスト/リミット、最小/最大値を設定します。ResourceQuotaはネームスペース全体で使用できる総リソース量（CPU、メモリ、Pod数など）を制限します。両方を併用すると詳細なリソース管理が可能になります。