Google Associate Cloud Engineer ACE Questions 301–375 | Page 5/11

301

MCQeasy

A developer wants to deploy a containerized web application that receives HTTP requests and can scale to zero when not in use. The application is stateless and has a startup time of less than 2 seconds. Which Google Cloud compute option is the most cost-effective?

A.Compute Engine with managed instance group and autoscaling

B.Google Kubernetes Engine (GKE) Standard

C.App Engine Standard with manual scaling

D.Cloud Run

AnswerD

Cloud Run executes stateless containers on a fully managed platform, where each instance only receives compute billing while actually processing a request and the service can scale down to zero when no traffic arrives. It automatically provisions instances based on concurrency and can start many instances to handle bursts, with optional min instances for latency-sensitive workloads. A containerized web application is an ideal fit because Cloud Run accepts any container image that listens on a port, and integrates directly with Cloud Build and Artifact Registry.

Why this answer

Cloud Run is a fully managed serverless platform that runs stateless containers and automatically scales to zero when there is no traffic, meaning you pay nothing when idle. It natively handles HTTP requests and supports rapid scaling based on incoming requests, making it ideal for a stateless web app with sub-2-second startup. The other options either do not scale to zero or require manual scaling configuration, leading to higher costs for sporadic workloads.

Exam trap

ACE often tests the misconception that any autoscaling solution can scale to zero, but only serverless platforms like Cloud Run and App Engine Standard (with automatic scaling) truly scale to zero; managed instance groups and GKE Standard always maintain a minimum capacity.

How to eliminate wrong answers

Option A is wrong because Compute Engine with a managed instance group and autoscaling does not scale to zero; at least one VM instance must always be running, incurring continuous costs even when idle. Option B is wrong because GKE Standard charges for the control plane (unless on Autopilot, but even then nodes may persist) and typically does not scale to zero by default; it requires managing node pools and cluster infrastructure, adding cost and complexity. Option C is wrong because App Engine Standard with manual scaling requires you to specify the number of instances, which means you cannot scale to zero automatically and will pay for idle instances.

Full explanation →

302

MCQmedium

A team needs to build a CI/CD pipeline that automatically tests and deploys to GKE when code is pushed to the main branch. Which GCP-native service builds and deploys the code automatically based on source code repository events?

A.Cloud Composer with a Git polling DAG

B.Cloud Build with a trigger configured on the repository's main branch

C.Cloud Run jobs triggered by a Pub/Sub subscription on the repository

D.Cloud Functions triggered by Cloud Source Repositories push events

AnswerB

Cloud Build Triggers are the native, fully managed CI/CD solution on Google Cloud. Configuring a trigger on the main branch means every push automatically executes a pipeline defined in cloudbuild.yaml, which can include steps for unit tests, container image building with Kaniko or Buildpacks, pushing to Artifact Registry, and deploying to a GKE cluster using the kubectl or gke-deploy builder. This is exactly the intended use case, with built-in integration, logging, and minimal operational overhead.

Why this answer

Cloud Build is the correct GCP-native service for building and deploying code automatically based on source code repository events. By configuring a Cloud Build trigger on the main branch, any push to that branch automatically initiates a build and deployment to GKE, fulfilling the CI/CD pipeline requirement without additional orchestration.

Exam trap

Google Cloud often tests the distinction between event-driven compute services (Cloud Functions, Cloud Run) and purpose-built CI/CD services (Cloud Build), leading candidates to mistakenly choose Cloud Functions or Cloud Run because they can be triggered by repository events, even though they lack the integrated build-and-deploy pipeline required for GKE deployments.

How to eliminate wrong answers

Option A is wrong because Cloud Composer is a workflow orchestration service for Apache Airflow, not a CI/CD build-and-deploy service; using a Git polling DAG would be an inefficient, non-native workaround that does not provide event-driven, automated builds. Option C is wrong because Cloud Run jobs are designed for batch or scheduled compute tasks, not for building container images or deploying to GKE; they lack native source-code event triggers and CI/CD capabilities. Option D is wrong because Cloud Functions triggered by Cloud Source Repositories push events can run custom code on a push, but they are not designed to build container images or orchestrate deployments to GKE; they lack the integrated build, test, and deploy pipeline that Cloud Build provides.

Full explanation →

303

MCQmedium

You need to delete a GCP project, but the deletion fails with an error. What is the most likely cause?

A.The project has IAM policies attached

B.The project still has active resources such as Compute Engine instances

C.The project is in a folder

D.The project's billing account is still linked

AnswerD

The correct answer is that a linked billing account prevents project deletion. Google Cloud requires you to disable billing for a project before it can be deleted, because deletion finalizes cost responsibility and prevents accidental ongoing charges. The console will display an error such as 'Billing must be disabled' if the project is still linked to a billing account. You must detach the billing account or disable the project's billing, then initiate the deletion process.

Why this answer

GCP requires that billing be disabled before a project can be deleted. If billing is still active, deletion will fail.

Full explanation →

304

Multi-Selectmedium

Which TWO statements are correct about deploying an application with an HTTP(S) load balancer on Compute Engine?

Select 2 answers

A.A network load balancer can be used for UDP traffic.

B.A TCP proxy load balancer can only be used for non-HTTP traffic.

C.SSL proxy load balancers cannot terminate HTTPS traffic.

D.Internal load balancers require a proxy instance.

E.An HTTP(S) load balancer requires a backend service with a health check.

AnswersA, E

A network load balancer is a pass-through, Layer 4 load balancer that forwards packets directly to backend instances without modifying or inspecting payload contents. Because it operates at the packet level, it can handle both TCP and UDP traffic, including protocols like DNS, NTP, or real-time UDP streams, making the statement correct.

Why this answer

Option A is correct because a network load balancer (TCP/UDP load balancing) operates at Layer 4 and supports UDP traffic, which is essential for non-TCP protocols. Option E is correct because an HTTP(S) load balancer requires a backend service that references instance groups or NEGs, and that backend service must have a health check to determine which backends are healthy and eligible to receive traffic. Option B is incorrect because a TCP proxy load balancer handles TCP traffic, including HTTP/HTTPS, not only non-HTTP traffic.

Option C is incorrect because SSL proxy load balancers are specifically designed to terminate SSL/TLS (HTTPS) traffic. Option D is incorrect because internal load balancers do not require a proxy instance; they use backend services and health checks like external load balancers.

Exam trap

The trap here is that candidates confuse the TCP proxy load balancer's ability to handle HTTP traffic with the HTTP(S) load balancer's Layer 7 capabilities, leading them to incorrectly think TCP proxy is restricted to non-HTTP traffic.

Full explanation →

305

MCQmedium

Your application runs on GKE and needs to call the Cloud Translation API. You want to follow Google's recommended security practice for service-to-cloud-API authentication within GKE. Which approach should you use?

A.Download a service account key JSON and mount it as a Kubernetes Secret in the pod.

B.Configure Workload Identity to bind the pod's Kubernetes Service Account to a Google Service Account with Translation API access.

C.Grant the GKE node pool's service account `roles/cloudtranslate.user`.

D.Use the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to a mounted key file.

AnswerB

Workload Identity is the recommended GKE authentication mechanism because it binds a Kubernetes Service Account to a Google Service Account via the `iam.gke.io/gcp-service-account` annotation. Pods automatically receive short-lived OAuth 2.0 access tokens from the GKE metadata server, eliminating the need to create, store, or rotate any service account key files. Since the mapped Google Service Account holds only `roles/cloudtranslate.user`, access is strictly scoped to the Translation API for that workload, satisfying least privilege. The node pool's service account only needs `roles/iam.workloadIdentityUser` to enable impersonation, so node-level permissions stay minimal.

Why this answer

Workload Identity is Google's recommended approach for authenticating workloads in GKE to Google Cloud APIs. It allows you to bind a Kubernetes Service Account (KSA) to a Google Service Account (GSA), so pods can impersonate the GSA without managing or storing long-lived service account keys. This eliminates the security risk of key exposure and follows the principle of least privilege.

Exam trap

Google Cloud often tests the misconception that mounting a service account key as a Kubernetes Secret is acceptable for production, but the correct answer emphasizes using Workload Identity to avoid managing static keys.

How to eliminate wrong answers

Option A is wrong because downloading a service account key JSON and mounting it as a Kubernetes Secret introduces a long-lived credential that can be leaked or misused, violating Google's recommendation to avoid static keys. Option C is wrong because granting the GKE node pool's service account `roles/cloudtranslate.user` gives all pods on that node pool access to the Translation API, breaking the principle of least privilege and not isolating permissions per workload. Option D is wrong because using the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to a mounted key file still relies on a static service account key, which is less secure than Workload Identity's token exchange mechanism.

Full explanation →

306

Multi-Selectmedium

A company uses preemptible VMs for batch processing. Which TWO best practices should be implemented to improve resilience and manageability? (Choose 2)

Select 2 answers

A.Use persistent disks to store application state.

B.Use instance metadata to pass configuration parameters.

C.Use Cloud Functions to monitor instance termination.

D.Use startup scripts to prepare the instance environment.

E.Use persistent disk snapshots for backup.

AnswersB, D

Instance metadata is a key-value store exposed by the metadata server to every VM, and it is the recommended way to pass configuration parameters to preemptible VMs without baking them into the image. Because preemptible VMs can be recreated at any time, metadata lets the same image serve many different configurations; startup scripts or agents can read those values at boot to adapt the workload. This keeps the image generic and enables dynamic, per-instance configuration even when thousands of ephemeral VMs are launched from one template.

Why this answer

Instance metadata is a key-value store that can be used to pass configuration parameters to preemptible VMs at boot time. Since preemptible VMs can be terminated at any time, using metadata ensures that new instances can be recreated with the same configuration without manual intervention. This improves manageability by centralizing configuration and resilience by enabling automated re-provisioning.

Exam trap

Google Cloud often tests the misconception that persistent disks or snapshots are needed for resilience with preemptible VMs, but the correct approach is to treat them as stateless and use external storage for state, with metadata and startup scripts for configuration and initialization.

Full explanation →

307

MCQeasy

A developer needs to SSH into a Compute Engine instance that has OS Login enabled. The developer's Google account is already granted the roles/compute.osLogin role. Which command should the developer use to connect?

A.ssh -i ~/.ssh/google_key user@instance-ip

B.gcloud compute ssh instance-name --zone=us-central1-a

C.gcloud compute instances get-serial-port-output instance-name --zone=us-central1-a

D.gcloud compute connect-to-serial-port instance-name --zone=us-central1-a

AnswerB

With OS Login enabled and roles/compute.osLogin granted, gcloud compute ssh authenticates using the Google account and manages SSH keys through OS Login, so no manual key setup is needed. This satisfies the scenario by connecting the developer to the instance in the specified zone.

Why this answer

With OS Login enabled and the roles/compute.osLogin role granted, the developer should connect using gcloud compute ssh, which automatically handles OS Login authentication and key management. The gcloud compute ssh command integrates with OS Login to generate short-lived SSH certificates and manage the developer's Google identity, so no manual key file is needed. Specifying the zone ensures the command targets the correct instance.

Exam trap

ACE often tests the misconception that OS Login still requires a manual SSH key file — candidates pick the ssh -i option because it looks like the 'standard' SSH command, but OS Login specifically replaces that workflow with identity-based gcloud authentication.

How to eliminate wrong answers

Option A is wrong because manually specifying a private key file bypasses OS Login's identity-based authentication and is not how OS Login connections are made. Option C is wrong because get-serial-port-output retrieves console output for troubleshooting, not an interactive SSH session. Option D is wrong because connect-to-serial-port provides serial console access for recovery, not a standard SSH login, and it does not use OS Login.

Full explanation →

308

MCQmedium

A company has a VPC with custom mode and needs to connect to an on-premises network via HA VPN. They have two on-premises VPN devices, each with a static public IP address. What is the correct way to configure the HA VPN gateway on Google Cloud?

A.Create one classic VPN gateway with two tunnels to the two on-premises devices

B.Create one HA VPN gateway with two interfaces in the same region, and create two tunnels, each connecting one cloud interface to one on-premises device

C.Create two separate VPN gateways, each with one interface, and assign each to a different region

D.Create one HA VPN gateway in one region and one classic VPN gateway in another region

AnswerB

This is the exact HA VPN architecture: one regional HA VPN gateway exposes two external IP addresses (called interfaces) in the same region, and each interface forms its own IPsec tunnel to a different on-premises device. The two tunnels run as an active/active or active/standby pair using BGP dynamic routing, so if one on-premises device or tunnel fails, the Cloud Router can withdraw routes and send traffic through the surviving tunnel. This configuration is required to meet the 99.99% availability SLA for Cloud VPN.

Why this answer

For HA VPN with two on-premises devices, you create one HA VPN gateway with two interfaces in the same region, and then create two tunnels, each connecting one cloud interface to one on-premises device. This provides redundancy and meets the HA requirements.

Exam trap

The trap is assuming that HA VPN requires multiple gateways or that interfaces can be in different regions. Candidates often confuse the HA VPN architecture with other VPN types.

How to eliminate wrong answers

Option A is wrong because Classic VPN does not support HA and has only one interface. Option C is wrong because HA VPN gateway interfaces must be in the same region; creating two gateways in different regions is not the standard HA VPN configuration. Option D is wrong because mixing HA VPN and Classic VPN does not provide the required redundancy and is not a supported HA configuration.

Full explanation →

309

Multi-Selectmedium

You need to export all logs from Cloud Logging to a BigQuery dataset for long-term analysis. The export should include logs from all projects in the organization. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Create a log sink with destination type Cloud Storage bucket

B.Create a log sink with destination type BigQuery dataset

C.Create a log-based metric to filter the logs

D.Create the sink at the organization level

E.Create the sink at the project level for each project individually

AnswersB, D

Creating a log sink with a BigQuery dataset destination routes matching log entries into BigQuery tables, satisfying the organisation-wide export requirement. Sink inclusion filters can scope the sink across all projects when created at the organisation level, enabling centralised long-term analysis without per-project configuration.

Why this answer

Option B is correct because a log sink's destination must be set to a BigQuery dataset to route log entries into BigQuery for long-term analysis; the sink uses the BigQuery destination and requires a dataset to exist. Option D is correct because creating the sink at the organization level allows it to aggregate and export logs from all projects in the organization in a single sink, which matches the requirement to include logs from all projects. Option A is incorrect because a Cloud Storage bucket destination exports logs to Cloud Storage, not BigQuery.

Option C is incorrect because log-based metrics create metric data for monitoring/alerting, not raw log export to BigQuery. Option E is incorrect because project-level sinks would need to be created per project and would not provide a single organization-wide export as required.

Exam trap

ACE often tests the difference between organization-level and project-level sinks; candidates may incorrectly choose project-level sinks for organization-wide log export, not realizing that organization-level sinks automatically cover all current and future projects.

Full explanation →

310

MCQmedium

A security audit found that several Cloud Storage buckets in your project have `allAuthenticatedUsers` in their IAM policy with `storage.objectViewer`. What does `allAuthenticatedUsers` grant, and why is it a security risk?

A.It grants access only to users within your Google Workspace domain — a minor risk if your domain is small.

B.It grants read access to any person with a Google account — effectively near-public access since Google accounts are free to create.

C.It grants access only to Google service accounts, which is acceptable since those are controlled.

D.It grants access to authenticated GCP users in your organization's IAM policy — this is normal for shared resources.

AnswerB

