クイズの説明
Month 5「マルチクラウド戦略を策定しよう」の卒業クイズです。マルチクラウド戦略、ワークロード配置、FinOps、セキュリティ、ベンダーマネジメントの全領域から出題します。
合格ライン: 80%（10問中8問正解）
問題
Q1. マルチクラウド戦略パターン（Step 1）
以下の組織の状況に最も適したマルチクラウド戦略パターンはどれですか？
AWSでコア業務を運用中。データサイエンスチームがBigQueryを希望、大企業顧客のSSO要件でMicrosoft連携が必要、来年度にEU展開を予定。
- A. DR/BCP分散パターン — すべてのワークロードを全クラウドで冗長化する
- B. ベストオブブリード + 規制対応の複合戦略 — 各クラウドの強みを活用しつつ規制要件に対応する
- C. 段階的移行パターン — AWSからGCPに全面移行する
- D. コスト最適化パターン — 最も安いクラウドにすべてを集約する
答えを見る
正解: B
この状況では3つの異なるニーズがあります。(1) BigQueryはGCPの得意分野（ベストオブブリード）、(2) Microsoft 365連携はAzureの得意分野（ベストオブブリード）、(3) EU展開はGDPR対応（規制対応）。これらを満たすのは「ベストオブブリード + 規制対応」の複合戦略です。全面冗長化（A）はコスト過大、全面移行（C）は要件と合わず、最安集約（D）はベストオブブリードの考え方と矛盾します。
Q2. ベンダーロックイン評価（Step 1）
LACE評価モデルでCloudFormationのスコアがL
, A, C, E（合計16）でした。最も適切な対策はどれですか？- A. CloudFormationの利用を拡大し、AWS専用の最適化を進める
- B. 新規リソースはTerraformで作成し、既存CloudFormationは優先度順に段階的にTerraformへ変換する
- C. CloudFormationをすべて即座に廃止する
- D. ロックインスコアは参考程度なので特段の対策は不要
答えを見る
正解: B
合計16は「極めて高リスク」に分類されます。ただし、即座の全廃止（C）は運用リスクが高すぎます。最も現実的なアプローチは「新規はTerraformで作成し、既存は優先度順に段階的に変換する」ことです。これにより新たなロックインの拡大を防ぎつつ、既存のロックインを計画的に解消できます。利用拡大（A）はリスクを増大させ、対策不要（D）は極めて高リスクを放置することになります。
Q3. ワークロード分類（Step 2）
決済処理ワークロード（DynamoDB依存、Tier 1）のマルチクラウド配置判断として最も適切なのはどれですか？
- A. ロックインが深いので即座にGCPに移行する
- B. ビジネスクリティカルかつDynamoDB依存が深いため、AWSに残留させ、Repository層で抽象化を導入する
- C. コスト削減のためにAzureに移行する
- D. 3つのクラウドすべてで同時に稼働させる
答えを見る
正解: B
決済処理はTier 1（ミッションクリティカル）であり、DynamoDBへの依存度が高い（LACE高スコア）ワークロードです。即座の移行（A, C）はサービス停止リスクが極めて高く、3クラウド同時稼働（D）はコストとデータ整合性の問題が大きすぎます。AWSに残留させつつ、将来の移行可能性を確保するためにRepository層で抽象化を導入するのが最も合理的です。DynamoDBの強み（単桁ミリ秒レイテンシ）を活かしながらリスクを管理できます。
Q4. マイグレーションパターン（Step 2）
Redshift上のDWHをBigQueryに移行する場合、最も適切な移行戦略と注意点の組み合わせはどれですか？
- A. Rehost（Lift & Shift）— そのまま移すだけで特段の作業は不要
- B. Replatform — Redshift固有のSQLをBigQuery SQLに変換し、ETLパイプラインを再構築する。並行稼動でデータ整合性を検証
- C. Refactor — DWH全体をスクラッチから再構築する
- D. Retire — DWH自体を廃止する
答えを見る
正解: B
RedshiftからBigQueryへの移行は「Replatform」が最適です。両者はDWHという同じカテゴリですが、SQL方言やデータ型、パーティショニング戦略が異なるため、単純なLift & Shift（A）は不可能です。ただし、完全な再構築（C）は過剰であり、Redshift固有のSQL変換とETLパイプラインの再構築で十分です。並行稼動期間を設けてデータ整合性を検証することが、ダウンタイムとリスクを最小化する鍵です。DWH廃止（D）は要件に反します。
Q5. FinOps — コスト可視化（Step 3）
マルチクラウドのコスト可視化で最も重要な基盤となるのはどれですか？
- A. 各クラウドのコンソールを個別に確認する体制
- B. クラウド横断の統一タグ戦略と、全クラウドのコストデータを統合するダッシュボード
- C. Excelで月末に手動集計する
- D. コスト管理はCFOの仕事なので技術チームは関与しない
答えを見る
正解: B
マルチクラウドFinOpsの基盤は「統一タグ戦略」と「統合ダッシュボード」です。クラウドごとに異なるタグ/ラベルの命名規則を統一し（例: ts:product, ts:team）、AWS CUR + GCP Billing Export + Azure Cost Exportを統合DWHに集約してダッシュボードで可視化します。個別コンソール（A）やExcel集計（C）ではリアルタイム性と正確性が失われます。FinOpsは技術チームを含む全社的な取り組みです（D）。
Q6. FinOps — コスト最適化（Step 3）
年間クラウドコスト9.6億円を8.5億円に削減する目標があります。最初に着手すべき施策群はどれですか？
- A. アプリケーションの全面リアーキテクチャ
- B. 未使用リソース削除、ライトサイジング、開発環境の自動停止、Savings Plans購入
- C. すべてのワークロードを最安のクラウドに即座に移行する
- D. エンジニアの人件費を削減する
答えを見る
正解: B
コスト最適化は「L1: 無駄の排除」から始めます。未使用リソース削除、ライトサイジング、開発環境の自動停止はリスクが低く即効性が高い施策です。これにSavings Plans/CUD購入を組み合わせることで、短期間で大きな削減効果が得られます。全面リアーキテクチャ（A）は高コスト・高リスクで最初の施策としては不適切です。即座の全移行（C）はエグレスコストで逆にコスト増の可能性があります。人件費削減（D）はFinOpsの範囲外です。
Q7. セキュリティ — ID連携（Step 4）
マルチクラウド環境のID管理で、最も推奨されるアーキテクチャはどれですか？
- A. 各クラウドにローカルユーザーを個別作成し、パスワードは全クラウドで同じにする
- B. 統一IdPからSAML/OIDCで全クラウドにSSO連携し、サービスアカウントはOIDC Federationでキーレス認証にする
- C. 全ユーザーにすべてのクラウドの管理者権限を付与する
- D. 認証はアプリケーション側で独自実装し、クラウドのIAM機能は使わない
答えを見る
正解: B
マルチクラウドのID管理のベストプラクティスは、(1) 統一IdP（Entra ID, Okta等）を中心にSAML/OIDCでSSOを提供し、(2) サービスアカウントは長期アクセスキーを排除してOIDC Federationによるキーレス認証を導入することです。ローカルユーザーの個別作成（A）はIDの分散管理によるセキュリティリスクを生み、パスワード共通化は一つの漏洩で全クラウドが危険にさらされます。全員管理者権限（C）は最小権限の原則に完全に反します。
Q8. セキュリティ — ネットワーク（Step 4）
マルチクラウドのネットワーク設計で絶対に避けるべきミスはどれですか？
- A. 各クラウドでサブネットのサイズを変えること
- B. 複数のクラウドで同じCIDRレンジ（例: どちらも10.0.0.0/16）を使用すること
- C. VPN接続にIPsec暗号化を使用すること
- D. ネットワーク構成をTerraformで管理すること
答えを見る
正解: B
複数クラウドで同じCIDRレンジを使用すると、VPN/Interconnect接続時にルーティングが衝突し、クラウド間の通信が正しく機能しなくなります。例えば、AWSとGCPの両方で10.0.0.0/16を使用すると、パケットがどちらのネットワーク宛か判断できません。設計段階で全クラウドのCIDRを統合管理し、重複を排除することが必須です。サブネットサイズの違い（A）、IPsec暗号化（C）、Terraform管理（D）はいずれも問題ありません。
Q9. ベンダーマネジメント — 契約交渉（Step 5）
マルチクラウド移行中にAWS EDPの更新交渉を行う場合、コミットメント額の設定として最も適切なのはどれですか？
- A. 現在の利用額をそのまま維持してコミットする
- B. マルチクラウド移行による利用減少を見込み、確実に達成できる保守的な額をコミットし、GCP/Azureの見積もりを交渉材料にする
- C. 最大割引を得るために実際の利用予測の200%をコミットする
- D. EDPは一切結ばず、全額オンデマンドで利用する
答えを見る
正解: B
マルチクラウド移行中は、AWSの利用額が減少する可能性があるため、保守的なコミットメント額を設定すべきです。同時に、GCP/Azureの見積もりや利用実績を交渉材料として活用することで、「他クラウドとの競争環境がある」ことをAWSに認識させ、割引率の改善を引き出せます。現状維持（A）はコミット割れリスク、過大コミット（C）は確実な損失、全オンデマンド（D）は割引ゼロでコスト効率が悪化します。
Q10. 総合判断問題（All Steps）
あなたはマルチクラウドアーキテクトとして、以下の状況に直面しています。最も適切な対応はどれですか？
状況: マルチクラウド移行のPhase 2（分析基盤のBigQuery移行中）で、以下の問題が同時に発生した。
- BigQuery移行テスト中に、一部のSQLクエリがRedshiftと異なる結果を返している
- AWSのEDP更新期限が1ヶ月後に迫っているが、GCPへの移行量が確定していないためコミットメント額が決められない
- GCPアカウントのIAM設定にミスがあり、開発者が本番データにアクセスできる状態が発見された
- CFOから「マルチクラウドのコストが当初計画より20%高い。説明を求める」と連絡があった
- A. コスト超過が経営課題なので最優先で対応し、他の問題は後回しにする
- B. すべての問題を一人で同時に対応し、速やかに解決する
- C. セキュリティ問題（IAMミス）を最優先で修正し、次にデータ整合性問題を調査、その上でEDP交渉とコスト説明を並行で進める
- D. マルチクラウド移行自体を中止し、すべてAWSに戻す
答えを見る
正解: C
複合的な問題が発生した場合の優先順位付けが重要です。
最優先: セキュリティ（問題3） — 開発者が本番データにアクセスできる状態はセキュリティインシデントです。データ漏洩に繋がる可能性があり、即座にIAMの修正（アクセス制限）が必要です。
次優先: データ整合性（問題1） — クエリ結果の不一致は、移行の品質に直結します。根本原因（SQL方言の違い、データ型の差異等）を特定し、移行テストを強化する必要があります。
並行対応: EDP交渉とコスト説明（問題2, 4） — EDP交渉は「現時点で確定している利用量」に基づいて保守的なコミットメントを設定し、GCP移行量は変動可能な形で交渉します。コスト超過はFinOpsダッシュボードの実績データをもとに原因（移行コスト、並行運用コスト等）を具体的に説明し、計画との差分を明示します。
移行中止（D）はこれまでの投資を無駄にし、課題を解決する方向で進めるべきです。
結果
合格（8問以上正解）
おめでとうございます。Month 5「マルチクラウド戦略を策定しよう」を修了しました。
マルチクラウド戦略の策定、ワークロード配置設計、FinOps体制構築、セキュリティ統合設計、ベンダーマネジメント — マルチクラウドの導入・運用に必要なすべての要素を学び、統合した戦略計画書を作成する力を身につけました。
「AWS一極集中から、戦略的なマルチクラウド活用へ。“選べる”技術力と”選ばない”判断力の両方を持つアーキテクトだ。この力を実際のプロジェクトで発揮してくれ」 — 田中VPoE
不合格（7問以下正解）
Month 5の内容を復習し、再度チャレンジしましょう。特に不正解だった領域のStepを重点的に復習してください。
| 問題番号 | 対応するStep |
|---|---|
| Q1 | Step 1: マルチクラウド戦略パターン |
| Q2 | Step 1: ベンダーロックイン評価 |
| Q3 | Step 2: ワークロード分類と配置判断 |
| Q4 | Step 2: マイグレーションパターン |
| Q5 | Step 3: コスト可視化の統合 |
| Q6 | Step 3: コスト最適化戦略 |
| Q7 | Step 4: ID連携とアクセス管理 |
| Q8 | Step 4: ネットワークセキュリティ |
| Q9 | Step 5: 契約交渉とコミットメント戦略 |
| Q10 | 総合: 全Stepの統合判断 |
推定所要時間: 30分