Free GCP-ACE practice questions

A team wants the lowest ongoing operational overhead for a stateless HTTP API and is willing to give up control over the host operating system. Which characteristic correctly distinguishes Cloud Run from Compute Engine for this workload?

• ACloud Run runs containers on a fully managed platform where Google patches and maintains the underlying infrastructure, whereas Compute Engine gives you a VM whose guest OS you must patch and maintain yourself.check_circle Correct
• BCloud Run requires you to size and patch worker VMs in the same way Compute Engine does, but bills you per request instead of per second of VM uptime.
• CCompute Engine automatically builds and deploys your container image from source, so it carries less deployment overhead than Cloud Run for a stateless API.
• DBoth services abstract the guest operating system equally, so the only real difference for this API is the region where each one can be deployed.

Why A is correct: Cloud Run is a managed serverless container platform, so Google operates the hosts and the candidate manages only the container image and its configuration, while Compute Engine hands you a VM you must patch.

Why B is wrong: This is tempting because both can run the same code, but it is wrong: fully managed Cloud Run exposes no worker VMs for you to size or patch, so the operational overhead claim is false.

Why C is wrong: This inverts the products: Compute Engine gives raw VMs and does no source-to-container build, whereas Cloud Run is the service designed to deploy container images or source directly.

Why D is wrong: This is wrong on substance because Compute Engine does not abstract the guest OS at all; you own patching on the VM, and region availability is not the distinguishing factor here.

An architect needs a compute service that scales the running instance count to zero when there is no traffic, so that an idle service incurs no per-instance compute charges. Which service supports scaling to zero as a native default behaviour?

• AA Compute Engine managed instance group, because its autoscaler removes every VM whenever no requests are arriving at the workload.
• BCloud Run, because a fully managed service can scale its container instances down to zero when idle and scale back up on the next request.check_circle Correct
• CA Standard tier Google Kubernetes Engine node pool, because the cluster autoscaler always deletes the last node once the Deployment reports no active connections.
• DCompute Engine with Spot VMs, because Spot pricing pauses billing on each VM during periods when the instance receives no inbound traffic.

Why A is wrong: This is tempting because managed instance groups do autoscale, but their autoscaler honours a minimum instance count and is not designed to hold at zero for request-driven idling, so idle VMs keep billing.

Why B is correct: Cloud Run's request-driven autoscaling drops to zero instances when no traffic arrives and starts a new instance on the next request, so an idle service accrues no per-instance compute charge.

Why C is wrong: GKE Standard keeps at least the nodes needed for system workloads and a running control plane, and connection counts do not drive node deletion, so it does not idle at zero the way the stem requires.

Why D is wrong: Spot VMs only change the price of a running VM and can be preempted, but they still bill while running and are not paused by an absence of traffic, so this misstates how Spot works.

A platform team values workload portability and wants to run the same containerised application unchanged across other Kubernetes environments later, while accepting more operational responsibility than a serverless option. Which service best matches that priority?

• ACloud Run functions, because event-driven functions are the most portable unit and move between any Kubernetes distribution without change.
• BCompute Engine, because a single VM image is the standard portable artefact that runs identically on every Kubernetes cluster you later adopt.
• CGoogle Kubernetes Engine, because it runs standard Kubernetes so the same manifests and container images can be redeployed to other conformant Kubernetes clusters.check_circle Correct
• DCloud Run in fully managed mode, because its service YAML is identical to a Kubernetes Deployment and therefore runs on any cluster with no edits.

Why A is wrong: This is tempting because functions feel lightweight, but Cloud Run functions target a managed serverless runtime rather than portable Kubernetes objects, so they do not deliver cluster portability.

Why B is wrong: A VM image is not a Kubernetes artefact and does not run on a cluster as a workload, so Compute Engine does not provide the Kubernetes portability the team is asking for.

Why C is correct: GKE runs upstream-conformant Kubernetes, so Deployments, Services and images defined for it can be applied to other conformant clusters, giving the portability the team wants at the cost of managing more of the platform.

