CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. GCP
  3. Google Professional Cloud Network Engineer
Google Professional Cloud Network Engineer

GCP

Google Professional Cloud Network Engineer

230+ 기출 문제 (AI 검증 답안 포함)

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
230+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 Google Professional Cloud Network Engineer 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

시험 도메인

Designing and Planning a Google Cloud VPC Network출제율 24%
Implementing a VPC Network출제율 19%
Configuring Managed Network Services출제율 16%
Configuring and Implementing Hybrid and Multi-Cloud Network Interconnectivity출제율 15%
Managing, Monitoring, and Troubleshooting Network Operations출제율 12%
Configuring, Implementing, and Managing a Cloud Network Security Solution출제율 14%

실전 문제

1
문제 1

Your company operates a single Google Cloud project with three VPC networks (prod, stage, dev) across two regions; you must ensure that API calls to Cloud Bigtable and Artifact Registry are allowed only when requests originate from your corporate egress NAT public IP ranges 203.0.113.0/24 and 198.51.100.0/24, and on-prem systems access Google APIs over the public internet via those NATs; what should you do?

오답입니다. Access Context Manager access levels에 IP 범위를 포함할 수는 있지만, access context policy를 Cloud Bigtable 또는 Artifact Registry에 독립적인 리소스로서 직접 “attach”하지는 않습니다. 이러한 서비스에 대한 enforcement는 access levels를 참조하는 VPC Service Controls service perimeters(및 해당 ingress/egress policies)를 통해 수행됩니다. 또한 “your VPC”를 허용하는 것은 핵심 속성이 NAT public IP인, 문제에서 명시된 on-prem public-internet 경로를 해결하지 못합니다.

정답입니다. 프로젝트에 대해 VPC Service Controls perimeter를 생성하고 Bigtable 및 Artifact Registry를 제한합니다. 그런 다음 회사 NAT public CIDR 203.0.113.0/24 및 198.51.100.0/24만 허용하는 Access Context Manager access level을 구성합니다. 이렇게 하면 Google이 해당 source IP를 관측할 때만 API 호출이 허용되어, on-prem이 해당 NAT를 통해 public internet으로 Google APIs에 액세스한다는 요구사항과 일치합니다.

오답입니다. VPC firewall rules는 VPC interfaces가 있는 리소스(예: Compute Engine VMs, GKE nodes)로의/로부터의 트래픽에 적용되며, Bigtable 및 Artifact Registry 같은 Google-managed service APIs에 대한 액세스를 제어하지 않습니다. Managed services에 대한 API access control은 IAM 및 VPC Service Controls 같은 상위 수준 제어로 처리되며, VPC networks의 packet-level firewall rules로 처리되지 않습니다.

오답입니다. VPC Service Controls perimeters는 “VPC network별”로 생성되지 않으며, 조직 내의 프로젝트(또는 프로젝트 그룹)를 둘러싸도록 정의됩니다. 세 개의 VPC가 단일 프로젝트에 있으므로, 각 VPC에 대해 별도의 perimeter를 의미 있게 만들 수 없습니다. 올바른 접근은 회사 NAT public IP 범위를 허용하는 access level을 포함한, 프로젝트에 대한 단일 perimeter입니다.

문제 분석

핵심 개념: 이 문제는 요청 출처(소스 public IP 범위)를 기준으로 Google-managed services(Cloud Bigtable 및 Artifact Registry)에 대한 액세스를 제한하기 위해 Access Context Manager (ACM) access levels와 함께 VPC Service Controls (VPC-SC)를 테스트합니다. 이는 Google Cloud Architecture Framework의 security pillar(데이터 유출 위험 감소 및 context-aware access 강제)와 정렬된 클라우드 네트워크 보안 제어입니다. 정답이 맞는 이유: Bigtable 및 Artifact Registry에 대한 API 호출을 요청이 회사 egress NAT public IP 범위(203.0.113.0/24 및 198.51.100.0/24)에서 시작될 때만 허용해야 합니다. On-prem 시스템은 해당 NAT를 통해 public internet으로 Google APIs에 도달하므로, service perimeter에서 강제할 수 있는 유일하게 신뢰 가능한 “origin” 신호는 Google이 관측하는 source IP입니다. 프로젝트를 둘러싼 VPC Service Controls service perimeter는 요청이 perimeter 규칙을 만족하지 않으면 지원되는 서비스에 대한 액세스를 제한합니다. 두 NAT public CIDR을 포함하는 ACM access level을 추가하면, 보호된 서비스에 대해 해당 source IP에서만 액세스를 허용하고 다른 IP(재택 사용자, 다른 클라우드, 또는 탈취된 자격 증명 포함)에서의 요청은 거부할 수 있습니다. 주요 기능 / 구성: - 프로젝트를 포함하는 VPC-SC service perimeter를 생성합니다. - restricted services를 추가합니다: bigtable.googleapis.com 및 artifactregistry.googleapis.com. - “ipSubnetworks”로 203.0.113.0/24 및 198.51.100.0/24를 사용하는 ACM access level을 생성하고, perimeter의 ingress policy(또는 모드에 따라 perimeter access level 구성)에서 이를 참조합니다. - VPC-SC는 VPC별이 아니라 프로젝트/폴더/org 리소스 수준에 적용된다는 점을 이해합니다. 흔한 오해: - Firewall rules(VPC firewall)는 Google APIs/managed services 엔드포인트에 대한 액세스를 제어하지 않습니다. 이는 VM NIC로의/로부터의 트래픽 및 특정 네트워크 경로를 제어합니다. - “Allow your VPC”는 public-internet-originated 요청을 허용하는 것과 동일하지 않습니다. On-prem이 public internet을 사용한다면, 관련 제어는 VPC 내부 범위가 아니라 source public IP입니다. - VPC별 perimeter 생성은 지원되거나 적절한 모델이 아닙니다. perimeters는 개별 VPC networks에 매핑되지 않습니다. 시험 팁: - 요구사항이 “특정 네트워크/IP에서만 Google managed services에 대한 액세스를 허용”이라면, VPC Service Controls + Access Context Manager를 떠올리세요. - 트래픽이 public internet을 통해 흐른다면, IP 기반 access levels가 종종 강제 가능한 신호입니다. - 범위를 기억하세요: VPC-SC perimeters는 개별 VPC가 아니라 프로젝트(및 그 상위)를 보호하며, packet filtering이 아니라 service access/유출(exfiltration)에 관한 것입니다.

2
문제 2

Your team manages a VPC named Studio that was created in auto mode for a global video-rendering platform; auto-mode VPCs reserve 10.128.0.0/9 for their subnets across regions. You must create a new VPC named Archive in the same project and connect it to Studio using VPC Network Peering so that internal RFC1918 traffic routes privately end-to-end without NAT; the two VPCs must have non-overlapping IP ranges now and as they scale. How should you configure the Archive VPC?

부정확합니다. Auto-mode VPC는 자동으로 생성되는 리전 subnet에 동일한 사전 정의된 10.128.0.0/9 공간을 사용합니다. Studio가 이미 10.128.0.0/9를 사용하므로 Archive를 auto mode로 생성하면 겹치게 되며, VPC Network Peering은 겹치지 않는 subnet IP 범위를 요구합니다. 이 선택지는 peering의 핵심 사전 요구사항을 충족하지 못하고 안전한 확장도 지원하지 않습니다.

정답입니다. Archive는 custom-mode VPC로 생성해야 하며, 이렇게 하면 Studio의 auto-mode 10.128.0.0/9 공간과 다른 RFC1918 address plan에서 subnet을 생성할 수 있습니다. Google Cloud에서는 VPC 자체에 CIDR를 할당하지 않습니다. 대신 primary 및 선택적 secondary range가 있는 subnet을 생성하며, 이러한 range는 피어링된 네트워크와 겹치지 않아야 합니다. 10.0.0.0/9와 같은 계획에서 분할한 subnet을 사용하면 향후 확장을 위한 여유를 확보하면서 private하고 non-NAT connectivity를 위한 피어링 요구 사항도 충족할 수 있습니다.

부정확합니다. Archive에 10.128.0.0/9를 할당하면 Studio의 auto-mode에서 예약/사용 중인 범위와 직접 겹칩니다. IP 범위가 겹치면 VPC Network Peering을 설정할 수 없거나(또는 routing 기대치를 깨뜨립니다). 신중한 subnetting으로 겹침을 피하려 해도, Studio의 auto-mode가 리전 전반으로 성장하면서 향후 충돌 가능성이 큽니다.

부정확합니다. Default VPC의 이름을 바꾸는 것은 IP 겹침 문제를 해결하지 못하며 운영상 위험합니다. Default VPC는 일반적으로 auto mode이며 10.128.0.0/9 subnet을 가지므로 Studio와 여전히 겹칩니다. 또한 default VPC에 의존하는 것은 subnet 생성이 통제되지 않고 거버넌스가 약해 프로덕션 환경에서는 권장되지 않습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 VPC Network Peering의 사전 요구 사항과 IP 계획을 테스트합니다. VPC Network Peering은 NAT 없이 Google의 backbone을 통해 private connectivity를 제공하지만, 피어링된 VPC의 모든 subnet primary 및 secondary IP range가 서로 겹치지 않아야 합니다. Auto-mode VPC는 10.128.0.0/9 대역에서 regional subnet을 자동으로 생성하므로, 피어링되는 네트워크는 다른 RFC1918 address plan을 사용해야 합니다. 정답인 이유: Studio는 auto-mode VPC이므로 해당 subnet은 10.128.0.0/9에서 생성됩니다. 지금과 미래 모두에서 Archive를 private하게 연결하려면, Archive는 custom-mode VPC로 생성해야 하며, 이렇게 하면 10.0.0.0/9에서 분할한 range와 같이 겹치지 않는 다른 RFC1918 plan에서 subnet을 정의할 수 있습니다. 필요한 subnet을 생성한 후에는 VPC Network Peering을 설정하고 NAT 없이 internal traffic을 private하게 라우팅할 수 있습니다. 주요 기능 / 모범 사례: - VPC Peering은 transitive하지 않으며, 겹치지 않는 subnet primary 및 secondary range가 필요합니다. - Auto-mode VPC는 10.128.0.0/9에서 region당 하나의 subnet을 자동으로 생성하므로, 종종 충돌을 일으킵니다. - Custom-mode VPC를 사용하면 필요한 subnet만 명시적으로 생성하고, 확장 가능하며 겹치지 않는 CIDR를 선택할 수 있습니다. - 좋은 IP 계획은 향후 regional 확장과 secondary range를 위해 충분한 address space를 예약해야 합니다. 일반적인 오해: 흔한 실수 중 하나는 custom-mode VPC 자체에 단일 CIDR block이 할당된다고 생각하는 것입니다. 실제로는 VPC가 subnet을 포함하며, 그 subnet range가 겹치지 않도록 계획되어야 합니다. 또 다른 오해는 두 개의 auto-mode VPC가 별도의 네트워크이므로 피어링할 수 있다고 생각하는 것이지만, 둘 다 10.128.0.0/9를 사용하므로 여전히 충돌합니다. Default network의 이름을 바꾸거나 재사용하는 것도 address overlap을 피하지 못합니다. 시험 팁: - Auto-mode VPC는 자동 생성되는 regional subnet에 10.128.0.0/9를 사용한다는 점을 기억하세요. - 피어링 문제에서는 항상 현재와 미래의 모든 subnet range가 겹치지 않게 유지될 수 있는지 확인하세요. - Production에서는 subnet 생성, governance, 장기적인 확장성에 대한 더 나은 제어를 제공하므로 custom-mode VPC를 선호하세요.

3
문제 3

You are a network engineer at a global streaming company migrating core APIs to Google Cloud. These are the connectivity requirements:

  • On-premises connectivity with at least 20 Gbps from a single metro data center
  • Lowest-latency private access to Google Cloud (target: <5 ms one-way to nearest POP)
  • A centralized Network Engineering team must administer all WAN links and routing New product groups are creating separate Google Cloud projects and require private access to on-prem services from their workloads. You need the most cost-efficient design to connect the data center to Google Cloud while meeting the above requirements. What should you do?

정답입니다. Shared VPC host project에 Interconnect (Dedicated 또는 Partner)와 모든 VLAN attachments를 배치하면 WAN links, Cloud Router/BGP, 그리고 routing policy에 대한 제어를 중앙화하면서도 여러 service projects가 shared VPC subnets와 on-prem routes를 사용할 수 있습니다. 이는 많은 product projects를 지원하는 중앙 Network Engineering 팀에 대해 일반적으로 가장 비용 효율적이고 운영적으로 일관된 접근 방식입니다.

오답입니다. service projects에 VLAN attachments를 생성하면 하이브리드 연결 관리가 분산됩니다. attachments가 Shared VPC network에 연결되더라도, 소유권과 lifecycle management가 product teams 전반에 퍼져 중앙 Network Engineering 팀이 모든 WAN links와 routing을 관리해야 한다는 요구사항과 충돌합니다. 또한 BGP/route advertisement 설정의 불일치 위험을 높이고 troubleshooting 및 governance를 복잡하게 만듭니다.

오답입니다. project별로 VLAN attachments를 갖는 standalone projects는 각 project가 자체 하이브리드 연결 구성요소와 routing을 관리해야 하므로 중앙 집중식 관리 요구사항을 위반합니다. 또한 각 project가 자체 Cloud Router sessions와 attachment configuration이 필요할 수 있어 규모가 커질수록 비용 효율이 떨어지고 운영 오버헤드가 증가하며, 일관된 routing policy enforcement가 더 어려워집니다.

