KCNA サンプル問題

正解：A

A（正解）　正解。ノード上でコンテナランタイムを制御し、restartPolicyに従って再起動する

B　未配置Podの配置先を決める。既に割り当てられたPod内の再起動は担当しない

C　レプリカ不足を補うなどの調整を行う。同じPod内の再起動はkubeletの役割

D　APIの受付と状態保存を仲介する。ノード上の再起動を実行する役割ではない

正解：B

A　イメージを保管する。DeploymentやSecretのAPI状態の保管先ではない

B（正解）　正解。KubernetesのAPIオブジェクトの状態を保存するキー・バリュー型データストア

C　Service名などの名前解決を行う。APIオブジェクトの永続化先ではない

D　Podの配置を判断する。クラスター状態を保存するデータストアではない

正解：C

A　Serviceの通信経路を構成する。CPU要求による配置判断は行わない

B　必要なPod数を維持する。作成したPodのノード選定はschedulerに委ねる

C（正解）　正解。未配置Podの要求量や配置条件を評価してノードを選ぶ

D　選ばれたノードでPodを実行する。複数ノードから配置先を選ぶ役割ではない

正解：D

A　削除・作成要求を受け付ける。レプリカ数を比較する調整ループとは別

B　新しく作成されたPodを配置する。不足Podの作成はReplicaSetコントローラーが担う

C　クラウドのノードやロードバランサーとの統合を担う。ReplicaSetの数調整とは別

D（正解）　正解。ReplicaSetコントローラーなどを実行し、宣言数と実際の数の差を埋める

正解：A

A（正解）　正解。APIリクエストを受け、認証・認可を通してリソースへのアクセスを判断する

B　ノード上でPodを管理する。kubectlによるAPIの一覧要求の入口ではない

C　名前解決を担う。ユーザーのAPI操作権限は判定しない

D　Service通信の転送を扱う。Kubernetes APIの認可はapiserverが担う

正解：B

A　ServiceのDNS名を解決する。クラウドAPIでロードバランサーを作る役割ではない

B（正解）　正解。クラウドプロバイダーのAPIと連携するService・Nodeなどのコントローラーを実行する

C　Podの配置先を選ぶ。クラウドのロードバランサー作成の担当ではない

D　Serviceオブジェクトを受け付ける。クラウド固有の作成処理は別コントローラーが担う

正解：C

A　Pod配置を決めるコントロールプレーン側のコンポーネント

B　APIを公開するコントロールプレーン側のコンポーネント

C（正解）　正解。各ノードのService転送ルールを管理するノードコンポーネント

D　APIオブジェクトの状態を保持するコントロールプレーン側のデータストア

正解：D

A　コンテナ実行やProbeを管理する。Service仮想IPの転送ルールの担当ではない

B　Pod配置を判断する。Service通信経路の同期は行わない

C　Service名をIPへ解決する。既知の仮想IPへの転送ルールは管理しない

D（正解）　正解。Serviceとエンドポイント情報からノード上の通信ルールを構成する

正解：A

A（正解）　正解。認証・認可や検証、アドミッション処理を通してオブジェクトを受け付ける

B　検証後の状態を保存する。kubectlの要求を直接受けてDeploymentの検証を行う入口ではない

C　作成済みの未配置Podを扱う。DeploymentマニフェストのAPI検証は担当しない

D　Serviceの転送ルールを更新する。Deploymentのフィールド検証は行わない

正解：B

A　Service通信のルールを維持する。ランタイムへのコンテナ起動指示は行わない

B（正解）　正解。割り当てられたPodの仕様に従ってランタイムを制御し、状態を報告する

C　クラスター全体の調整を行う。各ノードのProbe実行主体ではない

D　Podの割り当てを決める。割り当て後のコンテナ起動を実行しない

正解：C

A　対象ノードごとにPodを配置する。任意の3レプリカを維持する目的とは異なる

B　処理の完了を管理する。継続稼働するAPIのローリング更新には適さない

C（正解）　正解。交換可能なレプリカの数とPodテンプレートの段階的更新を管理する

D　安定したIDや専用ストレージが必要な用途向け。今回の条件ではDeploymentが標準的

正解：D

A　Podは交換可能なレプリカとして管理され、番号付きの安定IDや各レプリカのPVC管理を提供しない