In Cloud IAM, allAuthenticatedUsers is a special principal that matches any identity that is authenticated with Google, which includes not only your organization's users but every Gmail account, Workspace account, and even service account in the world. Because anyone can create a Google account for free, this permission is functionally equivalent to public access — a random individual only needs a few seconds to sign up and gain the granted role. For internal or sensitive data, this exposure is unacceptable, so the security risk is severe rather than minor.

Why this answer

`allAuthenticatedUsers` is a special IAM member that includes any person authenticated with a Google account, regardless of whether they belong to your organization or domain. Granting `storage.objectViewer` to this group means anyone with a free Google account (e.g., Gmail) can list and read objects in the bucket, making the data effectively public. This is a significant security risk because it exposes sensitive data to a vast, uncontrolled audience.

Exam trap

Google Cloud often tests the distinction between `allAuthenticatedUsers` and `allUsers`, where candidates mistakenly think `allAuthenticatedUsers` is safe because it requires authentication, but the trap is that any Google account (free or otherwise) qualifies, making it nearly as risky as `allUsers` for sensitive data.

How to eliminate wrong answers

Option A is wrong because `allAuthenticatedUsers` is not restricted to a Google Workspace domain; it includes all Google account holders, not just domain users. Option C is wrong because `allAuthenticatedUsers` includes human users with Google accounts, not just service accounts; service accounts are covered by `allUsers` or specific service account emails. Option D is wrong because `allAuthenticatedUsers` is not limited to users in your organization's IAM policy; it encompasses any authenticated Google identity, including external users.

Full explanation →

311

MCQmedium

A GKE application Pod needs a sidecar container that proxies all outbound network requests through an audit logger before they reach the internet. Both containers share the same network namespace. Which Kubernetes pattern implements this?

A.Run the audit logger as a separate Deployment and route traffic via a Service

B.Add the audit logger as a second container in the same Pod spec (sidecar pattern)

C.Use a DaemonSet for the audit logger on each node to intercept node-level traffic

D.Add an initContainer to start the audit logger before the main application

AnswerB

A sidecar container in the same Pod shares the network namespace with the main application container, meaning both can bind to the same localhost interface and the sidecar can transparently proxy or audit all traffic entering or leaving the Pod. This pattern is ideal for audit logging because it requires no code changes to the application and provides a complete view of the Pod's network activity, including both inbound and outbound connections, at the Pod boundary.

Why this answer

The sidecar pattern allows two containers to share the same network namespace within a single Pod, enabling the audit logger to intercept all outbound traffic from the application container before it reaches the internet. This is achieved by configuring the application container to route its outbound requests through the sidecar (e.g., via a localhost proxy or iptables rules), ensuring all traffic is logged without external network hops.

Exam trap

Google Cloud often tests the distinction between initContainers and sidecars, where candidates mistakenly choose initContainers because they think 'start before the main app' implies ongoing traffic interception, but initContainers exit after completion and cannot proxy runtime traffic.

How to eliminate wrong answers

Option A is wrong because running the audit logger as a separate Deployment and routing traffic via a Service introduces network latency and a separate IP address, breaking the requirement for the sidecar to intercept traffic within the same network namespace; the application would need to be explicitly configured to use the Service, which is not a transparent proxy. Option C is wrong because a DaemonSet runs a pod on each node for node-level traffic interception (e.g., using eBPF or iptables), but it does not share the same network namespace as the application Pod and cannot intercept per-Pod outbound requests without complex network policies. Option D is wrong because an initContainer runs to completion before the main application starts and cannot persist to proxy ongoing outbound traffic; it is used for setup tasks, not for runtime traffic interception.

Full explanation →

312

MCQmedium

A company is using BigQuery for analytics. They notice that queries are slow and expensive. The data is loaded daily into a single table. Which action would most improve performance and reduce cost?

A.Use a flat-rate reservation to improve query concurrency.

B.Denormalize the table to reduce joins.

C.Increase the number of slots available for the project.

D.Partition the table by date and cluster by frequently filtered columns.

AnswerD

Partitioning the table by date allows BigQuery to use partition pruning, so queries with date range filters only read the relevant daily partitions instead of the full table. Clustering on frequently filtered columns further organizes data within each partition, enabling block-level pruning based on the cluster columns' values. Together, these features dramatically reduce the bytes scanned and the underlying I/O, directly improving query speed and reducing cost.

Why this answer

Partitioning the table by date allows BigQuery to prune partitions during query execution, scanning only the relevant daily data instead of the entire table. Clustering on frequently filtered columns further reduces the data scanned by sorting data within partitions. This directly reduces both query cost (pay-per-byte) and latency, addressing the core issue of slow, expensive queries on a large daily-loaded table.

Exam trap

Google Cloud often tests the misconception that increasing compute resources (slots or concurrency) is the primary fix for slow queries, when in reality data pruning via partitioning and clustering is the first and most impactful optimization for cost and performance.

How to eliminate wrong answers

Option A is wrong because a flat-rate reservation improves query concurrency and provides predictable slot capacity, but it does not reduce the amount of data scanned per query; slow and expensive queries due to scanning the entire table would persist. Option B is wrong because denormalization reduces joins but does not address the primary issue of scanning a massive single table; it may even increase storage costs and data scanned if not combined with partitioning/clustering. Option C is wrong because increasing slots (via reservations or flex slots) improves query execution speed by providing more parallel processing, but it does not reduce the bytes billed; queries would still scan the entire table, keeping costs high.

Full explanation →

313

MCQhard

A financial services company is designing its Google Cloud landing zone. Auditors require that all resources be created in approved regions only, that no external IP addresses be assignable to Compute Engine instances, and that any new project automatically inherit these restrictions. The security team wants to enforce this centrally without relying on application teams to configure each project correctly. What should the company implement?

A.Deploy a Cloud Asset Inventory feed and a Cloud Function that deletes any resource created outside approved regions or with an external IP.

B.Use IAM deny policies at the organization node to block the compute.instances.create permission for all principals except the security team.

C.Configure a Shared VPC host project and grant the application teams the Compute Network User role on specific subnets in approved regions.

D.Create an organization policy with constraints for resource locations and VM external IP access, and attach it at the organization node so all projects inherit it.

AnswerD

Organization policies applied at the organization node are inherited by every folder and project, so new projects automatically receive the location and external IP restrictions. This central enforcement does not depend on application teams and satisfies the auditor requirement that all resources comply without per-project configuration.

Why this answer

Organization policies are the centralized preventive control that applies at the organization node and is inherited by all current and future projects. Constraints for resource locations and VM external IP access directly encode the auditors' requirements, so no application team can create a noncompliant resource even if they try.

Exam trap

The trap here is treating IAM deny policies or Shared VPC as equivalent to organization policy constraints, when only organization policies can restrict resource locations and external IP assignment across all projects.

Full explanation →

314

MCQmedium

A team is using Terraform to manage Google Cloud resources. They want to store the Terraform state file in a Cloud Storage bucket with versioning enabled. Which backend configuration should they use?

A.terraform { backend "cloud" { bucket = "my-terraform-state-bucket" prefix = "terraform/state" } }

B.terraform { backend "gcs" { bucket = "my-terraform-state-bucket" prefix = "terraform/state" } }

C.terraform { backend "gcs" { bucket = "gs://my-terraform-state-bucket" prefix = "terraform/state" } }

D.terraform { backend "remote" { hostname = "app.terraform.io" organization = "my-org" workspaces { name = "my-workspace" } } }

AnswerB

The gcs backend block points Terraform at the Cloud Storage bucket holding remote state, and the prefix namespaces the state object within that bucket. Versioning is configured on the bucket itself, so the backend only needs bucket and prefix.

Why this answer

The correct backend block for Google Cloud Storage in Terraform is backend "gcs", and the bucket argument must be the bare bucket name (e.g., "my-terraform-state-bucket") without the gs:// scheme prefix. Terraform's GCS backend automatically uses the Google Cloud Storage API and supports object versioning natively when enabled on the bucket. This configuration stores the state file at gs://my-terraform-state-bucket/terraform/state/default.tfstate.

Exam trap

The trap here is the gs:// prefix — candidates familiar with gsutil commands assume the bucket argument needs the URI scheme, but Terraform's GCS backend requires only the bare bucket name.

How to eliminate wrong answers

Option A is wrong because there is no backend type called "cloud" in Terraform — the valid GCS backend is named "gcs", so this block would fail with an unsupported backend error. Option C is wrong because although it uses the correct "gcs" backend name, the bucket argument includes the gs:// URI scheme; the GCS backend expects only the bucket name, and including the scheme causes a configuration error. Option D is wrong because the "remote" backend configures Terraform Cloud/Enterprise (app.terraform.io) as the state store, not a self-managed GCS bucket, so it does not meet the requirement of storing state in Cloud Storage with versioning.

Full explanation →

315

MCQeasy

You need to install the Google Cloud SDK on a Linux machine. Which command should you use to add the Cloud SDK distribution URI as a package source?

A.curl https://sdk.cloud.google.com | bash

B.gcloud init

C.sudo apt-get install google-cloud-sdk

D.echo 'deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main' | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

AnswerD

This command correctly configures the official Cloud SDK apt repository on a Debian or Ubuntu system by appending a sources.list entry with the signed-by parameter pointing to the imported Google signing key at /usr/share/keyrings/cloud.google.gpg. Using signed-by binds the repository to that specific key instead of trusting the global apt keyring, which is the recommended security practice. After running this, you still need to run sudo apt-get update and sudo apt-get install google-cloud-sdk, but this repository definition is the essential correct foundation for the package-manager installation method.

Why this answer

The Cloud SDK installation guide for Linux uses echo to add the URI to /etc/apt/sources.list.d/google-cloud-sdk.list.

Full explanation →

316

MCQmedium

A platform admin creates a new GCP project for a team. The team lead's email is teamlead@company.com. The admin needs the team lead to be able to create resources in the project but not manage IAM policies or billing. Which role is most appropriate?

A.Owner

B.Editor

C.Viewer

D.Billing Account Administrator

AnswerB

Editor provides create, read, update, and delete permissions on all GCP resources, but explicitly excludes IAM policy changes and billing management. This aligns exactly with the team lead's requirement to create and manage resources without managing access controls or billing. It is a primitive role that is broader than needed for many tasks, but in this scenario it matches the stated need precisely without overprivileged access.

Why this answer

The Editor role (roles/editor) grants all permissions necessary to create, modify, and delete resources within a GCP project, but explicitly excludes permissions to manage IAM policies (roles/iam.securityAdmin or roles/owner) and billing (roles/billing.admin). This makes it the correct choice for a team lead who needs to deploy and manage resources without having the ability to change access controls or alter billing configurations.

Exam trap

Google Cloud often tests the distinction between resource-level permissions and management-level permissions, and the trap here is that candidates may confuse the Editor role with Owner because both can create resources, but only Owner can manage IAM and billing.

How to eliminate wrong answers

Option A is wrong because the Owner role (roles/owner) includes all Editor permissions plus the ability to manage IAM policies and billing, which violates the requirement that the team lead should not manage IAM or billing. Option C is wrong because the Viewer role (roles/viewer) only allows read-only access to existing resources and does not permit creating any resources. Option D is wrong because the Billing Account Administrator role (roles/billing.admin) manages billing accounts and budgets but does not grant any permissions to create project resources.

Full explanation →

317

MCQmedium

An engineer needs to enable the Compute Engine API for a project using the gcloud command line. Which command should they run?

A.gcloud compute instances enable-api

B.gcloud services list --enabled

C.gcloud api enable compute

D.gcloud services enable compute.googleapis.com

AnswerD

This is the correct command to enable the Compute Engine API. `gcloud services enable compute.googleapis.com` tells the Service Usage API to enable the service in the current project. It uses the fully-qualified service name and is the standard gcloud method for this operation. After running it, you can create and manage Compute Engine instances via gcloud or the Console.

Why this answer

The `gcloud services enable` command is the correct way to enable APIs for a project, and `compute.googleapis.com` is the service name for the Compute Engine API. The full command `gcloud services enable compute.googleapis.com` enables the API at the project level, which is required before creating Compute Engine resources.

Exam trap

ACE often tests the exact gcloud command syntax, tempting candidates to invent plausible-sounding but invalid commands like `gcloud api enable` or `gcloud compute instances enable-api`.

How to eliminate wrong answers

Option A is wrong because `gcloud compute instances enable-api` is not a valid gcloud command — `gcloud compute instances` only supports subcommands like create, delete, list, and start/stop, not enable-api. Option B is wrong because `gcloud services list --enabled` lists currently enabled services but does not enable anything. Option C is wrong because `gcloud api enable compute` is not valid syntax — the correct command group is `gcloud services`, not `gcloud api`, and the service name must be the full API identifier (compute.googleapis.com).

Full explanation →

318

MCQmedium

A company is migrating a legacy monolithic application to Google Cloud. The application runs on a single VM and contains both the web server and backend processes. The team wants to separate concerns and deploy the web tier on Cloud Run and the backend on Compute Engine. They need to allow the Cloud Run service to initiate HTTPS connections to the backend VM. What is the most secure way to accomplish this?

A.Assign a public IP to the backend VM and configure firewall rules to allow HTTPS from any source

B.Set up a VPN tunnel between Cloud Run and the VPC

C.Use Cloud NAT to provide outbound internet access to Cloud Run

D.Use Serverless VPC Access to connect Cloud Run to the VPC, and keep the VM internal

AnswerD

Using Serverless VPC Access to connect Cloud Run to the VPC and keeping the VM internal is the correct approach because it enables private, encrypted communication over the Google network. The connector lets Cloud Run reach the VM's internal IP address without the VM ever needing a public IP or a firewall rule for public traffic. This minimizes the attack surface and is the recommended pattern for serverless-to-VPC connectivity.

Why this answer

Serverless VPC Access creates a direct, private connection between Cloud Run and your VPC, allowing the Cloud Run service to reach the backend VM using its internal IP address. This avoids exposing the VM to the public internet, which is the most secure approach for initiating HTTPS connections between the two tiers.

Exam trap

Google Cloud often tests the misconception that Cloud NAT or public IPs are needed for serverless-to-VM communication, but the correct approach is to use Serverless VPC Access for private, secure connectivity without exposing the backend.

How to eliminate wrong answers

Option A is wrong because assigning a public IP and allowing HTTPS from any source exposes the backend VM to the entire internet, violating the principle of least privilege and creating a significant security risk. Option B is wrong because a VPN tunnel is used to connect external networks (e.g., on-premises) to a VPC, not to connect a serverless service like Cloud Run to a VM within the same VPC. Option C is wrong because Cloud NAT provides outbound internet access for private instances, but Cloud Run already has outbound internet access by default; the issue is inbound connectivity to the backend VM, which Cloud NAT does not address.

Full explanation →

319

MCQmedium

An engineer needs to attach an existing persistent disk to a Compute Engine instance. They have created the disk using 'gcloud compute disks create'. Which command should they use to attach it?

A.gcloud compute disks resize

B.gcloud compute instances attach-disk

C.gcloud compute instances add-disk

D.gcloud compute disks attach

AnswerB

gcloud compute instances attach-disk is the correct command: it attaches an existing zonal or regional persistent disk to a specified Compute Engine instance, using --disk and optionally --device-name. It works on both running and stopped instances, and it ensures the disk becomes visible as a block device in the instance's guest OS.

Why this answer

'gcloud compute instances attach-disk' attaches a disk to an instance. 'gcloud compute disks attach' does not exist. 'gcloud compute instances add-disk' is not a valid command. 'gcloud compute disks resize' resizes the disk.

