1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kayu-s(ka yu)

Google Cloud Associate Cloud Engineer

1
Last updated at Posted at 2026-04-18

Google Cloud Associate Cloud Engineer 勉強メモ・試験感想

Udemy の模擬試験（200問）で大事そうなところをメモしたものです。
+自分は Skills で Associate Cloud Engineer Certification 受講しましたが、多分この記事の内容＋ある程度実務経験あれば受かると思います。

※ Skills は月35クレジットまで無料で実際にサービス構築体験(Lab)できるので、実務レベルの知識つけたい人にはおすすめです。（1回のLabに大体5クレジット程度消費）が、超長くて30時間とか多分かかったので、本試験に対してはオーバーキルかなと思います。

Skills のメモも自分用にまとめてたものですが記事にしました。
公式なので情報としては Udemy より正確かと思います。そしてさすがにわかりやすい。
https://qiita.com/kayu-s/items/1557eb61f294e2f2113e

VPC

  • VMの外部IPは「VPCによって透過的にVMの内部IPにマッピングされる」ため、VMのOSには認識されない（ipconfigを実行しても内部IPのみ返却される）

  • DNSは2種類

    • ゾーンDNS
      • ゾーンに分離することで信頼性が保証されるため、GoogleはゾーンDNSを強く推奨
    • グローバルDNS

  • 各インスタンスは内部IPに変換できるhostnameを持つ（hostname = インスタンス名）

  • subnetはカスタムとオートの２択が存在

    • オート
      • サブネットに割り当てられるプライマリ内部 IP アドレスの範囲（CIDR ブロック）を重複しないよう自動的に決定・割り当てされる
      • オンプレミス環境と VPN や専用線で接続する場合や、他の VPC ネットワークとピアリング接続を行う場合、IP アドレス範囲（10.128.0.0/9）が他のネットワークと重複してしまうリスクがある
        • → 要件が複雑な本番環境やハイブリッド クラウド環境を構築する際はカスタムモードを使うことを推奨

  • VPCはグローバルリソースである

    • 同一VPC NW内ならリージョン・ZONEが別でも内部IPでPING可能

  • セカンダリIP範囲（セカンダリCIDRブロック）

    • VPCサブネットにおいてプライマリ範囲とは別に追加設定できるIPアドレス範囲
    • 主にGKEのポッドやサービス、あるいはVMへのエイリアスIP割り当てに利用され、ネットワークの柔軟な拡張を可能にする

Compute Engine

  • ストレージの種類

image.png

  • スナップショット

    • バックアップやZone間の移動などに使用
    • スケジューリング可能
    • 増分で作成される
    • 永続ストレージのみ（ローカルSSDでは使用不可）

  • Confidential VM

    • 機密データの保護に使用
      • 分離: 暗号鍵は、ハイパーバイザからアクセスできない専用ハードウェアによって生成され、そのハードウェア内にのみ配置される
      • アテステーション: VM の ID と状態を検証して、重要なコンポーネントが改ざんされていないことを確認可能

  • Shielded VM

    • 有効化するだけでセキュリティ向上
      • 各インスタンスのブートローダーやOSの改ざん検知、システムの整合性確認
      • APIリクエストなどが自分たちのインスタンスで行われたことの検証
    • 追加課金は無し

  • マシンタイプ

    • E2
      • 小規模ワークロード、TEST
    • Cシリーズ
      • コンピュートエンジン最適化
    • Mシリーズ
      • メモリ最適化
      • GoogleのVMファミリーの中で最大のメモリを提供
      • メモリサイズは1TBから12TBまで対応
      • 最大416個のvCPUを搭載
      • ユースケース
        • SAP HANAなどの大規模インメモリデータベース
        • インメモリデータ分析のワークロード
        • ビジネスクリティカルなインメモリ型データベースアプリケーション
      • メモリサイズ
        • M1: 最大4TB
        • M2: 最大12TB

