KCNA Kubernetesクラウドネイティブアソシエイト 模擬試験60問

A) kube-apiserver B) etcd C) kube-scheduler D) kube-controller-manager

答え: B

解説: etcdはKubernetesの分散キー・バリューストアで、すべてのクラスター状態と設定データを永続的に保存します。kube-apiserverのみがetcdに直接アクセスします。

A) kubelet B) kube-proxy C) kube-scheduler D) kube-controller-manager

答え: C

解説: kube-schedulerはまだノードに割り当てられていない新規作成のPodを検知し、リソース要件、nodeSelector、affinityなどの条件を基に最適なノードを選択します。

A) クラスターネットワークポリシーの管理 B) 各ワーカーノードでPodとコンテナのライフサイクルを管理 C) APIリクエストの認証と認可 D) クラスター状態データの保存

答え: B

解説: kubeletは各ワーカーノードで実行され、kube-apiserverからPodSpecを受け取り、そのSpecに従ってコンテナが実行・正常動作するよう管理します。コンテナランタイムと通信してコンテナの起動・停止を行います。

A) Container B) Pod C) ReplicaSet D) Node

答え: B

解説: PodはKubernetesでデプロイ可能な最小単位です。1つ以上のコンテナを含み、ネットワーク名前空間とストレージを共有します。同一Pod内のコンテナはlocalhostで通信します。

A) kube-scheduler B) DaemonSet C) ReplicaSet D) StatefulSet

答え: C

解説: ReplicaSetは指定されたPodレプリカ数が常に実行中であることを保証します。DeploymentはReplicaSetを管理し、宣言的な更新とロールバック機能を提供します。

A) NodePort B) LoadBalancer C) ClusterIP D) ExternalName

答え: C

解説: ClusterIPはデフォルトのServiceタイプで、クラスター内部からのみアクセス可能な仮想IPを割り当てます。NodePortは各ノードのポートを通じた外部アクセスを、LoadBalancerはクラウドプロバイダーのロードバランサーをプロビジョニングします。

A) Label B) Annotation C) Namespace D) ConfigMap

答え: C

解説: Namespaceは1つのクラスター内でリソースを論理的に分離するメカニズムです。チーム別や環境別（dev/staging/prod）の分離に活用されます。デフォルトのNamespaceにはdefault、kube-system、kube-publicがあります。

A) Secret B) ConfigMap C) PersistentVolume D) ServiceAccount

答え: B

解説: ConfigMapは非機密の設定データをキー・バリューのペアで保存します。環境変数やボリュームマウントを通じてPodに注入されます。機密データ（パスワード、トークン）にはSecretを使用すべきです。

A) 実行するアクションをステップバイステップで命令する B) 望ましい最終状態を定義し、システムがその状態を達成する C) コマンドで即座にリソースを操作する D) 現在の状態を参照するだけのモード

答え: B

解説: 宣言的アプローチはkubectl apply -f manifest.yamlのように望ましい最終状態をYAML/JSONで定義します。Kubernetesが現在の状態と比較し、望ましい状態に収束させます。命令的（Imperative）アプローチはkubectl create deploymentのように即時のアクションを指示します。

A) Image Specification B) Runtime Specification C) Distribution Specification D) Orchestration Specification

答え: D

解説: OCIはImage Spec（イメージフォーマット）、Runtime Spec（コンテナ実行方式）、Distribution Spec（レジストリ配布プロトコル）の3つの仕様を定義します。オーケストレーションはOCI仕様に含まれず、Kubernetesなどの別ツールの領域です。

A) containerdはDockerを完全に代替できない B) DockerはcontainerdをContainerRuntimeとして内部的に使用し、containerdは独立したコンテナランタイムである C) containerdはKubernetes専用のランタイムである D) DockerとcontainerdはCNCFの同じプロジェクトである

答え: B