Full explanation →

320

Multi-Selecthard

You are responsible for monitoring a set of Compute Engine instances that run a critical web application. You want to be alerted when the average CPU utilization across all instances exceeds 80% for more than 5 minutes. You also want to receive a notification via email and SMS. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Configure a notification channel for email and SMS in Cloud Monitoring and attach it to the alerting policy.

B.Create a log-based alert in Cloud Logging that triggers when CPU utilization exceeds 80%.

C.Create a Cloud Monitoring alerting policy with a condition on the CPU utilization metric, setting the threshold to 80% and the duration to 5 minutes.

D.Install the Cloud Monitoring agent on each instance to collect CPU utilization metrics.

E.Set up an uptime check to monitor the CPU utilization of the instances.

AnswersA, C

This is correct because Cloud Monitoring supports notification channels for email, SMS, and other services. To receive alerts via email and SMS, you must create those channels and associate them with the alerting policy. Without notification channels, the alert would trigger but no notifications would be sent.

Why this answer

To alert on CPU utilization, you need a Cloud Monitoring alerting policy with a condition on the CPU metric, and you must attach notification channels for email and SMS. The Monitoring agent is not required for CPU metrics, log-based alerts are for logs, and uptime checks are for availability, not resource metrics.

Exam trap

The trap here is thinking that the Cloud Monitoring agent is needed for CPU metrics, when CPU is a built-in metric; also confusing log-based alerts with metric alerts.

Full explanation →

321

MCQeasy

A developer needs to allow a Compute Engine instance to access a Cloud Storage bucket without using a service account key file. The instance runs in a project that has the necessary APIs enabled. What should the developer do?

A.Use the instance's default Compute Engine service account and grant it the Editor role.

B.Create a service account key and store it on the instance's persistent disk.

C.Attach a service account to the instance and grant it the necessary IAM roles.

D.Enable Cloud Storage API access on the instance's network interface.

AnswerC

Attaching a service account to a Compute Engine instance automatically provides the instance with credentials via the metadata server. The application can use the default credentials to authenticate to Google Cloud APIs. By granting the service account appropriate IAM roles, such as Storage Object Viewer, the instance gains access without managing any key files.

Why this answer

Attaching a service account to the instance allows the instance to obtain short-lived credentials from the metadata server, eliminating the need for key files. Granting that service account the necessary IAM roles ensures it has the required permissions to access the Cloud Storage bucket. This is the recommended secure and manageable approach for Compute Engine workloads.

Exam trap

The trap here is assuming that network-level settings or default service accounts with broad roles are the right way to grant access, rather than using a dedicated service account with least privilege.

Full explanation →

322

MCQeasy

You want to export a subset of Cloud Logging logs to BigQuery for long-term analysis. Which method should you use?

A.Create a log-based metric and export the metric to BigQuery

B.Create a log sink with a filter and destination BigQuery

C.Set up a Cloud Function that triggers on logs and inserts into BigQuery

D.Use gcloud logging read and pipe to bq load

AnswerB

A log sink with a filter and a BigQuery destination is the fully managed, native way to export logs: Cloud Logging continuously routes any newly ingested log entries that match the filter into a specified BigQuery dataset. The sink automatically creates a table with the log schema, and you can use the _PARTITIONTIME pseudo-column for time-based partitioning. This gives reliable, near-real-time export without custom code or manual intervention.

Why this answer

A log sink is the native Cloud Logging mechanism for routing log entries to supported destinations, and BigQuery is a first-class sink destination. By attaching an inclusion filter to the sink, you can export only the subset of logs you care about, and Cloud Logging handles the delivery and schema management automatically. This is the designed, serverless, and most operationally sound approach for long-term log analysis in BigQuery.

Exam trap

The trap here is confusing log-based metrics (numeric Monitoring time series) with log sinks (raw log routing), causing candidates to pick the metric option when the question asks for exporting actual log data.

How to eliminate wrong answers

Option A is wrong because log-based metrics only produce numeric time-series counters/distributions in Cloud Monitoring; they do not carry the original log payload and cannot be exported as raw log rows to BigQuery. Option C is wrong because a Cloud Function triggered on logs is a custom, brittle workaround that duplicates what a native sink does, adds latency and cost, and is not the supported export path. Option D is wrong because 'gcloud logging read' piped to 'bq load' is a manual, batch, one-off operation that does not provide continuous, filtered, near-real-time export and requires you to manage schema and scheduling yourself.

Full explanation →

323

Matchingmedium

Match each GCP networking concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Virtual private cloud network

Regional IP address range within a VPC

Outbound internet access for private instances

Distributes traffic across instances

Content delivery network for low-latency delivery

Why these pairings

VPC is a global network, Subnet is regional, Firewall rules control traffic, Cloud Router uses BGP for hybrid connectivity, and VPC Peering connects VPCs privately.

Full explanation →

324

Multi-Selectmedium

A company is planning to deploy a batch processing workload on Google Cloud. The workload runs for several hours each night, can tolerate interruptions, and must be cost-optimized. The operations team wants to minimize management effort and ensure the workload automatically restarts if a VM is preempted. Which TWO actions should the company take? (Choose two.)

Select 2 answers

A.Create a managed instance group using Spot VMs as the instance template and configure it to automatically recreate instances.

B.Deploy the workload on sole-tenant nodes to guarantee physical isolation from other customers.

C.Configure the workload to run on a single large standard VM with a local SSD for temporary data.

D.Use standard Compute Engine VMs with committed use discounts for a three-year term.

E.Set up a Cloud Scheduler job that starts the batch process on a schedule and stores checkpoints in Cloud Storage.

AnswersA, E

Spot VMs offer deep discounts for interruptible workloads, and a managed instance group with automatic recreation replaces preempted instances so the batch job can resume. This combination matches the tolerance for interruptions, the cost goal, and the requirement to restart automatically with minimal manual effort.

Why this answer

Spot VMs in a managed instance group deliver the required cost savings for interruptible batch work, and automatic recreation keeps the job running after preemption. Adding Cloud Scheduler for nightly starts and Cloud Storage checkpoints makes restarts efficient, so the workload completes with minimal operational effort.

Exam trap

The trap here is assuming that committed use discounts are always the cheapest option, when they only pay off for continuous usage and this workload runs just a few hours per night.

Full explanation →

325

MCQmedium

A company wants to deploy a containerized application on Google Cloud that automatically scales to zero when not in use, and they want to minimize operational overhead. They also need to avoid managing any underlying infrastructure such as Kubernetes clusters or VMs. Which service should they use?

A.Google Kubernetes Engine (GKE)

B.App Engine Standard Environment

C.Cloud Run

D.Compute Engine with managed instance groups

AnswerC

Cloud Run is a fully managed serverless container platform that automatically scales in response to incoming requests, including scaling to zero when idle, so you only pay for the exact compute time consumed. It doesn't require any cluster or infrastructure management, and it can be used with Knative Serving APIs, making it the most direct fit for a stateless containerized application that needs to scale to zero.

Why this answer

Cloud Run is a fully managed serverless platform that runs containerized applications and automatically scales to zero when there is no traffic, eliminating costs during idle periods. It abstracts away all infrastructure management, including Kubernetes clusters and VMs, so the company can focus solely on their container image. This directly satisfies the requirements of containerized deployment, scale-to-zero, and minimal operational overhead.

Exam trap

ACE often tests the distinction between serverless container platforms and orchestration services, trapping candidates who assume Kubernetes is required for containers or that App Engine supports arbitrary containers with scale-to-zero.

How to eliminate wrong answers

Option A is wrong because GKE requires managing a Kubernetes cluster (nodes, upgrades, networking), which adds operational overhead and does not scale to zero by default (nodes remain running). Option B is wrong because App Engine Standard runs applications in a language-specific sandbox and does not support arbitrary containerized workloads (though App Engine Flexible supports containers, it does not scale to zero and still requires some infrastructure management). Option D is wrong because Compute Engine with managed instance groups requires managing VMs and does not scale to zero (minimum instance count is typically 1), leading to higher operational overhead.

Full explanation →

326

MCQhard

A Cloud KMS key used to encrypt a Cloud Storage bucket's data is being destroyed. What happens to the data in the bucket when the KMS key is destroyed?

A.The data in Cloud Storage is automatically deleted along with the key.

B.The encrypted data becomes permanently inaccessible (cryptographic erasure) since the decryption key no longer exists.

C.Cloud Storage automatically re-encrypts the data using Google-managed keys as a fallback.

D.The key enters a 'disabled' state where data can still be decrypted by Google support.

AnswerB

Cloud Storage objects are encrypted with envelope encryption: a data encryption key (DEK) is generated per object and then wrapped by the Cloud KMS key. When that KMS key is destroyed, the DEK can never be unwrapped, so the ciphertext bytes in Cloud Storage remain but are mathematically unreadable. This is cryptographic erasure — effective deletion without physically deleting the stored object.

Why this answer

When a Cloud KMS key is destroyed, the encrypted data in Cloud Storage becomes permanently inaccessible because the cryptographic key material is irrecoverably deleted. This is known as cryptographic erasure: without the key, the ciphertext cannot be decrypted, even though the raw encrypted bytes still exist in the bucket. Cloud Storage does not store a copy of the KMS key, and there is no fallback mechanism to re-encrypt or recover the data.

Exam trap

Google Cloud often tests the misconception that destroying a KMS key triggers automatic data deletion or that Google provides a fallback re-encryption mechanism, when in fact the data remains but is cryptographically erased and unrecoverable.

How to eliminate wrong answers

Option A is wrong because destroying the KMS key does not trigger automatic deletion of the encrypted data objects in Cloud Storage; the objects remain but are unreadable. Option C is wrong because Cloud Storage does not automatically re-encrypt data with Google-managed keys when a customer-managed KMS key is destroyed; the data remains encrypted with the destroyed key and is permanently inaccessible. Option D is wrong because key destruction is irreversible and does not enter a 'disabled' state; Google Support cannot decrypt data after a KMS key is destroyed, as the key material is permanently deleted and no backup exists.

Full explanation →

327

MCQeasy

Which gcloud command is used to deploy a Cloud Function triggered by HTTP requests?

A.gcloud functions call my-function --data '{"key":"value"}'

B.gcloud run deploy my-function --source . --platform managed

C.gcloud functions deploy my-function --runtime python39 --trigger-http

D.gcloud functions deploy my-function --runtime python39 --trigger-topic my-topic

AnswerC

This command correctly deploys an HTTP-triggered Cloud Function: `gcloud functions deploy` creates or updates a function resource, `--runtime python39` selects the Python 3.9 execution environment, and `--trigger-http` configures an HTTPS endpoint that invokes the function on web requests. No other trigger type is needed. The command will return a URL for the deployed function.

Why this answer

The command 'gcloud functions deploy' with --trigger-http creates an HTTP-triggered function. --runtime specifies the language runtime. --trigger-topic is for Pub/Sub triggers.

Full explanation →

328

MCQhard

Your Cloud SQL for MySQL primary instance in `us-central1` has failed. Cloud SQL HA automatically fails over to the standby. After the failover, your application is experiencing intermittent connection errors. What is the most likely cause and solution?

A.The standby instance has a different IP address; update the connection string.

B.Application connection pools hold stale connections to the failed primary; configure pools to validate connections and reconnect after failure.

C.The standby replica must be manually promoted before it can accept connections.

D.The MySQL binary log is incomplete after failover; run `mysqlcheck` to repair tables.

AnswerB

Connection pools retain TCP sessions that were established with the original primary; when failover occurs, those sessions are forcibly terminated and remain marked as 'open' in the pool. Without validation, the pool hands out dead connections and the application sees errors immediately after failover. Configure the pool to test connections before borrowing (e.g., testOnBorrow with a lightweight SELECT 1, or initialization/eviction checks) and to create new connections automatically. Using the Cloud SQL Auth Proxy also masks this by re-establishing connections to the new primary seamlessly.

Why this answer

After a Cloud SQL HA failover, the standby instance becomes the new primary with the same IP address, but existing application connections that were established to the old primary are now broken. Connection pools that do not validate connections before reuse will attempt to use these stale connections, causing intermittent errors. Configuring the pool to test connections (e.g., via `SELECT 1` or JDBC `connectionTestQuery`) and automatically reconnect resolves this by discarding dead connections and establishing fresh ones to the new primary.

Exam trap

Google Cloud often tests the misconception that IP addresses change during HA failover, leading candidates to incorrectly choose Option A, but in Cloud SQL HA the VIP remains constant, and the real issue is stale connections in the application pool.

How to eliminate wrong answers

Option A is wrong because Cloud SQL HA failover preserves the same IP address (the VIP is moved to the standby), so updating the connection string is unnecessary and would not fix stale connection pool issues. Option C is wrong because Cloud SQL HA automatically promotes the standby to primary during failover; no manual promotion is required, and the standby accepts connections immediately after failover completes. Option D is wrong because MySQL binary logs are replicated continuously to the standby in HA configurations, so the binary log is not incomplete after failover; `mysqlcheck` is used for table corruption repair, not for connection errors, and is unrelated to the described symptom.

Full explanation →

329

MCQhard

A company is migrating a PostgreSQL database to Cloud SQL. They need high availability with automatic failover and a read replica for reporting queries that must not impact the primary. Which Cloud SQL configuration should they choose?

A.High Availability (HA) configuration with automatic storage increase

B.High Availability (HA) configuration with a read replica

C.Single zone instance with a failover replica

D.Single zone instance with cross-region replication

AnswerB

Cloud SQL HA automatically fails over to a synchronous standby in a different zone, protecting against zonal outages. A read replica, created using binary log replication, serves read-only queries like reporting without burdening the primary. Together, these features satisfy both availability and performance needs, allowing the reporting workload to run in parallel with production.

Why this answer

Cloud SQL High Availability (HA) configuration provides a standby instance in a different zone with automatic failover, satisfying the HA requirement. Adding a read replica offloads reporting queries from the primary, ensuring they do not impact production performance. This combination meets both the HA and read-scaling needs.

Exam trap

ACE often tests the misconception that a failover replica is the same as a read replica; candidates must remember that HA provides automatic failover, while read replicas are for scaling reads and do not failover.

How to eliminate wrong answers

Option A is wrong because automatic storage increase addresses storage capacity, not read scaling or reporting isolation. Option C is wrong because a single-zone instance with a failover replica is the legacy HA configuration (now replaced by the regional HA setup) and does not provide a read replica for reporting. Option D is wrong because cross-region replication is for disaster recovery or read scaling across regions, but it does not provide automatic failover within a region and is not the standard HA configuration.

Full explanation →

330

MCQmedium

An engineer needs to create a Cloud SQL MySQL instance with 4 vCPUs, 15 GB of RAM, and a root password. The instance should be in the us-east1 region. Which command should the engineer run?

A.gcloud sql instances create my-instance --database-version=MYSQL_8_0 --tier=db-custom-4-15360 --region=us-east1

B.gcloud sql instances create my-instance --database-version=MYSQL_5_7 --tier=db-n1-standard-4 --region=us-east1-a --root-password=myPassword

C.gcloud sql instances create my-instance --database-version=MYSQL_8_0 --tier=db-custom-2-7680 --region=us-east1 --root-password=myPassword

D.gcloud sql instances create my-instance --database-version=MYSQL_8_0 --tier=db-custom-4-15360 --region=us-east1 --root-password=myPassword

AnswerD

