Professional Cloud Architect (PCA) Certification Lab Map

The Professional Cloud Architect certification validates your ability to design, plan, and manage secure, scalable, highly available cloud solutions — and to justify the trade-offs behind every design choice. The RAD platform's four foundation modules give you a live laboratory for exactly those trade-offs: Services_GCP (the shared platform layer — VPC, Cloud SQL, Redis, Filestore, GKE, CMEK, VPC-SC), App_CloudRun and App_GKE (two deployment engines for the same containerized workload, embodying the serverless-vs-orchestrated decision the PCA exam returns to again and again), and App_Common (shared layers implementing discovery, secrets, IAM, storage, and CI/CD patterns). Every toggle in your deployment portal is a design decision you can deploy, inspect in the GCP console, and reverse.

How to use this guide

• Deploy one of the profiles below through your deployment portal, then work through the matching section guide(s).
• Each section guide pairs "why the exam cares" decision criteria with the exact variables that implement the concept, hands-on steps, and self-check questions.
• Use the coverage legend honestly: 📘 topics (hybrid connectivity, migration planning, Vertex AI, org hierarchy) must be studied outside the platform — the "Beyond the modules" blocks tell you what and where.
• Case studies (📘): the PCA exam includes scenario questions built on official case studies such as EHR Healthcare, Helicopter Racing League, Mountkirk Games, and TerramEarth. The modules are an excellent rehearsal ground: read a case study's requirements, then write down which portal variables would satisfy each one (e.g. EHR Healthcare's encryption and audit demands map to enable_cmek, enable_audit_logging, and enable_vpc_sc; Mountkirk Games' global, autoscaled, container-based platform maps to GKE Autopilot with a global Gateway and Cloud Armor). Where a requirement has no matching variable — hybrid Interconnect for TerramEarth, multi-region Spanner for Mountkirk — you have found a study gap.

Coverage legend

Symbol	Meaning
✅	Fully demonstrated — deploy it, see it, modify it in the RAD platform
🟡	Partially demonstrated — the modules touch the concept; supplement with docs
📘	Concept-only — not implemented by the modules; study pointers provided

Deployment profiles

Profile: Lean baseline

Purpose: the lowest-cost architecture — zonal database, scale-to-zero serverless, self-managed NFS VM — your reference point for every cost/availability trade-off. Modules: Services_GCP, then App_CloudRun.

Variable	Value
create_postgres	true (default)
postgres_database_availability_type	ZONAL (default)
create_network_filesystem	true (default — e2-small NFS/Redis VM)
min_instance_count	0 (default, App_CloudRun)
max_instance_count	1 (default, App_CloudRun)

Estimated incremental cost: low — the zonal db-custom-1-3840 Cloud SQL instance and the e2-small NFS VM dominate; Cloud Run scales to zero.

Profile: Resilient data tier

Purpose: upgrade the baseline to high availability so you can compare ZONAL vs REGIONAL Cloud SQL, BASIC vs STANDARD_HA Redis, and VM-based NFS vs managed Filestore side by side. Modules: Services_GCP (update in place), App_CloudRun unchanged.

Variable	Value
postgres_database_availability_type	REGIONAL
create_postgres_read_replica	true
create_redis	true
redis_tier	STANDARD_HA
redis_persistence_mode	RDB
create_filestore_nfs	true
filestore_tier	BASIC_HDD (default)

Estimated incremental cost: high — REGIONAL Cloud SQL roughly doubles instance cost, the read replica adds another instance, STANDARD_HA Redis doubles Redis cost, and Filestore bills a minimum 1024 GB.

Profile: GKE architecture

Purpose: deploy the same workload on GKE Autopilot to exercise the Cloud Run vs GKE decision, Kubernetes governance (quotas, PDBs, NetworkPolicy), and Gateway API exposure. Modules: Services_GCP (update), then App_GKE.

