CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Cloud Network Engineer
Google Professional Cloud Network Engineer

Practice Test #1

50개 문제와 120분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제120분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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를 선호하세요.

2
문제 2

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)를 고려해 설계하세요.

3
문제 3

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)하세요.

4
문제 4

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 설정을 검증하세요.

5
문제 5

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 원칙과도 부합합니다.

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

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

6
문제 6

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”를 떠올리세요.

7
문제 7
(2개 선택)

Your company uses a third-party virtual firewall appliance to inspect egress traffic. In a spoke VPC in us-central1, you configured a custom default route 0.0.0.0/0 (priority 100) that sends all egress to the firewall in a hub VPC via next hop instance. None of the VM instances in the spoke subnets have external IP addresses. The data team needs VM instances in subnet analytics-subnet (10.50.1.0/24) to access the Cloud Storage JSON API and the Cloud Logging API directly without traversing the firewall, but all other internet-bound traffic must continue to use the firewall route. You must not assign public IPs to any VMs and must retain the existing 0.0.0.0/0 to the firewall for general egress. Which two actions should you take? (Choose two.)

정답입니다. Private Google Access는 subnet 레벨에서 활성화되며, 외부 IP가 없는 VM이 Google APIs/services에 접근할 수 있게 합니다. analytics-subnet에서 이를 활성화하면 해당 subnet의 VM만 public IP 없이 Cloud Storage JSON API와 Cloud Logging API에 직접 접근한다는 요구사항을 충족합니다. 또한 이 VM들이 Google APIs VIP를 성공적으로 사용하기 위한 기본 전제 조건입니다.

오답입니다. Private Google Access는 VPC 레벨에서 활성화되지 않으며 subnet별로 구성합니다. 시험에서는 이 범위(scope) 디테일을 자주 묻습니다. organization policy와 DNS는 중앙화할 수 있지만, PGA on/off 스위치는 subnet 속성입니다. 따라서 이 옵션은 Google Cloud에서 유효한 구성 작업이 아닙니다.

오답입니다. Private Services Access는 VPC peering을 통해 managed service에 프라이빗하게 접근하기 위해 사용됩니다(예: Cloud SQL private IP). 이는 Cloud Storage JSON API나 Cloud Logging API 같은 Google APIs 접근과는 무관합니다. 또한 Google APIs에 대해 방화벽을 우회하는 데 도움이 되지 않으며, 설명된 routing 요구사항도 해결하지 못합니다.

정답입니다. Google APIs VIP range에 대해 default internet gateway로 향하는 더 구체적인 라우트를 생성하면, 해당 목적지는 방화벽으로 향하는 0.0.0.0/0 next-hop-instance 라우트를 우회합니다. /0 라우트보다 longest prefix match가 우선이므로 Google API 트래픽만 예외로 분리되고, 다른 모든 인터넷 트래픽은 기존 default route를 따라 방화벽으로 계속 전달됩니다.

오답입니다. Google APIs는 VPC 내의 internal RFC1918 주소로 접근하지 않습니다. private/restricted Google access를 사용할 때는 잘 알려진 VIP range(예: 199.36.153.4/30 및 199.36.153.8/30)를 통해 접근합니다. “Google APIs의 internal IP addresses”로 default internet gateway에 라우팅하는 것은 유효하거나 의미 있는 구성이 아니며 목표를 달성하지 못합니다.

문제 분석