오답입니다. 모든 project에 Interconnects와 VLAN attachments를 모두 배포하는 것은 비용 효율이 가장 낮고 운영 복잡성이 가장 큰 설계입니다. 비싼 연결 리소스를 중복하고 port 및 attachment 수를 증가시키며, 중앙 집중식 routing 제어를 거의 불가능하게 만듭니다. project 수준의 isolation은 물리적 Interconnect 인프라를 복제하는 대신 Shared VPC governance, IAM, 그리고 network segmentation을 통해 달성해야 합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Interconnect (Dedicated 또는 Partner), VLAN attachments, Cloud Router/BGP, 그리고 Shared VPC를 사용하여 중앙 집중식 관리와 함께 멀티 프로젝트 프라이빗 연결을 제공하는 하이브리드 연결 설계를 테스트합니다. 정답이 맞는 이유: 단일 metro data center에서 >=20 Gbps 및 가장 가까운 Google POP까지 편도 지연 시간이 <5 ms라는 요구사항은 VPN보다는 Cloud Interconnect를 강하게 시사합니다. Dedicated Interconnect는 링크당 10/100 Gbps를 제공하며 colocation facility에서 최저 지연의 프라이빗 연결을 위해 설계되었습니다. Partner Interconnect도 provider offerings에 따라 대역폭 요구를 충족할 수 있지만, 엄격한 latency/throughput 목표에는 Dedicated가 일반적인 선택입니다. WAN links와 routing을 중앙에서 관리하면서도 여러 product teams가 별도의 projects를 사용하도록 하려면, Interconnect와 모든 VLAN attachments를 Shared VPC host project에 배치해야 합니다. 이렇게 하면 물리적 연결, VLAN attachments, Cloud Router sessions, route exchange policies의 소유권을 중앙화할 수 있고, service projects는 shared subnets를 소비하면서( IAM 및 firewall policy에 따름) on-prem routes에 자동으로 접근할 수 있습니다. 주요 기능 / 모범 사례: - Shared VPC를 사용해 network administration (host project)과 application ownership (service projects)을 분리하여, Google Cloud Architecture Framework의 중앙 집중식 governance와 위임된 사용 원칙에 부합시킵니다. - host project VPC에서 Interconnect VLAN attachments를 terminate하고 Cloud Router와 BGP를 사용해 routes를 교환합니다. 일관된 routing policy( advertised prefixes, BGP communities, route priority)를 중앙에서 적용합니다. - >=20 Gbps의 경우 HA 모범 사례를 충족하고 single points of failure를 피하기 위해 redundant Interconnect connections(및 redundant VLAN attachments/Cloud Routers)를 배포합니다. region별 VLAN attachments 및 Cloud Router sessions에 대한 quotas/limits도 고려합니다. - 비용 효율성: 하나의 Interconnect 리소스 세트를 여러 projects에서 공유하는 것이 일반적으로 project별로 attachments를 중복하는 것보다 더 저렴하고 운영이 단순합니다. 흔한 오해: 자율성을 위해 각 service project에 VLAN attachments를 생성하는 것이 매력적으로 보일 수 있지만, 이는 routing control을 분산시키고 운영 오버헤드와 비용을 증가시킵니다. 또 다른 오해는 “isolation”을 위해 project마다 별도의 Interconnect가 필요하다는 것인데, isolation은 보통 IAM, firewall policies, 그리고 segmentation( subnets, VPC design)으로 달성하며 물리적 연결을 중복하는 방식이 아닙니다. 시험 팁: 멀티 프로젝트 프라이빗 하이브리드 액세스 + 중앙 집중식 네트워크 제어가 보이면, Shared VPC host project가 하이브리드 연결(Interconnect/VLAN attachments/Cloud Router)을 소유한다고 생각하세요. 단일 metro에서 엄격한 latency와 높은 throughput에는 Dedicated Interconnect를 사용하고, 명시적으로 요구되지 않더라도 redundancy(최소 두 개의 connections와 dual attachments)를 고려해 설계하세요.

4
문제 4

Your company operates a globally available ticketing API for live events that is fronted by a global external HTTP(S) load balancer, and during flash sales traffic spikes to 250,000 requests per minute from more than 40 countries while your security team detects application-layer patterns such as SQL injection, cross-site scripting, and anomalous headers. You must protect the service against these application-level attacks at the edge without changing application code and attach the control to the existing load balancer backend; what should you do?

backend service에서 Cloud CDN을 활성화하면 Google의 edge에서 콘텐츠를 캐시하여 지연 시간을 줄이고 급증 시 backend load를 줄이는 데 도움이 됩니다. 그러나 Cloud CDN은 SQL injection이나 XSS 같은 애플리케이션 계층 공격을 탐지하거나 차단하도록 설계되지 않았습니다. 캐시된 응답을 제공함으로써 간접적으로 origin 노출을 줄일 수는 있지만, 문제에서 요구하는 WAF 시그니처나 헤더/payload 검사 기능을 제공하지 않습니다.

Firewall deny rules(VPC firewall rules)는 VM instances 및 일부 네트워크 엔드포인트로의 트래픽에 대해 Layer 3/4(IP/port/protocol)에서 동작합니다. HTTP 요청을 검사하여 SQLi/XSS 패턴이나 비정상 헤더를 탐지할 수 없고, Cloud Armor policies처럼 global external HTTP(S) load balancer에 “적용”되는 방식도 아닙니다. 이 선택지는 네트워크 firewalling과 L7 애플리케이션 보호를 혼동한 것입니다.

Cloud Armor security policies는 global external HTTP(S) Load Balancer의 backend service에 연결되며 Google의 edge에서 제어를 적용합니다. Cloud Armor WAF는 SQL injection, XSS 및 기타 일반적인 웹 exploit을 탐지하고 차단하기 위한 preconfigured rules를 제공하며, 헤더, 지리적 위치, rate limiting을 위한 custom rules도 제공합니다. edge 보호, app 코드 변경 없음, 기존 load balancer backend와의 통합이라는 모든 제약을 충족합니다.

VPC Service Controls는 데이터 유출 위험을 줄이고 Google APIs를 통해 Google-managed services(예: Cloud Storage, BigQuery)에 대한 접근을 제어하기 위해 service perimeters를 생성합니다. 이는 web application firewall이 아니며 public HTTP(S) endpoint를 SQLi/XSS로부터 보호하지 않습니다. 또한 global external HTTP(S) load balancer는 inbound internet traffic에 대해 VPC Service Controls로 의도된 방식으로 보호되지 않습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud Armor Web Application Firewall (WAF)을 사용하여 global external HTTP(S) Load Balancer에서 애플리케이션 계층(L7) 공격에 대한 edge 보호를 테스트합니다. 또한 load balancing 스택에서 제어가 어디에 연결되는지(backend service)와 애플리케이션 코드 변경을 피해야 한다는 요구사항도 테스트합니다. 정답이 맞는 이유: Google Cloud Armor는 Google Cloud의 global external HTTP(S) Load Balancer에 대한 네이티브 보안 제어로, SQL injection (SQLi), cross-site scripting (XSS), 프로토콜/헤더 이상 징후와 같은 L7 위협을 완화합니다. Cloud Armor security policy(사전 구성된 WAF rules 및/또는 custom match rules 포함)를 생성한 뒤 load balancer의 backend service에 연결합니다. 이렇게 하면 트래픽이 backends에 도달하기 전에 Google의 edge에서 정책이 적용되어, “edge에서 보호”하고 “기존 load balancer backend에 제어를 연결”하며 애플리케이션 코드를 수정하지 않는다는 요구사항을 충족합니다. 주요 기능 / 구성 / 모범 사례: - SQLi/XSS 및 기타 일반적인 exploit에 대해 Cloud Armor WAF preconfigured rules(OWASP Core Rule Set에서 파생된 시그니처)를 사용합니다. - 비정상 헤더, geo 기반 제어, allow/deny lists, rate limiting(플래시 세일 급증에 중요)을 위한 custom rules를 추가합니다. - 먼저 preview mode로 배포하여 false positives를 튜닝한 다음 enforce합니다. - 가시성과 incident response를 위해 Cloud Logging/Monitoring과 통합됩니다. - Google Cloud Architecture Framework의 보안 원칙(방어 심층화, 중앙집중식 정책, edge enforcement)과 정렬됩니다. 흔한 오해: - Cloud CDN은 성능을 개선하고 origin load를 줄일 수 있지만, WAF가 아니며 SQLi/XSS 패턴을 탐지하지 못합니다. - VPC firewall rules는 L3/L4 제어이며 애플리케이션 공격을 위한 HTTP payloads/headers를 검사할 수 없습니다. - VPC Service Controls는 Google-managed services 주변의 데이터 유출 및 API 접근 경계를 위한 것이지, inbound public HTTP(S) endpoints를 보호하기 위한 것이 아닙니다. 시험 팁: “SQL injection/XSS/anomalous headers” + “global external HTTP(S) load balancer” + “edge에서 보호” + “app 변경 없음”을 보면, 기대 정답은 backend service에 연결된 Cloud Armor WAF입니다. 기억하세요: firewall rules = 네트워크 계층; Cloud Armor = HTTP(S) LB를 위한 L7 edge policy; VPC Service Controls = Google APIs/데이터를 위한 service perimeter이지 inbound WAF가 아닙니다.

5
문제 5