解説: DockerはユーザーフレンドリーなCLIとビルドツールを含むプラットフォームで、内部的にcontainerdをコンテナランタイムとして使用します。containerdはCNCFのGraduatedプロジェクトで、Docker無しでKubernetesのCRI（Container Runtime Interface）を通じて直接使用できます。

A) Podのネットワーク速度を制限するため B) スケジューラーが適切なノードを選択し、ノードのリソース枯渇を防ぐため C) コンテナイメージのサイズを削減するため D) Serviceへのトラフィックを均等に分配するため

答え: B

解説: requestsはkube-schedulerがPodを配置するノードを選択する際の基準です。limitsはコンテナが使用できる最大リソースを制限し、ノードのリソース枯渇を防ぎます。CPU limitを超えるとスロットリング、Memory limitを超えるとOOMKilledが発生します。

A) Labelはマシンが読むためのもので、Annotationは人間が読むためのものだ B) LabelはKubernetesオブジェクトに付けるキー・バリューのペアで、Selectorを通じてオブジェクトグループを選択するのに使用する C) Labelは1つのオブジェクトに1つしか付けられない D) SelectorはNamespaceをまたいで機能する

答え: B

解説: Labelはapp: nginx、env: productionのようなキー・バリューのペアです。Service、ReplicaSetなどはSelectorを通じて特定のLabelを持つPodを選択・管理します。AnnotationはLabelと異なりオブジェクト選択には使用されず、非構造的なメタデータを格納します。

A) 指定されたPodレプリカ数を維持する B) クラスターのすべて（または一部）のノードに正確に1つのPodを実行する C) 一回性タスクの実行に使用される D) ステートフルなアプリケーションのデプロイに最適化されている

答え: B

解説: DaemonSetはすべてのノード（またはnodeSelectorで指定されたノード）にPodが1つずつ実行されることを保証します。監視エージェント（Prometheus Node Exporter）、ログコレクター（Fluentd）、ネットワークプラグイン（CNI）など、すべてのノードで実行される必要があるシステムデーモンに適しています。

A) StatefulSetはより多くのレプリカをサポートする B) StatefulSetは各Podに安定した固有のネットワークIDと永続ストレージを保証する C) StatefulSetはローリングアップデートをサポートしない D) StatefulSetは外部トラフィックを直接受信する

答え: B

解説: StatefulSetは各Podに安定した固有の名前（pod-0、pod-1...）と永続ストレージ（PersistentVolumeClaim）を提供します。データベース（MySQL、PostgreSQL）や分散メッセージブローカー（Kafka）などのステートフルなアプリケーションに適しています。Podは順番に起動し、逆順に終了します。

A) nodeSelectorはハードルールのみサポートし、Node Affinityはハードとソフトのルールをサポートする B) Node Affinityは古い機能でnodeSelectorが最新機能である C) nodeSelectorは複数の条件をサポートする D) 2つの機能は完全に同じである

答え: A

解説: nodeSelectorはシンプルなkey=valueマッチングのみをサポートし、必ず一致する必要があります。Node AffinityはrequiredDuringSchedulingIgnoredDuringExecution（ハード、必須）とpreferredDuringSchedulingIgnoredDuringExecution（ソフト、優先）の2つのルールをサポートし、複雑な式（In、NotIn、Existsなど）を使用できます。

A) TaintはPodに、TolerationはNodeに適用する B) NodeにTaintをセットすると、そのTaintをTolerationできないPodはそのノードにスケジューリングされない C) TaintはPodを特定のノードに必ず配置するよう強制する D) TolerationはPod間のネットワーク通信を制限する

答え: B

解説: Taintはノードに設定します（例: kubectl taint nodes node1 key=value:NoSchedule）。TaintがあるノードにはそのTaintをTolerationできるPodのみがスケジューリングされます。Node AffinityはPodが特定のノードを選好・要求する概念です。Taintはノードから不要なPodを排除し、Tolerationはそれを許容する仕組みです。