The `--tier=db-custom-4-15360` flag defines a custom machine type with exactly 4 vCPUs and 15360 MB (15 GB) of RAM, satisfying the stem's sizing constraint. Combined with `--database-version=MYSQL_8_0`, `--region=us-east1` and `--root-password`, it fulfils every stated requirement in one command.

Why this answer

The correct command must specify a custom machine type matching 4 vCPUs and 15 GB RAM, which is `db-custom-4-15360` (the format is db-custom-<vCPUs>-<memoryMB>). It must also include the root password and target the us-east1 region (not a zone). Option D is the only command that includes all required parameters: MYSQL_8_0, the correct custom tier, the region, and the root password.

Exam trap

ACE often tests whether candidates can decode the `db-custom-<vCPU>-<memoryMB>` format and distinguish `--region` from `--zone` — picking a zone value for `--region` is a classic distractor.

How to eliminate wrong answers

Option A is wrong because it omits the required `--root-password` flag, so the instance would be created without the specified root password. Option B is wrong because `db-n1-standard-4` is a predefined tier (4 vCPU, 15 GB) but the region is specified as `us-east1-a`, which is a zone, not a region — Cloud SQL instances are regional resources and `--region` expects a region name. Option C is wrong because `db-custom-2-7680` corresponds to 2 vCPUs and 7.5 GB RAM, not the required 4 vCPUs and 15 GB.

Full explanation →

331

MCQmedium

An engineer wants to create a Google-managed SSL certificate for an HTTPS load balancer. Which command should they use?

A.gcloud compute ssl-policies create my-policy --profile MODERN

B.gcloud compute ssl-certificates create my-cert --domains example.com

C.gcloud compute ssl-certificates create my-cert --certificate cert.pem --private-key key.pem

D.gcloud compute target-https-proxies create my-proxy --ssl-certificates my-cert

AnswerB

This is the correct command because it explicitly instructs Compute Engine to provision a Google-managed certificate for the specified domains. The --domains flag triggers Google's automatic certificate management lifecycle: Google Cloud obtains the certificate and handles renewals approximately 30 days before expiration, though you must verify domain ownership first. After creation, the certificate resource still needs to be attached to a target HTTPS proxy and associated with a forwarding rule before it can serve traffic.

Why this answer

Google-managed SSL certificates are created with `gcloud compute ssl-certificates create` and only require the `--domains` flag; Google provisions and renews the certificate automatically. The absence of `--certificate` and `--private-key` is what distinguishes a Google-managed cert from a self-managed one. The resulting certificate resource can then be attached to a target HTTPS proxy.

Exam trap

ACE often tests the distinction between Google-managed and self-managed certificates, so candidates who see `--certificate` and `--private-key` flags assume they are required and pick the self-managed option.

How to eliminate wrong answers

Option A is wrong because `gcloud compute ssl-policies create` creates an SSL policy (a TLS version/cipher-suite profile such as MODERN), not a certificate. Option C is wrong because supplying `--certificate cert.pem --private-key key.pem` creates a self-managed certificate, not a Google-managed one. Option D is wrong because `gcloud compute target-https-proxies create` creates the HTTPS proxy that consumes a certificate; it does not create the certificate itself.

Full explanation →

332

MCQmedium

A team wants to grant a contractor the Storage Object Viewer role on a specific bucket path, but only during business hours (Monday–Friday, 9am–5pm local time). Which IAM feature supports these conditions?

A.IAM deny policies scoped to non-business hours

B.IAM Conditions on the role binding

C.VPC Service Controls with a time-based access policy

D.Cloud Scheduler removing and re-adding the IAM binding on a schedule

AnswerB

IAM Conditions attach to a specific role binding and can include expressions using request.time, which supports date/time, day-of-week, and time-of-day comparisons such as Monday through Friday between 09:00 and 17:00. The condition narrows the binding's effect without altering the rest of the organization, folder, or project IAM policy. This approach is the recommended pattern because it is evaluated in real time by Cloud IAM, requires no external orchestration, and applies automatically to every API request that uses that binding.

Why this answer

IAM Conditions allow you to define time-based constraints on role bindings using the `request.time` attribute. By setting a condition that restricts access to Monday–Friday, 9am–5pm, the contractor is granted the Storage Object Viewer role only during those hours. This is the native IAM feature designed for such fine-grained, attribute-based access control.

Exam trap

Google Cloud often tests the distinction between IAM Conditions (which are attribute-based and evaluated at runtime) and external scheduling mechanisms like Cloud Scheduler, leading candidates to mistakenly choose the latter as a 'valid' solution despite its lack of native IAM integration and potential for access gaps.

How to eliminate wrong answers

Option A is wrong because IAM deny policies are used to explicitly deny access regardless of other allow policies, but they cannot be scoped to non-business hours in a way that grants access during business hours; they would deny access at all times unless combined with an allow policy, which is not the intended use. Option C is wrong because VPC Service Controls are designed to protect data within a VPC service perimeter based on network context and identity, not to enforce time-based access conditions on IAM roles. Option D is wrong because Cloud Scheduler removing and re-adding IAM bindings on a schedule is an overly complex, error-prone workaround that introduces latency and potential race conditions; it is not an IAM feature and does not provide real-time conditional access.

Full explanation →

333

MCQmedium

An organization has a VPC with instances in two subnets: subnet-a (10.0.1.0/24) and subnet-b (10.0.2.0/24). They want to allow HTTP traffic from any instance in subnet-a to any instance in subnet-b. What firewall rule should be created?

A.An egress rule on subnet-b allowing traffic to 10.0.1.0/24 on TCP port 80

B.An ingress rule on subnet-a allowing traffic to 10.0.2.0/24 on TCP port 80

C.An ingress rule on subnet-b allowing traffic from 10.0.1.0/24 on TCP port 80

D.An egress rule on subnet-a allowing traffic to 10.0.2.0/24 on TCP port 80

AnswerC

This is correct because the HTTP request travels from an instance in subnet-a (source 10.0.1.0/24) to an instance in subnet-b (destination) on TCP port 80. An ingress rule on subnet-b with the source range set to 10.0.1.0/24 explicitly allows that inbound connection at the destination. In GCP, the destination subnet's ingress rules are the primary gate for allowing traffic to reach the target instance.

Why this answer

Firewall rules are defined with direction and source/target. To allow inbound traffic to subnet-b from subnet-a, an ingress rule with source range 10.0.1.0/24 is needed.

Full explanation →

334

MCQeasy

A user wants to use gcloud to create a Cloud Storage bucket but receives a permission denied error. What is the most likely cause?

A.The bucket name is already taken

B.The user is not authenticated

C.The user does not have storage.buckets.create permission

D.The project does not have billing enabled

AnswerC

The gcloud storage buckets create command calls the Cloud Storage API, which verifies that the authenticated user has the storage.buckets.create permission on the project. A 'permissionDenied' error indicates a missing IAM role, such as Storage Admin (roles/storage.admin) or a custom role containing that permission. Since the request is authenticated but not authorized, this is the correct explanation.

Why this answer

C is correct because Cloud Storage uses IAM permissions to control access to bucket creation. The specific permission required is `storage.buckets.create`, which must be granted at the project level. Without this permission, the gcloud command will fail with a permission denied error, even if the user is authenticated and billing is enabled.

Exam trap

Google Cloud often tests the distinction between authentication (who you are) and authorization (what you can do), so the trap here is that candidates may confuse a permission denied error with an authentication failure or a naming conflict.

How to eliminate wrong answers

Option A is wrong because a bucket name being taken results in a '409 Conflict' error, not a permission denied error. Option B is wrong because if the user is not authenticated, gcloud would return an authentication error (e.g., 'ERROR: (gcloud) You do not have permission to access project') or prompt for login, not a generic permission denied. Option D is wrong because billing is not required to create a bucket; it is required for using the bucket (e.g., storing data) but not for the creation API call itself.

Full explanation →

335

MCQmedium

A Cloud Identity admin needs to grant a user access to manage billing for a specific GCP project without giving them access to any other projects in the organization. Which role should be assigned at the project level?

A.Billing Account Administrator at the organization level

B.Project Billing Manager on the specific project

C.Editor on the specific project

D.Billing Account User at the billing account level

AnswerB

Project Billing Manager on the specific project is correct because the role roles/billing.projectManager includes billing.projects.update, which permits linking or unlinking a billing account to precisely that project. It is scoped at the project level, so the user gains no access to other projects or to the billing account's administrative settings, satisfying least privilege.

Why this answer

The Project Billing Manager role is the correct choice because it grants permissions to manage billing for a specific GCP project, including viewing billing reports and setting budget alerts, without providing access to other projects. This role is assigned at the project level, ensuring the user's billing management scope is limited to that single project.

Exam trap

The trap here is that candidates often confuse the Project Billing Manager role with the Billing Account User role, mistakenly thinking the latter provides project-level billing management, when in fact it only allows linking projects to a billing account and does not grant billing management permissions for a specific project.

How to eliminate wrong answers

Option A is wrong because the Billing Account Administrator role at the organization level grants full control over the billing account, including the ability to link or unlink projects, which would give the user access to billing for all projects under that billing account, not just the specific one. Option C is wrong because the Editor role on the specific project includes permissions to modify project resources (e.g., compute, storage) beyond billing management, violating the principle of least privilege. Option D is wrong because the Billing Account User role at the billing account level allows the user to link projects to the billing account but does not grant permissions to manage billing for a specific project; it is designed for users who need to associate projects with a billing account, not for project-level billing administration.

Full explanation →

336

Multi-Selectmedium

An engineer needs to enable the Cloud Build API and the Kubernetes Engine API for a project. Which TWO commands should they run?

Select 2 answers

A.gcloud services enable cloudbuild.googleapis.com

B.gcloud services enable container.googleapis.com

C.gcloud services enable compute.googleapis.com

D.gcloud services enable kubernetes-engine.googleapis.com

E.gcloud services enable cloudbuild.googleapis.com --project=my-project

AnswersA, B

Enabling cloudbuild.googleapis.com activates the Cloud Build service for the project, satisfying the requirement to enable the Cloud Build API. The paired command must enable container.googleapis.com for Kubernetes Engine, since each Google Cloud API is enabled individually by its own service name.

Why this answer

Option A is correct because `gcloud services enable cloudbuild.googleapis.com` enables the Cloud Build API using the configured project. Option B is correct because `gcloud services enable container.googleapis.com` enables the Kubernetes Engine API (service name `container.googleapis.com`). Option C is wrong because `compute.googleapis.com` is the Compute Engine API.

Option D is wrong because `kubernetes-engine.googleapis.com` is not the correct service name. Option E is wrong because `--project=my-project` targets a specific project named `my-project`, but the question does not provide that project ID; without this flag the command applies to the default configured project. Therefore E is not one of the two required commands.

Exam trap

ACE often tests exact service names and project scoping. Candidates may incorrectly choose kubernetes-engine.googleapis.com or a command with an explicit --project flag that assumes a specific project ID not given in the question.

Full explanation →

337

Multi-Selecteasy

A developer is deploying an HTTP-triggered Cloud Function for a production application. Which TWO configuration options should be applied to ensure security and control costs? (Choose two.)

Select 2 answers

A.Allow unauthenticated invocations

B.Set a maximum instances limit

C.Set minimum instances to 0

D.Configure a custom domain for the function

E.Use a service account to authenticate invocations

AnswersB, E

Setting a maximum instances limit caps the number of concurrent Cloud Function instances that can be spun up in response to traffic. Without this limit, a sudden spike or a distributed denial-of-service attack could cause the function to scale out to a default high number, driving unbounded costs and risking quota exhaustion. A low maximum, such as 1 or 2 instances, both controls cost and limits the blast radius of a runaway or malicious invocation pattern, making it a practical cost-control and mild DoS mitigation measure.

Why this answer

Option B is correct because setting a maximum instances limit caps the number of concurrent function instances, which directly bounds the potential scaling and therefore controls the cost of an HTTP-triggered Cloud Function under heavy or unexpected traffic. Option E is correct because requiring a service account to authenticate invocations enforces IAM-based access control, ensuring only authorized identities (via signed ID tokens) can call the function, which is essential for a production security posture. Option A is incorrect because allowing unauthenticated invocations exposes the function publicly and defeats the security requirement.

Option C is incorrect because setting minimum instances to 0 only affects cold-start behavior and cost of idle capacity, not the security or the upper cost bound the scenario demands. Option D is incorrect because a custom domain is a routing/branding convenience and does not by itself provide security or cost control.

Exam trap

Google Cloud often tests the misconception that setting minimum instances to 0 is a cost-saving measure, but it is actually the default and does not control costs; the trap is confusing 'minimum instances' with 'maximum instances' for cost control.

Full explanation →

338

MCQhard

A company uses Cloud CDN to accelerate content delivery. They notice that some requests are not being cached, despite the cache-control headers being set correctly. The origin is a Compute Engine instance behind an HTTP load balancer. What is a likely cause?

A.The cache key includes the query string, causing too many variations.

B.The load balancer is using HTTP/2, which disables caching.

C.The content type is not supported by Cloud CDN.

D.The origin returns a Set-Cookie header, which prevents caching by default.

AnswerD

When an origin includes a Set-Cookie header in a response, Cloud CDN's default cache mode treats that response as private and skips caching entirely. This prevents any user-specific response from being accidentally served to other users, and follows the principle that responses with cookies often contain personalized data. Unless you explicitly configure the cache mode to FORCE_CACHE_ALL or configure Cloud CDN to ignore Set-Cookie, the presence of Set-Cookie effectively disables caching for that response.

Why this answer

Cloud CDN will not cache responses that include a Set-Cookie header by default, even if Cache-Control headers are correctly set. This is because Set-Cookie indicates user-specific or session-specific content, and caching it could lead to serving private data to other users. The origin (Compute Engine behind an HTTP load balancer) returning Set-Cookie effectively disables caching for those responses.

Exam trap

The trap here is that candidates often focus on cache-control headers or query strings, but Google Cloud tests the less obvious behavior that Set-Cookie headers implicitly prevent caching in Cloud CDN, even when other caching directives appear correct.

How to eliminate wrong answers

Option A is wrong because query string variations in the cache key can reduce cache hit ratio but do not prevent caching entirely; Cloud CDN can still cache responses with query strings if the cache key is configured appropriately. Option B is wrong because HTTP/2 does not disable caching; Cloud CDN fully supports HTTP/2 and caching behavior is independent of the HTTP version. Option C is wrong because Cloud CDN supports caching for all standard content types (e.g., text, image, video, application) and does not restrict caching based on content type.

Full explanation →

339

MCQeasy

A developer needs to create a Compute Engine VM with 4 vCPUs, 15 GB of memory, and a Debian 10 boot disk. Which gcloud compute instances create command is correct?

A.gcloud compute instances create my-vm --machine-type=n1-highmem-4 --image-family=debian-10 --image-project=debian-cloud

B.gcloud compute instances create my-vm --machine-type=n1-standard-4 --image-family=debian-10 --image-project=debian-cloud

C.gcloud compute instances create my-vm --machine-type=n1-standard-4 --image-family=ubuntu-1804 --image-project=ubuntu-os-cloud

D.gcloud compute instances create my-vm --machine-type=n1-standard-4

AnswerB

This is the correct command because n1-standard-4 is the general-purpose machine type that provides exactly 4 vCPUs and 15 GB of memory, satisfying the stated requirement. It also explicitly sets --image-family=debian-10 and --image-project=debian-cloud, which tells gcloud to use the latest active Debian 10 image from the official debian-cloud project. The command is complete and creates a reproducible Debian 10 VM with the desired vCPU count.