Why D is wrong: Fully managed Cloud Run uses the Knative Serving API rather than a Kubernetes Deployment, and it is not a general cluster you can move arbitrary Kubernetes workloads onto, so the equivalence claimed here is false.

A GKE Standard cluster runs some workloads that need GPU machine types and others that need only general-purpose CPUs. Which statement correctly describes what a node pool provides in this cluster?

• AA node pool is a single Compute Engine VM whose machine type every workload in the cluster must share, so mixed hardware needs are met by resizing that one VM.
• BA node pool is the Kubernetes object that stores application state, so placing GPU workloads in it guarantees their data survives when a node is restarted or replaced.
• CA node pool is a namespace-scoped policy that reserves CPU and memory for Pods, with no relationship to the machine type of the underlying nodes.
• DA node pool is a group of nodes within the cluster that share one configuration, so you can create one pool with GPU machine types and another with general-purpose machine types.check_circle Correct

Why A is wrong: This is tempting because a node is backed by a VM, but a node pool is a set of nodes rather than one VM, and a cluster can hold several pools, so mixed hardware is served by separate pools.

Why B is wrong: This confuses a node pool with persistent storage; a node pool defines node configuration and does not itself hold application state, which is provided by persistent volumes instead.

Why C is wrong: Resource reservation for Pods is done with requests and limits or quotas, whereas a node pool is a cluster-level grouping of nodes tied directly to their machine type.

Why D is correct: A node pool groups nodes of identical configuration, and a cluster can contain multiple pools, so a GPU pool and a general-purpose pool coexist and the scheduler places each workload on suitable nodes.

Several Pods in a GKE Standard cluster stay in the Pending state because no existing node has enough free CPU to schedule them. Which mechanism is responsible for adding capacity, and on what basis does it act?

• AThe cluster autoscaler, because it adds nodes to a node pool when Pods cannot be scheduled for want of resources, and later removes nodes that stay underutilised.check_circle Correct
• BThe Horizontal Pod Autoscaler, because it watches aggregate node CPU and provisions extra nodes into the pool once utilisation crosses its configured target.
• CThe Vertical Pod Autoscaler, because it recreates the Pending Pods with smaller resource requests until they fit onto the nodes that already exist.
• DThe kube-scheduler, because when it finds no fit it directly requests a new Compute Engine VM and binds the Pending Pods to it as soon as the VM registers.

Why A is correct: The cluster autoscaler resizes node pools based on scheduling pressure, adding nodes when Pods are unschedulable due to insufficient resources and removing nodes that remain underutilised.

Why B is wrong: This is tempting because the HPA reacts to CPU, but it scales Pod replica counts, not nodes, so it cannot resolve Pending Pods caused by a shortage of node capacity.

Why C is wrong: The VPA does adjust resource requests, but it is meant to right-size Pods rather than force-fit them, and it does not add the node capacity the Pending Pods actually need.

Why D is wrong: The scheduler only assigns Pods to nodes that already exist and reports failures when none fit; it does not create VMs, which is the cluster autoscaler's job.

A Deployment serves a web API whose traffic rises and falls through the day, and the team wants more identical replicas during peaks and fewer during quiet periods. Which autoscaler matches this goal, and what does it change?

• AThe Vertical Pod Autoscaler, because it adds and removes Pod replicas according to the memory requests that have been recorded for the workload over time.
• BThe Horizontal Pod Autoscaler, because it changes the number of Pod replicas in the Deployment in response to observed metrics such as average CPU utilisation.check_circle Correct
• CThe cluster autoscaler, because it edits the replicas field of the Deployment directly whenever the CPU on the underlying nodes crosses a set threshold.
• DThe Vertical Pod Autoscaler, because it raises the CPU and memory requests of each running Pod so that a single replica alone can absorb the daily peak.

