ACE — Google Cloud Associate Cloud Engineer Quick Review

Quick Review for Google Cloud ACE candidates: high-yield concepts, decision rules, common traps, and practice focus areas.

Quick Review purpose

This Quick Review is for candidates preparing for the Google Cloud Certified Associate Cloud Engineer (ACE) exam. It focuses on high-yield ideas you should be able to apply quickly before moving into topic drills, mock exams, and detailed explanations.

The ACE exam is practical. Expect scenario-style decisions about setting up cloud environments, deploying workloads, managing access, operating resources, and choosing appropriate Google Cloud services. The key is not just knowing product names; it is knowing what to do first, what is safest, what is managed, and what avoids unnecessary operational work.

Use this page to review the decision rules, then validate them with IT Mastery topic drills, mock exams, original practice questions, and detailed explanations.

High-yield ACE mindset

For most ACE scenarios, ask:

  1. What is the workload? VM, container, serverless app, data pipeline, database, static content, analytics, or operations task.
  2. What level of management is desired? Fully managed, serverless, managed platform, or self-managed infrastructure.
  3. What is the scope? Organization, folder, project, region, zone, subnet, bucket, service account, or resource.
  4. Who or what needs access? Human user, group, service account, workload identity, external identity, or Google-managed service.
  5. What is the safest minimal change? Least privilege, no broad basic roles, no public access unless explicitly required.
  6. What is the operational outcome? Deploy, scale, monitor, troubleshoot, back up, restore, update, or reduce cost.

Common ACE answer pattern

Scenario wordingLikely direction
“Minimum operations”Prefer managed/serverless services
“Need full OS control”Compute Engine
“Containerized app without managing nodes”Cloud Run or GKE Autopilot, depending Kubernetes needs
“Kubernetes required”Google Kubernetes Engine
“HTTP app, scale to zero, stateless”Cloud Run
“Traditional relational database”Cloud SQL
“Global relational scale”Cloud Spanner
“Analytics over large datasets”BigQuery
“Low-latency wide-column/time-series at scale”Bigtable
“Object storage, static assets, backups”Cloud Storage
“No external IP but needs outbound internet”Cloud NAT
“Private connection between VMs in same VPC”Internal IP, firewall rules
“Grant access to a workload”Service account with least-privilege IAM
“Grant user ability to attach a service account”Service Account User role on that service account
“Monitor availability”Uptime checks, alerting policies, Cloud Monitoring
“Analyze logs centrally”Cloud Logging, log sinks, BigQuery/Cloud Storage/Pub/Sub

Google Cloud resource hierarchy

Google Cloud resources are organized hierarchically. Many ACE questions test where to apply permissions or policies.

LevelWhat to remember
OrganizationTop-level resource for a company using Google Cloud
FolderOptional grouping under an organization
ProjectMain boundary for resources, APIs, IAM, billing association, and quotas
ResourceVM, bucket, dataset, service account, cluster, database, etc.

Decision rules

  • Use projects to separate environments, applications, teams, or billing boundaries.
  • IAM policies are commonly inherited down the hierarchy.
  • Grant access at the lowest practical level.
  • Avoid granting broad access at the organization or folder level unless there is a clear administrative need.
  • A project must generally have required APIs enabled before services can be used.
  • A project must be associated with billing for billable resources.

Candidate traps

TrapBetter thinking
Granting Owner or Editor because something “does not work”Identify the missing permission and use a predefined or custom least-privilege role
Applying project-level access when only one bucket/dataset is neededGrant access on the specific resource if possible
Forgetting API enablementIf deployment fails because a service is unavailable, check whether the API is enabled
Confusing billing account with project ownershipBilling pays for resources; IAM controls access

IAM and service accounts

IAM is one of the most important ACE areas. You need to distinguish who is acting, what they are accessing, and what role is required.

IAM essentials

