ACE sample questions — 25 answered and explained

Google Cloud resources have a location scope: global (VPC networks, images, firewall rules), regional (subnets, regional managed instance groups, static external regional IPs) or zonal (VM instances, zonal persistent disks). Scope decides what a zone or region outage takes down.

A Compute Engine VM instance is created in one zone and fails with it. VPC networks and custom images are global, and a subnet is regional, so none of them is lost when a single zone goes down.

1. Classify each option as global, regional or zonal.
2. Remember networks and images are global and subnets are regional.
3. Pick the only zonal resource: the VM instance.

Exam tip: VM instances and zonal disks are zonal; subnets are regional; VPC networks and images are global.

Workforce Identity Federation trusts an external identity provider (SAML 2.0 or OIDC) for human users. You create a workforce identity pool and provider at the organization level, map IdP attributes, and grant IAM roles to pool principals; no Google Accounts are created or synced.

Only Workforce Identity Federation gives employees console access without Cloud Identity accounts. GCDS and Cloud Identity SSO both still depend on user accounts in Cloud Identity, and Workload Identity Federation is the near-twin for applications rather than people.

1. Note the deciding constraint: no accounts created or synced in Cloud Identity.
2. Remove options that still need Cloud Identity users (GCDS, SSO).
3. Choose between Workforce (people) and Workload (applications) federation: the users are employees.

Exam tip: Workforce Identity Federation is for people, Workload Identity Federation is for workloads; neither creates Cloud Identity accounts.

Cloud Asset Inventory is a metadata inventory of resources, IAM policies and organization policies across a project, folder or organization. You can search it, export snapshots to BigQuery or Cloud Storage, and query asset history for up to 35 days.

Cloud Asset Inventory is the only option that produces both an organization-wide inventory of resources with their IAM policies and point-in-time history within the last 35 days. Audit logs capture the changes but not a ready inventory; IAM recommendations analyze permission usage; a get-iam-policy loop sees only current, project-level policies.

1. List the two needs: an organization-wide inventory and past policy state.
2. Recall that Cloud Asset Inventory keeps 35 days of asset history.
3. Reject tools that only see changes (audit logs) or only current project policies (gcloud loop).

Exam tip: Inventory plus history across the organization is Cloud Asset Inventory, within its 35-day history window.

IAM allow policies are additive. The effective permissions on a resource are the union of the bindings on the resource and all bindings inherited from its ancestors, whether granted to a user directly or through a group.

On web-prod the developer has the union of Viewer and Editor, which is Editor; on every other project only the inherited Viewer applies. No allow policy caps another, grants made through a group count fully, and a project-level binding never spreads to sibling projects.

1. Collect every binding that applies to each project.
2. Take the union on web-prod: Viewer plus Editor is Editor.
3. Take the union elsewhere: only the inherited Viewer.
4. Remember inheritance flows down only, never sideways.

Exam tip: Effective access is the union of the resource's bindings and its ancestors', and inheritance only flows downward.

Folders are the unit of delegation and policy scoping. Put the dimension that needs its own administrators and policies at the top folder level, so each department's IAM grants and organization policies attach once and inherit to all its projects.

Department folders with dev and prod subfolders let Finance's stricter policies attach once, to the Finance folder, and let each department's administrators be granted on their own folder. Environment-first folders scatter Finance across two subtrees; separate organizations fragment governance; a flat layout with labels has no inheritance at all.

1. Find the dimension that needs one policy and admin attachment point: the department.
2. Make it the top folder level, with environments as subfolders.
3. Check Finance: one folder, one policy attachment.
4. Reject labels as a policy boundary and separate organizations as over-fragmented.

Exam tip: Put the dimension that owns policy and delegation at the top of the folder tree.

Cloud Run's maximum concurrency setting controls how many requests one instance handles at once. For a given traffic level, the number of instances, and so the cost, falls as concurrency rises.

An I/O-bound service spends most of each request waiting, so one instance can interleave many requests. Setting concurrency near the tested safe value of 80 lets existing instances absorb spikes. Capping maximum instances is the tempting cost control, but with concurrency at 1 it would queue or reject requests. Minimum instances and bigger instances both raise cost.

