[Golden Kubestronaut] CGOA 実践練習問題 80問 - Certified GitOps Associate

A) 運用チームのみがアクセスできる中央データベース B) Gitリポジトリに保存された宣言的設定がシステムの唯一の真実の源 C) Kubernetes APIサーバーに保存された現在のクラスタ状態 D) CI/CDパイプラインの最終ビルドアーティファクト

正解: B

解説: GitOpsにおけるSingle Source of Truthは、Gitリポジトリに保存された宣言的設定ファイルを意味します。すべてのインフラとアプリケーション状態はGitで管理され、これがシステムが到達すべきDesired State（望ましい状態）の唯一の基準点です。

A) Deviation B) Drift C) Delta D) Divergence

正解: B

解説: Drift（ドリフト）は、Gitリポジトリに定義されたDesired State（望ましい状態）とクラスタで実際に実行されているActual State（実際の状態）の差異を表すGitOpsの核心用語です。

A) システムが到達すべき最終状態を記述する B) 状態に到達するためのステップバイステップのコマンドを記述する C) 手動で各リソースを順番に作成する D) スクリプトを通じて手続き的にインフラを構成する

正解: A

解説: 宣言的アプローチは「何（What）」を望むかを記述します。一方、命令的（Imperative）アプローチは「どのように（How）」到達するかをステップバイステップで記述します。GitOpsは宣言的方式を核心原則として使用します。

A) Kubernetes YAMLマニフェストでDeploymentを定義 B) kubectl create deployment nginx --image=nginx コマンドを実行 C) HelmチャートでアプリケーションパッケージId定義 D) Kustomizeオーバーレイで環境別設定を管理

正解: B

解説: kubectl createコマンドはリソースを直接作成する命令的アプローチです。YAMLファイルで定義してkubectl applyするのが宣言的アプローチであり、HelmとKustomizeも宣言的ツールです。

A) 宣言的（Declarative） B) バージョン管理と不変性（Versioned and Immutable） C) 手動承認後に適用（Manual Approval Required） D) 継続的調整（Continuously Reconciled）

正解: C

解説: OpenGitOpsの4つの原則は（1）Declarative、（2）Versioned and Immutable、（3）Pulled Automatically、（4）Continuously Reconciledです。手動承認はワークフローに追加できますが、核心原則ではありません。

A) Gitリポジトリのブランチをマージする過程 B) 望ましい状態と実際の状態を比較して一致させる過程 C) CIパイプラインでテストを実行する過程 D) コンテナイメージをビルドしてレジストリにプッシュする過程

正解: B

解説: Reconciliation（調整）は、GitOpsエージェントがGitに定義された望ましい状態とクラスタの実際の状態を定期的に比較し、差異があれば実際の状態を望ましい状態に収束させる核心メカニズムです。

A) 新しいアプリケーションを初めてデプロイする時 B) 誰かがkubectl editでクラスタ内のリソースを直接変更した時 C) Gitに新しいコミットがプッシュされた時 D) CIパイプラインが新しいイメージをビルドした時

正解: B

解説: Drift Detectionは、Gitに定義された状態とクラスタの実際の状態が異なる場合にこれを検知する機能です。代表的にはkubectlなどでクラスタに直接変更を加えた場合にドリフトが発生します。

A) コンテナイメージを保存するレジストリ B) インフラとアプリケーションの望ましい状態を保存する宣言的ストア C) CI/CDパイプラインの実行ログを保存する場所 D) モニタリングメトリクスを収集するデータソース

正解: B

解説: GitOpsにおいてGitリポジトリは、インフラとアプリケーションの望ましい状態を宣言的に保存するSingle Source of Truthの役割を果たします。

A) アプリケーションのランタイムデータを保存するデータベース B) 望ましい状態の宣言を保存するバージョン管理システム C) クラスタイベントを保存するログシステム D) シークレットを暗号化して保存するボールトシステム

正解: B

解説: GitOpsにおけるState Storeは、システムの望ましい状態（Desired State）を宣言的に保存するバージョン管理システムです。Gitが最も代表的なState Storeであり、不変の履歴と監査追跡を提供します。

A) 開発者にコードレビュー通知を送ること B) 実際の状態が望ましい状態から逸脱した時に検知してアラートすること C) CIパイプラインのテスト結果を報告すること D) Gitコミットに自動コメントを追加すること

正解: B

解説: Feedback LoopはGitOpsエージェントが実際のクラスタ状態を観察し、望ましい状態との差異を検知してオペレーターに通知するメカニズムです。これによりドリフト発生時に即座に対応できます。

