Ambassadorコンテナパターンはどのような目的で使用されますか？

A) ログを収集して外部に送信する B) メインコンテナに代わって外部サービスとの接続をプロキシし、接続管理を簡素化する C) 初期化作業を実行する D) データを変換してメインコンテナに渡す

正解: B

Ambassadorパターンではメインコンテナがlocalhostで通信し、AmbassadorコンテナがDB外部サービス（データベース、キャッシュなど）への接続をプロキシします。これによりサービスディスカバリー、コネクションプーリング、TLS処理などをメインアプリから分離できます。

Adapterコンテナパターンの特徴は？

A) メインコンテナのトラフィックをプロキシする B) メインコンテナの出力データを標準化された形式に変換する C) メインコンテナと同じ作業を実行する D) 初期化作業のみ担当する

正解: B

Adapterパターンはメインコンテナの出力（ログ、メトリクスなど）を標準化された形式に変換します。例えば様々な形式のログを共通のJSON形式に変換したり、アプリケーション固有のメトリクスをPrometheus形式に変換するのに使用されます。

Podに3つのInitコンテナが定義されており、2番目のInitコンテナが失敗した場合は？

A) 3番目のInitコンテナが実行される B) メインコンテナがすぐに起動する C) PodのrestartPolicyに従って2番目のInitコンテナがリトライされ、成功するまで3番目は実行されない D) Podが即座に削除される

正解: C

Initコンテナは順番に実行され、各々成功しないと次に進めません。1つが失敗するとrestartPolicyに従ってリトライされます。AlwaysやOnFailureポリシーならリトライし、NeverならPodがFailed状態になります。すべてのInitコンテナが成功してからメインコンテナが起動します。

helm install時にvalues.yamlの特定の値をオーバーライドするには？

A) values.yamlファイルを直接修正するしかない B) --setフラグや-fフラグでカスタムvaluesファイルを指定できる C) 環境変数でのみオーバーライド可能 D) ConfigMapを使用する必要がある

正解: B

helm installやhelm upgrade時に--set key=valueで個別値をオーバーライドしたり、-f custom-values.yamlで別のvaluesファイルを指定できます。--setが-fより優先されます。複雑なオーバーライドはファイルを使用することをお勧めします。

helm upgrade後に問題が発生して以前のバージョンにロールバックするには？

A) helm delete後に再インストールする必要がある B) helm rollbackコマンドで以前のリビジョンにロールバックできる C) kubectl rollout undoを使用する D) values.yamlを以前の値に変更して再度upgradeする

正解: B

helm rollback RELEASE_NAME REVISIONコマンドで特定のリビジョンにロールバックできます。helm history RELEASE_NAMEでリビジョン一覧を確認し、希望するリビジョン番号を指定します。ロールバックも新しいリビジョンとして記録されます。

Helmチャートをインストールする前にレンダリングされたYAMLマニフェストを確認するには？

A) helm install --dry-runまたはhelm templateコマンドを使用する B) kubectl apply --dry-runのみ使用可能 C) values.yamlを直接読む必要がある D) Helmはプレビューをサポートしていない

正解: A

helm templateはローカルでチャートをレンダリングしてYAMLを出力します。helm install --dry-runはサーバーサイド検証も含めてレンダリングします。両コマンドとも実際のリソースを作成しないので、デプロイ前の検証に有用です。

Helmチャートで他のチャートへの依存関係を管理するには？

A) 手動ですべてのYAMLファイルをコピーする B) Chart.yamlのdependenciesセクションに定義してhelm dependency updateを実行する C) requirements.txtファイルを使用する D) kubectlで依存関係を管理する

正解: B

Chart.yamlのdependenciesセクションに依存チャートの名前、バージョン、リポジトリを定義します。helm dependency updateを実行するとcharts/ディレクトリに依存チャートがダウンロードされます。conditionやtagsを使用して選択的に有効化することもできます。

Sidecarコンテナとメインコンテナ間でファイルを共有するには？

A) ネットワークを通じてのみ共有可能 B) emptyDirボリュームを定義して両方のコンテナでvolumeMountsでマウントする C) コンテナ間で直接ファイルシステムアクセスが可能 D) ConfigMapのみ使用可能

正解: B

emptyDirボリュームをPodレベルで定義し、各コンテナのvolumeMountsで該当ボリュームをマウントすると同じディレクトリを共有できます。emptyDirはPodライフサイクルに従って作成/削除され、medium: Memoryに設定するとtmpfsを使用できます。