ConceptReview point
PrincipalUser, group, service account, domain, or other identity
RoleCollection of permissions
PermissionSpecific action, such as compute.instances.get
PolicyBindings of principals to roles on a resource
Basic rolesOwner, Editor, Viewer; broad and usually not best practice
Predefined rolesGoogle-managed roles for specific services/tasks
Custom rolesUser-defined permissions for stricter least privilege
Service accountIdentity used by workloads and automation

Service account decision rules

NeedUse
VM or app needs to call Google APIsAttach a service account with required IAM roles
User needs to deploy a VM using a service accountGrant Service Account User on that service account
User or automation needs to impersonate a service accountGrant appropriate impersonation permission, such as Service Account Token Creator where required
GKE workload needs Google Cloud API accessPrefer Workload Identity / workload identity-based access rather than long-lived keys
External system needs access without service account keysPrefer Workload Identity Federation where suitable
Application needs a secretUse Secret Manager, not hardcoded environment variables or source code

IAM traps

  • Roles are not the same as OAuth scopes. For Compute Engine access to Google APIs, both IAM permissions and access scopes can matter. A common modern pattern is broad API scope with least-privilege IAM.
  • Service account keys are risky. Prefer attached service accounts, impersonation, or federation instead of downloading long-lived keys.
  • Default service accounts are often overused. Create purpose-specific service accounts where practical.
  • Viewer does not mean “safe for all data.” Some viewer roles can expose sensitive configuration or metadata.

Projects, gcloud, and environment setup

ACE candidates should be comfortable with common administrative setup tasks.

gcloud review

TaskCommand pattern to recognize
Authenticate usergcloud auth login
Use application default credentials locallygcloud auth application-default login
Set projectgcloud config set project PROJECT_ID
Set default regiongcloud config set compute/region REGION
Set default zonegcloud config set compute/zone ZONE
List active configgcloud config list
Manage configurationsgcloud config configurations ...
Enable an APIgcloud services enable SERVICE_NAME
View IAM policygcloud projects get-iam-policy PROJECT_ID
Add IAM bindinggcloud projects add-iam-policy-binding ...

Quick setup checklist

  1. Create or select the correct project.
  2. Confirm billing association if resources will be created.
  3. Enable required APIs.
  4. Set gcloud project, region, and zone.
  5. Create least-privilege service accounts.
  6. Grant only required IAM roles.
  7. Deploy resources.
  8. Configure monitoring, logging, and alerts.

Compute service selection

Choosing the right compute service is a core ACE skill.

    flowchart TD
	    A[Need to run application code] --> B{Need full OS control?}
	    B -->|Yes| C[Compute Engine]
	    B -->|No| D{Containerized?}
	    D -->|Yes| E{Need Kubernetes API/control?}
	    E -->|Yes| F[Google Kubernetes Engine]
	    E -->|No| G[Cloud Run]
	    D -->|No| H{Event-driven function?}
	    H -->|Yes| I[Cloud Functions]
	    H -->|No| J[App Engine or managed platform option]

Compute Engine

Use Compute Engine when you need VM-level control.

FeatureReview point
Machine typeCPU/memory shape; choose appropriately for workload
Boot diskPersistent disk used for OS
Persistent DiskDurable block storage; zonal or regional options
Local SSDHigh performance but ephemeral
Instance templateReusable VM configuration for managed instance groups
Managed instance groupAutoscaling, autohealing, rolling updates
Startup scriptBoot-time configuration via metadata
Shielded VMSecurity hardening features
Spot VMsLower-cost, interruptible workloads

Managed instance group traps

TrapCorrection
Using unmanaged groups for autohealing/autoscalingUse managed instance groups
Forgetting health check firewall rulesAllow health check ranges where required
Manually changing instances in a MIGUpdate template or rolling update strategy
Expecting zonal MIG to survive zone failureUse regional MIG for multi-zone resilience

GKE

Use Google Kubernetes Engine when the scenario requires Kubernetes orchestration.

