ACE-Associate common mistakes
ACE-Associate · Understand the traps and how to avoid them.
Creating projects and resources in the console without setting the active gcloud project (or forgetting to set it after switching accounts), so commands hit the wrong project or fail with a permissions error.
Candidates assume the console selection carries over to the CLI, or they switch accounts with gcloud auth login but never run gcloud config set project.
What to do instead
Always run gcloud config set project PROJECT_ID after authenticating, and verify with gcloud config list before running create/deploy commands.
Granting roles at the project level when the task calls for resource-level or least-privilege scoping, or using primitive roles like Owner/Editor to 'make it work'.
Primitive and broad roles are the quickest path to unblocking a permission error, so candidates stop there instead of reasoning about scope.
What to do instead
Identify the narrowest predefined role and attach it to the specific resource (bucket, dataset, instance) or use conditions; reserve primitive roles for cases explicitly requiring them.
Choosing between IAM roles and service accounts incorrectly, e.g., attaching a user's credentials to a workload or creating a service account key when the scenario supports workload identity or attached service accounts.
Key-based service accounts are the most familiar pattern, so candidates default to them even when the prompt describes a Compute Engine or GKE workload.
What to do instead
Match the credential to the workload: attached service accounts for Compute Engine, Workload Identity for GKE, and user credentials only for interactive human access.
Designing a VPC without accounting for subnet regionality, auto mode vs custom mode, or the default firewall rules, then failing questions about connectivity or isolation.
Candidates treat a VPC as a flat network and forget subnets are regional and that default rules allow broad ingress.
What to do instead
Explicitly state subnet region, choose custom mode when isolation is required, and reason about firewall rules per instance/tag before concluding connectivity.
Ignoring quotas and resource limits when planning a deployment, then proposing an architecture that cannot be provisioned in the target project.
Quotas are invisible in most design discussions, so candidates plan capacity without checking project-level limits.
What to do instead
Include a quota check step (per-region CPU, IP addresses, persistent disk) in the plan and note the need for quota increase requests.
Configuring autoscaling or load balancing without health checks and readiness, producing an architecture that routes traffic to unready instances.
Candidates focus on the scaling policy and skip the health-check wiring that gates traffic.
What to do instead
Specify a health check and, where applicable, a readiness probe, and confirm the backend service references them.
Setting up logging and monitoring after the fact and not knowing where to find logs (Cloud Logging vs serial console vs application logs) or how to create alerts from metrics.
Candidates memorize that logging exists but not the routing, retention, or metric-to-alert pipeline.
What to do instead
Practice the chain: log ingestion, log-based metric, alerting policy on that metric, and notification channel; know which log source answers which question.
Misreading billing and cost questions, e.g., assuming sustained-use discounts apply to all services or that committed-use discounts are automatic.
Cost mechanics are easy to conflate, and candidates apply discount models broadly.
What to do instead
Distinguish automatic discounts (sustained use) from opt-in commitments (committed use) and confirm which resource types each applies to.
Backing up or snapshotting without verifying restore, or assuming snapshots are regional/global when they are not.
Candidates equate taking a snapshot with having a recovery plan and skip the restore validation step.
What to do instead
Include a restore test in any backup design and state the snapshot's scope and cross-region behavior explicitly.
Failing to distinguish authentication from authorization when troubleshooting access, e.g., re-authenticating when the real issue is a missing IAM binding.
Both surface as 'permission denied', so candidates retry the login step instead of inspecting policy bindings.
What to do instead
Separate the two checks: confirm identity with gcloud auth list, then inspect effective permissions with gcloud projects get-iam-policy or the policy troubleshooter.