A) Podが即座に削除される B) そのPodへのトラフィックが送信されなくなる C) コンテナが再起動される D) Nodeが隔離される

答え: C

解説: Liveness Probeはアプリケーションが生きているか（alive）チェックします。失敗するとkubeletがそのコンテナを再起動します。Readiness Probeの失敗ではServiceのエンドポイントから除外されてトラフィックが送信されなくなりますが、再起動はされません。

A) 既存Podのリソースを動的に増加させる B) メトリクスに基づいてDeploymentのレプリカ数を自動調整する C) クラスターに新しいノードを自動追加する D) Podのネットワーク帯域を自動調整する

答え: B

解説: HPAはCPU使用率、メモリ、またはカスタムメトリクスに基づいてDeploymentやStatefulSetのPodレプリカ数を自動的に増減します。VPA（Vertical Pod Autoscaler）は個々のPodのリソース要求・制限を調整し、Cluster AutoscalerはNode数を調整します。

A) maxSurge: 同時に削除できるPod数、maxUnavailable: 追加作成できるPod数 B) maxSurge: 更新中に追加作成できるPod数、maxUnavailable: 更新中に利用不可にできるPod数 C) maxSurge: 最大ノード数、maxUnavailable: 最小ノード数 D) 両パラメーターはStatefulSetにのみ適用される

答え: B

解説: Rolling Update戦略でmaxSurgeはデザインされたレプリカ数を超えて一時的に作成できるPodの最大数（絶対値または%）、maxUnavailableは更新中に利用不可能な状態にあるPodの最大数です。これによりゼロダウンタイムデプロイが可能になります。

A) Jobは繰り返し実行、CronJobは一回性実行に使用する B) Jobは一回性タスクの完了を保証し、CronJobはスケジュールに従って定期的にJobを作成する C) CronJobはKubernetesでサポートされていない D) 両リソースは同じ機能をする

答え: B

解説: Jobは指定された数のPodが正常に完了するまで実行します（バッチ処理、データ移行など）。CronJobはLinuxのcrontabのようにスケジュール（例: 0 2 * * *）に従って定期的にJobオブジェクトを作成して実行します（定期レポート、バックアップなど）。

A) 設定をコードにハードコードする B) 環境（dev/staging/prod）によって変わる設定を環境変数に格納する C) 設定ファイルをコードリポジトリにコミットする D) すべての設定をデータベースに格納する

答え: B

解説: 12-Factor AppのConfig原則は、コードで変わる設定（DBのURL、APIキーなど）をコードから分離して環境変数に格納することを推奨します。KubernetesではConfigMapとSecretがこの原則を実装する手段です。

A) サービスごとの独立したデプロイとスケーリング B) テクノロジースタックの柔軟な選択 C) シンプルな運用複雑性 D) 障害分離（Fault Isolation）

答え: C

解説: マイクロサービスはサービス別の独立デプロイ、個別スケーリング、技術の多様性、障害分離などの利点があります。一方で、サービス間通信（ネットワークレイテンシ）、分散トランザクション、サービスディスカバリ、運用複雑性の増大が欠点です。モノリシックより運用複雑性が高くなります。

A) サービス間のmTLS（相互TLS）暗号化 B) トラフィック管理（カナリアデプロイ、A/Bテスト） C) 分散トレーシングとObservability D) コンテナイメージビルドの自動化

答え: D

解説: サービスメッシュ（Istio、Linkerdなど）はアプリケーションコードを変更せずにサービス間通信にmTLS、トラフィック管理（重み付きルーティング、サーキットブレーカー）、分散トレーシング、Observabilityを提供します。コンテナイメージビルドはCIパイプラインの役割です。

A) Kubernetesクラスターのプロビジョニング B) Kubernetes上でサーバーレスワークロード（イベント駆動、スケール・トゥ・ゼロ）を実行 C) コンテナレジストリの管理 D) 分散データベースの運用

答え: B