A) インフラは一度デプロイされたら絶対に変更できない B) 変更が必要な場合、既存インフラを修正せず新しく置き換える C) インフラのすべての設定がハードコーディングされている D) 物理サーバーでのみ可能なデプロイ方式

正解: B

解説: Immutable Infrastructureは既存インフラを変更（mutate）せず、新しいバージョンをデプロイして置き換えるパターンです。これにより構成ドリフトを防止し、ロールバックを容易にします。

A) コンテナイメージビルド速度の最適化 B) インフラとアプリケーションデプロイの一貫性、監査可能性、自動化 C) ソースコードコンパイル時間の短縮 D) ネットワーク帯域幅の最適化

正解: B

解説: GitOpsはインフラとアプリケーションのデプロイをGitベースのワークフローに統合し、一貫性（Consistency）、監査可能性（Auditability）、自動化（Automation）を保証することを目標としています。

A) コードをコンパイルしてテストを実行 B) Gitリポジトリの状態をクラスタに適用してドリフトを修正 C) 開発者のコードレビューを自動化 D) コンテナイメージをビルドしてプッシュ

正解: B

解説: GitOpsのSoftware Agent（ArgoCD、Fluxなど）はGitリポジトリに宣言された望ましい状態をクラスタに適用し、継続的にドリフトを検知して修正する役割を果たします。

A) GitOpsはモニタリングツールを代替する B) 実際の状態を観察して望ましい状態と比較するために不可欠 C) ログ収集とメトリクス分析のみを意味する D) CI/CDパイプラインのパフォーマンス測定にのみ使用される

正解: B

解説: GitOpsにおけるObservabilityは、クラスタの実際の状態を観察し、望ましい状態との差異を把握するために核心的な役割を果たします。ドリフト検知と自動修正の基盤となります。

A) 現在クラスタで実行中のすべてのリソースの状態 B) Gitリポジトリに宣言的に定義されたシステムが到達すべき目標状態 C) 運用チームが手動で設定したサーバー構成 D) モニタリングダッシュボードに表示されるメトリクス値

正解: B

解説: Desired StateはGitリポジトリに宣言的に定義されたシステムの目標状態です。GitOpsエージェントはこの状態を基準にクラスタを継続的に調整します。

A) 両者は完全に別の概念である B) Configuration as CodeはGitOpsの前提条件であり、すべての設定をコードとして管理する C) GitOpsはConfiguration as Codeを代替する新しい方法論である D) Configuration as Codeはアプリケーションコードにのみ適用される

正解: B

解説: Configuration as Codeはインフラとアプリケーション設定をコード（YAML、JSON、HCLなど）で管理することで、GitOpsを実現するための前提条件です。これによりGitバージョン管理と自動化が可能になります。

A) CIサーバーがクラスタに直接デプロイコマンドを送る B) クラスタ内部のエージェントがGitリポジトリから変更を取得して適用する C) 開発者がkubectlで直接リソースをデプロイする D) 外部スクリプトがSSHでサーバーに接続してデプロイする

正解: B

解説: Pullモデルでは、クラスタ内部で実行されるエージェント（ArgoCD、Flux）が定期的にGitリポジトリを確認し、変更をクラスタに適用します。外部からクラスタに直接アクセスする必要がないため、セキュリティ上有利です。

A) Gitリポジトリへの読み取り権限が必要 B) CI/CDシステムがクラスタへの直接アクセス権限（credentials）を保持する必要がある C) コンテナイメージレジストリへのアクセスが必要 D) コードレビュープロセスが複雑になる

正解: B

解説: PushモデルではJenkins、GitHub ActionsなどのCI/CDシステムがクラスタに直接アクセスするためのkubeconfigやServiceAccountトークンなどの資格情報を保持する必要があります。これはセキュリティ上の攻撃面を広げる欠点です。

A) クラスタで誰かが直接変更したDeploymentのreplica数の変更 B) Gitリポジトリに新しくコミットされたConfigMapの変更 C) 開発者のローカルマシンでテスト中の未コミットコード変更 D) Gitリポジトリにプッシュされた新しいHelmチャートバージョン

正解: C

解説: Reconciliation LoopはGitリポジトリにコミットされた状態とクラスタの実際の状態を比較します。開発者のローカルマシンでまだコミットされていない変更はGitに存在しないため、検知対象ではありません。

A) サーバーが物理的障害から自動的に復旧すること B) 実際の状態が望ましい状態と異なる場合、自動的に望ましい状態に復元すること C) アプリケーションコードのバグを自動的に修正すること D) ネットワーク障害を自動的に迂回すること