Helmでpre-install、post-installなどのhookの用途は？

A) Kubernetesイベントをモニタリングする B) チャートインストール/アップグレード/削除の特定時点でJobや他のリソースを実行できるようにする C) ネットワークポリシーを自動設定する D) Pod再起動ポリシーを管理する

正解: B

Helm hookはリリースライフサイクルの特定時点で作業を実行します。例えばpre-installでデータベースマイグレーション、post-installで初期データロード、pre-deleteでバックアップ実行などが可能です。hookはannotationでリソースに指定されます。

Kubernetes 1.28+で導入されたSidecarコンテナ（restartPolicy: AlwaysのinitContainers）の動作は？

A) メインコンテナと同時に起動される B) Initコンテナの順序で起動されるが、起動後完了を待たずに次のInitコンテナが実行され、Pod終了まで実行し続ける C) メインコンテナの後に起動される D) Initコンテナと完全に同じ動作をする

正解: B

Kubernetes 1.28+でinitContainersにrestartPolicy: Alwaysを設定するとネイティブサイドカーとして動作します。既存のInitコンテナの順序に従って起動しますが、起動後完了を待たずに次のコンテナが進行します。Pod全体のライフサイクル中実行され、Pod終了時にメインコンテナの後に終了します。

CRDを作成するとどのようなことが可能になりますか？

A) 既存のKubernetesリソースのスキーマを変更できる B) 新しいAPIリソースタイプを定義してkubectlで管理可能なカスタムリソースを作成できる C) KubernetesコアAPIを修正できる D) Podのランタイム動作を変更できる

正解: B

CRDを作成するとKubernetes APIに新しいリソースタイプが登録されます。kubectlでそのリソースのCRUD操作が可能になり、etcdに保存されます。Operatorパターンでは、CRDが望ましい状態を宣言的に定義するのに使用されます。

CRDのカスタムリソースに対するフィールド検証（validation）を設定するには？

A) 別途Webhookを必ず使用する必要がある B) CRDのspec.versions.schema.openAPIV3SchemaにJSON Schemaを定義する C) ConfigMapに検証ルールを保存する D) Kubernetesはカスタムリソース検証をサポートしていない

正解: B

openAPIV3SchemaフィールドにJSON Schemaを定義するとカスタムリソース作成/修正時にフィールドタイプ、必須フィールド、パターンなどを自動検証します。より複雑な検証が必要な場合はValidating Admission Webhookを追加で使用できます。

Validating Admission Webhookはいつ呼び出され、どのような役割を果たしますか？

A) リソースがetcdに保存された後に呼び出される B) APIリクエストが認証/認可を通過した後、etcdに保存される前に呼び出されてリクエストを許可または拒否する C) kubectlコマンド実行前に呼び出される D) Pod起動時に呼び出される

正解: B

Validating Admission WebhookはAPIリクエストが認証、認可、ミューテーション段階を通過した後に呼び出されます。リクエストを検査して許可（allow）または拒否（deny）を決定します。リクエスト内容を変更することはできず、変更が必要な場合はMutating Admission Webhookを使用します。

2種類のWebhookが両方設定されている場合の実行順序は？

A) Validatingが先に実行される B) Mutatingが先に実行され、その後Validatingが実行される C) 同時に実行される D) 順序はランダムである

正解: B

Admission処理順序は: 1) Mutating Admission Webhookが先に実行されてリクエストを修正、2) その後Validating Admission Webhookが修正されたリクエストを検証します。この順序のおかげでMutatingで追加されたデフォルト値などをValidatingで検証できます。

Kubernetes APIで特定リソースのAPIバージョンがdeprecated（非推奨）になった場合にすべきことは？

A) 何もしなくてよい B) deprecatedされたAPIバージョンを使用するすべてのマニフェストとツールを新しいAPIバージョンに更新する必要がある C) Kubernetesが自動的にマイグレーションする D) 以前のバージョンのクラスターにダウングレードする

正解: B

APIバージョンがdeprecatedされると一定リリース後に削除されます。kubectl convertコマンドか手動でマニフェストのapiVersionを更新する必要があります。CI/CDパイプライン、Helmチャート、運用スクリプトなどで使用するすべてのマニフェストを確認する必要があります。

kubectl convertコマンドはどのような目的で使用されますか？