1. Note the workload: I/O-bound, concurrency currently 1, one instance safely handles about 80.
2. Apply the constraint: lower cost without rejecting requests.
3. Raise maximum concurrency to about 80 (gcloud run services update --concurrency=80) and watch latency and instance count.

Exam tip: For I/O-bound Cloud Run services, raise per-instance concurrency to cut instances; capping instances instead turns away traffic.

Cloud Run deployment is a single gcloud operation: point gcloud run deploy at a container image in Artifact Registry and Google provisions the service, autoscaling, and a TLS-terminated HTTPS URL.

The requirement is a fully managed, autoscaling HTTPS service from an existing image in one command. gcloud run deploy does exactly that. kubectl needs a cluster to exist first, create-with-container gives a single unmanaged VM (and relies on the deprecated container startup agent), and gcloud builds submit only produces images.

1. Push the container image to Artifact Registry (already done).
2. Run gcloud run deploy with the image URL, choosing a region and allowing unauthenticated access if the service is public.
3. Use the HTTPS URL that Cloud Run returns; autoscaling and TLS are handled automatically.

Exam tip: gcloud run deploy turns a pushed container image into an autoscaling HTTPS service in one command.

Cloud Run functions are the source-code-first serverless option: you deploy a function and an entry point with an event trigger, such as a Cloud Storage object finalize event, and the platform builds, scales and invokes it.

A Cloud Run function triggered by the bucket's finalize event meets all three requirements: source only, near-immediate reaction to each upload, and scale to zero. The Cloud Run service with Eventarc is the near-twin and also event-driven, but it is deployed here from a container image the team would have to maintain. Polling VMs and hourly schedules are not event-driven and miss the latency requirement.

1. Identify the trigger: each completed object upload (finalize event).
2. Apply the constraints: source code only, seconds of latency, no idle charges.
3. Deploy a Cloud Run function with a Cloud Storage finalize trigger, for example gcloud functions deploy ... --trigger-bucket=BUCKET.

Exam tip: Small source-only code reacting to Cloud Storage uploads is the Cloud Run functions use case; choose a Cloud Run service when you ship your own container.

Eventarc routes events from Google Cloud sources, including Cloud Audit Logs entries filtered by service and method name, to destinations such as Cloud Run, in CloudEvents format, and manages the underlying transport.

Both the Eventarc trigger and a hand-built log sink to Pub/Sub with a push subscription would deliver the events within a few minutes, so the constraint decides: Eventarc needs one trigger, while the sink route needs a sink, a topic and a subscription you manage. A Cloud Storage export is batched hourly, and scheduled polling is not event-driven.

1. Identify the event source: Admin Activity audit log entries for firewall changes.
2. List workable delivery routes: an Eventarc audit-log trigger, or a log sink to Pub/Sub with push.
3. Apply the constraint (fewest resources to manage) and choose the Eventarc trigger.
4. Filter on serviceName compute.googleapis.com and the firewall insert, patch and delete methods.

Exam tip: To invoke Cloud Run from Google Cloud admin actions, create an Eventarc Cloud Audit Logs trigger; a sink to Pub/Sub works but is more to manage.

GPUs are the general-purpose accelerator (CUDA ecosystem, broad framework support, graphics and inference). TPUs are Google-designed ASICs optimised for large-scale tensor operations in frameworks such as JAX, TensorFlow and PyTorch/XLA.

The workload ticks every TPU box: very large models, dense matrix multiplication, a TPU-native framework, no CUDA dependency and sustained training where price-performance matters. High-end GPUs are the tempting choice and would work, but nothing in the scenario needs what GPUs uniquely offer. CPUs do not address the bottleneck.

1. Identify the computation: very large, dense matrix-multiply training.
2. Check the framework and dependencies: JAX, no CUDA.
3. Choose TPUs for sustained large-scale training; choose GPUs when CUDA, graphics or framework breadth is required.

Exam tip: Very large JAX/TensorFlow training without CUDA dependence points to TPUs; CUDA, graphics or mixed workloads point to GPUs.

Regional Persistent Disk (and Hyperdisk Balanced High Availability) replicate every write synchronously across two zones in one region, so a stateful VM can fail over to the other zone without data loss.