Why this answer

The `n1-standard-4` machine type provides exactly 4 vCPUs and 15 GB of memory, matching the requirement. Combined with `--image-family=debian-10` and `--image-project=debian-cloud`, this command creates a Debian 10 VM with the correct specs. The `n1-standard` family is the general-purpose line with a 1:3.75 vCPU-to-memory ratio.

Exam trap

ACE often tests whether candidates know the exact vCPU-to-memory ratios of GCE machine type families, especially confusing `n1-standard-4` (15 GB) with `n1-highmem-4` (26 GB).

How to eliminate wrong answers

Option A is wrong because `n1-highmem-4` provides 4 vCPUs but 26 GB of memory, not 15 GB — it belongs to the high-memory family with a 1:6.5 ratio. Option C is wrong because it specifies `ubuntu-1804` and `ubuntu-os-cloud`, which creates an Ubuntu 18.04 VM, not Debian 10 as required. Option D is wrong because it omits both the image family and image project flags, so the VM would use the default image (often Debian, but not guaranteed to be Debian 10) and lacks the explicit boot disk specification.

Full explanation →

340

MCQmedium

You want to monitor the uptime of an external HTTP endpoint every minute and receive an email notification if the endpoint is unavailable for more than two consecutive checks. What should you do?

A.Create a log-based alert in Cloud Logging that triggers on network errors

B.Create an uptime check in Cloud Monitoring, then create an alerting policy with condition 'metric threshold' for 'check_failed' and set notification channel to email

C.Use Cloud Functions to periodically call the endpoint and send an email on failure

D.Configure a TCP health check on the load balancer

AnswerB

Uptime checks in Cloud Monitoring are the managed, intended way to verify that an external HTTP endpoint is reachable and returning expected responses from multiple locations across the globe. The check_failed metric increments each time a probe fails, and a metric-threshold alerting policy lets you define a condition—for instance, when the number of failed checks is consistently above zero over a specified period—and route it to an email notification channel. This directly implements the requirement without custom code.

Why this answer

Cloud Monitoring uptime checks are purpose-built to probe external HTTP/HTTPS/TCP endpoints on a schedule (as frequent as once per minute), and alerting policies can trigger on the 'check_failed' metric with a threshold and duration that maps to 'two consecutive failures.' Email notification channels are natively supported, making this the correct, managed solution without custom code.

Exam trap

ACE often tests the difference between reactive log-based alerting and proactive uptime monitoring — candidates choose Cloud Logging alerts when the requirement is active endpoint probing.

How to eliminate wrong answers

Option A is wrong because log-based alerts in Cloud Logging react to log entries, not active probing of an external endpoint — there is no log generated if the endpoint simply goes down. Option C is wrong because Cloud Functions would require custom code, scheduling, state tracking for consecutive failures, and email integration — reinventing what Cloud Monitoring provides natively and adding operational overhead. Option D is wrong because a load balancer TCP health check only monitors backends behind that load balancer and does not send email alerts on its own; it also doesn't probe arbitrary external endpoints.

Full explanation →

341

MCQhard

A platform team is deploying a multi-tier application on GKE: a frontend Deployment, a backend Deployment, and a Redis StatefulSet. The backend must be reachable by name from the frontend, but not from outside the cluster. Which Kubernetes resource enables internal name-based service discovery?

A.A NodePort Service for the backend

B.A ClusterIP Service for the backend

C.A LoadBalancer Service for the backend

D.A Kubernetes Ingress resource for the backend

AnswerB

A ClusterIP Service is the correct choice because it provisions a stable virtual IP and an internal DNS record (e.g., backend.default.svc.cluster.local) that is resolvable only within the cluster. Frontend pods can communicate with the backend by its service name, and kube-proxy load-balances traffic to the backend pods automatically. Because the Service is not published on any node IP or external load balancer, it remains strictly internal, fully matching the requirement.

Why this answer

A ClusterIP Service exposes the backend Pods on a stable, internal IP address that is only reachable from within the GKE cluster. The frontend can resolve the backend by the Service's DNS name (e.g., `backend.default.svc.cluster.local`) using the cluster's internal DNS (CoreDNS), enabling name-based service discovery without exposing the backend to external traffic.

Exam trap

Google Cloud often tests the misconception that Ingress is used for internal service discovery, but Ingress is an external-facing layer-7 routing resource that requires a Service (typically ClusterIP or NodePort) to route traffic, and it does not provide internal DNS-based name resolution by itself.

How to eliminate wrong answers

Option A is wrong because a NodePort Service exposes the backend on a static port on every node's IP address, making it reachable from outside the cluster, which violates the requirement that the backend not be accessible externally. Option C is wrong because a LoadBalancer Service provisions an external cloud load balancer with a public IP, explicitly exposing the backend to the internet or external networks. Option D is wrong because a Kubernetes Ingress resource is an API object that manages external HTTP/S traffic routing to Services, typically requiring an Ingress controller and exposing the backend to external clients; it does not provide internal-only name-based discovery.

Full explanation →

342

MCQmedium

You need to export logs from Cloud Logging to a BigQuery dataset for long-term analysis. What should you create?

A.An alerting policy with a log-based trigger

B.A log-based metric

C.An export job in BigQuery

D.A log sink with BigQuery as the destination

AnswerD

A log sink with BigQuery as the destination is the correct method: Cloud Logging's log router matches your chosen log entries and delivers them to a BigQuery dataset, where each daily collection becomes a table. You configure the destination by providing a dataset name, and the sink automatically handles batching and streaming writes. This is the officially supported, commonly used way to export logs to BigQuery for analytics.

Why this answer

To export logs from Cloud Logging to BigQuery, you create a log sink with BigQuery as the destination. Log sinks are the mechanism in Google Cloud for routing log entries to supported destinations, including BigQuery, Cloud Storage, and Pub/Sub. This allows for long-term storage and analysis.

Exam trap

ACE often tests the confusion between log-based metrics and log sinks; candidates may choose log-based metrics thinking they export logs, but metrics only aggregate data for monitoring, not export raw logs.

How to eliminate wrong answers

Option A is wrong because an alerting policy with a log-based trigger is used to notify when specific log events occur, not to export logs. Option B is wrong because a log-based metric counts or extracts values from logs for monitoring, but does not export the raw logs. Option C is wrong because an export job in BigQuery is not a native Cloud Logging feature; you cannot directly create an export job from Cloud Logging to BigQuery without a sink.

Full explanation →

343

MCQhard

You need to drain a GKE node for maintenance, ensuring that daemonsets and pods using emptyDir volumes are handled properly. Which command should you use?

A.kubectl taint nodes NODE key=value:NoSchedule

B.kubectl drain NODE --ignore-daemonsets --delete-emptydir-data

C.kubectl delete node NODE

D.kubectl cordon NODE && kubectl delete pods --all

AnswerB

`kubectl drain` gracefully evicts all pods from the node while respecting PodDisruptionBudgets, making the node unschedulable and empty for maintenance. The `--ignore-daemonsets` flag skips DaemonSet-managed pods, which are intended to run on every node and would otherwise block eviction, while `--delete-emptydir-data` allows deletion of pods using emptyDir volumes, which would otherwise prevent the drain from finishing. These flags together ensure the command completes cleanly on nodes with these pod types.

Why this answer

kubectl drain with flags ignores daemonsets and deletes emptyDir pods.

Full explanation →

344

Multi-Selectmedium

An engineer needs to allow a set of Compute Engine instances (with tag 'web-server') to receive traffic on port 443 from the internet. The VPC has a default network with default firewall rules. Which TWO actions should the engineer take? (Choose TWO)

Select 2 answers

A.Create a firewall rule allowing ingress from 0.0.0.0/0 on port 443 with target tag 'https-server' and priority 1000.

B.Modify the default-allow-https rule to change the target tag to 'web-server'.

C.Delete the default-allow-https rule to avoid conflicts.

D.Create a firewall rule allowing ingress from 0.0.0.0/0 on port 443 with target tag 'web-server' and priority 1000.

E.Ensure that instances have the 'web-server' network tag applied.

AnswersD, E

Default network rules permit internal traffic and deny most external ingress, so an explicit ingress rule is required. Specifying 0.0.0.0/0 as source, port 443, target tag 'web-server' and priority 1000 permits internet HTTPS traffic to precisely those tagged instances, satisfying the stated requirement.

Why this answer

Option D is correct because a VPC firewall rule must explicitly match the instances it protects via a target tag, so creating an ingress rule from 0.0.0.0/0 on tcp:443 with target tag 'web-server' and a priority (1000) permits the desired HTTPS traffic to exactly those instances. Option E is correct because firewall target tags only apply to instances that actually carry the matching network tag, so the Compute Engine instances must have the 'web-server' tag applied for the rule to take effect. Option A is wrong because its target tag 'https-server' does not match the instances tagged 'web-server', so the rule would not apply to them.

Option B is wrong because the default network's default-allow-https rule targets 'https-server', and modifying it to 'web-server' would affect all instances with that tag rather than cleanly scoping the change, and it is not the required action here. Option C is wrong because deleting the default-allow-https rule is unnecessary and would remove existing HTTPS access for instances tagged 'https-server' without solving the tagging mismatch.

Exam trap

ACE often tests the need to both create a firewall rule with the correct target tag and ensure instances have that tag, so candidates may forget to apply the tag or choose the wrong tag.

Full explanation →

345

MCQmedium

A team's Cloud Build jobs are consistently failing with 'quota exceeded' errors. Billing is active and the project has available budget. What should the team do?

A.Delete unused projects in the same organization to release global quota

B.Upgrade the billing account to a higher payment tier

C.Request a quota increase for the Cloud Build API in the project settings

D.Use a larger machine type for Cloud Build worker pools

AnswerC

The correct resolution is to submit a quota increase request for Cloud Build API metrics, such as concurrent builds or daily build time, in the project's IAM & Admin > Quotas page (or the Cloud Quotas product). Choose the specific metric that triggered the error, specify a new limit, and provide a justification; the request is then reviewed by Google Cloud. Once approved, the new limit applies to that project, resolving the quota exhaustion error.

Why this answer

Cloud Build quota errors indicate that the project has reached its API rate limit or concurrent build limit, not a billing issue. Quotas are per-project and can be increased by requesting a higher limit from the Cloud Build API quotas page in the Google Cloud Console. Billing being active and having budget means the issue is not financial, so the team must specifically request a quota increase for the Cloud Build API.

Exam trap

The trap here is that candidates confuse billing-related errors (e.g., 'insufficient funds') with quota errors (e.g., 'quota exceeded'), leading them to incorrectly choose billing upgrades or project deletions instead of recognizing that API quotas are a separate, project-level limit that must be explicitly increased.

How to eliminate wrong answers

Option A is wrong because deleting unused projects does not release global quota; quotas are per-project and independent, so removing other projects has no effect on the Cloud Build quota in the affected project. Option B is wrong because upgrading the billing account to a higher payment tier does not affect API quotas; billing tiers relate to payment methods and invoicing, not resource limits. Option D is wrong because using a larger machine type for Cloud Build worker pools changes the compute resources for builds but does not increase the API quota for the number of concurrent builds or API requests; quota errors are about rate limits, not machine size.

Full explanation →

346

MCQhard

A team is using Terraform to manage infrastructure. They want to store the Terraform state file remotely in a GCS bucket for team collaboration. Which Terraform backend configuration is correct?

A.terraform { backend "gcs" { bucket = "my-terraform-state" } }

B.terraform { backend "gcs" { bucket = "my-terraform-state" prefix = "terraform/state" } }

C.terraform { backend "storage" { bucket = "my-terraform-state" } }

D.terraform { backend "gcloud" { bucket = "my-terraform-state" } }

AnswerA, B

Correct. The 'gcs' backend requires a 'bucket' argument. This configuration will store the state file in the root of the bucket.

Why this answer

Both options A and B are valid Terraform backend configurations for GCS. Option A uses the minimal required argument 'bucket'. Option B adds the optional 'prefix' argument to organize state files within the bucket.

The 'gcs' backend supports both. Options C and D are invalid because 'storage' and 'gcloud' are not valid backend types.

Full explanation →

347

MCQmedium

A network team is creating a new VPC and must decide between auto mode and custom mode. Why would they choose custom mode?

A.Auto mode VPCs cost more per subnet than custom mode

B.Custom mode allows full control over which regions have subnets and what CIDR ranges are used

C.Auto mode VPCs cannot be used with GKE clusters

D.Custom mode VPCs support more IP addresses per subnet than auto mode

AnswerB

In custom mode, you explicitly define every subnet, choosing the exact region and CIDR block, which lets you align your VPC address space with on-premises networks and avoid overlapping IP ranges that would break VPN or Interconnect peering. Unlike auto mode, which automatically creates subnets in all regions using a reserved 10.128.0.0/9 range (each with a /20), custom mode gives you the flexibility to create subnets only where needed and with appropriate sizes, preventing subnet sprawl and preserving address space for future growth. This control is essential for hybrid cloud designs that require careful CIDR planning to ensure route propagation doesn't conflict.

Why this answer

Custom mode VPCs give the network team full control over the IP address range (CIDR block) and the ability to create subnets in any region, unlike auto mode VPCs which automatically create subnets in every region with a fixed /20 range per region. This is essential when you need to avoid overlapping CIDRs with on-premises networks or other VPCs, or when you want to restrict subnets to specific regions for compliance or cost reasons.

Exam trap

Google Cloud often tests the misconception that auto mode VPCs are more expensive or have IP limitations, when in fact the key differentiator is control over subnet placement and CIDR range, not cost or capacity.

How to eliminate wrong answers

Option A is wrong because auto mode and custom mode VPCs have the same pricing model—there is no cost difference per subnet; both are free to create and use, with charges only for resources like NAT gateways or VPNs. Option C is wrong because auto mode VPCs can be used with GKE clusters; GKE supports both auto and custom mode VPCs, though custom mode is often preferred for more precise subnet control. Option D is wrong because both auto and custom mode VPCs support the same maximum IP address per subnet (the default limit is 256 IPs per subnet, which can be increased via quota request, but the mode does not affect this limit).

Full explanation →

348

MCQeasy

A team needs to run a simple containerized script that processes a batch of files once per night and exits when done — no HTTP endpoint needed. Which GCP service is most appropriate?

A.Cloud Run Services with a timeout set to 24 hours

B.Cloud Run Jobs triggered by Cloud Scheduler

C.Cloud Functions with a 540-second maximum timeout

D.App Engine Standard with a background service

AnswerB

Cloud Run Jobs execute a container to completion in response to an explicit execution request, making them ideal for a nightly batch script. You can configure the job with a command, environment variables, a timeout (up to 24 hours or more), and the number of parallel tasks, and the job exits with a success/failure exit code. Cloud Scheduler can trigger the job via Pub/Sub or a direct API call using IAM authentication, providing a serverless cron that runs each night without maintaining an HTTP server.

Why this answer

Cloud Run Jobs is the correct choice because it is designed for batch workloads that run to completion, with no requirement for an HTTP endpoint. It can handle long-running tasks (up to 24 hours) and can be triggered by Cloud Scheduler for nightly execution, making it ideal for processing files once per night.

Exam trap

Google Cloud often tests the distinction between Cloud Run Services (HTTP-driven, always-on) and Cloud Run Jobs (batch, run-to-completion), leading candidates to incorrectly choose Cloud Run Services for batch workloads due to familiarity with the 'Cloud Run' name.

