セクション1：クラウドネイティブアプリの設計

公式試験ガイド 042426版（2026年4月改訂） — Section 1: Designing highly scalable, secure, and reliable cloud-native applications

1.1 高性能なアプリケーションと API の設計

公式ガイドのキー項目は 15項目（プラットフォーム選定、コンテナデプロイ、地理的分散、ロードバランサ、セッションアフィニティ、キャッシュ、API、レート制限、非同期統合、リソース要件、コスト最適化、データレプリケーション、トラフィック分割、オーケストレーション）。1.1 だけでこのセクション内の半数近くを占める想定。

コンピュート 3 種の使い分け（最頻出）

選定フローチャート（暗記推奨）

Cloud Run のオートスケーリング深掘り

Cloud Run のスケーリング挙動は試験でも実務でも最頻出。公式ドキュメントから3つの主要フラグを正しく理解しましょう。

gcloud run deploy my-service \
  --image=us-central1-docker.pkg.dev/PROJECT/repo/app:v1 \
  --min-instances=1 \
  --max-instances=100 \
  --concurrency=80 \
  --region=us-central1

Cloud Run のスケーリングシーケンス

ロードバランサ — 5種類の使い分け

Cloud Run / GKE への LB 接続

非同期 / イベント駆動 — 4種の使い分け

PCD で最頻出のひっかけポイント。各サービスの「本来の役割」をペアで対比して覚えるのが攻略の鍵。

判断軸チートシート（即答できるようにする）

Pub/Sub Exactly-once delivery の詳細（深掘り）

gcloud pubsub subscriptions create my-sub \
  --topic=my-topic \
  --enable-exactly-once-delivery

トラフィック分割（Canary / Blue-Green / A/B）

Cloud Run のリビジョン管理 + traffic splitting は試験必須トピック。

段階的リリースの実装フロー

実装コード（コピペ可）

# Step 1: 新リビジョンを 0% でデプロイ + canary タグ
gcloud run deploy my-service \
  --image=us-central1-docker.pkg.dev/PROJECT/repo/app:v2 \
  --no-traffic --tag=canary --region=us-central1
# → https://canary---my-service-xxx.a.run.app でテスト可能

# Step 2: 10% に振る（タグ指定）
gcloud run services update-traffic my-service \
  --to-tags=canary=10 --region=us-central1

# Step 3: 監視（Cloud Monitoring の error rate, p99 latency を観察）
# 異常があれば↓
gcloud run services update-traffic my-service \
  --to-revisions=LATEST=0 --region=us-central1
# 旧リビジョンに 100% 戻る

# Step 4: 段階的に拡大
gcloud run services update-traffic my-service \
  --to-tags=canary=50 --region=us-central1
gcloud run services update-traffic my-service \
  --to-tags=canary=100 --region=us-central1

1.2 セキュアなアプリケーションの設計

認証パターン — 5シナリオ別の正解

from google.cloud import storage
client = storage.Client()  # ADC で自動認証
bucket = client.bucket("my-bucket")

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-ksa
  namespace: default
  annotations:
    iam.gke.io/gcp-service-account: my-gsa@PROJECT.iam.gserviceaccount.com

gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@PROJECT.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:PROJECT.svc.id.goog[default/my-ksa]"

Workload Identity Federation（WIF）深掘り

2026改訂で 強化された頻出トピック。「Service Account Key を発行しない」現代的なクラウド外連携の標準。

WIF の構成手順（GitHub Actions の例）

# Pool 作成
gcloud iam workload-identity-pools create github-pool \
  --location=global \
  --display-name="GitHub Actions Pool"

# Provider 作成（GitHub の OIDC）
gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location=global \
  --workload-identity-pool=github-pool \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository=='my-org/my-repo'"

# Service Account 借用許可（SA 経由パターン）
gcloud iam service-accounts add-iam-policy-binding \
  my-sa@PROJECT.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"

# またはリソースに直接 IAM（直接アクセスパターン）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/run.developer \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"

# .github/workflows/deploy.yml
name: Deploy to Cloud Run
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write    # ← OIDC トークン要求のため必須

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/providers/github-provider
          service_account: my-sa@PROJECT.iam.gserviceaccount.com
      - run: gcloud run deploy my-service --source=. --region=us-central1

