GCP Cloud Architect common mistakes
GCP Cloud Architect · Understand the traps and how to avoid them.
Reading the case study once at the start, then answering case-study questions from memory and generic GCP best practice instead of the company's stated constraints (budget ceiling, existing team skills, regulatory scope, committed deadlines).
The case studies contain dozens of facts and the questions deliberately hinge on one or two of them (e.g., 'must remain on-premises for two years', 'auditors require key custody'). Candidates pattern-match to the 'most modern' or 'most scalable' option because it feels like the textbook answer.
What to do instead
Before answering any case-study block, write a one-page constraint sheet: business drivers, hard technical constraints, compliance requirements, current-state inventory, and explicit exclusions. For each option, first eliminate choices that violate a written constraint, then compare the survivors on the stated decision drivers, not on general elegance.
Choosing the compute platform by familiarity or by 'managed is always better' rather than by workload characteristics - recommending serverless for workloads that need OS-level control, third-party agents, licensed software tied to the OS, persistent local disks, or long-lived stateful connections.
Candidates memorize 'prefer managed services' as a rule and stop there. The exam rewards managed services only when the workload's requirements fit the abstraction; portability, kernel-level tuning, and legacy licensing are recurring traps.
What to do instead
Build a short decision checklist you apply to every compute question: OS/kernel access needed, custom agents or licensing, runtime duration and connection model, statefulness, portability requirement, and operational team size. Escalate from Functions/Cloud Run to GKE to Compute Engine as those requirements appear, and state the reason in your own words before picking.
Proposing console-driven, step-by-step manual configuration when the scenario mentions repeatable environments, audit trails, multiple teams, or frequent change - or proposing a bespoke scripting approach where a declarative pipeline is expected.
Many candidates have hands-on console experience and translate that directly into answers. The professional exam tests whether you can make environments reproducible and governable at scale, where manual steps are the failure mode being tested.
What to do instead
Default to infrastructure as code delivered through a CI/CD pipeline (Terraform or Config Controller for GCP resources, with policy validation in the pipeline and state stored centrally). Treat console steps as an acceptable answer only for one-off exploration, and remember Deployment Manager is a legacy option rather than the modern recommendation.
Designing a target architecture without checking the platform prerequisites and limits the design depends on: service quotas, per-region product availability, IP address space, org policy restrictions inherited from the folder hierarchy, and lead times for quota increases.
Quotas, org policies, and regional gaps are invisible until deployment, so candidates validate the logical design and never validate feasibility. Exam scenarios frequently hinge on an inherited constraint or a limit that a naive design exceeds.
What to do instead
After drafting any design, run a feasibility pass: list every service used and confirm it exists in the chosen regions; compute address space against expected growth; enumerate quotas that a scale-up or migration would breach and plan increases before cutover; and check what org policies are inherited and whether an exception process is needed.
Confusing the layers of Google Cloud access control - answering an identity question with a firewall rule, a data-exfiltration question with IAM, or a configuration-guardrail question with a VPC control.
IAM, VPC firewall rules, VPC Service Controls, org policy, and CMEK all sound like 'security', so candidates pick whichever they used most recently. The exam writes distractors that are correct controls at the wrong layer.
What to do instead
Anchor each control to the question it answers: IAM = who can do what on which resource; firewall and routes = whether packets can reach a resource; VPC Service Controls = whether data can leave a boundary through Google APIs regardless of IAM; org policy = what configuration is even permitted in a project; CMEK/EKM = who holds the key. Identify the layer the requirement names before evaluating options.
Over-engineering encryption (mandating CMEK or customer-managed keys everywhere) while under-engineering identity - recommending downloaded service account keys, basic roles such as Editor/Owner, or long-lived credentials for workloads and human access.
Candidates equate 'more key control' with 'more secure' and also reach for the simplest-looking authentication mechanism. Google Cloud encrypts data at rest by default, so added key management only helps when a specific requirement exists, while key files and broad roles are the actual recurring risks.
What to do instead
Apply encryption additions only when the scenario states a key-ownership, key-rotation, or residency requirement. For identity, default to short-lived credentials: Workload Identity Federation for external workloads, attached service accounts for GCP workloads, and predefined or custom roles scoped to specific resources, escalating to basic roles only when you can articulate why.
Applying the wrong cost lever: recommending committed use discounts or sustained use for spiky, short-lived, or unpredictable workloads; putting stateful or interruption-intolerant work on Spot VMs; or ignoring storage lifecycle and data-transfer costs in the estimate.
Cost questions reward matching the discount instrument to the usage profile, but candidates reach for the biggest-sounding saving or the tool they know. Egress and storage-class costs are invisible in diagrams, so they get omitted from TCO answers.
What to do instead
Classify the workload first (steady-state baseline vs. variable peak vs. batch-tolerant), then pick levers: commitments for the predictable baseline, autoscaling and Spot for the elastic or fault-tolerant portion, storage lifecycle and class changes for aging data, and explicitly account for network egress between regions and to the internet in any cost comparison.
Jumping straight to the target-state architecture in a migration scenario, with no assessment, no dependency-ordered migration waves, no data synchronization approach, and no cutover, rollback, or recovery validation criteria.
Diagrams are the most satisfying part of the answer, so candidates skip the unglamorous assessment phase. The exam tests whether you can de-risk the transition, and answers that describe the destination without describing how to get there safely are the distractors.
What to do instead
For every migration scenario, state four things before the target design: an assessment of the current estate (dependencies, usage, criticality), grouping into waves by dependency and business priority, the data movement and synchronization method, and explicit cutover criteria with a tested rollback path - plus how recovery will be validated, since backups alone are not a recovery plan.
Answering the end-state solution when the question asks for the immediate next step, the first thing the architect should do, or the correct escalation route.
The end-state answer is usually also technically valid, which makes it feel right, but the stem is testing sequencing and role boundaries. Candidates read for the technology and skim the framing words ('first', 'next', 'before').
What to do instead
Classify the stem before looking at the options: is this asking for a first action, an ongoing control, or an escalation? If it is a first action, the correct answer is almost always the smallest step that reduces uncertainty or secures approval - assess, define success criteria, run a proof of concept, align stakeholders on trade-offs - not the full architecture.
Monitoring resource metrics rather than user-facing outcomes - alerting on CPU, memory, or disk thresholds as the primary signal, with no defined SLIs/SLOs, no error budget policy, and no review loop after incidents.
Resource metrics are the easiest to imagine and are what tutorials show, so they crowd out service-level thinking. The operations domain is testing whether you can measure and improve reliability as experienced by users, not whether you can watch a dashboard.
What to do instead
For any reliability or operations question, define the SLI from the user's perspective, set an SLO with a target and window, alert on error-budget burn rather than raw utilization, and pair alerting policies with notification channels plus a post-incident review that feeds changes back into the design. Use utilization metrics only as secondary diagnostics.