Zero lost transactions plus fast failover in the same region means synchronous cross-zone replication, which is regional Persistent Disk: on zone failure you force-attach the disk to the standby VM. Asynchronous Replication is the tempting option because it also replicates, but it is asynchronous and cross-region. Snapshots lose recent writes, and Local SSD is not replicated at all.

1. Translate the requirement: RPO of zero, failover in minutes, same region.
2. Zero data loss requires synchronous replication; asynchronous and snapshot-based options fail.
3. Use regional Persistent Disk and force-attach it to the standby VM in the replica zone on failure.

Exam tip: Zero data loss across zones in one region means regional Persistent Disk (or Hyperdisk Balanced HA); snapshots and async replication are backup and DR, not synchronous HA.

Hyperdisk provisions IOPS and throughput independently of capacity, and each Hyperdisk type has its own ceiling: Balanced for general workloads (up to 160,000 IOPS), Extreme for the highest-IOPS databases (up to 350,000), Throughput for sequential throughput.

Three requirements decide: about 250,000 IOPS on one volume, performance adjustable without buying capacity, and durability through a host failure. Hyperdisk Extreme meets all three. Hyperdisk Balanced is the near-twin with the same independent provisioning model, but its per-volume ceiling is lower. pd-extreme also caps far lower, and Local SSD scales only by adding fixed-size disks and loses data when the host fails.

1. Quantify the need: about 250,000 IOPS on one volume, durable data.
2. Prefer Hyperdisk, which provisions performance separately from capacity.
3. Compare per-volume ceilings: Balanced 160,000, Extreme 350,000.
4. Attach Hyperdisk Extreme and set its provisioned IOPS.

Exam tip: Highest-IOPS durable block storage tuned independently of size is Hyperdisk Extreme; Hyperdisk Balanced caps lower and Local SSD is tied to the host.

A VM's availability policy sets its host-maintenance behaviour (MIGRATE to live-migrate, or TERMINATE) and whether Compute Engine restarts it automatically after it is stopped by maintenance or a failure. VMs with attached GPUs cannot live-migrate.

Two facts combine. First, GPU VMs cannot live-migrate, so the maintenance policy must be TERMINATE. Second, only automatic restart brings the VM back without a person, and the checkpoint-on-boot design then resumes the job. TERMINATE without restart is the near-twin that leaves the VM stopped, and Spot adds interruptions instead of avoiding them.

1. Note the GPU: live migration is not supported, so MIGRATE is out.
2. Set the maintenance policy to TERMINATE.
3. Keep automatic restart enabled so Compute Engine restarts the VM after maintenance.
4. Rely on the boot-time checkpoint resume for the job itself.

Exam tip: GPU VMs cannot live-migrate: use TERMINATE with automatic restart, and checkpoint the workload.

Manual node pool scaling in GKE is done with gcloud container clusters resize, which changes the node count of a named pool through the GKE control plane.

gcloud container clusters resize CLUSTER --node-pool=batch-pool --num-nodes=8 tells GKE to bring that pool to 8 nodes straight away. kubectl cannot scale nodes, resizing the underlying managed instance group bypasses GKE's ownership of it, and autoscaling only reacts to Pending Pods, so it would not pre-provision capacity. In a regional or multi-zonal cluster, --num-nodes is per zone, which is why the stem specifies a zonal cluster.

1. Run gcloud container clusters resize CLUSTER_NAME --node-pool=batch-pool --num-nodes=8 --zone=ZONE.
2. Watch the new nodes register with kubectl get nodes until 8 batch-pool nodes are Ready.
3. After quarter-end, resize back to 3 (or enable autoscaling) to stop paying for idle nodes.

Exam tip: Scale a node pool manually with gcloud container clusters resize --node-pool --num-nodes, never by resizing its managed instance group; in regional clusters the count is per zone.

GKE's cluster autoscaler works per node pool: it adds nodes when Pods cannot be scheduled and removes nodes whose Pods fit elsewhere, within configured bounds.

Node pool autoscaling reacts to exactly the signals described: Pending Pods trigger scale-up during the day and idle nodes are consolidated away at night. HPA and VPA act on Pods, not nodes, and a scheduled resize is a guess rather than demand-driven scaling.

1. Enable it: gcloud container node-pools update POOL --cluster=CLUSTER --enable-autoscaling --min-nodes=2 --max-nodes=10 --zone=ZONE.
2. Make sure workloads declare resource requests, because the autoscaler simulates scheduling from requests.
3. Watch scale events and kubectl get nodes over a daily cycle.

