PCNE 模擬試験 2 (シニア向け / 30問 / 75分)
本試験のシナリオ寄り (構成設計・トラブルシュート系) を多めに。模擬試験1 で 80%+ 取れた人向け。
Q1 [シナリオ]
グローバル展開する EC サイト (Shared VPC, GKE, Cloud SQL)。ヘッドエンドに以下が必要:
- グローバル Anycast の HTTPS
- WAF + DDoS 防御
- 静的アセットのキャッシュ
最適な構成は?
A. Global External Application LB + Cloud Armor + Cloud CDN
B. Regional External Application LB × 複数リージョン + Geolocation DNS
C. External Passthrough NLB + Cloud Armor (NW)
D. Internal Application LB cross-region
解答
**A**。Global External Application LB は Anycast + Cloud Armor + Cloud CDN を統合。Q2
オンプレ DC (大阪) + GCP (asia-northeast2) を Dedicated Interconnect で 99.99% SLA 接続。必要な最小構成は?
A. 2 metros (Tokyo + Osaka) × 4 attachments × 2 Cloud Routers × global routing × active/active
B. 1 metro × 2 attachments × 1 Cloud Router
C. 1 metro × 4 attachments × 2 Cloud Routers
D. 2 metros × 2 attachments × 1 Cloud Router
解答
**A**。99.99% 公式要件。Q3
Private cluster GKE で kubectl がコントロールプレーンに届かない。考えられる原因 (複数)?
A. master-authorized-networks に source IP が含まれていない
B. private endpoint なのに external IP が無い VM から接続を試みた
C. Cloud Router の BGP が down
D. master CIDR と subnet が衝突
解答
**A, B**。private endpoint は VPC 内 (or peered, or hybrid) からのみ。authorized networks で IP も絞る。Q4
HA NVA を VPC 間に挿入。トラフィックを Active/Active で分散したい。次に行うべき設定は?
A. NVA を 2 つ起動、それぞれを VPC route の next-hop-instance に登録
B. Internal Passthrough LB を 2 NVA の前に置き、VPC route の next-hop-ilb に登録
C. External LB を NVA の前に
D. Cloud NAT を経由
解答
**B**。Internal Passthrough LB as next-hop が HA NVA の標準。Q5
Cloud Router の advertisement-mode=CUSTOM で、特定 prefix 10.20.0.0/16 を追加広告したい。コマンドは?
A. --advertised-ranges=10.20.0.0/16=internal-services
B. --add-route=10.20.0.0/16
C. --learned-routes=10.20.0.0/16
D. --peer-ranges=10.20.0.0/16
解答
**A**。Custom advertisement で `--advertised-ranges` でカスタム prefix を BGP で広告。Q6
VPC-A の Cloud SQL を VPC-B からプライベート接続したい。最適なアプローチは?
A. Private Service Connect for Cloud SQL
B. VPC Peering + Private Services Access
C. Cloud VPN
D. Cloud NAT
解答
**A**。PSC for Cloud SQL は consumer 側で endpoint を作成、Producer 側の Cloud SQL に到達できる現代的アプローチ。B も従来パターンだが PSC のほうが推奨。Q7
クライアント IP を保持する内部 TCP LB が必要。さらに 複数リージョンから到達可能に。
A. Internal Passthrough NLB + global access
B. Cross-region Internal Proxy NLB
C. Cross-region Internal Application LB
D. Internal Passthrough NLB のみ
解答
**A**。Internal Passthrough NLB は **regional** だが `--allow-global-access` で他リージョンから到達可能。IP/Port を保持する唯一の選択肢。Q8
複数の Cloud Run サービスを 1 つのドメインで URL path で振り分けたい。
A. Global External Application LB + Serverless NEG + URL map
B. Cloud DNS routing policy
C. Cloud CDN
D. Cloud Run domain mapping のみ
解答
**A**。Serverless NEG + LB の URL map で path-based routing。Q9
3 VPC を NCC mesh で接続したが、VPC-A → VPC-B は通るが VPC-A → VPC-C が通らない。確認すべきは?
A. NCC spoke の include-export-ranges 設定
B. VPC-C の Cloud Router BGP
C. Cloud DNS
D. firewall rule (VPC-C で VPC-A の CIDR を許可しているか)
解答
**A, D** が現実的に多い原因。NCC で transitive は機能するが、spoke の export 設定 + 終点 VPC の firewall を見直す。Q10
Cloud Armor で Tor ネットワーク経由のアクセスをブロックしたい。最適な機能は?
A. Threat Intelligence (iplist-tor-exit-nodes)
B. Adaptive Protection
C. Rate Limiting
D. WAF SQLi rule
解答
**A**。Threat Intelligence の preconfigured iplist で Tor exit を deny。Q11
オンプレで使用中の 192.168.0.0/16 と衝突しないように GCP の VPC 設計を行いたい。考えるべきは?
A. GCP 側を別 RFC1918 か non-RFC1918 で設計
B. Cloud NAT を使う
C. NAT 不可
D. Cloud DNS で解決
解答
**A**。設計時に CIDR 衝突を避ける。困難なら Private NAT で吸収。Q12 [シナリオ]
Org 全体に SOC2 監査で「すべての ingress に対し WAF 必須」を強制。Org 管理者として?
A. Hierarchical firewall policy で 80/443 inbound を deny し、特定 LB だけ goto_next で許可。各 LB に Cloud Armor を必須化 (CI/CD policy で強制)。
B. すべての VM に内部 WAF を入れる
C. Cloud DNS で制御
D. VPC Service Controls
解答
**A**。Hierarchical FW + Cloud Armor の組み合わせがガバナンス + ランタイム防御の標準。Q13
HA VPN で 2 つの tunnel が active なのに帯域が頭打ちで ~3 Gbps。改善策は?
A. VPN tunnel を追加し、Cloud Router で ECMP で分散
B. Dedicated Interconnect に切り替え
C. Classic VPN を併用
D. Cloud Armor で rate limit を解除
解答
**A** または **B**。1 tunnel あたり ~3 Gbps が上限。トンネル追加で水平拡張 or Interconnect 移行。Q14
オンプレ DC から GCP *.googleapis.com を private 経路で叩きたい。
A. Cloud DNS で *.googleapis.com → 199.36.153.8/30 に上書き、Cloud Interconnect/VPN 経由でルーティング
B. Cloud NAT を経由
C. 公開インターネット経由
D. External LB
解答
**A**。`private.googleapis.com (199.36.153.8/30)` を Cloud DNS forwarding/policy で上書き、Interconnect 経路で到達。最新は PSC for Google APIs も推奨。Q15
Cloud NGFW Standard 配下で、特定の egress を *.github.com のみに絞りたい。
A. FQDN object を target に dest-fqdns で allow
B. URL filtering (Standard では未対応)
C. Cloud Armor で
D. Cloud NAT で
解答
**A**。NGFW Standard は FQDN object サポート。よりリッチな URL filter は SWP。Q16
Subnet IP 範囲は /22、ノード数 100 (×30 Pod/node) を GKE で運用。Pod range の見積もりは?
A. 30 × 100 = 3,000 Pod → /20 (4,096 IPs) で十分
B. ノード × 110 (per-node default) = 11,000 → /18 推奨
C. /24 で足りる
D. ノード数だけで決まる
解答
**B**。GKE は per-node default で 110 Pod 分の CIDR を予約する (実 Pod 数とは別)。余裕を見て `/18` ~ `/16`。Q17
HA VPN を別 GCP VPC に張る (VPC-A ↔ VPC-B)。BGP セッションは?
A. Cloud Router を両 VPC に作成、お互いの HA VPN gateway を peer external gateway として設定
B. Cloud Router 不要 (static route で OK)
C. Cloud NAT を経由
D. VPC peering で代替
解答
**A**。GCP VPC 同士の HA VPN も BGP 必須。Q18
Cloud DNS for GKE を VPC scope で有効化した。利点は?
A. kube-dns Pod が不要、Cloud DNS が管理
B. VPC 全体から GKE Service を service.namespace.svc.gke.example.com で解決可能
C. クラスタごとの DNS 設定が不要
D. 上記すべて
解答
**D**。Cloud DNS for GKE は運用負荷を大幅に下げる。Q19
Cloud Router で MD5 認証ミスマッチが発生。最初に確認するログは?
A. Cloud Router の BGP session events (BGP_FAILED, auth mismatch)
B. VPC Flow Logs
C. Cloud Logging で Compute Engine の events
D. Cloud NAT logs
解答
**A**。BGP session events に認証エラーが出る。Q20
Packet Mirroring で特定 subnet のトラフィックをコレクター ILB に送る。Mirror 元の subnet と Collector ILB の subnet は?
A. 同じ VPC でないとダメ
B. 異なる VPCでも、VPC Peering 経由ならOK
C. オンプレ subnet も対象に可
D. インターネット経由でも可
解答
**B**。Packet Mirroring は VPC Peering 越しの collector ILB をサポート (mirror dst は別 VPC で OK)。Q21
重要な egress URL allow list として *.googleapis.com, github.com だけ許可、それ以外 deny にしたい。マネージドで実現する最適解は?
A. Secure Web Proxy with allow list
B. Cloud NAT で blockhole
C. VPC firewall rule (CIDR ベース)
D. Cloud Armor
解答
**A**。SWP は L7 URL allow list が公式機能。Q22
VPC-SC で特定 BigQuery dataset を保護したが、Looker (Looker Studio) からのクエリも遮断された。
A. Access Level で Looker Studio の IP 範囲を allow
B. Ingress rule で Looker Studio service account を allow
C. perimeter を削除
D. dry-run mode に切り替え
解答
**B**。VPC-SC は API service principal ベースの ingress rule で例外を許可。dry-run 切替は本番停止につながらない選択。Q23
Cloud NAT で endpoint-independent mapping を有効化する典型ユースケースは?
A. P2P アプリ (e.g., STUN/TURN, VoIP) で外部からの NAT 戻りを許可
B. ポート枯渇対策
C. レイテンシ短縮
D. クライアント IP 保持
解答
**A**。同じ source からは同じ external IP/Port にマップされ、P2P で外部からのリターン送信を許可する。Q24
ある SaaS が複数顧客 VPC に producer から接続を返す (e.g., outbound から producer → consumer) 必要がある。最適な PSC モードは?
A. PSC Endpoint
B. PSC Backend (LB backend)
C. PSC Interface (producer から consumer へ NW を出す)
D. PSC for Google APIs
解答
**C**。PSC Interface は producer 側 NW を consumer VPC 内に interface として出し、producer から consumer リソースへアクセス可能にする (例: data ingest)。Q25
内部 application LB のヘルスチェックが全て fail。VPC-SC, firewall rule は問題なし。次に確認?
A. backend service の health check 設定 (timeout / interval / unhealthy threshold)
B. backend MIG / NEG の listener と path
C. proxy-only subnet が作成されているか (regional/cross-region Internal Application LB)
D. すべて
解答
**D**。proxy-only subnet (`/26` 推奨) が必須なのを忘れがち。Q26
Cloud Armor の edge security policy と backend security policy の違いとして 正しいものは?
A. Edge は CDN cache 前で評価される
B. Backend のみ WAF ルールが使える
C. Edge は L7 inspection 可能
D. Backend のみ rate limit 可能
解答
**A**。Edge security policy は CDN cache ヒット前に評価され、cache poisoning を防げる。WAF/rate limit/bot management は backend policy で full support。Q27
Cloud NGFW Enterprise の L7 検査を有効化する手順として 正しいものは?
A. Endpoint group と Firewall endpoint を作成し、NGFW policy で intercept rule に設定
B. Cloud Armor の edge policy で有効化
C. VPC firewall rule で --enable-l7 フラグ
D. SWP を経由
解答
**A**。NGFW Endpoint group + Firewall endpoint (organization 単位) + intercept rule で構築。Q28
NCC hub に hybrid spoke と producer spoke を組み合わせ、オンプレから複数のマネージドサービスへ private 接続を集約したい。妥当な構成は?
A. Hybrid spoke (VPN) + Producer spoke (PSC) + IP/CIDR filter で route 制御
B. hybrid spoke のみ
C. VPC peering 全張り
D. Cloud NAT 経由
解答
**A**。NCC で hybrid + producer を組み合わせるのが現代の集中アーキテクチャ。Q29
DNSSEC 設定後、dig +dnssec www.example.com で AD bit が立たない。原因は?
A. DS レコードをドメイン Registrar に登録していない
B. Cloud DNS の zone が private
C. DNSSEC は Cloud DNS では使えない
D. Cloud Router 経由していない
解答
**A**。DNSSEC chain of trust に DS レコードが必須。Registrar に DS を登録するまで validation は成立しない。Q30
Cloud Interconnect VLAN attachment を 10G から 50G に切り替えたい。GCP の制約は?
A. 既存 attachment を resize で切り替え可能
B. 50G 単位の attachment は GA で利用可、新規作成して BGP セッションを切り替える
C. Dedicated Interconnect のみ 50G 対応
D. Partner Interconnect は 50G に対応していない
解答
**B**。VLAN attachment の capacity 変更は新規作成が原則 (一部 resize 可)。50G は Partner Interconnect でも対応開始。採点ガイドライン
| 正答数 | 評価 |
|---|---|
| 27+ / 30 (90%+) | 本番予約 OK |
| 23-26 / 30 (76-86%) | 弱点 Section を1日復習 |
| 18-22 / 30 (60-73%) | 模擬試験1 もまだ落としている可能性、用語集 + 学習資料を再読 |
| ≤17 / 30 (≤56%) | ロードマップに戻る |