핵심 개념: 이 문제는 외부 IP가 없는 VM이 Google APIs에 프라이빗하게 접근하도록 하면서도, 커스텀 라우트를 사용해 일반 인터넷 egress는 서드파티 방화벽을 통해 강제하는 방법을 테스트합니다. 핵심 서비스는 Private Google Access (PGA)와 VPC routing/route priority 동작입니다. 정답이 맞는 이유: 1) analytics-subnet에서 Private Google Access를 활성화합니다. PGA는 내부 IP만 가진 VM이 Google의 네트워크를 통해 Google APIs 및 서비스에 접근할 수 있게 해주며, Google APIs VIP(예: restricted.googleapis.com 또는 private.googleapis.com)를 대상으로 합니다. PGA가 없으면 해당 VM은 외부 IP가 있거나 proxy/NAT 경로를 사용하지 않는 한 Google APIs에 접근할 수 없습니다. 2) Google APIs VIP range에 대해 default internet gateway로 향하는 더 구체적인(static) 라우트를 추가합니다. 방화벽을 가리키는 기존 0.0.0.0/0 라우트(priority 100)는 유지해야 합니다. Google Cloud routing에서는 priority보다 먼저 가장 구체적인(가장 긴 prefix) 라우트가 우선합니다. 따라서 Google APIs VIP(들)에 대한 라우트(/0보다 더 구체적)를 추가하면 기본 라우트를 오버라이드하여 해당 트래픽만 방화벽을 우회해 internet gateway로 직접 보내고, 다른 모든 목적지는 여전히 0.0.0.0/0에 매칭되어 방화벽을 계속 통과합니다. 핵심 기능 / 구성: - Private Google Access는 subnet 단위로 활성화됩니다(VPC 단위가 아님). 범위를 제한하기 위해 analytics-subnet에만 적용합니다. - 문서화된 Google APIs VIP range(private.googleapis.com 199.36.153.8/30 및/또는 restricted.googleapis.com 199.36.153.4/30)를 사용하고, default internet gateway로 향하는 custom route를 생성합니다. 또한 subnet의 DNS가 Google APIs를 의도한 VIP로 resolve하도록 보장해야 합니다(대개 Cloud DNS policy 또는 on-prem DNS forwarding rule을 통해). - 이 설계는 Google Cloud Architecture Framework(보안 및 네트워크 설계)와 부합합니다: 최소 권한 routing(필요한 것만 예외로 분리)과 그 외 트래픽에 대한 중앙 집중식 inspection. 흔한 오해: - Private Services Access는 Private Service Connect/peering(예: Cloud SQL)을 사용해 서비스에 프라이빗하게 연결하기 위한 것이며, Google APIs 접근을 활성화하지 않습니다. - “Google APIs의 internal IP addresses”라는 표현은 잘못입니다. Google APIs는 내부 RFC1918 주소가 아니라 VIP를 통해 접근합니다. 시험 팁: - 라우트 선택 순서를 기억하세요: longest prefix match가 먼저, 그 다음 priority. - PGA는 subnet 레벨입니다. 문제가 “일부 subnet이 외부 IP 없이 Google APIs가 필요”라고 하면, (방화벽/proxy로 향하는 default route가 존재할 때) PGA + DNS + specific route를 떠올리세요.

8
문제 8

Helios Labs operates three product squads—API, Batch, and Analytics—each requiring Compute Engine instances in us-central1, europe-west1, and asia-east1 (up to 20 VMs per squad per region) and separate projects for billing isolation and least-privilege access. Your 2-person network/security team must retain centralized control of IP space 10.64.0.0/12, including subnets, routes, and firewall rules, avoid overlapping subnets, and minimize operational overhead for inter-squad connectivity. How should you design the Google Cloud network topology?

정답입니다. 단일 Shared VPC host project는 IP 공간(10.64.0.0/12), subnet 생성, routes, firewall rules를 중앙집중화하면서, 각 스쿼드가 billing isolation과 least privilege를 위해 자체 service project에서 운영할 수 있게 합니다. Subnet 수준 IAM(예: Compute Network User)을 통해 스쿼드는 network admin 권한 없이 VM을 배포할 수 있습니다. 모든 워크로드가 하나의 VPC routing domain을 공유하므로 connectivity 오버헤드를 최소화하고 CIDR overlap을 방지합니다.

오답입니다. 3개의 독립 VPC와 full-mesh HA VPN은 상당한 운영 오버헤드(여러 gateways, tunnels, routing, monitoring)와 비용을 추가합니다. 또한 프로젝트 전반에 걸친 subnets 및 firewall rules의 중앙집중식 제어를 제공하지 못하며, 각 VPC는 독립적으로 관리됩니다. VPN은 일반적인 조직 내 east-west connectivity보다는 하이브리드 connectivity 또는 public internet 상의 암호화가 필요한 경우에 더 적합합니다.