Your hardware startup distributes a critical smart door lock firmware globally via Cloud CDN in front of an external HTTP(S) load balancer with a Cloud Storage backend bucket. During a staggered rollout, you discover that the wrong firmware build (2.4.1-debug) was uploaded and has been cached worldwide; the object is served with Cache-Control: max-age=86400, and tens of thousands of devices have already pulled it. Your communications team has instructed customers to re-download the corrected firmware using the same URL (https://updates.example.com/locks/fw.bin). You must ensure that all subsequent downloads fetch the corrected firmware immediately from the same URL across all edge locations. What should you do?

Cloud Armor security policy는 요청을 차단하거나 rate-limit할 수 있지만, 캐시된 객체를 제거하거나 새로 고치지는 못합니다. Cloud CDN 트래픽을 차단하더라도 이후 다운로드가 edge location에서 즉시 수정된 펌웨어를 가져오도록 보장할 수 없고, 단지 접근만 방해하게 됩니다. 로그 검토와 클라이언트 필터링은 오래된 캐시 콘텐츠를 수정하는 것과 무관합니다.

새 URL 경로를 게시하는 것은 변경 불가능한 아티팩트(버전된 파일명)에 대한 일반적으로 강력한 모범 사례이지만, 동일 URL(https://updates.example.com/locks/fw.bin)을 유지해야 한다는 요구사항을 위반합니다. 또한 캐시가 자연 만료되도록 두면 max-age 때문에 최대 86400초가 걸릴 수 있어 “즉시” 요구사항을 충족하지 못합니다.

이 접근이 정답입니다: origin(Cloud Storage backend bucket)의 객체를 교체하고 Cloud CDN에서 캐시된 경로를 invalidate하여 edge location이 오래된 펌웨어를 제거하고 다음 요청에서 수정된 버전을 다시 가져오도록 합니다. 이는 긴 TTL 동작을 직접 해결하며 동일 URL을 유지하면서 빠르게 전 세계 일관성을 보장합니다.

Cloud CDN을 비활성화했다가 다시 활성화하는 것은 운영상 위험한 우회책이며, 모든 edge location에서 즉각적인 캐시 purge를 신뢰성 있게 보장하지 못합니다. 또한 origin으로의 트래픽 급증과 잠재적 다운타임 또는 성능 저하를 유발할 수 있습니다. 지원되고 정밀한 방법은 origin을 업데이트한 뒤 특정 URL/경로에 대해 cache invalidation을 수행하는 것입니다.

문제 분석

핵심 개념: 이 문제는 Cloud Storage backend bucket을 사용하는 외부 HTTP(S) Load Balancer에서 Cloud CDN 캐시 동작과 캐시 무효화를 테스트합니다. Cloud CDN을 사용하면 객체는 HTTP 캐싱 헤더(예: Cache-Control: max-age)에 따라 Google edge location에 캐시됩니다. 정답이 맞는 이유: 펌웨어가 단일 고정 URL에서 제공되고 현재 전 세계적으로 최대 86400초 동안 캐시되어 있으므로, (1) origin 객체를 교체하고 (2) Cloud CDN이 오래된 캐시 버전을 제공하지 않도록 강제로 중단시켜야 합니다. Cloud Storage bucket에 수정된 fw.bin를 업로드하면 origin이 수정됩니다. 그런 다음 해당 URL/경로에 대해 Cloud CDN cache invalidation을 실행하면 edge location 전반에서 캐시된 객체가 제거되어 이후 요청이 즉시 origin에서 다시 가져오게 됩니다(그리고 수정된 콘텐츠가 다시 캐시됨). 이는 요구사항(동일 URL, 전 세계 즉시 반영)을 충족합니다. 주요 기능 / 모범 사례: - Cloud CDN은 Cache-Control을 준수하며, 그렇지 않으면 TTL 만료까지 캐시된 콘텐츠를 제공할 수 있습니다. - Cache invalidation은 캐시된 콘텐츠를 조기에 제거하기 위한 지원되는 메커니즘입니다(/locks/fw.bin 같은 경로 기반 invalidation 또는 필요 시 더 넓은 prefix). - 펌웨어 같은 중요 아티팩트의 경우 버전이 포함된 객체 이름(fw-2.4.2.bin)과 작은 “latest” 포인터 파일을 고려하거나, 롤아웃 중에는 더 짧은 TTL을 사용해 영향 범위를 줄이세요. 이는 Google Cloud Architecture Framework의 신뢰성 원칙(안전한 변경/롤아웃을 위한 설계)과 일치합니다. 흔한 오해: - Cloud CDN을 비활성화해도 모든 edge cache가 즉시 제거되지는 않으며, 운영 리스크를 유발하고 즉각적인 전 세계 일관성을 보장하지 못할 수 있습니다. - 새 URL을 게시하는 것은 일반적인 웹 패턴이지만, 이 시나리오는 동일 URL을 명시적으로 요구합니다. - 보안 정책/로그 검토는 캐시 정확성 문제를 해결하지 못합니다. 시험 팁: “전 세계적으로 잘못된 콘텐츠가 캐시됨” + “동일 URL을 사용해야 함” + “긴 max-age”를 보면, 정석적인 해결책은 다음입니다: origin 객체를 업데이트하고 영향을 받는 경로에 대해 Cloud CDN cache를 invalidate. invalidation은 VPC 라우팅 변경이 아니라 Load Balancer/CDN 구성에 연결된 managed network service 작업임을 기억하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

6
문제 6

In your Google Cloud organization, there are two folders: Analytics and Compliance; you need a scalable, consistent, and low-cost way to enforce the following across all VMs in every project under those folders: • For Analytics projects, TCP port 9000 must always be open for ingress from any source (0.0.0.0/0). • For Compliance projects, all ingress traffic to TCP port 9000 must be denied. What should you do?

정답입니다. 폴더에 연결된 hierarchical firewall policies는 모든 하위 projects 및 VPC networks 전반에 걸쳐 중앙집중식으로 상속되는 강제를 제공합니다. 이는 프로젝트별 구성을 피하고 drift를 방지함으로써 “확장 가능, 일관적, 저비용” 요구사항을 충족합니다. Compliance의 deny는 프로젝트 소유자가 permissive VPC firewall rules를 추가하려고 해도 노출을 차단하는 guardrail로 동작할 수 있습니다. Analytics는 TCP/9000에 대한 일관된 allow를 강제할 수 있습니다.

오답입니다. Shared VPC는 네트워킹을 중앙화할 수 있지만, 해당 host projects를 사용하도록 프로젝트를 마이그레이션/표준화해야 하며, 폴더 아래 모든 프로젝트의 모든 기존 VPCs를 자동으로 커버하지는 않습니다. 또한 운영 복잡성(host/service project 모델, IAM, attachment 관리)을 추가합니다. 문제는 폴더 아래 모든 프로젝트의 모든 VMs에 대한 강제를 요구하며, 이는 hierarchical firewall policies가 더 직접적으로 해결합니다.

오답입니다. 모든 프로젝트의 모든 VPC마다 VPC firewall rules를 생성하는 것은 확장 가능하지 않고 configuration drift 및 인적 오류에 취약합니다. 또한 새 projects/VPCs가 생성될수록 시간이 지남에 따라 운영 비용이 증가합니다. 이 접근은 강력한 guardrails를 제공하지 못합니다. 특히 Compliance에서 “deny되어야 함”은 중앙에서 강제되는 통제를 의미하므로, 프로젝트 소유자가 실수로 규칙을 제거하거나 변경할 수 있는 여지가 있으면 안 됩니다.

오답입니다. Anthos Config Connector는 주로 Kubernetes 기반의 구성 관리 도구로, Google Cloud resources를 선언적으로 생성/관리하는 데 사용됩니다. 이는 조직 전반의 VM firewall enforcement에 가장 적절하거나 저비용인 메커니즘이 아니며, 추가적인 플랫폼 의존성(GKE/Anthos, controllers, lifecycle 관리)을 도입합니다. 설령 사용하더라도 근본적으로 올바른 통제는 여전히 hierarchical firewall policies이므로, 이 선택지는 간접적이고 불필요하게 복잡합니다.

문제 분석

핵심 개념: 이 문제는 Hierarchical Firewall Policies(Google Cloud의 Firewall Policies의 일부)를 사용해 조직 규모의 네트워크 보안 강제를 수행하는지를 평가합니다. Hierarchical firewall policies를 사용하면 조직 또는 폴더 수준에서 allow/deny 규칙을 정의하고, 하위 프로젝트의 모든 VPC networks 및 VM NICs에 일관되게 적용할 수 있어, Google Cloud Architecture Framework의 centralized governance 및 policy-as-code 원칙에 부합합니다. 정답이 맞는 이유: 동일한 포트(TCP 9000)에 대해 상반된 요구사항을 가진 두 개의 폴더가 있습니다. 가장 확장 가능하고 일관적이며 저비용인 접근은 각 폴더에 hierarchical firewall policy를 연결하는 것입니다. 즉, Analytics에는 0.0.0.0/0에서의 TCP/9000 ingress를 allow하도록 보장하는 정책을, Compliance에는 TCP/9000 ingress를 deny하는 정책을 적용합니다. 정책이 폴더 수준에 연결되므로, 해당 폴더 아래에 새 프로젝트나 VPC가 생성되더라도 자동으로 강제가 상속되어 프로젝트별 규칙 관리를 제거하고 운영 오버헤드를 줄입니다. 주요 기능 / 동작 방식: Hierarchical firewall policies는 VPC firewall rules보다 먼저 평가되며 baseline controls를 강제하는 데 사용할 수 있습니다. priorities와 rule actions(allow/deny)를 사용할 수 있고, 필요 시 target service accounts/tags를 통해 광범위하게(모든 instances) 또는 특정 대상으로 타깃팅할 수 있습니다. Compliance의 경우 폴더 수준의 deny rule은 프로젝트 소유자가 permissive VPC firewall rules를 추가하더라도 실수로 노출되는 것을 방지합니다. Analytics의 경우 allow rule이 포트가 일관되게 열려 있도록 보장합니다. 실무에서는 더 상위(organization) 정책이 이를 deny하지 않는지, 그리고 rule priority/order가 올바른지도 확인해야 합니다. 흔한 오해: 많은 사람들이 centralized firewalling에 Shared VPC가 필요하다고 생각하지만, Shared VPC는 네트워크를 중앙화할 뿐 임의의 기존 projects/VPCs 전반에 대한 governance를 제공하는 것은 아닙니다. 또 다른 경우로 프로젝트별 VPC firewall rules에 의존하는데, 이는 확장성이 없고 오류가 발생하기 쉽습니다. Anthos Config Connector는 배포 메커니즘이지 근본적인 강제 프리미티브가 아니며, hierarchical policies를 관리하는 데 사용하지 않는 한 폴더 수준의 guardrails를 본질적으로 제공하지 않습니다. 시험 팁: 요구사항에 “폴더/org 아래의 모든 프로젝트 전반”이 언급되면 hierarchical firewall policies(및/또는 org policy constraints)를 떠올리세요. 요구사항에 “항상” 및 “deny되어야 함”이 포함되면 프로젝트 수준의 override를 방지하는 통제를 우선하세요. 또한 비용/운영 측면을 기억하세요: centralized policies는 administrative toil과 configuration drift를 줄입니다.

7
문제 7

Your company operates a low-latency RTMP streaming service behind a regional external passthrough Network Load Balancer with backends in two managed instance groups located in us-central1 and europe-west1. For licensing reasons, only client networks 203.0.113.0/24 and 198.51.100.64/26 must be able to reach TCP port 1935 of the service from the internet, and all other client IPs must be blocked, while Google Cloud health checks must continue to work (130.211.0.0/22 and 35.191.0.0/16). What should you do?

오답입니다. Access Context Manager policy와 VPC Service Controls perimeter는 데이터 유출 위험을 줄이기 위해 Google Cloud API 및 관리형 service에 대한 접근을 제한하도록 설계되었습니다. 이들은 인터넷에서 외부 passthrough Network Load Balancer VIP로 들어오는 원시 L4 트래픽에 대해 소스 IP allowlist를 강제하지 않습니다. health check와 1935 포트로의 클라이언트 TCP flow는 VPC Service Controls로 제어되지 않습니다.

오답입니다. VPC Service Controls에서 “external load balancer를 protected service로 추가”하여 load balancer의 public IP로 TCP 연결을 열 수 있는 대상을 제한하는 것은 의미 있게 할 수 없습니다. VPC Service Controls는 지원되는 Google service(API endpoint)에 적용되며, passthrough NLB 트래픽에 대한 인터넷 노출 L4 firewall로 동작하지 않습니다.

정답입니다. 외부 passthrough Network Load Balancer의 경우 트래픽이 백엔드 VM으로 전달되므로, 해당 VM의 ingress VPC firewall rule이 어떤 소스가 tcp:1935에 도달할 수 있는지 결정합니다. MIG instance template을 통해 적용된 network tag를 대상으로 하면 인스턴스와 리전에 걸쳐 일관된 강제가 보장됩니다. 130.211.0.0/22 및 35.191.0.0/16을 포함하면 Google health check를 유지하면서, 그 외 모든 소스는 implied deny에 의해 차단됩니다.

오답입니다. VPC firewall rule은 label로 인스턴스를 대상으로 지정할 수 없습니다. firewall rule target은 network tag 또는 service account를 사용해 지정할 수 있으며(VPC 내에서 적용), label은 조직화와 과금에는 유용하지만 firewall enforcement를 위한 유효한 selector가 아니므로 이 옵션은 서술된 대로 구현할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud health check를 유지하면서 외부 passthrough Network Load Balancer (NLB)에 대해 인터넷 클라이언트 소스 IP를 제한하는 방법을 테스트합니다. passthrough NLB의 경우 트래픽이 백엔드 VM NIC로 직접 전달되므로, 백엔드에서의 VPC firewall rule이 클라이언트 소스를 허용/거부하는 주요 제어 수단입니다. 정답이 맞는 이유: 옵션 C는 (network tag를 통해) 백엔드 인스턴스를 대상으로 하는 ingress VPC firewall rule을 사용하여 두 개의 허용된 클라이언트 CIDR과 Google health check 대역(130.211.0.0/22 및 35.191.0.0/16)에서만 TCP/1935를 허용하므로 올바릅니다. VPC firewall rule은 stateful이며 VM의 ingress에서 평가되기 때문에, 명시적으로 허용되지 않은 트래픽은 implied deny(또는 더 낮은 우선순위의 deny rule)에 의해 다른 모든 인터넷 소스를 효과적으로 차단합니다. 또한 firewall rule은 VPC network 수준에서 적용되며 어떤 리전의 인스턴스도 대상으로 할 수 있으므로, 백엔드가 서로 다른 리전(us-central1 및 europe-west1)에 있더라도 이 접근 방식은 동작합니다. 주요 기능 / 구성: - instance template에 network tag(예: rtmp-backend)를 사용하여 모든 MIG 인스턴스가 자동으로 이를 상속하도록 합니다. - 다음 설정으로 ingress allow rule을 생성합니다: - Target: 해당 tag - Protocol/port: tcp:1935 - Source ranges: 203.0.113.0/24, 198.51.100.64/26, 130.211.0.0/22, 35.191.0.0/16 - Priority: 광범위한 allow rule보다 더 높은 우선순위 - 해당 인스턴스에 대해 0.0.0.0/0에서 tcp:1935를 광범위하게 허용하는 다른 firewall rule이 없도록 합니다. 흔한 오해: VPC Service Controls와 Access Context Manager는 “IP allowlisting”에 대해 자주(그리고 잘못) 선택됩니다. VPC Service Controls는 Google 관리형 API/service를 데이터 유출로부터 보호하고 Google API에 대한 접근을 제어하는 것이지, 외부 load balancer VIP로의 원시 TCP/UDP 연결성을 제어하는 것이 아닙니다. 또한 label은 firewall rule target으로 사용할 수 없으며, network tag와 service account만 유효한 target입니다. 시험 팁: - 외부 passthrough NLB의 경우, 백엔드에서의 VPC firewall rule로 클라이언트 접근을 제어합니다. - 소스를 제한할 때는 항상 Google health check IP range를 포함하세요. - 기억: firewall target은 tag 또는 service account( label 아님)이며, VPC Service Controls는 API/service perimeter용이지 L4 인터넷 트래픽 필터링용이 아닙니다.

8
문제 8

A global retail company operates a single Shared VPC (prod-hub) in Google Cloud and connects two on-premises data centers via dual 10-Gbps Dedicated Interconnect attachments terminated in us-east4 for private reachability. Compliance requires that all on-premises access to Cloud Storage must traverse the Interconnect links, but requests to all other Google APIs and services (for example, Pub/Sub and BigQuery) must continue to egress over the public internet through the existing NAT; what should you do?

이 선택지는 Cloud Storage를 다른 모든 Google API 및 서비스와 함께 기본 public endpoint에 그대로 둡니다. 그 결과, 온프레미스의 Cloud Storage 액세스는 Dedicated Interconnect를 통과하는 대신 NAT를 통한 public internet 경로를 계속 사용하게 됩니다. 이는 compliance 요구 사항을 직접적으로 위반합니다. 다른 APIs에 대한 현재 동작은 유지하지만, 문제에서 가장 중요한 조건을 충족하지 못합니다.

이 선택지는 Cloud Storage만 private hybrid 경로를 사용하게 하고 다른 모든 Google APIs 및 서비스는 기존 public internet 경로에 그대로 두어야 한다는 요구 사항에 가장 잘 부합합니다. Google APIs용 Private Service Connect를 사용하면 온프레미스 클라이언트가 Dedicated Interconnect를 통해 도달할 수 있는 private endpoint를 VPC에 노출할 수 있으므로, Cloud Storage에 대한 compliance 요구 사항을 충족합니다. 다른 모든 Google APIs 및 서비스에 대해서는 기본 public domain을 계속 사용하므로, 해당 요청은 여전히 public address로 resolve되고 설명된 대로 기존 NAT를 통해 egress됩니다. 이것이 Cloud Storage를 나머지 Google API 트래픽과 깔끔하게 분리하는 유일한 선택지입니다.

이 선택지는 Cloud Storage를 restricted.googleapis.com으로 보내지만, 동시에 다른 모든 Google APIs 및 서비스를 private.googleapis.com으로도 보내게 됩니다. restricted.googleapis.com과 private.googleapis.com 모두 private connectivity를 통해 도달하도록 설계된 private Google API VIP이므로, 이렇게 하면 다른 API 트래픽도 public NAT 경로에서 벗어나게 됩니다. 이는 Cloud Storage가 아닌 모든 Google API 트래픽은 반드시 public internet을 통해 계속 egress되어야 한다는 명시적 요구 사항과 모순됩니다. 따라서 C는 private access를 과도하게 적용하며 선택적 라우팅 요구 사항을 충족하지 못합니다.

이 선택지는 Cloud Storage를 private.googleapis.com으로 보내고 다른 모든 Google APIs 및 서비스를 restricted.googleapis.com으로 보냅니다. 어느 경우든 두 범주 모두 non-Storage APIs를 public endpoint에 남겨두는 대신 private Google API VIP로 향하게 됩니다. 즉, 다른 Google API 트래픽은 더 이상 NAT를 통해 public internet으로 계속 나가지 않게 되며, 이는 요구 사항을 위반합니다. 또한 더 제한적인 endpoint를 더 넓은 서비스 집합에 적용함으로써 의도된 제어 posture도 뒤바꿉니다.

문제 분석

핵심 개념: 이 문제는 온프레미스에서 오는 Cloud Storage 트래픽만 Dedicated Interconnect를 통해 선택적으로 라우팅하고, 다른 모든 Google APIs 및 서비스는 인터넷을 통해 기존의 일반 public endpoint를 계속 사용하도록 하는 것에 관한 것입니다. 핵심 차이점은 Google APIs에 대한 private access 방식과 서비스를 기본 public DNS 이름으로 그대로 두는 것 사이에 있습니다. 정답인 이유: Cloud Storage는 Google APIs용 Private Service Connect를 사용하여 private하게 액세스할 수 있으므로, 온프레미스 클라이언트가 Interconnect에 연결된 VPC를 통해 이에 도달할 수 있고, 다른 모든 APIs는 기본 public domain에 그대로 남아 있으므로 기존 NAT 경로를 통해 계속 egress됩니다. 주요 기능: Google APIs용 Private Service Connect는 VPC 내부에 private하게 도달 가능한 endpoint를 제공합니다. Interconnect를 통해 연결된 온프레미스 네트워크는 이러한 endpoint에 도달할 수 있습니다. DNS는 Cloud Storage만 private하게 resolve되고 다른 APIs는 public resolution을 유지하도록 구성할 수 있습니다. 흔한 오해: private.googleapis.com 및 restricted.googleapis.com은 많은 Google APIs를 위한 광범위한 VIP 기반 메커니즘이며, 선택지가 두 범주를 해당 VIP로 매핑하도록 명시하는 경우 다른 API는 public으로 유지하면서 오직 하나의 API만 분리하는 방법이 아닙니다. 시험 팁: 요구 사항이 오직 하나의 Google API에 대한 액세스만 private하게 만들고 다른 것들은 public으로 유지하는 것이라면, 여러 서비스에 영향을 주는 광범위한 private API VIP보다는 서비스별 private endpoint 접근 방식과 선택적 DNS를 찾으세요.

9
문제 9

당신은 Google Cloud로 마이그레이션하는 글로벌 리테일 대기업에서 근무하고 있습니다. Cloud 요구 사항: • 일본(도쿄)과 독일(프랑크푸르트)에 위치한 두 개의 on-premises data center가 있으며, 각각 10 Gbps로 프로비저닝된 Dedicated Interconnect를 통해 Cloud region asia-northeast1(주요 HQ) 및 europe-west3(백업)에 연결되어 있습니다. • LATAM 및 Middle East/Africa 전역에 여러 regional branch office가 있습니다. • 지역별 데이터 처리는 europe-west3 및 asia-southeast1에서 이루어져야 합니다. • 중앙집중식 Network Operations 팀이 프로젝트 전반에서 Shared VPC를 관리합니다. 보안 및 규정 준수 팀은 north–south traffic에 대해 L7 URL filtering을 수행할 virtual inline security appliance를 요구하며, 당신은 이 appliance를 asia-northeast1에 배치할 계획입니다. 어떻게 해야 합니까?

정답입니다. Shared VPC Host Project에 2-NIC inline appliance를 배포하는 것은 중앙집중식 Network Operations 팀이 Shared VPC를 관리한다는 요구 사항과 일치합니다. 2개의 VPC와 dual-NIC VM은 명확한 trusted/untrusted 분리와 appliance를 통한 routing 기반 traffic steering을 가능하게 합니다. IP forwarding을 활성화하고 custom route/firewall rule을 사용하는 것은 VM이 inline L7 inspection point로 동작하는 데 필요합니다.

이 옵션은 inspection appliance를 Service Project에 배치하므로 최선의 선택이 아닙니다. 문제는 Network Operations 팀에 의한 중앙집중식 Shared VPC 관리를 강조하고 있기 때문입니다. service-project VM이 Shared VPC subnet에 연결될 수는 있지만, 공유 inline security 기능을 그곳에 호스팅하면 소유권이 분리되고 중앙집중식 거버넌스와의 정렬성이 떨어집니다. 또한 VM이 transit appliance로 동작하는 데 필요한 IP forwarding 활성화도 빠져 있습니다. 거버넌스 불일치와 forwarding 요구 사항 누락 두 가지 이유로 인해 A보다 열등합니다.

오답입니다. 단일 VPC에서 서로 다른 subnet에 2개의 NIC를 사용하는 방식은 일부 appliance 패턴에 사용될 수 있지만, 2개의 별도 VPC만큼 강력한 segmentation 및 강제 transit 경계를 제공하지는 않습니다. 단일 VPC에서는 routing을 통해 우회 경로를 의도치 않게 허용하기 쉬우며, URL filtering appliance를 위한 명확한 north–south “outside/inside” 분리 설계와도 덜 부합합니다.

오답입니다. 이는 Shared VPC가 중앙집중식으로 관리된다는 명시된 요구 사항을 위반하며, Shared VPC 구조도 잘못 설명하고 있습니다. “Shared VPC Service Project”는 VPC network를 소유하지 않으며, Host Project가 소유합니다. service project에 VPC를 생성하는 것은 설명된 Shared VPC 거버넌스 모델을 충족하지 못하고, inline security enforcement point에 기대되는 중앙집중식 제어도 제공하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Shared VPC를 사용하는 Google Cloud에서 north–south traffic 검사를 위한 inline (bump-in-the-wire) virtual security appliance를 구현하는 방법을 테스트합니다. 핵심 개념은 Shared VPC의 소유/관리 경계, multi-NIC VM 기능, 그리고 IP forwarding과 함께 custom route(및 firewall rule)를 사용한 traffic steering입니다. 정답인 이유: 옵션 A가 가장 적절합니다. 중앙집중식 Network Operations 팀이 Shared VPC를 관리하는 환경에서 inline appliance VM을 Shared VPC Host Project에 배치하기 때문입니다. Shared VPC에서 VPC network는 Host Project가 소유하며, service project는 subnet에 리소스를 연결할 수 있지만 network를 소유하지는 않습니다. 여러 프로젝트와 잠재적으로 여러 network segment에 걸쳐 traffic을 안정적으로 유도하고 검사해야 하는 inline appliance의 경우, appliance를 Host Project에 호스팅하면 routing, firewall policy, lifecycle management에 대한 중앙집중식 제어와 잘 부합합니다. 2개의 VPC와 2-NIC VM을 사용하는 것은 “untrusted/external” 및 “trusted/internal” segment를 분리하고 두 network 간 routing을 통해 traffic이 appliance를 통과하도록 강제하는 일반적인 패턴입니다. 주요 기능 / 구성: - Multi-NIC VM: VPC #1의 NIC0와 VPC #2의 NIC1을 사용하여 제어된 transit point를 생성합니다. - VM에서 IP forwarding을 활성화하여 자신이 목적지가 아닌 packet도 전달할 수 있도록 합니다. - Custom route: 관련 north–south prefix(예: default route 또는 특정 on-prem/Internet-bound prefix)를 next hop으로 appliance 쪽으로 유도합니다. - Firewall rule: appliance interface로의/로부터 필요한 flow를 허용하고 우회 경로를 제한합니다. - 운영 모범 사례: 일관된 거버넌스를 위해 routing 및 보안 제어를 Host Project에 유지합니다(Google Cloud Architecture Framework의 중앙집중식 거버넌스 및 보안 원칙과 일치). 일반적인 오해: 많은 사람들은 service project가 Shared VPC subnet에 VM을 생성할 수 있기 때문에 appliance를 service project(옵션 B)에 배치할 수 있다고 생각합니다. 그러나 여러 프로젝트에 걸친 중앙집중식 거버넌스가 필요한 inline inspection point의 경우, Host Project에 배치하면 관리상 마찰을 줄이고 중요한 routing/보안 구성 요소의 소유권 분리를 피할 수 있습니다. 시험 팁: - 기억하세요: Shared VPC network는 Host Project에 존재하고, service project는 subnet을 사용합니다. - Inline appliance에는 일반적으로 다음이 필요합니다: 2개의 NIC, IP forwarding, custom route, 그리고 엄격한 firewalling. - “중앙집중식 NetOps가 Shared VPC를 관리”하는 경우, 문제에서 service-project 소유권을 명시적으로 요구하지 않는 한 공유 network 기능(NAT, inspection, routing hub)은 Host Project에 배포하는 것을 선호하세요.

10
문제 10

Your company operates a third-party edge firewall at a remote warehouse that only supports IKEv1 and does not support BGP. You must establish connectivity from the warehouse network to workloads running in Google Cloud using a policy-based VPN. The on-premises warehouse uses 10.30.20.0/24, 10.30.21.0/24, and 10.30.22.0/24. Your Google Cloud VPC uses 172.25.40.0/24, 172.25.41.0/24, and 172.25.42.0/24. You have already created a Cloud VPN gateway in Google Cloud and need to define the traffic selectors (LOCAL_TS and REMOTE_TS) on the legacy firewall to bring the tunnel up. What should you configure?

오답입니다. 10.30.20.0/22 및 172.25.40.0/22는 /24 3개를 요약하지만, 각 측에 추가 /24(10.30.23.0/24 및 172.25.43.0/24)도 포함합니다. 정책 기반 VPN은 종종 셀렉터가 실제 암호화 도메인과 정확히 일치해야 하므로, 의도치 않은 범위를 추가하면 협상 불일치가 발생하거나 의도하지 않은 트래픽이 암호화될 수 있습니다.

오답입니다. 이 옵션은 온프레미스 방화벽 관점에서 LOCAL_TS와 REMOTE_TS의 의미를 뒤바꿉니다. LOCAL_TS는 방화벽 뒤의 로컬(창고) 네트워크를 나타내야 하고, REMOTE_TS는 원격(Google Cloud VPC) 네트워크를 나타내야 합니다. 이를 바꾸면 제안된 셀렉터가 기대와 일치하지 않아 터널이 수립되지 않는 경우가 흔합니다.

정답입니다. IKEv1 및 BGP 없음 조건의 정책 기반 VPN에서는 관심 트래픽을 명시적으로 정의해야 합니다. LOCAL_TS를 온프레미스 /24 3개로, REMOTE_TS를 VPC /24 3개로 설정하면 추가 주소 공간을 포함하지 않고 필요한 서브넷과 정확히 일치합니다. 이는 Cloud VPN과 레거시 정책 기반 IPsec의 상호운용성 측면에서 가장 호환성이 높고 위험이 가장 낮은 구성입니다.

오답입니다. REMOTE_TS를 0.0.0.0/0로 사용하는 것은 라우트 기반 VPN 설계(종종 동적 라우팅/BGP 포함)의 특징이며, 과도하게 넓은 암호화 도메인을 만듭니다. 정책 기반 VPN 요구사항에서는 Google Cloud가 특정 원격 프리픽스를 기대하므로, 0.0.0.0/0는 거부되거나 구성된 라우트/셀렉터와 매칭되지 않아 실패하거나 의도치 않게 모든 트래픽을 터널로 보낼 수 있습니다.

문제 분석

핵심 개념: 이 문제는 레거시 정책 기반 IPsec VPN(IKEv1, BGP 없음)과의 Classic Cloud VPN 상호운용성을 테스트합니다. 정책 기반 VPN에서는 터널이 트래픽 셀렉터(LOCAL_TS 및 REMOTE_TS)로 정의되며, 암호화가 허용되는 로컬 및 원격 CIDR 범위를 명시적으로 열거합니다. 정답이 맞는 이유: 서드파티 방화벽이 정책 기반이고 BGP를 지원하지 않으므로, 정적 라우팅을 사용하고 관심 트래픽(interesting traffic)을 명시적으로 정의해야 합니다. Google Cloud 정책 기반 VPN은 온프레미스 장비가 양쪽 서브넷과 일치하는 트래픽 셀렉터를 제안할 것을 요구합니다. 여기서 창고에는 /24가 3개(10.30.20.0/24, 10.30.21.0/24, 10.30.22.0/24)이고 VPC에도 /24가 3개(172.25.40.0/24, 172.25.41.0/24, 172.25.42.0/24) 있습니다. 따라서 LOCAL_TS에는 온프레미스 /24 3개를 포함해야 하고 REMOTE_TS에는 VPC /24 3개를 포함해야 합니다. 이는 Cloud VPN이 셀렉터를 검증하는 방식과 일치하며, 협상된 IPsec SA가 의도한 프리픽스를 정확히 커버하도록 보장합니다. 주요 기능 / 모범 사례: - 정책 기반 VPN은 트래픽 셀렉터를 사용하고, 라우트 기반 VPN은 0.0.0.0/0 셀렉터를 사용하며 라우팅(종종 HA VPN의 BGP)에 의존합니다. - 정적 라우팅을 사용할 때는 양쪽에 대응하는 정적 라우트가 존재하도록 해야 합니다(Google Cloud의 Cloud VPN 정적 라우트, 방화벽의 정적 라우트/정책). - 셀렉터는 필요한 만큼 구체적으로 유지하고, 의도치 않게 트래픽을 암호화하거나 불일치로 실패할 수 있는 과도하게 넓은 셀렉터는 피하십시오. 흔한 오해: - /22로 요약하면 편리해 보이지만 실제로 사용하지 않는 추가 주소 공간(예: 10.30.23.0/24 및 172.25.43.0/24)을 포함합니다. 많은 정책 기반 구현은 정확한 일치를 요구하므로, 추가 범위는 셀렉터 불일치를 유발하거나 의도치 않은 암호화 도메인을 만들 수 있습니다. - LOCAL_TS와 REMOTE_TS를 바꾸는 것은 흔한 실수입니다. LOCAL_TS는 항상 로컬(방화벽 측) 서브넷입니다. - 0.0.0.0/0 사용은 라우트 기반 VPN에서 일반적이며 정책 기반에서는 거부되거나 과도하게 허용적인 암호화 도메인을 만들 수 있습니다. 시험 팁: “IKEv1”, “no BGP”, “policy-based VPN”을 보면 트래픽 셀렉터에 명시적인 서브넷 쌍과 정적 라우트를 떠올리십시오. LOCAL_TS는 온프레미스 프리픽스에, REMOTE_TS는 VPC 프리픽스에 대응하도록 하고, 양쪽이 더 넓은 CIDR을 수용하고 의도한다는 확신이 없다면 요약은 피하십시오.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

11
문제 11

Your retail company has set up a single IPSec Cloud VPN tunnel from its Google Cloud VPC to a logistics partner’s on-premises device; the VPN Tunnel Status shows Established, but the Cloud Router’s BGP Session Status shows BGP not configured. The partner provided these BGP parameters: • Partner BGP address: 169.254.22.1/30 • Partner ASN: 65044 • Google Cloud BGP address: 169.254.22.2 • Google Cloud ASN: 65001 • MD5 Authentication: Disabled You have already associated the Cloud Router with the Cloud VPN tunnel. Based on the partner’s settings, how should you configure the local BGP session on Google Cloud?

Peer ASN을 65001로 설정했기 때문에 오답입니다. 이는 파트너의 ASN이 아니라 Google Cloud의 ASN입니다. Cloud Router BGP peer 구성에서 “Peer ASN”은 원격 ASN(여기서는 65044)이어야 합니다. IP와 MD5 설정은 그 외에는 정렬되어 있어 이 옵션이 그럴듯해 보일 수 있지만, ASN 불일치로 인해 올바른 eBGP session이 성립되지 않습니다.

local과 peer BGP IP 주소를 서로 바꿨기 때문에 오답입니다. 제공된 파라미터에 따르면 Google의 local BGP IP는 169.254.22.2이고 파트너의 peer IP는 169.254.22.1이어야 합니다. 이 주소들을 반대로 설정하면 IPSec 터널이 up이어도 BGP neighbor establishment가 실패합니다.

이것이 정답인 이유는 파트너 ASN 65044를 Peer ASN으로 사용하기 때문이며, 이는 Cloud Router에서 eBGP를 구성하는 정확한 방식입니다. 또한 Google Cloud의 BGP address 169.254.22.2를 Local BGP IP로, 파트너의 address 169.254.22.1을 Peer BGP IP로 할당하여 문제에서 제공된 값과 일치합니다. MD5 authentication은 disabled로 설정되어 있으며, 이는 파트너 구성과 일치하고 session을 성공적으로 설정하는 데 필요합니다. route priority가 100으로 표시되어 있지만, 이 값이 이 option이 정답인 이유는 아닙니다. 중요한 일치는 ASN, IP addressing, 그리고 MD5 설정입니다.

이 option은 파트너가 MD5 authentication이 disabled라고 명시했음에도 MD5 authentication을 활성화하기 때문에 오답입니다. BGP authentication 설정은 양쪽에서 일치해야 하며, 불일치가 있으면 IPSec tunnel 자체가 활성화되어 있더라도 BGP session이 설정되지 않습니다. local 및 peer IP와 peer ASN은 그 외에는 일치하므로 그럴듯한 distractor가 됩니다. route priority 값 1000은 여기서 핵심 문제가 아니며, MD5 불일치만으로도 구성이 실패하기에 충분합니다.

문제 분석

핵심 개념: 이 문제는 IPSec tunnel이 이미 설정된 후 Cloud VPN tunnel에 대해 Cloud Router BGP peer를 어떻게 구성하는지 테스트합니다. 설정된 VPN tunnel은 암호화된 전송이 활성화되었음을 확인할 뿐이며, 동적 route 교환은 여전히 Cloud Router에서 올바르게 구성된 BGP session이 필요합니다. 정답인 이유: 파트너가 /30 link-local peering subnet에 대한 원격 BGP 매개변수를 제공했습니다. Google Cloud에서는 BGP peer가 파트너 ASN을 Peer ASN으로 사용해야 하고, Google Cloud의 BGP address를 Local BGP IP로, 파트너의 BGP address를 Peer BGP IP로 사용해야 하며, MD5 authentication은 파트너 설정인 disabled와 일치해야 합니다. Option C만 이러한 필수 값과 일치합니다. 주요 기능 / 구성 모범 사례: - Cloud Router는 로컬에서 router 자체 ASN을 사용하고 원격 device의 ASN을 peer ASN으로 사용합니다. - local 및 peer BGP IP는 BGP link의 각 측에 할당된 정확한 address와 일치해야 합니다. - MD5 authentication은 양쪽에서 동일하게 구성되어야 하며, 그렇지 않으면 BGP session이 실패합니다. - advertised route priority는 일부 시나리오에서 path preference에 영향을 주지만, 이 문제에서 BGP session이 올바르게 구성되었는지를 결정하는 요소는 아닙니다. 흔한 오해: - Cloud Router ASN과 peer ASN을 혼동하는 것. router ASN은 Cloud Router 자체에 구성되며, BGP session은 파트너 ASN을 peer로 사용합니다. - VPN tunnel이 설정되었으므로 routing이 이미 작동해야 한다고 가정하는 것. BGP peer가 없으면 동적 route는 교환되지 않습니다. - local과 peer BGP IP를 서로 바꾸는 것. 두 address가 같은 /30 범위에 있더라도 각 측은 자신에게 특정하게 할당된 address를 사용해야 합니다. 시험 팁: - Cloud Router BGP 문제에서는 제공된 각 매개변수를 직접 매핑하세요: remote ASN은 Peer ASN, Google IP는 Local BGP IP, partner IP는 Peer BGP IP입니다. - 상태에 “BGP not configured”라고 표시되면, 문제는 보통 IPSec 실패가 아니라 누락되었거나 잘못된 BGP peer 설정입니다. - 문제가 path preference나 route selection에 대해 명시적으로 묻지 않는 한, 관련 없는 값을 바꾸는 distractor는 무시하세요.

12
문제 12

Your security team now requires capturing packet payloads for all egress traffic originating from Compute Engine instances in region europe-west4 within VPC prod-vpc, limited to subnets app-euw4 (10.70.0.0/20) and jobs-euw4 (10.70.16.0/20). You have deployed an IDS virtual appliance as a regional managed instance group with 3 VMs (ids-mig) in europe-west4. You must integrate the IDS so it receives mirrored packets for egress traffic only and production routing remains unchanged. What should you do?

Firewall rules logging records는 Cloud Logging에 allow/deny 결정과 일부 연결 메타데이터를 기록하지만, 전체 패킷이나 페이로드를 캡처하지는 않습니다. IDS로 forwarding logs를 보내더라도 deep packet inspection과 signature-based detection에 필요한 raw traffic을 제공하지 못합니다. 또한 로그 처리 지연을 유발하며, 명시적인 “packet payloads” 요구사항을 충족하지 못합니다.

VPC Flow Logs는 네트워크 flow 메타데이터(예: src/dst IP, ports, protocol, bytes, packets, start/end time)를 캡처하며, 가시성과 트러블슈팅에 유용하지만 페이로드 검사용은 아닙니다. Logging sink와 egress 필터링을 사용하더라도 패킷 내용을 재구성할 수 없습니다. 이는 페이로드가 포함된 미러링 패킷에 대한 IDS 요구사항을 충족하지 못합니다.

Packet Mirroring은 프로덕션 라우팅을 변경하지 않고 보안 appliances로 패킷(페이로드 포함) 복사본을 전송하도록 설계되었습니다. packet mirroring collector는 regional internal TCP/UDP(passthrough) load balancer를 사용해 구현되며, scale과 HA를 위해 ids-mig 같은 managed instance group을 대상으로 지정할 수 있습니다. europe-west4에서 direction=EGRESS로 regional policy를 구성하고 두 subnets를 선택하는 것은 요구사항과 정확히 일치합니다.

internal HTTP(S) load balancer는 proxy 기반 Layer 7 서비스이며 Packet Mirroring collector로 사용되지 않습니다. Packet Mirroring collectors는 L7 termination이나 프로토콜 제약 없이 미러링된 패킷이 전달되도록 internal passthrough Network Load Balancer(TCP/UDP)가 필요합니다. 또한 “HTTP(S)”는 subnets에서 발생하는 임의의 egress 트래픽(비-HTTP)을 커버하지 못합니다.

문제 분석

핵심 개념: 이 문제는 out-of-band 네트워크 보안 모니터링을 위한 Google Cloud Packet Mirroring을 테스트합니다. Packet Mirroring은 선택한 소스(VM NICs, instance tags, 또는 subnets)에서 패킷(페이로드 포함)을 collector로 복사하며, 라우팅을 변경하거나 inline appliances를 요구하지 않습니다. 이는 inline 의존성을 피함으로써 신뢰성을 보존하면서, 중앙집중식 가시성과 탐지를 강조하는 Google Cloud Architecture Framework 보안 원칙과 일치합니다. 정답이 맞는 이유: 요구사항은 europe-west4의 Compute Engine instances에서 시작되는 egress 트래픽에 대해 패킷 페이로드를 캡처하고, 두 개의 subnets로 범위를 제한하며, 미러링된 패킷을 IDS MIG로 전송하되, 프로덕션 라우팅은 변경하지 않는 것입니다. Packet Mirroring은 메타데이터 로그가 아니라 전체 패킷 복사본(페이로드)을 제공하는 유일한 옵션입니다. Google Cloud에서 미러링 트래픽은 Packet Mirroring collector로 전달되며, 이는 regional internal passthrough Network Load Balancer(internal TCP/UDP load balancer)를 사용해 구현됩니다. 그런 다음 europe-west4에 regional packet mirroring policy를 구성하고, 두 subnets를 mirrored sources로 선택하며, direction=EGRESS로 설정해 outbound 트래픽만 미러링합니다. 주요 기능/구성 포인트: - 범위: Packet mirroring policy는 regional이며, sources와 collector는 동일한 region(europe-west4)에 있어야 합니다. - Sources: coverage를 제한하기 위해 subnets app-euw4와 jobs-euw4를 선택합니다. - Direction: “egress only” 요구사항을 충족하기 위해 EGRESS로 설정합니다. - Collector: regional internal TCP/UDP load balancer(passthrough)를 사용해 ids-mig instance group을 대상으로 지정하여 3개의 IDS VMs에 트래픽이 분산되도록 합니다. - 라우팅 변경 없음: mirroring은 복사본이므로, forwarding 결정에 영향을 주거나 프로덕션 플로우에 지연을 추가하지 않습니다. 흔한 오해: Flow Logs와 firewall logs는 종종 packet capture와 혼동됩니다. 이들은 메타데이터(5-tuple, bytes, actions)를 제공하지만 페이로드는 제공하지 않으므로 “packet payloads”를 충족할 수 없습니다. 또한 HTTP(S) load balancers는 proxy 기반 L7 서비스이며 packet mirroring collectors로 사용되지 않습니다. 시험 팁: “payload,” “IDS,” “out-of-band,” “routing remains unchanged”를 보면 Packet Mirroring을 떠올리세요. collectors는 internal passthrough(TCP/UDP) load balancing을 사용하고, policies는 regional이며 direction(INGRESS/EGRESS/BOTH)을 선택할 수 있다는 점을 기억하세요. 또한 quotas/cost도 고려하세요. 미러링 트래픽은 대용량이 될 수 있고 과금될 수 있으므로, 비용과 용량을 제어하기 위해 mirroring 범위를 엄격히 제한(subnets, direction, optional filters)하세요.

13
문제 13

Your company runs two microservices in a regional GKE cluster (name: prod-net, region: us-central1) exposed through a single external HTTP(S) Load Balancer configured by a Kubernetes Ingress; requests to shop.acmepuzzles.com/orders and shop.acmepuzzles.com/insights load correctly, but going to https://shop.acmepuzzles.com/ returns an HTTP 404 from the load balancer, and you must fix this without changing DNS or creating a new load balancer; what should you do?

오답입니다. Kubernetes Service에는 HTTP path rule이 포함되지 않습니다. Service는 주로 L4 construct(ClusterIP/NodePort/LoadBalancer)로서 Pod를 선택하고 port를 노출합니다. Service에 “*” path rule을 추가하는 것은 Google Cloud HTTP(S) Load Balancer URL map에 영향을 주는 유효하거나 효과적인 방법이 아닙니다. Path 기반 routing은 Service가 아니라 Ingress resource에서 구성합니다.

오답입니다. Routing을 변경하기에 Ingress가 올바른 위치인 것은 맞지만, “*”에 대한 path rule을 추가하는 것은 올바르거나 이식 가능한 접근이 아닙니다. Kubernetes Ingress path matching은 일반적으로 Prefix 또는 Exact이며, “*”는 표준 path pattern이 아니어서 허용되지 않거나 예기치 않게 동작할 수 있습니다. 매칭되지 않는 path에 대한 깔끔하고 지원되는 해결책은 default backend를 사용하는 것(또는 명시적으로 “/” prefix rule을 추가하는 것)입니다.

정답입니다. Ingress에서 spec.defaultBackend를 정의하면 load balancer URL map의 default service가 설정됩니다. 이렇게 하면 어떤 host/path rule과도 매칭되지 않는 요청(별도로 매칭되지 않는 경우 bare domain root 포함)이 load balancer의 기본 404를 반환하는 대신 의도한 base Service로 라우팅됩니다. 이 변경은 Ingress가 생성한 기존 GCLB를 업데이트하므로 제약 조건을 충족합니다.

오답입니다. Service는 Ingress 스타일의 default backend를 정의하는 것을 지원하지 않습니다. Default backend 개념은 Ingress/HTTP(S) load balancing 계층(URL map)에 속합니다. Service YAML을 편집해도 external HTTP(S) Load Balancer가 path를 매칭하는 방식이나 어떤 path rule도 매칭되지 않을 때의 동작을 바꿀 수 없습니다. 이를 변경할 수 있는 것은 Ingress 구성뿐입니다.

문제 분석

핵심 개념: 이 문제는 GKE에서 Kubernetes Ingress가 Google Cloud external HTTP(S) Load Balancer (GCLB)를 어떻게 프로그래밍하는지, 그리고 매칭되지 않는 URL path가 어떻게 처리되는지를 테스트합니다. GKE Ingress에서 path rule은 backend Service에 매핑됩니다. 요청이 어떤 host/path rule과도 매칭되지 않으면, load balancer는 URL map이 생성한 404를 반환합니다(여러분의 Pod가 반환하는 것이 아님). 정답이 맞는 이유: /orders와 /insights는 동작하므로, Ingress에 해당 prefix에 대한 명시적 path rule이 있습니다. root path “/” (https://shop.acmepuzzles.com/)는 어떤 rule과도 매칭되지 않기 때문에, GCLB URL map에는 매칭되는 path matcher가 없고 기본 404를 반환합니다. 올바른 해결책은 Ingress에 default backend를 구성하여, 특정 path rule과 매칭되지 않는 모든 요청(별도로 정의되지 않았다면 “/” 포함)이 의도한 “base” Service로 라우팅되도록 하는 것입니다. 이는 제약 조건( DNS 변경 없음, 새로운 load balancer 없음)을 만족합니다. 즉, 기존 URL map을 다시 프로그래밍하는 Ingress 업데이트만 필요합니다. 주요 기능 / 구성: Kubernetes Ingress (networking.k8s.io/v1)에서는 spec.defaultBackend(또는 이전 API에서는 spec.backend)를 Service로 설정할 수 있습니다. 이는 URL map의 defaultService가 됩니다. 예기치 않은 404를 방지하고, 통제된 landing page 또는 error handler를 제공하기 위해 default backend를 정의하는 것은 best practice입니다. 이는 Google Cloud Architecture Framework의 operational excellence(예측 가능한 routing과 명확한 failure mode)와도 일치합니다. 흔한 오해: 많은 사람들이 “*” 같은 wildcard path를 Kubernetes Ingress에 추가하는 것이 유효하다고 가정합니다. 실제로 Kubernetes path matching은 Prefix/Exact(및 ImplementationSpecific) 기반이며, “*”는 이식 가능하고 표준 기반의 path가 아닙니다. 또 다른 오해는 Service가 HTTP routing을 제어한다는 것입니다. Service는 L4 abstraction이며 URL path를 정의하지 않습니다—Ingress가 정의합니다. 시험 팁: 일부 path는 동작하는데 “404 from the load balancer”가 보이면, URL map path matching과 Ingress rule을 떠올리세요. 해결은 보통 “/” prefix rule을 추가하거나 spec.defaultBackend를 정의하는 것입니다. 또한 DNS는 forwarding rule IP를 가리킨다는 점을 기억하세요. 새로운 load balancer 없이 routing을 바꾸려면, Service를 수정하기보다 Ingress를 업데이트하여(URL map을 업데이트) 처리하는 경우가 일반적입니다.

14
문제 14

여러 지역 spoke VPC를 보유한 미디어 회사를 위해 Google Cloud에서 transit-hub 네트워크를 구현하고 있습니다. hub에는 VIP 172.31.10.8을 사용하는 regional internal passthrough Network Load Balancer 뒤에 high availability로 구성된 서드파티 firewall 한 쌍이 있으며, 모든 spoke는 이미 hub와 peering되어 있습니다. 요구 사항은 모든 spoke가 모든 인터넷 egress(0.0.0.0/0)에 대해 hub firewall을 사용해야 하고, 동시에 hub의 firewall 인스턴스만 hub의 default internet gateway를 사용할 수 있어야 한다는 것입니다. 이러한 요구 사항을 충족하고 high availability를 유지하려면 무엇을 구성해야 합니까?

이 옵션은 spoke 자체의 default internet gateway route를 그대로 남겨두기 때문에 불완전합니다. Google Cloud에서는 spoke VPC의 local route가 VPC peering을 통해 학습된 route보다 우선되므로, hub에서 import된 0.0.0.0/0는 실제 인터넷 egress에 사용되지 않습니다. 그 결과 spoke workload는 hub firewall을 통과하는 대신 계속 인터넷으로 직접 나가게 됩니다. 이는 모든 spoke가 모든 인터넷 대상 트래픽에 대해 hub firewall을 사용해야 한다는 명시적 요구 사항을 위반합니다.

이 옵션은 hub의 0.0.0.0/0 route에 대한 next hop으로 regional internal passthrough Network Load Balancer VIP를 올바르게 사용하므로 firewall 쌍 전반에 걸쳐 high availability를 유지합니다. 또한 제한 없는 hub default internet gateway route를 tag 범위 route로 대체하여, inspection 이후 firewall 인스턴스만 트래픽을 인터넷으로 직접 전송할 수 있도록 합니다. hub에서 custom routes를 export하고 spoke로 import하면 중앙집중식 default route가 VPC peering을 통해 전파될 수 있습니다. 마지막으로 spoke 자체의 default route를 제거하면 hub를 우회하지 않게 되며, 이는 모든 spoke가 모든 인터넷 egress에 대해 hub firewall을 사용해야 한다는 요구 사항을 충족하는 데 필요합니다.

이 옵션은 internal passthrough NLB VIP 대신 개별 firewall 인스턴스를 route next hop으로 사용하므로, 제시된 아키텍처에 대한 최적의 high-availability 설계가 아닙니다. 문제에서 firewall이 regional internal passthrough Network Load Balancer 뒤에 배포되어 있다고 명시했으며, 해당 VIP가 활성 appliance로 트래픽을 전달하기 위한 지원되는 복원력 있는 next hop입니다. 인스턴스별 next hop을 사용하면 failover가 복잡해지고 appliance 장애 시 비대칭 routing 또는 routing 실패가 발생할 수 있습니다. 또한 최선의 답변만큼 spoke 측 route 우선순위 문제를 명확하게 해결하지도 못합니다.

이 옵션은 spoke VPC가 VPC peering을 통해 다른 VPC에 있는 internal passthrough load balancer VIP를 next hop으로 하는 static route를 생성할 수 없기 때문에 유효하지 않습니다. 지원되는 방식은 hub에서 custom route를 생성하고 custom routes의 export 및 import를 활성화하여 peering을 통해 이를 교환하는 것입니다. spoke에서 원격 VIP를 직접 참조하는 것은 peering route 교환 메커니즘을 우회하는 것이며, peered VPC 간 next hop이 동작하는 방식도 아닙니다. 따라서 기술적 제약이나 의도된 중앙집중식 egress 설계를 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 internal passthrough Network Load Balancer를 사용해 hub VPC의 서드파티 firewall을 통한 중앙집중식 인터넷 egress를 구현하면서, VPC Network Peering custom route 교환을 활용하고 high availability를 유지하는지를 테스트합니다. 중요한 routing 규칙은 Google Cloud에서 VPC의 local route가 peering을 통해 학습된 route보다 우선된다는 점이며, 여기에는 default internet gateway로의 local default route도 포함됩니다. 따라서 spoke가 hub에서 광고한 0.0.0.0/0 route를 실제로 사용하려면, spoke 자체의 local default internet gateway route를 제거하여 hub에서 import된 custom default route가 선택되도록 해야 합니다. 정답인 이유: Option B는 먼저 hub에서 internal passthrough NLB VIP를 가리키는 custom default route를 생성하는데, 이는 firewall 쌍 전체에 대해 high availability next hop을 제공합니다. 또한 hub의 광범위한 default internet gateway route를 firewall 인스턴스만 사용할 수 있는 tag 범위 route로 대체하여 hub에서의 직접 인터넷 액세스를 제한합니다. 그런 다음 hub-and-spoke peering 전반에서 custom routes의 export/import를 활성화하여 spoke가 hub의 0.0.0.0/0 route를 학습하도록 합니다. 마지막으로 spoke 자체의 default internet gateway route를 제거하는데, 이는 local route가 peering을 통해 학습된 route보다 우선되기 때문에 반드시 필요합니다. 주요 특징: - Internal passthrough Network Load Balancer VIP는 custom static route의 next hop으로 사용되어 서드파티 appliance에 대한 HA를 제공할 수 있습니다. - hub에서 tag 범위가 지정된 default internet gateway route는 firewall 인스턴스만 인터넷으로 직접 egress할 수 있도록 보장합니다. - VPC Network Peering은 export/import가 명시적으로 활성화된 경우에만 custom routes를 교환할 수 있습니다. - spoke VPC가 import된 hub default route를 사용해야 한다면 자체 local default route를 유지해서는 안 됩니다. 흔한 오해: - spoke에 자체 local default internet gateway route가 여전히 남아 있다면, peering을 통해 custom default route를 import하는 것만으로는 충분하지 않습니다. local route가 우선합니다. - 한 VPC의 route를 다른 peered VPC의 internal load balancer VIP로 직접 지정할 수는 없습니다. - 개별 firewall 인스턴스를 route next hop으로 사용하는 것은 internal passthrough NLB VIP를 사용하는 것과 같은 수준의 HA 동작을 제공하지 않습니다. 시험 팁: - Google Cloud의 route 선택 우선순위를 기억하세요: local route가 peering route보다 우선됩니다. - peering을 통한 중앙집중식 egress에서는 항상 custom route 교환과 spoke의 local route를 제거하거나 대체해야 하는지를 함께 확인하세요. - HA 서드파티 appliance의 경우, 개별 인스턴스 대신 internal passthrough NLB를 route next hop으로 사용하는 것을 우선 고려하세요.

15
문제 15

Your company is deploying a new 20-Gbps Dedicated Interconnect with two VLAN attachments in us-east4 and BGP peering to on-premises ASN 65010; three departments (R&D, HR, and Finance) each use separate service projects attached to a single Shared VPC host project that owns the central VPC, and you need all departments to exchange routes with on-premises over this Interconnect—where should you create the Cloud Router instance?

오답입니다. Shared VPC hybrid routing을 해결하기 위해 “모든 project의 VPC networks에 Cloud Router를 생성”할 수는 없습니다. Cloud Router는 특정 VPC network에 종속되며, Shared VPC에서는 VPC network가 host project에 존재합니다. Service projects는 shared subnets에 대한 별도의 VPC networks를 갖지 않고 host의 VPC에 attach합니다. 여러 project에 여러 routers를 두어도 shared VPC route exchange를 제공하지 못합니다.

오답입니다. Finance service project에 Cloud Router를 생성해도 Shared VPC host project의 VPC network에 attach되지 않습니다. Service projects는 일반적으로 shared VPC network를 소유하지 않고 host의 subnets만 사용합니다. 그 결과 Dedicated Interconnect에 대한 VLAN attachments/BGP sessions가 모든 부서가 사용하는 중앙 VPC와 올바르게 연관되지 않습니다.

정답입니다. Shared VPC host project가 중앙 VPC network를 소유하며, Cloud Router는 서비스를 제공할 VPC network와 동일한 project에서 생성되어야 합니다. Dedicated Interconnect VLAN attachments가 us-east4에 있고 모든 부서에 대해 on-premises와 routes를 교환해야 하므로, host project의 VPC에 Cloud Router를 배치하면 R&D, HR, Finance가 소비하는 shared network에 대해 dynamic route import/export가 가능해집니다.

오답입니다. R&D, HR, Finance는 service projects이며 shared subnets에 대해 각각의 VPC network를 갖지 않고 host project의 VPC에 attach합니다. 각 service project에 별도의 Cloud Routers를 생성해도 해당 routers가 shared VPC에 연결되지 않으며, host VPC와 연관되어야 하는 Dedicated Interconnect의 VLAN attachments를 올바르게 terminate할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 Cloud Router, VLAN attachments (Dedicated Interconnect), 그리고 Shared VPC가 어떻게 상호작용하는지를 테스트합니다. Cloud Router는 regional이며 VPC-scoped인 managed BGP control plane으로, Interconnect(또는 VPN)를 통해 VPC network와 on-premises 간에 routes를 동적으로 교환하는 데 사용됩니다. 정답이 맞는 이유: Shared VPC 아키텍처에서 VPC network는 host project가 소유하고, service projects는 해당 host project의 VPC 내 subnets에 resources(VMs, GKE nodes 등)를 연결합니다. Cloud Router와 VLAN attachments처럼 VPC-scoped인 hybrid connectivity 구성요소는 VPC network를 소유한 project(Shared VPC host project)에서 생성되어야 합니다. Cloud Router를 host project의 VPC에 생성하면, BGP를 통해 on-premises에서 학습한 routes가 shared VPC로 import되고, 따라서 routing mode 및 custom route import/export policies에 따라 연결된 모든 service projects(R&D, HR, Finance)에서 사용할 수 있게 됩니다. 주요 기능 / 구성: - Cloud Router는 regional이므로, us-east4의 VLAN attachments와 일치하도록 us-east4에 생성합니다. - VLAN attachments는 host project의 VPC로 terminate되며, on-prem ASN 65010에 대한 BGP sessions를 위해 Cloud Router와 연결됩니다. - 이후 dynamic route exchange가 VPC 내부로 전파됩니다(global vs regional dynamic routing mode 및 custom route advertisements의 적용을 받음). - Best practice: high availability를 위해 redundant VLAN attachments와 BGP sessions를 사용하고, 적절한 route advertisement(필요 시 custom prefixes)를 보장하며, route limits/quotas를 고려합니다. 흔한 오해: 자주 하는 실수는 각 부서의 service project마다 Cloud Router가 필요하다고 생각하는 것입니다. Service projects는 shared VPC network를 “소유”하지 않고 “소비”합니다. 따라서 service project에 Cloud Router를 두면 shared VPC network에 연결되지 않으며, 모든 부서에 대한 hybrid route exchange를 제공할 수 없습니다. 시험 팁: - 범위(scoping) 규칙을 기억하세요: Cloud Router와 Interconnect VLAN attachments는 연결되는 VPC network를 소유한 project에서 생성됩니다. - Shared VPC에서는 hybrid connectivity가 일반적으로 host project에 중앙집중화됩니다. - 항상 Cloud Router region을 Interconnect/VLAN attachment region과 맞추고, cross-project reachability를 위해 dynamic routing mode 및 route advertisement/import 설정을 검증하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

16
문제 16

Your organization operates 4 VPC networks across 3 Google Cloud projects under a single folder. The Compliance team owns all firewall rules and SSL certificates for audit purposes, while the Platform Networking team administers VPCs, subnets, routes, and peering. The networking team must be able to view firewall rules across all projects for troubleshooting (read/list only), but must not be able to create, modify, or delete any firewall rules. You plan to grant access at the folder level so it inherits to all current and future projects. What IAM permissions or roles should you assign to the Platform Networking team to meet these requirements while adhering to least privilege?

compute.networkUser는 Shared VPC network 또는 subnet에 VM이나 load balancer 같은 resources를 연결해야 하는 service projects 또는 principals를 위한 role입니다. 이 role은 문제 해결 요구 사항에서 요구하는 프로젝트 전반의 firewall rules에 대한 광범위한 읽기 전용 가시성을 제공하지 않으며, network topology resources를 관리하는 목적과도 맞지 않습니다. 이 role은 networks를 소비하는 용도이지 firewall policy를 검사하는 용도가 아닙니다. 따라서 명시된 운영 요구 사항을 충족하지 못합니다.

compute.networkAdmin은 다른 networking resources와 함께 firewall rules를 관리할 수 있는 권한이 포함되어 있어 권한이 너무 큽니다. 이는 감사 목적상 Compliance 팀이 firewall rules와 SSL certificates를 소유한다는 직무 분리 요구 사항을 직접 위반합니다. 이 role은 networking 팀이 문제를 해결할 수 있게 해주지만, 동시에 firewall rules를 생성, 수정 또는 삭제할 수도 있게 하며, 이는 문제에서 명시적으로 금지하고 있습니다. 최소 권한 원칙에 따라 이 옵션은 즉시 제외됩니다.

compute.networks.*와 compute.firewalls.list만 포함하는 custom role은 설명된 책임 범위에 비해 불완전합니다. 시나리오에서는 Platform Networking 팀이 VPCs, subnets, routes, peering을 관리한다고 했지만, compute.networks.*는 network resources만 다루며 subnetworks, routes, network peerings에 대한 별도의 권한 계열은 포함하지 않습니다. 또한 firewall 액세스를 list로만 제한하는 것은 명시된 read/list 요구보다 더 좁아서 완전한 문제 해결 가시성을 지원하지 못할 수 있습니다. 이 custom role은 필요한 networking 관리 권한을 누락하므로 전체 요구 사항을 충족하지 못합니다.

compute.networkViewer는 folder와 그 하위 모든 프로젝트 전반에서 firewall rules를 포함한 networking resources에 대한 읽기 전용 가시성을 제공하는 predefined 최소 권한 role입니다. 이는 Platform Networking 팀이 firewall rules를 조회하고 문제를 해결할 수 있어야 하지만 이를 생성, 수정 또는 삭제할 수 없어야 한다는 명시적 요구 사항을 충족합니다. 추가된 compute.networks.use 권한은 명시된 firewall 조회 요구 사항에는 불필요하지만, 제시된 선택지 중에서는 administrative role이나 불완전한 custom role이 아니라 읽기 전용 networking role을 기반으로 한 유일한 옵션입니다. 바인딩이 folder 수준에 적용되므로 해당 folder 아래의 현재 및 미래 모든 프로젝트에 액세스가 일관되게 상속됩니다.

문제 분석

핵심 개념: 이 문제는 Compliance가 firewall 관리를 담당하는 직무 분리를 유지하면서, Platform Networking 팀이 상속된 모든 프로젝트 전반에서 firewall rules를 조회하여 문제를 해결할 수 있도록 folder 수준에서 최소 권한의 IAM role 할당을 선택하는 것에 관한 것입니다. 정답인 이유: 이 팀은 firewall rules와 networking resources에 대한 읽기 전용 가시성이 필요하지만, firewall rules를 생성, 업데이트 또는 삭제할 수 있으면 안 됩니다. 핵심 특징: Folder 수준 IAM 상속은 현재 및 미래의 모든 프로젝트에 적용되며, 요구 사항을 충족하는 경우 predefined viewer roles가 선호되고, firewall rule 가시성은 admin 권한이 아니라 읽기 전용 권한에서 제공되어야 합니다. 흔한 오해: compute.networkAdmin은 firewall 관리가 포함되어 있어 너무 광범위하고, compute.networkUser는 networks에 resources를 연결하는 용도이지 조회/관리 용도가 아니며, compute.networks.*로 제한된 custom role은 시나리오에 언급된 더 넓은 networking resources를 포괄하지 못합니다. 시험 팁: 문제에서 read/list only라고 하면 변경 권한이 있는 role은 제외하세요. 최소 권한이 요구되면 가시성 요구 사항을 충족하는 가장 좁은 predefined role을 우선하고, 필요한 resource 계열을 빠뜨리는 custom roles는 피하세요.

17
문제 17

Your media startup is launching a stateless HTTPS landing site in europe-west1 and asia-southeast1. The site runs on Compute Engine instances in two regional managed instance groups (one per region) with autoscaling and autohealing; no database or session persistence is required. You need a single global endpoint (site.example.com) that minimizes latency for EMEA and APAC users and can withstand a full regional outage, following Google-recommended practices. What should you do?

오답. Regional network load balancer는 L4이며 regional이므로 단일 global anycast endpoint를 제공하지 않습니다. Cloud CDN은 regional TCP/UDP network load balancer에서 활성화되지 않습니다(CDN은 external HTTP(S) load balancing과 통합됨). DNS에 두 IP를 넣는 방식(round-robin)은 health-aware가 아니며 DNS caching/TTL 때문에 unhealthy region으로 계속 트래픽을 보낼 수 있어 outage resiliency를 해칩니다.

정답. Global external HTTP(S) load balancer(Premium Tier)는 단일 global anycast IP를 제공하고 사용자를 가장 가까운 edge로 라우팅한 뒤, region 간에서 가장 가까운 healthy backend로 전달합니다. 두 regional MIG를 연결하면 health check를 통해 automatic cross-region failover가 가능합니다. Cloud CDN은 cache 가능한 콘텐츠의 latency를 개선하고, Cloud Armor는 internet-facing app에 권장되는 managed security layer입니다. Cloud DNS는 global VIP를 가리키는 단일 A record를 사용합니다.

오답. 여러 region의 backend를 가진 global external HTTP(S) load balancer를 사용하기 위해 별도의 VPC나 VPC peering이 필요하지 않습니다. 단일 VPC가 표준입니다. 또한 Cloud DNS는 일반적으로 load balancer IP에 대한 A/AAAA record를 사용해야 하며, 제공된 DNS name이 없는 한 CNAME을 load balancer로 직접 가리키는 방식은 사용하지 않습니다(LB는 주로 IP를 노출). 이는 이점 없이 복잡성만 추가합니다.

오답. Standard Network Tier는 external HTTP(S) load balancing에 대해 global anycast IP를 제공하지 않습니다. regional이므로 “latency를 최소화하는 단일 global endpoint” 요구사항을 충족하지 못합니다. 또한 CNAME record는 IP address를 가리킬 수 없습니다(CNAME target은 hostname이어야 함). A record로 수정하더라도 Standard Tier는 여전히 global latency 및 resiliency 목표를 만족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Premium Tier를 사용하는 Google Cloud global external HTTP(S) Load Balancing (Application Load Balancer)을 테스트합니다. 이는 단일 global anycast IP, Google edge에서의 latency-based routing, 그리고 cross-region failover를 제공합니다. 또한 load balancer에 연결되는 managed service로서 Cloud CDN/Cloud Armor도 함께 다룹니다. 정답이 맞는 이유: EMEA와 APAC 사용자에 대해 latency를 최소화하면서 전체 regional outage에도 견디는 단일 global endpoint(site.example.com)가 필요합니다. Premium Tier의 global external HTTP(S) load balancer는 여러 edge location에서 단일 anycast IP를 광고(advertise)합니다. 사용자는 가장 가까운 edge로 라우팅된 뒤, Google backbone을 통해 가장 건강한(healthy) backend(europe-west1 또는 asia-southeast1)로 전달됩니다. 한 region 전체가 장애가 나면 health check가 해당 backend를 unhealthy로 표시하고, 트래픽은 자동으로 남아 있는 region으로 failover됩니다—DNS 변경이나 client-side retry가 필요 없습니다. 이는 global, highly available HTTPS 서비스를 위한 Google 권장 패턴입니다. 주요 기능 / best practices: - Global anycast VIP + Premium Tier: 최상의 latency와 global resiliency 제공; Standard Tier는 regional이며 동일한 edge 기반 global routing을 제공하지 않습니다. - Backend service는 여러 regional MIG(각 region당 1개)를 포함할 수 있으며 autoscaling/autohealing을 사용할 수 있습니다. - Health check와 capacity-based balancing으로 automatic regional failover를 제공합니다. - Cloud CDN은 HTTP(S) load balancer에서 통합되어 edge에서 static content를 캐싱합니다(landing site에 유용). - Cloud Armor는 internet-facing endpoint에 권장되는 보안 제어(WAF/DDoS policy)이나, availability에 필수는 아닙니다. - Cloud DNS는 global VIP에 대한 단일 A record를 사용합니다(“DIY” failover를 위한 다중 A record가 아님). 흔한 오해: - 여러 A record를 사용하는 DNS(round-robin)는 진정한 load balancing이나 빠른 failover가 아닙니다. caching/TTL 및 health 인지 부족으로 dead region으로 사용자를 보낼 수 있습니다. - Network Load Balancer(L4)는 host/path routing, managed cert, CDN 통합, global anycast 같은 HTTPS 기능에 적합한 도구가 아닙니다. - Standard Tier는 단일 global anycast endpoint를 제공할 수 없습니다. 시험 팁: “single global endpoint”, “minimize latency globally”, “withstand regional outage”를 보면 기본적으로 Premium Tier의 Global External HTTP(S) Load Balancing과 multi-region backend를 선택하세요. Cloud DNS A record로 global VIP를 가리키고, DNS 기반 failover를 주요 HA 메커니즘으로 사용하는 것은 피하세요.

18
문제 18

Your media analytics team runs workers in a VPC-native GKE Standard cluster in us-east1 where nodes currently have external IPs; the cluster uses the default ip-masq-agent settings (SNAT enabled). A partner exposes an API only to traffic originating from your Cloud NAT public addresses, and the partner's allowlist covers 203.51.64.0/19; you must ensure all pod egress to 203.51.64.0/19 uses Cloud NAT rather than the nodes' external IPs. You will configure Cloud NAT on the cluster subnet; what change should you make on the cluster to ensure traffic to 203.51.64.0/19 is NATed by Cloud NAT?

오답입니다. 203.51.64.0/19를 nonMasqueradeCIDRs에 추가하면 해당 대상에 대한 pod-to-node SNAT가 비활성화되므로, node IP로 변환되는 대신 pod IP가 유지됩니다. 이것이 Cloud NAT 사용을 본질적으로 유발하는 것은 아니며, external IP addresses가 있는 노드를 사용하는 cluster에서는 문제의 요구 사항도 해결하지 못합니다. 이 설명은 ip-masq 비활성화와 Cloud NAT 강제를 혼동하고 있는데, 둘은 동일한 동작이 아닙니다. 이 선택지는 Cloud NAT 적용 가능성을 바꾸는 것이 아니라 pod source preservation을 변경합니다.

정답입니다. nonMasqueradeCIDRs는 pod-to-node SNAT를 우회해야 하는 대상을 나열하므로, 203.51.64.0/19를 제거하면 해당 partner range로 가는 트래픽이 node IP로 masquerade됩니다. 제시된 선택지 중 이것만이 의도한 방향으로 해당 대상에 대한 egress 동작을 실제로 변경하는 cluster 측 변경입니다. 또한 지원되지 않는 Cloud NAT 기능을 만들어내지 않고 ip-masq-agent 메커니즘을 올바르게 사용합니다. 이 선택지는 pod가 node IP로 SNAT되는지 여부를 제어하는 cluster 구성 요소가 Cloud NAT가 아니라 ip-masq-agent라는 사실을 반영합니다.

오답입니다. Cloud NAT는 '이 external CIDR로 가는 트래픽은 변환하지 말라'와 같은 destination-based exclusion rule을 제공하지 않습니다. Cloud NAT는 Cloud Router와 subnet ranges에 연결되며, 이 선택지가 설명하는 방식처럼 대상별 인터넷 제외 규칙으로 동작을 구성하지 않습니다. 따라서 이는 요구 사항에 대한 유효하거나 의미 있는 구성 변경이 아닙니다. 이 선택지는 Cloud NAT가 제공하지 않는 기능을 전제로 합니다.

오답입니다. Cloud NAT에는 nonMasqueradeCIDRs라는 구성이 없으며, ip-masq-agent 설정을 사용하거나 미러링하지도 않습니다. 이 선택지는 Kubernetes pod SNAT 제어와 VPC egress NAT 제어를 마치 하나의 시스템인 것처럼 잘못 혼합하고 있습니다. 두 계층은 서로 독립적이므로, Cloud NAT에 동일한 목록을 중복 구성하는 것은 지원되는 해결책이 아닙니다. 이 문구는 기술적으로 부정확하며 실제 구성 패턴을 설명하지 않습니다.

문제 분석

핵심 개념: 이 문제는 external IP addresses가 있는 노드를 사용하는 VPC-native GKE Standard cluster에서 pod egress에 대해 GKE ip-masq-agent와 Cloud NAT가 어떻게 상호작용하는지를 테스트합니다. 핵심 포인트는 ip-masq-agent가 트래픽이 노드를 떠나기 전에 pod 트래픽이 node IP로 source-NAT되는지 여부를 제어하는 반면, Cloud NAT는 VPC 수준의 NAT 서비스이며 ip-masq-agent와 구성을 공유하지 않는다는 점입니다. 정답인 이유: 특정 대상에 대한 pod egress가 pod IP를 유지하지 않고 node identity를 사용하게 하려면, 해당 대상이 nonMasqueradeCIDRs에 포함되어 있으면 안 됩니다. nonMasqueradeCIDRs에서 203.51.64.0/19를 제거하면 해당 partner range로 가는 pod 트래픽이 node IP로 masquerade되며, 제시된 선택지 중 이것만이 node-level egress 동작을 사용하는 방향과 일치하는 cluster 측 변경입니다. 다른 선택지들은 pod IP를 유지하게 하거나, 지원되지 않는 Cloud NAT 동작을 설명하거나, Cloud NAT와 ip-masq-agent를 잘못 동일시합니다. 주요 기능: - ip-masq-agent의 nonMasqueradeCIDRs는 pod 트래픽이 node IP로 SNAT되지 않고 pod source IP를 유지해야 하는 대상 CIDR를 정의합니다. - 대상이 nonMasqueradeCIDRs에 없으면, pod 트래픽은 노드를 떠나기 전에 node IP로 masquerade됩니다. - Cloud NAT는 subnet/router에 구성되며 ip-masq-agent 설정과는 독립적입니다. 또한 이에 대응하는 nonMasqueradeCIDRs 개념도 없습니다. 흔한 오해: - 대상을 nonMasqueradeCIDRs에 추가한다고 해서 Cloud NAT가 강제되는 것은 아닙니다. 이는 해당 대상에 대해 pod-to-node SNAT만 비활성화할 뿐입니다. - Cloud NAT는 선택지 C에 설명된 유형의 destination-based exclusion rule을 지원하지 않습니다. - Cloud NAT와 ip-masq-agent는 서로 다른 문제를 해결하며, 선택지 D가 암시하듯 공유된 destination list로 구성할 수 없습니다. 시험 팁: - GKE networking 문제를 읽을 때는 Kubernetes SNAT 동작과 VPC NAT 동작을 구분하세요. - nonMasqueradeCIDRs는 “이 대상들에 대해서는 pod 트래픽을 node IP로 SNAT하지 말라”는 의미입니다. - 어떤 선택지가 Cloud NAT에 destination-based filtering이 있거나 ip-masq-agent와 구성 의미를 공유한다고 주장하면, 대개 틀렸습니다.

19
문제 19

You are deploying a new VPC in europe-west1 to host internal microservices that must bind to two distinct private IP ranges. Your application VMs will reside in a subnet using 10.20.0.0/24, but a legacy client integration requires the same VMs to also listen on IPs from 192.168.70.0/24 for inbound connections. Without adding a second NIC or introducing new gateways, you need the instances to have addresses in both ranges; what should you do?

global external HTTP(S) load balancer는 external anycast VIP와 L7 routing을 제공할 뿐, 192.168.70.0/24 같은 internal RFC1918 range의 주소를 VM이 네이티브하게 소유하도록 만드는 방법이 아닙니다. 또한 새로운 front end(관리형 gateway)를 도입하며 protocol-specific(HTTP/S)입니다. 이는 새 gateways를 피하라는 요구사항을 위반하고 “instances가 두 range 모두의 주소를 가진다”는 조건도 충족하지 못합니다.

DNS records는 clients를 다른 IP로 안내할 수 있지만, DNS는 VM interface에 IP 주소를 할당하지 않습니다. VM에 192.168.70.0/24 주소가 실제로 구성되어 있지 않다면, 해당 IP로 향하는 트래픽을 수신할 수 없습니다(다른 device/load balancer가 그 IP를 소유하지 않는 한). DNS는 naming 솔루션이지 IP addressing 메커니즘이 아니므로 요구사항을 충족할 수 없습니다.

Alias IP ranges는 동일한 NIC에서 VM에 추가 internal IP를 부여하는 올바른 메커니즘입니다. subnet에 192.168.70.0/24를 secondary range로 추가한 다음, 해당 range에서 alias IPs를 instances에 할당합니다. 이는 같은 VMs, 두 private ranges, 두 번째 NIC 없음, 추가 gateways 없음 요구사항을 모두 충족합니다. multi-IP workloads를 위한 표준 VPC 기능입니다.

VPC peering은 두 개의 별도 VPC networks를 연결하고 routes를 교환하지만, 단일 VM interface가 서로 관련 없는 두 range의 IP를 보유하게 만들지는 않습니다. 여전히 192.168.70.0/24 range가 어딘가에 subnet/secondary range로 존재해야 하고, 그 IP들을 VM에 할당할 방법이 필요합니다. Peering은 아키텍처 복잡성도 추가하며 “같은 instances가 두 range 모두의 주소를 가진다”는 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 VPC subnet 설계와, NIC나 routing gateway를 추가하지 않고 Google Cloud에서 동일한 VM interface에 여러 IP 주소/대역을 할당하는 방법을 테스트합니다. 핵심 기능은 subnet의 Alias IP ranges(secondary ranges)와 VM instance에 대한 alias IP 할당입니다. 정답이 맞는 이유: 이미 VM NIC용 primary subnet range(10.20.0.0/24)가 있지만, 동일한 VM들이 두 번째 private range(192.168.70.0/24)의 주소에서도 “listen”해야 합니다. Google Cloud에서는 동일한 subnet에 secondary IP range를 추가한 뒤, 해당 secondary range에서 alias IP를 VM의 기존 NIC에 할당할 수 있습니다. 이렇게 하면 동일한 interface에서 instance가 추가 internal IP 주소를 갖게 되어 “두 번째 NIC 없음” 및 “새 gateway 없음” 요구사항을 충족합니다. 해당 alias IP로 들어오는 트래픽은 VPC dataplane에 의해 직접 VM으로 전달됩니다. 주요 기능 / 구성 참고 사항: 1) europe-west1의 subnet에 192.168.70.0/24를 secondary range로 추가합니다. 2) 각 VM NIC에 해당 secondary range에서 하나 이상의 alias IP를 구성합니다(또는 VM마다 필요한 IP 개수에 따라 /32를 VM별로 할당). 3) 필요에 따라 firewall rules가 alias IP/port로의 ingress를 허용하도록 보장합니다(firewall rules는 instances/tags/service accounts를 대상으로 할 수 있으며 별도의 NIC가 필요하지 않습니다). 4) guest OS/app이 추가 IP에서 bind/listen하도록 구성되어 있는지 확인합니다. 흔한 오해: 사람들은 종종 “VM에 여러 IP”를 “여러 NIC”로 혼동하거나 load balancers, DNS 트릭, VPC peering이 필요하다고 생각합니다. DNS는 name-to-IP 매핑만 변경할 뿐, VM이 IP를 소유하게 만들지는 않습니다. Load balancers는 트래픽 분산을 위한 것이며, 일반적으로 subnet 내부의 임의 RFC1918 대역을 단순히 사용하는 VIP를 제공하는 방식이 아닙니다. VPC peering은 두 VPC를 연결하는 것이지, 동일한 VM interface에 두 번째 IP range를 할당하는 기능이 아닙니다. Exam tips: “같은 VM, 두 private ranges, 추가 NIC 없음, gateway 없음” 같은 요구사항을 보면 subnet secondary ranges + alias IPs를 떠올리세요. 또한 alias IPs는 internal-only이며, multi-IP workloads, container networking, service IPs에 흔히 사용됩니다. 이는 운영 복잡성을 줄이는 managed, native primitives를 선택하라는 Google Cloud Architecture Framework 원칙과도 부합합니다.

