Kubernetes環境でFalcoの主な役割は何ですか？

A) コンテナイメージの脆弱性をスキャンする B) ランタイムでシステムコールを監視して異常な活動を検知しアラートする C) ネットワークポリシーを自動生成する D) Podのリソース使用量を制限する

正解: B

FalcoはLinuxカーネルのシステムコールをリアルタイムで監視するランタイムセキュリティツールです。コンテナ内でのシェル実行、機密ファイルの読み取り、ネットワーク接続など異常な活動を検知してアラートします。eBPFまたはカーネルモジュールを使用して動作します。

Falcoルールのconditionフィールドはどのような目的で使用されますか？

A) アラートメッセージの形式を定義する B) システムコールイベントをフィルタリングする条件式を定義してどのイベントがルールにマッチするか決定する C) ルールの優先度を設定する D) 出力チャネルを指定する

正解: B

conditionはSysdigフィルター構文を使用してイベントマッチング条件を定義します。例えばcontainer.id != host and proc.name = bashはコンテナ内でbashプロセスが実行されることを検知します。syscall、process、file、network関連フィールドを組み合わせることができます。

Falcoルールでコンテナ内部でシェル（bash、sh）が実行されることを検知するにはどのconditionを使用すべきですか？

A) fd.name contains /bin/bash B) container.id != host and proc.name in (bash, sh, zsh) and evt.type = execve C) k8s.pod.name exists D) syscall.type = open

正解: B

container.id != hostでコンテナ環境をフィルタリングし、proc.nameでシェルプロセスを指定し、evt.type = execveでプロセス実行イベントを検知します。この組み合わせでコンテナ内のインタラクティブシェルアクセスを効果的に検出できます。

Trivyを使用してコンテナイメージのHIGH/CRITICAL脆弱性のみ確認するには？

A) trivy image IMAGE_NAMEのみ実行すればよい B) trivy image --severity HIGH,CRITICAL IMAGE_NAMEで深刻度をフィルタリングする C) trivy scan --level=highコマンドを使用する D) docker scanコマンドのみ使用可能

正解: B

--severity HIGH,CRITICALフラグを使用すると指定された深刻度の脆弱性のみ表示します。--exit-code 1を追加すると脆弱性発見時にCI/CDパイプラインを失敗させることができます。--ignore-unfixedで修正可能な脆弱性のみ表示することもできます。

TrivyとGrypeの両方がイメージスキャニングツールです。主な違いは？

A) 両方とも完全に同じツールである B) Trivyはイメージ、ファイルシステム、Gitリポジトリ、IaCなど様々な対象をスキャンし、Grypeは主にイメージとSBOMベースの脆弱性スキャンに特化している C) Grypeはランタイムセキュリティツールである D) Trivyはネットワークスキャニングツールである

正解: B

TrivyはAqua Securityが開発した総合セキュリティスキャナーでイメージ、ファイルシステム、IaC、Secretスキャンなどをサポートします。GrypeはAnchoreが開発したツールでイメージおよびSBOMベースの脆弱性スキャンに集中します。両方ともCKS試験で扱われる可能性があるツールです。

OPA GatekeeperでConstraintTemplateの役割は何ですか？

A) Kubernetesリソースを直接作成する B) Rego言語で書かれたポリシーロジックを定義し、それに基づいてConstraintリソースを作成できるようにする C) NetworkPolicyを自動生成する D) RBACルールを管理する

正解: B

ConstraintTemplateはポリシーのスキーマとRegoロジックを定義します。これに基づいてConstraintリソースを作成すると特定条件でリソース作成/修正を制限できます。例えばprivilegedコンテナの禁止、特定レジストリのみ許可などのポリシーを実装します。

ConstraintTemplateとConstraintの関係について正しい説明は？

A) Constraintがポリシーロジックを含む B) ConstraintTemplateがポリシーロジック（Rego）を定義し、Constraintがそのテンプレートのインスタンスとして具体的なパラメータと適用範囲を指定する C) 両者は独立しており関係がない D) Constraintはネームスペース単位でのみ適用される

正解: B

ConstraintTemplateは再利用可能なポリシーテンプレート（Regoコード含む）であり、Constraintはそのテンプレートのインスタンスです。Constraintでmatchフィールドで適用対象（ネームスペース、リソース種類など）を指定し、parametersでポリシーの具体的な値を設定します。

Gatekeeper Constraintをdry-runモードに設定すると？

A) ポリシーが完全に無効化される B) ポリシー違反を検知しログに記録するが、実際にリソース作成/修正をブロックしない C) ポリシーが強制適用される D) テストネームスペースにのみ適用される