正解: B

解説: Self-HealingはGitOpsエージェントがドリフトを検知した時に自動的にGitに定義された望ましい状態に復元するメカニズムです。例えば誰かが手動でreplica数を変更すると、エージェントがこれを検知してGitの値に戻します。

A) すべての環境が単一ブランチで管理される B) 各環境（dev、staging、prod）に対応する別々のブランチが存在する C) ブランチなしでタグのみ使用する D) featureブランチから直接本番環境にデプロイする

正解: B

解説: Environment per Branchパターンでは、main、staging、productionなど各環境に対応するブランチを置き、該当ブランチにマージするとGitOpsエージェントが自動的にその環境にデプロイします。

A) kubectlで以前のバージョンのイメージを直接設定 B) Gitで以前のコミットにrevertして新しいコミットを作成 C) クラスタのetcdバックアップを復元 D) CI/CDパイプラインを手動で再実行

正解: B

解説: GitOpsにおけるロールバックはGitで以前のコミットにrevertすることが推奨されます。これにより変更履歴が保存され、GitOpsエージェントが自動的に以前の状態にクラスタを調整します。

A) 長期実行ブランチが増えてマージコンフリクトが減る B) 短命のブランチと頻繁な統合により高速なフィードバックとデプロイが可能 C) コードレビューなしで直接mainブランチにコミットできる D) 複数の環境を一つのブランチだけで管理できる

正解: B

解説: Trunk-Based Developmentは短命のfeatureブランチを使用し頻繁にmainに統合する方式です。GitOpsと組み合わせると頻繁なデプロイと高速なフィードバックループを実現できます。

A) 自動的にコンテナイメージをビルドする B) 変更に対するレビュー、承認、監査追跡を提供する C) クラスタに直接デプロイを実行する D) テスト環境を自動的にプロビジョニングする

正解: B

解説: Pull RequestはGitOpsワークフローにおいて変更に対するコードレビュー、チーム承認、自動化された検証（CI）、そして変更履歴の監査追跡を提供する重要なゲートです。

A) Gitリポジトリの容量制限のため B) アプリケーションソースコードとデプロイ設定の変更サイクルと権限が異なるため C) Gitがバイナリファイルをうまく処理できないため D) CI/CDパイプラインの速度を上げるため

正解: B

解説: アプリケーションソースコードとデプロイ設定（manifest）は変更サイクル、アクセス権限、レビュープロセスが異なります。これを分離すればそれぞれ独立して管理しRBACを適用できます。

A) デプロイ速度を上げるため B) 同一の宣言的状態を複数回適用しても結果が同一であることを保証するため C) Gitコミットメッセージの一貫性を維持するため D) コンテナイメージのサイズを削減するため

正解: B

解説: 冪等性は同一の操作を複数回実行しても結果が同一である属性です。GitOpsではreconciliation loopが繰り返し状態を適用するため、毎回同一の結果を保証する冪等性が不可欠です。

A) 違いはなく同一の概念である B) CI/CDはイベント基盤でトリガーされ、Continuous Reconciliationは継続的に状態を比較調整する C) CI/CDのみが自動化を提供する D) Continuous Reconciliationはビルド段階のみ含む

正解: B

解説: CI/CDはコミットやマージなどのイベントにトリガーされてビルド-テスト-デプロイを実行します。Continuous Reconciliationはイベントに関係なく継続的に望ましい状態と実際の状態を比較して調整します。

A) 別途の監査ログシステムを構築したため B) すべての変更がGitコミットとして記録され、誰が、いつ、何を変更したかを追跡できるため C) Kubernetesイベントが永久保存されるため D) CI/CDパイプラインログが保管されるため

正解: B

解説: GitOpsにおいてすべてのインフラ変更はGitコミットで行われるため、コミット履歴が自然に監査追跡の役割を果たします。コミッター、時刻、変更内容、PRレビュー記録がすべて保存されます。

A) すべてのチームが一つのリポジトリとネームスペースを共有 B) チーム別リポジトリとネームスペースを分離し、RBACでアクセスを制限 C) 各チームが独立したKubernetesクラスタを運用 D) GitOpsを使用せず手動デプロイ

正解: B

解説: Multi-tenancy環境ではチーム別Gitリポジトリとネームスペースを分離し、ArgoCDのAppProjectやFluxのTenant機能でRBACを適用して分離を保証します。