解説: KnativeはCNCFプロジェクトで、Kubernetesを基盤にサーバーレス機能を提供します。Serving（HTTPワークロードの自動スケーリング、スケール・トゥ・ゼロ）とEventing（イベントソースとコンシューマーを繋ぐメッセージングシステム）で構成されます。

A) 運用者がクラスターに直接接続してkubectlで変更する B) Gitリポジトリをインフラ状態の唯一の真実の情報源として使用し、自動化されたエージェントがGitの状態に同期する C) CIパイプラインが直接プロダクションクラスターにデプロイする D) インフラ変更は手動承認なしに即時適用される

答え: B

解説: GitOpsはすべてのインフラとアプリケーション設定をGitに宣言的に格納し、ArgoCDやFluxのようなGitOpsエージェントがクラスター状態をGitの状態と継続的に同期します。変更はPull Requestを通じてGitに反映され、監査証跡（audit trail）が自動的に作成されます。

A) コンテナイメージの脆弱性スキャン B) Gitリポジトリの状態とKubernetesクラスターを継続的に同期するGitOps CDツール C) Kubernetesクラスターの監視 D) シークレット暗号化管理

答え: B

解説: ArgoCDはCNCFのGraduatedプロジェクトで、Gitリポジトリ（Helmチャート、Kustomize、通常のYAML）に定義されたアプリケーション状態とKubernetesクラスターを自動同期します。UIダッシュボードで同期状態の確認、手動同期、ロールバックが可能です。

A) CPU、Memory、Disk B) Metrics、Logs、Traces C) Deployment、Service、Ingress D) Build、Test、Deploy

答え: B

解説: クラウドネイティブObservabilityの3つの核心要素（Three Pillars）はMetrics（数値ベースの時系列データ）、Logs（イベントベースのテキスト記録）、Traces（分散システムでのリクエストフロー追跡）です。OpenTelemetryはこの3つを統合する標準フレームワークです。

A) アプリケーションがPrometheusサーバーにデータをPushする B) PrometheusサーバーがアプリケーションのメトリクスエンドポイントからデータをPullする C) メッセージブローカーを通じて非同期に収集する D) データベースから定期的にクエリする

答え: B

解説: PrometheusはデフォルトでPull方式を使用します。監視対象（Target）の/metrics HTTPエンドポイントから定期的にメトリクスをスクレイプします。ただし、短命なJobのようにPullが難しい場合はPushgatewayを通じたPush方式もサポートします。

A) Kubernetesクラスターデプロイの自動化 B) Metrics、Logs、Tracesを収集するためのベンダー中立な標準API、SDK、ツールの提供 C) コンテナイメージレジストリの標準化 D) KubernetesネットワークポリシーLの管理

答え: B

解説: OpenTelemetry（OTel）はCNCFプロジェクトで、Observabilityデータ（Metrics、Logs、Traces）を生成・収集・エクスポートするためのベンダー中立な標準を提供します。アプリケーションにOTel SDKを追加すると、Prometheus、Jaeger、Zipkin、Datadogなどへデータをエクスポートできます。

A) コンテナログの集約 B) 分散トレーシング（Distributed Tracing）- マイクロサービス間のリクエストフロー追跡 C) CPU/メモリメトリクスの可視化 D) Kubernetesクラスター状態の監視

答え: B

解説: JaegerはCNCFのGraduatedプロジェクトで、分散トレーシングシステムです。マイクロサービス間のリクエストがどのサービスを通じて処理されるか可視化し、レイテンシのボトルネックを特定するのに使用されます。Zipkinと同様の機能を提供します。

A) コンテナイメージの脆弱性スキャン B) 各種データソース（Prometheus、Elasticsearchなど）のメトリクスを可視化するダッシュボードツール C) CI/CDパイプラインの実行 D) KubernetesローリングアップデートLの管理

答え: B

