QUIZ 30分

クイズの説明

Step 2「セルフサービスプラットフォームを設計しよう」の理解度を確認します。セルフサービス設計、API駆動プラットフォーム、Kubernetes抽象化、GitOpsについて問います。

合格ライン: 80%（5問中4問正解）

問題

Q1. セルフサービスの成熟度

セルフサービス成熟度L3（パラメータ化セルフサービス）の特徴として最も適切なものはどれですか？

  • A. すべてのインフラ操作をインフラチームにチケットで依頼する
  • B. Terraformモジュールを開発者に渡し、開発者がカスタマイズして実行する
  • C. 開発者がWebフォームやCLIでパラメータを選択するだけでリソースが自動プロビジョニングされる
  • D. AIがサービスの使用パターンを分析し、必要なリソースを自動提案する
答えを見る

正解: C

L3（パラメータ化セルフサービス）では、開発者がパラメータ（サイズ、環境、名前等）を選択するだけでリソースが自動的にプロビジョニングされます。A（チケット依頼）はL1、B（テンプレートをカスタマイズ）はL2、D（AI自動提案）はL5に該当します。L3では開発者がインフラの詳細を知らなくても、抽象化されたパラメータを選ぶだけで必要なリソースが得られます。

Q2. API-First設計

Platform APIをAPI-Firstで設計する最大のメリットはどれですか？

  • A. Webポータルの開発が不要になる
  • B. APIドキュメントが自動生成される
  • C. Webポータル、CLI、CI/CDパイプライン、Slackボットなど、複数のクライアントから統一されたインターフェースで操作でき、自動化の基盤となる
  • D. REST APIはgRPCより高速である
答えを見る

正解: C

API-Firstの最大のメリットは、すべてのプラットフォーム操作がAPIとして定義されることで、Webポータル、CLI、CI/CDパイプライン、Slackボットなど、任意のクライアントから統一されたインターフェースで操作できることです。これにより、UIからしかできない操作が生まれることを防ぎ、自動化の基盤を確保できます。A（Webポータル不要）ではなく、APIの上にWebポータルを構築します。B（ドキュメント自動生成）は副次的なメリットです。

Q3. Kubernetes抽象化

開発者がApplication CRD（約30行）を書くことで、プラットフォームがDeployment、Service、HPA、PDB、NetworkPolicy等を自動生成するアプローチの最大の利点はどれですか？

  • A. YAMLの行数が減るため、Gitリポジトリのサイズが小さくなる
  • B. 開発者の認知負荷を大幅に軽減しつつ、セキュリティやベストプラクティスを自動適用できる
  • C. Kubernetesのバージョンアップが不要になる
  • D. すべてのサービスが同じリソース量で動作するようになる
答えを見る

正解: B

Application CRDによる抽象化の最大の利点は、開発者が「何をデプロイしたいか」だけを記述し、「どうデプロイするか」はプラットフォームが決定することで、認知負荷を大幅に軽減できることです。同時に、SecurityContext、NetworkPolicy、PDB等のベストプラクティスやセキュリティ設定が自動的に適用されるため、設定漏れのリスクも排除できます。D（同じリソース量）ではなく、T-shirt Sizingにより適切なリソース量を選択できます。

Q4. GitOpsの原則

GitOpsにおけるPullモデル（Argo CD等）がPushモデル（CIパイプラインからのkubectl apply）より優れている点として最も適切なものはどれですか？

  • A. Pullモデルの方がデプロイ速度が速い
  • B. CIパイプラインにクラスタの認証情報を持たせる必要がなく、ドリフト（Gitとクラスタの乖離）を自動検出・修正できる
  • C. Pullモデルではテストが自動的に実行される
  • D. Pullモデルの方がコスト効率が良い
答えを見る

正解: B

GitOpsのPullモデルでは、クラスタ内のエージェント（Argo CD等）がGitリポジトリを監視し、変更を検知して自動的にクラスタに反映します。CIパイプラインにクラスタの認証情報を持たせる必要がないため、攻撃面が狭くなります。また、クラスタの実際の状態がGitの宣言と異なっていれば自動的に検出・修正（Reconciliation）するため、手動変更による設定のドリフトを防止できます。A（デプロイ速度）は必ずしもPullの方が速いわけではありません。

Q5. プロモーション戦略

GitOpsにおける環境間プロモーション（dev→staging→production）で、最も安全なアプローチはどれですか？

  • A. 1つのブランチにすべての環境の設定を入れ、mainへのマージで全環境に同時デプロイする
  • B. 環境ごとにGitOpsリポジトリのディレクトリを分け、devでの自動テスト成功後にstagingへPRを自動作成し、productionへは承認必須のPRで昇格させる
  • C. 開発者が各環境に手動でkubectl applyを実行する
  • D. すべての環境で同じ設定を使い、環境変数だけで制御する
答えを見る

正解: B

環境ごとにGitOpsリポジトリのディレクトリを分離し、段階的にプロモーションするアプローチが最も安全です。devではイメージプッシュ後に自動同期し、自動テストを実行。成功すればstagingへのPRを自動作成。stagingでのテスト成功後、productionへの昇格は承認必須のPRで管理します。これにより、各環境でのテストによる品質保証と、productionへの変更に対する承認による統制が両立します。A（全環境同時デプロイ）は障害の影響範囲が大きく危険です。

結果

合格（4問以上正解）

Step 2の内容をよく理解しています。セルフサービスプラットフォームの設計に必要な知識を身につけました。次のStep 3「Internal Developer Portalを構築しよう」に進みましょう。

不合格（3問以下正解）

Step 2の内容を復習しましょう。特に以下のポイントを重点的に確認してください：

  • セルフサービス成熟度 — L1からL5の5段階と目標設定
  • API-First — すべての操作をAPIとして定義する意義
  • Kubernetes抽象化 — Application CRDによる認知負荷の軽減
  • GitOps — Pull型モデルとプロモーション戦略

推定所要時間: 30分