Cloud Digital Leader 完全攻略② — インフラ近代化・セキュリティ・運用の後半3領域

Cloud Digital Leader の後半 3 領域は、クラウドで「何を作り、どう守り、どう運用するか」を問う実践寄りのパートだ。前半の概念・データ・AI に続き、本記事は Section 4（インフラとアプリの近代化）、Section 5（信頼性とセキュリティ）、Section 6（運用によるスケーリング）を、公式試験ガイドの論点に沿って攻略する。配点は 3 領域とも約 17% ずつ、合計で約 51% と試験の過半を占める。ここを固めれば合格はぐっと近づく。

前半 3 領域はCloud Digital Leader 完全攻略①（2026-06-23 公開）で扱った。本記事と合わせて読むことで、Cloud Digital Leader の 6 領域すべてが視野に入る。

後半 3 領域の地図 — 構築・保護・運用で過半を取る

後半の 3 領域は、前半の「理解する」フェーズから「実際に動かし、守り、回す」フェーズへと話が移る。それぞれの性格を先に掴んでおこう。Section 4 は、既存システムをどうクラウドへ移し、どんなコンピュート基盤で動かすかという「構築」の領域だ。Section 5 は、その基盤をどう守るかという「保護」の領域で、暗号化や認証、Google のインフラ設計思想が問われる。そして Section 6 は、コストと信頼性をどう管理し続けるかという「運用」の領域になる。

3 領域とも配点が約 17% で並ぶため、どれも捨てられない。とりわけ後半は、AWS で運用やセキュリティを経験した読者ほど既視感のある論点が多く、知識の流用が効く。逆に、開発寄りのキャリアで運用に縁が薄かった読者にとっては、財務ガバナンスや SRE といった用語が新鮮に映るはずだ。自分の経験の濃淡に合わせて、薄い領域に時間を多めに配るのが効率的だ。

もう一つ意識したいのは、後半が前半の知識をそのまま使う構造になっている点だ。前半で学んだ責任共有の考え方はセキュリティの領域で再び問われ、データ活用の知識は運用領域のコスト管理につながる。前半と後半は分断されておらず、一つの物語の前編と後編のような関係にある。だから後半を学ぶときは、前半で覚えた概念を「今度は守る側・運用する側の視点で見るとどうなるか」と問い直すと、理解が一段深まる。丸暗記ではなく、視点を移しながら同じ知識を何度も使い回す、という学び方が後半では効いてくる。

Section 4 — インフラとアプリの近代化（約 17%）

Section 4 は、クラウド移行とコンピュートの選択肢を扱う、後半で最も範囲が広い領域だ。まず問われるのが、なぜ近代化と移行が変革の重要なステップなのか、そしてアプリごとに最適な移行パスが異なる、という考え方である。すべてを一律にクラウドへ持ち上げるのではなく、アプリの特性に応じて移行方法を選び分ける、という視点が核心になる。

移行を語るうえで欠かせないのが、専用の用語群だ。公式試験ガイドは、ワークロード、retire（廃止）、retain（保持）、rehost（再ホスト）、lift and shift（リフト＆シフト）、replatform（プラットフォーム変更）、move and improve（移行と改善）、refactor（リファクタリング）、reimagine（再構想）といった言葉を挙げている。これらは「どこまで手を加えてクラウドへ移すか」のグラデーションだ。手を加えずそのまま動かす rehost から、設計を根本から作り直す reimagine まで、コストと効果のバランスで選ぶ。

移行方法を選ぶ判断は、現実のプロジェクトでも頭を悩ませる論点だ。古くて動いてさえいればよいシステムは、手をかけずにそのまま移すのが合理的だし、これから長く育てていく中核システムなら、思い切って作り直す価値がある。試験では、こうした「どのアプリにどれだけ投資するか」という経営判断が、移行方法の選択という形で問われる。一律にすべてを近代化するのではなく、投資対効果で濃淡をつける、という発想が背景にあると理解しておきたい。すべてを最新化しようとして予算と時間を使い果たすのは、よくある失敗の典型でもある。