解説: GrafanaはPrometheus、InfluxDB、Elasticsearch、Lokiなど様々なデータソースを接続してメトリクス、ログ、トレースを可視化するオープンソースのダッシュボードプラットフォームです。AlertManagerとの連携でアラート設定も可能です。

A) Kubernetesクラスターのプロビジョニング B) KubernetesアプリケーションのパッケージングL、デプロイ、管理のためのパッケージマネージャー C) コンテナイメージビルドツール D) ノードの自動スケーリング

答え: B

解説: HelmはKubernetesのパッケージマネージャーで、アプリケーションに関する複数のYAMLマニフェストをChartという単位にパッケージ化します。values.yamlでパラメーター化されたデプロイが可能で、helm install、helm upgrade、helm rollbackコマンドでアプリケーションのライフサイクルを管理します。

A) Kustomizeは有料ツールで、Helmは無料である B) Kustomizeはテンプレートなしにオーバーレイ方式でYAMLをカスタマイズし、HelmはGoテンプレートベースのパッケージングを使用する C) KustomizeはKubernetesで公式サポートされていない D) Helmはマルチクラスターデプロイをサポートしない

答え: B

解説: KustomizeはKubernetesに内蔵されており（kubectl apply -k）、ベースのYAMLを変更せずにオーバーレイで環境差分を適用します。HelmはGoテンプレートでYAMLを動的に生成するパッケージマネージャーです。両ツールは併用されることもあります。

A) 2つの用語は完全に同じである B) Continuous Deliveryはプロダクションデプロイ前に手動承認が必要、Continuous Deploymentはプロダクションまで自動でデプロイする C) Continuous Deploymentはステージング環境にのみ自動デプロイされる D) Continuous Deliveryはコードを自動ビルドするステップである

答え: B

解説: **Continuous Integration（CI）**はコード変更を自動ビルド・テストするステップです。Continuous DeliveryはCI後ステージングまで自動デプロイされますが、プロダクションは手動承認が必要です。Continuous Deploymentはテスト通過後にプロダクションまで自動デプロイされます。

A) コンテナイメージをノードにダウンロード B) 各ノードでServiceのネットワークルール（iptables/IPVS）を管理し、クラスター内トラフィックをPodにルーティング C) コントロールプレーンとワーカーノード間の通信暗号化 D) ノードの状態を定期的に報告

答え: B

解説: kube-proxyは各ノードで実行され、KubernetesのServiceオブジェクトが作成・変更されるとノードのネットワークルール（デフォルトiptables、またはIPVS）を更新して、ClusterIPへのトラフィックを実際のPod IPにルーティングします。

A) PVCはPVを作成するツールである B) PVはクラスター管理者がプロビジョニングしたストレージで、PVCはユーザーがストレージを要求するリソースである C) PVとPVCは常に同じNamespaceにある必要がある D) PVCは一時ストレージにのみ使用される

答え: B

解説: PersistentVolume（PV）はクラスター管理者がプロビジョニングした実際のストレージリソースです。PersistentVolumeClaim（PVC）はユーザーがストレージを要求するオブジェクトで、容量とAccessModeを指定します。PVCとPVはバインドされてPodにマウントされます。StorageClassを通じた動的プロビジョニングも可能です。

A) Pod間の内部通信を管理 B) クラスター外部からのHTTP/HTTPSトラフィックをServiceにルーティングするルールを定義 C) ノード間のネットワーク暗号化 D) ストレージアクセス制御

答え: B

解説: IngressはHTTP/HTTPSの外部リクエストをクラスター内のServiceにルーティングするルールを定義します。ホスト名ベース（app.example.com）、パスベース（/api、/web）のルーティング、TLSターミネーションをサポートします。実際の動作はNginx、Traefik、EnvoyなどのIngress Controllerが担います。

A) クラウドインフラを直接運用する組織 B) クラウドネイティブ技術のオープンソースプロジェクトを管理し、エコシステムを発展させるLinux Foundation傘下の非営利財団 C) Kubernetesを作った会社 D) AWS、GCP、Azureの連合団体