How to eliminate wrong answers

Option A is wrong because Cloud Run Services are intended for HTTP-driven applications that must handle continuous requests; setting a 24-hour timeout is technically possible but misuses the service, as it is not designed for batch jobs that exit. Option C is wrong because Cloud Functions has a maximum timeout of 540 seconds (9 minutes), which is insufficient for a batch job that may run for hours processing files nightly. Option D is wrong because App Engine Standard with a background service is not designed for short-lived batch tasks; it is meant for long-running background processes within a web application, and it lacks native scheduling integration for one-off nightly jobs.

Full explanation →

349

MCQmedium

An engineering team is deciding between App Engine Standard and App Engine Flexible for a Python API. The API has unpredictable traffic, must scale to zero when idle, runs standard Python code with no custom system packages, and requires < 1 second startup time. Which environment is most suitable?

A.App Engine Flexible — it supports Python with custom packages

B.App Engine Standard — it scales to zero, starts in sub-second, and supports standard Python runtimes

C.Both are equivalent — the difference is only in supported languages

D.Neither — use Cloud Run instead for Python APIs

AnswerB

App Engine Standard is the correct choice because it runs on a fully managed, sandboxed PaaS that automatically scales to zero instances when idle, eliminating compute cost between requests. Its stateless runtime instances start in under a second even from cold, which is critical for latency-sensitive or sporadically used APIs. The API's requirement of standard Python runtimes fits Standard's supported runtimes exactly, and the absence of any need for custom system packages sidesteps Standard's primary limitation.

Why this answer

App Engine Standard is the correct choice because it automatically scales to zero instances during idle periods, starts new instances in under a second, and supports standard Python runtimes without custom system packages. The requirement for sub-second startup time and scaling to zero aligns perfectly with Standard's sandboxed, pre-loaded runtime environment, whereas Flexible environment has slower startup times due to VM provisioning and cannot scale to zero.

Exam trap

Google Cloud often tests the misconception that App Engine Flexible is more capable because it supports custom runtimes, leading candidates to overlook the critical requirements of scaling to zero and sub-second startup that only Standard satisfies.

How to eliminate wrong answers

Option A is wrong because App Engine Flexible does not scale to zero instances (it maintains at least one VM) and has startup times of several minutes, failing the <1 second requirement; custom packages are irrelevant since the API uses standard Python code. Option C is wrong because the environments differ significantly in scaling behavior, startup latency, and sandboxing — they are not equivalent. Option D is wrong because Cloud Run can scale to zero and start quickly, but App Engine Standard is equally suitable and is a first-class option for this use case; the question asks which environment is most suitable, and Standard directly meets all criteria without requiring a different service.

Full explanation →

350

MCQmedium

An engineer needs to enable the Compute Engine API for a project using the CLI. Which command should they run?

A.gcloud compute enable

B.gcloud services enable compute

C.gcloud api enable compute.googleapis.com

D.gcloud services enable compute.googleapis.com

AnswerD

'gcloud services enable compute.googleapis.com' is the correct command to enable the Compute Engine API for the active project. The 'gcloud services' command group interacts with the Service Usage API to manage service availability. This command uses the fully qualified service name 'compute.googleapis.com', which is required for successful enablement. You can also specify a project with the '--project' flag if the API should be enabled for a different project than the current one.

Why this answer

The correct command to enable a Google Cloud API for a project using the CLI is 'gcloud services enable compute.googleapis.com'. This command uses the 'gcloud services' command group, which manages API enablement, and requires the full service name (e.g., compute.googleapis.com). This is the standard and documented way to enable APIs.

Exam trap

ACE often tests the exact syntax of gcloud commands, and candidates may forget the '.googleapis.com' suffix or confuse 'gcloud services' with 'gcloud compute' or 'gcloud api'.

How to eliminate wrong answers

Option A is wrong because 'gcloud compute enable' is not a valid command; 'gcloud compute' manages Compute Engine resources, not API enablement. Option B is wrong because 'gcloud services enable compute' is missing the domain suffix '.googleapis.com', which is required to identify the service. Option C is wrong because 'gcloud api enable' is not a valid command group; the correct group is 'gcloud services'.

Full explanation →

351

MCQmedium

You notice that your Cloud SQL for PostgreSQL instance's `pg_stat_activity` shows many connections in `idle in transaction` state, and the connection count is near the max_connections limit. Application threads are blocking waiting for connections. What is the most effective solution to manage database connections for a GKE-hosted application?

A.Increase `max_connections` in the Cloud SQL PostgreSQL instance flags.

B.Deploy PgBouncer as a sidecar or deployment to pool connections to Cloud SQL in transaction mode.

C.Switch from Cloud SQL to Cloud Spanner, which has no connection limits.

D.Restart the Cloud SQL instance to clear idle connections.

AnswerB

PgBouncer in transaction mode multiplexes many client connections onto few server connections, releasing the backend between transactions. This clears idle-in-transaction sessions and keeps Cloud SQL below max_connections, resolving the thread blocking that a larger connection limit would not fix.

Why this answer

PgBouncer is a lightweight connection pooler that can be deployed as a sidecar or separate deployment in GKE to manage connections to Cloud SQL for PostgreSQL. By operating in transaction mode, it holds database connections only for the duration of a transaction, not for the entire client session, which drastically reduces the number of concurrent connections to the database. This directly addresses the `idle in transaction` connections and the near-max_connections issue without requiring application code changes.

Exam trap

Google Cloud often tests the misconception that simply increasing `max_connections` is a safe scaling solution, when in fact it can lead to resource exhaustion and does not address the underlying idle connection problem.

How to eliminate wrong answers

Option A is wrong because increasing `max_connections` only raises the hard limit without solving the root cause of idle connections; it can also degrade database performance due to increased context switching and memory overhead. Option C is wrong because Cloud Spanner is a globally distributed, horizontally scalable database with a different API and consistency model, not a drop-in replacement for PostgreSQL, and it still has connection limits (though higher). Option D is wrong because restarting the instance is a disruptive, temporary fix that kills all connections but does not prevent idle connections from reaccumulating, and it causes downtime for the application.

Full explanation →

352

MCQhard

A company runs a batch job on Compute Engine that processes large files from Cloud Storage. The job is taking longer than expected. The instances are using standard persistent disks. Which change would most likely improve I/O performance?

A.Use regional persistent disks instead of zonal.

B.Increase the machine type to have more vCPUs.

C.Add local SSDs to the instances.

D.Replace standard persistent disks with SSD persistent disks.

AnswerD

SSD persistent disks are built on flash-based media and deliver substantially higher IOPS, throughput, and lower latency than standard persistent disks, directly addressing an I/O-bound workload. Unlike local SSDs, they remain durable across instance lifecycle events and maintain the same persistent disk management model. Replacing standard persistent disks with SSD persistent disks is the appropriate change to remove the storage bottleneck while retaining data durability.

Why this answer

Standard persistent disks (pd-standard) are backed by HDDs and have lower IOPS and throughput compared to SSD persistent disks (pd-ssd). Since the batch job processes large files from Cloud Storage, the bottleneck is likely disk I/O performance. Upgrading to SSD persistent disks provides higher IOPS and throughput, directly improving I/O performance for read/write operations.

Exam trap

Google Cloud often tests the distinction between persistent disk types (standard vs. SSD) versus disk replication options (zonal vs. regional), leading candidates to mistakenly choose regional disks for performance instead of durability.

How to eliminate wrong answers

Option A is wrong because regional persistent disks provide synchronous replication across two zones for durability, not higher I/O performance; they have the same performance characteristics as zonal persistent disks. Option B is wrong because increasing vCPUs does not improve disk I/O performance; the bottleneck is the disk subsystem, not CPU capacity. Option C is wrong because local SSDs provide high IOPS but are ephemeral and cannot be used for persistent data; the job processes files from Cloud Storage, which requires persistent storage for the batch job's working data.

Full explanation →

353

MCQmedium

You have a Kubernetes Deployment running 5 replicas. You need to update the container image with zero downtime, ensuring that at least 4 replicas are always available during the update, and no more than 6 replicas exist at any time. Which Deployment strategy and settings achieve this?

A.Recreate strategy with `minReadySeconds: 30`.

B.RollingUpdate with `maxUnavailable: 1` and `maxSurge: 1`.

C.RollingUpdate with `maxUnavailable: 0` and `maxSurge: 2`.

D.RollingUpdate with `maxUnavailable: 2` and `maxSurge: 1`.

AnswerB

With maxUnavailable=1 the Deployment is allowed to take down at most one pod at a time, so at least 5 - 1 = 4 pods remain available throughout the update. With maxSurge=1 the Deployment may create at most one extra pod above the desired count, capping total simultaneous pods at 5 + 1 = 6. These two parameters exactly satisfy both the minimum-4 available and maximum-6 total constraints while keeping the rollout incremental and service available.

Why this answer

A RollingUpdate strategy with `maxUnavailable: 1` and `maxSurge: 1` ensures that during the update, at most one replica is taken down (so at least 4 remain available) and at most one extra replica is created above the desired 5 (so no more than 6 exist at any time). This satisfies both constraints while achieving zero downtime.

Exam trap

Google Cloud often tests the interaction between `maxSurge` and `maxUnavailable` by presenting values that seem reasonable but violate the given constraints, and the trap here is assuming that a higher surge or higher unavailable count is safe without calculating the resulting minimum available and maximum total replicas.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime and violating the requirement of at least 4 replicas always available. Option C is wrong because `maxSurge: 2` allows up to 7 replicas (5 desired + 2 surge), exceeding the limit of 6 replicas at any time. Option D is wrong because `maxUnavailable: 2` allows up to 2 replicas to be unavailable, which could drop the available count to 3, violating the requirement of at least 4 replicas always available.

Full explanation →

354

MCQeasy

Which kubectl command is used to view the logs of a specific pod named 'my-pod'?

A.kubectl logs my-pod

B.kubectl exec my-pod -- logs

C.kubectl get pod my-pod

D.kubectl describe pod my-pod

AnswerA

The `kubectl logs my-pod` command retrieves the logs of the primary container running inside the specified pod by reading the container's stdout/stderr streams. This is the direct, native Kubernetes approach for accessing application log output, and if the pod has multiple containers, you must append `-c <container>` to select a specific one. It does not require shell access or any extra tooling, making it the correct command for viewing logs.

Why this answer

The 'kubectl logs' command streams logs from a pod. 'kubectl describe' shows metadata, 'kubectl get' shows status, and 'kubectl exec' runs commands inside the pod.

Full explanation →

355

MCQmedium

You need to monitor a Cloud Run service for errors and receive a PagerDuty notification when the number of 5xx errors exceeds 10 in any 5-minute window. Which Cloud Monitoring feature should you use?

A.Create a log-based metric on Cloud Run error logs, then create an alerting policy on that metric with a PagerDuty notification channel.

B.Configure Cloud Run to send error emails directly to the PagerDuty email integration.

C.Use Cloud Pub/Sub to stream Cloud Run logs to a custom application that pages PagerDuty.

D.Enable Cloud Run's built-in alerting feature in the service configuration.

AnswerA

This is the correct pattern: first, create a log-based metric in Cloud Logging that counts Cloud Run errors, for example by filtering on status codes >= 500 or severity ERROR. Then, define a Cloud Monitoring alerting policy that watches that metric and triggers when the error count crosses a threshold. Finally, attach a PagerDuty notification channel to the policy so an incident is created automatically. This approach uses fully managed services and requires no custom application code.

Why this answer

A log-based metric extracts a numeric counter from Cloud Run error logs (e.g., HTTP 5xx status codes). An alerting policy can then evaluate that metric over a sliding 5-minute window, triggering a PagerDuty notification via a configured notification channel when the count exceeds 10. This is the native, serverless approach that requires no additional infrastructure.

Exam trap

Google Cloud often tests the misconception that Cloud Run has built-in alerting or that direct email integration is sufficient, when in fact Cloud Monitoring's log-based metrics and alerting policies are the required mechanism for threshold-based paging.

How to eliminate wrong answers

Option B is wrong because Cloud Run does not have a built-in feature to send error emails directly to a PagerDuty email integration; it would require custom log routing and filtering. Option C is wrong because using Cloud Pub/Sub and a custom application adds unnecessary complexity and latency compared to the native Cloud Monitoring alerting pipeline. Option D is wrong because Cloud Run does not have a built-in alerting feature in its service configuration; alerting must be configured externally via Cloud Monitoring.

Full explanation →

356

MCQhard

An organization has a policy requiring all new GCP projects to be created within specific folders and linked to approved billing accounts only. Which combination of features enforces this at scale?

A.IAM deny policies on the organization + VPC Service Controls

B.Organization policies to restrict allowed billing accounts + granting Project Creator role only at approved folder level

C.Cloud Asset Inventory alerts + manual review of new projects

D.Requiring multi-factor authentication for all project creators

AnswerB

This is the correct preventive approach because the `billing.allowedBillingAccounts` organization policy (constraint: `constraints/billing.allowedBillingAccounts`) restricts the set of billing accounts that can be associated with a project, and it is evaluated at project creation time, not after the fact. Scoping the Project Creator role to only approved folders via IAM roles on those folders means a user can create a project only within those resource boundaries, because the permission to create a project is inherited down the hierarchy only from those folders. Together these controls ensure that any new project is created in an approved folder and must use an allowed billing account, preventing non-compliant project sprawl before it happens.

Why this answer

It combines two enforcement mechanisms: Organization policies (specifically the `constraints/compute.restrictBillingAccounts` constraint) to limit which billing accounts can be attached to projects, and granting the Project Creator role (`roles/resourcemanager.projectCreator`) only at the folder level (not the organization level). This ensures that new projects can only be created within the approved folders and must use an approved billing account, enforcing the policy at scale across the entire organization.

Exam trap

Google Cloud often tests the distinction between reactive monitoring (like Cloud Asset Inventory) and proactive enforcement (like Organization policies and IAM roles), leading candidates to choose a monitoring-based answer instead of the correct policy-based enforcement.

How to eliminate wrong answers

Option A is wrong because IAM deny policies are used to explicitly deny access to resources, not to restrict billing accounts or project creation locations; VPC Service Controls are designed to protect data in GCP services by controlling data exfiltration, not for enforcing project creation or billing constraints. Option C is wrong because Cloud Asset Inventory alerts and manual review are reactive, not proactive enforcement; they cannot prevent non-compliant projects from being created at scale. Option D is wrong because multi-factor authentication (MFA) is an identity security measure that does not restrict which billing accounts or folders can be used when creating projects.

Full explanation →

357

MCQeasy

A team wants logs from their Python application running on a Compute Engine VM to appear in Cloud Logging. What must be installed on the VM?

A.Cloud Trace SDK for the Python application