正解: B

ConstraintのenforcementActionをdryrunに設定するとポリシー違反時にリソースをブロックせず違反事項のみ記録します。新しいポリシーをプロダクションに適用する前に影響度を把握するのに有用です。denyはブロック、warnは警告のみ表示します。

コンテナイメージをタグの代わりにダイジェスト（sha256ハッシュ）で参照する理由は？

A) イメージダウンロード速度が速くなる B) 同じタグに異なるイメージがプッシュされるタグ改ざんを防止し、正確に検証されたイメージを使用することを保証する C) イメージサイズが減る D) レジストリ認証が不要になる

正解: B

タグは変更可能なので同じタグに異なるイメージがプッシュされる可能性があります（タグ改ざん）。ダイジェストはイメージ内容のハッシュ値なので内容が変更されるとダイジェストも変更されます。これにより署名された正確なイメージを使用することを保証できます。

クラスターで特定のコンテナレジストリ（例: myregistry.io）のイメージのみ使用するよう制限するには？

A) NetworkPolicyでレジストリアクセスをブロックする B) ConstraintTemplateでイメージ名プレフィックスを検査するRegoポリシーを作成し、Constraintで許可レジストリリストを指定する C) kubelet設定でレジストリを制限する D) Podにannotationを追加する

正解: B

ConstraintTemplateでコンテナイメージのプレフィックスが許可リストにあるか検査するRegoコードを作成します。Constraintでparametersに許可レジストリリスト（例: myregistry.io）を指定すると、そのレジストリ以外のイメージを使用するPod作成が拒否されます。

KubernetesでAppArmorプロファイルをコンテナに適用するには？

A) PodのsecurityContextに直接設定する B) コンテナのsecurityContext.appArmorProfileフィールドにプロファイルタイプと名前を指定する（Kubernetes 1.30+） C) ConfigMapにプロファイルを保存する D) クラスター全体に一度だけ設定すればよい

正解: B

Kubernetes 1.30+ではsecurityContext.appArmorProfileフィールドを使用します。typeにLocalhost、RuntimeDefaultなどを指定し、Localhostの場合localhostProfileにプロファイル名を指定します。プロファイルは該当ノードに事前にロードされている必要があります。

Seccomp（Secure Computing Mode）プロファイルの主な役割は？

A) ネットワークトラフィックをフィルタリングする B) コンテナが使用できるLinuxシステムコールを制限して攻撃表面を縮小する C) ファイルシステムアクセスを制御する D) CPU使用量を制限する

正解: B

Seccompはコンテナプロセスが呼び出せるシステムコールを制限します。RuntimeDefaultプロファイルは一般的に安全でないシステムコールをブロックします。カスタムプロファイルを作成して特定アプリに必要なシステムコールのみ許可することもできます。

PodのすべてのコンテナにデフォルトのSeccompプロファイルを適用するには？

A) Nodeに設定する必要がある B) Pod specのsecurityContext.seccompProfileにtype: RuntimeDefaultを設定する C) DaemonSetでデプロイする必要がある D) kube-proxyに設定する

正解: B

PodレベルのsecurityContext.seccompProfileにtype: RuntimeDefaultを設定するとすべてのコンテナに適用されます。コンテナレベルでも個別設定が可能でコンテナ設定がPod設定より優先されます。Localhostタイプでカスタムプロファイルも使用可能です。

Kubernetes Pod Security Standardsで定義される3つのセキュリティレベルは？

A) Low、Medium、High B) Privileged、Baseline、Restricted C) Basic、Standard、Enterprise D) None、Default、Strict

正解: B

Pod Security StandardsはPrivileged（制限なし）、Baseline（既知の権限昇格防止）、Restricted（強化されたセキュリティベストプラクティス）の3段階です。BaselineはhostNetwork、privilegedコンテナなどを禁止し、Restrictedは追加でroot実行、権限昇格などを禁止します。

特定のネームスペースにRestrictedレベルのPod Securityを適用するには？

A) CRDを作成する必要がある B) ネームスペースにpod-security.kubernetes.io/enforce: restrictedラベルを追加する C) クラスター全体の設定のみ可能 D) Podにannotationを追加する

正解: B

ネームスペースにpod-security.kubernetes.io/enforceラベルを設定すると該当レベルを超えるPod作成が拒否されます。enforce以外にaudit（監査ログ記録）とwarn（警告表示）モードもあります。バージョンも一緒に指定できます（例: pod-security.kubernetes.io/enforce-version: v1.30）。

Kubernetes RuntimeClassはどのような目的で使用されますか？