Variable	Value
create_google_kubernetes_engine	true (Services_GCP)
gke_cluster_mode	AUTOPILOT (default)
enable_resource_quota	true (App_GKE)
enable_network_segmentation	true (App_GKE)
enable_pod_disruption_budget	true (default, App_GKE)
stateful_pvc_enabled	true, with stateful_pvc_size = "10Gi" and a mount path

Estimated incremental cost: moderate — Autopilot bills per pod resource request plus a cluster management fee; the stateful PVC adds a small persistent disk.

Profile: Security and delivery

Purpose: layer in defense-in-depth (CMEK, Binary Authorization, VPC-SC dry run, audit logs) and a full CI/CD pipeline with progressive delivery — the backbone for Sections 3, 4, and 6. Modules: Services_GCP (update), App_CloudRun (update).

Variable	Value
enable_cmek	true (Services_GCP)
enable_binary_authorization	true, binauthz_evaluation_mode = "REQUIRE_ATTESTATION" (Services_GCP)
enable_vpc_sc	true, vpc_sc_dry_run = true (Services_GCP; needs org + admin_ip_ranges)
enable_audit_logging	true (Services_GCP)
enable_cloud_armor	true (application_domains optional on App_CloudRun)
enable_iap	true, plus iap_authorized_users (App_CloudRun)
enable_cicd_trigger	true, plus github_repository_url (App_CloudRun)
enable_cloud_deploy	true (App_CloudRun)
enable_auto_password_rotation	true (App_CloudRun)

Estimated incremental cost: moderate — KMS keys, the global load balancer forwarding rule, and audit-log storage are the main drivers; VPC-SC and Binary Authorization are free.

Section 1: Designing and planning a cloud solution architecture (~25% of the exam)

The heart of the PCA exam: choosing architectures that satisfy business and technical requirements. The modules embody the canonical trade-offs — serverless vs orchestrated compute, zonal vs regional databases, managed vs self-managed file storage — but business analysis, migration planning, and futures thinking live outside any Terraform module.

Exam topic	Coverage	Where in RAD	Guide
1.1 Business requirements (cost, security, success measures)	🟡	min_instance_count, create_billing_budget, enable_iap, support_users	Section 1 guide
1.2 Technical requirements (HA, scalability, reliability)	✅	postgres_database_availability_type, redis_tier, create_postgres_read_replica, HPA/PDB in App_GKE	Section 1 guide
1.3 Network, storage, and compute design	✅	VPC + Cloud NAT + private services access, Filestore vs self-managed NFS, App_CloudRun vs App_GKE	Section 1 guide
1.4 Creating a migration plan	📘	nearest: enable_backup_import data import jobs	Section 1 guide
1.5 Envisioning future solution improvements	📘	nearest: layered module architecture, discovery-vs-inline pattern	Section 1 guide

Section 2: Managing and provisioning a cloud solution infrastructure (~17.5% of the exam)

Provisioning is what the modules do for a living: a custom-mode VPC with Cloud NAT and private services access, four database engines, three flavors of file/object storage, and two container platforms — all declaratively. Hybrid topologies and the two Vertex AI subsections are study-only.

Exam topic	Coverage	Where in RAD	Guide
2.1 Configuring network topologies	🟡	availability_regions, subnet_cidr_range, Cloud NAT + private services access; no hybrid/Shared VPC	Section 2 guide
2.2 Configuring individual storage systems	✅	storage_buckets, backup_schedule, create_filestore_nfs, Cloud SQL PITR	Section 2 guide
2.3 Configuring compute systems	✅	gke_cluster_mode, gke_autoscaling_profile, container_resources, execution_environment	Section 2 guide
2.4 Leveraging Vertex AI for end-to-end ML workflows	📘	not implemented	Section 2 guide
2.5 Configuring prebuilt solutions or APIs with Vertex AI	📘	nearest: secret_environment_variables for API keys	Section 2 guide

Section 3: Designing for security and compliance (~17.5% of the exam)