ゾーンによって利用可能なマシンタイプは異なる

  • インスタンスタイプ

    • プリエンプティブル

      • Spot VMの古いバージョン
      • 最大91%割引
      • 24時間経過したら強制的に停止するなどの制約もある為現在はSpot VMを推奨

    • Spot VM

      • 最大91%割引
      • 低価格で動かせるかわりに停止する可能性がある

    • コンピューティング最適化

      • ゲーミングなどのグラフィカル処理や機械学習
      • Compute Engine 上で 1 コアあたりのパフォーマンスが最も高く、コンピューティング負荷の高いワークロードに最適

  • ソースディスク、イメージ、スナップショット、Cloud Storage に保存されているイメージからカスタム イメージを作成し、それらのイメージを使用して仮想マシン（VM）インスタンスを作成することができる

  • ログ取得方法

    • Ops エージェントまたはCloud Logging エージェントをインスタンスにインストール
      • Cloud Logging エージェントは現在非推奨
    • インスタンスのCPU使用率などのメトリクスはCloud Loggingに自動的に収集されるが、インスタンス内部のOS動作などの詳細ログは Ops エージェントを設定しなければ取得できない

  • 単一テナントノード

    • 同一PJのみがノードで実行され、他のプロジェクトのVMから物理的に隔離される
    • セキュリティやコンプライアンス、ライセンス要件への対応がユースケース

      • このような分離制限が設けられていることで、他の顧客と物理サーバーを共有できないような厳しいコンプライアンス要件やセキュリティポリシーを満たすことができます。また、特定の物理コア数などに紐付くソフトウェアライセンス（Windows ServerのBYOLなど）をGoogle Cloudに持ち込んで使用する際にも、この専用ハードウェア構成が必要になります。

  • マネージド インスタンス グループ（MIG）

    • リージョンマネージドインスタンスグループ
      • 複数ゾーン間でのトラフィック分散が可能
    • ローリングデプロイメントオプション
      • maxSurge
        • 自動更新中にtargetSize を超えて作成できる新しいインスタンスの数を指定
        • 更新速度は上がるが課金増
      • maxUnavailable
        • 自動更新中に常時利用できないインスタンスの数を指定

  • 外部IPはセキュリティ上持たないのがベストプラクティス

    • 外部アクセスが必要な場合は以下で補完
      • CloudNATで外部アクセス可能にする
      • プライベートGoogleアクセスを有効化
    • VM作成時にデフォルトで外部IPは作られるが、組織ポリシーで作られないように設定を変えることも可能

  • プライベートGoogleアクセス

    • subnetレベルで設定可能
    • プライベートIPのみでGoogleの各種APIとサービスにアクセス可能
      image.png

  • gcloud scp

    • 内部的にssh（port:22）を使用してファイル転送

  • DEPRECATED

    • イメージのステータスを非推奨「DEPRECATED」にすると、そのイメージを利用して、引き続き VM の作成に使用できるが、警告が表示されるようになる

  • 永続ディスクの名前はインスタンス名と同じになる

    • 既に同じ名前の永続ディスクがある場合起動に失敗する