틀렸습니다. 세 개의 별도 Shared VPC host project를 사용하면 여전히 환경이 세 개의 개별 VPC network로 분리되며, 각각은 자체 routing domain, firewall rules, subnet administration을 갖게 됩니다. 중앙 팀이 해당 host들 전반에 걸쳐 IP allocation을 수동으로 조정할 수는 있지만, 이 설계는 요청된 단일 권한 있는 network control plane이나 가장 단순한 east-west connectivity 모델을 제공하지 않습니다. squad 간 통신에는 여전히 VPC Network Peering 또는 VPN과 같은 추가 구성이 필요하며, 이는 모든 squad를 하나의 Shared VPC에 배치하는 것과 비교해 운영 오버헤드를 증가시킵니다.

오답입니다. VPC Network Peering은 VPN 대비 일부 오버헤드를 줄이지만, 여전히 각 VPC에서 firewall 및 route 관리가 분산되는 별도의 routing/security domain을 생성하므로 중앙집중식 제어 요구사항에 반합니다. Peering은 설계 제약( transitive peering 불가, 신중한 route exchange 계획 필요)도 있으며, 외부에서 IPAM을 강제하지 않는 한 overlapping subnets를 본질적으로 방지하지 못합니다. 여기서는 Shared VPC가 더 깔끔한 거버넌스 모델입니다.

문제 분석

핵심 개념: 이 문제는 멀티 프로젝트 환경에서의 Shared VPC 설계를 평가하며, 분산된 워크로드 소유권을 가능하게 하면서 중앙집중식 네트워크 거버넌스(IPAM, subnets, routes, firewall policy)를 강조합니다. 또한 east-west connectivity에 대한 운영 오버헤드를 최소화하고 CIDR 중복을 방지하는 것도 다룹니다. 정답이 맞는 이유: 10.64.0.0/12를 사용하는 단일 Shared VPC host project는 하나의 권위 있는 IP 공간과 하나의 VPC routing domain을 제공합니다. 세 개의 service projects(API, Batch, Analytics)를 연결하면 프로젝트 수준에서 billing isolation과 least-privilege access를 유지하면서도, 모든 스쿼드가 us-central1, europe-west1, asia-east1의 중앙에서 제어되는 subnets에 VM을 배포할 수 있습니다. 모든 인스턴스가 동일한 VPC에 있으므로 스쿼드 간 connectivity는 네이티브로 제공되며(peering/VPN mesh 불필요), 네트워크/보안 팀은 subnets, routes, firewall rules에 대한 중앙집중식 제어를 유지합니다. 이는 제시된 요구사항과 정확히 일치합니다. 주요 기능 / 모범 사례: - Shared VPC host project가 VPC network, subnets, routes, firewall rules를 소유하고, service projects는 이를 소비합니다. - Subnet 수준 IAM 위임(예: 특정 subnets에 대한 Compute Network User)을 통해 스쿼드가 광범위한 network admin 권한 없이 인스턴스를 생성할 수 있습니다. - 중앙집중식 firewall 거버넌스는 hierarchical firewall policies(organization/folder) 또는 host-project firewall rules로 구현할 수 있으며, Google Cloud Architecture Framework의 거버넌스 및 보안 원칙에 부합합니다. - 단일 IP 계획(10.64.0.0/12)은 설계상 overlap을 방지하며, regional subnets는 리전당 스쿼드별 최대 20개 VM과 성장 버퍼를 고려해 크기를 산정할 수 있습니다. 흔한 오해: 팀들이 별도 VPC를 연결하기 위해 VPC peering 또는 VPN을 선택하는 경우가 많지만, 이는 운영 오버헤드를 증가시키고 firewall/routing 제어를 분절시킵니다. Peering은 transitivity 제한도 있으며 중앙집중식 보안 posture를 복잡하게 만들 수 있습니다. 시험 팁: “billing/least privilege를 위한 별도 projects”와 “subnets/routes/firewalls의 중앙집중식 제어”, “overlap 방지”가 함께 보이면 Shared VPC가 기본 패턴입니다. 단순한 east-west connectivity와 중앙집중식 거버넌스를 원할 때는 단일 Shared VPC를 선호하고, 별도 routing domain을 유지해야 하거나 조직 간/하이브리드 환경을 연결해야 할 때 주로 peering/VPN을 사용합니다.

