ACE-Specialist common mistakes
ACE-Specialist · Understand the traps and how to avoid them.
Choosing the compute platform first (for example defaulting every workload to Compute Engine VMs or to GKE) and then justifying it, instead of extracting the workload's constraints before evaluating options.
Candidates anchor on the platform they use daily at work, and the decisive constraint (bursty vs steady traffic, statefulness, per-request latency budget, team operational capacity, budget ceiling) is usually buried in the final sentence of the scenario rather than stated up front.
What to do instead
Before looking at any answer choice, write down four things from the stem: traffic pattern, state requirements, operational capacity of the team, and cost/availability target. Then eliminate options that violate any one of them. If two options survive, prefer the one requiring the fewest moving parts to operate, since specialist-level items reward managed services unless a constraint explicitly rules them out.
Designing a network and identity layout in isolation, without checking whether the organization already enforces Shared VPC, VPC Service Controls perimeters, or organization policies that make the proposed design impossible.
Scenarios often describe an enterprise with a central networking team, and candidates design a standalone project with its own VPC and firewall rules, forgetting that the host/service project split and perimeter restrictions are givens, not choices.
What to do instead
Treat organization-level guardrails as hard constraints: when the stem mentions a central networking team, assume Shared VPC with the workload in a service project; when it mentions data exfiltration controls, assume a service perimeter and check that every dependency (including the API endpoints used by the workload) sits inside or is allowed by it. State the guardrail explicitly in your reasoning so a violated assumption becomes visible.
Proposing a migration or rollout plan that treats a stateful, write-active system as if it can simply be replicated and cut over, without a data synchronization, freeze, or rollback step.
Lift-and-shift and blue/green patterns are taught with stateless web tiers, so candidates reuse them for databases and file-backed applications, and they skip the cutover sequencing because the migration tooling appears to handle it.
What to do instead
Classify every component as stateless or stateful before choosing a pattern. For stateful components, name the replication mechanism, the write-freeze or dual-write window, the validation step, and the rollback trigger. If an answer choice contains no data-consistency step for a stateful workload, eliminate it regardless of how clean the rest of the plan sounds.
Losing track of resource scope and prerequisites: placing a resource in the wrong project or region, assuming a global resource is regional (or vice versa), or writing a deployment sequence that omits enabling the required APIs and creating the service identity first.
Console workflows hide these steps because they are performed automatically behind a single click, so hands-on experience does not surface the ordering dependency until a scripted deployment fails halfway through.
What to do instead
For each resource in the plan, note three attributes before writing steps: project, location scope (global, regional, zonal), and prerequisite APIs or identities. Sequence the plan as enable APIs, create identities and grants, create network and data resources, then create compute and front ends. When an answer choice groups creation steps in a different order, check whether a dependency is being satisfied too late.
Solving access requirements by granting primitive roles such as Owner or Editor, or by creating and downloading a service account key for an application, rather than using predefined or custom roles and a workload identity mechanism.
Primitive roles and exported keys are the fastest path to a working demo, and candidates transfer that habit into exam answers where the scenario stresses least privilege, key rotation burden, or workloads running on Google Cloud infrastructure.
What to do instead
Default to predefined roles scoped to the narrowest resource, and escalate to a custom role only when no predefined role fits. For any workload running on Google Cloud compute, prefer the attached service account or workload identity federation; reserve keys for genuine external/on-premises cases and pair them with rotation. Any option that fixes an access problem by broadening to Editor or by minting a key is almost always the distractor.
Assuming an IAM or policy change takes effect instantly and diagnosing the resulting permission error by adding more roles, instead of verifying effective access and checking for inherited denies, perimeter restrictions, or propagation delay.
Policy changes usually appear immediate in small test projects, so candidates do not build the verification step into their troubleshooting sequence and instead stack permissions until something works.
What to do instead
When access fails right after a grant, verify effective permissions for the principal on the specific resource and inspect the full policy inheritance chain including organization-level denies and service perimeters. Add the missing role only after confirming the binding exists and the principal is the one actually being used by the workload (the runtime service account, not the human operator).
Jumping straight to remediation (restarting, resizing, redeploying) on the first symptom instead of localizing the fault across the request path from load balancer to backend to application to dependency.
Under time pressure the visible symptom, such as a 502 or a latency spike, gets treated as the cause, and candidates never check which layer actually emitted the error, so the fix addresses a healthy tier.
What to do instead
Work outward from the layer that reported the failure: confirm the load balancer health check state and backend status, then the instance or pod logs, then dependency connectivity and quotas. Use the metric or log source that names the failing layer, and only change configuration once the failing hop is identified. If an option changes a component upstream of the observed error, it is premature.
Designing observability after the fact: no defined SLI or alerting policy, alerts wired to a metric that does not reflect user impact, or no notification channel attached, so the proposed monitoring would not actually page anyone.
Candidates focus on getting the resource running and treat logging and alerting as a checkbox, forgetting that an alert policy without a notification channel, or one keyed on CPU rather than on the user-facing signal, produces no actionable signal.
What to do instead
For any operational scenario, specify the signal, the threshold, the notification path, and who acts on it. Prefer user-facing indicators (error rate, latency percentile, health check failures) over resource saturation, and confirm the alert routes to a channel. Where the stem asks for root-cause investigation rather than paging, prefer logs with retention and export over metrics alone.
Treating infrastructure as code as a one-way generator: applying from local state or without a locking backend, then hand-editing resources in the console, and later assuming a plan that shows no changes means the deployed environment matches the code.
Local state works fine for a single operator and a single run, so the failure only appears with a team or a second pipeline, and drift is invisible unless it is actively detected.
What to do instead
Use a remote backend with state locking and versioning from the start, keep all environments applied from the same module versions, and prohibit console edits for managed resources. Treat a plan that unexpectedly shows no changes as a signal to verify which state file and workspace were used. When the scenario involves multiple operators or repeated pipelines, any answer relying on local state is wrong.
Ignoring cost and lifecycle mechanics: no labeling or budget alerts, no quota planning, no storage lifecycle or retention rules, and assuming discounts apply when the workload's usage pattern does not qualify.
Cost questions read like afterthoughts, so candidates answer with the architecturally ideal option and skip the controls that make spend attributable and bounded, or they assume committed-use and sustained-use discounts apply to bursty or short-lived workloads.
What to do instead
Attach a label scheme for cost attribution and a budget with alerts to any multi-resource design, check regional quotas before planning capacity, and define lifecycle or retention rules for storage and logs. Match discount mechanisms to the usage profile: sustained use for steady baseline, commitments for predictable long-running load, preemptible or spot for interruptible batch. If an option's cost claim contradicts the workload's pattern, it is the distractor.