A) 同一YAMLをすべての環境にコピー&ペースト B) Pull Requestを通じて変更をdevからstaging、stagingからprodへ順次昇格 C) kubectlで各環境に手動デプロイ D) 環境ごとに完全に異なるマニフェストを作成

正解: B

解説: Environment PromotionはPull Requestワークフローを通じて変更をdevからstaging、stagingからproductionへ順次昇格するパターンです。各段階でレビューと自動テストを実行します。

A) Gitリポジトリアクセスの制限時間 B) 同期作業が完了するまでの最大許容時間 C) PRレビュー待機時間制限 D) イメージビルドタイムアウト

正解: B

解説: Reconciliation Timeoutは同期作業が完了するまでに許容される最大時間です。この時間内にリソースが正常状態に到達しないと同期失敗として処理されます。

A) IaCはGitOpsとは無関係な概念 B) IaCはGitOpsの基盤であり、インフラをコードとして定義してGitで管理する C) GitOpsはIaCを完全に代替する D) IaCはクラウド環境でのみ使用可能

正解: B

解説: Infrastructure as Codeはインフラをコードとして定義する方法論で、GitOpsの基盤です。IaCで定義されたインフラをGitに保存し、GitOpsエージェントがこれを自動的に適用します。

A) クラスタに直接デプロイを実行する B) Gitリポジトリの変更をエージェントに即座に通知して高速同期をトリガーする C) コンテナイメージをビルドする D) セキュリティスキャンを実行する

正解: B

解説: WebhookはGitリポジトリに変更が発生するとGitOpsエージェント（ArgoCD、Flux）に即座に通知を送り、ポーリング間隔を待たずに高速で同期を開始できるようにします。

A) 複数のGitブランチを一つに統合すること B) 実際の状態が望ましい状態に収束して一致すること C) 複数のマイクロサービスが一つのモノリスに統合されること D) 分散システムが一つのデータセンターに集約されること

正解: B

解説: ConvergenceはGitOpsエージェントのreconciliationを通じて、クラスタの実際の状態がGitに定義された望ましい状態に漸進的に収束し、最終的に一致することを意味します。

A) Pullモデルの方が速いため B) クラスタ資格情報を外部CI/CDシステムに公開する必要がないため C) Pullモデルは暗号化を使用するため D) PushモデルはGitを使用しないため

正解: B

解説: Pullモデルではクラスタ内部のエージェントがGitから読み取って適用するため、クラスタの資格情報（kubeconfig、token）を外部システム（Jenkins、GitHub Actionsなど）に共有する必要がありません。これは攻撃面を削減します。

A) 使用するプログラミング言語が異なる B) Declarativeは最終状態を定義し、Proceduralは到達ステップを定義する C) Declarativeの方が常に速い D) Proceduralの方が常に安全

正解: B

解説: Declarative Configurationは「システムがどの状態であるべきか」を定義し、Procedural Configurationは「どのステップを実行すべきか」を定義します。GitOpsは宣言的方式を使用します。

A) 関連がない B) Observabilityにより実際の状態を把握し、Reconciliationの基盤データを提供する C) ObservabilityがReconciliationを代替する D) 両方ともログ分析にのみ使用される

正解: B

解説: Observabilityはクラスタの実際の状態を把握する機能を提供します。GitOpsエージェントはこの情報を基に望ましい状態との差異を検知しReconciliationを実行します。

A) すべての変更が即座に適用される B) 時間が経つとクラスタ状態がGitに定義された状態と最終的に一致する C) データベースのトランザクション一貫性 D) ネットワーク遅延がない状態

正解: B

解説: GitOpsにおけるEventual Consistencyは、Gitに変更がコミットされた後、即座に適用されない場合があるが、reconciliation loopを通じて最終的にクラスタが望ましい状態に到達することを意味します。

A) 環境別Gitリポジトリ分離 B) 環境別ブランチ分離 C) 環境別ディレクトリ分離（Kustomize overlays） D) すべての環境のシークレットを一つのファイルに平文で保存

正解: D

解説: すべての環境のシークレットを一つのファイルに平文で保存することはセキュリティ上非常に危険であり、GitOpsの環境分離原則にも反します。環境分離はリポジトリ、ブランチ、またはディレクトリレベルで実装します。

A) ドリフト発生時に管理者にメールのみ送信 B) ドリフトを検知すると自動的にGitに定義された状態にクラスタを復元 C) ドリフトが発生するとクラスタを完全に再作成 D) ドリフト発生時にGitリポジトリをクラスタの状態で更新

正解: B

