Kubernetes and Cloud Native Associate (KCNA) #9 模擬選択式試験: 50問 + 解説
読了 21分
#1 から #8 まで整理した概念が頭に定着しているかを確認するステップです。本物の KCNA と同じドメイン比重で 50 問 を解きます。本記事がシリーズの最終回です。
KCNA の本試験は 60 問ですが、本模試は採点を 50 問基準にしています。合格点は同じく 75% で、50 問中 38 問 以上正解で合格圏とみなします。
解き方 #
- 60〜75 分 以内に解いてみます (本試験は 60 問 90 分ですが、本模試は 50 問基準)
- 1 問ずつ解いてすぐに解説を見ず、最後まで解いてから採点します
- 38 問 (75%) 以上 正解で合格圏とみなします
- 弱いドメインが見つかったら、該当する記事に戻ってもう一度整理します
ドメイン分布 #
| ドメイン | 問題数 | 範囲 |
|---|---|---|
| Domain 1: Kubernetes Fundamentals (46%) | 23 | Q1 〜 Q23 |
| Domain 2: Container Orchestration (22%) | 11 | Q24 〜 Q34 |
| Domain 3: Cloud Native Architecture (16%) | 8 | Q35 〜 Q42 |
| Domain 4: Cloud Native Observability (8%) | 4 | Q43 〜 Q46 |
| Domain 5: Cloud Native Application Delivery (8%) | 4 | Q47 〜 Q50 |
Domain 1: Kubernetes Fundamentals #
Q1. control plane でクラスターのすべての状態 (望ましい状態と現在の状態) を保存するコンポーネントはどれですか。
解説
etcd はクラスター全体の状態を保持する分散キーバリューストアです。scheduler は Pod をノードに配置し、controller-manager はコントローラーループを回し、kubelet は worker node でコンテナを実行するため、状態保存とは役割が異なります。
Q2. クラスターへのすべてのリクエストが通過する単一の入口であり、etcd にアクセスする唯一のコンポーネントはどれですか。
解説
kube-apiserver はすべての kubectl・コントローラー・kubelet のリクエストが通過する control plane の正面玄関であり、etcd に直接読み書きする唯一のコンポーネントです。kube-proxy はノードのネットワークルールを担当し、kubelet はコンテナの実行を担当します。
Q3. 新しく生成された Pod をどの worker node で実行するかを決定する control plane コンポーネントはどれですか。
解説
kube-scheduler はリソース要求・ノード状態・affinity などを評価して Pod をノードに配置します。kubelet は配置が終わった後、該当ノードでコンテナを実際に立ち上げるエージェントです。
Q4. worker node で control plane から PodSpec を受け取り、コンテナが指定どおり実行され続けているかを保証するエージェントはどれですか。
解説
kubelet は各 worker node で動作し、PodSpec に合わせてコンテナが立ち上がっているかを継続的に保証します。kube-proxy は Service トラフィックのルーティングを担当し、containerd は実際にコンテナを実行するランタイムです。
Q5. Kubernetes でデプロイ・管理される最小の実行単位は何ですか。
解説
Kubernetes がスケジューリングして管理する最小単位は Pod です。コンテナは Pod の中で動作し、Kubernetes はコンテナを直接スケジューリングせず、常に Pod 単位で扱います。
Q6. 1 つの Pod の中に 2 つ以上のコンテナが一緒に入る場合、それらが共有するものはどれですか。(Choose TWO)
解説
同じ Pod のコンテナはネットワークネームスペース (同じ IP・localhost) とボリュームを共有します。イメージはコンテナごとに異なり、CPU コア番号や単一の PID 1 を共有するという概念は Pod の共有モデルには該当しません。
Q7. 指定した数の同一 Pod レプリカが常に維持されることを保証するリソースはどれですか。
解説
ReplicaSet は望ましいレプリカ数を維持します。DaemonSet はノードごとに 1 つ、Job は完了が目標の一回限りの作業、StatefulSet は安定した識別子が必要なステートフルワークロードに使われます。
Q8. ReplicaSet と比べたとき、Deployment が追加で提供する中核機能はどれですか。
解説
Deployment は ReplicaSet を管理しながら、ローリングアップデートと以前のバージョンへのロールバックを提供します。ノード別の配置は DaemonSet、Cron 予約は CronJob の役割です。
Q9. データベースのように安定したネットワーク識別子と、順序のある永続ストレージが必要なワークロードに適したリソースはどれですか。
解説
StatefulSet は安定した Pod 名・順序・固有ボリュームを保証するため、データベースのようなステートフルアプリケーションに適しています。Deployment・ReplicaSet は Pod が相互に置き換え可能なステートレスワークロードを前提とします。
Q10. クラスターのすべての (または特定の) ノードごとに正確に 1 つの Pod レプリカを実行するには、どのリソースを使いますか。
解説
DaemonSet はノードごとに 1 つの Pod を立ち上げるため、ログ収集器・ノード監視エージェントのようなノード単位の作業に適しています。ReplicaSet はノードの分布ではなく、総レプリカ数だけを保証します。
Q11. 1 日に 1 回、決まった時刻にバッチ作業を自動実行するには、どのリソースを使いますか。
解説
CronJob は cron 式のスケジュールに合わせて Job を生成します。Job は一度実行されて完了する作業であり、繰り返しのスケジュール自体を管理するわけではありません。
Q12. ひとまとまりの Pod に安定した単一の仮想 IP と DNS 名を提供し、まとまりの内部へトラフィックを分散するリソースはどれですか。
解説
Service は selector でまとめられた Pod 集合に固定 ClusterIP と DNS 名を付与し、負荷を分散します。Ingress はクラスター外部の HTTP ルーティング層で、Service より一段上で動作します。
Q13. クラスター内部からのみアクセス可能なデフォルトの Service タイプは何ですか。
解説
ClusterIP はデフォルトのタイプで、クラスター内部の IP のみを公開します。NodePort は各ノードのポートを開き、LoadBalancer は外部ロードバランサーをプロビジョニングし、ExternalName は外部 DNS にマッピングします。
Q14. クラウド環境で外部ロードバランサーを自動的にプロビジョニングし、インターネットから Service にアクセスできるようにする Service タイプはどれですか。
解説
LoadBalancer タイプはクラウドプロバイダーのロードバランサーを生成して外部トラフィックを受けます。NodePort も外部アクセスを開きますが、ノード IP・ポートを直接使う必要があり、ClusterIP は内部専用です。
Q15. 複数のホスト・パスのルールで、外部の HTTP/HTTPS トラフィックを複数の Service へルーティングする L7 リソースはどれですか。
解説
Ingress はホスト・パスベースのルールで HTTP/HTTPS トラフィックを内部 Service へルーティングする L7 リソースであり、実際に動作させるには Ingress Controller が必要です。Service は L4 レベルでのまとまりの公開を担当します。
Q16. 設定値 (環境変数・設定ファイル) をコンテナイメージから分離し、平文で保存するリソースはどれですか。
解説
ConfigMap は非機密の設定データを平文で保存し、イメージから分離します。パスワード・トークンのような機密情報は base64 でエンコードされる Secret に置きます。
Q17. ConfigMap と Secret の最も重要な違いとして正しいものはどれですか。
解説
Secret はパスワード・トークン・キーのような機密情報のためのリソースで、base64 エンコードと RBAC・暗号化オプションのような追加保護を適用します。どちらも環境変数・ボリュームとして注入できるため A は誤りです。
Q18. 1 つの物理クラスターをチーム・プロジェクト単位で論理的に分離し、名前の衝突を防ぐリソースはどれですか。
解説
Namespace はクラスターを論理的に分割してリソース名の範囲を分け、クォータ・アクセス制御を適用します。Label・Annotation はリソースにメタデータを付けるキーバリューで、隔離の境界の役割は果たしません。
Q19. Kubernetes の動作モデルを最も正確に説明したものはどれですか。
解説
Kubernetes は宣言型 (declarative) モデルで、望ましい状態 (desired state) を宣言すると、コントローラーループが現在の状態 (current state) を絶えず比較・調整 (reconcile) します。手続き的にステップを直接実行する命令型モデルと対比されます。
Q20. Service がどの Pod 集合へトラフィックを送るかを選ぶとき、そして Deployment がどの Pod を管理するかを決めるときに共通して使うキーバリューのメタデータはどれですか。
解説
Label は Pod に付けるキーバリューのメタデータであり、selector はその Label で対象の Pod 集合を選ぶクエリです。Service・ReplicaSet・Deployment はいずれもこの組み合わせで対象をまとめます。Annotation は識別ではなく付加情報の保存用なので、selector の対象ではありません。
Q21. コンテナがトラフィックを受ける準備ができたかを判断し、準備できていなければ Service エンドポイントから除外するプローブはどれですか。
解説
readiness probe が失敗すると、該当する Pod は Service エンドポイントから外れてトラフィックを受けなくなります。liveness probe は失敗時にコンテナを再起動し、startup probe は起動の遅いアプリの初期起動を確認します。
Q22. liveness probe が繰り返し失敗したとき、kubelet が取る動作はどれですか。
解説
liveness probe が失敗すると、kubelet がコンテナを再起動してデッドロック・ハング状態を回復します。Service エンドポイントから外すのは readiness probe の動作です。
Q23. 宣言型で書いたマニフェストファイルをクラスターに適用し、望ましい状態にする標準の kubectl コマンドはどれですか。
解説
kubectl apply -f はマニフェストの宣言型の状態をクラスターに適用する標準コマンドです。run は命令型でリソースをその場で生成し、exec はコンテナの中でコマンドを実行し、describe はリソースの詳細を照会します。
Domain 2: Container Orchestration #
Q24. kubelet とコンテナランタイムの間の標準インターフェースで、どのランタイムを使っても同じように通信できるようにする規約はどれですか。
解説
CRI (Container Runtime Interface) は kubelet が containerd・CRI-O のようなランタイムと通信する標準インターフェースです。CNI はネットワーキング、CSI はストレージ、OCI はイメージ・ランタイムフォーマットの標準で、境界が異なります。
Q25. Pod に IP を割り当て、Pod 間のネットワーク接続を構成するプラグインの標準はどれですか。
解説
CNI (Container Network Interface) は Calico・Cilium・Flannel のようなプラグインが Pod のネットワーキングを構成する標準です。CRI はランタイム、CSI はストレージ、OCI はイメージフォーマットの標準です。
Q26. 外部ストレージシステムを Kubernetes に接続し、ボリュームをプロビジョニング・マウントする標準インターフェースはどれですか。
解説
CSI (Container Storage Interface) は外部ストレージプロバイダーが Kubernetes にボリュームを提供する標準です。CRI はランタイム、CNI はネットワーキングとの境界を分けます。
Q27. 次のうち、Kubernetes でよく使われる CRI 互換のコンテナランタイムはどれですか。(Choose TWO)
解説
containerd と CRI-O はいずれも CRI を実装するコンテナランタイムです。Calico は CNI プラグイン、etcd は状態ストア、Prometheus は監視ツールで、ランタイムではありません。
Q28. コンテナイメージフォーマットとランタイム動作の業界標準を定義し、イメージを複数のツール間で互換性を持たせる標準はどれですか。
解説
OCI はイメージフォーマットとランタイム仕様を標準化し、Docker・containerd・Podman などが同じイメージを扱えるようにします。CRI・CNI・CSI はそれぞれ Kubernetes 内部のランタイム・ネットワーキング・ストレージのインターフェースです。
Q29. 「誰がどのリソースにどの動作をできるか」を役割ベースで制御する Kubernetes の権限モデルはどれですか。
解説
RBAC (Role-Based Access Control) は Role・ClusterRole とバインディングで、ユーザー・サービスアカウントの権限を制御します。NetworkPolicy はトラフィック制御、SecurityContext はコンテナ実行権限の設定で、認証・認可モデルとは異なります。
Q30. Pod 間のネットワークトラフィックを許可・遮断するルールを定義するリソースはどれですか。
解説
NetworkPolicy はラベルセレクターベースで Pod のイングレス・エグレストラフィックを許可または遮断します。ただし NetworkPolicy を強制するには、それをサポートする CNI プラグインが必要です。Ingress は外部 HTTP ルーティングで役割が異なります。
Q31. コンテナを root 以外のユーザーで実行したり、権限昇格を防いだりするなど、コンテナ・Pod 単位のセキュリティ設定を指定するフィールドはどれですか。
解説
SecurityContext は runAsNonRoot、readOnlyRootFilesystem、capability 制限のようなコンテナ・Pod のセキュリティ設定を保持します。RBAC は API 権限、NetworkPolicy はネットワークトラフィックを扱います。
Q32. 管理者があらかじめ用意した実際のストレージ資源と、ユーザーが必要な容量・アクセスモードを要求するリソースの組み合わせとして正しいものはどれですか。
解説
PV は実際のストレージ資源であり、PVC はユーザーのストレージ要求です。PVC が条件に合う PV にバインドされて、Pod がボリュームを使います。残りの組み合わせは設定・ネットワーキング・権限で領域が異なります。
Q33. サービス間の通信を、アプリケーションコードを変更せずに mTLS 暗号化・トラフィック管理・観測で扱う層を何と呼びますか。
解説
Service Mesh (Istio・Linkerd など) はサイドカープロキシで、サービス間通信に mTLS・トラフィックルーティング・観測機能をコード変更なしで追加します。Ingress Controller は外部からの進入ルーティング、CNI は基本のネットワーキングを担当します。
Q34. Service Mesh で、各アプリケーション Pod の隣に一緒にデプロイされてトラフィックを横取りするプロキシを指すパターンの名前は何ですか。
解説
Service Mesh は sidecar パターンで各 Pod にプロキシ (例: Envoy) を付け、通信を横取りして管理します。init container は本コンテナの開始前に一度実行されて終了するコンテナで、役割が異なります。
Domain 3: Cloud Native Architecture #
Q35. CPU 使用率のような指標に応じて、ワークロードの Pod レプリカ数を自動的に増減するコンポーネントはどれですか。
解説
HPA は負荷に応じてレプリカ数 (横方向) を調整します。VPA は Pod の CPU・メモリ要求量 (縦方向) を調整し、Cluster Autoscaler はノード数を調整します。
Q36. 個々の Pod の CPU・メモリの要求と制限の値を、使用パターンに合わせて自動的に調整するコンポーネントはどれですか。
解説
VPA (Vertical Pod Autoscaler) は Pod のリソース要求・制限を縦方向に調整します。HPA はレプリカ数、Cluster Autoscaler はノード数を扱う点で区別されます。
Q37. スケジューリングするノードの容量が不足して Pending 状態の Pod が生じたとき、クラウドからノードを追加するコンポーネントはどれですか。
解説
Cluster Autoscaler は配置する場所がなくて Pending になった Pod が生じるとノードを追加し、ノードが空けば減らしてコストを削減します。HPA・VPA は Pod レベルのスケーリングを担当します。
Q38. リクエストが来たときだけ関数が実行され、アイドル時に 0 まで縮小してコストを減らすクラウドネイティブの実行モデルはどれですか。
解説
サーバーレス (FaaS, Function as a Service) はイベントベースで関数を実行し、アイドル時に 0 までスケールダウンします。Kubernetes の上では Knative が代表的なサーバーレスプラットフォームです。
Q39. Kubernetes の上でサーバーレスワークロードと 0 へのスケールダウンを提供する代表的な CNCF プロジェクトはどれですか。
解説
Knative は Kubernetes の上でサーバーレスのデプロイ・自動スケーリング (0 まで)・イベント処理を提供します。Prometheus は監視、ArgoCD は GitOps、Envoy はプロキシで領域が異なります。
Q40. CNCF プロジェクトの成熟度段階を、低いものから高い順に正しく並べたものはどれですか。
解説
CNCF の成熟度段階は Sandbox (初期) → Incubating (成長) → Graduated (成熟) の順です。Kubernetes・Prometheus・Envoy などが Graduated 段階に該当します。
Q41. 次のうち、クラウドネイティブアーキテクチャの中核的な性質とは見なしにくいものはどれですか。
解説
クラウドネイティブはマイクロサービス・自己修復・宣言型自動化を志向します。モノリシックを強制的にまとめるのはその反対方向なので、中核的な性質とは見なしにくいです。
Q42. 観測データ (メトリクス・ログ・トレース) の生成と収集の方式を標準化し、特定のベンダーに縛られないようにする CNCF のオープンスタンダードプロジェクトはどれですか。
解説
OpenTelemetry はテレメトリデータの収集・転送を標準化するベンダー中立のプロジェクトです。Prometheus はメトリクスの保存・クエリ、Jaeger はトレーシングバックエンド、Fluentd はログ収集器で、それぞれ特定の領域に集中します。
Domain 4: Cloud Native Observability #
Q43. オブザーバビリティの三本柱 (three pillars) として正しくまとめたものはどれですか。
解説
オブザーバビリティの三本柱はメトリクス・ログ・トレースです。SLI・SLO・SLA は信頼性の目標指標の体系であり、CPU・メモリはメトリクスの一例にすぎません。
Q44. 時系列メトリクスを収集・保存し、PromQL でクエリする、クラウドネイティブで最も広く使われる監視ツールはどれですか。
解説
Prometheus は時系列メトリクスを pull 方式で収集・保存し、PromQL でクエリします。Jaeger は分散トレーシング、Fluentd はログ収集、Grafana は可視化ダッシュボードで役割が分かれます。
Q45. 1 つのリクエストが複数のマイクロサービスを通過する全体の経路と、各区間の遅延を追ってボトルネックを見つける観測データはどれですか。
解説
分散トレースはリクエストがサービスを通過する経路と、各区間の所要時間をつないで見せます。メトリクスは集計された数値、ログは個々の事象の記録で、単一リクエストの端から端までの経路を追うわけではありません。
Q46. クラウドネイティブ環境でリソース使用量を可視化し、無駄を減らしてコストを管理する実践を何と呼びますか。
解説
FinOps はクラウドコストの可視化と最適化を扱う実践で、Kubecost のようなツールが使われます。GitOps は Git ベースのデプロイ、DevSecOps はセキュリティを統合した開発運用で、コスト管理とは焦点が異なります。
Domain 5: Cloud Native Application Delivery #
Q47. Git リポジトリを望ましい状態の単一のソースとし、クラスターの状態をそれに合わせて自動的に同期する運用方式はどれですか。
解説
GitOps は Git を desired state の単一のソース (source of truth) として置き、エージェントがクラスターをその状態へ継続的に同期します。変更は常に Git のコミット・PR を経るため、監査とロールバックが容易です。
Q48. 次のうち、GitOps を実装する代表的な CNCF ツールとして正しくまとめたものはどれですか。(Choose TWO)
解説
ArgoCD と Flux は Git の状態をクラスターに同期する代表的な GitOps ツールです。Helm はパッケージ管理、Prometheus は監視、Istio は Service Mesh で、GitOps の同期自体を担当するわけではありません。
Q49. GitOps で、運用者がクラスターに直接 kubectl で命令型の変更を加えず、Git の変更だけを経るようにする理由として最も適切なものはどれですか。
解説
GitOps の中核的な利点は、すべての変更が Git の一か所を経て履歴・レビュー・ロールバックが可能になる点にあります。クラスターを直接修正すると、Git の状態とずれる drift が生じて自動同期が壊れます。
Q50. コードの変更を自動的にビルド・テストし、続いてデプロイまで自動化するパイプラインを総称する用語はどれですか。
解説
CI/CD は継続的インテグレーション (Continuous Integration) と継続的デリバリー・デプロイ (Continuous Delivery/Deployment) をまとめた自動化パイプラインです。RBAC は権限、CRD はユーザー定義リソース、CRI はランタイムインターフェースで領域が異なります。
採点 #
総合スコア
正解 0 / 0
回答 0 / 0
| 点数帯 | 評価 | 次のステップ |
|---|---|---|
| 45+ (90% 以上) | 非常に安定。試験予約 | 試験受験 |
| 38〜44 (76〜88%) | 合格圏。弱いドメインをもう一周 | 弱点ドメイン #2〜#8 を再読 |
| 30〜37 (60〜74%) | 不足。弱いドメインに集中学習 | 2 つの弱点ドメイン + 別の模擬試験 |
| 29 以下 | もう一周必要 | シリーズ全体を再読 |
ドメイン別スコア分析 #
各ドメインの正解数を数えて弱点を見つけます。
| ドメイン | 問題数 | 推奨正解数 (75%) | 不足時の復習先 |
|---|---|---|---|
| Domain 1 (Q1〜Q23) | 23 | 17+ | #2 · #3 |
| Domain 2 (Q24〜Q34) | 11 | 8+ | #4 |
| Domain 3 (Q35〜Q42) | 8 | 6+ | #5 |
| Domain 4 (Q43〜Q46) | 4 | 3+ | #6 |
| Domain 5 (Q47〜Q50) | 4 | 3+ | #7 |
比重が 46% で最も大きい Domain 1 で点数を確保することが合格の鍵です。Domain 1 と Domain 2 を合わせると全体の 68% になるため、この 2 つが揺らぐと、残りの 3 ドメインをすべて正解しても合格点を超えるのは難しくなります。
合格点を超えた場合 #
- 38 問以上正解したなら合格圏です。試験予約 を進めてください (Linux Foundation 教育ポータル)
- 受験直前に #8 の試験のコツとよく間違えるパターンを最後にもう一度ざっと確認します
- 受験日は学習のモチベーションが維持される 1〜2 週間以内に設定します
- オンライン監督 (PSI) 環境の点検は、受験前日までに済ませておきます
合格点に届かなかった場合 #
- ドメイン別スコア を見て、最も不足しているドメインから再整理します
- 本シリーズの該当記事をもう一度読み、表・マッピング・落とし穴のセクションを中心に見ます
- CNCF が提供する 公式 KCNA 学習資料 で別の出題パターンも解いてみます
- 1 週間ほど後に本模試をもう一度解いて進捗を確認します
シリーズの締め #
KCNA シリーズ 9 編がすべて終わりました。このシリーズで作ったものを整理します。
- #1 — 試験構成と学習戦略
- #2 — Domain 1 アーキテクチャと中核リソース
- #3 — Domain 1 API・コンテナ・スケジューリング
- #4 — Domain 2 ランタイム・セキュリティ・ネットワーキング・ストレージ・Service Mesh
- #5 — Domain 3 オートスケーリング・サーバーレス・コミュニティ・オープンスタンダード
- #6 — Domain 4 テレメトリ・Prometheus・コスト管理
- #7 — Domain 5 GitOps・CI/CD
- #8 — 試験のコツとよく間違えるパターン
- #9 — 50 問模擬試験 ← この記事
K8s 実務トラック 26 編 が minikube と kubectl の上の感覚だとすれば、本シリーズはその感覚を選択式の試験問題に変換する語彙を上に乗せる作業でした。KCNA 合格後の次のステップは、ターミナルから直接クラスターを扱う CKAD (アプリ開発者)・CKA (クラスター管理者) の実技資格であり、それぞれ独立したシリーズとして整理する予定です。
試験合格をお祈りします。