正解：B

Cloud SQL Auth Proxy は IAM 認証 + TLS 暗号化を提供。Cloud Run は --add-cloudsql-instances でインスタンスを宣言すれば、Unix Socket（/cloudsql/PROJECT:REGION:INSTANCE）経由で接続できる。パスワードベース + Public IP は禁忌。

• ❌ A：Public IP + パスワードは漏洩リスク。
• ❌ C：接続情報の保存先と認証方式は別問題。
• ❌ D：VPC SC は境界制御で、接続方式とは無関係。

📖 関連：02_学習資料/04_GCP統合/01_基礎.md § Cloud SQL Auth Proxy

正解：C

GCE / GKE / Cloud Run / Cloud Functions では VM/Pod/Service にサービスアカウントを割り当てれば、ADC が自動でメタデータサーバから取得する。SA Key の配布は不要。

• ❌ A：Metadata 保存も漏洩リスク。標準機能を使う。
• ❌ B：ユーザー認証情報は人間用。サーバー間では SA を使う。
• ❌ D：公開は最終手段で、要件にも反する。

📖 関連：02_学習資料/04_GCP統合/01_基礎.md § Application Default Credentials (ADC)

正解：C

指数バックオフ + ジッターが標準アンサー。Cloud Client Libraries は google.api_core.retry で組み込みサポート。即時リトライは衝突して下流をさらに過負荷にする。

• ❌ A：処理が完了しないまま流れる。データ欠損リスク。
• ❌ B：DDoS 化、下流崩壊。
• ❌ D：一過性の障害でも 1 回しかリトライしないと取りこぼす。

📖 関連：02_学習資料/04_GCP統合/02_応用.md § 指数バックオフ + ジッター

正解：B

サービス境界の遅延は分散トレースで可視化する。**OpenTelemetry（OTel）**で計装、Cloud Trace にエクスポート、**W3C Trace Context（traceparent）**でサービス間を貫通させる。1リクエストの span チェーンが Cloud Trace で 1つの trace として見える。

• ❌ A：printf デバッグでは構造化されず、サービス境界の対応付けができない。
• ❌ C：Profiler は CPU/メモリの hotspot。レイテンシ可視化には Trace。
• ❌ D：メトリクスは集計値で、個別リクエストの追跡には不向き。

📖 関連：02_学習資料/04_GCP統合/02_応用.md § 分散トレースの実装

正解：C

構造化ログに logging.googleapis.com/trace フィールド（値は projects/PROJECT/traces/TRACE_ID）を含めると、Cloud Logging UI から Cloud Trace に直接遷移できる。OTel と組み合わせて自動付与するのが標準。

• ❌ A, B：手動対応付けは煩雑で精度も低い。
• ❌ D：URL は関係ない。

📖 関連：02_学習資料/04_GCP統合/02_応用.md § 構造化ログと Trace の関連付け

正解：B

4xx クライアントエラー（特に 401 / 403 / 404）はリトライしても解決しない。権限不足や URL 誤りはリトライで直らない。例外は 408 Request Timeout と 429 Too Many Requests（バックオフ付きでリトライ可）。

• ❌ A, D：5xx はサーバ側の一過性エラー、リトライ対象。
• ❌ C：429 はレート制限。バックオフで間隔を空けてリトライする。

📖 関連：02_学習資料/04_GCP統合/02_応用.md § リトライ対象のエラーを正しく選ぶ

正解：B

Cloud Client Libraries は 自動でページネーションを扱う。iterator を for で回せば内部で nextPageToken を処理し、メモリには現在のページ分だけ載る。

• ❌ A：100万件すべてをメモリ展開は OOM の原因。
• ❌ C：subprocess は非効率、ライブラリ標準を使うべき。
• ❌ D：データを分割するのは目的に反する。

📖 関連：02_学習資料/04_GCP統合/02_応用.md § ページネーション 3つのスタイル

正解：D

Cloud Profiler は継続的プロファイリングサービス。CPU・メモリ・ロック競合の hotspot を可視化。低オーバーヘッド（< 1%）で本番でも有効化可。

• ❌ A：ログ。プロファイリングではない。
• ❌ B：メトリクスは集計値。hotspot 関数までは分からない。
• ❌ C：Trace は分散レイテンシの可視化。関数単位の CPU 占有は分からない。

📖 関連：02_学習資料/04_GCP統合/01_基礎.md § Cloud Profiler

正解：A, C

• A：ERROR ログ + スタックトレースを Cloud Logging に出すと、Error Reporting が自動で同一スタックトレースをグルーピングする。

• C：通知チャンネルを Error Reporting に設定すれば、新規エラー・回帰エラー時に自動で通知。

• ❌ B：握り潰しは禁忌。デバッグできなくなる。

• ❌ D：Webhook URL のハードコードはシークレット漏洩リスク + 通知設定の一元化に反する。

📖 関連：02_学習資料/04_GCP統合/01_基礎.md § Error Reporting

正解：A, C

• A：Exclusion Filter で DEBUG / health-check の繰り返しログ等を破棄。コスト削減の王道。

• C：Sink で BigQuery（クエリしやすい長期保管）や Cloud Storage（アーカイブ）にエクスポートすれば、Cloud Logging 自体は短期保持で済む。

• ❌ B：可観測性が失われる。本末転倒。

• ❌ D：severity を変えてもデータ量は変わらない。コスト改善にならない。

📖 関連：02_学習資料/04_GCP統合/02_応用.md § ログのコスト最適化