解説: Automated Drift RemediationはGitOpsエージェントがドリフトを検知した時に自動的にGitに定義された望ましい状態にクラスタを復元する機能です。Gitが常に真実の源であるため、クラスタをGitに合わせるのが正しい方向です。

A) Gitリポジトリをクローンしてマニフェストを生成する B) 実行中のアプリケーション状態を監視し、望ましい状態と比較する C) ユーザー認証を処理する D) Web UIを提供する

正解: B

解説: Application ControllerはArgoCDの核心コンポーネントで、Kubernetesクラスタで実行中のアプリケーション状態を継続的に監視し、Gitに定義された望ましい状態と比較します。

A) クラスタのリソース状態をキャッシュする B) Gitリポジトリをクローンし、Helm、Kustomizeなどでマニフェストを生成する C) RBACポリシーを管理する D) 外部システムに通知を送信する

正解: B

解説: Repository Server（repo-server）はGitリポジトリをクローンし、パス内のマニフェストをHelm、Kustomize、plain YAML、またはConfig Management Pluginなどを使用して最終的なKubernetesリソースにレンダリングします。

A) ユーザーセッションとマニフェストキャッシュを保存する B) Gitリポジトリのバックアップを維持する C) コンテナイメージをキャッシュする D) SSL証明書を管理する

正解: A

解説: ArgoCDにおいてRedisはマニフェスト生成結果のキャッシュとユーザーセッションデータを保存します。これによりRepository Serverの負荷を軽減し、応答速度を向上させます。

A) Gitリポジトリへのアクセス権限を管理する B) SSO（Single Sign-On）のためのOIDC/SAML/LDAP認証を提供する C) Kubernetesリソースの状態を確認する D) マニフェストをレンダリングする

正解: B

解説: DexはArgoCDに統合されたOIDC（OpenID Connect）Identity Providerで、SAML、LDAP、GitHub、Googleなど様々な外部認証システムとのSSOをサポートします。

A) GitRepository B) HelmRepository C) OCIRepository D) DockerRepository

正解: D

解説: Fluxのsource-controllerはGitRepository、HelmRepository、OCIRepository、Bucketなどのソースタイプをサポートします。DockerRepositoryはFluxで使用されるリソースタイプではありません。

A) Helmチャートをデプロイする B) Kustomizeオーバーレイを適用してKubernetesリソースをクラスタにデプロイする C) Gitリポジトリからソースを取得する D) 外部システムに通知を送信する

正解: B

解説: kustomize-controllerはsource-controllerが取得したソースにKustomizeオーバーレイを適用して最終マニフェストを生成し、クラスタにデプロイします。plain YAMLも処理できます。

A) HelmChart B) HelmRelease C) HelmDeployment D) HelmApplication

正解: B

解説: Fluxのhelm-controllerはHelmRelease CRDを使用してHelmチャートのリリースを宣言的に管理します。HelmReleaseでチャートソース、値（values）、依存関係などを定義します。

A) クラスタ内部のPod間通信を管理する B) 外部システム（Slack、Teams、Webhookなど）にイベント通知を配信する C) DNSレコードを更新する D) 証明書を自動更新する

正解: B

解説: notification-controllerはFluxイベント（同期成功/失敗、ドリフト検知など）をSlack、Microsoft Teams、Webhookなど外部システムに通知として配信します。

A) ArgoCDサーバーにエラーが発生した B) Gitに定義された状態とクラスタの実際の状態が異なる C) ネットワーク接続が切断された D) 認証トークンが期限切れ

正解: B

解説: OutOfSyncはGitリポジトリに定義された望ましい状態とクラスタで実行中の実際の状態に差異があることを示します。手動または自動Syncで一致させることができます。

A) すべてのPodが正常に実行中 B) 一部のリソースが正常でない状態（例：Pod CrashLoopBackOff） C) Gitリポジトリにアクセスできない D) ArgoCD UIにログインエラーが発生

正解: B

解説: Health StatusがDegradedの場合、アプリケーションの一部リソースが異常状態であることを示します。例えばPodがCrashLoopBackOffであったり、Deploymentのreplicaが不足している場合が該当します。

A) コンテナランタイムを管理する B) Kubernetesアプリケーションをパッケージとしてテンプレート化してデプロイする C) ネットワークポリシーを管理する D) クラスタ認証を処理する

正解: B

解説: HelmはKubernetesのパッケージマネージャーで、チャート（Chart）というパッケージ形式でKubernetesリソースをテンプレート化し、valuesでカスタマイズしてデプロイします。

A) テンプレートエンジンを使用してYAMLを生成する B) ベースマニフェストにパッチとオーバーレイを適用して環境別設定を生成する C) バイナリパッケージでアプリケーションをデプロイする D) コンテナイメージをビルドする