A) Podのネットワーク設定を管理する B) コンテナランタイムハンドラーを選択してgVisor、Kata Containersなど様々な分離レベルのランタイムをPodごとに指定できるようにする C) イメージレジストリを管理する D) ストレージクラスを管理する

正解: B

RuntimeClassを使用するとPodが使用するコンテナランタイムを選択できます。例えばセキュリティが重要なワークロードにgVisorやKata Containersを使用し、一般的なワークロードにはruncを使用する形でランタイムを分離できます。

gVisorとKata Containersの分離方式の違いは？

A) 両方とも同じ方式で動作する B) gVisorはユーザー空間でLinuxカーネルをエミュレーションし、Kata Containersは軽量仮想マシン（VM）内でコンテナを実行する C) gVisorはVMを使用しKataはネームスペースを使用する D) 両方ともeBPFベースである

正解: B

gVisor（runsc）はGoで書かれたユーザー空間カーネルで、システムコールをインターセプトして制限されたカーネルインターフェースを提供します。Kata Containersは各コンテナを軽量VMで実行してハードウェアレベルの分離を提供します。両方ともruncより強い分離を提供しますがオーバーヘッドがあります。

PodがgVisorランタイムを使用するよう設定するには？

A) ノードにラベルを追加する B) RuntimeClassリソースを作成し、Pod specのruntimeClassNameフィールドに該当RuntimeClass名を指定する C) kubelet設定のみ変更する D) すべてのPodが自動的にgVisorを使用する

正解: B

まずRuntimeClassリソースを作成してhandler（例: runsc）を指定します。その後Pod specのruntimeClassNameフィールドに該当RuntimeClass名を指定すると該当ランタイムでコンテナが実行されます。ノードに該当ランタイムがインストールされている必要があります。

AppArmorとSELinuxの主な違いは？

A) 両方とも同じ方式で動作する B) AppArmorはパスベースのアクセス制御を使用し、SELinuxはラベルベースの強制アクセス制御（MAC）を使用する C) SELinuxがよりシンプルである D) AppArmorはネットワークのみ制御する

正解: B

AppArmorはファイルパスベースでプロセスのアクセスを制御しプロファイル作成が比較的簡単です。SELinuxはすべてのファイル、プロセス、ポートにセキュリティラベルを割り当ててラベルベースの強制アクセス制御（MAC）を行い、より細かい制御が可能ですが複雑です。

Pod Security Admissionで特定のユーザーやネームスペースをポリシーから除外するには？

A) 除外は不可能である B) PodSecurityConfigurationのexemptionsフィールドでusernames、runtimeClasses、namespacesを指定して例外を設定する C) ネームスペースを削除する必要がある D) RBACでのみ制御可能

正解: B

PodSecurityConfiguration（AdmissionConfigurationファイル）のexemptionsで特定ユーザー、RuntimeClass、ネームスペースをポリシー適用から除外できます。システムコンポーネントや特殊なワークロードがセキュリティ制限を回避する必要がある場合に使用します。

Kubernetes監査ポリシーのomitStagesフィールドの用途は？

A) 特定リソースをロギングから除外する B) RequestReceivedなど特定のリクエスト処理段階をロギングから除外してログボリュームを削減する C) 監査ログを無効化する D) 特定ユーザーを除外する

正解: B

omitStagesを使用するとRequestReceived、ResponseStarted、ResponseComplete、Panicのうち特定段階をロギングから除外できます。例えばRequestReceivedを除外するとリクエスト受信時点のログを省略してログボリュームを削減できます。

Kubernetes APIサーバー監査ログのバックエンドの種類は？

A) ファイルバックエンドのみサポート B) ログバックエンド（ファイル）とWebhookバックエンド（外部サービス）をサポートする C) データベースバックエンドのみサポート D) syslogのみサポート

正解: B

Kubernetesはログバックエンド（--audit-log-pathでファイルに記録）とWebhookバックエンド（--audit-webhook-config-fileで外部HTTPサービスに送信）をサポートします。両バックエンドを同時に使用でき、各々別のポリシー設定が可能です。

kubeletのクライアント証明書が自動的にローテーションされるよう設定するには？

A) 手動でのみ更新可能 B) kubelet設定でrotateCertificatesをtrueに設定し、controller-managerでCSR自動承認を有効化する C) etcdで証明書を管理する D) 証明書は期限切れにならない

正解: B

kubeletのrotateCertificates: true設定は証明書期限切れ前に自動的にCSR（Certificate Signing Request）を生成します。kube-controller-managerのcsrsigningコントローラーがCSRを自動承認すると新しい証明書が発行されます。serverTLSBootstrapも合わせて設定するとサービング証明書も自動ローテーションされます。