B　ノード単位の配置を管理する。データベースメンバーごとの番号付きID管理とは異なる

C　レプリカ数を維持する。安定した番号やレプリカ別PVCの管理はStatefulSetの機能

D（正解）　正解。レプリカごとの安定したIDとvolumeClaimTemplatesによるPVCを管理できる

正解：A

A（正解）　正解。適格な各ノードにPodを配置し、ノード追加にも追従する

B　指定した総レプリカ数を管理する。対象ノードごとに1つという配置を保証しない

C　レプリカごとの安定したIDを管理する。ノード追加に応じたエージェント配置とは別

D　時刻に応じてJobを起動する。ノードごとの常駐エージェント管理には使わない

正解：B

A　周期的にJobを生成する。今回の単発処理に時刻スケジュールは不要

B（正解）　正解。成功した実行の完了数を管理し、必要に応じて失敗を再試行する

C　継続稼働するレプリカを維持する。成功して終了する処理の完了管理とは異なる

D　ノードごとのPodを維持する。単発の移行成功を完了として管理する用途ではない

正解：C

A　常駐するレプリカを維持する。時間に基づくJob生成を行わない

B　対象ノードごとのPodを維持する。時間に基づくJob生成を行わない

C（正解）　正解。cron形式のスケジュールに従ってJobを生成し、各実行はJobが管理する

D　1回の実行の成功数を管理する。日次スケジュールを持つ親はCronJob

正解：C

A　等値条件として有効だが、キーがappではなくtierなので同じ条件にならない

B　web以外の値やそのキーがないPodを選ぶ不等値条件で、要求と逆

C（正解）　正解。YAMLではapp: webというマッピング、CLIの等値セレクターではapp=webと表す

D　等値条件として有効だが、値がwebではなくapiなので一致しない

正解：C

A　Namespace指定はmetadata.namespace。containersはPod内のコンテナ定義

B　コンテナ名はcontainers内のname。トップレベルmetadata.nameはPod名

C（正解）　正解。metadataはオブジェクトの識別情報、specは望ましい構成を定義する

D　Pod名はweb、イメージはimageの値。containersはノード一覧ではない

正解：B

A　既存のノードラベルを評価する指定で、ストレージを作成する操作ではない

B（正解）　正解。nodeSelectorはノードラベルとの一致条件。Pod自身のラベルではなくノードのラベルを評価する

C　hddは指定値ssdと一致しないため候補にならない

D　Podラベルの付与はmetadata.labels。nodeSelectorは配置先の条件を表す

正解：A

A（正解）　正解。-cでコンテナを選び、--以降のコマンドをコンテナ内で新規実行する

B　既存プロセスの入出力へ接続する。新しいshを起動する操作ではない

C　新しいshは起動できるが、対象がproxyであり、調べたいappではない

D　appの標準出力ログを追う。コンテナ内にシェルを起動しない

正解：A

A（正解）　正解。Deploymentの保存済み履歴を使って直前のPodテンプレートへ戻す

B　現在のテンプレートでPodを作り直す。過去のイメージや設定には戻さない

C　更新の進行状況を監視する。リビジョンを変更しない

D　レプリカ数を変更する。過去のPodテンプレートへ戻す操作ではない

正解：D

A　主に状態の要約を表示する。詳細なイベント確認にはdescribeを使う

B　前回終了したコンテナのログを見る。未起動Podのスケジューリングイベントは表示しない

C　使用量を取得する。未起動Podの配置失敗理由を表示するコマンドではない

D（正解）　正解。Podの詳細とEventsを表示し、配置不可の理由などを確認できる

正解：C

A　状態やアドレスなどの一覧を広げる。現在のCPU・メモリ使用量は表示しない

B　全NamespaceのPod使用量を表示する。ノード単位の使用量一覧とは対象が異なる

C（正解）　正解。Metrics APIからノードの現在のCPU・メモリ使用量を表示する

D　容量や要求量、イベントを確認できるが、現在の実測使用量一覧を取得するコマンドではない

正解：C

A　自発的中断で同時に利用不能となるPod数を制限する。負荷に応じてPodを増減させる機能ではない

B　VPAはPodのリソース要求を推奨・調整する。レプリカ数を増やして負荷を分散する仕組みではない

C（正解）　正解。HPAは対象ワークロードのレプリカ数をメトリクスに基づいて調整する。CPU使用率はrequestsを基準に計算する

