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:
- What is the workload? VM, container, serverless app, data pipeline, database, static content, analytics, or operations task.
- What level of management is desired? Fully managed, serverless, managed platform, or self-managed infrastructure.
- What is the scope? Organization, folder, project, region, zone, subnet, bucket, service account, or resource.
- Who or what needs access? Human user, group, service account, workload identity, external identity, or Google-managed service.
- What is the safest minimal change? Least privilege, no broad basic roles, no public access unless explicitly required.
- What is the operational outcome? Deploy, scale, monitor, troubleshoot, back up, restore, update, or reduce cost.
Common ACE answer pattern
| Scenario wording | Likely 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.
| Level | What to remember |
|---|---|
| Organization | Top-level resource for a company using Google Cloud |
| Folder | Optional grouping under an organization |
| Project | Main boundary for resources, APIs, IAM, billing association, and quotas |
| Resource | VM, 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
| Trap | Better 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 needed | Grant access on the specific resource if possible |
| Forgetting API enablement | If deployment fails because a service is unavailable, check whether the API is enabled |
| Confusing billing account with project ownership | Billing 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
| Concept | Review point |
|---|---|
| Principal | User, group, service account, domain, or other identity |
| Role | Collection of permissions |
| Permission | Specific action, such as compute.instances.get |
| Policy | Bindings of principals to roles on a resource |
| Basic roles | Owner, Editor, Viewer; broad and usually not best practice |
| Predefined roles | Google-managed roles for specific services/tasks |
| Custom roles | User-defined permissions for stricter least privilege |
| Service account | Identity used by workloads and automation |
Service account decision rules
| Need | Use |
|---|---|
| VM or app needs to call Google APIs | Attach a service account with required IAM roles |
| User needs to deploy a VM using a service account | Grant Service Account User on that service account |
| User or automation needs to impersonate a service account | Grant appropriate impersonation permission, such as Service Account Token Creator where required |
| GKE workload needs Google Cloud API access | Prefer Workload Identity / workload identity-based access rather than long-lived keys |
| External system needs access without service account keys | Prefer Workload Identity Federation where suitable |
| Application needs a secret | Use 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
| Task | Command pattern to recognize |
|---|---|
| Authenticate user | gcloud auth login |
| Use application default credentials locally | gcloud auth application-default login |
| Set project | gcloud config set project PROJECT_ID |
| Set default region | gcloud config set compute/region REGION |
| Set default zone | gcloud config set compute/zone ZONE |
| List active config | gcloud config list |
| Manage configurations | gcloud config configurations ... |
| Enable an API | gcloud services enable SERVICE_NAME |
| View IAM policy | gcloud projects get-iam-policy PROJECT_ID |
| Add IAM binding | gcloud projects add-iam-policy-binding ... |
Quick setup checklist
- Create or select the correct project.
- Confirm billing association if resources will be created.
- Enable required APIs.
- Set
gcloudproject, region, and zone. - Create least-privilege service accounts.
- Grant only required IAM roles.
- Deploy resources.
- 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.
| Feature | Review point |
|---|---|
| Machine type | CPU/memory shape; choose appropriately for workload |
| Boot disk | Persistent disk used for OS |
| Persistent Disk | Durable block storage; zonal or regional options |
| Local SSD | High performance but ephemeral |
| Instance template | Reusable VM configuration for managed instance groups |
| Managed instance group | Autoscaling, autohealing, rolling updates |
| Startup script | Boot-time configuration via metadata |
| Shielded VM | Security hardening features |
| Spot VMs | Lower-cost, interruptible workloads |
Managed instance group traps
| Trap | Correction |
|---|---|
| Using unmanaged groups for autohealing/autoscaling | Use managed instance groups |
| Forgetting health check firewall rules | Allow health check ranges where required |
| Manually changing instances in a MIG | Update template or rolling update strategy |
| Expecting zonal MIG to survive zone failure | Use regional MIG for multi-zone resilience |
GKE
Use Google Kubernetes Engine when the scenario requires Kubernetes orchestration.
| Concept | Review point |
|---|---|
| Cluster | Kubernetes control plane plus nodes or managed capacity |
| Node pool | Group of nodes with common configuration |
| Pod | Smallest deployable workload unit |
| Service | Stable network endpoint for pods |
| Ingress / Gateway | HTTP(S) routing into cluster workloads |
| Autopilot | More managed GKE mode; less node management |
| Standard | More 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
| Service | Best fit |
|---|---|
| App Engine | Managed web app platform with versions and traffic splitting |
| Cloud Functions | Event-driven functions for lightweight code triggered by events |
| Cloud Run | More flexible container-based serverless runtime |
Networking Quick Review
Networking questions often test scope, connectivity, and firewall behavior.
VPC fundamentals
| Item | Scope / behavior |
|---|---|
| VPC network | Global resource |
| Subnet | Regional resource |
| VM internal IP | Belongs to a subnet |
| Firewall rule | Applies to VPC traffic based on direction, priority, target, and source/destination |
| Route | Controls traffic path |
| Cloud NAT | Outbound internet for private resources without external IPs |
| VPC peering | Private connectivity between VPCs; not transitive |
| Shared VPC | Central 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:
- VM exists and service is listening.
- Correct internal or external IP.
- Firewall allows traffic.
- Route exists.
- OS-level firewall permits traffic.
- Health checks are allowed if behind a load balancer.
Connectivity decisions
| Requirement | Likely solution |
|---|---|
| VM with no external IP needs outbound internet | Cloud NAT |
| Private Google API access from subnet | Private Google Access |
| Private connectivity between VPCs | VPC Network Peering |
| Shared network managed centrally | Shared VPC |
| Hybrid connectivity over public internet with encryption | Cloud VPN |
| Dedicated/private hybrid connection | Cloud Interconnect |
| Protect HTTP(S) app from web attacks | Cloud Armor |
| Identity-aware access to app or SSH/RDP | Identity-Aware Proxy where appropriate |
Load balancing decision table
| Requirement | Review direction |
|---|---|
| External HTTP(S) app | Application Load Balancer |
| Internal HTTP(S) service | Internal Application Load Balancer |
| TCP/UDP pass-through | Network Load Balancer option |
| Global user-facing web app | Global external HTTP(S) load balancing where applicable |
| Private internal service | Internal load balancing |
| Serverless backend | Serverless 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.
| Feature | Review point |
|---|---|
| Bucket | Container for objects; globally unique name |
| Object | Stored file/blob |
| Location | Region, dual-region, or multi-region |
| Storage class | Standard, Nearline, Coldline, Archive based on access pattern |
| Lifecycle policy | Automatically transition or delete objects |
| Object versioning | Preserve older versions |
| Retention policy | Prevent deletion/modification for a defined retention period |
| Uniform bucket-level access | Simplifies access by using IAM instead of object ACLs |
| Signed URL | Time-limited access to a specific object |
Storage class decision rules
| Access pattern | Likely class |
|---|---|
| Frequently accessed | Standard |
| Infrequently accessed, occasional retrieval | Nearline |
| Rarely accessed | Coldline |
| Long-term archive | Archive |
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
| Need | Service |
|---|---|
| VM boot or attached block storage | Persistent Disk |
| High-performance temporary VM storage | Local SSD |
| Shared NFS file storage | Filestore |
| Object/blob storage | Cloud Storage |
Database and analytics choices
| Requirement | Service to consider |
|---|---|
| Managed MySQL/PostgreSQL/SQL Server | Cloud SQL |
| Horizontally scalable relational database | Cloud Spanner |
| Serverless document database | Firestore |
| Wide-column, low-latency, high-throughput workloads | Bigtable |
| Data warehouse and analytics SQL | BigQuery |
| In-memory cache | Memorystore |
| Object-based data lake storage | Cloud Storage |
Database traps
| Trap | Better answer |
|---|---|
| Using BigQuery for transactional application storage | Use Cloud SQL, Spanner, Firestore, or Bigtable depending need |
| Using Cloud Storage like a relational database | Use a database service |
| Choosing Spanner for a small simple app | Cloud SQL is often more appropriate |
| Choosing Cloud SQL for global horizontal relational scale | Consider Spanner |
| Choosing Bigtable for ad hoc SQL analytics | Consider BigQuery |
| Ignoring backups and HA | Review 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
- Build container image.
- Store image in Artifact Registry.
- Deploy to Cloud Run, GKE, or another runtime.
- Configure service account and environment settings.
- Set traffic routing, scaling, and networking.
- Monitor logs, metrics, and errors.
Common deployment tools
| Tool / service | Review point |
|---|---|
| gcloud CLI | Direct command-line deployment and administration |
| Cloud Shell | Browser-based shell with Google Cloud tools |
| Cloud Build | Build and CI automation |
| Artifact Registry | Store container images and packages |
| Cloud Deploy | Delivery pipeline support for selected deployment workflows |
| Terraform / IaC | Repeatable infrastructure provisioning |
| kubectl | Kubernetes operations against GKE clusters |
Safe release patterns
| Pattern | Purpose |
|---|---|
| Rolling update | Gradually replace old instances/pods |
| Canary | Send small traffic portion to new version |
| Blue/green | Switch between two production-ready environments |
| Traffic splitting | Route percentages across revisions/versions |
| Rollback | Return 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
| Need | Service / feature |
|---|---|
| Metrics and dashboards | Cloud Monitoring |
| Alerts | Alerting policies |
| Logs | Cloud Logging |
| Log-based metric | Metric derived from logs |
| Export logs | Log sinks |
| Error grouping | Error Reporting |
| Distributed request traces | Cloud Trace |
| Application profiling | Cloud Profiler |
| Audit visibility | Cloud Audit Logs |
| Service health | Uptime checks and dashboards |
Logs decision table
| Requirement | Use |
|---|---|
| View recent application logs | Logs Explorer |
| Alert on log pattern | Log-based metric plus alerting policy |
| Retain logs outside default retention | Log sink to Cloud Storage or BigQuery |
| Analyze logs with SQL | Sink logs to BigQuery |
| Stream logs to external system | Sink to Pub/Sub |
| Store long-term audit records cheaply | Sink to Cloud Storage |
Audit logs
Know the broad categories:
| Audit log type | What it captures |
|---|---|
| Admin Activity | Administrative changes to resources |
| Data Access | Data reads/writes where enabled and applicable |
| System Event | Google Cloud system actions |
| Policy Denied | Access denied by policy controls |
Troubleshooting sequence
| Symptom | First checks |
|---|---|
| VM unreachable by SSH | IAM/OS Login, firewall, external/internal IP, IAP, routes, instance status |
| App behind load balancer unhealthy | Health check path/port, firewall, backend service, instance group, app listener |
| Cloud Run returns permission error | Service account IAM, invoker permissions, secret access, API enablement |
| GKE pods not starting | Pod events, image pull errors, resource requests, service account, node health |
| API call denied | Caller identity, IAM role, API enabled, resource scope, organization policy |
| Unexpected cost spike | Billing 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
| Need | Service / feature |
|---|---|
| Manage secrets | Secret Manager |
| Manage encryption keys | Cloud KMS |
| Protect web apps | Cloud Armor |
| Access apps based on identity | Identity-Aware Proxy |
| Manage Linux login with IAM | OS Login |
| Isolate private workloads | VPC, firewall rules, private IPs |
| Reduce data exfiltration risk | VPC Service Controls where appropriate |
| Scan/secure artifacts | Artifact-related security features where configured |
Security traps
| Trap | Better approach |
|---|---|
| Put credentials in startup scripts | Use service accounts and Secret Manager |
| Give users service account keys | Prefer impersonation or federation |
| Make bucket public for temporary sharing | Use signed URLs or scoped IAM when possible |
| Use Editor for deployment automation | Grant specific deployment and resource roles |
| Assume encryption requires manual setup | Google 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
| Need | Review point |
|---|---|
| Track spend | Billing reports |
| Notify on spend | Budgets and alerts |
| Attribute cost | Labels and project structure |
| Reduce VM cost for predictable usage | Committed use discounts where appropriate |
| Reduce cost for fault-tolerant workloads | Spot VMs |
| Avoid idle spend | Stop/delete unused resources |
| Reduce storage cost | Lifecycle policies and correct storage class |
| Avoid surprise egress | Understand 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
| Requirement | Design direction |
|---|---|
| Survive instance failure | Managed instance group with autohealing |
| Survive zone failure | Regional managed instance group or regional service design |
| Durable object storage | Cloud Storage |
| Block storage replicated across zones | Regional Persistent Disk where appropriate |
| Database HA | Use managed HA/replication options for the selected database |
| Disaster recovery | Backups, replicas, tested restore procedures |
| Global user performance | Global 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.
| Task | What to know |
|---|---|
| Create VM | project, zone, machine type, image, network, service account |
| SSH to VM | firewall, IAM/OS Login, external IP or IAP path |
| Create bucket | globally unique name, location, storage class |
| Deploy Cloud Run | image, region, service account, ingress/auth settings |
| Create GKE cluster | mode, region/zone, node pools or Autopilot |
| Configure IAM | add/remove policy bindings at correct scope |
| Enable monitoring | metrics, logs, dashboards, alerts |
| Export logs | create sink and destination permissions |
| Use Cloud Shell | preconfigured 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 area | What to drill |
|---|---|
| IAM | Role scope, service accounts, impersonation, least privilege |
| Networking | VPC/subnet scope, firewall rules, NAT, peering, load balancers |
| Compute | Compute Engine vs GKE vs Cloud Run vs App Engine vs Cloud Functions |
| Storage | Cloud Storage classes, lifecycle, access, disks, Filestore |
| Databases | Cloud SQL, Spanner, Firestore, Bigtable, BigQuery selection |
| Operations | Logging, Monitoring, alerts, troubleshooting, audit logs |
| Deployment | Artifact Registry, Cloud Build, GKE deployments, Cloud Run revisions |
| Cost | Budgets, labels, idle resources, storage class, VM discount options |
| Reliability | MIGs, 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:
- Start with topic drills for IAM, networking, compute, and storage.
- Review every missed question using detailed explanations.
- Convert each miss into a rule: service choice, IAM scope, network path, or operational sequence.
- Take mixed sets from the question bank to practice switching topics quickly.
- 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.