正解: B

解説: Kustomizeはテンプレートなし（template-free）でベースマニフェストにパッチ（patches）とオーバーレイ（overlays）を適用して環境別カスタマイズを行います。kustomization.yamlファイルで変換を定義します。

A) マニフェストレンダリングを自動化する B) Gitリポジトリに変更が検知されると自動的にクラスタに同期する C) イメージタグを自動的に更新する D) PRを自動的にマージする

正解: B

解説: Auto-Syncを有効にすると、ArgoCDがGitリポジトリで変更を検知した時に手動介入なしで自動的にクラスタに同期します。無効の場合、手動でSyncボタンをクリックまたはCLIを使用する必要があります。

A) 古いGitブランチを削除する B) Gitから削除されたリソースをクラスタからも自動的に削除する C) 使用されていないコンテナイメージを整理する D) 期限切れの証明書を削除する

正解: B

解説: PruneはGitリポジトリからリソース定義が削除された時、クラスタに残っている該当リソースを自動的に削除するオプションです。Auto-Syncと併用するとGitの状態とクラスタを完全に一致させることができます。

A) プロジェクトのソースコードを管理する B) アプリケーションがデプロイできるソースリポジトリ、対象クラスタ、ネームスペースを制限する C) CI/CDパイプラインを定義する D) モニタリングダッシュボードを構成する

正解: B

解説: AppProjectはArgoCDのRBAC単位で、該当プロジェクトに属するApplicationがアクセスできるGitリポジトリ、対象クラスタ、ネームスペース、作成可能なリソース種類などを制限します。

A) Flux CLIフラグでグローバル設定 B) 各リソース（GitRepository、Kustomizationなど）のspec.intervalフィールドで個別設定 C) Kubernetes ConfigMapで設定 D) 環境変数で設定

正解: B

解説: Fluxでは各リソース（GitRepository、Kustomization、HelmReleaseなど）のspec.intervalフィールドで個別にreconciliation周期を設定します。これによりリソース別に異なる周期を適用できます。

A) argocd app deploy APP_NAME B) argocd app sync APP_NAME C) argocd app apply APP_NAME D) argocd app push APP_NAME

正解: B

解説: argocd app sync APP_NAMEコマンドで特定のアプリケーションをGitリポジトリの最新状態と同期できます。

A) ArgoCD自体が障害から自動復旧する B) クラスタで手動変更が発生すると自動的にGitの状態に戻す C) Gitリポジトリの競合を自動的に解決する D) 期限切れのシークレットを自動的に更新する

正解: B

解説: Self-HealはAuto-Syncの下位オプションで、クラスタで手動変更（kubectl editなど）が検知されると自動的にGitに定義された状態に戻す機能です。ドリフトを即座に修正します。

A) Kubernetesクラスタを最初からインストールする B) Fluxコンポーネントをクラスタにインストールし、GitリポジトリにFlux設定をコミットする C) Helmチャートリポジトリを初期化する D) コンテナレジストリを設定する

正解: B

解説: Flux BootstrapはFluxコントローラーをクラスタにインストールし、Gitリポジトリに Flux設定ファイル（gotk-components.yamlなど）をコミットします。以後Fluxはこのリポジトリを通じて自身を管理します。

A) 同一のプログラミング言語で書かれている B) 両方ともCNCFプロジェクトであり、Pull基盤GitOpsエージェントである C) 同一のCRDを使用する D) 同一のWeb UIを提供する

正解: B

解説: ArgoCDとFluxはともにCNCF Graduatedプロジェクトであり、Pull基盤GitOpsモデルを実装したエージェントです。両方ともGo言語で書かれていますが、アーキテクチャとCRD、UIなどは異なります。

A) RBACポリシーを管理する B) デフォルトでサポートされていないツール（jsonnet、cueなど）でマニフェストを生成する C) クラスタネットワークを構成する D) ユーザーアカウントを管理する

正解: B

解説: Config Management Plugin（CMP）はArgoCDがデフォルトでサポートしないマニフェスト生成ツール（Jsonnet、CUE、KCLなど）をプラグイン形式で追加して使用できるようにします。

A) Sync完了後にクリーンアップ作業を実行する B) 実際の同期作業の前にデータベースマイグレーションなどの事前作業を実行する C) Sync失敗時に通知を送信する D) Gitリポジトリを事前検証する

正解: B

