GCP Professional Cloud Architect Practice Question

Your organization is designing a multi-environment Apigee X deployment. Strict security policy requires the following:

Back-end microservices run in private GKE clusters inside two separate VPC networks: prod-svc-vpc and nonprod-svc-vpc. These VPCs must not be exposed to the public internet.
Only Apigee should receive client traffic; clients must never connect directly to the clusters.
Operational teams want clean separation of IAM, quotas, and billing between production and non-production while keeping administration effort low.

Which network architecture best satisfies the requirements?

Create one Apigee organization in a shared project and configure two environments (prod and non-prod) on a single Apigee instance that is attached to a shared VPC network peered to both service VPCs.
Create separate VPC networks for prod and non-prod in the same Google Cloud project, deploy all Apigee instances there, and use Cloud NAT so the runtime nodes call backend services through their public IP addresses.
Create two Google Cloud projects, one per environment. In each project create an Apigee organization with a single Apigee instance whose runtime uses its own VPC network. Peer apigee-prod-vpc only with prod-svc-vpc and apigee-nonprod-vpc only with nonprod-svc-vpc.
Create one Apigee organization with two instances that share the same runtime VPC; use firewall rules instead of VPC peering to reach the private GKE clusters over the public internet.

Report Issue

Answer Description

Using two Apigee organizations, each in its own Google Cloud project, gives hard separation of IAM policies, runtime quotas, and billing. Each organization contains one Apigee instance whose runtime nodes live in a dedicated VPC network (apigee-prod-vpc and apigee-nonprod-vpc). Peering each runtime VPC only with the corresponding service VPC lets the instance reach the private GKE clusters without exposing them publicly and avoids transitive connectivity between environments. Because Apigee X automatically manages the runtime VPCs, the only operational task is creating the two peering connections, so administration remains simple. The alternative designs either mix prod and non-prod traffic in the same Apigee org (reducing quota/ IAM isolation), rely on firewall rules alone without VPC peering (backend cannot be reached from a private Apigee runtime), or attempt to reuse a single runtime VPC for both instances (violates hard separation and introduces overlapping-IP risk).

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.