ConceptReview point
ClusterKubernetes control plane plus nodes or managed capacity
Node poolGroup of nodes with common configuration
PodSmallest deployable workload unit
ServiceStable network endpoint for pods
Ingress / GatewayHTTP(S) routing into cluster workloads
AutopilotMore managed GKE mode; less node management
StandardMore control over nodes and cluster configuration

Cloud Run

Use Cloud Run for stateless containers with minimal operations.

High-yield points:

  • Runs containers.
  • Scales based on requests/events.
  • Can scale to zero.
  • Uses revisions and traffic splitting.
  • Good for HTTP APIs, web apps, background services, and containerized jobs.
  • Store images in Artifact Registry.
  • Use environment variables for non-secret config and Secret Manager for secrets.

App Engine and Cloud Functions

ServiceBest fit
App EngineManaged web app platform with versions and traffic splitting
Cloud FunctionsEvent-driven functions for lightweight code triggered by events
Cloud RunMore flexible container-based serverless runtime

Networking Quick Review

Networking questions often test scope, connectivity, and firewall behavior.

VPC fundamentals

ItemScope / behavior
VPC networkGlobal resource
SubnetRegional resource
VM internal IPBelongs to a subnet
Firewall ruleApplies to VPC traffic based on direction, priority, target, and source/destination
RouteControls traffic path
Cloud NATOutbound internet for private resources without external IPs
VPC peeringPrivate connectivity between VPCs; not transitive
Shared VPCCentral host project shares subnets with service projects

Firewall rules

Remember:

  • Firewall rules are stateful.
  • Lower priority number wins.
  • Rules have direction: ingress or egress.
  • Targets can use network tags or service accounts.
  • Default VPCs and custom VPCs may have different preconfigured behavior.
  • If a VM cannot be reached, check:
    1. VM exists and service is listening.
    2. Correct internal or external IP.
    3. Firewall allows traffic.
    4. Route exists.
    5. OS-level firewall permits traffic.
    6. Health checks are allowed if behind a load balancer.

Connectivity decisions

RequirementLikely solution
VM with no external IP needs outbound internetCloud NAT
Private Google API access from subnetPrivate Google Access
Private connectivity between VPCsVPC Network Peering
Shared network managed centrallyShared VPC
Hybrid connectivity over public internet with encryptionCloud VPN
Dedicated/private hybrid connectionCloud Interconnect
Protect HTTP(S) app from web attacksCloud Armor
Identity-aware access to app or SSH/RDPIdentity-Aware Proxy where appropriate

Load balancing decision table

RequirementReview direction
External HTTP(S) appApplication Load Balancer
Internal HTTP(S) serviceInternal Application Load Balancer
TCP/UDP pass-throughNetwork Load Balancer option
Global user-facing web appGlobal external HTTP(S) load balancing where applicable
Private internal serviceInternal load balancing
Serverless backendServerless network endpoint group where supported

Networking traps

  • Cloud NAT is outbound only. It does not allow inbound connections to private VMs.
  • VPC peering is not transitive. If A peers with B and B peers with C, A does not automatically reach C through B.
  • Subnets are regional. Do not treat a subnet as global.
  • Firewall and IAM are different. IAM grants control-plane access; firewall rules control packet flow.
  • External IP is not required for every workload. Private resources can use Cloud NAT or private access patterns.

Storage and database selection

Cloud Storage

Use Cloud Storage for object storage: backups, static assets, logs, data lake objects, and durable unstructured storage.

FeatureReview point
BucketContainer for objects; globally unique name
ObjectStored file/blob
LocationRegion, dual-region, or multi-region
Storage classStandard, Nearline, Coldline, Archive based on access pattern
Lifecycle policyAutomatically transition or delete objects
Object versioningPreserve older versions
Retention policyPrevent deletion/modification for a defined retention period
Uniform bucket-level accessSimplifies access by using IAM instead of object ACLs
Signed URLTime-limited access to a specific object

Storage class decision rules