20
문제 20

You are deploying an internal-only metrics ingestion HTTP endpoint on a Compute Engine VM named collector-01 in zone us-central1-b within the project analytics-prd, the VM has no external IP and must be reachable only by multiple client VMs in the same VPC network, and you need a simple, built-in way for those clients to obtain the service’s IP address without creating public DNS records or exposing the service; what should you do?

오답입니다. static external IP를 예약하고 external HTTP(S) load balancer를 사용하면 설계상 internet-reachable frontend가 생성됩니다. backend가 프라이빗이더라도 forwarding rule은 public이며, 서비스가 internal-only이고 노출되지 않아야 한다는 요구사항을 위반합니다. 또한 VM 디스커버리를 위한 내장 internal DNS에 비해 불필요한 비용과 복잡성을 추가합니다.

정답입니다. Compute Engine은 VPC 내의 VM이 인스턴스의 internal FQDN을 해당 private IP address로 해석할 수 있도록 internal DNS를 제공합니다. https://collector-01.us-central1-b.c.analytics-prd.internal/ 를 사용하는 것은 public DNS 레코드가 필요 없고, 서비스를 외부에 노출하지 않으며, 동일한 VPC의 클라이언트에 자연스럽게 동작하는 단순한 내장 service discovery 메커니즘입니다.

