Manage and provision a solution infrastructure Study Guide — Professional Cloud Architect

Manage and Provision a Solution Infrastructure

This domain accounts for 15% of the PCA exam and tests your ability to design repeatable, scalable, and auditable infrastructure on Google Cloud. Expect questions on selecting the right provisioning tool, structuring the resource hierarchy for policy and billing isolation, building CI/CD pipelines, managing GKE and compute fleets, and controlling cost through quotas, labels, and preemptible capacity. Questions often require you to choose between two valid-sounding services, so precision on defaults, limits, and behavioral differences is critical.

Infrastructure as Code: Terraform on GCP and Cloud Deployment Manager

Terraform is an open-source, provider-agnostic IaC tool that Google officially recommends for GCP. It uses HCL (HashiCorp Configuration Language) and stores state in a backend—on GCP this is typically a Cloud Storage bucket for remote, shared state. Terraform interacts with GCP through the Google provider, and resources are managed via terraform apply / terraform destroy / terraform plan.

Cloud Deployment Manager is Google's native IaC service. It uses YAML, Jinja2, or Python templates and requires no external tooling. Deployment Manager is tightly integrated with GCP IAM and does not require managing state files—state is stored server-side by GCP. However, it is GCP-only, less extensible than Terraform, and is being de-emphasized in favor of Terraform in new guidance.

Common traps

• The exam may imply you must use Deployment Manager for GCP-only projects. Terraform is equally valid and preferred.
• Terraform state stored locally is a single point of failure—always move state to a GCS bucket for team use.
• terraform import brings existing resources under management but does not generate HCL for you.
• Deployment Manager does not automatically delete resources removed from a config unless the deployment is updated or deleted.

Worked scenario: A team needs to provision identical VPC networks across 10 GCP projects using a shared codebase reusable by other cloud teams. → Use Terraform with a GCS remote backend and modules. Deployment Manager cannot serve other clouds, and local state breaks multi-user workflows.

Google Cloud Resource Hierarchy: Organization, Folders, Projects

The GCP resource hierarchy is Organization → Folders → Projects → Resources. Policies set at a higher level are inherited downward; more permissive policies at a lower level cannot override a Deny policy above (with IAM Deny policies) but an Allow policy at a lower level can grant access that a parent does not grant.

Organization node is the root, tied to a Cloud Identity or Google Workspace domain. Folders provide grouping for departments, teams, or environments and can be nested up to 10 levels deep. Projects are the billing and API-enablement boundary; all GCP resources exist inside a project. A project has a Project ID (globally unique, immutable), Project Name (mutable), and Project Number (numeric, immutable).

IAM inheritance rule: Effective policy = union of policies at resource level + all ancestor levels. A policy at the organization level that grants roles/owner propagates to all folders and projects beneath it.

Common traps

• Folders cannot be attached directly to a billing account—billing is always attached at the project level.
• Moving a project between folders does not change its Project ID or Number but may change inherited IAM policies immediately.
• Organization policies (e.g., constraints/compute.vmExternalIpAccess) override project-level IAM—they are distinct from IAM policies.
• Labels are applied at the resource level for cost allocation; they are not part of the hierarchy.