コンピュートの選択肢も中心論点だ。仮想マシン、コンテナ、サーバーレスという 3 つの実行形態を、それぞれの利点とともに理解する必要がある。あわせて、コンテナ化、マイクロサービス、Kubernetes、オートスケーリング、ロードバランシング、そしてコスト効率の高いプリエンプティブル VM といった用語も定義レベルで問われる。仮想マシンを動かす Compute Engine の業務価値、そして特殊なレガシーアプリには rehost が向く、という判断も押さえておきたい。

コンピュートの選択肢 — VM・コンテナ・サーバーレスの使い分け

後半の山場が、コンピュート製品の使い分けだ。役割と製品をワンセットで覚えておこう。

サーバーレスは、インフラ管理から解放されて開発に集中できる点が価値だ。Cloud Run、App Engine、Cloud Functions の 3 つが代表製品として挙げられる。コンテナでは、仮想マシンとの違い、マイクロサービスの利点を理解したうえで、GKE と Cloud Run がコンテナ実行の中心になる。Kubernetes はオープンソースのコンテナオーケストレーターであり、GKE はそれを Google がマネージドで提供するサービス、という関係を押さえておくと混乱しない。

API とハイブリッド/マルチクラウドの論点も Section 4 に含まれる。API は、組織が公開 API を通じて新たなビジネス機会を生み出す手段であり、その管理基盤が Apigee API Management だ。そしてハイブリッドクラウドやマルチクラウドを選ぶ理由と、GKE が複数環境をまたぐ単一のコントロールパネルとして機能する点が問われる。GKE は他クラウドでも動くため、ベンダーロックインを避けたい組織にとって、マルチクラウド戦略の要になる。

三つの実行形態の関係は、自由度と運用負荷のトレードオフで整理できる。自分で隅々まで制御したいなら仮想マシン、移植性とスケーラビリティを取りたいならコンテナ、運用の手間を極限まで減らしたいならサーバーレス、という順に管理の負担が軽くなっていく。どれが正解という話ではなく、要件に応じて選ぶ、あるいは組み合わせるのが現実的だ。試験でも、要件文に含まれる「運用の手間を減らしたい」「細かく制御したい」といった言葉が、選ぶべき形態を指し示す手がかりになる。要件語を起点に逆引きする癖をつけておくと、迷いが減る。

Section 5 — 信頼性とセキュリティ（約 17%）

Section 5 は、クラウドセキュリティの基礎と Google のインフラ設計を扱う。出発点は、今日の主要なサイバー脅威とそのビジネスへの影響、クラウドセキュリティとオンプレミスセキュリティの違い、そしてセキュリティモデルにおける管理・コンプライアンス・機密性・完全性・可用性の重要性を理解することだ。これらは AWS のセキュリティドメインで学んだ概念とほぼ重なる。

セキュリティの領域で大切なのは、個々の用語を暗記するより、「なぜ守る必要があるのか」という動機から理解することだ。脅威がもたらす事業への影響を具体的に思い描けると、対策の意味が腑に落ちる。たとえば、情報漏洩は金銭的な損失だけでなく、顧客の信頼そのものを失わせる。だからこそ、機密性・完全性・可用性という三つの軸でデータを守る、という発想が生まれる。こうした因果でつなげて覚えると、断片的な用語が一つの体系として頭に残り、初見の設問にも応用が利くようになる。

Google のインフラ設計思想も大きな論点だ。Google は自社でデータセンターを設計・構築し、専用のサーバーやネットワーク、カスタムのセキュリティハードウェアを使う多層防御（defense-in-depth）を採る。データを守る暗号化は、保存中・転送中といったデータの状態ごとに役割を持つ。認証（authentication）・認可（authorization）・監査（auditing）の 3 つの違い、2 段階認証（2SV）と IAM の利点も問われる。ネットワーク攻撃、とりわけ DDoS への対策としては Google Cloud Armor が挙げられ、クラウドにおけるセキュリティ運用（SecOps）の業務価値も理解しておきたい。