오답입니다. 이 선택지는 public DNS A record를 명시적으로 생성하고 static external IP를 가진 external HTTP(S) load balancer를 사용합니다. 이는 public DNS 레코드를 피하고 서비스를 노출하지 말라는 요구사항에 반합니다. firewall로 접근을 제한하더라도 엔드포인트는 여전히 공개 주소를 가지며 공격 표면과 운영 오버헤드를 증가시킵니다.

오답입니다. https://metrics/v1/ 같은 짧은 alias는 Compute Engine이 자동으로 제공하는 것이 아닙니다. 기본 search domain은 custom DNS(예: “metrics”에 대한 A record가 있는 private Cloud DNS zone)를 구성하지 않는 한 임의의 hostname을 해석하도록 보장되지 않습니다. 그 구성 없이는 클라이언트가 이름을 해석하지 못하므로 신뢰할 수 있는 내장 솔루션이 아닙니다.

문제 분석

핵심 개념: 이 문제는 프라이빗 리소스를 위한 Google Cloud의 내장 이름 해석 기능에 대한 지식을 평가합니다: Compute Engine internal DNS(“internal” 모드에서 Google-managed zone에 대해 Cloud DNS가 제공). 이는 관리형 네트워크 서비스로, VM이 공개 DNS 레코드를 생성하지 않고도 프라이빗 RFC1918 주소를 사용해 이름으로 다른 VM을 찾을 수 있게 해줍니다. 정답이 맞는 이유: VM collector-01에는 external IP가 없고 동일한 VPC 내의 클라이언트에서만 접근 가능해야 합니다. 클라이언트가 서비스 IP를 얻는 가장 단순한 내장 방식은 인스턴스의 internal fully qualified domain name(FQDN)을 사용하는 것이며, 이는 VPC 내부에서 VM의 internal IP로 해석됩니다. internal DNS 이름 형식에는 instance name, zone, 그리고 프로젝트별 internal domain(…c.<project-id>.internal)이 포함됩니다. 클라이언트는 https://collector-01.us-central1-b.c.analytics-prd.internal/ 로 호출하고 Google이 제공하는 internal DNS 해석에 의존할 수 있습니다. 이렇게 하면 엔드포인트를 프라이빗으로 유지하면서 Cloud DNS public zone을 관리하거나 어떤 external load balancer도 노출할 필요가 없습니다. 주요 기능 / 모범 사례: - Compute Engine는 VPC network 상의 인스턴스에 대해 internal DNS 해석을 제공합니다. 이름은 internal IP로 해석되며 VPC 내부에서만 해석 가능합니다(그리고 구성에 따라 Cloud VPN/Interconnect로 연결된 네트워크에서도 DNS forwarding을 통해 해석 가능). - 이 접근 방식은 Google Cloud Architecture Framework의 보안(공개 노출 없음) 및 운영 우수성(추가 구성요소 없이 관리형 서비스 디스커버리) 원칙에 부합합니다. - VM lifecycle과 무관한 안정적인 이름이 필요하다면, 이후 private Cloud DNS zone과 레코드를 추가할 수 있습니다. 하지만 문제는 “단순한, 내장” 및 “public DNS 레코드 없음”을 요구합니다. 흔한 오해: A와 C는 load balancer와 static IP가 안정적인 엔드포인트를 제공하므로 매력적으로 보일 수 있지만, 이는 external IP를 가진 external HTTP(S) load balancer로서 “internal-only”에 위배되며 불필요한 노출 위험과 비용을 추가합니다. D는 generic search domain과 “metrics” 같은 짧은 alias를 가정하지만, 이는 GCE에서 보장되거나 기본으로 해석 가능한 이름이 아닙니다. custom DNS 구성이 필요합니다. 시험 팁: - VPC 내부에서의 프라이빗 VM-to-VM 디스커버리는 먼저 “Compute Engine internal DNS”를 떠올리세요. - instance naming/zone에 묶이지 않는 프라이빗 서비스 이름은 “Cloud DNS private zone”을 떠올리세요. - 프라이빗 L7 load balancing은 external이 아니라 “Internal HTTP(S) Load Balancer”를 떠올리세요.