D　ノードグループの容量を調整する。DeploymentのCPU使用率を直接の目標としてレプリカ数を制御するものではない

正解：A

A（正解）　正解。VPAはCPUやメモリの使用実績からrequestsを推奨する。推奨だけを利用する運用もでき、Pod数の変更とは別の調整となる

B　スケジュールできないPodや余剰容量を踏まえてノード数を調整する。Pod単体のrequestsを推奨しない

C　HPAの調整対象はレプリカ数である。各Podのrequestsの推奨値を算出する目的にはVPAを用いる

D　既存のrequestsなどを使ってPodの配置先を決める。実測からrequestsの推奨値を生成する機能ではない

正解：A

A（正解）　正解。配置できないPodの要求とノードグループの構成を評価してノードを増やす。任意のPending理由を解消するわけではない

B　クラウド固有のノード情報やロードバランサーを連携する。容量不足を判断してノード数を増減する役割とは異なる

C　Podのレプリカ数は変更できるが、要求CPUを収容するノード自体を作成する機能ではない

D　対象ノードにPodを配置するコントローラーである。ノードグループの容量を増やす機能ではない

正解：A

A（正解）　正解。NoScheduleは新規のスケジューリングを防ぐ。既存Podの退去はNoExecuteと区別し、tolerationがあっても配置を保証しない

B　NoScheduleに一致するtolerationがないPodはこのtaintを許容できない。ラベルを追加するだけの操作とは異なる

C　NoScheduleは既存Podを退去させず、許容しない新規Podの配置を防ぐ。既存と新規の扱いが逆になっている

D　既存Podも退去の対象にする効果はNoExecuteである。NoScheduleを付けるだけでは既存Podを追い出さない

正解：B

A　PodSecurityPolicyのAPI自体が削除されている。Namespaceを変更しても利用できず、代替の制御を設計する必要がある

B（正解）　正解。PodSecurityPolicyはv1.25で削除された。Pod Security Admissionなどへ要件を対応付けて移行する必要がある

C　PodSecurityPolicyはPodのセキュリティ設定を制約する旧APIである。NetworkPolicyはネットワーク通信の許可を扱う

D　RBACはAPI操作の権限を制御する。Podの特権設定を制限する要件を同名のRoleだけで満たすことはできない

正解：A

A（正解）　正解。runAsNonRootはPodまたはコンテナのsecurityContext、readOnlyRootFilesystemはコンテナのsecurityContextで指定できる

B　Podがトラフィックを受けられるかを検査する。root実行やルートファイルシステムへの書き込みを制限する設定ではない

C　CPU・メモリなどのrequestsとlimitsを指定する。実行ユーザーやファイルシステム権限の制御とは異なる

D　APIアクセス時に利用するServiceAccountを選ぶフィールドである。Linuxユーザーやファイルシステムの書き込み可否は指定しない

正解：D

A　Pod間などのネットワーク通信を制限する。APIのlistやdeleteを操作別に認可する仕組みではない

B　Podのセキュリティ標準をAdmission時に検査する。ServiceAccountにAPIの一覧取得権限を付与する仕組みではない

C　Podとノードのスケジューリング制約を扱う。APIリソースへの操作権限はRoleなどで定義する

D（正解）　正解。Roleのresourcesとverbsで許可する操作を定義し、RoleBindingでServiceAccountへ割り当てる

正解：C

A　設定されたルールに従い通信を処理するプロキシである。プロキシ単体と、それを管理するサービスメッシュ全体を区別する

B　Serviceなどの名前解決を提供するDNSサーバーである。サービス間のHTTPルーティングやmTLSをまとめて管理しない

C（正解）　正解。サービスメッシュとして通信ポリシーやルーティングを管理する。サイドカーモードではEnvoyがデータプレーンを担う

D　Podネットワークやネットワークポリシーを実装する。ここで求めるHTTP通信を管理するサービスメッシュとは役割が異なる

正解：B

A　Podの配置先を選ぶ。配置後のサービス間通信を中継するデータプレーンではない

B（正解）　正解。Envoyプロキシがデータプレーンとして通信を処理する。Istiodなどの制御プレーンは設定や証明書を管理する

C　DNSによる名前解決を担う。HTTPリクエストをメッシュの設定に従って中継するプロキシではない