Exam tip: Pending Pods plus idle off-peak nodes call for node pool autoscaling; HPA and VPA only change Pods.

StatefulSets run workloads where identity matters: each replica gets a sticky ordinal name, its own PersistentVolumeClaim from volumeClaimTemplates, a DNS record through a headless Service, and ordered creation.

The three requirements map to three StatefulSet pieces: volumeClaimTemplates create one claim per member that follows it across rescheduling; the headless Service (clusterIP: None) publishes db-0.db, db-1.db and so on; and the default OrderedReady policy starts each Pod after the previous one is Ready. The near-twin StatefulSet with one shared claim and a ClusterIP Service gets the names but not per-member storage or per-Pod DNS. Deployments treat replicas as interchangeable and have no volumeClaimTemplates field.

1. Map each requirement: own volume, stable DNS name, ordered start.
2. Own volume per replica means volumeClaimTemplates, which only StatefulSets have.
3. Stable per-Pod DNS means a headless Service named in the StatefulSet's serviceName.
4. Apply and watch db-0 become Ready before db-1 starts with kubectl get pods -w.

Exam tip: Own volume + stable name + ordered start = StatefulSet with volumeClaimTemplates and a headless Service.

The HorizontalPodAutoscaler scales a workload's replica count to hold a metric, most often CPU utilisation as a percentage of Pod requests, near a target.

An HPA with a 60% CPU target adds replicas as lunchtime load pushes utilisation up and removes them overnight, within minReplicas and maxReplicas. VPA right-sizes requests instead of adding Pods, node autoscaling only reacts to Pending Pods, and a PodDisruptionBudget governs evictions.

1. Check the containers declare CPU requests; HPA percentages are computed against them.
2. Create it: kubectl autoscale deployment api --cpu-percent=60 --min=2 --max=12.
3. Watch kubectl get hpa under load to confirm scale-out and scale-in.

Exam tip: Replica count that follows load = HPA, and its CPU percentage is measured against Pod requests.

The VerticalPodAutoscaler recommends per-container requests from observed usage. Its updateMode decides what it does with them: Off only recommends, Initial applies them when Pods are created, Auto (or Recreate) evicts Pods to apply them.

Two constraints decide this. No evictions rules out Auto. Requests changing only through reviewed manifests rules out Initial, the tempting choice: it does not evict, but its admission webhook overwrites the manifest's requests whenever a Pod is created, so production would run unreviewed values. Off mode gives the same recommendations (kubectl describe vpa) with no mutation at all, and the pipeline applies them.

1. List what each mode does: Off recommends, Initial mutates at creation, Auto evicts and mutates.
2. Apply the no-eviction rule: Auto is out.
3. Apply the reviewed-manifest rule: Initial changes requests outside the pipeline, so it is out.
4. Use Off, read the targets with kubectl describe vpa, and ship them through CI/CD.

Exam tip: VPA Off = recommendations only; Initial still changes Pods (at creation) and Auto evicts.

In GKE Autopilot, Google provisions and manages nodes, and general-purpose Pods are billed for their CPU, memory and ephemeral-storage requests. Autopilot applies defaults when requests are missing and adjusts values outside its allowed ranges.

The service is paying for 2 vCPU and 8 GiB per container while using a fraction of it, and in Autopilot the request is what you pay for. Lowering requests toward observed use (with headroom) is the cost lever. Node pools and node autoscaling are Standard-mode controls that Autopilot does not expose. Lowering limits while keeping requests is the tempting near-twin, but billing follows requests, and Kubernetes rejects a limit set below its request.

1. Recall the Autopilot cost model: you pay for Pod requests, not nodes.
2. Compare requests to observed usage from Cloud Monitoring or VPA recommendations.
3. Set new requests with headroom and redeploy; check the admitted Pod spec for any Autopilot adjustment.

Exam tip: In Autopilot, Pod requests are the bill: right-size the requests, not the limits, because there are no nodes to resize.

Every Cloud Run deployment creates an immutable revision, and the service's traffic settings decide each revision's share. --no-traffic separates deploying a revision from releasing it.