答え: B

解説: CNCFはLinux Foundation傘下の非営利組織で、Kubernetes、Prometheus、Envoy、Containerd、ArgoCDなどのクラウドネイティブオープンソースプロジェクトを中立的に管理します。Sandbox → Incubating → Graduatedのステージでプロジェクトの成熟度を管理します。

A) 人がクラスターにログインするアカウント B) PodがKubernetes APIを呼び出す際に使用する認証ID C) ノード間認証に使用するアカウント D) Ingressアクセス制御に使用するアカウント

答え: B

解説: ServiceAccountはPod（アプリケーション）がKubernetes APIにアクセスする際のアイデンティティです。作成時にトークンが自動付与され、RBACで必要な権限のみを付与します。人間のアクセスにはUserまたはGroupを使用します。

A) 各RUN命令は新しいレイヤーを作成し、レイヤーは不変で再利用される B) コンテナイメージは1つのレイヤーのみで構成される C) レイヤーはランタイムに動的に変更される D) イメージレイヤーはKubernetesノードでのみキャッシュされる

答え: A

解説: Docker/OCIイメージは複数の不変レイヤーのスタックで構成されます。DockerfileのFROM、RUN、COPYなどの各命令が新しいレイヤーを作成します。同一レイヤーは複数のイメージで共有（再利用）されてストレージを節約します。コンテナ実行時には読み書き可能なレイヤーが最上部に追加されます。

A) サーバーを絶対に削除しないポリシー B) デプロイされたインフラを変更せず、変更が必要な場合は新しいインスタンスを作成して入れ替える方式 C) データを変更できないようにロック D) インフラのコードを読み取り専用に保持

答え: B

解説: Immutable Infrastructureは一旦デプロイされたサーバーやコンテナを直接変更せず、変更が必要な場合は新しいイメージをビルドして新しいインスタンスに置き換えます。「設定ドリフト（configuration drift）」を防ぎ、一貫性を保証します。Kubernetesのコンテナモデルはこの原則に従っています。

A) CPU/メモリのみに基づいてスケーリングする B) メッセージキューの深さやイベント数など外部イベントソースに基づいてPodを0からスケールする C) クラスターのノード数を自動調整する D) VPAと同じ機能を実行する

答え: B

解説: KEDAはCNCFのGraduatedプロジェクトで、Kafkaトピックのメッセージ数、RabbitMQキューの深さ、Azure Service Bus、AWS SQSなど60以上のスケーラーをサポートし、イベント駆動でPodを0からNまで自動スケーリングします。標準HPAを拡張します。

A) デフォルトですべてのPod間トラフィックがブロックされる B) NetworkPolicyがなければすべてのPod間トラフィックが許可される C) NetworkPolicyはコントロールプレーンコンポーネント間の通信のみを制御する D) NetworkPolicyは外部インターネットトラフィックのみを制御する

答え: B

解説: Kubernetesはデフォルトで「オープン by default」ポリシーを採用しており、NetworkPolicyオブジェクトがなければすべてのPod間トラフィックが許可されます。NetworkPolicyを適用すると、そのPodへのIngress/Egressトラフィックをホワイトリスト方式で制限できます。NetworkPolicyの実装はCNIプラグイン（Calico、Ciliumなど）が担います。

A) AES-256で暗号化されて保存 B) Base64でエンコードされてetcdに保存（暗号化ではない） C) SHA-256ハッシュで保存 D) プレーンテキストで保存

答え: B

解説: KubernetesのSecretに保存されたデータはデフォルトでbase64エンコードされてetcdに保存されます。Base64はエンコードであり暗号化ではありません。セキュリティのためにetcdのEncryption at Restを有効にするか、HashiCorp VaultやExternal Secrets Operatorなどの外部シークレット管理ツールを使用することが推奨されます。

