WEB問題集
正解：B
正解の根拠
VPC Flow Logs はサブネット単位で 4 つの主要パラメーター（Aggregation interval、Sample rate、Metadata、Filter）を制御できます。Aggregation interval を長く取りつつ Sample rate を下げる組合せは、ログ量を確実に削減しながら長尺フローの観測には十分な解像度を維持できるため、運用コストとトラブルシュート性のバランスがとれます。
パラメーター比較
| パラメーター | 取り得る値 | 効果 |
|---|---|---|
| Aggregation interval | 5s/30s/1m/5m/10m | 長いほどログ件数減 |
| Sample rate | 0<rate≤1.0 | 低いほど件数比例で減 |
| Metadata | Include all / Exclude all / Custom | 付帯情報の粒度 |
| Filter | CEL 式 | 収集対象を絞込 |
サンプル設定
gcloud compute networks subnets update SUBNET
--region=us-central1
--enable-flow-logs
--logging-aggregation-interval=interval-10-min
--logging-flow-sampling=0.5
--logging-metadata=include-all不正解の理由
- A: 最短 interval と 100% サンプリングではログ量が爆発するため、コスト最適化の意図に反します。
- C: Filter は CEL 式で記述する機能であり、all=true という構文は VPC Flow Logs には存在しません。
- D: Sample rate を 0 にするとログが一切収集されず、長尺フローの観測ができなくなります。
正解：C
正解の根拠
Firewall Rules Logging を有効にしたルールは、当該ルールが連携した接続単位で 5-tuple、ルール優先度、許可/拒否（disposition）、接続元/接続先、リファレンス（self-link）などを含むレコードを Cloud Logging に書き込みます。これにより、特定の通信がどのルールにマッチしたかを追跡できます。
記録項目の主な内容
| フィールド | 内容 |
|---|---|
| jsonPayload.rule_details | ルール ID、priority、direction、disposition |
| jsonPayload.connection | src_ip/dest_ip/src_port/dest_port/protocol |
| jsonPayload.instance | 該当 VM 情報 |
| jsonPayload.remote_location | 地理情報（外部 IP の場合） |
Logs Explorer サンプルクエリ
resource.type="gce_subnetwork"
log_id("compute.googleapis.com/firewall")
jsonPayload.rule_details.action="DENY"不正解の理由
- A: Allow / Deny の双方を、有効化したルール単位で記録します。
- B: ディスク I/O などホスト内メトリクスは Firewall Logging の対象外です。
- D: ルール ID とタイムスタンプだけではなく、接続フローと付帯情報を含む詳細レコードを書き込みます。
正解：C
正解の根拠
Cloud NAT の Logging には ERRORS_ONLY と TRANSLATION_AND_ERRORS の 2 種類があります。TRANSLATION_AND_ERRORS を有効にすると変換成功も含めて記録できる一方、ログ量とコストが増加するため Cloud Logging 側の sink/exclusion で必要なものだけを保持するのが運用上のベストプラクティスです。
ログモード比較
| モード | 記録内容 | 用途 |
|---|---|---|
| ERRORS_ONLY | 変換失敗のみ | 障害検知特化 |
| TRANSLATION_AND_ERRORS | 変換成功+失敗 | 監査・調査 |
| NONE | ログなし | 非推奨 |
有効化コマンド
gcloud compute routers nats update NAT_NAME
--router=ROUTER --region=us-central1
--enable-logging
--log-filter=ALL不正解の理由
- A: NAT 動作の可視化ができなくなり、エラー発生時の原因特定が極めて困難になります。
- B: 本番でも監査のために TRANSLATION_AND_ERRORS が必要な要件があり、一律禁止は過剰です。
- D: Cloud NAT ログは Cloud Logging 上で取り込み量に応じて課金されるため、無制限保持はコスト最適とは言えません。
正解：C
正解の根拠
Logs Explorer のクエリ言語では log_id() 関数でログ種別を、ip_in_net() で CIDR 判定を行います。VPC Flow Logs と Firewall Logging のフィールドを組み合わせることで、宛先 CIDR と DENY 判定の AND 条件を表現できます。
Logs Explorer の主要演算子
| 関数/演算子 | 用途 |
|---|---|
| log_id("...") | logName の短縮指定 |
| ip_in_net(field, cidr) | IP の CIDR メンバ判定 |
| =~ | 正規表現マッチ |
| : | 部分一致 |
クエリ例
log_id("compute.googleapis.com/vpc_flows")
ip_in_net(jsonPayload.connection.dest_ip, "10.20.0.0/16")
jsonPayload.rule_details.action="DENY"不正解の理由
- A: dest_ip=ip("...") という構文は無効で、CIDR 判定には ip_in_net() を使う必要があります。
- B: resource.type やフィールド名が正しい命名規則になっておらず、クエリは構文的に成立しません。
- D: severity は INFO/WARNING/ERROR 等の標準レベルであり、DENY は severity 値ではありません。
正解：D
正解の根拠
Cloud Logging の Logs Router を使えば、特定の logName/フィルターに合致するログを BigQuery、Cloud Storage、Pub/Sub、別の Logging バケットへルーティングできます。BigQuery sink を選び、データセットのパーティション期限を 5 年に設定すれば、クエリ可能な状態で 5 年間保持できます。
主要 sink 先と用途
| Sink 先 | クエリ性 | 適する用途 |
|---|---|---|
| BigQuery | SQL で即時 | 分析・監査 |
| Cloud Storage | 低（外部テーブル要） | コールド保管 |
| Pub/Sub | リアルタイム転送 | 後段システム連携 |
| Logging バケット | Logs Explorer | 分析の継続 |
作成コマンド
gcloud logging sinks create flow-bq
bigquery.googleapis.com/projects/PROJECT/datasets/flow_logs
--log-filter='log_id("compute.googleapis.com/vpc_flows")'不正解の理由
- A: デフォルトバケットを延長しても Logs Explorer の検索範囲が広がるだけで、BigQuery でのクエリ可能性は得られません。
- B: Logs Router は BigQuery を直接 sink 先に指定できるため、Pub/Sub 経由は必須ではありません。
- C: Audit Logs を有効化しても、BigQuery への転送は別途 sink 設定が必要です。