A) コンテナイメージ形式を変換する B) KubernetesリソースマニフェストのAPIバージョンを他のバージョンに変換する C) YAMLをJSONに変換する D) Secretをエンコードする

正解: B

kubectl convertはリソースマニフェストのapiVersionを変換します。例えばapps/v1beta1のDeploymentをapps/v1に変換できます。このプラグインは別途インストールが必要で、APIマイグレーション時に有用です。

Admission Webhook設定でfailurePolicy: Ignoreの意味は？

A) Webhook呼び出しが失敗するとAPIリクエストを拒否する B) Webhook呼び出しが失敗すると該当Webhookを無視してAPIリクエストを許可する C) Webhookを無効化する D) エラーをログにのみ記録する

正解: B

failurePolicy: IgnoreはWebhookサーバーに接続できない、またはタイムアウト時にそのWebhookをスキップしてリクエストを許可します。failurePolicy: Fail（デフォルト）はWebhook失敗時にAPIリクエストを拒否します。重要なセキュリティWebhookはFailに、付加機能はIgnoreに設定するのが一般的です。

CRDでadditionalPrinterColumnsを設定するとどのような効果がありますか？

A) リソースの保存形式が変更される B) kubectl get出力にカスタム列が追加されて重要なフィールドをすぐに確認できる C) リソースの検証ルールが追加される D) APIサーバーのパフォーマンスが向上する

正解: B

additionalPrinterColumnsを使用するとkubectl get出力にカスタムリソースの特定フィールドを列として表示できます。jsonPathを指定してspecやstatusの特定フィールド値を表示します。リソースの状態を素早く把握するのに有用です。

CRDでstatusサブリソースを有効にするとどのような利点がありますか？

A) statusフィールドが自動的に更新される B) specとstatusの更新が分離され、コントローラーがstatusのみ独立して更新できる C) statusフィールドが削除される D) 検証が無効化される

正解: B

statusサブリソースを有効にすると/statusエンドポイントが生成されます。これによりspec更新とstatus更新を分離できます。ユーザーはspecを変更し、コントローラーはstatusを変更する関心事の分離が可能になります。RBACで別途権限管理も可能です。

Admission Webhookが特定のネームスペースにのみ適用されるようにするには？

A) すべてのネームスペースに適用する必要がある B) Webhook設定のnamespaceSelectorにラベルマッチング条件を指定する C) ネームスペースごとに別のWebhookを作成する必要がある D) PodにannotationをAppendする

正解: B

ValidatingWebhookConfigurationやMutatingWebhookConfigurationのnamespaceSelectorフィールドにmatchLabelsやmatchExpressionsを指定すると、該当条件に合うネームスペースのリソースにのみWebhookが適用されます。kube-systemなどシステムネームスペースを除外するのによく使用されます。

Startup Probeはどのような状況で使用されますか？

A) コンテナが正常に終了したか確認する B) 起動に時間がかかるアプリケーションで初期化が完了するまでliveness/readiness検査を遅延させる C) トラフィックルーティングを管理する D) ディスク使用量をモニタリングする

正解: B

Startup Probeはコンテナ起動時に一度だけ使用され、成功するまでlivenessとreadinessプローブが実行されません。Javaアプリや大規模データロードが必要なアプリのように初期化に時間がかかる場合、livenessプローブによる不要な再起動を防止します。

Kubernetes 1.24+でgRPCベースのヘルスチェックプローブを設定するには？

A) execプローブでgrpcurlコマンドを使用するしかない B) プローブにgrpcフィールドを使用してポートを指定する C) HTTPプローブのみ使用可能 D) TCPソケットプローブで代替する必要がある

正解: B

Kubernetes 1.24+ではgrpcプローブタイプがGAになりました。livenessProbeやreadinessProbeでgrpc.portを指定するとgRPC Health Checking Protocolを使用してヘルスチェックを実行します。オプションでserviceフィールドで特定サービスを指定できます。

kubectl debugコマンドで作成されるエフェメラルコンテナの特徴は？

A) 永続的にPodに追加される B) 実行中のPodに一時的にデバッグ用コンテナを追加し、Pod再起動なしでトラブルシューティングに使用される C) Podを新しく作成する D) ノードレベルでのみ実行される

正解: B

エフェメラルコンテナはkubectl debugで実行中のPodに追加できます。プローブ、ポート、リソース制限などを指定できず、Pod再起動なしでデバッグツールが含まれたイメージで問題を診断できます。デバッグイメージがないdistrolessコンテナの問題解決に特に有用です。