The Security and delivery profile turns on most of what this section tests: dedicated least-privilege service accounts, CMEK with automatic rotation, Binary Authorization attestation, VPC Service Controls in dry-run mode, IAP zero-trust access, and comprehensive audit logging. Organization hierarchy and regulatory frameworks remain study topics.

Exam topic	Coverage	Where in RAD	Guide
3.1 Security — IAM, secrets, encryption, supply chain, perimeters	✅	enable_cmek, enable_binary_authorization, enable_vpc_sc, enable_iap, the platform's secrets and IAM layers	Section 3 guide
3.1 Security — resource hierarchy, org policies	📘	not implemented	Section 3 guide
3.1 Security — Workload Identity Federation (keyless CI)	✅	enable_workload_identity_federation, wif_provider_type (Services_GCP)	Section 3 guide
3.2 Compliance — auditability, ITAR/HIPAA-style controls	🟡	enable_audit_logging, enable_security_command_center, vpc_sc_dry_run	Section 3 guide

Section 4: Analyzing and optimizing technical and business processes (~15% of the exam)

CI/CD and release governance are fully demonstrable: a GitHub-triggered Cloud Build pipeline, Kaniko image builds into Artifact Registry, optional Binary Authorization attestation, and a Cloud Deploy pipeline whose default prod stage requires manual approval. SRE culture, post-mortems, and stakeholder management are people topics — study them separately.

Exam topic	Coverage	Where in RAD	Guide
4.1 Technical processes — SDLC, CI/CD, testing	🟡	enable_cicd_trigger, cloud_deploy_stages, traffic_split	Section 4 guide
4.2 Business processes — change management, decision-making	🟡	require_approval gates in cloud_deploy_stages; cost guardrails via create_billing_budget	Section 4 guide

Section 5: Managing implementation (~12.5% of the exam)

The platform is an implementation-management exhibit: a four-tier IaC architecture that development teams consume through a portal, with Artifact Registry hygiene policies and guardrail validations baked in. Raw SDK fluency (gcloud, client libraries, emulators) requires hands-on practice beyond the portal.

Exam topic	Coverage	Where in RAD	Guide
5.1 Advising development and operation teams	🟡	layered module architecture, max_images_to_retain, plan-time validations	Section 5 guide
5.2 Interacting with Google Cloud programmatically	🟡	OpenTofu workflow, gcloud-based provisioners and discovery scripts	Section 5 guide

Section 6: Ensuring solution and operations excellence (~12.5% of the exam)

Day-2 operations: every deployment ships a monitoring dashboard and email alert channels; Cloud SQL and the NFS VM get CPU/memory/disk alerts; releases can be canaried with traffic_split and promoted through Cloud Deploy. Publicly reachable deployments also get a synthetic uptime check and alert policy via uptime_check_config (provisioned by the platform's monitoring layer); support processes and chaos engineering are concept-only.

Exam topic	Coverage	Where in RAD	Guide
6.1 Operational excellence pillar (Well-Architected Framework)	🟡	automation throughout; auto-healing NFS MIG, plan-time CMEK key recovery	Section 6 guide
6.2 Familiarity with Google Cloud Observability solutions	✅	support_users, alert_policies, uptime_check_config, the platform monitoring layer	Section 6 guide
6.3 Deployment and release management	✅	traffic_split, cloud_deploy_stages, max_revisions_to_retain	Section 6 guide
6.4 Assisting with the support of deployed solutions	📘	nearest: support_users notification channels	Section 6 guide
6.5 Evaluating quality control measures	🟡	enable_vulnerability_scanning, Binary Authorization attestation step, the App_GKE plan-time validation suite	Section 6 guide
6.6 Ensuring the reliability of solutions in production	🟡	PDBs, topology spread, auto-healing NFS MIG, Redis production-tier guardrail	Section 6 guide

---

Application wrapper modules (Django, WordPress, and others) exist on the platform but are out of scope for these guides — everything here is demonstrated with the four foundation modules alone.