QuestionQ187

Designing for security and compliance

Your organization uses distinct Google Cloud projects for shared services, development, testing, and production.

  • The shared services project contains private CI/CD runners and a centralized Artifact Registry.
  • The development, testing, and production projects contain the GKE clusters on which applications are deployed.

You must design an architecture that lets the CI/CD runners connect to the GKE clusters and lets the clusters pull images from Artifact Registry, all through private IP addresses. Direct network traffic among the development, testing, and production environments must, however, be strictly prohibited. What should you do?

  • A Create a separate VPC in each of the four projects. Connect each environment's VPC to the shared services VPC through VPC Network Peering.
  • B Expose the resources in the shared services project using an external load balancer. Implement a firewall rule to limit access.
  • C Create a separate VPC in each project. Use VPC Network Peering to create a full mesh, connecting every VPC directly to every other VPC.
  • D Configure the shared services project as a Shared VPC host. Create a single VPC in this host project and attach the environment projects as service projects.
Explanation

A hub-and-spoke VPC Network Peering design gives each environment private internal connectivity to the shared-services VPC, allowing access to shared CI/CD and GKE-related resources. VPC Network Peering is not transitive, so environments peered only with shared services cannot communicate with one another through that VPC. Private GKE access to Artifact Registry can use private Google API access, including the restricted VIP configuration where required.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!