Access patternLikely class
Frequently accessedStandard
Infrequently accessed, occasional retrievalNearline
Rarely accessedColdline
Long-term archiveArchive

Do not choose a colder class just because it is cheaper to store. Retrieval frequency, minimum storage duration, and access costs matter.

Block, file, and object storage

NeedService
VM boot or attached block storagePersistent Disk
High-performance temporary VM storageLocal SSD
Shared NFS file storageFilestore
Object/blob storageCloud Storage

Database and analytics choices

RequirementService to consider
Managed MySQL/PostgreSQL/SQL ServerCloud SQL
Horizontally scalable relational databaseCloud Spanner
Serverless document databaseFirestore
Wide-column, low-latency, high-throughput workloadsBigtable
Data warehouse and analytics SQLBigQuery
In-memory cacheMemorystore
Object-based data lake storageCloud Storage

Database traps

TrapBetter answer
Using BigQuery for transactional application storageUse Cloud SQL, Spanner, Firestore, or Bigtable depending need
Using Cloud Storage like a relational databaseUse a database service
Choosing Spanner for a small simple appCloud SQL is often more appropriate
Choosing Cloud SQL for global horizontal relational scaleConsider Spanner
Choosing Bigtable for ad hoc SQL analyticsConsider BigQuery
Ignoring backups and HAReview backup, restore, replication, and regional availability options

Deployment and release management

ACE candidates should recognize common deployment paths and operationally safe release patterns.

Container deployment flow

  1. Build container image.
  2. Store image in Artifact Registry.
  3. Deploy to Cloud Run, GKE, or another runtime.
  4. Configure service account and environment settings.
  5. Set traffic routing, scaling, and networking.
  6. Monitor logs, metrics, and errors.

Common deployment tools

Tool / serviceReview point
gcloud CLIDirect command-line deployment and administration
Cloud ShellBrowser-based shell with Google Cloud tools
Cloud BuildBuild and CI automation
Artifact RegistryStore container images and packages
Cloud DeployDelivery pipeline support for selected deployment workflows
Terraform / IaCRepeatable infrastructure provisioning
kubectlKubernetes operations against GKE clusters

Safe release patterns

PatternPurpose
Rolling updateGradually replace old instances/pods
CanarySend small traffic portion to new version
Blue/greenSwitch between two production-ready environments
Traffic splittingRoute percentages across revisions/versions
RollbackReturn to known-good version quickly

Deployment traps

  • Do not manually patch one VM in a managed instance group and expect it to persist.
  • Do not store secrets in source code or container images.
  • Do not grant deployment pipelines broad Owner permissions unless explicitly justified.
  • If a service cannot pull an image, check Artifact Registry permissions and image path.
  • If Kubernetes deployment fails, check namespace, image, service account, pod events, and logs.

Operations, monitoring, and troubleshooting

The ACE exam often presents broken or incomplete systems and asks for the next operational step.

Observability services

NeedService / feature
Metrics and dashboardsCloud Monitoring
AlertsAlerting policies
LogsCloud Logging
Log-based metricMetric derived from logs
Export logsLog sinks
Error groupingError Reporting
Distributed request tracesCloud Trace
Application profilingCloud Profiler
Audit visibilityCloud Audit Logs
Service healthUptime checks and dashboards

Logs decision table

RequirementUse
View recent application logsLogs Explorer
Alert on log patternLog-based metric plus alerting policy
Retain logs outside default retentionLog sink to Cloud Storage or BigQuery
Analyze logs with SQLSink logs to BigQuery
Stream logs to external systemSink to Pub/Sub
Store long-term audit records cheaplySink to Cloud Storage

Audit logs

Know the broad categories:

Audit log typeWhat it captures
Admin ActivityAdministrative changes to resources
Data AccessData reads/writes where enabled and applicable
System EventGoogle Cloud system actions
Policy DeniedAccess denied by policy controls

Troubleshooting sequence