9
문제 9

Your company runs a manufacturing plant with an on-premises Juniper SRX gateway in Tokyo (ASN 65010) that must exchange routes dynamically with a Google Cloud VPC in asia-northeast1. You have already created an HA VPN gateway in Google Cloud and a peer VPN gateway that points to the SRX public IPs. The on-prem network advertises 172.20.0.0/16, and the VPC will advertise 10.60.0.0/16 and 10.61.0.0/16, with the requirement that any future subnets be learned automatically without manual updates. What should you do next to complete the setup for dynamic routing?

정답입니다. Cloud VPN에서의 동적 라우팅은 Cloud Router와 BGP가 필요합니다. asia-northeast1에 Cloud Router를 생성한 다음, HA VPN gateway에 tunnel 2개(interface당 1개)를 만들고 tunnel당 1개의 BGP session을 구성하여 온프레미스 ASN 65010과 peering합니다. 이렇게 하면 수동 업데이트 없이 현재 및 향후 route를 자동으로 학습/advertise할 수 있고 high availability도 제공합니다.

오답입니다. static route를 추가하는 것은 향후 subnet을 자동으로 학습해야 한다는 요구사항과 모순됩니다. static route는 새 VPC subnet이 생성되거나 온프레미스 prefix가 변경될 때마다 수동 변경이 필요합니다. Cloud Router가 static route와 함께 존재할 수는 있지만, static routing은 “dynamic routing”이 아니며 BGP 기반 HA VPN 연결을 위한 의도된 해법이 아닙니다.

오답입니다. HA VPN은 이미 두 interface를 포함하고 있어 tunnel 2개로 이중화를 설계하도록 되어 있으므로 두 번째 HA VPN gateway는 불필요합니다. 또한 일반적으로 Cloud Router로의 BGP(tcp/179)를 허용하기 위해 VPC firewall rule을 만들지 않습니다. Cloud Router는 관리형 control-plane 서비스이며, VPC 내에서 BGP packet을 직접 수신하는 VM endpoint가 아닙니다.

오답입니다. global dynamic routing을 활성화하면 asia-northeast1에서 학습된 route를 다른 리전에서도 사용할 필요가 있을 때 유용할 수 있지만, 필요한 Cloud Router + BGP 구성을 대체하지는 못합니다. 두 번째 HA VPN gateway를 만드는 것 또한 불필요합니다. 누락된 핵심 단계는 기존 HA VPN gateway tunnel을 통해 Cloud Router로 BGP session을 설정하는 것입니다.

문제 분석