解説: PreSync Hookは実際の同期（Sync）の前に実行されるリソース（Job、Podなど）です。データベーススキーママイグレーション、設定検証など同期前に必要な事前作業に使用されます。

A) 違いはなく同一である B) Strategic merge patchは部分上書き、JSON 6902は明示的なadd/remove/replace操作を指定する C) JSON 6902の方が常に速い D) Strategic merge patchはHelmでのみ使用する

正解: B

解説: Strategic merge patchは既存リソースに部分的にフィールドを上書きする方式で、JSON 6902 patchはadd、remove、replace、move、copyなどの明示的な操作をパスで指定します。

A) LabelとFinalizer B) AnnotationとLabel C) ConfigMapとSecret D) CRDとWebhook

正解: B

解説: ArgoCDはAnnotation方式（デフォルト）とLabel方式で自身が管理するリソースを追跡します。Annotation方式はargocd.argoproj.io/tracking-idを、Label方式はapp.kubernetes.io/instanceを使用します。

A) 単一アプリケーションを複数クラスタにデプロイ B) ルートApplicationが子Applicationを宣言的に管理して大規模デプロイを構造化 C) 単一Gitリポジトリですべてのアプリケーションを管理 D) アプリケーション間のネットワーク通信を設定

正解: B

解説: App-of-Appsパターンではルート（親）Applicationが子Applicationリソースを含み、ArgoCDがこれを再帰的に同期します。これにより大規模マイクロサービスデプロイを体系的に管理します。

A) 新しいKubernetesクラスタを作成する B) ArgoCDに登録されたクラスタ一覧を基に各クラスタにApplicationを自動作成する C) クラスタのリソース使用量を監視する D) クラスタ証明書を管理する

正解: B

解説: Cluster GeneratorはArgoCDに登録されたクラスタ一覧を巡回し、各クラスタに対してApplicationを自動的に作成します。新しいクラスタが登録されると自動的にアプリケーションが作成されます。

A) Gitコミット履歴を基にApplicationを作成する B) Gitリポジトリのディレクトリ構造をスキャンして各ディレクトリに対応するApplicationを自動作成する C) Gitブランチ別にApplicationを作成する D) Gitタグを基にApplicationバージョンを管理する

正解: B

解説: Git Generator - DirectoryはGitリポジトリの指定パス配下のディレクトリをスキャンし、各ディレクトリに対応するApplicationを自動作成します。新しいディレクトリが追加されると自動的にApplicationが作成されます。

A) 行列演算でリソースを最適化する B) 2つのGeneratorを結合して組み合わせ（デカルト積）でApplicationを作成する C) マニフェストの文法を検証する D) クラスタ間ロードバランシングを行う

正解: B

解説: Matrix Generatorは2つの子Generatorを組み合わせてデカルト積（Cartesian product）でApplicationを作成します。例えばCluster GeneratorとGit Generatorを結合すると（クラスタ x ディレクトリ）のすべての組み合わせに対してApplicationを作成します。

A) 各クラスタに独立したArgoCDをインストール B) ハブ（Hub）クラスタのArgoCDが複数のスポーク（Spoke）クラスタを管理 C) すべてのクラスタが一つのGitブランチを共有 D) クラスタ間の直接API通信で同期

正解: B

解説: Hub-Spokeモデルでは中央ハブクラスタのArgoCDが複数のスポーククラスタを管理します。ArgoCDにリモートクラスタを登録すると、そのクラスタへApplicationをデプロイできます。

A) Gitで直接トラフィック比率を変更 B) Argo RolloutsまたはFlaggerを使用して段階的にトラフィックを切り替え C) すべてのPodを同時に新バージョンに置換 D) Blue-Greenデプロイのみサポート

正解: B

解説: Canary DeploymentをGitOpsで実装する際はArgo RolloutsやFlaggerなどのProgressive Deliveryツールを使用します。これらはトラフィック比率を段階的に調整しメトリクスを分析して自動昇格/ロールバックを実行します。

A) Kubernetes SecretをBase64でのみエンコードする B) 公開鍵でシークレットを暗号化してGitに安全に保存し、クラスタ内コントローラーが秘密鍵で復号化する C) シークレットを外部ボールトに保存し参照のみGitに保管する D) シークレットファイルを圧縮してGitに保存する

正解: B

解説: Sealed Secretsは非対称暗号を使用します。公開鍵（public key）でシークレットを暗号化してSealedSecretリソースを作成しGitに安全に保存し、クラスタのSealed Secrets Controllerが秘密鍵（private key）で復号化して通常のSecretに変換します。