Why A is wrong: This is tempting because the VPA also reacts to usage, but it does not change replica count; it adjusts the CPU and memory requests of Pods instead.

Why B is correct: The HPA adjusts the replica count of a workload up or down to track a target metric, which is exactly the behaviour of adding replicas at peak and removing them when traffic falls.

Why C is wrong: The cluster autoscaler resizes node pools rather than editing a Deployment, so it never sets the replica count and does not perform the scaling the team wants.

Why D is wrong: This correctly describes VPA behaviour but not the requirement; the team asked for more identical replicas, which is horizontal scaling, not larger single Pods.

A boolean organization policy constraint is enforced on a folder. A team then creates a new project inside that folder, and no policy is set directly on the project. How does the constraint apply to the new project?

• AThe constraint is inherited from the folder and enforced on the new project, because a project evaluates an effective policy built from every ancestor above it.check_circle Correct
• BThe constraint does not reach the project, because organization policies attach to the organization node and folders but stop above the project level.
• CThe constraint applies only after an administrator re-applies it on the project, since existing policies do not propagate to resources created after the policy is set.
• DThe constraint is inherited but downgraded to advisory, so violations on the project are recorded in Cloud Logging instead of being blocked.

Why A is correct: Correct: the effective policy for any node is the result of evaluating its own policy against those inherited from the folders and organization above it, so a folder constraint applies to child projects.

Why B is wrong: It sounds plausible if you assume policies protect only higher tiers, but organization policies attach to and are enforced at organization, folder, and project nodes alike.

Why C is wrong: The timing detail is tempting, but inheritance is evaluated dynamically at each request, so a project created later still inherits the folder policy without any manual re-application.

Why D is wrong: It borrows the idea of a dry-run mode, but an enforced organization policy actively blocks non-compliant actions rather than merely logging them as advisory events.

Which statement correctly describes how nodes relate to one another in the Google Cloud resource hierarchy?

• AProjects attach directly under the organization node, and folders exist to group billing accounts rather than to group projects.
• BFolders can contain other folders and projects, whereas a project holds resources but cannot contain another project or a folder.check_circle Correct
• CThe organization node is optional, and a folder can act as the top-level root of the hierarchy when no organization has been created.
• DA folder can be attached to more than one parent at a time, letting the same folder appear under two organizations for shared administration.

Why A is wrong: Projects can attach directly under the organization, but folders are grouping nodes for folders and projects, not for billing accounts, which sit outside the resource hierarchy.

Why B is correct: Correct: folders may nest folders and projects to model an organization's structure, while a project is a leaf container for resources and cannot itself contain folders or projects.

Why C is wrong: This confuses the two node types: folders require an organization as an ancestor and cannot exist as a root, so the organization node is the only possible top of the hierarchy.

Why D is wrong: Shared administration is a real need, but every folder and project has exactly one parent, so a folder cannot appear under two organizations simultaneously.

An administrator grants a viewer IAM role on a folder and separately enforces an organization policy on the same folder. How do these two mechanisms propagate to projects within that folder?

• ABoth propagate, but the inherited IAM grant can be cancelled by adding a matching allow binding on a child project to remove that access.
• BNeither propagates automatically, so both the IAM role binding and the organization policy have to be recreated individually on each project.
• CBoth propagate downward: the IAM role is inherited additively by the projects, and the organization policy is inherited as part of each project's effective policy.check_circle Correct
• DThe organization policy propagates, but the IAM role binding stays on the folder resource itself and does not extend to the projects beneath it.

Why A is wrong: IAM allow policies are additive, so an extra binding on a child cannot subtract an inherited grant; removing access would require IAM conditions or a deny policy, not another allow.

Why B is wrong: This misses the shared inheritance model: both IAM bindings and organization policies flow down the hierarchy, so recreating them on every project is unnecessary.

Why C is correct: Correct: IAM allow bindings on a folder are inherited by descendant projects as additive permissions, and organization policies on the folder form part of each descendant project's effective policy.

