資格道場
The Linux Foundation（CNCF）Level 1

難易度は Level 1（やさしめ）〜Level 5（難関） の5段階です。

KCNA-JPのサンプル問題（本番形式・解説付き）

KCNA-JP（The Linux Foundation（CNCF）・Kubernetes and Cloud Native Associate（KCNA-JP））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試 第1回（60問）の冒頭から抜粋したオリジナル問題です。当サイトは全368問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

設計書に CPU の要求量を 500m と書いた理由を、レビューで問われている。正しいものはどれか。

  • 500m は 500 コアを意味し、大規模な並列処理の割り当てにあたる
  • 500m は 0.5 コアを意味し、単位の 1 が1コア（1 vCPU）に相当する（正解）
  • 500m は 500 ミリ秒あたりの実行時間の上限を意味する指定にあたる
  • 500m は 500 メビバイトのメモリを意味し、CPU とは別の指定にあたる

解説

CPU の単位は「1」が1コア（1 vCPU）相当で、500m は 0.5 コアを意味します。CPU の値は実行時間の上限を表す指定ではありません。メビバイトはメモリの単位で、Mi と表記され CPU の単位とは別です。

設問2

Pod が Pending のまま止まり、Events には何も表示されていない。考えられる原因として最も適切なものはどれか。

  • kube-scheduler 自体が動いていない可能性がある（正解）
  • kube-proxy 自体が動いていない可能性がある
  • CoreDNS 自体が動いていない可能性がある
  • Metrics Server の Pod 自体が動いていない可能性がある

解説

Events に何も出ていないのに Pending が続く場合は、kube-scheduler 自体が動いていない可能性があります。またコントロールプレーンの表でも、Pod が Pending のまま増える症状に対して kube-scheduler の停止を疑うとしています。kube-proxy は転送ルール、CoreDNS は名前解決、Metrics Server は使用量の取得に関わるもので、配置が始まらない原因ではありません。

設問3

すべてのコンテナで requests と limits を指定し、両者を同じ値にした Pod がある。正しい QoS クラスはどれか。

  • requests は指定されているが limits と一致しない場合にあたる Burstable
  • requests も limits も一切指定していない場合にあたる BestEffort
  • 優先度の値によって決まるクラスにあたる system-cluster-critical
  • すべてのコンテナで requests と limits が等しい場合にあたる Guaranteed（正解）

解説

Guaranteed は、すべてのコンテナで requests と limits が指定され、かつ両者が等しい場合の QoS クラスで、最も退去されにくいクラスです。Burstable は requests は指定されているが limits と一致しない、または一部だけ指定した場合です。BestEffort は requests も limits も一切指定されていない場合で、最初に退去されます。system-cluster-critical は組み込みの PriorityClass の名前で、QoS クラスではありません。

設問4

航空会社の予約基盤のチームが、分散トレースの用語を整理している。Span の説明として正しいものはどれか。

  • 1つのリクエストの全体像で、複数の作業単位から構成される
  • trace ID と span ID をサービス間で受け渡していく仕組みである
  • 量が多すぎるため一部だけを保存するようにする仕組みである
  • トレース内の1つの作業単位で、開始時刻や属性や親子関係を持つ（正解）

解説

Span はトレース内の1つの作業単位で、開始時刻、終了時刻、属性、親子関係を持ちます。1つのリクエストの全体像で複数の span から構成されるのは Trace です。trace ID と span ID をサービス間で受け渡すのは Context propagation で、HTTP ヘッダを使います。一部だけ保存するのは Sampling です。

設問5

気象データ配信のチームが、要求が無いときに資源を消費しない実行モデルを検討している。serverless の説明として最も適切なものはどれか。

  • 要求の有無によらず一定の資源を確保し、待機し続けて即応する
  • 要求が無いときは資源を消費せず、来た分だけ自動的に拡張する（正解）
  • 要求の傾向を事前に見積もり、時間帯ごとに台数を固定しておく
  • 要求をキューへ蓄積し、夜間にまとめて処理して資源を平準化する

解説

serverless はサーバの存在を意識せずにコードを動かすモデルで、要求が無いときは資源を消費せず（scale to zero）、要求が来た分だけ自動的に拡張します。一定の資源を確保して待機し続ける形は、資源をゼロにできる点と反します。時間帯ごとの台数固定や夜間のまとめ処理も、サーバレスの性質ではありません。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く
← KCNA-JP の資格ページへ