A) シークレットをGitリポジトリに暗号化して保存する B) 外部シークレット管理システム（Vault、AWS SMなど）からシークレットを取得してKubernetes Secretとして同期する C) Kubernetes Secretを外部システムにエクスポートする D) シークレット値を環境変数として注入する

正解: B

解説: External Secrets OperatorはExternalSecret CRDを通じて外部シークレット管理システム（HashiCorp Vault、AWS Secrets Manager、Azure Key Vault、GCP Secret Managerなど）からシークレットを取得し、Kubernetes Secretとして自動同期します。

A) SOPSがクラスタでシークレットを直接管理する B) SOPSでYAML/JSONのvalueを暗号化してGitに保存し、CI/CDまたはGitOpsツールで復号化する C) SOPSがKubernetes APIを代替する D) SOPSでコンテナイメージを暗号化する

正解: B

解説: SOPSはYAMLやJSONファイルの値（value）のみを選択的に暗号化してGitに安全に保存します。キー（key）は平文で維持されレビューが可能であり、FluxのKustomize ControllerはSOPS復号化をネイティブにサポートします。

A) 長所：単一リポジトリで全アプリを管理し一貫性確保 / 短所：大規模時の権限管理が複雑 B) 長所：チーム別の完全な分離 / 短所：リポジトリ間の依存関係管理が困難 C) MonorepoはGitOpsに適していない D) 長所も短所もなくすべての状況で最適

正解: A

解説: Monorepoはすべてのアプリケーションデプロイ設定を単一リポジトリで管理します。長所は一貫性とシンプルな依存関係管理、短所は大規模組織で細かいRBAC適用とCI/CDパイプライン管理が複雑になることです。

A) PRを自動的にマージする B) 開いているPull Requestごとに一時的なプレビュー環境を自動作成する C) PRのコードレビューを自動化する D) PRにセキュリティスキャン結果を追加する

正解: B

解説: PullRequest GeneratorはGitHub、GitLabなどの開いているPRを検知し、各PRに対応する一時的なApplication（プレビュー環境）を自動作成します。PRが閉じられると該当環境も自動削除されます。

A) ArgoCD NotificationsまたはFlux notification-controller B) Kubernetes Eventだけで十分 C) 別途のcron jobで実装する必要がある D) モニタリングツール（Prometheus）のみ使用する

正解: A

解説: ArgoCD Notifications（argocd-notifications-controller）とFluxのnotification-controllerを使用して、ドリフト検知、同期状態変更などのイベントをSlack、Teams、PagerDutyなどにアラートを送信できます。

A) 単一環境のみ必要 B) 2つの環境（Blue、Green）のリソースが必要で、トラフィック切り替えメカニズムが必須 C) ロールバックが不可能 D) データベースマイグレーションが自動的に処理される

正解: B

解説: Blue-Greenデプロイでは現在のバージョン（Blue）と新バージョン（Green）の2環境を同時に運用するため2倍のリソースが必要です。ServiceやIngressによるトラフィック切り替えメカニズムが必須であり、Gitでこれを宣言的に管理します。

A) Gitブランチをマージする時 B) 複数のGeneratorの結果を共通キーで結合して特定の組み合わせにのみオーバーライドを適用する時 C) 複数のHelmチャートを結合する時 D) マニフェストを一つのファイルに結合する時

正解: B

解説: Merge Generatorは複数のGeneratorの結果を共通キーフィールドを基準にマージします。ベースGeneratorで全体リストを生成し、補助Generatorで特定項目にのみ追加パラメータをオーバーライドする時に有用です。

A) シークレットをGitに平文で保存してもよい B) シークレットは暗号化するか外部参照のみGitに保存して、平文シークレットがGitに公開されないようにする C) シークレットは常に環境変数でのみ管理する D) シークレット管理はGitOpsの範囲外

正解: B

解説: GitOpsにおいてシークレットは絶対に平文でGitに保存してはいけません。Sealed Secretsで暗号化するか、External Secrets Operatorで外部シークレットストアの参照のみGitに保存するのが核心原則です。

A) 直ちにArgoCDを本番環境にインストールする B) 既存のインフラとアプリケーション設定を宣言的コードに変換し、Gitリポジトリ戦略を策定する C) すべての開発者にkubectlアクセス権限を付与する D) モニタリングシステムを最初に完全に構築する

正解: B

解説: GitOpsを導入するにはまず既存のインフラとアプリケーション設定を宣言的コード（IaC、Kubernetes manifests）に変換し、Gitリポジトリ構造（monorepo vs polyrepo）、ブランチ戦略、環境管理方針を策定する必要があります。