핵심 개념: 이 문제는 HA VPN + Cloud Router(BGP)를 사용한 하이브리드 연결의 동적 라우팅을 평가합니다. Google Cloud에서 Cloud VPN을 통한 동적 경로 교환에는 HA VPN gateway와 동일한 리전에 있는 Cloud Router가 필요하며, 각 VPN tunnel 위에 BGP session을 설정해야 합니다. 정답이 맞는 이유: 이미 HA VPN gateway와 peer VPN gateway(온프레미스 Juniper SRX)가 있습니다. 경로를 동적으로 교환하고(그리고 향후 subnet을 자동으로 학습하려면) Cloud Router와 BGP를 사용해야 합니다. 올바른 다음 단계는 다음과 같습니다: asia-northeast1에 Google 측 ASN(충돌하지 않는 임의의 private ASN, 예: 64514)으로 Cloud Router를 생성하고, 온프레미스 peer로 향하는 VPN tunnel을 2개(HA VPN interface당 1개) 생성한 뒤, tunnel당 1개씩 BGP session을 구성하여 SRX ASN 65010과 peering합니다. BGP가 올라오면 SRX는 172.20.0.0/16을 advertise할 수 있고, Google은 VPC subnet route(10.60.0.0/16, 10.61.0.0/16 및 향후 subnet)를 수동 route 변경 없이 advertise할 수 있습니다. 주요 기능 / 모범 사례: - HA VPN은 두 개의 interface를 제공합니다. 모범 사례는 이중화를 위해 tunnel 2개와 BGP session 2개를 구성하는 것입니다. - Cloud Router는 관리형 BGP speaker로, 적격 VPC subnet route를 자동으로 advertise하고 온프레미스 prefix를 학습합니다. - BGP IP(link-local /30)가 양쪽에서 일관되게 구성되었는지, 그리고 Cloud Router가 HA VPN gateway와 동일한 리전에 있는지 확인하세요. - VPC dynamic routing mode(regional vs global)를 고려하세요. global은 학습된 route를 리전 간에 전파하려는 경우에만 필요하며, asia-northeast1에서 BGP를 설정하는 것 자체에는 필수는 아닙니다. 흔한 오해: - static route가 “dynamic routing” 요구사항을 충족한다고 생각하는 것(그렇지 않으며, 향후 subnet에 대해 수동 업데이트가 필요합니다). - HA를 위해 두 번째 HA VPN gateway가 필요하다고 믿는 것(HA VPN은 이미 두 interface로 이중화를 제공합니다). - Cloud Router로의 BGP에 firewall rule이 필요하다고 가정하는 것. Cloud Router는 VM이 아니며 BGP는 VPN/IKE/IPsec 구성 내부에서 동작합니다. 시험 팁: “향후 subnet을 자동으로 학습” 같은 키워드가 나오면 Cloud Router + BGP를 찾으세요. HA VPN의 경우 동일 리전에서 tunnel 2개와 BGP session 2개를 기대하세요. 학습된 route의 리전 간 전파가 명시적으로 요구될 때만 “global dynamic routing”을 선택하세요.

10
문제 10
(2개 선택)

Aurora Analytics ordered two 10-Gbps Dedicated Interconnect circuits at the Equinix TY2 facility in Tokyo under project net-prod-123 and named the first interconnect aurora-ty2-ic1; you must provide the Letter of Authorization/Connecting Facility Assignment (LOA-CFA) to the colocation provider within 5 business days to complete the cross-connect. During the order, you specified noc-aurora@aurora.example as the NOC contact email. Which two actions will allow you to obtain the LOA-CFA documents? (Choose two.)

Cloud Support 케이스를 여는 것은 LOA-CFA를 얻는 표준 또는 필수 방법이 아닙니다. 일반적인 Dedicated Interconnect 프로비저닝에서는 LOA-CFA가 셀프서비스 메커니즘(Console 다운로드 및 NOC contact로의 email)을 통해 제공됩니다. Support는 비정상 상황(예: LOA-CFA 미생성, 접근 문제, 잘못된 연락처 정보)에서만 도움을 줄 수 있지만, 시험에서 기대하는 주요 조치 중 하나는 아닙니다.

정답입니다. Google Cloud Console은 Hybrid Connectivity/Cloud Interconnect 섹션에서 Dedicated Interconnect에 대한 LOA-CFA를 제공합니다. 특정 interconnect 리소스(예: aurora-ty2-ic1)를 선택한 뒤, 코로케이션 제공업체가 cross-connect를 완료하는 데 필요한 LOA-CFA 문서를 다운로드합니다. 이는 일반적인 운영 단계이며 Dedicated Interconnect의 셀프서비스 프로비저닝 워크플로와 일치합니다.

오답입니다. gcloud compute interconnects describe 명령은 리소스 메타데이터(state, location, link type 등)를 반환하지만, 표준 CLI 출력의 일부로 LOA-CFA PDF를 직접 다운로드하지는 않습니다. API/console에서 LOA-CFA 조회가 노출될 수는 있으나, 제시된 명령은 cross-connect 주문을 위한 LOA-CFA 문서 자체를 다운로드하는 전형적이거나 문서화된 방법이 아닙니다.