Kubernetes

  • Pod

    • 最小単位
    • 内部でコンテナが動く
    • コンテナはpodに対して1 or N

  • ノード

    • VM

  • ノードプール

    • 同じ構成を持つVMのグループ

  • PodのIPアドレスは一時的（エフェメラル）

    • Kubernetesでは、Podは使い捨てのリソースとして扱われ、Podが終了・再作成されると新しいPodには以前とは異なる新しいIPアドレスが動的に割り当てられる

  • Kubernetes Serviceによる抽象化と固定IPの提供

    • Kubernetesの「Service」は、複数のPodの論理的なグループに対する単一の固定されたアクセスポイントを提供するリソース
    • Serviceを作成すると、クラスター内に一意で変動しないIPアドレス（ClusterIP）と、それに紐づくDNS名が割り当てられる

  • トラフィックの自動ルーティングと負荷分散

    • アプリケーションがこのServiceの固定IP（またはDNS名）宛てにリクエストを送信すると、Kubernetesが背後で稼働している正常なPod群に対して自動的にトラフィックをルーティング（負荷分散）する

  • IP割り当て元

    • ノードのIPアドレス: サブネットの「プライマリ IP アドレス範囲」から割り当て
    • PodやServiceのIPアドレス: サブネットの「セカンダリ IP アドレス範囲（エイリアス IP 範囲）」から割り当て

  • kubernetes 内部の設定などは kubectl を使う

  • Auto Scaling 適用コマンド

    • kubectl autoscale rc test1 --min=2 --max=8 --cpu-percent=70

  • 水平 Pod 自動スケーリング（HPA: Horizontal Pod Autoscaler）

    • CPU使用率やメモリ使用率などの指標（メトリクス）に基づいて、デプロイされているPodの数（レプリカ数）を自動的に増減させる

  • 垂直 Pod 自動スケーリング（VPA: Vertical Pod Autoscaler）

    • Podの「数」ではなく、コンテナに割り当てるリソース（CPUやメモリのリクエストと上限）の「サイズ」を自動的に調整（スケールアップ/スケールダウン）

  • 多次元 Pod 自動スケーリング 水平スケーリング（HPA）と垂直スケーリング（VPA）を組み合わせて、Podの数とリソースサイズの両方を多次元的に構成・最適化

  • 異なるスペックのクラスタを構成するには異なるスペックを設定したノードプールを用意する

    • 大容量のリソース（GPUなど）要求を受け入れるための物理的な基盤（ノードプール）がクラスタ内に適切に用意されている必要がある
可用性タイプ コントロールプレーンの可用性 ノードの可用性
シングルゾーンクラスタ 1つのゾーンで単一のコントロールプレーンが実行される。 すべてのノードがコントロールプレーンと同一ゾーンで実行される。
マルチゾーンクラスタ 1つのゾーンで単一のコントロールプレーンが実行される。 リージョン内の複数のゾーンで各ノードが実行される。
リージョンクラスタ リージョン内の複数のゾーンでコントロールプレーンが実行される。 リージョン内の複数のゾーンで各ノードが実行される。

VPC

  • CIDRはサブネットごとに1つ作成することで、サブネット内のIPアドレスの割り当て数やサブネット範囲を規定可能

AWSなどの他のクラウドプロバイダーで用いられるネットワーク概念（インターネットゲートウェイへのルーティングの有無によってサブネットをパブリックやプライベートに分ける手法）に基づいています。 しかし、Google CloudのVPCネットワークの仕様では、サブネット自体に「パブリック」や「プライベート」という設定上の区別は存在しません。Google Cloudにおいて、インスタンスがインターネットと通信できるかどうかは、サブネットの設定ではなく、「インスタンスに外部IPアドレスが付与されているか」と「ファイアウォールルールで許可されているか」によって決定されます

  • 限定公開 Google アクセス

    • External IP を持たないVMやオンプレからGoogle Cloudのリソースにアクセスを可能とする

  • Dedicated Interconnect

    • 物理的な専用線でオンプレからGoogle Cloudに接続
    • Cloud VPNはインターネット回線を利用するので、よりセキュアな要件ならこちらを選択