信頼とコンプライアンスの論点も外せない。Google Cloud がどのように顧客の信頼を獲得・維持するか — 信頼の原則、透明性レポートの公開、独立した第三者監査 — が問われる。さらに、データ主権やデータレジデンシーが要件になる理由と、Google Cloud がデータの保管場所を制御できる仕組み、そして Compliance Reports Manager によるコンプライアンス対応も押さえておく。

データ主権という論点は、日本企業にとって特に身近だ。個人情報や規制対象のデータを国外に置けない、という要件は珍しくない。クラウドがデータの保管場所を選べる仕組みを持つことは、こうした規制への対応そのものであり、単なる技術機能ではなく事業継続の前提になる。透明性レポートや第三者監査も、預けたデータが約束どおりに扱われていることを外部の目で保証する仕掛けだと理解すると、信頼にまつわる論点が一本の筋でつながる。

Google のセキュリティの仕組み — 多層防御と暗号化・IAM

セキュリティ領域で確実に得点するために、AWS の知識との対応を整理しておく。考え方はほぼ共通で、製品名が変わるだけだ。

ここでのコツは、製品の細かな設定ではなく、「なぜそれが信頼につながるのか」を語れることだ。たとえば、Google が自社でハードウェアまで設計するのは、サプライチェーン全体を制御してセキュリティを高めるためだ、という文脈で理解すると記憶に残りやすい。暗号化も「データが盗まれても読めない状態を保つ」という目的から逆算すれば、保存中・転送中という状態の区別が自然に頭に入る。

Section 6 — 運用によるスケーリング（約 17%）

Section 6 は、コストと信頼性をどう管理し続けるかという運用の領域だ。3 つの柱で構成される。

1 つ目は財務ガバナンスとコスト管理だ。クラウドの財務ガバナンスのベストプラクティスが、予測可能性とコストの制御をもたらす。リソース階層を使ったアクセス制御、リソースクォータのポリシーと予算しきい値ルールによる消費の制御、そして Cloud Billing Reports によるコストの可視化が問われる。AWS の Organizations やコスト管理ツールを使った経験があれば、考え方はそのまま通用する。

財務ガバナンスの本質は、使った分だけ払うクラウドの自由さが、放っておくとコストの暴走につながるという裏返しのリスクにある。だからこそ、誰がどのリソースを使えるかを階層で制御し、上限や予算のしきい値をあらかじめ決め、使用状況を可視化して早めに手を打つ、という規律が要る。これは技術の話というより、組織としてクラウド支出をどう統制するかという経営の話だ。試験がこの領域に約 17% を割いていること自体が、運用フェーズでのコスト管理の重要性を物語っている。

2 つ目は運用の卓越性と信頼性だ。運用の近代化、回復性・耐障害性・スケーラビリティを備えた設計による高可用性とディザスタリカバリ（DR）、そして DevOps と SRE（サイト信頼性エンジニアリング）の主要用語が問われる。さらに、クラウド導入を支える Google Cloud Customer Care の役割と、サポートケースが処理されるまでの流れも出題対象だ。

信頼性の設計思想として、SRE という考え方も押さえておきたい。これは、システムの信頼性をエンジニアリングの対象として扱い、どこまでの不具合なら許容するかをあらかじめ決めて運用する、という近代的な運用観だ。完璧を目指して歩みを止めるのではなく、適切な信頼性の水準を保ちながら速く改善し続ける。この発想は、高可用性やディザスタリカバリの設計とも地続きで、後半の運用領域を貫く背骨になっている。用語そのものより、この「信頼性を測って管理する」という姿勢を理解しておくと、関連する設問に強くなる。

3 つ目はサステナビリティだ。Google Cloud がサステナビリティと環境負荷削減にどうコミットし、どんな製品で組織のサステナビリティ目標を支援するかが問われる。AWS の認定ではサステナビリティが Well-Architected の柱として登場したが、CDL でも独立した論点として扱われる点が特徴的だ。クラウドの選定理由に環境配慮が含まれる時代を反映している。

AWS の知識で後半 3 領域を攻略する

後半 3 領域は、AWS の運用・セキュリティ経験がそのまま武器になる。役割で対応づけると、新規に覚える量を大きく減らせる。