정답입니다. Google은 Dedicated Interconnect 주문 시 지정한 NOC contact email로 LOA-CFA를 전송합니다. noc-aurora@aurora.example가 NOC contact로 제공되었으므로, 필요한 기간 내에 LOA-CFA를 얻기 위해 해당 받은편지함을 확인하는 것은 적절한 방법입니다. 이것이 interconnect 운영에서 모니터링되는 NOC 배포 리스트를 사용하는 것이 모범 사례인 이유입니다.

오답입니다. Google은 일반적으로 완전한 핸즈오프 방식으로 LOA-CFA를 코로케이션 제공업체에 직접 보내지 않습니다. 고객이 보통 LOA-CFA를 제공업체에 제공하여 cross-connect를 승인하고 지시해야 합니다. 제공업체에 아무 조치가 필요 없다고 말하면 5영업일 윈도우를 놓치고 회선 개통이 지연되어 프로젝트 일정과 중복성 목표에 영향을 줄 수 있습니다.

문제 분석

핵심 개념: 이 문제는 Dedicated Cloud Interconnect를 프로비저닝하기 위한 운영 단계, 특히 Letter of Authorization/Connecting Facility Assignment (LOA-CFA)를 어떻게 가져오는지(조회/다운로드)를 평가합니다. LOA-CFA는 코로케이션 제공업체가 시설(여기서는 Equinix TY2)에서 고객 라우터와 Google의 interconnect 포트 간 물리적 cross-connect를 완료하는 데 필요합니다. 이는 하이브리드 연결 라이프사이클 관리의 일부입니다. 정답이 맞는 이유: LOA-CFA 문서는 일반적으로 두 가지 표준 방법으로 얻을 수 있습니다. 첫째, Google Cloud Console에서 Hybrid Connectivity (Cloud Interconnect) 아래의 해당 interconnect 리소스에서(예: aurora-ty2-ic1) LOA-CFA를 다운로드할 수 있습니다. 둘째, Google은 주문 시 지정한 NOC contact email로 LOA-CFA를 전송하므로, 해당 받은편지함을 확인하는 것도 유효한 조회 방법입니다. 이는 기대되는 워크플로와 일치합니다. 즉, interconnect가 프로비저닝되어 cross-connect 준비 상태가 되면 LOA-CFA가 사용 가능해지고 운영 연락처로 배포됩니다. 주요 기능 / 모범 사례: Dedicated Interconnect는 고객, 코로케이션 제공업체, Google의 세 주체 간 조율이 필요합니다. LOA-CFA에는 cross-connect 주문에 필요한 meet-me room/cage 정보와 포트 식별자 같은 세부 정보가 포함됩니다. 모범 사례는 NOC email을 모니터링되는 배포 리스트로 설정하고, 감사 가능성을 위해 LOA-CFA를 통제된 저장소에 다운로드/보관하는 것입니다. Google Cloud Architecture Framework 관점에서 이는 Operational Excellence(반복 가능한 프로비저닝 프로세스)와 Reliability(특히 dual circuits에서 중복성/가용성 목표를 충족하기 위한 물리적 연결의 적시 완료)를 지원합니다. 흔한 오해: Cloud Support에 반드시 연락해야 한다고(A) 생각하기 쉽지만, LOA-CFA는 예외 상황(접근 권한 상실, 프로비저닝 문제) 이외에는 보통 Console/email을 통한 셀프서비스로 제공됩니다. 또한 Google이 LOA-CFA를 코로케이션 제공업체에 직접 보낸다고(E) 가정하는 경우가 흔한데, 실제로는 고객이 제공업체에 LOA-CFA를 제공하여 cross-connect를 시작하는 경우가 일반적입니다. 시험 팁: Dedicated Interconnect의 순서를 기억하세요: 포트 주문 -> LOA-CFA 수신/다운로드 -> 코로케이션에 cross-connect 요청 -> VLAN attachments(interconnect attachments) 구성 -> BGP. “LOA-CFA를 어떻게 얻는가”를 묻는다면 “Console 다운로드”와 “NOC email”을 떠올리면 됩니다.

합격 후기(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

← 모든 Google Professional Cloud Network Engineer 문제 보기

지금 학습 시작하기

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.