資格道場
記事法人
LPI-JapanLevel 4

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

LinuC レベル3 3PS試験のサンプル問題(本番形式・解説付き)

LinuC レベル3 3PS試験(LPI-Japan・LinuC-3PS(プラットフォームスペシャリスト))の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試 第1回(60問)の冒頭から抜粋したオリジナル問題です。当サイトは全420問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

containerd では、起動したコンテナごとに shim と呼ばれるプロセスを介在させる構成を取る。この設計によって得られる運用上の利点として、最も適切なものはどれか。

  • 低レベルランタイムの実装差が shim に吸収され、同一ホスト上のコンテナが同じカーネル機能だけで動くようになる。
  • コンテナのプロセスが containerd の子プロセスとして束ねられ、ホスト全体の資源配分を一か所で制御できる。
  • containerd を停止して更新しても、稼働中のコンテナは shim に引き取られたまま動き続ける。(正解)
  • 低レベルランタイムの処理が shim の中で完結し、コンテナを起動するたびに別のプロセスを生成せずに済む。

解説

shim は containerd 本体とコンテナのプロセスの間にコンテナ単位で常駐し、containerd から独立して動く。そのため containerd デーモンを停止・更新しても稼働中のコンテナは落ちず、containerd は再起動後に既存の shim へ接続し直せる。shim を「低レベルランタイムの代わり」と捉えるのは取り違えで、実行そのものは shim が起動する低レベルランタイムが行う。

他の選択肢が誤りである理由

  • 低レベルランタイムの実装差が shim に吸収され、同一ホスト上のコンテナが同じカーネル機能だけで動くようになる。shim は低レベルランタイムを呼び出す仲立ちであり、実装差を吸収して機能を共通化する層ではない。どのカーネル機能が使われるかは選んだ低レベルランタイムの方式によって変わる。
  • コンテナのプロセスが containerd の子プロセスとして束ねられ、ホスト全体の資源配分を一か所で制御できる。この構成の狙いはむしろ逆で、コンテナのプロセスを containerd の直接の子として束ねないところにある。資源配分の制御はホスト側の仕組みで行うものであり、shim を挟む理由ではない。
  • 低レベルランタイムの処理が shim の中で完結し、コンテナを起動するたびに別のプロセスを生成せずに済む。shim は低レベルランタイムを別プロセスとして呼び出す形を取るため、起動処理そのものが shim 内で完結するわけではない。プロセス生成を省く仕組みではなく、コンテナの寿命を containerd から切り離す仕組みである。

設問2

高レベルランタイムと低レベルランタイムを組み合わせた基盤で、コンテナの起動要求がレジストリからのイメージ取得の段階で失敗している。階層構造を踏まえた切り分けの進め方として、最も適切なものはどれか。

  • 低レベルランタイムのバイナリを別の実装へ差し替え、同じ要求が通るかどうかで原因の所在を判断する。
  • 隔離環境の生成でつまずいている可能性が高いため、低レベルランタイムへ渡される設定ファイルの中身から確認を始める。
  • 両者が同じ処理を並行して行う構成であるため、双方のログを突き合わせて先に失敗した側を特定する。
  • イメージの取得と展開は高レベルランタイム側の責務であるため、その設定と資格情報、ストレージ領域の空き状況を先に確認する。(正解)

解説

レジストリとの通信、イメージの取得、レイヤーの展開はいずれも高レベルランタイムの担当範囲であり、低レベルランタイムはバンドルが揃ってから初めて呼び出される。したがってこの段階の失敗は低レベルランタイムの選択や実装とは切り離して考えてよい。逆に、イメージは取得できているのに起動時に落ちる場合は低レベルランタイム側を疑う、というのが層による切り分けの基本になる。

他の選択肢が誤りである理由

  • 低レベルランタイムのバイナリを別の実装へ差し替え、同じ要求が通るかどうかで原因の所在を判断する。低レベルランタイムはイメージの取得に関与しないため、実装を差し替えても結果は変わらず、原因の所在を判断する手がかりにならない。
  • 隔離環境の生成でつまずいている可能性が高いため、低レベルランタイムへ渡される設定ファイルの中身から確認を始める。隔離環境の生成は低レベルランタイムが呼び出されたあとの工程であり、イメージの取得段階で止まっている状況ではまだそこまで到達していない。
  • 両者が同じ処理を並行して行う構成であるため、双方のログを突き合わせて先に失敗した側を特定する。高レベルランタイムと低レベルランタイムは並行して同じ処理を行うのではなく、前者が準備を終えてから後者を呼び出す直列の関係にある。

設問3