Cloud Functions (1 gen)

  • トリガーに設定可能なリソース
    • HTTP
    • Cloud Storage
    • Cloud Pub/Sub
    • Cloud Firestore
    • Firebase（Realtime Database、Storage、アナリティクス、Auth）
    • Cloud Logging (Pub/Sub経由でトリガー可能）

Cloud Run

  • 環境変数
    https://docs.cloud.google.com/run/docs/container-contract?hl=ja
    image.png

  • Cloud Run for Anthos

    • Anthos プラットフォームでサーバーレス デベロッパー エクスペリエンスを提供
    • ハイブリッド環境とマルチクラウド環境の両方でワークロードを簡単にデプロイする際に利用する

Cloud Pub/Sub

  • --dead-letter-topic
    • 配信不能メッセージの転送先トピック
  • --ack-deadline
    • publisherが再試行する際の待機時間
  • --min-retry-delay
    • メッセージ送信時の最小待機間隔
  • --max-retry-delay
    • メッセージ送信時の最大待機間隔

Cloud Spanner

  • オートスケーラー
    • CPU 使用率が設定したしきい値を超えた場合や下回った場合に、ノードや処理ユニットの追加または削除を自動的に行う
    • 内部的にはCloud Monitoring と Cloud Functions が動いている
  • BigTableと異なりBigQueryを外部テーブルとして使うことはできない。BigTableと組み合わせる場合は連携クエリを使用することでBigQueryにデータ送信可能

Cloud Storage(GCS)

  • gcloudやgsutilコマンド失敗時は切り捨て型指数バックオフを使用して計算された待機時間後に自動的に再試行する

  • ライフサイクル

    • オブジェクトがライフサイクルルールで指定されたすべての条件を満たしている場合に以下のアクションを実行
      • Delete アクション: オブジェクトが削除される
      • SetStorageClass アクション: オブジェクトのストレージクラスが変更される

  • アクセス権限管理

    • 署名付きURL
      • ユーザーに対してオブジェクトへの一時的な読み取りまたは書き込みのアクセス権を付与
      • URLを共有したすべての人が指定された時間内にオブジェクトにアクセス可能
    • オブジェクトACL
      • ユーザーのIDやIPを指定した制限が可能

  • Classes

    • Nearline: 30日
    • Coldline: 90日
    • Archive: 1年
    • Durable Reduced Availability: Standardと同等だが高額かつSLAが低下（現在は非推奨）

  • CLIによるバケット作成

gcloud mb

ホットスポット
Cloud Storageバケットに保存されるデータは、ファイル名に基づいてクラウドストレージシステム内の特定のサーバーに書き込まれる。この際、類似のファイル名は同じサーバーに格納される。そのため、日付にユーザーIDを付加して似たような名前のファイルを大量にアップロードすると、特定のサーバーにワークロードが集中し、パフォーマンスが低下する恐れがある。

Transfer Appliance

  • オンプレから300TB容量のデータを安全にCloudStorageに移行

Transfer Applianceはデータは改ざん不可能で高性能なデータ転送を可能とします。すべての SSD ストレージはデータの高速書き込みが可能で、CMEK（顧客管理の暗号鍵）と AES 256 暗号化のサポートによって移動中のデータが保護され、業界固有の規制（ISO、SOC、PCI、HIPAA）を遵守できます。

AppEngine

  • min_idle_instances: 常時確保するアイドルインスタンスの最低数

  • 種類

    • スタンダード
      • Sandbox上で任意の言語のアプリを稼働できる
    • フレキシブル
      • VM上で動く
      • Dockerコンテナが使える

  • トラフィック分割

    • Cookie 分割
      • HTTPリクエストヘッダー内の GOOGAPPUID というCookieの値（0〜999の範囲）に基づいてリクエストをルーティング
    • IP 分割
      • 送信者のIPアドレスを0〜999の範囲のハッシュ値に変換し、その数値に基づいてリクエストをルーティング
    • 設定コマンド gcloud app services set-traffic s1 --splits=v2=.5,v1=.5

  • スケーリングは3種類

F: フロントエンドインスタンス
B: バックエンドインスタンス

スケーリング方式 特徴 対応インスタンスクラス 向いているケース 注意点
自動スケーリング リクエスト量に応じてインスタンス数を自動増減。ウォーム状態のインスタンスを維持しやすい F1, F2, F4, F4_1G トラフィック変動が大きく、応答速度を重視したい場合 コストは変動しやすい
基本スケーリング リクエスト時のみインスタンス起動、アイドル時は自動停止 B1, B2, B4, B4_1G, B8 トラフィックが少ない時間帯のコストを抑えたい場合 コールドスタートで遅延が発生する
手動スケーリング 指定した数のインスタンスを常時稼働 B1, B2, B4, B4_1G, B8 常時一定のトラフィックがある、または遅延を避けたい場合 アイドル時もコストがかかる

Cost Billing

  • 予算はプロジェクトごとに作る必要がある

ファイアウォール

  • 階層型ファイアウォールポリシー
    • 組織全体で統一されたファイアウォールを適用可能
    • 組織全体の「ポリシー」の下にプロジェクトごとの「ルール」が存在するイメージ？

Role

  • roles/bigtable.reader
    • テーブルのデータ読み取り
  • roles/bigtable.viewer
    • データベースのメタデータ読み取り

Cloud Asset Inventory

  • Google Cloud 全体のアセット（リソースやポリシー）の状況を一元的に可視化し、分析できるフルマネージドサービス
    • gcloud projects get-iam-policy ではPJレベルの権限しか参照できないが、特定のバケットに付与された権限なども可視化できる

DataStore

BigQuery

  • データセット情報表示コマンド
    • bq show (bq listは無い）

CloudSQL

  • 自動バックアップ
    • 日次で実行される（月次は不可）
    • 最長1年保存できる

Cloud Logging

デフォルトで用意されたログバケット

  • _Required ログバケット

    • 保存されるログ
      • コンプライアンスまたは監査目的に必要なログエントリ
    • 保持期間
      • 400日
      • 変更不可

  • _Default ログバケット

    • 保存されるログ
      • _Requiredに保存されないログ
    • 保持期間
      • 30日
      • 変更可

PAM

  • Privileged Access Manager
  • ワークフローでリクエスターが理由とともに必要な権限をリクエストし、承認者が承認することでJIT（Just In Time）の一時的な権限付与が行われる
  • 一連の操作はCloud Logging と統合され、Auditログが自動で保存される

Infrastructure Manager

  • 構成管理（IaC)

前身のDeployment Managerは2026年3月31日をもってサポートが終了済み

  • 構成変更手順
  1. GitHubなどのGitリポジトリを作成し、Google Cloudリソースを定義したTerraform構成ファイル（.tf）を保存する。Terraformのステートファイル（.tfstate）をCloud Storageバケットに保存する。
  2. Infrastructure Managerで「ブループリント」を作成し、準備したGitリポジトリに接続し、リソース操作に必要な権限を持つサービスアカウントを設定する。
  3. Pull Request（PR）を作成してチームメンバーに変更内容を共有し、レビューを依頼する。
  4. PRが承認されたら、Infrastructure Managerで「デプロイメント」を作成・実行する。

試験結果

GKE, CloudRunなどのコンテナサービス系がかなり多かった印象（半分くらい？）苦手な分野だったのでちょっと焦りました。

各サービスの選定フローや GKE の Autopilot と Standard の違いとかはしっかり抑えないとつらそう。あとはVPC周りも苦手だったが結構出てきた印象。

Udemy で模擬試験 200問解いていたが、それでも知らない単語が結構でてきて10問くらいは消去法で適当に選んだので若干落ちたかと思いました。

あとこれはAWSでもあるあるですが問題文の日本語が微妙...いかようにも解釈できるようなのとか、理解しづらい文章が多い。そしてAWSと違って原文（英語）に切り替えてみれないのでつらかった。

でも全体通すと、「これ勉強しなくても普通（ロジカルに）に考えればわかるんじゃね？」な問題も結構多かったので、まぁアソシエイトレベルとして妥当な難易度って感じでした。多分CloudRunとか実務で触ってる人なら割と簡単に受かると思います🙂

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?