etcdに保存されるSecretを暗号化するには？

A) Secretをbase64でエンコードすれば暗号化される B) EncryptionConfigurationファイルを作成しkube-apiserverに--encryption-provider-configフラグで指定する C) etcd自体が自動的に暗号化する D) Secretの代わりにConfigMapを使用する

正解: B

EncryptionConfigurationファイルで暗号化プロバイダー（aescbc、aesgcm、secretboxなど）とキーを定義します。kube-apiserver起動時に--encryption-provider-configでこのファイルを指定すると指定されたリソース（secretsなど）がetcdに暗号化されて保存されます。base64はエンコーディングであり暗号化ではありません。

Secrets暗号化でKMSプロバイダーを使用する利点は？

A) 設定がよりシンプルになる B) 暗号化キーが外部KMSで管理されてキー管理が中央化され、キーローテーションがAPIサーバー再起動なしで可能になる C) 暗号化パフォーマンスが低下する D) 追加インフラが不要になる

正解: B

KMSプロバイダーを使用するとDEK（Data Encryption Key）はローカルで生成し、DEKを暗号化するKEK（Key Encryption Key）は外部KMS（AWS KMS、GCP KMS、HashiCorp Vaultなど）で管理します。キーローテーション時にAPIサーバー再起動が不要でキー管理が中央化されます。

CIS（Center for Internet Security）Kubernetes Benchmarkとは何ですか？

A) Kubernetesパフォーマンスベンチマークツール B) Kubernetesクラスターのセキュリティ設定に関するベストプラクティスガイドラインで、コントロールプレーン、ノード、ポリシーなどのセキュリティ構成を検査する C) ネットワークパフォーマンステストツール D) イメージビルドガイド

正解: B

CIS BenchmarkはKubernetesコンポーネント（APIサーバー、etcd、kubelet、スケジューラーなど）のセキュリティ設定を点検するガイドラインです。kube-benchツールを使用して自動的に検査でき、各項目について合格/不合格/警告の結果を提供します。

kube-benchはどのような目的で使用されますか？

A) Kubernetesクラスターの負荷テストを実行する B) CIS Kubernetes Benchmarkに従ってクラスターセキュリティ設定を自動的に検査し結果を報告する C) イメージの脆弱性をスキャンする D) ランタイムセキュリティを監視する

正解: B

kube-benchはAqua Securityが開発したオープンソースツールで、CIS Benchmark項目を自動的に検査します。コントロールプレーン、ワーカーノード、etcdなどの設定を点検し、失敗項目に対する修正方法を案内します。Jobとしてクラスター内で実行できます。

cosignを使用してコンテナイメージに署名する目的は？

A) イメージサイズを縮小する B) イメージの出所と整合性を検証して承認されたビルドパイプラインで生成されたイメージのみデプロイされることを保証する C) イメージダウンロード速度を向上させる D) イメージの脆弱性を除去する

正解: B

cosign（Sigstoreプロジェクト）でイメージに署名すると、デプロイ時に署名を検証してイメージが信頼できるソースからビルドされ改ざんされていないことを確認できます。ポリシーエンジン（Kyverno、OPAなど）と連携すると署名されていないイメージのデプロイを自動ブロックできます。

コンテナイメージのSBOMを生成する理由は？

A) イメージビルドを自動化する B) イメージに含まれるすべてのソフトウェアパッケージと依存関係リストを提供して脆弱性管理とライセンス遵守をサポートする C) イメージを圧縮する D) イメージレイヤーを最適化する

正解: B

SBOMはコンテナイメージに含まれるすべてのパッケージ、ライブラリ、依存関係の詳細リストです。新しい脆弱性が発見された際に影響を受けるイメージを素早く特定し、ライセンス遵守状況を確認するのに活用されます。Syft、Trivyなどで生成できます。

Kubernetesサプライチェーンセキュリティでadmission controllerを活用する方法は？

A) イメージビルドを担当する B) イメージ署名検証、許可レジストリ検査、脆弱性スキャン結果確認などをデプロイ時点で自動的に実行して未承認イメージのデプロイをブロックする C) CI/CDパイプラインを管理する D) ソースコードをスキャンする

正解: B

Validating Admission Webhookやポリシーエンジン（Kyverno、OPA Gatekeeper）を使用してPod作成時にイメージ署名検証、許可レジストリ確認、脆弱性スキャン結果ベースのブロック、ダイジェスト使用強制などの検査を自動的に実行します。これによりサプライチェーン攻撃を防御できます。