합격 후기(5)

E
E**********Nov 25, 2025

학습 기간: 1 month

I really appreciated the detailed explanations. This app strengthened my fundamentals more than any video course.

혜
혜**Nov 17, 2025

학습 기간: 1 month

문제를 다 풀긴했는데 정답률이 65%가 나와서 1번 더 리셋해서 문제 풀었어요. 문제와 정답을 외우기보다 실제 개념 학습에 초점을 맞춰서 그런지 공부량이 많았고, 실제 시험에서 비슷한 유형도 나왔지만 처음보는 시나리오가 나왔는데도 잘 풀 수 있었어요. 수험생분들도 잘 준비해서 꼭 합격하시길!!

S
S***********Nov 6, 2025

학습 기간: 1 month

I was surprised how similar the question style was to the actual PCNE exam. Practicing with this app made complex topics like VPC peering and NAT configuration much easier. Passed and I’m really satisfied.

A
A************Oct 25, 2025

학습 기간: 2 weeks

I spent two weeks solving about 30 questions a day, and Cloud Pass helped me reinforce my weak spots in hybrid networking and load balancing strategies. This app is a must-have for anyone preparing for PCNE.

R
R*********Oct 17, 2025

학습 기간: 1 month

Good questions and similar to the real exam questions. The app is very helpful tool

모의고사

Practice Test #1

50 문제·120분·합격 700/1000

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Google Associate Cloud Engineer

Associate

Google Associate Data Practitioner

Google Associate Data Practitioner

Associate

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Security Engineer

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

Cloud Pass를 다운로드하여 모든 Google Professional Cloud Network Engineer 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

이동 중에도 모든 문제를 풀고 싶으신가요?

앱 받기

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.