SymptomFirst checks
VM unreachable by SSHIAM/OS Login, firewall, external/internal IP, IAP, routes, instance status
App behind load balancer unhealthyHealth check path/port, firewall, backend service, instance group, app listener
Cloud Run returns permission errorService account IAM, invoker permissions, secret access, API enablement
GKE pods not startingPod events, image pull errors, resource requests, service account, node health
API call deniedCaller identity, IAM role, API enabled, resource scope, organization policy
Unexpected cost spikeBilling reports, labels, logs, autoscaling, data egress, idle resources

Security review

Least privilege checklist

  • Use groups for human access where possible.
  • Use service accounts for workloads.
  • Grant roles at the lowest suitable level.
  • Prefer predefined roles over basic roles.
  • Use custom roles only when predefined roles are too broad.
  • Avoid service account keys unless no safer option fits.
  • Rotate and manage secrets in Secret Manager.
  • Use Cloud KMS for encryption key management where customer-managed keys are required.
  • Use audit logs and monitoring for sensitive actions.

Common security services

NeedService / feature
Manage secretsSecret Manager
Manage encryption keysCloud KMS
Protect web appsCloud Armor
Access apps based on identityIdentity-Aware Proxy
Manage Linux login with IAMOS Login
Isolate private workloadsVPC, firewall rules, private IPs
Reduce data exfiltration riskVPC Service Controls where appropriate
Scan/secure artifactsArtifact-related security features where configured

Security traps

TrapBetter approach
Put credentials in startup scriptsUse service accounts and Secret Manager
Give users service account keysPrefer impersonation or federation
Make bucket public for temporary sharingUse signed URLs or scoped IAM when possible
Use Editor for deployment automationGrant specific deployment and resource roles
Assume encryption requires manual setupGoogle Cloud encrypts data by default; use CMEK only when customer-managed control is required

Cost and billing review

ACE cost questions usually test operational awareness, not deep financial modeling.

Cost control tools and behaviors

NeedReview point
Track spendBilling reports
Notify on spendBudgets and alerts
Attribute costLabels and project structure
Reduce VM cost for predictable usageCommitted use discounts where appropriate
Reduce cost for fault-tolerant workloadsSpot VMs
Avoid idle spendStop/delete unused resources
Reduce storage costLifecycle policies and correct storage class
Avoid surprise egressUnderstand data movement across regions/internet

Cost traps

  • Budgets and alerts notify; they do not automatically stop all spending unless you build automation.
  • Stopped VMs may still incur disk/IP-related charges.
  • Cold storage can cost more if accessed frequently.
  • Overprovisioned VMs and unused disks are common waste sources.
  • Cross-region and internet egress can matter in architecture questions.

Reliability and backup review

Availability concepts

RequirementDesign direction
Survive instance failureManaged instance group with autohealing
Survive zone failureRegional managed instance group or regional service design
Durable object storageCloud Storage
Block storage replicated across zonesRegional Persistent Disk where appropriate
Database HAUse managed HA/replication options for the selected database
Disaster recoveryBackups, replicas, tested restore procedures
Global user performanceGlobal load balancing/CDN patterns where suitable

Backup and restore traps

  • A snapshot is not the same as a machine image.
  • Backups are only useful if restore is tested.
  • High availability is not a substitute for backup.
  • Replication can copy accidental deletes or bad writes.
  • Regional/multi-region choices affect resilience, latency, and cost.

High-yield command and console tasks

You do not need to memorize every command, but you should recognize task-oriented command patterns.

TaskWhat to know
Create VMproject, zone, machine type, image, network, service account
SSH to VMfirewall, IAM/OS Login, external IP or IAP path
Create bucketglobally unique name, location, storage class
Deploy Cloud Runimage, region, service account, ingress/auth settings
Create GKE clustermode, region/zone, node pools or Autopilot
Configure IAMadd/remove policy bindings at correct scope
Enable monitoringmetrics, logs, dashboards, alerts
Export logscreate sink and destination permissions
Use Cloud Shellpreconfigured browser shell for administration