D　サービス検出や設定配布などの制御プレーンを担う。各Podのデータ通信をサイドカーとして中継する役割ではない

正解：C

A　ボリュームの作成や接続を扱う。コンテナへのネットワーク接続はCNI対応プラグインの担当となる

B　Service名などの名前解決を提供する。Podのネットワーク接続を作成してIPを割り当てる役割ではない

C（正解）　正解。ネットワークプラグインがPodのネットワーク接続を用意し、IPAMなどと連携してIPを割り当てる。実装方式はプラグインにより異なる

D　主に外部からのHTTP(S)ルーティングを実装する。PodネットワークそのものやPodのIP割り当ては担わない

正解：A

A（正解）　正解。KubernetesのService情報を利用してクラスター内DNSを提供する。IP接続とDNS解決を分けて調査できる

B　Serviceの仮想IPへ届いた通信の転送を実装する。DNS名をIPへ解決するサーバーではない

C　Podの配置先ノードを選択する。配置後のDNS問い合わせに回答する役割は持たない

D　クラスターの状態を保存する。PodからのDNS問い合わせを受け付けてService名を解決しない

正解：B

A　オブジェクトを論理的に分けるスコープである。同じNamespaceでもPodは異なるノードへ配置できる

B（正解）　正解。Podが1つ以上のコンテナをまとめる最小のデプロイ単位となる。同一Podのコンテナは一緒に配置される

C　コンテナはPod内で実行される。Kubernetesのschedulerがそれぞれ独立に別ノードへ配置する単位ではない

D　希望する数のPodを維持するコントローラーである。コンテナの共有ネットワークを定義する最小単位ではない

正解：A

A（正解）　正解。同一Podではlocalhostで通信でき、同じボリュームを各コンテナにマウントできる。密結合な補助処理を同居させる設計に向く

B　Podはコンテナ群をまとめて複製する。同じPodに入れると、補助コンテナだけ別のレプリカ数へ変更することはできない

C　同一Podでもコンテナは個別の実行環境を持つ。目的は必要なネットワークとボリュームを共有し、連携を容易にすることにある

D　コンテナごとのルートファイルシステムは別である。ファイルの共有には同じボリュームをそれぞれへマウントする

正解：D

A　旧版と新版を並行稼働させて通信先を切り替える更新方式である。ログ転送コンテナの同居を指す用語ではない

B　各対象ノードにPodを配置する方式である。今回の要件はノードごとではなくアプリと同じPodでの補助処理となる

C　通常のInit Containerはアプリ起動前に実行を完了する。実行中のアプリのログを継続転送する用途には常駐する補助処理を使う

D（正解）　正解。アプリと並走する補助コンテナを同じPodに配置する。起動前に完了する準備処理とは用途が異なる

正解：A

A（正解）　正解。実環境とバージョン管理された望ましい状態を比較し、調整ループが差分を解消する

B　操作の再生ではなく、現在の状態と望ましい状態の差分を扱う

C　変更時の一度きりの適用では、その後の直接編集によるドリフトを検知できない

D　テスト結果は構成の信頼できる情報源を置き換えるものではない

正解：B

A　サービス間通信の制御が中心で、Gitに置いたアプリ構成の同期は担わない

B（正解）　正解。Kubernetesの宣言的な構成を監視し、Gitと実環境の差分の表示や同期を行う

C　ビルドなどを自動化するCI基盤で、記述された構成監視はArgo CDの役割に合う

D　Kubernetesクラスターの初期構築を行うツールで、アプリ構成のGit同期は担わない

正解：C

A　クラスター構築を支援するもので、アプリのチャートを管理するツールではない

B　コンテナランタイムで、チャートの導入やリリース履歴を管理しない

C（正解）　正解。チャートにテンプレートや値、依存関係をまとめ、リリース単位で導入と更新を管理する

D　既存マニフェストをパッチで合成する仕組みで、チャートのリリース管理は行わない

正解：D

A　versionはチャートのバージョンであり、Podのレプリカ数として参照されない

B　statusは観測された状態であり、Helmテンプレートの入力値や望ましいレプリカ数ではない

C　依存チャートの数はこのDeploymentのreplicaCountを変更しない

D（正解）　正解。helm upgrade等の -f で値ファイルを渡すと、テンプレートへ注入する既定値を上書きできる