A) etcdはワーカーノードで実行される B) etcdはRaft合意アルゴリズムを使用する分散キー・バリューストアで、奇数個のインスタンス（3、5、7）を推奨する C) etcdはコンテナイメージを保存する D) etcdのデータはメモリにのみ保存され、再起動時に初期化される

答え: B

解説: etcdはコントロールプレーンの分散キー・バリューストアで、すべてのKubernetesクラスター状態を永続的に保存します。Raft合意アルゴリズムでデータ整合性を保証します。高可用性のために3、5、7個（奇数）のインスタンスが推奨されます。etcdデータの損失はクラスター全体の損失を意味するため、定期的なバックアップが必須です。

A) Always B) OnFailure C) Never D) OnSuccess

答え: D

解説: PodのrestartPolicyはAlways（デフォルト、常に再起動）、OnFailure（失敗時のみ再起動）、Never（再起動しない）の3つです。OnSuccessは存在しないオプションです。JobにはOnFailureまたはNeverを使用し、DeploymentにはAlwaysが強制されます。

A) コンテナイメージのキャッシング B) クラスター内のサービスディスカバリのためのDNSサーバーの役割 C) ノード間のネットワーク暗号化 D) Ingressトラフィックのロードバランシング

答え: B

解説: CoreDNSはKubernetesクラスターのデフォルトDNSサーバーです。サービス名でDNSクエリができるようにし、サービスディスカバリをサポートします。例えばmy-service.my-namespace.svc.cluster.localの形式でサービスを見つけることができます。

A) kube-apiserver B) kube-scheduler C) kubelet D) kube-controller-manager

答え: C

解説: kubeletはワーカーノードのコンポーネントです。コントロールプレーンのコンポーネントはkube-apiserver、etcd、kube-scheduler、kube-controller-manager（および一部のcloud-controller-manager）です。kubeletはすべてのノードで実行される場合もありますが、ワーカーノードの核心コンポーネントです。

A) 環境変数として注入（envFrom） B) ボリュームとしてマウント C) Podイメージに直接ビルド D) 個別環境変数として注入（env.valueFrom）

答え: C

解説: ConfigMapをPodに注入する方法は環境変数（envFrom.configMapRefで全体、またはenv.valueFrom.configMapKeyRefで個別キー）とボリュームマウント（ファイルとしてマウント）です。イメージに直接ビルドすることはImmutable Infrastructureの原則に反し、ConfigMapの目的（ランタイム設定の分離）に合いません。

A) 外部IPをクラスター内のServiceとして公開する B) クラスター内部で外部DNS名をService名として抽象化する（CNAMEの役割） C) すべてのノードのポートを外部に公開する D) クラウドプロバイダーのロードバランサーをプロビジョニングする

答え: B

解説: ExternalName ServiceはクラスターLAの内部から外部DNS名（例: my-external-db.example.com）へのCNAMEレコードを作成します。内部サービスが外部サービスを抽象化された名前でアクセスできるため、外部エンドポイントが変更されてもService名は維持されます。

A) アプリケーションコンテナと同時に起動する B) メインコンテナより先に順次実行され、完了するとメインコンテナが起動する C) バックグラウンドで継続的に実行される D) ノードの初期化にのみ使用される

答え: B

解説: init containerはメインコンテナ（appコンテナ）が起動する前に実行される特殊なコンテナです。複数のinit containerがある場合は順次実行され、それぞれが完了（exit 0）すると次が実行されます。データベース準備待ち、設定ファイル生成、依存関係のダウンロードなどに活用されます。

A) チャートのバージョンと依存関係情報を定義 B) チャートのデフォルト設定値を定義し、デプロイ時にオーバーライド可能 C) デプロイするKubernetesリソーステンプレートを含む D) チャートの使用方法をドキュメント化

答え: B

解説: HelmチャートLのvalues.yamlはチャートのデフォルト値を定義します。helm installやhelm upgrade時に--set key=valueや-f custom-values.yamlでLオーバーライドできます。Chart.yamlはチャートのメタデータ、templates/ディレクトリはKubernetesリソーステンプレートを含みます。