検証用の仮想マシンを1つのテンプレートから多数複製する基盤で、割り当て容量ぶんの領域を最初に確保せず実使用量だけを消費し、かつイメージ自身の中にスナップショットを保持できる仮想ディスクイメージ形式を選びたい。この形式の名称を入力せよ。

入力形式(コマンドを打ち込んで答える問題です)

QCOW2(正解)

別解: qcow2 / Qcow2 / QCow2

解説

QCOW2 は参照テーブルを介して実際に書き込まれたブロックだけを保持するため、薄く始めて必要な分だけ育てる運用と、イメージ内部でのスナップショット保持ができる。同じディスクを載せる RAW は構造を持たないぶん機能が無い代わりに変換層が挟まらず、機能で選ぶか I/O 経路の短さで選ぶかが判断の分かれ目になる。

設問4

低レベルランタイムが OCI のランタイム仕様に準拠していることが、コンテナ基盤の設計にもたらす効果として、最も適切なものはどれか。

  • 実行系を仕様に沿った別の実装へ入れ替えても、上位層からの呼び出し方を変えずに済む。(正解)
  • 高レベルランタイムを入れ替えても、既存のイメージのレイヤー構造をそのまま引き継いで再利用できる。
  • 準拠した実装同士では隔離の強度が揃うため、実行系の選択を性能の比較だけで決められる。
  • 仕様が実行時のリソース上限まで定めるため、ホスト側で個別に上限を設ける必要がなくなる。

解説

OCI のランタイム仕様は「与えられたバンドルを受け取ってコンテナを起動・停止する」という呼び出しの形を定めるものなので、runc・crun・gVisor・kata-container のように内部方式がまったく異なる実装であっても、上位層からは同じ手順で扱える。ここで揃うのは呼び出し方であって隔離の強度ではない点が要で、実装ごとの隔離方式の違いは仕様に準拠していても残る。

他の選択肢が誤りである理由

  • 高レベルランタイムを入れ替えても、既存のイメージのレイヤー構造をそのまま引き継いで再利用できる。イメージの形式について定めるのはランタイム仕様ではなく別の仕様であり、低レベルランタイムの準拠によって得られる効果としては論点がずれている。
  • 準拠した実装同士では隔離の強度が揃うため、実行系の選択を性能の比較だけで決められる。仕様が定めるのは呼び出しの形であり、ホストカーネルを共有する実装と別カーネルを挟む実装では隔離の強度が大きく異なるため、性能だけで選ぶ判断にはならない。
  • 仕様が実行時のリソース上限まで定めるため、ホスト側で個別に上限を設ける必要がなくなる。リソース上限の値そのものは仕様ではなくバンドルの設定として与えるものであり、準拠していれば上限管理が不要になるわけではない。

設問5

低レベルランタイムのうち gVisor が隔離を強める仕組みとして、最も適切なものはどれか。

  • コンテナごとに専用のゲストカーネルを持つ軽量な仮想マシンを起動し、その内部でプロセスを動かす。
  • アプリケーションが発行するシステムコールをユーザー空間の実行系が受け取り、そこで処理する。(正解)
  • ホストカーネルの機能をそのまま用いつつ、強制アクセス制御の適用範囲を広げて呼び出しを絞り込む。
  • イメージのレイヤーごとに署名を検証し、改ざんされた層を含むコンテナの起動を拒む。

解説

gVisor はユーザー空間で動作するアプリケーションカーネルがコンテナからのシステムコールを受け取って処理し、ホストカーネルへそのまま渡さないことで攻撃面を狭める。ゲストカーネルを持つ仮想マシンで隔てる kata-container とは方式が異なり、実装されていないシステムコールや疑似ファイルがあると動かない、という互換性の制約が対価になる。

他の選択肢が誤りである理由

  • コンテナごとに専用のゲストカーネルを持つ軽量な仮想マシンを起動し、その内部でプロセスを動かす。これは kata-container の方式にあたる説明であり、gVisor はハードウェア仮想化による仮想マシンを立てずにユーザー空間で隔離を作る。
  • ホストカーネルの機能をそのまま用いつつ、強制アクセス制御の適用範囲を広げて呼び出しを絞り込む。gVisor の要点はホストカーネルへ渡るシステムコールを減らすところにあり、ホストカーネルの機能をそのまま用いる前提の仕組みではない。
  • イメージのレイヤーごとに署名を検証し、改ざんされた層を含むコンテナの起動を拒む。イメージの署名検証はコンテナの供給元を確かめる仕組みであり、実行時の隔離を強めるものではない。

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

登録なしで50問解く