クイズの説明
Step 2「技術基盤の目標状態を設計しよう」の理解度を確認します。目標アーキテクチャ、プラットフォーム戦略、統合設計、技術標準とガバナンスについて問います。
合格ライン: 80%（5問中4問正解）
問題
Q1. アーキテクチャ原則の適用
「新規サービスを構築する際、チームがオンプレミスサーバーでの構築を提案してきた」場合、「クラウドネイティブ第一」の原則に基づく対応として最も適切なものはどれですか？
- A. 原則を厳格に適用し、理由を聞かずにクラウドでの構築を指示する
- B. オンプレミスを選択した理由を確認し、正当な理由がなければクラウドネイティブでの構築を推奨する。正当な理由がある場合は例外として承認し記録する
- C. アーキテクチャ原則はあくまで参考であり、チームの判断を尊重する
- D. クラウドネイティブ第一の原則を廃止し、チームの自由に任せる
答えを見る
正解: B
アーキテクチャ原則は一貫性を保つための指針ですが、現実には例外が必要な場合もあります（規制要件、超低レイテンシ要件、既存システムとの物理的接続等）。重要なのは、原則からの逸脱には正当な理由を求め、例外として記録・追跡することです。理由を聞かずに強制する（A）のは組織の信頼を損ない、参考程度にする（C）や廃止する（D）では原則の意味がなくなります。例外管理プロセスを通じて、原則の有効性を維持しつつ柔軟性を確保します。
Q2. プラットフォーム間の統合
CI/CDプラットフォームとセキュリティプラットフォームの統合において、「Guardrails, not Gates」の原則を実現する方法として最も適切なものはどれですか？
- A. デプロイ前にセキュリティチームの手動承認を必須にする
- B. CI/CDパイプラインにSAST/SCA/DASTを自動統合し、ポリシー違反時は自動的にブロックする。開発者にはフィードバックと修正方法を提示する
- C. セキュリティスキャンは任意とし、チームの自主性に委ねる
- D. デプロイ後にセキュリティスキャンを実行し、問題があれば事後対応する
答えを見る
正解: B
「Guardrails, not Gates」は、人間の承認ゲート（Gate）ではなく、自動化されたガードレール（Guardrail）で安全性を確保するアプローチです。CI/CDパイプラインにセキュリティスキャンを自動統合（B）することで、開発速度を損なわずにセキュリティを担保できます。手動承認（A）はボトルネックになり、任意（C）では漏れが発生し、事後対応（D）ではリスクが本番に到達してしまいます。Month 1（CI/CD）とMonth 4（セキュリティ）の知見を統合したDevSecOpsの実践です。
Q3. 技術標準の分類
以下の4つの技術標準のうち、「必須（Mandatory）」層に分類すべきものはどれですか？
- A. OpenTelemetryによるトレース計装
- B. 全クラウドリソースへのコスト管理タグの付与
- C. ADR（Architecture Decision Record）の作成
- D. TypeScriptの使用
答えを見る
正解: B
「必須（Mandatory）」層には、セキュリティ、コンプライアンス、コスト管理など、組織として例外を認めるべきでない項目を配置します。コスト管理タグ（B）は、FinOps（Month 5）の基盤であり、タグなしのリソースはコスト配分が不可能になるため必須です。OpenTelemetry（A）とADR（C）は良い慣行ですが「推奨」または「標準」レベルが適切です。TypeScript（D）は言語選定であり、チームの技術スタックによって異なるため「推奨」が妥当です。
Q4. プラットフォーム戦略の段階
IDPの成熟度を「Stage 1: ツール提供 → Stage 2: テンプレート提供 → Stage 3: セルフサービス → Stage 4: 自動最適化」で進める場合、Stage 2からStage 3への移行で最も重要な要素はどれですか？
- A. より多くのテンプレートを追加すること
- B. 開発者が申請や承認なしに、WebUIやCLIからリソースをプロビジョニングできるようにすること
- C. プラットフォームチームの人数を倍増すること
- D. 全チームへのIDP利用を義務化すること
答えを見る
正解: B
Stage 2（テンプレート提供）からStage 3（セルフサービス）への移行の本質は、「開発者の自律性」です。テンプレートが存在しても、利用にプラットフォームチームの介入が必要であればセルフサービスとは言えません。WebUIやCLIから申請なしにリソースを作成・管理できること（B）がセルフサービスの核心です。Month 6で学んだIDPの設計思想であり、Month 8のリーダーシップで学んだ「自律と統制のバランス」の具体的実現でもあります。テンプレート追加（A）はStage 2の改善、人員増（C）はスケールしない方法、義務化（D）は採用を促進しますがセルフサービスの本質ではありません。
Q5. イベント駆動統合の設計
「SLOのエラーバジェットが枯渇した」というイベントが発生した場合、プラットフォーム間で連鎖すべきアクションとして最も適切な組み合わせはどれですか？
- A. オブザーバビリティPF → CI/CD PF（デプロイ凍結） → IDP（チーム通知）
- B. オブザーバビリティPF → データPF（ログ分析） → AI/ML PF（予測モデル更新）
- C. セキュリティPF → CI/CD PF（全パイプライン停止） → 経営層通知
- D. CI/CD PF → オブザーバビリティPF → セキュリティPF
答えを見る
正解: A
Month 2のSREで学んだエラーバジェットポリシーに基づくと、エラーバジェット枯渇時はサービスの信頼性を回復させるために、新機能のデプロイを凍結（CI/CD PFへのアクション）し、担当チームに通知（IDPを通じたコミュニケーション）するのが適切です。これはオブザーバビリティPFが検出し、CI/CDとIDPに連鎖するイベント駆動の典型例です。B はエラーバジェット枯渇の直接的な対応ではなく、C はセキュリティインシデントの対応であり、D はイベントの発生元が間違っています。
結果
合格（4問以上正解）
Step 2の内容をよく理解しています。目標アーキテクチャの設計、プラットフォーム戦略、統合設計、技術標準とガバナンスの考え方を身につけました。次のStep 3「移行ロードマップを策定しよう」に進みましょう。
不合格（3問以下正解）
Step 2の内容を復習しましょう。特に以下のポイントを重点的に確認してください：
- アーキテクチャ原則 — 原則の適用と例外管理のバランス
- Guardrails, not Gates — 自動化されたガードレールによるセキュリティ
- 3層標準化 — 必須/標準/推奨の分類基準
- プラットフォーム成熟度 — セルフサービスの本質
- イベント駆動統合 — プラットフォーム間の連鎖アクション
推定所要時間: 30分