正解：A

A（正解）　正解。ベースのリソースに環境ごとのパッチを重ね、kubectlの -k で適用できる

B　Helmはテンプレートを値で展開する方式で、kubectl apply -k の対象ではない

C　段階公開を制御する仕組みで、ベースの環境別パッチを合成する方式ではない

D　クラスター状態のバックアップ方式で、アプリの環境差分を管理する方式ではない

正解：B

A　旧Podを削除してから新版を作成するため、旧版と新版を残して公開比率を増やす方式ではない

B（正解）　正解。少量の本番トラフィックで新版を検証し、リスクを限定しながら公開範囲を広げる

C　一般に並行する環境間でトラフィックを切り替える方式で、設問の段階的な比率制御はカナリアに当たる

D　Podを順次置き換えるが、指定したリクエスト比率の分析と段階昇格は標準Deploymentだけでは行わない

正解：D

A　historyは過去のリビジョンを表示するので、現在の展開完了を待たない

B　コンテナログを表示するコマンドで、tailは表示行数。展開を120秒待つ指定ではない

C　その時点のオブジェクトを表示するだけで、展開完了を待機して終了結果を判定するコマンドではない

D（正解）　正解。rollout statusは展開を追跡し、完了時は成功終了する。timeoutで待機時間を限定できる

正解：D

A　最低3個となるのはmaxUnavailableが1の場合で、設問では0

B　maxSurgeは1なので、新Podを先に1個作成できる

C　replicasは望ましい総数であり、maxSurgeとmaxUnavailableの意味を入れ替えている

D（正解）　正解。maxUnavailableが0なので4個の可用性を維持し、maxSurgeが1なのでdesiredを1個まで超えて作成できる

正解：C

A　失敗率の継続的な集計にはメトリクス、個別エラーの内容にはログが合い、順序が逆

B　最初は合うが、特定エラーの内容をログ、下流の処理区間をトレースとして扱う順序が逆

C（正解）　正解。集計された時系列はメトリクス、個別イベントの詳細はログ、サービスをまたぐ処理経路はトレースが適する

D　ログだけでも集計は可能だが、設問の代表的な役割分担では個別エラーはログで、下流の処理区間はトレース

正解：D

A　データソースをクエリして可視化するが、設問のPrometheus形式の収集と時系列保存を担うバックエンドではない

B　ログの収集と転送に使うもので、PromQLを提供する時系列バックエンドではない

C　テレメトリーの受信・処理・転送を担い、PromQL付きの長期時系列保存基盤ではない

D（正解）　正解。メトリクスを収集・保存し、PromQLで時系列を計算する機能を提供する

正解：A

A（正解）　正解。複数のデータソースへ接続し、メトリクスやログをダッシュボードで可視化できる

B　アラートの集約と通知を担い、メトリクスとログのダッシュボード作成が主目的ではない

C　ログ転送を担うので、すでに保存されたメトリクスとのダッシュボード表示を担わない

D　CPUやメモリのリソースメトリクスを提供するが、複数データソースの可視化ツールではない

正解：B

A　イメージ容量は配布サイズであり、処理中の下流サービスの待ち時間を直接示さない

B（正解）　正解。分散トレースは関連する処理区間をつなぎ、サービスごとの所要時間や依存関係を調べられる

C　CPU平均は利用傾向を示すが、その注文が下流のどの処理で待ったかまでは示さない

D　Pod総数はリクエストの経路と各処理区間の時間を表さない

正解：C

A　アプリのメトリクスはetcdを経由せず、公開エンドポイントから収集する

B　この設定はPrometheusの取得間隔であり、kubeletの永続保存処理を指定しない

C（正解）　正解。通常のスクレイプはPrometheus側がHTTPエンドポイントへアクセスするプル方式

D　scrape_intervalはPrometheus側の取得間隔で、アプリの送信スケジュールではない

正解：D

A　表示の整理はできるが、アラート通知の重複排除と依存関係に基づく抑制の中心はAlertmanager

B　リソース使用量の提供基盤で、Prometheusアラートの通知集約を担当しない

C　Pod構成の変更はアラート通知のグループ化や抑制ルールの代わりにならない

D（正解）　正解。アラートをグループ化し、重複排除やinhibitionによって派生通知を抑制できる