Deploying with --no-traffic --tag=qa stands up version 2 at a tag URL such as https://qa---api-HASH-REGION.a.run.app while the current revision keeps 100% of production traffic. After QA, gcloud run services update-traffic api --to-latest (or a percentage split) releases it. The tempting near-twin uses --tag alone: the tag URL appears, but the deploy still shifts all traffic because the service follows the latest revision. A separate service works but forfeits revision traffic control.

1. Deploy: gcloud run deploy api --image=IMAGE --no-traffic --tag=qa.
2. QA tests the qa--- tag URL.
3. Release: gcloud run services update-traffic api --to-latest, or --to-revisions for a gradual split.
4. Roll back by sending traffic to the previous revision.

Exam tip: A tag only adds a URL; --no-traffic is what keeps a new Cloud Run revision at 0%.

Google recommends granting roles to Google groups that represent job functions rather than to individual users.

When the same access goes to a changing set of people, the group is the stable principal. Binding roles to the group means membership changes happen in Google Groups or Cloud Identity, not in IAM. Per-user bindings and a per-user custom role both keep individuals in the policy. The domain principal avoids churn but grants access to the whole company.

1. Notice the same roles for many people and frequent membership changes.
2. Choose a principal that stays constant: a Google group.
3. Reject options that bind individuals or widen access to the whole domain.

Exam tip: Same access for a changing team: grant to a group, manage people through membership.

allUsers and allAuthenticatedUsers are special principals. allUsers is anyone; allAuthenticatedUsers is any authenticated Google identity, not just your organization.

The name suggests 'our logged-in users', but allAuthenticatedUsers covers every Google account and service account, including personal Gmail accounts. That makes it public in practice. To limit access to company staff, grant the role to the company's domain: principal or, better, a group. The allUsers twin differs only in also allowing unauthenticated callers.

1. Read the principal literally: all authenticated Google identities.
2. Recall that this is not scoped to a domain or project.
3. Distinguish it from allUsers, which includes unauthenticated callers.
4. Use domain: or group: to limit access to staff.

Exam tip: allAuthenticatedUsers is anyone with a Google account: treat it as public.

IAM has dedicated roles for administering and reviewing access; choosing between them is a least-privilege decision.

The auditor's job is to read who has access to what across the organization. Security Reviewer is built for that: it lists resources and reads their allow policies, and it cannot change them. Granting it on the organization covers every descendant through inheritance. Security Admin adds write access, basic Viewer reads application data across services, and Organization Role Viewer reads role definitions rather than policies.

1. Identify the job: read policies and security settings everywhere, change nothing.
2. Pick the role made for read-only access review: Security Reviewer.
3. Grant it at the organization so inheritance covers everything.
4. Reject roles that can write, that read data, or that cover only role definitions.

Exam tip: Read-only access review across an org: roles/iam.securityReviewer on the organization.

Administering who has access is separate from using services. Project IAM Admin is the narrow role for managing a project's allow policy.

Three options would let the teammate change access on billing-api, so least privilege and scope decide. Project IAM Admin holds the project getIamPolicy and setIamPolicy permissions and nothing else significant. Security Admin works too but can set IAM policies on any resource, which is broader. Folder IAM Admin on the parent changes the folder's policy, which reaches every project in the folder. Role Administrator manages role definitions, not who holds them.

1. Identify the action: change the project's allow policy.
2. List the roles that can do it: projectIamAdmin, securityAdmin, folderIamAdmin on the parent.
3. Apply scope: only billing-api, so not the folder.
4. Apply least privilege: projectIamAdmin over securityAdmin.

Exam tip: To let someone manage a project's access only, grant roles/resourcemanager.projectIamAdmin on that project.

Predefined roles are maintained by Google; custom roles are maintained by you.

A custom role is a static list. Copying a predefined role takes a snapshot of its permissions at that moment, and IAM never links the two afterwards. When Google adds permissions for new features, the predefined role gets them and the custom role does not. Support levels and launch stages are real custom-role properties, which is why they make tempting distractors, but neither explains a snapshot falling behind.

1. Compare the two roles: the predefined one works, the custom one does not.
2. Recall who maintains each: Google versus you.
3. Conclude the custom role lacks the new permissions until you add them.

Exam tip: Copied custom roles go stale: you must add new permissions yourself.