topologySpreadConstraintsを使用する目的は？

A) Podのリソース使用量を制限する B) Podを特定のトポロジードメイン（ノード、ゾーン、リージョン）に均等に分散配置する C) ネットワークポリシーを設定する D) ストレージを管理する

正解: B

topologySpreadConstraintsはPodをノード、アベイラビリティゾーン、リージョンなどのトポロジードメインにわたって均等に分散させます。maxSkewでドメイン間の最大不均衡数を指定し、whenUnsatisfiableで条件を満たせない場合の動作（DoNotScheduleまたはScheduleAnyway）を決定します。

maxSkew: 1に設定するとどのような意味ですか？

A) 最大1つのPodのみ作成される B) トポロジードメイン間のPod数の差が最大1を超えないようにする C) 1つのドメインにのみ配置する D) スケジューリング遅延が1秒である

正解: B

maxSkew: 1はトポロジードメイン間のマッチングPod数の最大差が1を超えてはならないことを意味します。例えば3つのzoneにPodを分散する場合、各zoneのPod数の差が1以内に維持されます。値が小さいほどより均等な分散を保証します。

Gateway APIが既存のIngressより改善された点は？

A) Gateway APIはIngressと同一である B) Gateway APIは役割ベースの分離（インフラ管理者、アプリ開発者）、マルチプロトコルサポート（HTTP、TCP、gRPC）、より細かいルーティングルールを提供する C) Gateway APIはHTTPのみサポートする D) Gateway APIはクラスター外部でのみ使用される

正解: B

Gateway APIはGatewayClass、Gateway、HTTPRouteなどのリソースを通じて役割ベースの管理をサポートします。インフラチームがGatewayClassとGatewayを管理し、アプリチームがRouteを管理します。HTTP、TCP、TLS、gRPCなど様々なプロトコルとヘッダーベースのルーティング、加重分配などをサポートします。

Gateway APIのHTTPRouteで2つのサービスにトラフィックを80:20で分配するには？

A) Ingress annotationを使用する B) HTTPRouteのbackendRefsに2つのサービスを指定しそれぞれweightを80と20に設定する C) Serviceのselectorを変更する D) 別のロードバランサーを使用する

正解: B

HTTPRouteのrules.backendRefsに複数のサービスを指定してweightフィールドを設定すると加重ベースのトラフィック分配が可能です。これはカナリアデプロイメント、A/Bテスト、段階的ロールアウトに有用です。

projectedボリュームタイプはどのような目的で使用されますか？

A) 外部ストレージをマウントする B) 複数のボリュームソース（Secret、ConfigMap、downwardAPI、serviceAccountToken）を1つのディレクトリに統合マウントする C) ボリュームを暗号化する D) ボリュームを他のPodと共有する

正解: B

projectedボリュームは複数ソースのデータを単一のマウントポイントに結合します。Secret、ConfigMap、Downward API、ServiceAccountトークンを1つのディレクトリに一緒にマウントできます。特にbound service account tokenを使用する際によく活用されます。

Kubernetesネイティブリソースのみで簡単なカナリアデプロイメントを実装するには？

A) DeploymentのstrategyをCanaryに設定する B) 2つのDeploymentを作成して同じlabel selectorを使用するServiceで接続し、カナリアDeploymentのreplicasを調整してトラフィック比率を管理する C) StatefulSetのみ使用する D) DaemonSetでのみ可能

正解: B

KubernetesにはネイティブのCanaryデプロイメント戦略がありません。しかし同じServiceセレクターにマッチする2つのDeploymentを作成してレプリカ数を調整すると簡単なCanaryが可能です。より精緻な制御にはIstio、Gateway APIなどの加重ルーティングを使用します。

kubectl debugを使用してノードのファイルシステムにアクセスするには？

A) SSHでのみアクセス可能 B) kubectl debug node/NODE_NAME --image=IMAGEコマンドでノードにデバッグPodを作成してホストファイルシステムにアクセスする C) kubeletを再起動する必要がある D) ノードにDaemonSetをデプロイする必要がある

正解: B

kubectl debug node/NODE_NAMEコマンドは対象ノードに特権（privileged）Podを作成しホストのファイルシステムを/hostにマウントします。chroot /hostでホスト環境に直接アクセスでき、kubeletログ確認、ネットワーク設定点検、ディスク状態確認などに有用です。