注意したいのは、AWS の 6R 移行戦略（rehost / replatform / repurchase / refactor / retain / retire）と、GCP の移行用語が完全一致ではない点だ。GCP は move and improve や reimagine といった独自の言い回しを持つ。概念は近いが、用語そのものは公式ガイドの表記で覚え直しておきたい。製品名だけでなく、こうした用語の差分も、後半で取りこぼしを防ぐ鍵になる。

とはいえ、用語の差分に過度に身構える必要はない。大半は AWS で培った運用とセキュリティの感覚がそのまま効く領域だ。新しく覚えるのは Google 固有の言い回しと製品名だけで、その下にある考え方は共通している。だからこそ、対応表を一度作ってしまえば、後半は短い時間で仕上げられる。AWS 経験者にとって、後半はむしろ得点を稼ぎやすいパートだと捉えてよい。

後半 3 領域のつまずきポイント

後半で典型的につまずく 3 点を挙げる。

第一に、コンピュート製品の境界だ。GKE と Cloud Run はどちらもコンテナを動かせるため混同しやすい。GKE は Kubernetes を細かく制御したい場合、Cloud Run はより手軽にコンテナを動かしたい場合、という棲み分けを押さえておく。Cloud Run はサーバーレスとコンテナの両方の文脈で登場する点にも注意したい。

第二に、移行用語の暗記不足だ。rehost、replatform、refactor、reimagine の違いは、順序付けや対応付けの形式で問われやすい。「どこまで手を加えるか」の度合いで一直線に並べて覚えると、迷いにくくなる。

第三に、運用領域の軽視だ。財務ガバナンスや SRE、サステナビリティは、開発寄りの読者には馴染みが薄く、つい後回しにしがちだ。しかし配点は約 17% としっかりある。リソース階層・予算しきい値・Customer Care といった用語を、AWS の対応物に紐づけて早めに潰しておきたい。

加えて、後半は前半以上に「なぜ」を問う設問が多い。なぜマルチクラウドを選ぶのか、なぜ暗号化が信頼につながるのか、なぜ予算のしきい値が必要なのか。単語の意味を覚えるだけでは、こうした理由を問う設問で迷う。各論点について、ひとことで理由を言える状態にしておくと、本番での判断が速くなり、ひねった選択肢にも惑わされにくくなる。

まとめ — 6 領域を制覇して合格圏へ

Cloud Digital Leader の後半 3 領域は、Section 4（インフラとアプリの近代化）・Section 5（信頼性とセキュリティ）・Section 6（運用によるスケーリング）で構成され、合計約 51% と試験の過半を占める。移行用語のグラデーション、Compute Engine・GKE・Cloud Run・Cloud Functions というコンピュートの使い分け、IAM と暗号化と Google Cloud Armor によるセキュリティ、そしてリソース階層と Cloud Billing Reports による運用 — これらを AWS の知識に紐づけて押さえれば、後半は得点源になる。

前半の概念・データ・AI と合わせ、6 領域すべてを一巡したら、あとは模擬問題で穴を可視化し、全領域で 8 割の正答率を安定させるだけだ。Cloud Digital Leader を取得したら、次はもう 1 枚の基礎資格である Generative AI Leader へ進み、GCP の生成 AI を体系的に押さえていきたい。

学習の総仕上げとしては、前半と後半で覚えた 6 領域を一枚の地図に描き直すのが効果的だ。理解・データ・AI・構築・保護・運用という流れで並べると、クラウドがビジネスを変える物語の全体像が見えてくる。あとは模擬問題で領域別の正答率を測り、弱い領域を地図に書き戻しながら埋めていけばよい。公式の試験ガイドと正規の教材だけで合格圏には十分届くため、実試験問題の転載をうたう dumps サイトには手を出さないこと。

参照

• Cloud Digital Leader（公式試験ページ）
• Cloud Digital Leader 試験ガイド（公式 PDF）
• Google Kubernetes Engine（公式）
• Google Cloud Armor（公式）
• Cloud Digital Leader 完全攻略①（2026-06-23 公開）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.