Secret Manager 深掘り

Secret Manager は単なる「環境変数の代替」ではなく、バージョン管理・IAM・CMEK・自動ローテーションを一体化したシークレット基盤。

Secret Manager の3つのアクセスパターン

ランタイム取得の実装例

from google.cloud import secretmanager

def get_secret(secret_id: str, version: str = "latest") -> str:
    client = secretmanager.SecretManagerServiceClient()
    name = f"projects/PROJECT_ID/secrets/{secret_id}/versions/{version}"
    response = client.access_secret_version(request={"name": name})
    return response.payload.data.decode("UTF-8")

# 起動時に1回だけ取得（毎リクエストで取得しない）
DB_PASSWORD = get_secret("db-password")
API_KEY = get_secret("third-party-api-key")

Identity-Aware Proxy（IAP）深掘り

「既存のアプリにコード変更なしで認証を追加する」シナリオの定番解答。

IAP のサポート対象

• Cloud Run（HTTP(S) LB + Serverless NEG 経由）
• GKE（Ingress + BackendConfig で有効化）
• Compute Engine（VM 直接、または MIG + LB）
• App Engine（直接統合）
• オンプレミス（Identity-Aware Proxy connector）

IAM ロール

# ユーザーに IAP アクセスを許可
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/iap.httpsResourceAccessor"

# グループに付与（推奨）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="group:engineers@example.com" \
  --role="roles/iap.httpsResourceAccessor"

# Service Account からの呼び出しを許可（Cloud Tasks 等から）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:caller@project.iam.gserviceaccount.com" \
  --role="roles/iap.httpsResourceAccessor"

バックエンドでの JWT 検証

from google.auth.transport import requests
from google.oauth2 import id_token

EXPECTED_AUDIENCE = "/projects/PROJECT_NUMBER/global/backendServices/BACKEND_ID"

def verify_iap_jwt(request):
    jwt = request.headers.get("X-Goog-IAP-JWT-Assertion")
    if not jwt:
        raise ValueError("Missing IAP JWT")
    payload = id_token.verify_token(
        jwt,
        requests.Request(),
        audience=EXPECTED_AUDIENCE,
        certs_url="https://www.gstatic.com/iap/verify/public_key",
    )
    return payload["email"]  # 認証済みユーザーのメール

Binary Authorization 深掘り

サプライチェーン攻撃対策として 2026改訂で重要度が上昇。attestor / attestation / provenance の関係を正確に理解する。

用語の正確な意味

ポリシーの構成要素

# Binary Authorization Policy (gcloud で apply)
defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
    - projects/PROJECT_ID/attestors/prod-attestor

clusterAdmissionRules:
  "us-central1.prod-cluster":
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
      - projects/PROJECT_ID/attestors/prod-attestor
      - projects/PROJECT_ID/attestors/vulnerability-attestor

# 開発環境は緩く
istioServiceIdentityAdmissionRules:
  "us-central1.dev-cluster":
    evaluationMode: ALWAYS_ALLOW
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG

enforcementMode の3モード

1.3 データの保存とアクセス

ストレージ意思決定ツリー（最頻出）

PCD の選択肢で最も問われる「ストレージの選定」。下のツリーを声に出して即答できるレベルが必要。

各サービスの詳細比較

Signed URL 深掘り

Cloud Storage への 一時的なアクセス権を URL に焼き込む機能。IAM 設定変更なしでアクセス委譲できる。

V2 vs V4 の違い

署名に使う鍵

from google.cloud import storage
from datetime import timedelta

client = storage.Client()
bucket = client.bucket("my-bucket")
blob = bucket.blob("uploads/file.bin")

url = blob.generate_signed_url(
    version="v4",
    expiration=timedelta(minutes=15),
    method="PUT",   # アップロード用
    content_type="application/octet-stream",
)
# url を返す → クライアントが直接 PUT

HTTP メソッド対応

• GET: ダウンロードリンク（限定公開）
• PUT: 単一アップロード（最も多用）
• POST: フォームベースアップロード（Resumable Upload の初期化等）
• DELETE: 削除権限の委譲

ユースケース

🚨 事故ケース集（postmortem 形式）

セクション1 試験戦略まとめ