Why D is wrong: It correctly identifies organization policy inheritance yet wrongly stops IAM there; a role granted on a folder is inherited by the projects and resources within that folder.

A colleague new to Google Cloud asks how the three IAM role types differ. Which statement correctly characterises basic, predefined, and custom roles?

• ABasic roles are granular roles maintained by Google for a single service, predefined roles are the legacy Owner, Editor, and Viewer, and custom roles are copies of basic roles scoped to one project.
• BBasic roles are the broad legacy Owner, Editor, and Viewer roles, predefined roles are granular Google-maintained roles for specific services, and custom roles let you assemble a chosen set of permissions.check_circle Correct
• CBasic roles apply only to Cloud Storage buckets, predefined roles apply only to Compute Engine, and custom roles are the sole way to grant access to any other Google Cloud service.
• DBasic roles and predefined roles are both authored by the customer, whereas custom roles are supplied and updated automatically by Google as services change.

Why A is wrong: This swaps the definitions of basic and predefined roles; Owner, Editor, and Viewer are the basic roles, while the granular per-service roles maintained by Google are the predefined ones.

Why B is correct: This matches the model exactly: basic roles are broad and legacy, predefined roles are fine-grained and maintained by Google, and custom roles are built by selecting the specific permissions you want.

Why C is wrong: This invents per-service limits that do not exist; basic and predefined roles both span many services, and custom roles are an option for tailoring permissions rather than the only route to most services.

Why D is wrong: This reverses authorship; basic and predefined roles are provided and maintained by Google, while custom roles are the ones the customer authors and must maintain themselves.

A team wants to grant an application the permissions to publish and consume Pub/Sub messages without giving any broader access. What is the main advantage of choosing a predefined role over a basic role here?

• AA predefined role can be edited by the team to add or remove individual permissions, whereas a basic role has a fixed permission set that cannot be changed.
• BA predefined role automatically applies across the whole organisation hierarchy, so it needs to be granted only once, unlike a basic role that must be granted per resource.
• CA predefined role bundles a curated set of permissions for a specific service, granting just the Pub/Sub access the application needs rather than broad access to unrelated services.check_circle Correct
• DA predefined role grants temporary permissions that expire after the application finishes, while a basic role grants permanent access that must be revoked manually.

Why A is wrong: This confuses predefined with custom roles; predefined roles are maintained by Google and are not customer-editable, so editability is not the advantage they offer.

Why B is wrong: This misstates inheritance; both role types follow the same policy-inheritance rules based on where they are granted, so this is not a distinguishing benefit of predefined roles.

Why C is correct: Predefined roles are granular and service-focused, so a Pub/Sub publisher or subscriber role grants only the relevant permissions, aligning with least privilege far better than a broad basic role.

Why D is wrong: This invents an expiry behaviour; predefined roles do not self-expire, and time-bound access is handled separately, so the genuine advantage is their granular service scope.

An administrator plans to create a custom IAM role so it can be reused across several projects under one folder. At which levels of the resource hierarchy can a custom role be created?

• AAt the folder level only, so that every project beneath the folder inherits the same custom role definition automatically.
• BAt the billing account level, because custom roles are scoped to the account that pays for the resources they govern.
• CAt the project level only, because a custom role defined anywhere else would conflict with the predefined roles Google maintains organisation-wide.
• DAt either the organisation level or the project level, depending on how widely the administrator wants the role to be available.check_circle Correct

Why A is wrong: Custom roles cannot be created at the folder level at all, so a folder-only answer is incorrect even though folders do play a role in policy inheritance.

Why B is wrong: Billing accounts are not a location for defining custom roles; role creation is tied to the organisation and project scopes, not to who pays for usage.

Why C is wrong: This wrongly rules out organisation-level custom roles, which are supported; there is no conflict with predefined roles, so restricting creation to projects is inaccurate.

Why D is correct: Custom roles can be defined at the organisation level, making them available to all projects in the organisation, or at the project level for use within that single project.