B.Ops Agent (Google Cloud's combined logging and monitoring agent)

C.Cloud Monitoring agent only

D.No installation needed — GCE VMs automatically stream logs to Cloud Logging

AnswerB

The Ops Agent is the correct solution because it is Google Cloud's unified agent for both logging and monitoring on Compute Engine. It can be configured to collect logs from system daemons, application log files, and custom pipelines, then forward them as structured log entries to Cloud Logging, while also ingesting metrics for Cloud Monitoring. It must be explicitly installed on the VM, but it is the supported, modern replacement for the separate legacy logging and monitoring agents.

Why this answer

The Ops Agent is Google Cloud's unified agent for both logging and monitoring, and it is required to stream custom application logs from a Compute Engine VM to Cloud Logging. While the VM itself sends basic platform logs (e.g., serial console output), application-level logs (e.g., from a Python app) require the Ops Agent to collect, parse, and forward them to the Cloud Logging API.

Exam trap

The trap here is that candidates assume GCE VMs automatically send all logs (including application logs) to Cloud Logging, but in reality only platform-level logs are auto-streamed, and application logs require the Ops Agent.

How to eliminate wrong answers

Option A is wrong because the Cloud Trace SDK is used for distributed tracing, not for collecting or forwarding application logs to Cloud Logging. Option C is wrong because the Cloud Monitoring agent only handles metrics for Cloud Monitoring, not logs for Cloud Logging; the Ops Agent replaces both the legacy logging and monitoring agents. Option D is wrong because GCE VMs do not automatically stream application logs; they only send basic platform logs (e.g., from the guest environment), and custom application logs require an agent like the Ops Agent to be installed and configured.

Full explanation →

358

MCQhard

Your organization uses Cloud Functions to process messages from a Pub/Sub topic. Each function processes a single message and writes results to BigQuery. Recently, the function has been timing out and the Pub/Sub subscription's unacknowledged message count is growing rapidly. The function's memory is set to 256 MB and timeout is 60 seconds. The function logs show occasional 'memory limit exceeded' errors. You suspect that the function is leaking memory when processing large messages. What should you do to resolve the issue while minimizing cost and complexity?

A.Increase the function's memory to 1 GB and timeout to 540 seconds.

B.Set up a retry policy on the Pub/Sub subscription to dead-letter undelivered messages.

C.Increase the function's timeout to 120 seconds and reduce the batch size.

D.Increase the function's memory to 512 MB and timeout to 120 seconds.

AnswerD

Allocating 512 MB gives the function enough headroom to handle the message payload without exhausting the default 256 MB limit, and extending the timeout to 120 seconds ensures slower processing steps aren't cut off. This directly addresses both the memory-termination error and the short timeout, while keeping costs significantly lower than the 1 GB option. It is a right-sized adjustment based on the observed failure pattern.

Why this answer

The function is timing out and running out of memory due to large messages. Increasing memory to 512 MB provides more headroom for processing, and raising the timeout to 120 seconds gives the function enough time to complete without unnecessary cost. This directly addresses the memory leak and timeout issues while keeping complexity low.

Exam trap

Google Cloud often tests the misconception that increasing timeout alone (Option C) or adding a dead-letter queue (Option B) solves memory-related failures, when in fact memory must be increased to prevent 'memory limit exceeded' errors.

How to eliminate wrong answers

Option A is wrong because increasing memory to 1 GB and timeout to 540 seconds is over-provisioned and unnecessarily increases cost without addressing the root cause of memory leaks; it also exceeds typical Cloud Functions limits for event-driven processing. Option B is wrong because a dead-letter queue only handles undelivered messages after retries, but does not fix the underlying memory leak or timeout; messages will still fail and accumulate. Option C is wrong because reducing batch size is irrelevant since each function processes a single message, and increasing timeout alone without addressing memory will still cause 'memory limit exceeded' errors.

Full explanation →

359

MCQmedium

You need to resize a Compute Engine instance from n1-standard-4 to n1-highmem-8. The instance has a local SSD attached. What must you do before changing the machine type?

A.Stop the instance, change the machine type, then start the instance

B.Take a snapshot of the local SSD

C.Change the machine type without stopping

D.Detach the local SSD

AnswerA

To change the machine type of a Compute Engine instance, you must first stop it, which brings it to the TERMINATED state. While stopped, the persistent disks and instance settings remain intact, but any data on local SSDs is permanently lost because local SSDs are ephemeral storage tied to the host server. After updating the machine type, you start the instance; this process is the only supported way to resize an instance's vCPU and memory.

Why this answer

To change the machine type, the instance must be stopped. Local SSDs preserve data only if the instance is not stopped or terminated; however, when you stop the instance, local SSD data is lost. The correct procedure is to stop the instance, change the machine type, and then start it.

Data on local SSDs will be lost.

Full explanation →

360

MCQeasy

Which feature of Cloud SQL provides automated backups and enables point-in-time recovery?

A.All Cloud SQL tiers

B.Only Cloud SQL Enterprise

C.Only Cloud SQL High Availability configuration

D.Only Cloud SQL Enterprise Plus

AnswerA

Automated backups and point-in-time recovery (PITR) via binary logging are foundational features of Cloud SQL, available on every edition: Enterprise, Enterprise Plus, and even the legacy basic tier. The backup infrastructure ingests daily snapshots and transaction logs regardless of the instance's tier, so no premium edition or add-on is required. Because these capabilities are guaranteed baseline functionality, the correct answer is that they apply to all Cloud SQL tiers.

Why this answer

Cloud SQL provides automated backups and point-in-time recovery (PITR) for all tiers, including Cloud SQL Enterprise, Enterprise Plus, and even the basic (non-HA) configurations. This is because the backup and PITR functionality is a core feature of the Cloud SQL service itself, not tied to a specific tier or high-availability setup. Automated backups are enabled by default, and PITR uses binary log (binlog) files to allow restoration to any point within the backup retention window.

Exam trap

Google Cloud often tests the misconception that advanced features like PITR or automated backups are reserved for higher-tier or HA configurations, when in fact they are available across all Cloud SQL tiers.

How to eliminate wrong answers

Option B is wrong because it incorrectly restricts automated backups and PITR to only the Enterprise tier, while these features are available across all Cloud SQL tiers, including the basic tier. Option C is wrong because it ties the feature to High Availability configuration, but HA only affects instance availability and failover, not backup or PITR capabilities. Option D is wrong because it limits the feature to Enterprise Plus, which is a higher-performance tier, but automated backups and PITR are not exclusive to that tier.

Full explanation →

361

Multi-Selectmedium

A company wants to set up a Cloud SQL for MySQL instance with automated backups and a read replica for disaster recovery. Which THREE features or configurations should be enabled?

Select 3 answers

A.Enable automated backups

B.Enable binary logging

C.Enable deletion protection on the primary instance

D.Configure the read replica in a different region

E.Assign a public IP address to the read replica

AnswersA, B, D

Automated backups in Cloud SQL are mandatory for point-in-time recovery (PITR) and for creating read replicas. Without them, you cannot perform a restore to a specific timestamp, and you lose the baseline backup needed for replica creation. They also provide a daily recovery point that protects against data loss or corruption.

Why this answer

Automated backups are enabled by default but must be configured. A read replica requires the binary log to be enabled on the primary. The backup location can be set to multi-regional for DR.

Cross-region replication requires a replica in another region. Point-in-time recovery uses binary logs.

Full explanation →

362

MCQhard

A team is using Terraform to manage GCP infrastructure. They want to store the state file in a Cloud Storage bucket with versioning enabled. Which backend configuration is correct?

A.provider "google" { backend "gcs" { bucket = "my-bucket" } }

B.terraform { backend "gcs" { bucket = "my-bucket" prefix = "terraform/state" } }

C.terraform { backend "gcs" { bucket = "my-bucket" versioning = true } }

D.terraform { backend "cloud-storage" { bucket = "my-bucket" } }

AnswerB

This is the correct configuration because it uses the required `terraform` block with a `backend "gcs"` block, and includes both the `bucket` name (where the state file is stored) and a `prefix` (the object path within the bucket). The backend type is exactly `"gcs"`, and this syntax registers Google Cloud Storage as the remote state backend, enabling shared state and locking across the team.

Why this answer

To use Cloud Storage as a backend, you must specify 'bucket' and optionally 'prefix' for the state file path. The provider block is for the Google provider, not state storage.

Full explanation →

363

MCQmedium

An engineer needs to create a firewall rule that allows incoming HTTPS traffic only from a specific IP range to instances tagged 'web-server'. Which command should they use?

A.gcloud compute firewall-rules create allow-https --allow tcp:443 --source-ranges 192.168.0.0/16 --target-tags web-server

B.gcloud compute firewall-rules create allow-https --allow tcp:443 --source-tags web-server

C.gcloud compute firewall-rules create allow-https --allow udp:443 --source-ranges 192.168.0.0/16 --target-tags web-server

D.gcloud compute firewall-rules create allow-https --allow tcp:443 --source-ranges 0.0.0.0/0 --target-tags web-server

AnswerA

This rule is correct because it explicitly restricts inbound HTTPS (TCP port 443) to source IPs within the RFC 1918 private range 192.168.0.0/16 and applies only to VM instances bearing the network tag 'web-server'. The combination of --source-ranges with a CIDR and --target-tags ensures the rule targets exactly the intended web servers and only allows traffic from the specified internal subnet, satisfying the requirement.

Why this answer

The correct command uses --allow tcp:443 to permit HTTPS, --source-ranges 192.168.0.0/16 to restrict the source IP range, and --target-tags web-server to apply the rule only to instances tagged 'web-server'. This matches all three requirements: protocol/port, source restriction, and target selection. The gcloud compute firewall-rules create syntax requires --allow with protocol:port and uses --target-tags (not --source-tags) to select destination instances.

Exam trap

ACE often tests the confusion between --source-tags (source instances) and --target-tags (destination instances), and between TCP and UDP for HTTPS, causing candidates to pick a rule that allows the wrong traffic.

How to eliminate wrong answers

Option B is wrong because --source-tags filters by the tags of the source instances, not the destination, and it omits the required --source-ranges for the specific IP range; it also does not target the web-server instances correctly. Option C is wrong because it specifies udp:443, but HTTPS uses TCP port 443 — UDP 443 is used by HTTP/3 (QUIC), not standard HTTPS, so this would not allow the intended traffic. Option D is wrong because --source-ranges 0.0.0.0/0 allows HTTPS from any source on the internet, violating the requirement to restrict to a specific IP range.

Full explanation →

364

MCQeasy

You need to monitor the CPU utilization across all instances in a managed instance group. What is the most efficient way to create an alerting policy?

A.Create an alerting policy using the Logs Explorer to parse instance logs.

B.Use Cloud Scheduler to call the monitoring API periodically.

C.Set up a cron job to run gcloud compute instances list and check CPU.

D.Create an alerting policy in Cloud Monitoring for the metric 'compute.googleapis.com/instance/cpu/utilization'.

AnswerD

Cloud Monitoring automatically collects `compute.googleapis.com/instance/cpu/utilization` from every Compute Engine VM without requiring an agent, storing it as a time-series metric. You can create an alerting policy with a threshold condition, setting an aggregation (e.g., mean value across instances) and a duration (e.g., 5 minutes) to reduce noise, and attach notification channels like email or Pub/Sub. This is the native, managed, and real-time mechanism for CPU monitoring, and it integrates directly with the rest of Cloud Monitoring, including dashboards and incident escalation.

Why this answer

Cloud Monitoring provides a pre-built metric, 'compute.googleapis.com/instance/cpu/utilization', which directly measures CPU usage for VM instances. Creating an alerting policy based on this metric is the most efficient approach, as it requires no custom scripting or external scheduling, and integrates natively with managed instance groups to aggregate data across all instances.

Exam trap

Google Cloud often tests the distinction between logs and metrics, and the trap here is that candidates may confuse log-based analysis (Option A) with metric-based alerting, or assume that custom scripting (Options B and C) is necessary when a native monitoring service already provides the required functionality.

How to eliminate wrong answers

Option A is wrong because the Logs Explorer parses log entries, not real-time metrics; CPU utilization is a metric, not a log event, and parsing logs for CPU data would be inefficient and miss real-time thresholds. Option B is wrong because Cloud Scheduler calling the Monitoring API periodically introduces latency and complexity, and is not the recommended method for continuous metric-based alerting; alerting policies are designed to evaluate metrics automatically. Option C is wrong because a cron job running 'gcloud compute instances list' only retrieves instance metadata, not CPU utilization metrics, and would require additional commands and scripting to fetch and analyze monitoring data, making it inefficient and non-native.

Full explanation →

365

MCQeasy

An engineer wants to create a Google-managed SSL certificate for a domain and attach it to an HTTPS load balancer. Which gcloud command should they use to create the certificate?

A.gcloud compute target-https-proxies create --ssl-certificates

B.gcloud compute ssl-certificates create --domains example.com

C.gcloud compute ssl-policies create

D.gcloud compute ssl-certificates create --certificate example.crt --private-key example.key

AnswerB

The `gcloud compute ssl-certificates create` command with the `--domains` flag provisions a Google-managed SSL certificate, which satisfies the stem’s requirement for a Google-managed certificate rather than a self-managed one. This command triggers Google’s Certificate Authority to automatically handle domain validation and renewal for `example.com`, eliminating the need for manual certificate uploads. It directly attaches to the HTTPS load balancer’s target proxy, meeting the load-balancer constraint.

Why this answer

The gcloud command 'gcloud compute ssl-certificates create --domains example.com' creates a Google-managed SSL certificate, which is automatically provisioned and renewed by Google Cloud. The --domains flag specifies the domain names for which the certificate should be issued, and Google handles the certificate lifecycle without requiring the user to provide a private key or certificate file. This is the correct command for creating a Google-managed certificate to attach to an HTTPS load balancer.

Exam trap

ACE often tests the distinction between creating a certificate versus attaching it to a proxy, and between Google-managed versus self-managed certificates — candidates frequently select the command that uploads a certificate file when the question asks for a Google-managed certificate.

How to eliminate wrong answers

Option A is wrong because 'gcloud compute target-https-proxies create --ssl-certificates' creates or updates the HTTPS target proxy and attaches an existing certificate to it — it does not create the certificate itself. Option C is wrong because 'gcloud compute ssl-policies create' creates an SSL policy that defines TLS versions and cipher suites, not an SSL certificate. Option D is wrong because 'gcloud compute ssl-certificates create --certificate example.crt --private-key example.key' creates a self-managed SSL certificate by uploading a certificate and private key, which is the opposite of a Google-managed certificate.

Full explanation →

366

MCQmedium

A team wants to roll back a GKE Deployment to its previous revision because the new version introduced a regression. Which kubectl command performs this rollback?

A.kubectl revert deployment/my-app --to-previous

B.kubectl rollout undo deployment/my-app

C.kubectl apply -f previous-deployment.yaml

D.kubectl delete deployment/my-app && kubectl create -f deployment.yaml

AnswerB

`kubectl rollout undo deployment/my-app` is the built-in rollback mechanism. It instructs the Deployment controller to revert the pod template to the spec from the previous ReplicaSet revision, scaling up the old ReplicaSet and scaling down the new one. This preserves the Deployment's revision history, so you can undo again or jump to a specific revision with `--to-revision`. It is the correct, declarative way to return to a stable version without recreating the Deployment object or disrupting its managed state.

Why this answer

`kubectl rollout undo deployment/my-app` is the standard Kubernetes command to roll back a Deployment to the previous revision. This command leverages the Deployment's revision history, which is automatically maintained by the Kubernetes controller, to revert the desired state to the prior revision without needing to manually reapply an old manifest.

Exam trap

Google Cloud often tests the distinction between `rollout undo` and non-existent commands like `revert`, or the misconception that reapplying an old YAML file is equivalent to a proper rollback, when in fact it bypasses the Deployment's revision history and can cause version mismatches.

How to eliminate wrong answers

Option A is wrong because `kubectl revert` is not a valid kubectl command; the correct verb is `rollout undo`, not `revert`. Option C is wrong because `kubectl apply -f previous-deployment.yaml` would reapply an old manifest file, but it does not perform a rollback to the previous revision tracked by the Deployment's history; it simply applies whatever YAML is provided, which may not match the exact previous revision and could introduce configuration drift. Option D is wrong because deleting and recreating the Deployment from a YAML file is a manual, error-prone process that bypasses the built-in revision history and does not guarantee a clean rollback to the exact previous revision; it also causes unnecessary downtime and does not leverage the Deployment's automatic revision tracking.

Full explanation →

367

MCQhard

An application is experiencing intermittent high latency. Using Cloud Trace, an engineer identifies that the bottleneck is a Pub/Sub subscription with a large backlog. Which action would MOST directly help reduce the backlog?

A.Increase the ack deadline

B.Increase the maximum message size

C.Increase the message retention duration

D.Increase the number of subscribers

AnswerD

Increasing the number of subscribers (i.e., scaling out the subscriber fleet) directly raises the aggregate processing throughput of the subscription. Because the intermittent high latency is likely due to a backlog of messages accumulating faster than the current subscribers can drain, adding more subscribers allows messages to be pulled and processed in parallel, reducing the queue depth and lowering end-to-end latency. This is the correct scaling action for a latency problem caused by insufficient compute, assuming the subscribers are stateless and can process messages independently.

Why this answer

Increasing the number of subscribers (e.g., scaling out the subscriber application) will increase the processing rate and reduce backlog. Increasing the retention duration keeps messages longer, not reducing backlog. The ack deadline and message size are not the primary causes of backlog.

Full explanation →

368

MCQeasy

Your organization has multiple Google Cloud projects. You want to separate development and production environments. Which resource hierarchy structure is recommended?

A.Create two separate organizations.

B.Use labels on projects to differentiate environments.

C.Use a single project with separate VPC networks.

D.Use folders under the organization node to separate dev and prod projects.

AnswerD

Folders sit beneath the organisation node and group projects, letting you apply separate IAM policies and billing to dev and prod. This isolates environments while retaining centralised organisation-level control, which placing projects directly under the organisation or in separate organisations would not achieve as cleanly.

Why this answer

Using folders under the organization node to separate dev and prod projects is the recommended approach because it aligns with Google Cloud's resource hierarchy, allowing centralized policy management and inheritance. Folders enable logical separation of environments while maintaining a single organization, which simplifies billing and IAM. This structure supports least privilege and environment isolation.

Exam trap

ACE often tests the misconception that labels or separate VPCs provide sufficient environment separation, when the correct answer is using folders for hierarchical policy inheritance.

How to eliminate wrong answers

Option A is wrong because creating two separate organizations is not recommended; it complicates management and billing, and is typically not feasible for a single company. Option B is wrong because labels are for metadata and cannot enforce separation or policy inheritance like folders. Option C is wrong because using a single project with separate VPC networks does not provide sufficient isolation for dev and prod environments, as projects are the primary boundary for resources and IAM.

Full explanation →

369

MCQhard

A security team wants to ensure that a service account created for an application cannot create new service accounts or modify IAM policies within the project. Which IAM role restriction achieves this?

A.Grant the service account only the specific roles its application requires — omitting IAM admin roles

B.Create an IAM deny policy blocking iam.serviceAccounts.create and iam.projects.setIamPolicy for the service account

C.Set an organization policy constraint restricting service account creation to admin users only

D.Disable the IAM API for the project so service accounts cannot manage IAM

AnswerA

Granting only the specific roles the application requires enforces least privilege, so the service account lacks permissions to create service accounts or modify IAM policies. Omitting IAM admin roles directly satisfies the restriction, whereas broader predefined roles would still permit those privileged actions.

Why this answer

The principle of least privilege dictates that a service account should only be granted the specific roles required for its application's functionality. By deliberately omitting roles that include IAM administrative permissions (such as roles/iam.serviceAccountAdmin or roles/iam.serviceAccountUser with the iam.serviceAccounts.create permission, or roles/resourcemanager.projectIamAdmin), the service account is inherently restricted from creating new service accounts or modifying IAM policies. This approach avoids the complexity of deny policies and aligns with Google Cloud's recommended IAM best practices.

Exam trap

Google Cloud often tests the principle of least privilege by presenting complex alternatives like deny policies or organization constraints, but the simplest and most correct answer is to grant only the necessary roles, which inherently prevents unauthorized IAM administration.

How to eliminate wrong answers

Option B is wrong because IAM deny policies are a valid mechanism but they are not the most straightforward or recommended restriction for this scenario; they require careful management and can be circumvented if not applied at the correct hierarchy level, and the question asks for a restriction that 'achieves' the goal, implying a simpler, built-in approach. Option C is wrong because organization policy constraints (e.g., constraints/iam.disableServiceAccountCreation) apply to all principals in the organization, not specifically to a single service account, and they do not prevent the service account from modifying IAM policies. Option D is wrong because disabling the IAM API for the project would break all IAM operations, including those required by the application itself, making the service account and the application non-functional.

Full explanation →

370

MCQmedium

Your team needs to manage Google Kubernetes Engine clusters across multiple projects. Rather than granting `roles/container.admin` on each project individually, you want a centralized approach. What is the most maintainable solution?

A.Create a service account with `roles/container.admin` and share its key JSON with team members.

B.Grant `roles/container.admin` to the team's Google Group at the folder level containing all relevant projects.

C.Grant `roles/container.admin` to each team member individually in each project's IAM policy.

D.Use the GKE Hub to create a fleet and assign RBAC roles within each cluster.

AnswerB

Granting `roles/container.admin` to a Google Group at the folder level lets every current and future project beneath that folder inherit the role, satisfying the centralised, maintainable requirement. Adding or removing members changes access everywhere at once, avoiding per-project IAM bindings.

Why this answer

Granting `roles/container.admin` at the folder level to a Google Group is the most maintainable solution because it centralizes IAM policy management. When new projects are added under that folder, they automatically inherit the role, and team membership changes are handled by updating the Google Group rather than modifying individual project IAM policies. This approach follows Google Cloud's recommended practice of using groups and resource hierarchy for scalable access control.

Exam trap

The trap here is that candidates confuse Kubernetes RBAC (which controls access within a cluster) with Google Cloud IAM (which controls access to the GKE API and cluster management), leading them to choose fleet-based RBAC solutions that do not address the centralized IAM requirement.

How to eliminate wrong answers

Option A is wrong because sharing a service account key JSON with team members violates security best practices, creates a long-lived credential that cannot be easily revoked per user, and bypasses audit logging tied to individual identities. Option C is wrong because granting `roles/container.admin` to each team member individually in each project's IAM policy is not scalable, creates significant administrative overhead, and violates the principle of least privilege by requiring per-project updates for any team change. Option D is wrong because GKE Hub fleets manage multi-cluster features like service discovery and policy propagation, but they do not replace IAM roles at the project or folder level; RBAC roles within clusters control Kubernetes-level permissions, not GCP-level access to the GKE API or cluster management.

Full explanation →

371

MCQeasy

A developer needs to test a Cloud Run service locally before deploying it to GCP. The service is packaged as a Docker container. Which tool allows them to run and test the container locally in a way that closely mimics the Cloud Run execution environment?

A.Run the container using `docker run -p 8080:8080 IMAGE` with the required environment variables.

B.Deploy the service to a staging Cloud Run environment using `gcloud run deploy --no-traffic`.

C.Use `gcloud run services describe` to simulate a local run.

D.Use Cloud Shell to run the container since Cloud Shell has Docker installed.

AnswerA

`docker run` with the `-p 8080:8080` flag binds the host port to the container's port 8080, which matches Cloud Run's default expected `$PORT` value and lets the service be exercised via `localhost:8080`. Supplying the same environment variables the Cloud Run service will receive replicates its runtime configuration, so the local container behaves like the deployed revision, enabling accurate functional and integration testing before deployment.

Why this answer

`docker run -p 8080:8080 IMAGE` with the required environment variables directly runs the containerized Cloud Run service on your local machine, mapping port 8080 to the container's port 8080 (the default Cloud Run listens on). This approach closely mimics the Cloud Run execution environment because Cloud Run also runs containers in a Docker-like runtime, and you can replicate environment variables, memory limits, and concurrency settings locally for accurate testing before deployment.

Exam trap

The trap here is that candidates assume any `gcloud` command or Cloud Shell can simulate a local runtime, but the ACE exam tests the distinction between local container execution (Docker) and cloud deployment commands, where only `docker run` with proper port mapping and environment variables provides a local test that closely mimics the Cloud Run execution environment.

How to eliminate wrong answers

Option B is wrong because deploying to a staging Cloud Run environment using `gcloud run deploy --no-traffic` does not test the service locally; it deploys the container to GCP, which requires network connectivity and incurs costs, and the `--no-traffic` flag only prevents routing requests to the new revision, not enabling local testing. Option C is wrong because `gcloud run services describe` is a read-only command that retrieves metadata about an existing Cloud Run service (e.g., URL, revision details) and cannot simulate or execute a local run of the container. Option D is wrong because Cloud Shell, while having Docker installed, runs in a remote, resource-constrained environment that does not replicate the Cloud Run execution environment (e.g., it lacks the same sandboxing, request handling, and scaling behavior), and it is not intended for local testing of containerized services.

Full explanation →

372

MCQeasy

A team wants to receive an email alert when the average CPU utilization of VMs in a managed instance group exceeds 80% for more than 5 minutes. What should they create in Cloud Monitoring?

A.A dashboard with a CPU utilization chart

B.An alerting policy with a CPU utilization threshold condition

C.A log-based metric filter for high-CPU events

D.An uptime check targeting the managed instance group

AnswerB

An alerting policy with a CPU utilization threshold condition is the correct choice because it continuously evaluates the compute.googleapis.com/instance/cpu/utilization metric against the threshold you set. Once the metric exceeds the threshold for the specified duration (e.g., 5 minutes), the policy triggers a notification through the configured channel (email, SMS, webhook, etc.). This provides the real-time proactive notification that dashboards, log-based metrics, and uptime checks cannot.

Why this answer

B is correct because Cloud Monitoring alerting policies allow you to define conditions based on metric thresholds, such as average CPU utilization exceeding 80% for a specified duration (5 minutes). This directly meets the requirement to trigger an email alert when the condition is met.

Exam trap

Google Cloud often tests the distinction between alerting policies (which trigger notifications) and dashboards (which only display data), so candidates mistakenly choose a dashboard thinking it can send alerts.

How to eliminate wrong answers

Option A is wrong because a dashboard with a CPU utilization chart only visualizes data; it does not send alerts. Option C is wrong because log-based metric filters are used to extract metrics from log entries (e.g., custom application logs), not to monitor VM CPU utilization metrics which are already collected by Cloud Monitoring. Option D is wrong because uptime checks monitor the availability and response of HTTP/HTTPS services, not CPU utilization of VMs.

Full explanation →

373

MCQmedium

A team enables OS Login on their GKE node pool. What does OS Login provide for SSH access to GKE nodes compared to the default metadata-based SSH key approach?

A.OS Login stores SSH keys in a Cloud KMS-managed keystore for enhanced encryption

B.OS Login links SSH access to IAM roles — access is centrally managed and revocable via IAM without updating VM metadata

C.OS Login automatically generates and rotates SSH key pairs every 24 hours

D.OS Login restricts SSH access to connections from specific IP ranges defined in Cloud Armor

AnswerB

OS Login links SSH access to IAM roles like `roles/compute.osLogin` or `roles/compute.osAdminLogin`. When a user is granted one of these roles, they can SSH into instances using their own identity, and revoking that role immediately removes access across all VMs without requiring metadata edits or key cleanup. This centralizes access management, simplifies revocation, and improves auditability compared to storing keys per instance.

Why this answer

OS Login links SSH access to IAM roles, so access is centrally managed and revocable via IAM without updating VM metadata. This means you can grant or revoke SSH access to GKE nodes by assigning or removing IAM roles (e.g., roles/compute.osLogin) on user or service accounts, eliminating the need to manage SSH keys in instance metadata. This provides a more secure and auditable access control mechanism compared to the default metadata-based SSH key approach.

Exam trap

The trap here is that candidates often confuse OS Login with SSH key management in metadata, thinking it still requires manual key distribution, when in fact it delegates authentication entirely to IAM, making access fully revocable and auditable without metadata updates.

How to eliminate wrong answers

Option A is wrong because OS Login does not store SSH keys in a Cloud KMS-managed keystore; instead, it uses IAM-based authentication and generates temporary SSH keys that are not stored in KMS. Option C is wrong because OS Login does not automatically generate and rotate SSH key pairs every 24 hours; it generates a temporary key per session that is valid only for the duration of the SSH connection. Option D is wrong because OS Login does not restrict SSH access based on IP ranges defined in Cloud Armor; IP-based restrictions are handled separately via VPC firewall rules or Cloud Armor policies, not by OS Login.

Full explanation →

374

MCQeasy

A startup is planning its first Google Cloud deployment for a stateless containerized API. The team has no Kubernetes experience and wants to minimize operational overhead while paying only for resources used during requests. The API must scale automatically, including down to zero when there is no traffic. Which Google Cloud service should they choose?

A.App Engine flexible environment

B.Compute Engine managed instance group with autoscaling

C.Google Kubernetes Engine Autopilot

D.Cloud Run

AnswerD

Cloud Run runs stateless containers in a fully managed serverless environment, scales automatically based on requests, and can scale to zero instances when idle so no cost accrues. It requires no Kubernetes knowledge and bills per request and resource usage, directly matching the startup's operational and cost constraints.

Why this answer

Cloud Run is the serverless container platform that scales to zero and bills only for request handling and resources consumed, with no cluster or VM management. It fits a stateless API that has idle periods and a team without Kubernetes skills, satisfying both the operational and cost requirements.

Exam trap

The trap here is equating reduced node management in GKE Autopilot with full serverless scale-to-zero, when Autopilot still requires a running cluster with baseline cost.

Full explanation →

375

Multi-Selectmedium

An administrator needs to create a custom IAM role that allows listing projects and viewing billing accounts. Which TWO permissions should be included?

Select 2 answers

A.billing.accounts.list

B.billing.accounts.create

C.resourcemanager.projects.create

D.resourcemanager.projects.list

E.resourcemanager.projects.delete

AnswersA, D

Correct. The billing.accounts.list permission is the specific IAM permission that allows a principal to enumerate the billing accounts they can access. Including this permission in the custom role is essential and sufficient for the read-only task of listing billing accounts; without it, any API call or console view that attempts to list billing accounts will fail with a permission denied error.

Why this answer

Option A, billing.accounts.list, is correct because viewing billing accounts requires the Cloud Billing permission billing.accounts.list, which allows the role to enumerate the billing accounts the principal has access to. Option D, resourcemanager.projects.list, is correct because listing projects is governed by the Resource Manager permission resourcemanager.projects.list, which permits reading the set of projects visible to the caller. Option B, billing.accounts.create, is not needed since the task only requires viewing, not creating, billing accounts.

Option C, resourcemanager.projects.create, and Option E, resourcemanager.projects.delete, are also unnecessary because creating or deleting projects is outside the stated scope of listing projects and viewing billing accounts.

Exam trap

ACE often tests least-privilege permission selection — the trap is including create or delete permissions because they share the same resource prefix (billing.accounts.* or resourcemanager.projects.*), when only the .list verb matches the stated read-only requirement.

Full explanation →

Google Associate Cloud Engineer (ACE) — Questions 301–375