Common ACE mistakes to eliminate

Mistake checklist

  • Choosing the most powerful service instead of the simplest managed fit.
  • Granting Owner/Editor instead of least-privilege roles.
  • Forgetting service accounts are identities, not just configuration objects.
  • Confusing Cloud Storage, Persistent Disk, and Filestore.
  • Treating BigQuery as an OLTP database.
  • Assuming private VMs can reach the internet without Cloud NAT or another egress path.
  • Ignoring firewall rules when troubleshooting connectivity.
  • Using public access when signed URLs, IAM, IAP, or private networking would be safer.
  • Choosing Compute Engine when Cloud Run or App Engine would reduce operations.
  • Choosing serverless when the scenario requires OS-level control.
  • Ignoring region/zone scope.
  • Forgetting to enable required APIs.
  • Assuming monitoring exists without alert policies or uptime checks.
  • Not checking logs before changing infrastructure.

Rapid scenario drills

Use these prompts to test your decision speed before moving into full original practice questions.

Scenario 1: Private VM needs updates

A VM has no external IP address. It must download operating system updates from the internet.

Best direction: Cloud NAT for outbound internet access, with appropriate routes/firewall behavior. Do not assign a public IP unless the scenario requires inbound public access.

Scenario 2: User needs to deploy using a service account

A developer can create VMs but cannot attach the required service account.

Best direction: Grant the user permission to use that service account, commonly via Service Account User on the service account, while keeping resource permissions least-privilege.

Scenario 3: Static website assets

A team needs to store and serve static objects.

Best direction: Cloud Storage for objects. Consider bucket IAM, public access requirements, signed URLs, lifecycle rules, and caching/CDN depending scenario.

Scenario 4: Stateless container API

A containerized HTTP API must scale down when idle and requires minimal infrastructure management.

Best direction: Cloud Run, with image in Artifact Registry, appropriate service account, ingress/auth configuration, and monitoring.

Scenario 5: Kubernetes-specific platform

The application team requires Kubernetes APIs, custom controllers, and Kubernetes-native deployment workflows.

Best direction: GKE, selecting Autopilot or Standard based on control requirements.

Scenario 6: Analytics over terabytes

A business team wants SQL analysis over very large datasets.

Best direction: BigQuery, not Cloud SQL.

Scenario 7: VM group must self-heal

A web tier runs on Compute Engine and must replace unhealthy instances automatically.

Best direction: Managed instance group with health check, instance template, autoscaling/autohealing as needed, and firewall rules allowing health checks.

Practice focus map

Use this map to guide topic drills in a question bank.

Practice areaWhat to drill
IAMRole scope, service accounts, impersonation, least privilege
NetworkingVPC/subnet scope, firewall rules, NAT, peering, load balancers
ComputeCompute Engine vs GKE vs Cloud Run vs App Engine vs Cloud Functions
StorageCloud Storage classes, lifecycle, access, disks, Filestore
DatabasesCloud SQL, Spanner, Firestore, Bigtable, BigQuery selection
OperationsLogging, Monitoring, alerts, troubleshooting, audit logs
DeploymentArtifact Registry, Cloud Build, GKE deployments, Cloud Run revisions
CostBudgets, labels, idle resources, storage class, VM discount options
ReliabilityMIGs, backups, snapshots, regional design, restore decisions

How to use this Quick Review with practice

After reviewing the tables above, move directly into IT Mastery practice:

  1. Start with topic drills for IAM, networking, compute, and storage.
  2. Review every missed question using detailed explanations.
  3. Convert each miss into a rule: service choice, IAM scope, network path, or operational sequence.
  4. Take mixed sets from the question bank to practice switching topics quickly.
  5. Use mock exams only after your weak-topic accuracy improves.

A practical next step: complete a focused set of original practice questions on IAM and networking first, because those concepts appear across many Google Cloud ACE scenarios.

Continue in IT Mastery

Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official Google Cloud questions, copied live-exam content, or exam dumps.