A) Kubernetes B) Prometheus C) Terraform D) Argo

答え: C

解説: TerraformはHashiCorpのインフラプロビジョニングツールでCNCFプロジェクトではありません（BSLライセンス）。CNCF GraduatedプロジェクトにはKubernetes、Prometheus、Envoy、CoreDNS、containerd、Argo、Flux、Jaeger、Vitessなどがあります。

A) Podを特権（privileged）モードで実行する B) コンテナがrootユーザー（UID 0）で実行されることを禁止する C) コンテナ内部のファイルシステムを読み取り専用に設定する D) コンテナのネットワークアクセスを制限する

答え: B

解説: runAsNonRoot: trueはコンテナがroot（UID 0）として実行されると起動を拒否します。イメージにroot以外のユーザーが設定されている必要があります。コンテナエスケープ攻撃でのroot権限取得を防ぐ重要なセキュリティ設定です。runAsUser: 1000と組み合わせて使用するのが一般的です。

A) コンテナが再起動される B) Podが削除される C) ServiceのエンドポイントL から除外されてトラフィックを受け取らなくなる D) ノードが隔離される

答え: C

解説: Readiness Probeはコンテナがトラフィックを処理する準備ができているかチェックします。失敗するとそのPodはServiceのEndpointsオブジェクトから除外されてトラフィックを受け取りません。再起動は発生しません。アプリケーション起動時間が長い場合や一時的な過負荷状態で有用です。

A) kube-system NamespaceにはKubernetesシステムコンポーネントが実行される B) NamespaceはNodeやPersistentVolumeのようなクラスター全体のリソースを分離する C) ResourceQuotaでNamespace別のリソース使用量を制限できる D) default Namespaceは別途Namespaceを指定しないリソースが作成される場所である

答え: B

解説: NamespaceはPod、Deployment、ServiceのようなNamespaceレベルのリソースを分離します。Node、PersistentVolume、StorageClass、ClusterRoleのようなクラスター全体のリソースはNamespaceに属しません。ResourceQuotaとLimitRangeでNamespace別のリソース使用量制限が可能です。

A) kubectl restart deployment my-app B) kubectl rollout undo deployment/my-app C) kubectl revert deployment my-app D) kubectl restore deployment my-app

答え: B

解説: kubectl rollout undo deployment/my-appで以前のReplicaSetにロールバックします。kubectl rollout history deployment/my-appで履歴を確認し、--to-revision=2で特定バージョンにロールバックできます。kubectl rollout statusでロールアウト/ロールバックの進行状況をリアルタイムに監視します。

A) 電気回路の保護 B) 失敗しているサービスへのリクエストを遮断してカスケード障害（Cascading Failure）を防ぐ C) ネットワークトラフィックの暗号化 D) データベース接続プールの管理

答え: B

解説: サーキットブレーカーパターンはマイクロサービスで特定サービスが繰り返し失敗する際に、そのサービスへのリクエストを即座に失敗処理してシステム全体への障害伝播を防ぎます。Istio、Envoy、Resilience4jなどで実装されます。Closed（正常）→ Open（遮断）→ Half-Open（テスト）の3つの状態を持ちます。

A) Cluster Autoscalerが必ず導入されていなければならない B) PodにリソースのrequestsLが設定されていて、Metrics Server（またはカスタムメトリクスサーバー）が実行中でなければならない C) StatefulSetにのみ適用可能である D) 最低3つ以上のノードが必要である

答え: B

解説: HPAがCPUベースで動作するには2つの条件が必要です。1) 対象PodにCPUのrequestsが設定されていること（現在の使用率 = 実際の使用量 / requests）。2) クラスターにMetrics Serverがデプロイされてメトリクスを収集できること。カスタムメトリクス（KEDA）は別途アダプターが必要です。