Google Associate Cloud Engineer ACE Questions 376–450 | Page 6/7

376

MCQmedium

You need to transfer 50 TB of data from an AWS S3 bucket to Cloud Storage. The data must be transferred within 48 hours, and the network bandwidth between AWS and GCP is limited to 1 Gbps. Which GCP service manages this transfer efficiently?

A.Use `gsutil -m cp` from a Compute Engine VM in the same region as the destination bucket.

B.Use Storage Transfer Service to set up an S3-to-GCS transfer job.

C.Download from S3 and re-upload to GCS using a local machine with high bandwidth.

D.Use BigQuery Data Transfer Service to move S3 data to GCS.

AnswerB

Storage Transfer Service natively supports AWS S3 as a source. It manages parallelism, retries, filtering, and scheduling for large cross-cloud transfers — purpose-built for this use case.

Why this answer

Storage Transfer Service is the correct choice because it is a managed service designed specifically for moving large datasets from external cloud providers (like AWS S3) to Google Cloud Storage. It handles the transfer asynchronously, can parallelize connections to maximize throughput, and is ideal for the 50 TB / 48-hour constraint given a 1 Gbps link (theoretical max ~5.4 TB/day, but with parallelism and retries, STS can approach line rate). It eliminates the need for an intermediate VM or manual scripting.

Exam trap

The trap here is that candidates assume a Compute Engine VM with `gsutil -m cp` is the simplest approach, but they overlook that Storage Transfer Service is a fully managed, scalable solution that offloads orchestration and retry logic, making it the only viable option for meeting a strict time constraint with limited bandwidth.

How to eliminate wrong answers

Option A is wrong because using `gsutil -m cp` from a Compute Engine VM introduces a single point of failure, requires managing the VM's lifecycle, and the VM's network egress from AWS is still limited by the same 1 Gbps pipe; moreover, the VM adds latency and cost without any throughput advantage over a managed service. Option C is wrong because downloading to a local machine and re-uploading is impractical for 50 TB (local bandwidth is often far lower than 1 Gbps, and the process is manual, error-prone, and violates the 48-hour SLA). Option D is wrong because BigQuery Data Transfer Service is designed for loading data into BigQuery tables, not for moving raw objects into Cloud Storage; it cannot write to a GCS bucket as a destination.

Full explanation →

377

MCQmedium

You want to use Kustomize to manage environment-specific Kubernetes configurations (dev, staging, prod) from a single base set of manifests. How does Kustomize achieve environment customization without duplicating YAML files?

A.Kustomize duplicates all YAML files per environment, then applies find-and-replace on values.

B.Kustomize uses overlays that patch a shared base: environment-specific differences are expressed as patches without duplicating base manifests.

C.Kustomize uses Helm charts with values files per environment for templating.

D.Kustomize requires a separate Git branch per environment where manifests are committed.

AnswerB

The base contains common YAML (Deployment, Service, etc.). Overlays per environment contain only what differs (image tag, replicas, ConfigMap values) as patches. kubectl apply -k applies them merged.

Why this answer

Kustomize uses a base set of Kubernetes manifests and applies environment-specific overlays that contain patches. These patches modify only the differences (e.g., replicas, image tags, namespaces) without copying or altering the original base YAML files. This approach avoids duplication and keeps the base clean, with each overlay representing a distinct environment.

Exam trap

Google Cloud often tests the distinction between Kustomize's overlay/patch model and Helm's templating approach, so the trap is assuming any configuration management tool uses find-and-replace or requires separate branches.

How to eliminate wrong answers

Option A is wrong because Kustomize does not duplicate YAML files per environment; it uses a layered overlay model with patches, not find-and-replace. Option C is wrong because Helm charts use templating with values files, which is a different tool; Kustomize is template-free and relies on pure YAML patching. Option D is wrong because Kustomize does not require separate Git branches; it manages environments within the same repository using overlay directories.

Full explanation →

378

MCQmedium

A production GKE cluster is running low on node resources. Pods are in Pending state because no node has sufficient CPU or memory. Without deleting existing Pods, what is the fastest way to resolve this?

A.Resize the node pool to add more nodes: `gcloud container clusters resize`

B.Delete existing Pods to free resources for the Pending Pods

C.Change the Pending Pods' resource requests to zero

D.Upgrade the Kubernetes control plane version

AnswerA

`gcloud container clusters resize [CLUSTER] --node-pool=[POOL] --num-nodes=[N]` adds nodes immediately. If cluster autoscaler is enabled, it will do this automatically when Pods are Pending.

Why this answer

Option A is correct because resizing the node pool with `gcloud container clusters resize` immediately adds more nodes to the cluster, providing additional CPU and memory capacity. This allows the scheduler to place pending Pods without modifying or deleting existing workloads, making it the fastest solution that preserves running Pods.

Exam trap

Google Cloud often tests the misconception that upgrading the control plane or modifying Pod specs can resolve resource shortages, when in fact only adding nodes or reducing existing Pod resource usage addresses the capacity issue.

How to eliminate wrong answers

Option B is wrong because deleting existing Pods disrupts running workloads and does not guarantee that freed resources will be sufficient for pending Pods; it also violates the constraint of not deleting existing Pods. Option C is wrong because changing resource requests to zero bypasses Kubernetes resource guarantees, leading to potential resource starvation and unpredictable scheduling behavior, and it requires modifying Pod specs which is not a fast or safe resolution. Option D is wrong because upgrading the control plane version does not add compute resources; it updates the Kubernetes API server and controller manager but does not affect node capacity or scheduling of pending Pods.

Full explanation →

379

MCQmedium

Instead of granting IAM roles to 50 individual developer email addresses, a team wants to manage access by team membership. When a developer joins or leaves, access updates automatically. What is the recommended approach?

A.Create a service account shared by all developers on the team

B.Grant IAM roles to a Google Group containing all team members

C.Create a GCP project per developer and use cross-project IAM bindings

D.Use Cloud Identity-Aware Proxy to manage team membership

AnswerB

Google Groups are supported as IAM principals. Roles granted to a group apply to all members. Membership changes in Google Groups are reflected in GCP access immediately.

Why this answer

Option B is correct because Google Groups act as identity containers that can be granted IAM roles at the project or resource level. When developers are added to or removed from the group, their IAM permissions automatically update without requiring manual role changes for each individual user. This aligns with the principle of least privilege and simplifies access management at scale.

Exam trap

The trap here is that candidates often confuse service accounts with user identities or think that Cloud IAP can manage IAM roles, when in fact IAP only controls access to applications and not to GCP resource-level permissions.

How to eliminate wrong answers

Option A is wrong because sharing a service account among multiple developers violates security best practices — service accounts are intended for application-to-application authentication, not for individual user access, and sharing credentials eliminates audit trails and non-repudiation. Option C is wrong because creating a GCP project per developer introduces unnecessary overhead and complexity; cross-project IAM bindings still require managing individual identities and do not leverage group-based membership for automatic updates. Option D is wrong because Cloud Identity-Aware Proxy (IAP) controls access to applications at the HTTP/S layer, not to GCP IAM roles or resources; it does not replace IAM role management for cloud infrastructure permissions.

Full explanation →

380

MCQmedium

A developer accidentally committed a service account key JSON file to a public GitHub repository. The key was valid for a service account with broad Editor permissions. What should you do FIRST?

A.Remove the committed file from Git history using `git filter-branch` or BFG Repo Cleaner.

B.Immediately delete or disable the service account key in the Cloud Console or via gcloud.

C.Make the GitHub repository private to hide the exposed key.

D.Reduce the service account's permissions to limit the blast radius.

AnswerB

Revoking the key immediately stops any ongoing or future unauthorized use. This is the highest-priority action — stop the bleeding first, then investigate.

Why this answer

Option B is correct because the immediate priority is to revoke the exposed credential to prevent unauthorized access. Deleting or disabling the service account key in the Cloud Console or via `gcloud iam service-accounts keys delete` ensures the key is invalidated within minutes, stopping any attacker from using it to authenticate with Google Cloud APIs. This aligns with the principle of least privilege and incident response best practices: contain the breach before remediation.

Exam trap

Google Cloud often tests the misconception that removing the file from Git history (Option A) is sufficient, but the key remains valid and usable by anyone who already has it, so revocation must come first.

How to eliminate wrong answers

Option A is wrong because removing the file from Git history does not invalidate the already-exposed key; an attacker who has already cloned the repository or accessed the commit can still use the key until it is revoked. Option C is wrong because making the repository private does not revoke the key or prevent attackers who have already seen the public commit from using it; the key remains valid. Option D is wrong because reducing the service account's permissions does not immediately stop an attacker who already has the key from using its current Editor permissions; the key must be disabled first to cut off access.

Full explanation →

381

MCQhard

A company runs a multi-tier web application on Compute Engine: a frontend instance group (us-east1) and a backend instance group (us-east1) that stores data on persistent disks. They recently experienced a zone failure in us-east1-b, causing all instances in that zone to go down. The application was unavailable for 2 hours. The team is now required to design a solution that provides high availability across multiple zones within the us-east1 region and minimizes data loss. The frontend is stateless, but the backend holds critical state data on persistent disks. The team considers: (A) Migrate backend to use regional persistent disks and distribute backend instances across zones using a regional MIG. (B) Use a zonal MIG in us-east1-b with snapshots to another zone. (C) Move the entire application to a single zone in us-central1 with more resources. (D) Use Cloud SQL for backend data and keep Compute Engine instances in a single zone. Which option best meets the requirements?

A.Replace backend Compute Engine instances with Cloud SQL for data storage and keep frontend as is

B.Move all instances to a single zone in us-central1 with larger machine types

C.Keep the backend in a zonal MIG in us-east1-b but take hourly snapshots of persistent disks to a different zone

D.Use regional persistent disks for backend data and deploy a regional managed instance group for backend instances across us-east1-a and us-east1-b

AnswerD

Regional persistent disks are replicated across zones; regional MIG provides auto-healing and distribution.

Why this answer

Option D is correct because it uses regional persistent disks (which replicate data synchronously across two zones in the same region) combined with a regional managed instance group (MIG) that distributes backend instances across us-east1-a and us-east1-b. This architecture ensures that if one zone fails, the backend instances in the other zone can immediately attach the same regional persistent disk, minimizing data loss and providing high availability without requiring manual snapshot recovery.

Exam trap

Google Cloud often tests the distinction between zonal and regional resources; the trap here is that candidates may think snapshots or backups are sufficient for high availability, but they fail to recognize that snapshots do not provide automatic failover or near-zero data loss, which is only achievable with synchronous replication like regional persistent disks.

How to eliminate wrong answers

Option A is wrong because replacing backend Compute Engine instances with Cloud SQL does not address the requirement to minimize data loss from persistent disks; Cloud SQL is a managed database service, not a direct replacement for stateful application data stored on persistent disks, and it introduces a different data storage paradigm that may not support the existing application architecture. Option B is wrong because moving all instances to a single zone in us-central1 does not provide high availability across multiple zones within us-east1; it actually reduces availability by consolidating into one zone and ignores the requirement to stay within us-east1. Option C is wrong because keeping the backend in a zonal MIG in us-east1-b with hourly snapshots to another zone does not provide high availability; snapshots are point-in-time backups and cannot be used to instantly failover, resulting in up to one hour of data loss and significant recovery time, which fails the 'minimizes data loss' requirement.

Full explanation →

382

Multi-Selectmedium

A company is setting up a new Google Cloud environment. They need to ensure that they can manage billing across multiple projects and have a hierarchical resource structure. Which TWO statements are correct about the Google Cloud resource hierarchy?

Select 2 answers

A.Each billing account can be linked to only one project.

B.A project must always belong to a folder or organization.

C.Resources are organized hierarchically with Organization, Folders, Projects, and Resources.

D.Each project must belong to a folder.

E.IAM policies can be inherited from a folder to projects within it.

AnswersC, E

This is the correct hierarchical structure.

Why this answer

Options A and D are correct. Option A correctly describes the hierarchy. Option D correctly states that IAM policies can be inherited from folders.

Option B is false because billing accounts can be linked to multiple projects. Option C is false because projects do not have to belong to a folder. Option E is false because projects can exist without a folder or organization if using a standalone billing account.

Full explanation →

383

Multi-Selecthard

A company has multiple Google Cloud projects and needs to connect VPCs in different regions privately without traversing the public internet or using VPN tunnels. Which two Google Cloud networking solutions can accomplish this requirement?

Select 2 answers

A.VPC Peering

B.Private Google Access

C.Cloud NAT

D.Cloud VPN

E.Shared VPC

AnswersA, E

Direct private connectivity between VPC networks, supports cross-region peering.

Why this answer

Options A and C are correct. VPC Peering (A) allows direct peering between VPCs across regions without internet. Shared VPC (C) allows centralized management and connectivity between host and service projects.

Option B (Cloud NAT) is for outbound internet access. Option D (Cloud VPN) uses the public internet. Option E (Private Google Access) allows on-premises access to Google APIs.

Full explanation →

384

MCQmedium

An application receives the error 'Permission denied on resource project [PROJECT_ID] (or it may not exist)' when making an API call with a service account. The service account has the correct IAM role. What else might be missing?

A.The service account needs the Project Owner role to make any API calls

B.The relevant GCP API is not enabled in the project

C.The service account needs to be in the same organization as the project

D.The service account email must be explicitly allow-listed in the API's configuration

AnswerB

GCP requires the API to be enabled before any service account or user can use it. The error 'or it may not exist' refers to the resource being unreachable because the API is disabled.

Why this answer

The error 'Permission denied on resource project [PROJECT_ID] (or it may not exist)' typically occurs when the service account has the correct IAM role but the API being called is not enabled for the project. Even with proper IAM permissions, GCP requires that the specific API (e.g., Compute Engine API, Cloud Storage API) be enabled in the project before any API calls can succeed. Enabling the API activates the service and allows the service account to use it.

Exam trap

Google Cloud often tests the misconception that IAM roles alone guarantee API access, but the trap here is that candidates overlook the prerequisite of enabling the API service in the project, which is a separate step from assigning IAM permissions.

How to eliminate wrong answers

Option A is wrong because the Project Owner role is not required for making API calls; a service account only needs the specific IAM role granting the necessary permissions, and Project Owner is overly broad and unnecessary. Option C is wrong because service accounts do not need to be in the same organization as the project; they can be created in one project and used in another project within the same or different organization, as long as IAM permissions are granted. Option D is wrong because there is no concept of 'allow-listing' a service account email in an API's configuration; access is controlled entirely through IAM roles and policies, not through an explicit allow list.

Full explanation →

385

MCQeasy

A team's GCP project is approaching its monthly budget. They want to receive an email alert when spending reaches 80% and 100% of the $500 monthly budget. Which GCP feature sends these budget alerts?

A.Cloud Monitoring alerting policy on the billing/cost metric

B.A Cloud Scheduler job that queries the Billing API and sends an email when cost exceeds thresholds

C.Cloud Billing budget with alert thresholds set at 80% and 100%

D.Cloud Logging alert on billing cost log entries

AnswerC

Cloud Billing budgets support multiple alert thresholds. When spending crosses each threshold, notifications are automatically sent to configured email recipients.

Why this answer

Option C is correct because Cloud Billing budgets are the native GCP feature designed to monitor spending against a budget and send email alerts when actual or forecasted costs exceed user-defined thresholds (e.g., 80% and 100% of $500). This feature is configured directly in the Cloud Console or via the Billing API and automatically triggers notifications without requiring custom code or additional services.

Exam trap

Google Cloud often tests the distinction between native GCP services (Cloud Billing budgets) and workarounds (Cloud Scheduler + Billing API) to see if candidates recognize the built-in, no-code solution for budget alerts.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring alerting policies cannot directly use billing/cost metrics; billing data is not exposed as a Cloud Monitoring metric, and the 'billing/cost metric' does not exist in the Monitoring API. Option B is wrong because while a Cloud Scheduler job could theoretically query the Billing API and send an email, this is not a built-in GCP feature for budget alerts—it requires custom development, cron management, and is not the recommended or simplest solution. Option D is wrong because Cloud Logging alerts on billing cost log entries are not supported; billing data is not written to Cloud Logging as structured log entries that can trigger alerts, and the Billing budget feature already handles threshold-based notifications natively.

Full explanation →

386

MCQmedium

A team stores application log archives in a Cloud Storage bucket. Logs older than 90 days should automatically move to Coldline storage, and logs older than 365 days should be deleted. Which feature automates this?

A.Cloud Scheduler jobs that run gsutil rewrite and gsutil rm commands nightly

B.Cloud Storage Object Lifecycle Management rules on the bucket

C.Cloud Pub/Sub notifications triggering a Cloud Function on each object creation

D.Retention policies that lock objects in Coldline after 90 days

AnswerB

Lifecycle rules on the bucket automatically transition objects to Coldline after 90 days and delete them after 365 days — fully managed with no scripts or schedulers required.

Why this answer

Option B is correct because Cloud Storage Object Lifecycle Management rules allow you to automatically transition objects to Coldline storage after 90 days and delete them after 365 days based on object age conditions. This is a native, serverless feature that requires no external compute or scheduling, making it the most efficient and reliable approach for automating tiering and deletion of log archives.

Exam trap

Google Cloud often tests the misconception that custom scheduling or event-driven functions are required for automated data management, when in fact Cloud Storage's native lifecycle management handles age-based transitions and deletions without any additional services.

How to eliminate wrong answers

Option A is wrong because Cloud Scheduler jobs running gsutil rewrite and gsutil rm commands introduce unnecessary complexity, potential for human error, and additional cost for compute resources; lifecycle management handles this natively without custom scripts. Option C is wrong because Cloud Pub/Sub notifications triggering a Cloud Function on each object creation would only fire on new objects, not on existing objects, and would require custom code to implement age-based transitions and deletions, which is less efficient and more error-prone than built-in lifecycle rules. Option D is wrong because retention policies are used to prevent object deletion or modification for a specified period, not to automate transitions or deletions; locking objects in Coldline after 90 days would actually prevent the deletion at 365 days that the requirement specifies.

Full explanation →

387

MCQmedium

A team is designing a system where two GCP projects — a shared services project and an application project — need their VMs to communicate using private IPs. Both projects are in the same organization. Which networking option best enables this with centralized network management?

A.VPC Peering between the two projects' VPCs

B.Shared VPC (XPN) with the shared services project as the host

C.Cloud VPN between the two projects' default VPCs

D.Using external IPs with TLS — private IP communication isn't necessary between GCP projects

AnswerB

Shared VPC centralizes network management in the host project while allowing service project VMs to use shared subnets with private IPs — ideal for organization-wide network governance.

Why this answer

Shared VPC (XPN) allows an organization to centrally manage networking across multiple projects from a single host project, enabling VMs in the shared services project and the application project to communicate via private IPs without needing separate peering or VPN configurations. This is the best option because it provides centralized network administration and policy enforcement, which aligns with the requirement for centralized network management.

Exam trap

The trap here is that candidates often choose VPC Peering (Option A) because it seems simpler for connecting two projects, but they overlook the explicit requirement for centralized network management, which Shared VPC uniquely provides by design.

How to eliminate wrong answers

Option A is wrong because VPC Peering requires manual configuration of each peering connection and does not provide centralized network management; each project retains separate administrative control, and routes must be managed individually. Option C is wrong because Cloud VPN is designed for connecting on-premises networks or different VPCs across regions via encrypted tunnels, but it adds complexity and latency for intra-organization communication that can be achieved more simply with Shared VPC. Option D is wrong because using external IPs with TLS violates the requirement for private IP communication and introduces security risks and egress costs, as well as bypassing the centralized management goal.

Full explanation →

388

MCQmedium

A team builds a document processing pipeline: files are uploaded to Cloud Storage, then analyzed by Cloud Vision AI, results stored in Firestore, and a confirmation email sent. Each step depends on the previous. Which GCP service orchestrates these sequential, dependent steps reliably?

A.Cloud Pub/Sub with a subscription per step

B.Cloud Tasks with per-step queues

C.Cloud Workflows

D.Cloud Functions chained via HTTP calls

AnswerC

Cloud Workflows orchestrates sequential API calls with conditional logic, error handling, and retries — purpose-built for coordinating dependent multi-step pipelines.

Why this answer

Cloud Workflows is designed to orchestrate sequential, dependent steps with built-in retry, error handling, and state management. It directly models the pipeline as a series of steps where each step's output feeds the next, without requiring manual chaining or intermediate messaging infrastructure.

Exam trap

Google Cloud often tests the distinction between asynchronous messaging (Pub/Sub, Tasks) and synchronous orchestration (Workflows), where candidates mistakenly choose a messaging service for sequential workflows because they focus on 'reliability' rather than 'ordered dependency management'.

How to eliminate wrong answers

Option A is wrong because Cloud Pub/Sub is a publish-subscribe messaging service for asynchronous, decoupled communication, not for orchestrating sequential dependent steps; it would require additional logic to enforce order and handle failures. Option B is wrong because Cloud Tasks is a distributed task queue for executing discrete tasks asynchronously, not for defining a sequential workflow with dependencies; it lacks built-in step sequencing and state management. Option D is wrong because chaining Cloud Functions via HTTP calls creates tight coupling, requires manual error handling and retries, and does not provide a centralized view of the workflow execution or built-in step sequencing.

Full explanation →

389

Matchingmedium

Match each BigQuery feature to its description.

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

Concepts

Matches

Unit of compute capacity for queries

Divides tables into segments for faster queries

Sorts data within partitions for better performance

Precomputed query results for faster access

In-memory analysis service for sub-second query response

Why these pairings

These features optimize BigQuery performance and cost.

Full explanation →

390

MCQhard

Refer to the exhibit. A user tries to delete the disk 'my-disk' but receives an error. Based on the exhibit, what is the most likely cause?

A.The disk is being used by a snapshot.

B.The disk size must be 0 to delete.

C.The disk is still attached to an instance.

D.The disk is not in the correct project.

AnswerC

The USERS field shows attachment to an instance.

Why this answer

Option C is correct because a disk cannot be deleted while it is attached to a running or stopped instance. In Google Cloud, you must first detach the disk from the instance before deletion. The error message indicates the disk is in use, and the exhibit confirms it is attached to an instance.

Exam trap

Google Cloud often tests the misconception that snapshots or disk size prevent deletion, but the real blocker is the attachment state, which is a common oversight when managing persistent disks.

How to eliminate wrong answers

Option A is wrong because a disk can be deleted even if it has snapshots; snapshots are independent and do not block disk deletion. Option B is wrong because disk size does not need to be 0 for deletion; any size disk can be deleted as long as it is not attached. Option D is wrong because the disk is in the correct project, as shown in the exhibit; the error is not related to project permissions or location.

Full explanation →

391

MCQmedium

Your security team wants to monitor all privileged IAM changes in your GCP organization (e.g., when anyone is granted `roles/owner` or `roles/editor`). They need real-time notifications. Which approach achieves this?

A.Create a Cloud Monitoring alerting policy on the `iam.googleapis.com/SetIamPolicy` log metric.

B.Enable Security Command Center's Event Threat Detection for IAM changes.

C.Run a daily script using `gcloud projects get-iam-policy` and compare with the previous day's output.

D.Use Cloud Asset Inventory with asset feeds to detect IAM policy changes in real-time.

AnswerA, D

A log-based metric that counts `SetIamPolicy` operations with filter on privileged roles, combined with a Cloud Monitoring alert with a notification channel, provides real-time alerting on IAM changes.

Why this answer

Option A is correct because Cloud Monitoring can ingest log-based metrics from the `iam.googleapis.com/SetIamPolicy` audit log entry, and an alerting policy can be configured to trigger in near real-time when that log metric exceeds a threshold. This provides immediate notification of privileged IAM changes such as granting `roles/owner` or `roles/editor`.

Exam trap

The trap here is that candidates may think Cloud Asset Inventory feeds (Option D) provide real-time detection, but asset feeds have a latency of several minutes and are designed for inventory synchronization, not real-time alerting on specific IAM role grants.

How to eliminate wrong answers

Option B is wrong because Security Command Center's Event Threat Detection focuses on threat detection (e.g., compromised credentials, malware) and does not provide real-time alerting for all IAM policy changes; it is not designed for monitoring routine administrative IAM modifications. Option C is wrong because running a daily script using `gcloud projects get-iam-policy` is a batch, non-real-time approach that introduces up to 24 hours of delay, failing the requirement for real-time notifications.

Full explanation →

392

MCQmedium

A company is migrating a legacy on-premises application to Google Cloud. The application stores structured transactional data in a relational database. The database currently handles 2,000 transactions per second (TPS) and is expected to grow to 10,000 TPS over the next year. The database size is 500 GB. The application requires strong consistency and the ability to run complex JOIN queries. Which Google Cloud database service should the company choose?

A.Cloud Spanner

B.Cloud SQL for PostgreSQL

C.Cloud Bigtable

D.Cloud Firestore

AnswerB

Cloud SQL provides a fully managed relational database with strong consistency and support for complex queries.

Why this answer

Cloud SQL for PostgreSQL is the correct choice because it provides a fully managed relational database with strong ACID compliance, support for complex JOIN queries, and can scale vertically or via read replicas to handle up to 10,000 TPS with proper configuration. The 500 GB database size is well within Cloud SQL's limits, and PostgreSQL's native support for complex joins meets the application's requirements without the operational overhead of self-managed databases.

Exam trap

Google Cloud often tests the misconception that Cloud Spanner is the only option for strong consistency and high TPS, but the trap here is that the workload is single-region and moderate scale, making Cloud SQL a simpler and more cost-effective choice despite Spanner's global capabilities.

How to eliminate wrong answers

Option A is wrong because Cloud Spanner is designed for globally distributed, horizontally scalable workloads with strong consistency, but it introduces unnecessary complexity and higher cost for a single-region workload that only needs up to 10,000 TPS and 500 GB; it also requires schema changes to use interleaved tables for optimal JOIN performance. Option C is wrong because Cloud Bigtable is a NoSQL wide-column database that does not support SQL JOINs or strong relational consistency, making it unsuitable for structured transactional data requiring complex queries. Option D is wrong because Cloud Firestore is a NoSQL document database designed for mobile and web apps with eventual consistency by default, and it lacks native support for complex JOIN operations or the transactional throughput needed for 10,000 TPS.

Full explanation →

393

MCQhard

You need to ensure that a Cloud Run service can only be invoked by specific Cloud Scheduler jobs and not from the public internet, while still receiving HTTP requests. The Cloud Run service currently allows unauthenticated invocations. What configuration changes are required?

A.Add a Cloud Armor security policy to the Cloud Run service blocking all IPs except Cloud Scheduler.

B.Disable unauthenticated invocations on the Cloud Run service, grant `roles/run.invoker` to the Scheduler SA, and configure Scheduler to use OIDC authentication.

C.Deploy the Cloud Run service in a VPC and use a VPC firewall rule to block all traffic except Cloud Scheduler.

D.Add a secret header to Cloud Scheduler requests and validate it in the Cloud Run application code.

AnswerB

This three-step configuration enforces authentication: Cloud Run requires auth tokens, the Scheduler SA has invoker permission, and Scheduler sends OIDC tokens with each request. No other caller can invoke the service.

Why this answer

Option B is correct because Cloud Run services that require authentication must have unauthenticated invocations disabled, and the Cloud Scheduler service account must be granted the `roles/run.invoker` role. Additionally, Cloud Scheduler must be configured to use OIDC authentication, which allows it to present an identity token signed by Google to the Cloud Run service, ensuring only authorized scheduler jobs can invoke the service.

Exam trap

Google Cloud often tests the misconception that IP-based restrictions (like Cloud Armor or VPC firewall rules) can secure serverless services, when in fact serverless services like Cloud Run require IAM-based authentication for secure, identity-aware access control.

How to eliminate wrong answers

Option A is wrong because Cloud Armor security policies operate at the HTTP(S) load balancer level and cannot be directly attached to a Cloud Run service that is not behind a load balancer; also, Cloud Scheduler does not have a fixed set of IP addresses, so blocking by IP is impractical. Option C is wrong because Cloud Run services cannot be deployed directly into a VPC; they use VPC connectors for outbound traffic, and VPC firewall rules cannot control inbound traffic to a serverless service like Cloud Run. Option D is wrong because relying on a secret header for authentication is not a secure access control mechanism; it can be easily spoofed and does not leverage Google Cloud's IAM-based authentication, which is the recommended approach.

Full explanation →

394

MCQeasy

A media company needs to serve large video files (average 2 GB) to global users with low latency. The files are stored in Cloud Storage. What combination of services delivers the best streaming performance?

A.Cloud Storage in a multi-region bucket with direct public access

B.Cloud Storage + Cloud CDN via a Global Load Balancer backend bucket

C.Upload video files to a Compute Engine VM with nginx serving them directly

D.Cloud Filestore with NFS-mounted streaming

AnswerB

Enabling Cloud CDN on a Cloud Storage backend bucket caches video files at Google's edge PoPs globally, reducing latency and origin bandwidth for geographically distributed users.

Why this answer

Cloud Storage combined with Cloud CDN via a Global Loader Balancer backend bucket is the best choice because it provides edge-caching of large video files, reducing latency for global users. The Global Load Balancer terminates HTTP(S) traffic at the closest point of presence, and Cloud CDN caches content from the multi-region bucket, minimizing origin load and improving streaming performance.

Exam trap

Google Cloud often tests the misconception that direct Cloud Storage access (Option A) is sufficient for global low-latency streaming, but the trap is that without a CDN and load balancer, users experience high latency and the bucket cannot handle global traffic efficiently.

How to eliminate wrong answers

Option A is wrong because a multi-region bucket with direct public access lacks edge caching, meaning every user request hits the bucket directly, increasing latency and egress costs for global streaming. Option C is wrong because serving large video files from a single Compute Engine VM with nginx creates a single point of failure, cannot scale to handle global traffic, and introduces unnecessary latency for users far from the VM's region. Option D is wrong because Cloud Filestore with NFS-mounted streaming is designed for high-performance file shares for compute instances, not for direct internet-facing content delivery; it lacks CDN integration and cannot serve video files with low latency to global users.

Full explanation →

395

MCQeasy

A company wants to deploy a web application on Compute Engine. They expect variable traffic and want to automatically add or remove virtual machine instances based on CPU utilization. What is the recommended approach?

A.Use a single large instance and rely on Cloud Load Balancing

B.Use an unmanaged instance group and manually add or remove instances

C.Use a managed instance group with an autoscaling policy based on CPU utilization

D.Deploy the application on App Engine Standard environment

AnswerC

Managed instance groups with autoscaling automatically adjust instance count based on CPU utilization metrics.

Why this answer

A managed instance group (MIG) with an autoscaling policy based on CPU utilization is the recommended approach because it automatically adjusts the number of VM instances in response to real-time CPU load, ensuring the application can handle variable traffic without manual intervention. This aligns with Google Cloud's best practices for elastic scaling of stateless web applications on Compute Engine.

Exam trap

Google Cloud often tests the distinction between managed and unmanaged instance groups, where candidates mistakenly think unmanaged groups can be autoscaled, but only managed instance groups support autoscaling policies.

How to eliminate wrong answers

Option A is wrong because relying on a single large instance with Cloud Load Balancing does not provide autoscaling; a single instance cannot scale out to handle increased traffic and introduces a single point of failure. Option B is wrong because an unmanaged instance group requires manual addition or removal of instances, which contradicts the requirement for automatic scaling based on CPU utilization. Option D is wrong because App Engine Standard is a fully managed platform that abstracts infrastructure, but the question specifically asks about deploying on Compute Engine, not App Engine.

Full explanation →

396

MCQmedium

A team needs to run a containerized HTTP API that scales to zero when idle and requires zero cluster or server management. Which GCP compute platform is the best fit?

A.Compute Engine with a managed instance group

B.Google Kubernetes Engine Autopilot

C.Cloud Run

D.App Engine Flexible

AnswerC

Cloud Run is purpose-built for containerized HTTP services with zero-to-scale autoscaling, no infrastructure management, and per-request billing.

Why this answer

Cloud Run is the best fit because it is a fully managed serverless platform that automatically scales your containerized HTTP API to zero when idle, meaning you pay only for resources used during request processing. It requires no cluster or server management, as it abstracts away the underlying infrastructure entirely, unlike other options that still involve some level of node or instance management.

Exam trap

Google Cloud often tests the distinction between 'scaling to zero' and 'scaling down to a minimum of one' — candidates mistakenly think GKE Autopilot or App Engine Flexible can scale to zero, but only Cloud Run (and Cloud Functions) natively supports true zero-instance scaling without additional configuration.

How to eliminate wrong answers

Option A is wrong because Compute Engine with a managed instance group still requires you to manage virtual machine instances, and while it can scale down, it cannot scale to zero instances (minimum is 1 per zone) and involves server management. Option B is wrong because Google Kubernetes Engine Autopilot, while reducing node management, still requires you to manage a Kubernetes cluster (even if abstracted) and cannot scale to zero pods without manual configuration or third-party tools like KEDA, plus you pay for the cluster control plane. Option D is wrong because App Engine Flexible runs containers but requires at least one instance to be running at all times (cannot scale to zero), and it involves more configuration for custom runtimes compared to Cloud Run's simplicity.

Full explanation →

397

Matchingmedium

Match each Google Kubernetes Engine (GKE) concept to its definition.

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

Concepts

Matches

Smallest deployable unit, one or more containers

Exposes a set of pods as a network service

Declarative update for pods and ReplicaSets

A worker machine in a Kubernetes cluster

Set of nodes managed by the control plane

Why these pairings

These are core Kubernetes objects used in GKE.

Full explanation →

398

Multi-Selecteasy

A company is migrating an on-premises MySQL database to Cloud SQL. Which TWO steps are necessary for setting up ongoing replication from on-premises to Cloud SQL? (Choose 2)

Select 2 answers

A.Set up a Dataflow pipeline to stream changes.

B.Use pg_dump to export the database.

C.Enable binary logging on the on-premises MySQL server.

D.Create a Cloud SQL instance to be the replica.

E.Establish a Cloud VPN connection between on-premises and Google Cloud.

AnswersC, D

Binary logs are needed for replication.

Why this answer

Option C is correct because MySQL's native replication relies on binary logs (binlogs) to capture all changes on the primary server. Enabling binary logging on the on-premises MySQL server is essential to generate the change stream that Cloud SQL will read and apply for ongoing replication.

Exam trap

The trap here is that candidates confuse 'ongoing replication' with 'one-time migration' and select a dump tool (Option B) or a generic streaming service (Option A), missing that MySQL replication specifically requires binary logs and a Cloud SQL replica instance.

Full explanation →

399

MCQmedium

A team runs Apache Kafka on self-managed VMs for event streaming but wants to reduce operational overhead. Which GCP-native service is the managed alternative to Kafka for pub/sub messaging at scale?

A.Cloud Pub/Sub — Google's managed pub/sub messaging service

B.Cloud Bigtable — a managed wide-column store for streaming data

C.Cloud Dataflow — the GCP managed streaming processing service

D.Cloud Storage — use GCS notification events as a message queue

AnswerA

Cloud Pub/Sub is the native GCP alternative to self-managed Kafka — fully managed, globally available, and scales to millions of messages/second without operational overhead.

Why this answer

Cloud Pub/Sub is the correct answer because it is Google Cloud's fully managed, scalable pub/sub messaging service that provides at-least-once delivery and supports both push and pull subscriptions, making it the direct managed alternative to self-managed Apache Kafka. It eliminates the operational overhead of managing Kafka clusters on VMs while offering similar event streaming capabilities with automatic scaling and global availability.

Exam trap

Google Cloud often tests the distinction between a messaging/queue service (Pub/Sub) and a data processing service (Dataflow) or a storage service (Bigtable, Cloud Storage), so candidates mistakenly choose Dataflow because it 'processes streaming data' or Bigtable because it 'handles streaming data,' missing that the question asks for a managed alternative to Kafka's pub/sub messaging, not for processing or storage.

How to eliminate wrong answers

Option B is wrong because Cloud Bigtable is a managed NoSQL wide-column database optimized for low-latency read/write access to large volumes of streaming data, not a pub/sub messaging system; it lacks the topic-based publish-subscribe model and message retention semantics of Kafka. Option C is wrong because Cloud Dataflow is a managed stream and batch processing service (based on Apache Beam) that processes data from sources like Pub/Sub, but it is not a messaging or queue service itself. Option D is wrong because Cloud Storage with GCS notification events provides object change notifications that can be used as a simple event trigger, but it does not offer the durable, ordered, partitioned message log, configurable retention, or pub/sub semantics required for a Kafka alternative.

Full explanation →

400

MCQhard

A service account from project A needs to read a BigQuery dataset in project B. The service account is granted roles/bigquery.dataViewer at the project B level. Yet the access is denied. What additional step is needed?

A.Enable the BigQuery API on project A

B.Grant the service account roles/bigquery.jobUser on project A

C.Grant the service account roles/bigquery.user on project B

D.Add the service account to the dataset's ACL in BigQuery

AnswerD

Dataset ACL can override project-level roles, requiring explicit grant.

Why this answer

D is correct because BigQuery datasets use Access Control Lists (ACLs) in addition to IAM policies. Even though the service account has the roles/bigquery.dataViewer IAM role at the project B level, this role grants access to list datasets and read metadata, but does not automatically grant access to the actual data within a dataset. The dataset's ACL must explicitly include the service account to allow reading the tables and views.

This is a common requirement when cross-project access is needed, as IAM roles at the project level do not propagate to dataset-level ACLs unless the dataset is configured to inherit permissions.

Exam trap

Google Cloud often tests the misconception that IAM roles at the project level are sufficient for cross-project data access, when in fact BigQuery datasets require explicit ACL entries for the service account to read data.

How to eliminate wrong answers

Option A is wrong because enabling the BigQuery API on project A is not required for the service account to read data in project B; the API must be enabled on the project where the dataset resides (project B), and it is likely already enabled. Option B is wrong because roles/bigquery.jobUser on project A grants permission to run jobs (e.g., queries) in project A, but does not grant read access to the dataset in project B; the service account needs data access in project B, not job execution rights in project A. Option C is wrong because roles/bigquery.user on project B allows listing datasets and running jobs, but does not grant read access to the actual data in the dataset; it is a higher-level role that still requires dataset-level ACLs for data access.

Full explanation →

401

MCQmedium

A team runs a Kubernetes CronJob that performs nightly database cleanup. The job runs at 2 AM UTC. This morning, the team notices the job failed at 2 AM but no one was alerted. How should the team configure alerting for CronJob failures?

A.Set `successfulJobsHistoryLimit: 0` — GKE sends an alert when the history is empty

B.Create a log-based metric on CronJob failure events in Cloud Logging and an alerting policy on that metric

C.Set `restartPolicy: Always` on the CronJob's Pod template — it will retry until success

D.Enable GKE's built-in CronJob alerting feature in the cluster's Notifications settings

AnswerB

Kubernetes CronJob failures are logged as events in Cloud Logging. A log-based metric counting failure events, combined with a Cloud Monitoring alerting policy, sends notifications when failures occur.

Why this answer

Option B is correct because Google Cloud Logging captures Kubernetes CronJob failure events, and you can create a log-based metric to count these failures. An alerting policy on that metric then triggers notifications when failures occur, providing a reliable, customizable alerting mechanism that does not depend on job history or restart policies.

Exam trap

The trap here is that candidates assume GKE has a native CronJob alerting toggle or that restart policies alone solve monitoring, when in reality you must explicitly create a log-based metric and alerting policy to detect job failures.

How to eliminate wrong answers

Option A is wrong because setting `successfulJobsHistoryLimit: 0` only removes completed job pods from history; it does not generate any alert and GKE has no built-in alert for an empty history. Option C is wrong because `restartPolicy: Always` is not valid for a CronJob's Pod template (only `Never` or `OnFailure` are allowed) and even if it were, it would retry the pod but not alert on failure. Option D is wrong because GKE does not have a built-in 'CronJob alerting feature' in cluster Notifications settings; cluster Notifications cover node and upgrade events, not CronJob failures.

Full explanation →

402

MCQmedium

A web application uses a managed instance group. Traffic spikes sharply between 9 AM and 5 PM and drops to near zero overnight. Which autoscaling metric most directly triggers scale-out before user experience degrades?

A.Average CPU utilization of instances in the group

B.Pub/Sub subscription queue depth

C.HTTP load balancing serving capacity (requests per second per instance)

D.Disk I/O throughput

AnswerC

This metric reflects actual HTTP request load and triggers scaling before instances become saturated, providing the most responsive scale-out for web workloads.

Why this answer

HTTP load balancing serving capacity (requests per second per instance) is the most direct metric because it measures the actual user-facing load on each instance. When traffic spikes, this metric rises immediately, triggering scale-out before instances become saturated and response times degrade. CPU utilization can lag behind the spike due to queuing or async processing, making it less responsive for sharp traffic patterns.

Exam trap

The trap here is that candidates assume CPU utilization is the universal autoscaling metric, but the ACE exam specifically tests that for web applications with sharp traffic spikes, the HTTP load balancing serving capacity metric provides the fastest and most direct signal to prevent user experience degradation.

How to eliminate wrong answers

Option A is wrong because average CPU utilization can be a lagging indicator—instances may queue requests before CPU spikes, and some workloads (e.g., I/O-bound or async) don't correlate tightly with user-facing load, so scale-out may occur too late. Option B is wrong because Pub/Sub subscription queue depth measures backlog of asynchronous messages, not direct user requests; it is suitable for event-driven or worker-based autoscaling, not for a web application serving live traffic. Option D is wrong because disk I/O throughput is a storage-level metric unrelated to request handling capacity; it would only be relevant for data-intensive batch jobs, not for scaling a web frontend.

Full explanation →

403

MCQhard

You are designing a data pipeline that reads from Cloud Storage, transforms data, and writes to BigQuery. The pipeline must process data exactly when new files land (event-driven), handle files up to 5 GB, and complete within 10 minutes. Which approach best meets these requirements?

A.Configure a Cloud Storage Pub/Sub notification → Cloud Function that launches a Dataflow job for each new file.

B.Use a Cloud Scheduler cron job that scans Cloud Storage every minute and processes new files with Dataflow.

C.Use Cloud Functions triggered by GCS events to read and transform the 5 GB file directly.

D.Use BigQuery Data Transfer Service to load files from Cloud Storage on a schedule.

AnswerA

GCS object notifications to Pub/Sub trigger a Cloud Function that launches a Dataflow job. Dataflow handles files up to 5 GB within 10 minutes using parallel workers, and the event-driven architecture processes files exactly when they land.

Why this answer

Option A is correct because Cloud Storage Pub/Sub notifications provide event-driven triggers for each new file, and launching a Dataflow job via a Cloud Function allows processing of up to 5 GB files within the 10-minute window. Dataflow’s autoscaling and streaming capabilities handle large files efficiently, while the Cloud Function acts as a lightweight orchestrator without processing the data itself.

Exam trap

Google Cloud often tests the misconception that Cloud Functions can handle large data processing tasks directly, but the trap here is ignoring the 9-minute timeout and 2 GB memory limit, which make them unsuitable for files over a few hundred megabytes.

How to eliminate wrong answers

Option B is wrong because Cloud Scheduler cron jobs introduce polling latency (up to 1 minute) and are not truly event-driven, potentially missing the 10-minute completion requirement if files arrive between scans. Option C is wrong because Cloud Functions have a 9-minute timeout and 2 GB memory limit, making them incapable of processing a 5 GB file directly within the required time and resource constraints. Option D is wrong because BigQuery Data Transfer Service is designed for scheduled, batch loads from Cloud Storage, not event-driven processing triggered by new file arrivals, and it lacks the transformation capabilities needed for the pipeline.

Full explanation →

404

MCQeasy

A new developer has just started at your company and has been given access to a project. They need to deploy a Cloud Run service, but they receive an error: 'Permission run.services.create denied.' The developer's IAM role is 'roles/cloudrun.viewer'. What is the most appropriate action to grant the developer the minimum necessary permissions to deploy Cloud Run services?

A.Grant the developer individual permissions: run.services.create and run.services.update.

B.Grant the developer the 'roles/editor' role for the project.

C.Grant the developer the 'roles/run.developer' role.

D.Add the developer to the 'roles/cloudrun.admin' role.

AnswerC

This role has the necessary permissions for deploying and managing Cloud Run services.

Why this answer

The 'roles/run.developer' role grants the minimum necessary permissions to deploy Cloud Run services, including run.services.create and run.services.update, without granting broader project-level access. The developer's current 'roles/cloudrun.viewer' role only allows read-only access, so upgrading to 'roles/run.developer' is the appropriate least-privilege solution.

Exam trap

The trap here is that candidates often confuse 'roles/cloudrun.admin' with the correct role, thinking it is the standard 'admin' role for Cloud Run, but the ACE exam expects knowledge of the newer 'run.developer' role as the least-privilege option for deploying services.

How to eliminate wrong answers

Option A is wrong because granting individual permissions like run.services.create and run.services.update is not a predefined IAM role and would require custom role creation, which is not the most straightforward or recommended approach for a new developer. Option B is wrong because 'roles/editor' grants broad project-level permissions (e.g., to modify all resources), which violates the principle of least privilege and is excessive for deploying only Cloud Run services. Option D is wrong because 'roles/cloudrun.admin' grants full administrative control over Cloud Run resources, including deletion and IAM policy changes, which is more than the minimum necessary permissions for deploying services.

Full explanation →

405

MCQmedium

A GCP project administrator needs to share read-only access to all resources in the project with an external auditor who has a Gmail account (auditor@gmail.com). What should the admin do?

A.Create a service account for the auditor and share the JSON key file

B.Grant the Viewer role to auditor@gmail.com in the project's IAM policy

C.Add auditor@gmail.com as a project billing admin to give them read-only access

D.Create a Cloud Identity account for the auditor — Gmail accounts cannot access GCP projects

AnswerB

GCP IAM supports Gmail accounts as principals. Granting Viewer to auditor@gmail.com gives read-only access to all project resources using their Google identity.

Why this answer

Granting the Viewer (roles/viewer) role to auditor@gmail.com in the project's IAM policy is correct because it provides read-only access to all resources in the project without requiring a Cloud Identity account. Gmail accounts are supported as Google Accounts and can be added directly to IAM policies, allowing them to authenticate and access resources via the GCP Console or APIs.

Exam trap

Google Cloud often tests the misconception that external users with Gmail accounts cannot be added to GCP IAM policies, leading candidates to incorrectly choose the Cloud Identity option, but in reality, any Google Account (including @gmail.com) can be granted IAM roles directly.

How to eliminate wrong answers

Option A is wrong because service accounts are intended for applications and automated workloads, not for individual users; sharing a JSON key file with a person is a security risk and violates best practices for user authentication. Option C is wrong because the Billing Admin role (roles/billing.admin) grants full billing management permissions, not read-only access to project resources, and it does not provide Viewer-level access to compute, storage, or other services. Option D is wrong because Gmail accounts are valid Google Accounts that can be used directly in IAM policies without needing a Cloud Identity account; Cloud Identity is for organizations that want to manage users without Gmail addresses.

Full explanation →

406

MCQeasy

A startup creates its first Google Cloud project. Before deploying any paid resources, what must be linked to the project?

A.A Cloud Identity domain

B.An Organization resource node

C.A billing account

D.A Shared VPC host project

AnswerC

Every project that uses paid GCP services must have a billing account linked. Without it, resource creation for paid services will fail.

Why this answer

A billing account must be linked to a Google Cloud project before deploying any paid resources because Google Cloud requires a valid payment method to be associated with the project to track and charge for resource usage. Without a billing account, the project is in a 'billing-enabled' state and can only use free-tier or always-free resources, but any paid service will fail to provision.

Exam trap

Google Cloud often tests the misconception that an Organization resource node is required for billing, but in reality, a project can be created under no organization (standalone) and still have a billing account attached, so the trap is confusing organizational hierarchy with billing prerequisites.

How to eliminate wrong answers

Option A is wrong because a Cloud Identity domain is used for managing users and groups with identity federation, but it is not a prerequisite for deploying paid resources; a project can exist without a Cloud Identity domain. Option B is wrong because an Organization resource node is a top-level container for projects under an organization, but it is not required for a standalone project; a project can be created without an organization node, and billing can still be attached. Option D is wrong because a Shared VPC host project is used to share VPC networks across multiple projects, but it is not required for a single project to deploy paid resources; billing is independent of VPC sharing.

Full explanation →

407

MCQhard

An enterprise stores sensitive customer data in Cloud Storage. Regulatory requirements mandate that the company controls its own encryption keys — Google must not be able to decrypt data unilaterally. Which encryption configuration satisfies this?

A.Google-managed encryption keys (the default)

B.Customer-managed encryption keys (CMEK) using Cloud KMS

C.Client-side encryption before uploading to Cloud Storage, without using Cloud KMS

D.Shielded VM with vTPM enabled on the storage backend

AnswerB

CMEK keys are created and controlled by the customer in Cloud KMS. GCP encrypts data using these keys, but the customer retains full control — including the ability to revoke access.

Why this answer

Option B is correct because Customer-Managed Encryption Keys (CMEK) with Cloud KMS allow the enterprise to control and manage their own encryption keys, ensuring that Google cannot unilaterally decrypt the data. With CMEK, the encryption keys are stored in Cloud KMS under the customer's control, and Google only has access to the key material for encryption/decryption operations as authorized by the customer. This satisfies the regulatory requirement that the company retains sole control over key material, preventing Google from decrypting data without explicit permission.

Exam trap

The trap here is that candidates often confuse client-side encryption (Option C) as always meeting compliance requirements, but the ACE exam tests that CMEK is the specific Google Cloud service that provides customer-controlled keys with full integration into Cloud Storage's access control and auditing, whereas client-side encryption lacks native key management and audit trails.

How to eliminate wrong answers

Option A is wrong because Google-managed encryption keys are the default where Google generates, stores, and manages the keys, meaning Google can decrypt the data unilaterally, which violates the regulatory mandate. Option C is wrong because client-side encryption before uploading to Cloud Storage, without using Cloud KMS, does not leverage Google's key management infrastructure and may not meet compliance requirements that mandate integration with a managed key service like Cloud KMS for auditing and key rotation; it also places full key management burden on the customer without the controls of CMEK. Option D is wrong because Shielded VM with vTPM is a compute instance security feature that ensures boot integrity and key attestation, not a storage encryption configuration; it does not control encryption keys for Cloud Storage data.

Full explanation →

408

MCQeasy

A developer's gcloud command fails with 'PROJECT_ID is not set'. They need to confirm the currently active configuration — project, account, and default region. Which command shows this?

A.gcloud info

B.gcloud config list

C.gcloud auth status

D.gcloud projects describe --current

AnswerB

`gcloud config list` displays the active configuration: project, account, region, zone, and any other set properties. It's the quickest way to verify the current context.

Why this answer

Option B, `gcloud config list`, is correct because it displays the currently active configuration's core properties: project, account, and region (and zone if set). This directly answers the need to confirm the active project ID, account, and default region, and is the standard command for troubleshooting configuration issues like 'PROJECT_ID is not set'.

Exam trap

The trap here is that candidates confuse `gcloud info` (which shows verbose SDK details) with `gcloud config list` (which shows the active configuration's settings), or they incorrectly assume `gcloud projects describe --current` is a valid shortcut to fetch the current project's metadata.

How to eliminate wrong answers

Option A is wrong because `gcloud info` shows detailed information about the SDK installation, including paths, versions, and network settings, but it does not present the active configuration's project, account, and region in a concise, focused list. Option C is wrong because `gcloud auth status` only verifies the authentication state of the current account (e.g., whether credentials are valid) and does not display the project ID or default region. Option D is wrong because `gcloud projects describe --current` is not a valid command; `gcloud projects describe` requires a project ID or number as an argument, and there is no `--current` flag to infer the active project from the configuration.

Full explanation →

409

MCQeasy

A company needs to store structured data with strong consistency and global distribution for a global user base. Which Google Cloud database service is best suited?

A.Bigtable

B.Cloud Spanner

C.Cloud SQL

D.Firestore

AnswerB

Cloud Spanner is a globally distributed, strongly consistent database.

Why this answer

Cloud Spanner is the correct choice because it provides strong consistency, horizontal scalability, and global distribution via synchronous replication across regions. It supports SQL queries and ACID transactions, making it ideal for structured data that requires both consistency and global access.

Exam trap

The trap here is that candidates often confuse Firestore's multi-region mode with strong global consistency, not realizing that Firestore sacrifices consistency for availability in that configuration, while Cloud Spanner is the only option that guarantees strong consistency across globally distributed regions.

How to eliminate wrong answers

Option A is wrong because Bigtable is a NoSQL wide-column database designed for high-throughput, low-latency analytical workloads, not for strong consistency across global regions (it offers eventual consistency). Option C is wrong because Cloud SQL is a regional relational database that cannot natively replicate across multiple global regions with strong consistency. Option D is wrong because Firestore is a NoSQL document database that offers strong consistency only within a single region; its multi-region mode provides eventual consistency, not the strong consistency required for global distribution.

Full explanation →

410

MCQeasy

Your web application serves users globally. Static assets (images, JS, CSS) are stored in Cloud Storage. Users in Asia report slow load times for these assets. The application origin is in `us-central1`. What is the most cost-effective way to improve static asset performance for Asian users?

A.Replicate the Cloud Storage bucket to an Asia region and update DNS to route Asian users to the regional bucket.

B.Enable Cloud CDN on the Cloud Storage bucket's load balancer backend.

C.Deploy Cloud Run instances in Asia regions to serve the static assets.

D.Increase the Cloud Storage bucket's replication factor to improve throughput.

AnswerB

Cloud CDN caches static assets at Google's global edge PoPs. Asian users receive cached content from a nearby PoP, reducing round-trip latency to us-central1 dramatically.

Why this answer

Cloud CDN uses Google's global edge cache network to serve static assets from locations close to users, reducing latency for Asian users without requiring bucket replication or additional compute. It is the most cost-effective solution because it leverages existing Cloud Storage as the origin and only charges for cache egress and operations, avoiding the overhead of managing regional buckets or compute instances.

Exam trap

Google Cloud often tests the misconception that moving data closer to users requires replicating the storage or deploying compute in multiple regions, when in fact a global CDN is the simplest and most cost-effective solution for static content delivery.

How to eliminate wrong answers

Option A is wrong because replicating the Cloud Storage bucket to an Asia region and updating DNS adds complexity and cost for storage and egress, and DNS-based routing does not provide the same low-latency edge caching as Cloud CDN. Option C is wrong because deploying Cloud Run instances in Asia regions to serve static assets is over-engineered and more expensive than using Cloud CDN, as Cloud Run is designed for compute workloads, not static asset delivery. Option D is wrong because Cloud Storage buckets do not have a configurable 'replication factor' to improve throughput; throughput is handled by the underlying infrastructure, and increasing it does not address geographic latency.

Full explanation →

411

MCQmedium

A team uses Terraform to manage GCP infrastructure. After running `terraform plan`, they see 15 resources to be created. They want to apply only the Cloud SQL instance (resource name: `google_sql_database_instance.main`) without applying all 15 changes. Which Terraform command targets a specific resource?

A.terraform apply --resource=google_sql_database_instance.main

B.terraform apply -target=google_sql_database_instance.main

C.terraform apply -only=google_sql_database_instance.main

D.terraform plan --filter=google_sql_database_instance.main && terraform apply

AnswerB

The `-target` flag limits apply to the specified resource and its direct dependencies — creating only the Cloud SQL instance from the 15-resource plan.

Why this answer

Option B is correct because Terraform uses the `-target` flag to limit the operation to a specific resource address, allowing you to apply only the `google_sql_database_instance.main` resource without affecting the other 14 resources in the plan. This is the standard Terraform syntax for targeting a single resource during `apply` or `destroy` operations.

Exam trap

Google Cloud often tests the distinction between valid Terraform flags like `-target` and common but invalid flags such as `--resource`, `-only`, or `--filter`, exploiting candidates' familiarity with other tools (e.g., `kubectl` or `gcloud`) that use similar but different syntax.

How to eliminate wrong answers

Option A is wrong because `--resource` is not a valid Terraform flag; Terraform uses `-target` for resource targeting. Option C is wrong because `-only` is not a valid Terraform flag; it does not exist in Terraform's CLI syntax. Option D is wrong because `--filter` is not a valid Terraform flag for `plan`; Terraform does not support filtering resources in `plan` output, and the proposed command chain would not achieve targeted application.

Full explanation →

412

MCQmedium

A developer accidentally exposed their gcloud application default credentials (ADC) file. They need to immediately revoke these credentials. Which command revokes the active application default credentials?

A.gcloud auth revoke [ACCOUNT_EMAIL]

B.gcloud auth application-default revoke

C.Delete the ~/.config/gcloud/application_default_credentials.json file manually

D.gcloud config unset auth/application_default_credentials

AnswerB

This command specifically revokes the application default credentials (the ADC file used by client libraries), not the standard gcloud CLI credentials.

Why this answer

Option B is correct because `gcloud auth application-default revoke` is the specific command designed to revoke the Application Default Credentials (ADC) that were set via `gcloud auth application-default login`. This command invalidates the OAuth 2.0 refresh token stored in the ADC file, ensuring the credentials can no longer be used for authentication to Google Cloud APIs.

Exam trap

Google Cloud often tests the distinction between user credentials (`gcloud auth`) and application credentials (`gcloud auth application-default`), and the trap here is that candidates mistakenly think deleting the file or using a general revoke command is sufficient, overlooking the need to explicitly revoke the OAuth refresh token server-side.

How to eliminate wrong answers

Option A is wrong because `gcloud auth revoke [ACCOUNT_EMAIL]` revokes user account credentials used for gcloud CLI operations, not the separate Application Default Credentials (ADC) file. Option C is wrong because simply deleting the file does not revoke the underlying OAuth 2.0 refresh token; the token remains valid until it expires or is explicitly revoked via the command, leaving a potential security gap. Option D is wrong because `gcloud config unset auth/application_default_credentials` unsets a configuration property that does not exist; ADC is managed via a credentials file, not a gcloud config property, so this command has no effect on revoking the credentials.

Full explanation →

413

MCQmedium

You have a Cloud Run service configured with `min-instances: 0`. During load testing you notice the first request after a period of inactivity takes 3–5 seconds instead of the normal 100ms. Subsequent requests are fast. What is causing this, and what is the most cost-effective fix?

A.The Cloud Run service's container image is too large; reduce image size.

B.Set `min-instances: 1` to keep a warm instance running and eliminate the cold start latency.

C.Switch from Cloud Run to GKE, which doesn't have cold starts.

D.Increase Cloud Run's request timeout to 30 seconds to accommodate cold starts.

AnswerB

min-instances: 1 prevents scale-to-zero, keeping a container warm. The first request after inactivity hits a ready instance instead of waiting for container startup.

Why this answer

Cold starts occur when Cloud Run needs to spin up a new container instance from zero. The 3–5 second delay is the container startup time. Setting `min-instances: 1` keeps at least one instance warm at all times, eliminating cold starts for the first request.

This adds a small cost (one always-running instance) but is the most targeted fix. Increasing memory or CPU doesn't directly address cold start if the issue is container initialization time.

Full explanation →

414

MCQmedium

A compliance team needs a log of every time a user or service account accessed data in a BigQuery dataset — specifically read operations. Which Cloud Audit Log type captures this?

A.System event audit logs

B.Admin Activity audit logs

C.Data Access audit logs

D.VPC flow logs

AnswerC

Data Access audit logs record API calls that read data — including BigQuery table reads and query executions. They must be explicitly enabled and can generate high log volume.

Why this answer

Data Access audit logs record API calls that read or modify user-provided data, including BigQuery read operations like SELECT queries. Since the requirement is specifically for read operations on user data, Data Access logs are the correct type. Admin Activity logs cover configuration changes, not data reads, and System Event logs cover Google-managed actions, not user-initiated reads.

Exam trap

Google Cloud often tests the distinction between Admin Activity logs (which capture resource configuration changes) and Data Access logs (which capture data reads/writes), leading candidates to mistakenly choose Admin Activity for any 'access' scenario.

How to eliminate wrong answers

Option A is wrong because System event audit logs capture Google Cloud administrative actions that change resource configurations, not user or service account data reads. Option B is wrong because Admin Activity audit logs record operations that modify metadata or configurations (e.g., creating a dataset), not read operations on the data itself. Option D is wrong because VPC flow logs capture network traffic metadata (IP addresses, ports, protocols) at the subnet level, not application-level data access like BigQuery queries.

Full explanation →

415

MCQmedium

An organization is running a batch job that processes sensitive data. The job writes output to a Cloud Storage bucket. The security team requires that all data at rest be encrypted with a customer-managed key. Which key type should be used?

A.Cloud HSM

B.Default encryption (Google-managed)

C.Customer-supplied encryption keys (CSEK)

D.Cloud KMS CMEK

AnswerD

CMEK provides customer control over keys via Cloud KMS.

Why this answer

Cloud KMS CMEK (Customer-Managed Encryption Keys) is the correct choice because it allows the organization to control and manage the encryption keys used to protect data at rest in Cloud Storage, meeting the security team's requirement for customer-managed keys. CMEK keys are created and managed in Cloud KMS, and you can control key rotation, access, and lifecycle, ensuring compliance with regulatory mandates for customer-managed encryption.

Exam trap

Google Cloud often tests the distinction between key types (CMEK, CSEK, Google-managed) and key protection methods (Cloud HSM, Cloud KMS), so the trap here is confusing Cloud HSM (a key protection option) with a key type, or thinking CSEK is still the recommended customer-managed approach for Cloud Storage.

How to eliminate wrong answers

Option A is wrong because Cloud HSM is a hardware security module service that provides a FIPS 140-2 Level 3 certified environment for key operations, but it is a key hosting option for CMEK keys, not a key type itself; the question asks for the key type, not the key protection method. Option B is wrong because Default encryption (Google-managed) uses Google-managed keys, which do not satisfy the requirement for customer-managed keys, as the organization cannot control or audit the key material. Option C is wrong because Customer-supplied encryption keys (CSEK) are used for client-side encryption where the customer provides the key directly in API calls, but CSEK is deprecated and not recommended for Cloud Storage; moreover, CSEK keys are not managed through Cloud KMS and do not provide the same level of integration, auditing, or lifecycle management as CMEK.

Full explanation →

416

Matchingmedium

Match each Google Cloud service to its primary purpose.

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

Concepts

Matches

Object storage for unstructured data

Serverless data warehouse for analytics

Asynchronous messaging service

Event-driven serverless compute

Managed relational database service

Why these pairings

These are core GCP services with distinct use cases.

Full explanation →

417

MCQmedium

A company runs an App Engine Standard application with multiple versions. They want to gradually roll out new features by sending a small percentage of traffic to a new version. How should they implement this?

A.Deploy the new version and delete the old version

B.Use Cloud Load Balancing to distribute traffic between versions

C.Create a new service for the new version and use a custom domain

D.Use App Engine's traffic splitting feature to assign a percentage of traffic to the new version

AnswerD

Traffic splitting is natively supported by App Engine for gradual rollouts.

Why this answer

App Engine Standard provides built-in traffic splitting, allowing you to assign a percentage of incoming requests to different versions of the same service. This is the simplest and most direct way to gradually roll out a new feature by sending a small percentage of traffic to the new version without needing external load balancers or additional services.

Exam trap

The trap here is that candidates may confuse App Engine's internal traffic splitting with external Cloud Load Balancing, thinking they need to set up a separate load balancer when App Engine already provides this capability natively for version-level traffic distribution.

How to eliminate wrong answers

Option A is wrong because deleting the old version would immediately send 100% of traffic to the new version, which defeats the purpose of a gradual rollout. Option B is wrong because Cloud Load Balancing is used for distributing traffic across different services or regions, not for splitting traffic between versions of the same App Engine service; App Engine's traffic splitting handles this internally. Option C is wrong because creating a new service for the new version and using a custom domain would require separate scaling and routing, and it does not provide the fine-grained percentage-based traffic splitting between versions within the same service that the question requires.

Full explanation →

418

MCQmedium

A team is using Cloud Deployment Manager to define infrastructure as code. They need to ensure that a Cloud Storage bucket is created before a Compute Engine instance that uses the bucket. How should they accomplish this?

A.Use a dependsOn metadata annotation in the instance template

B.Set a dependency using the 'dependsOn' field in the instance resource definition

C.Reference the bucket's selfLink in the instance template metadata

D.Create the bucket and instance in separate deployments and run them sequentially

AnswerB

dependsOn in the resource definition ensures the bucket is created first.

Why this answer

In Cloud Deployment Manager, you can define explicit dependencies between resources using the `dependsOn` field within the resource definition. This ensures that the Cloud Storage bucket is fully created before the Compute Engine instance that references it, preventing race conditions or deployment failures. The `dependsOn` field accepts a list of resource names or selfLinks, and Deployment Manager waits for the depended-on resource to reach a DONE state before creating the dependent resource.

Exam trap

Google Cloud often tests the misconception that simply referencing a resource's attribute (like selfLink) in another resource's configuration automatically creates a dependency, but in Deployment Manager, dependencies must be explicitly declared with `dependsOn`.

How to eliminate wrong answers

Option A is wrong because `dependsOn` is not a metadata annotation; metadata annotations in Deployment Manager are used for arbitrary key-value pairs, not for resource dependency ordering. Option C is wrong because referencing the bucket's selfLink in instance template metadata does not create an implicit dependency; Deployment Manager does not automatically infer dependencies from metadata references — you must explicitly declare them with `dependsOn`. Option D is wrong because creating the bucket and instance in separate deployments and running them sequentially is an unnecessary manual workaround that defeats the purpose of using a single declarative template; Deployment Manager natively supports intra-template dependencies with `dependsOn`.

Full explanation →

419

MCQmedium

A team's application emits a custom business metric (orders per minute) via its code. They want to display this metric on a Cloud Monitoring dashboard and alert when it drops below 50 orders per minute. What must be done first?

A.Enable the Custom Metrics feature flag in the GCP Console under Cloud Monitoring settings

B.Instrument the application to write the metric to the Cloud Monitoring API using a client library or OpenTelemetry

C.Create a log-based metric that extracts the orders value from application logs

D.Custom metrics require BigQuery — store values in BigQuery and link it to Cloud Monitoring

AnswerB

The application must emit the custom metric to Cloud Monitoring via the Monitoring API, client library (e.g., google-cloud-monitoring), or OpenTelemetry SDK. Once flowing, it appears in Metrics Explorer.

Why this answer

Option B is correct because Cloud Monitoring requires metrics to be explicitly ingested via its API or through OpenTelemetry. Custom metrics are not automatically available; the application must be instrumented to write the metric data (e.g., using the `cloud.google.com/go/monitoring` client library or OpenTelemetry exporter) to the Cloud Monitoring API. Without this step, the metric does not exist in Cloud Monitoring for dashboards or alerts.

Exam trap

Google Cloud often tests the misconception that custom metrics require a feature flag or a separate storage service like BigQuery, when in reality the only prerequisite is instrumenting the application to send data to the Cloud Monitoring API.

How to eliminate wrong answers

Option A is wrong because there is no 'Custom Metrics feature flag' in Cloud Monitoring settings; custom metrics are enabled by default once you write data via the API, and no toggle is required. Option C is wrong because a log-based metric extracts values from existing log entries, but the question states the metric is emitted via code, not logs — creating a log-based metric would require the application to first write logs, which is an unnecessary extra step and not the direct method for a custom metric. Option D is wrong because custom metrics do not require BigQuery; Cloud Monitoring stores custom metric data natively in its time-series database, and BigQuery integration is optional for long-term analysis, not a prerequisite.

Full explanation →

420

MCQmedium

Refer to the exhibit. You have set up an HTTP load balancer with this health check. Your backend instances are running a web server on port 80, and the /health endpoint returns 200 OK. However, the health check marks all instances as unhealthy. What is the most likely cause?

A.The unhealthyThreshold is too low

B.The health check port is 80 but the web server is on port 80

C.The checkIntervalSec is too high

D.The requestPath is /healthz but the application does not have that endpoint

AnswerD

Correct. The health check path must match the application's health endpoint.

Why this answer

The health check is configured with requestPath /healthz, but the application only serves /health. This mismatch causes the health check to receive a non-200 response, marking instances unhealthy.

Full explanation →

421

MCQmedium

During a gcloud CLI session, a developer runs `gcloud config list` and sees the output shows `project = old-project`. They need to work in `new-project`. Which sequence of commands correctly switches projects and verifies the change?

A.gcloud projects activate new-project; gcloud config list

B.gcloud config set project new-project; gcloud config list

C.gcloud auth login --project=new-project; gcloud config list

D.export GCLOUD_PROJECT=new-project; gcloud config list

AnswerB

`gcloud config set project` updates the active project and `gcloud config list` confirms the new setting — a clean, targeted approach.

Why this answer

Option B is correct because `gcloud config set project new-project` updates the active project in the local CLI configuration, and `gcloud config list` then displays the current configuration, confirming the change. This is the standard method to switch the working project for subsequent gcloud commands.

Exam trap

Google Cloud often tests the distinction between environment variables and configuration file settings, trapping candidates who think setting `GCLOUD_PROJECT` will update the output of `gcloud config list`.

How to eliminate wrong answers

Option A is wrong because `gcloud projects activate new-project` is not a valid gcloud command; the correct command to switch projects is `gcloud config set project`. Option C is wrong because `gcloud auth login --project=new-project` authenticates the user and optionally sets a project during login, but it does not reliably change the project for the current session if a project is already configured; the `--project` flag is only a one-time override and does not persist in the config. Option D is wrong because `export GCLOUD_PROJECT=new-project` sets an environment variable that overrides the project for the current shell session, but `gcloud config list` still reads from the local configuration file and will show the old project unless the config is also updated; the environment variable is not reflected in `gcloud config list` output.

Full explanation →

422

MCQmedium

An internal web application running on GKE must be accessible only to employees who are authenticated with the company's Google Workspace account — without exposing it to the internet or using a VPN. Which GCP service provides identity-based access without a VPN?

A.VPC Service Controls creating a perimeter around the GKE cluster

B.Cloud Identity-Aware Proxy (IAP) configured on the load balancer in front of the GKE service

C.Firebase Authentication SDK integrated into the web application frontend

D.Cloud Armor with a Google Workspace IP allowlist

AnswerB

IAP enforces Google identity authentication at the load balancer layer. Users must sign in with an authorized Google account — rejecting all unauthenticated requests before they reach the application.

Why this answer

Cloud Identity-Aware Proxy (IAP) is the correct choice because it enforces identity-based access control at the application layer, verifying that users are authenticated via Google Workspace before allowing traffic to reach the GKE service through an HTTPS load balancer. This eliminates the need for a VPN or public internet exposure by leveraging Google's global infrastructure to authenticate and authorize each request based on the user's identity and context.

Exam trap

The trap here is that candidates often confuse network-level controls (VPC Service Controls, Cloud Armor IP allowlists) with identity-based access, or they assume client-side authentication (Firebase) is sufficient for server-side access control, missing that IAP is the only service that combines identity verification with network edge enforcement without a VPN.

How to eliminate wrong answers

Option A is wrong because VPC Service Controls creates perimeters to prevent data exfiltration and restrict access based on network context, but it does not provide per-user authentication or authorization for individual HTTP requests; it operates at the VPC network boundary, not the application layer. Option C is wrong because Firebase Authentication SDK is designed for client-side user authentication in web and mobile apps, but it does not integrate with GKE's ingress or load balancer to control access at the network edge, and it would require exposing the application to the internet for the SDK to function. Option D is wrong because Cloud Armor with a Google Workspace IP allowlist is not feasible, as Google Workspace does not publish a static or predictable set of IP addresses for all employee connections; employees may connect from various networks, including home or mobile, making IP-based allowlisting ineffective for identity-based access.

Full explanation →

423

MCQmedium

A team deploys a containerized service to Cloud Run. After deployment, requests are timing out after 60 seconds. The service sometimes needs 3 minutes to process certain long-running requests. What should the team adjust?

A.Increase the minimum number of instances to reduce cold starts

B.Increase the Cloud Run request timeout to at least 180 seconds

C.Set concurrency to 1 to ensure each instance handles only one request at a time

D.Switch to Cloud Run Jobs instead of Cloud Run Services

AnswerB

Cloud Run's default request timeout is 60 seconds. For requests needing up to 3 minutes, the timeout must be explicitly increased (up to 3600 seconds via the console or `--timeout` flag).

Why this answer

Cloud Run has a default request timeout of 60 seconds. Since the service requires up to 3 minutes (180 seconds) for certain long-running requests, the timeout must be increased to at least 180 seconds. This is configured via the `--timeout` flag or the `timeout_seconds` field in the YAML configuration, and the maximum allowed value is 60 minutes (3600 seconds).

Exam trap

Google Cloud often tests the distinction between timeout-related issues and scaling or concurrency issues, so candidates mistakenly choose options that address cold starts or concurrency when the real problem is a hard timeout limit.

How to eliminate wrong answers

Option A is wrong because increasing the minimum number of instances reduces cold start latency but does not affect the request timeout; the 60-second timeout will still terminate long-running requests. Option C is wrong because setting concurrency to 1 limits the number of concurrent requests per instance but does not extend the request timeout; the request will still be terminated after 60 seconds. Option D is wrong because Cloud Run Jobs are designed for batch workloads that run to completion, not for handling HTTP requests; switching to Jobs would break the service's HTTP endpoint functionality.

Full explanation →

424

MCQmedium

A company recently deployed a web application on a managed instance group (MIG) behind a regional external HTTP(S) load balancer. The application is a Python Flask app running on Compute Engine VMs. After a code update that caused increased response times under load, users report intermittent 503 errors. You examine the load balancer logs and see that the backend instances are periodically marked as unhealthy. The health check is configured to query the /health endpoint every 5 seconds with a healthy threshold of 2 and a timeout of 1 second. The application's /health endpoint returns 200 OK, but sometimes takes up to 1.5 seconds to respond. What is the most likely cause of the health check failures?

A.The instances are overloaded and failing health checks intermittently.

B.The health check response timeout is too low for the application's increased response time.

C.The health check firewall rule is missing or misconfigured.

D.The health check is checking the wrong port.

AnswerB

Timeout of 1 second causes false negatives when response takes 1.5 seconds.

Why this answer

The health check is configured with a timeout of 1 second, but the /health endpoint now takes up to 1.5 seconds to respond due to the code update. Since the health check waits only 1 second for a response, any request that takes longer than that will be considered a failure, causing the backend to be marked unhealthy and triggering 503 errors. This is a classic mismatch between health check timeout and application response time.

Exam trap

Google Cloud often tests the distinction between a health check timing out versus the instance being truly unhealthy—candidates may incorrectly attribute intermittent 503s to overload (Option A) rather than recognizing that the health check timeout value is the direct cause when the endpoint response time exceeds it.

How to eliminate wrong answers

Option A is wrong because while overloaded instances can cause health check failures, the specific evidence here is that the /health endpoint itself takes up to 1.5 seconds to respond, which directly exceeds the 1-second timeout—overload is a possible symptom but not the root cause. Option C is wrong because a missing or misconfigured firewall rule would cause health checks to fail consistently (all probes would time out or be dropped), not intermittently with some successful responses. Option D is wrong because the health check is configured to query the /health endpoint on the correct port (default HTTP 80 or the port the app listens on), and the logs show that the endpoint does respond, just slowly—so the port is not the issue.

Full explanation →

425

MCQmedium

A developer receives a "Permission 'cloudfunctions.functions.call' denied" error when trying to invoke a Cloud Function from another service. What is the most likely cause?

A.The service account of the caller lacks the Cloud Functions Invoker role.

B.The function is not deployed to the correct region.

C.The Cloud Function has a CORS misconfiguration.

D.The VPC connector is not configured correctly.

AnswerA

IAM permissions are required to invoke a function.

Why this answer

The error 'Permission cloudfunctions.functions.call denied' indicates that the Identity and Access Management (IAM) policy does not grant the caller the required permission to invoke the function. The Cloud Functions Invoker role (roles/cloudfunctions.invoker) specifically allows the `cloudfunctions.functions.call` permission, which is necessary for HTTP-triggered functions. Without this role on the caller's service account, any invocation attempt will be denied, regardless of other configurations.

Exam trap

Google Cloud often tests the distinction between IAM permission errors and network/configuration errors, so candidates mistakenly choose CORS or VPC options because they think invocation failures are always due to networking or browser restrictions, but the specific error message points directly to a missing IAM role.

How to eliminate wrong answers

Option B is wrong because deploying to the wrong region would cause a 'function not found' or routing error, not a permission denied error; the IAM check occurs before regional routing. Option C is wrong because CORS misconfiguration affects browser-based cross-origin requests by blocking HTTP responses, not the underlying IAM authorization; the error message explicitly references a permission denial, not a CORS header issue. Option D is wrong because VPC connector misconfiguration would cause network connectivity failures (e.g., timeouts or unreachable endpoints) but does not affect IAM permission checks; the error is about authorization, not network access.

Full explanation →

426

MCQhard

A healthcare company uses GCP to store sensitive patient data in Cloud Storage buckets. Their security policy requires that all data access be logged and that any attempt to access data from outside the corporate network is blocked. They have implemented VPC Service Controls to create a service perimeter around the projects containing the buckets. They have also enabled Data Access audit logs. However, during an audit, they find that a few access attempts from an IP address outside the corporate network succeeded. The logs show that the requests were made using service account credentials. The service account has the storage.objectViewer role on the bucket. The VPC Service Controls perimeter is configured to block all access from outside the perimeter, but the logs show that some requests were allowed. What is the most likely reason?

A.The VPC Service Controls perimeter was configured with an access level that permits certain IP ranges.

B.The bucket is outside the service perimeter.

C.The service account is a member of the perimeter.

D.The VPC Service Controls perimeter does not block requests made by service accounts.

AnswerA

Access levels can allow traffic from specific IPs, so if the external IP is in an allowed range, the request succeeds.

Why this answer

Option A is correct because VPC Service Controls can be configured with access levels that define allowed client IP ranges. If the access level permits the IP addresses from which the service account requests originated, those requests would be allowed even though they come from outside the corporate network. The logs confirm that the requests used service account credentials, and the storage.objectViewer role grants read access, so the only remaining control that could have been bypassed is the VPC Service Controls perimeter — and an overly permissive access level is the most likely cause.

Exam trap

Google Cloud often tests the misconception that VPC Service Controls blocks all traffic from outside the perimeter unconditionally, but the trap here is that access levels can create exceptions that allow specific IP ranges, including non-corporate IPs, to bypass the block.

How to eliminate wrong answers

Option B is wrong because if the bucket were outside the service perimeter, VPC Service Controls would not apply at all, and the question states the perimeter is configured around the projects containing the buckets, so the buckets are inside the perimeter. Option C is wrong because service accounts are not 'members' of a service perimeter; VPC Service Controls perimeters define boundaries around projects, not individual identities, and service accounts inside the perimeter are still subject to the same ingress/egress rules. Option D is wrong because VPC Service Controls does block requests made by service accounts when those requests originate from outside the perimeter, unless an access level or other exception is explicitly configured.

Full explanation →

427

MCQmedium

A gaming company's GKE cluster uses a mix of node pools: a standard on-demand pool for stateful database pods, and a Spot VM pool for compute-intensive but fault-tolerant game simulation pods. The simulation pods occasionally get preempted. How should the Deployment be configured to route simulation pods to the Spot pool only?

A.Set podAffinity to prefer nodes where Spot pods are running

B.Add a nodeSelector: cloud.google.com/gke-spot: 'true' to the simulation Deployment spec

C.Set requests.cpu and requests.memory to very high values — GKE will route them to Spot nodes

D.Name the simulation Deployment with a 'spot-' prefix — GKE routes prefixed deployments to Spot pools

AnswerB

GKE automatically labels Spot VMs with `cloud.google.com/gke-spot: 'true'`. A nodeSelector with this label ensures simulation Pods are scheduled only on Spot nodes.

Why this answer

Option B is correct because GKE uses the node label `cloud.google.com/gke-spot` to identify Spot VMs. Adding a `nodeSelector` with that exact key-value pair ensures the simulation Deployment is scheduled exclusively on Spot nodes, which is the intended behavior for fault-tolerant, preemptible workloads.

Exam trap

The trap here is that candidates may confuse `nodeSelector` with `podAffinity` or assume GKE uses naming conventions or resource requests to determine node pool placement, when in fact it relies on node labels and taints.

How to eliminate wrong answers

Option A is wrong because `podAffinity` influences scheduling based on pod relationships, not node types; it would not restrict pods to Spot nodes. Option C is wrong because setting high resource requests does not route pods to Spot nodes; it only affects scheduling based on available capacity, and GKE does not use resource requests to determine node pool type. Option D is wrong because GKE does not route deployments to Spot pools based on naming conventions; node selection is controlled by labels, taints, and tolerations, not prefixes.

Full explanation →

428

MCQmedium

A company is deploying a stateful application on Google Kubernetes Engine (GKE) that requires persistent storage. Each pod needs its own dedicated persistent disk that is not shared. Which Kubernetes resource should be used to manage the deployment?

A.Job with PersistentVolume

B.DaemonSet with hostPath volumes

C.Deployment with PersistentVolumeClaim template

D.StatefulSet with volumeClaimTemplates

AnswerD

StatefulSet creates unique PersistentVolumeClaims for each pod, ensuring dedicated persistent storage.

Why this answer

Option D is correct because a StatefulSet with volumeClaimTemplates is designed for stateful applications where each pod requires its own dedicated PersistentVolume (PV) that is not shared. The volumeClaimTemplates automatically generate a unique PersistentVolumeClaim (PVC) for each pod replica, ensuring each pod gets a separate, stable persistent disk that persists across rescheduling. This matches the requirement for a stateful application on GKE where pods need dedicated, non-shared storage.

Exam trap

Google Cloud often tests the distinction between Deployments and StatefulSets, and the trap here is that candidates mistakenly choose a Deployment with a PVC template, not realizing that Deployments treat all pods as interchangeable and would share the same PVC, violating the 'dedicated disk per pod' requirement.

How to eliminate wrong answers

Option A is wrong because a Job is used for batch or one-time tasks, not for managing a long-running stateful application, and a PersistentVolume alone does not provide per-pod dedicated storage without a PVC. Option B is wrong because a DaemonSet runs one pod per node, typically for cluster-level services like logging or monitoring, and hostPath volumes use the node's local filesystem, which does not provide dedicated, persistent storage that survives pod rescheduling across nodes. Option C is wrong because a Deployment with a PersistentVolumeClaim template would share the same PVC across all replicas, leading to shared storage and potential data corruption, whereas the requirement is for each pod to have its own dedicated disk.

Full explanation →

429

MCQhard

A DevOps team uses Terraform to manage GCP infrastructure and wants to store Terraform state in a shared location that all team members can access securely, with state locking to prevent concurrent modifications. Which backend configuration achieves this?

A.gcs backend storing state in a Cloud Storage bucket

B.gcp backend storing state in a BigQuery table

C.remote backend connected to a Cloud SQL database

D.local backend with a path shared over Cloud Filestore

AnswerA

The `gcs` backend stores Terraform state in a Cloud Storage bucket and supports state locking via GCS object lock, enabling safe concurrent team usage.

Why this answer

The `gcs` backend is the correct choice because it stores Terraform state in a Google Cloud Storage bucket, which provides secure, shared access via IAM policies and supports state locking natively through object versioning and write-preconditions. This ensures that only one team member can modify the state at a time, preventing conflicts and corruption.

Exam trap

The trap here is that candidates confuse the `gcp` provider (which manages GCP resources) with a backend name, or assume that any shared filesystem (like Cloud Filestore) can provide locking, ignoring that Terraform requires atomic, server-side locking which only object storage backends like `gcs` or `s3` provide natively.

How to eliminate wrong answers

Option B is wrong because BigQuery is a data warehouse for analytics, not a state storage backend; it lacks native state locking and is not designed for the atomic write operations Terraform requires. Option C is wrong because the `remote` backend in Terraform is specifically for Terraform Cloud or Terraform Enterprise, not for connecting to a Cloud SQL database, which would require custom scripting and does not support built-in state locking. Option D is wrong because the `local` backend stores state on the local filesystem; sharing a path over Cloud Filestore does not provide state locking, as NFS does not support the atomic file locks Terraform needs, leading to race conditions and state corruption.

Full explanation →

430

MCQhard

A GCP organization has 150 projects. A new security policy requires all projects to enable the Security Command Center API. What is the most efficient way to enable this API across all projects without manually visiting each project?

A.Manually enable the API in each of the 150 projects via the Cloud Console

B.Use a gcloud script to iterate over all projects and enable the API for each

C.Enable the API at the organization level — it inherits down to all projects

D.Create an organization policy enabling all APIs on all projects

AnswerB

Scripting with `gcloud projects list | xargs` or Terraform with `google_project_service` for each project enables the API across all 150 projects efficiently and repeatably.

Why this answer

Option B is correct because the gcloud command-line tool allows you to script the enabling of the Security Command Center API across all projects efficiently. Using `gcloud services enable securitycenter.googleapis.com --project=<project_id>` in a loop over the list of projects automates the task without manual intervention, leveraging the Cloud SDK's programmatic access to the Service Usage API.

Exam trap

Google Cloud often tests the misconception that organization-level settings automatically propagate API enablement to all projects, but in GCP, APIs must be explicitly enabled per project, and organization policies only enforce constraints, not service activation.

How to eliminate wrong answers

Option A is wrong because manually enabling the API in each of 150 projects via the Cloud Console is time-consuming and error-prone, contradicting the requirement for the 'most efficient' method. Option C is wrong because enabling an API at the organization level does not automatically inherit down to all projects; APIs must be enabled per project, and organization-level settings only control policies, not service enablement. Option D is wrong because organization policies cannot enable APIs; they enforce constraints (e.g., resource restrictions) via the Organization Policy Service, not service activation, and there is no policy to enable all APIs.

Full explanation →

431

MCQeasy

A GKE pod's container is frequently crashing and restarting. You need to view the logs from the previous container instance (before the last crash) to diagnose the crash cause. Which command retrieves these logs?

A.`kubectl logs POD_NAME`

B.`kubectl logs POD_NAME --previous`

C.`kubectl describe pod POD_NAME`

D.`kubectl get events --field-selector reason=OOMKilled`

AnswerB

--previous retrieves logs from the terminated previous container instance — exactly what's needed to see what happened before the crash.

Why this answer

Option B is correct because the `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container in a pod, which is exactly what you need when the current container has crashed and restarted. This allows you to see the logs that led to the crash, even though the container is now running a new instance.

Exam trap

The trap here is that candidates often confuse `kubectl logs` with `kubectl describe` or `kubectl get events`, thinking those commands provide log output, when in fact only `kubectl logs` retrieves container logs and the `--previous` flag is the specific mechanism to access logs from a crashed instance.

How to eliminate wrong answers

Option A is wrong because `kubectl logs POD_NAME` only shows logs from the currently running container instance, not from the previous crashed instance, so it would not show the crash cause. Option C is wrong because `kubectl describe pod POD_NAME` shows pod metadata, status, and events, but does not retrieve container logs; it cannot show the log output from the previous container instance. Option D is wrong because `kubectl get events --field-selector reason=OOMKilled` only filters for Out-Of-Memory kill events, which is too narrow and may miss other crash reasons; it also does not retrieve the actual container logs needed for diagnosis.

Full explanation →

432

MCQhard

An organization needs to allow a third-party SIEM tool to ingest audit logs from their Google Cloud organization. The SIEM tool should only have read access to logs. Which IAM role should be granted?

A.roles/logging.configWriter

B.roles/logging.admin

C.roles/logging.viewer

D.roles/logging.privateLogViewer

AnswerC

Provides read-only access to log entries.

Why this answer

The roles/logging.viewer role grants read-only access to all logs in the Google Cloud organization, including audit logs, which is exactly what the third-party SIEM tool requires. This role allows the SIEM to ingest logs without the ability to modify or delete them, ensuring the principle of least privilege is maintained.

Exam trap

Google Cloud often tests the distinction between roles/logging.viewer and roles/logging.privateLogViewer, where candidates mistakenly choose the latter thinking it is required for audit logs, but privateLogViewer is only needed for logs containing sensitive data like Access Transparency logs, not standard audit logs.

How to eliminate wrong answers

Option A is wrong because roles/logging.configWriter grants write access to log configurations (e.g., creating log sinks and exclusions), not read-only access to logs, and would allow the SIEM to modify logging infrastructure. Option B is wrong because roles/logging.admin provides full administrative control over logging, including the ability to delete logs and modify log buckets, which exceeds the required read-only access. Option D is wrong because roles/logging.privateLogViewer grants read access to private log entries (e.g., those containing sensitive data like Access Transparency logs), which is more permissive than needed and could expose data the SIEM should not see; the standard roles/logging.viewer is sufficient for audit logs.

Full explanation →

433

MCQmedium

A Cloud SQL instance's disk is at 95% capacity. The application is experiencing write failures. You need to resolve this immediately with no downtime. What should you do?

A.Take a snapshot of the instance, create a new larger instance from the snapshot, then update the connection string.

B.Increase the disk size via the Cloud SQL console or `gcloud sql instances patch` — this occurs with no instance restart.

C.Delete old database tables to free up space.

D.Switch the instance to SSD storage, which has higher throughput and allows more writes.

AnswerB

Cloud SQL disk increases are online operations. `gcloud sql instances patch INSTANCE --storage-size=NEW_SIZE` resizes the disk without restarting or interrupting the instance.

Why this answer

Option B is correct because Cloud SQL supports dynamic disk resizing without requiring an instance restart. When you increase the disk size via the console or `gcloud sql instances patch`, the change takes effect immediately, allowing the database to continue serving writes without downtime. This directly resolves the write failures caused by disk-full conditions.

Exam trap

The trap here is that candidates often assume any disk change requires a restart or migration, but Cloud SQL's online disk resize is a key differentiator that allows immediate resolution without downtime.

How to eliminate wrong answers

Option A is wrong because taking a snapshot and creating a new instance introduces significant downtime while the snapshot is taken, the new instance is provisioned, and the connection string is updated — violating the 'no downtime' requirement. Option C is wrong because deleting tables is a destructive, time-consuming operation that may not free enough space quickly, and it risks data loss; it also does not address the root cause of insufficient disk capacity. Option D is wrong because switching to SSD storage requires recreating the instance or migrating data, which causes downtime, and SSD does not increase disk capacity — it only improves I/O performance, so it would not resolve the disk-full write failures.

Full explanation →

434

MCQmedium

Refer to the exhibit. A user runs `gcloud compute instances list` in Cloud Shell and gets the output 'Listed 0 items.' The user expects to see the VM they just created via the Console. What is the most likely cause?

A.The VM was created in a different region

B.The Cloud Shell is in a different project

C.The VM is stopping

D.The user does not have compute.instances.list permission

AnswerB

Cloud Shell uses the configured project, which might not be the same as the Console project.

Why this answer

The `gcloud compute instances list` command lists VM instances in the currently configured project (set via `gcloud config set project`). If the Cloud Shell is pointing to a different project than the one where the VM was created via the Console, the command will return 'Listed 0 items' even though the VM exists. This is the most likely cause because the user expects to see the VM but the command is scoped to a different project context.

Exam trap

Google Cloud often tests the distinction between project-level scope and regional scope, trapping candidates who assume region mismatch is the cause when the real issue is the Cloud Shell being configured to a different project.

How to eliminate wrong answers

Option A is wrong because the `gcloud compute instances list` command by default lists instances across all regions in the current project; a region mismatch would not cause 'Listed 0 items' unless the instance was in a different project. Option C is wrong because a VM in 'stopping' state is still listed by `gcloud compute instances list` (it appears with status 'STOPPING'), so it would not result in zero items. Option D is wrong because if the user lacked `compute.instances.list` permission, the command would return a permission denied error, not 'Listed 0 items'.

Full explanation →

435

MCQmedium

Your application writes structured JSON logs to stdout from a Cloud Run service. You want to query logs in Cloud Logging to find all requests where the `user_id` field equals `12345`. Which log query syntax finds these entries?

A.`textPayload:"user_id:12345"`

B.`jsonPayload.user_id="12345"`

C.`resource.labels.user_id="12345"`

D.`labels.user_id="12345"`

AnswerB

Cloud Run parses JSON stdout as structured logs in jsonPayload. Field-level queries like jsonPayload.user_id="12345" filter log entries by specific JSON field values.

Why this answer

Option B is correct because Cloud Logging uses the `jsonPayload` field to access structured JSON fields in log entries. When your application writes structured JSON logs to stdout, Cloud Run automatically parses them and stores the fields under `jsonPayload`. The query `jsonPayload.user_id="12345"` directly matches the `user_id` field within that JSON payload.

Exam trap

Google Cloud often tests the distinction between `jsonPayload` for structured logs and `textPayload` for unstructured logs, and candidates mistakenly use `textPayload` or confuse `resource.labels` with application-level JSON fields.

How to eliminate wrong answers

Option A is wrong because `textPayload` is used for unstructured text logs, not structured JSON; the syntax `textPayload:"user_id:12345"` would search for that literal string in the text payload, not the JSON field. Option C is wrong because `resource.labels` refers to labels on the monitored resource (e.g., Cloud Run service name, revision), not the application's JSON payload fields. Option D is wrong because `labels` in Cloud Logging refer to user-defined metadata labels on the log entry itself, not the structured JSON fields from the application output.

Full explanation →

436

MCQmedium

A financial application requires a relational database with automatic failover to a standby in a different zone, with minimal configuration overhead. Which Cloud SQL configuration provides this?

A.Cloud SQL with a read replica in a different zone

B.Cloud SQL with High Availability (HA) configuration

C.Cloud Spanner multi-region instance

D.Two separate Cloud SQL instances with application-level failover logic

AnswerB

Cloud SQL HA creates an automatic failover replica in a different zone. Failover is automatic and requires no manual intervention.

Why this answer

Cloud SQL's High Availability (HA) configuration provides automatic failover to a standby instance in a different zone using synchronous replication and a regional persistent disk. This meets the requirement for minimal configuration overhead because it is a built-in feature that requires no application-level logic or manual intervention.

Exam trap

Google Cloud often tests the misconception that a read replica can serve as a failover target, but read replicas use asynchronous replication and require manual promotion, making them unsuitable for automatic failover with minimal configuration.

How to eliminate wrong answers

Option A is wrong because a read replica is designed for read scaling, not automatic failover; it requires manual promotion and does not provide synchronous replication for zero data loss. Option C is wrong because Cloud Spanner is a globally distributed, horizontally scalable database that introduces significant configuration overhead and cost, not a minimal-configuration relational database for a single-region failover requirement. Option D is wrong because managing two separate Cloud SQL instances with application-level failover logic adds significant configuration overhead and defeats the purpose of minimal configuration, as it requires custom code for health checks, replication, and failover coordination.

Full explanation →

437

MCQeasy

A small business has a single Google Cloud project with a few Compute Engine instances running a web application. The instances are all in the same VPC and subnet. The security team wants to ensure that only HTTP (port 80) and HTTPS (port 443) traffic from the public internet is allowed to the instances, and that all other inbound traffic is blocked. They have already configured Cloud Armor for the load balancer. However, they notice that SSH traffic (port 22) is still reaching the instances from the internet, even though they do not have any explicit firewall rules allowing SSH. The project was just created and uses the default VPC network. What should they do to resolve this?

A.Create a VPC firewall rule with priority 1000 to deny ingress on port 22 from 0.0.0.0/0.

B.Configure a route to drop traffic destined to the instances on port 22.

C.Remove the SSH public key from the instance metadata.

D.Disable or delete the default-allow-ssh firewall rule in the VPC.

AnswerD

This rule allows SSH from anywhere; disabling it stops SSH traffic from the internet.

Why this answer

Option B is correct because the default VPC includes a default-allow-ssh firewall rule that allows SSH traffic from any source (0.0.0.0/0) on port 22. Disabling this rule will block SSH traffic. Option A is incorrect because creating a deny rule with a lower priority does not override the existing allow rule (allow rules take precedence if a matching allow rule exists).

Option C is incorrect because removing SSH keys does not block network traffic. Option D is incorrect because routes control packet forwarding, not firewall filtering.

Full explanation →

438

MCQmedium

Refer to the exhibit. The Terraform plan above returns the error: Error: "member" is required. What is the issue?

A.The Terraform provider version is outdated.

B.The project ID is incorrect.

C.The member argument must be a service account, not a user.

D.The member argument should be 'member' (singular) not 'members'.

AnswerD

For google_project_iam_member, use 'member' attribute.

Why this answer

The Terraform error 'Error: "member" is required' indicates that the resource block is using the plural argument 'members' instead of the singular 'member'. In the Google Cloud Terraform provider, the google_project_iam_member resource expects a single 'member' argument (e.g., 'user:email@example.com'), not a list. The correct syntax is 'member = "user:email@example.com"', not 'members = ["user:email@example.com"]'.

This is a common syntax error when transitioning from other IAM resources that accept lists.

Exam trap

Google Cloud often tests the subtle difference between singular and plural argument names in Terraform resources (e.g., 'member' vs 'members'), tricking candidates who assume both forms are interchangeable or who confuse IAM member with IAM binding syntax.

How to eliminate wrong answers

Option A is wrong because an outdated provider version would typically cause deprecation warnings or missing features, not a specific error about a required argument name. Option B is wrong because an incorrect project ID would result in an error like 'project not found' or 'permission denied', not a missing 'member' argument. Option C is wrong because the 'member' argument can accept users, service accounts, groups, or domains (e.g., 'user:email', 'serviceAccount:sa@project.iam.gserviceaccount.com'); the error is about the argument name, not the value type.

Full explanation →

439

MCQmedium

Your application runs on Compute Engine instances behind a regional external HTTP(S) load balancer. Users report intermittent timeouts during periods of high traffic. Health checks show all instances as healthy. Which two configuration parameters should you review first?

A.Check SSL certificate expiration

B.Review connection draining and session affinity settings

C.Increase instance machine type (size)

D.Enable Cloud CDN

AnswerB

Connection draining timeouts and session affinity misconfigurations are common causes of intermittent timeouts under load.

Why this answer

B is correct because connection draining (drain mode) and session affinity settings directly affect how the load balancer handles in-flight requests and distributes traffic during high load. Connection draining ensures existing connections complete before an instance is removed, preventing abrupt timeouts. Session affinity (sticky sessions) can cause uneven traffic distribution if misconfigured, leading to overloaded instances and intermittent timeouts even when health checks pass.

Exam trap

Google Cloud often tests the misconception that health check status alone guarantees application availability, but candidates must understand that load balancer configuration parameters like connection draining and session affinity can cause timeouts even when all instances are healthy.

How to eliminate wrong answers

Option A is wrong because SSL certificate expiration would cause persistent TLS handshake failures, not intermittent timeouts during high traffic, and health checks would still show instances as healthy. Option C is wrong because increasing instance machine type addresses resource exhaustion on the instances themselves, but the issue is load balancer-level connection handling and traffic distribution, not compute capacity. Option D is wrong because enabling Cloud CDN caches static content at edge locations, which does not resolve intermittent timeouts caused by connection draining or session affinity misconfiguration for dynamic or stateful traffic.

Full explanation →

440

Multi-Selecthard

Which THREE options are valid methods to authenticate a service account when making calls to Google Cloud APIs from a Compute Engine instance?

Select 3 answers

A.Using a JSON key file downloaded for the service account.

B.Using a user account's OAuth2 tokens obtained via a web browser.

C.Using an API key generated from the Cloud Console.

D.Using the Compute Engine metadata server to obtain an access token for a custom service account.

E.Using the default service account's automatically provided credentials.

AnswersA, D, E

Service account key files can be used for authentication.

Why this answer

Option A is correct because a JSON key file downloaded for a service account contains the private key necessary to create a signed JWT assertion, which is exchanged for an OAuth 2.0 access token via the Google OAuth 2.0 token endpoint (https://oauth2.googleapis.com/token). This is a standard authentication method for service accounts outside of Google Cloud, but it is also valid from a Compute Engine instance, though less secure than using the metadata server.

Exam trap

Google Cloud often tests the distinction between authentication (proving identity) and authorization (granting permissions), and the trap here is that candidates mistakenly think API keys (Option C) can authenticate a service account, when in fact API keys only identify the project and are not tied to a specific identity.

Full explanation →

441

Multi-Selecthard

A company requires that all service account keys be automatically rotated every 90 days. Which two steps should the administrator take to enforce this? (Choose two.)

Select 2 answers

A.Enable the Service Account Key Rotator in the Google Cloud Console.

B.Use IAM to set a condition that keys must have an expiration date.

C.Use the Service Account API to create keys with a custom expiration time.

D.Use an Organization Policy to disable service account key creation.

E.Use a Cloud Function to monitor key age and delete keys older than 90 days.

AnswersC, E

Keys can be created with expiration in the API, enforcing rotation.

Why this answer

Option C is correct because the Service Account API allows creating keys with a custom expiration time, which enforces automatic rotation by ensuring keys are invalid after 90 days. Option E is correct because a Cloud Function can monitor key age and delete keys older than 90 days, providing a programmatic enforcement mechanism. Both approaches ensure keys are rotated automatically without manual intervention.

Exam trap

Google Cloud often tests the misconception that there is a built-in 'auto-rotate' toggle in the console, but in reality, you must use API-level expiration or custom automation like Cloud Functions to enforce rotation.

Full explanation →

442

MCQeasy

A developer needs to run an interactive shell inside a running GKE Pod named 'api-pod-7d4f9' in the 'production' namespace to investigate a runtime issue. Which kubectl command opens an interactive shell?

A.kubectl ssh api-pod-7d4f9 -n production

B.kubectl exec -it api-pod-7d4f9 -n production -- /bin/bash

C.kubectl run debug --image=busybox --attach=api-pod-7d4f9

D.gcloud container exec api-pod-7d4f9 --namespace=production -- bash

AnswerB

This command opens an interactive bash shell in the Pod. `-i` keeps stdin open, `-t` allocates a pseudo-TTY, `-n production` targets the correct namespace.

Why this answer

Option B is correct because `kubectl exec -it` attaches an interactive terminal to a running container in a Pod, with `-i` for stdin and `-t` for a TTY. The `-- /bin/bash` launches a Bash shell inside the container, allowing the developer to investigate runtime issues. This is the standard Kubernetes method for interactive shell access.

Exam trap

Google Cloud often tests the distinction between `kubectl exec` (for existing containers) and `kubectl run` (for creating new Pods), and candidates mistakenly choose options that use non-existent commands like `kubectl ssh` or `gcloud container exec`.

How to eliminate wrong answers

Option A is wrong because `kubectl ssh` is not a valid kubectl command; Kubernetes does not use SSH for container access, and this would fail. Option C is wrong because `kubectl run debug --image=busybox --attach=api-pod-7d4f9` creates a new Pod named 'debug' rather than attaching to the existing 'api-pod-7d4f9', and the `--attach` flag is misused (it attaches to the new Pod's logs, not the target Pod). Option D is wrong because `gcloud container exec` is not a valid gcloud command; the correct gcloud command for exec access is `gcloud container clusters get-credentials` followed by `kubectl exec`, and the syntax shown is incorrect.

Full explanation →

443

MCQmedium

A team is migrating from Google Container Registry (gcr.io) to Artifact Registry. Existing automation scripts use `gcr.io/my-project/myimage`. To avoid updating all scripts immediately, which Artifact Registry feature allows gcr.io-addressed pulls to work with Artifact Registry backends?

A.Artifact Registry has no gcr.io compatibility — all scripts must be updated immediately

B.Enable the gcr.io compatibility redirect in Artifact Registry settings so gcr.io URLs route to Artifact Registry

C.Use a Cloud DNS private zone to redirect gcr.io to Artifact Registry

D.Both Container Registry and Artifact Registry can be active simultaneously with no configuration

AnswerB

Artifact Registry supports a gcr.io compatibility mode where requests to gcr.io/[PROJECT]/[IMAGE] are served from Artifact Registry — allowing gradual script migration.

Why this answer

Option B is correct because Artifact Registry offers a gcr.io compatibility redirect feature that automatically routes requests originally targeting `gcr.io/my-project/myimage` to the corresponding Artifact Registry repository. This allows existing automation scripts to continue using the old `gcr.io` hostname without modification, while the underlying storage and image management are handled by Artifact Registry. The redirect is configured at the project level and works transparently for pull operations, eliminating the need for immediate script updates.

Exam trap

Google Cloud often tests the misconception that DNS manipulation (like Cloud DNS private zones) can solve hostname redirection for external services, but in reality, Google-managed hostnames like `gcr.io` cannot be overridden with private DNS, and the correct solution is the built-in Artifact Registry redirect feature.

How to eliminate wrong answers

Option A is wrong because Artifact Registry does provide gcr.io compatibility via a redirect feature, so scripts do not need to be updated immediately. Option C is wrong because Cloud DNS private zones cannot redirect external hostnames like `gcr.io` to Artifact Registry; DNS resolution for `gcr.io` is managed by Google and cannot be overridden with private zones, and this approach would not handle the authentication or routing required for container pulls. Option D is wrong because while both registries can be active simultaneously, no configuration is needed only if you manually push images to both; the gcr.io compatibility redirect specifically requires enabling the feature to make `gcr.io` pulls work with Artifact Registry backends without script changes.

Full explanation →

444

MCQmedium

A company wants to ensure that all IAM users in a project must use two-factor authentication. Which Google Cloud service should be used?

A.Cloud Identity

B.Identity Platform

C.Cloud IAM

D.Cloud Audit Logs

AnswerA

Cloud Identity provides user management and security policies like 2SV.

Why this answer

Cloud Identity is the correct service because it provides identity-as-a-service (IDaaS) that allows administrators to enforce security policies, including requiring two-factor authentication (2FA) for all IAM users. By enabling 2FA at the Cloud Identity level, every user authenticating through Google Cloud's identity layer must complete a second factor (e.g., TOTP via Google Authenticator or a security key) before accessing any Google Cloud resources. This policy applies globally across all projects in the organization, ensuring consistent enforcement without needing to configure per-user or per-project settings.

Exam trap

The trap here is that candidates confuse Cloud IAM (which handles authorization) with Cloud Identity (which handles authentication and MFA enforcement), leading them to incorrectly select Cloud IAM because they think 'IAM' covers all identity-related settings.

How to eliminate wrong answers

Option B is wrong because Identity Platform is a customer-facing authentication service for applications (e.g., adding sign-in to a web app), not for enforcing 2FA on internal IAM users accessing Google Cloud resources. Option C is wrong because Cloud IAM manages permissions (who has access to what) but does not handle authentication methods or enforce multi-factor authentication policies. Option D is wrong because Cloud Audit Logs records who did what and when, but it cannot enforce or require two-factor authentication; it is a logging and monitoring service, not an identity or policy enforcement service.

Full explanation →

445

MCQmedium

An application running on a Compute Engine VM needs to read objects from a Cloud Storage bucket in the same project. What is the recommended authentication approach?

A.Embed a developer's user account credentials in the application configuration file

B.Attach a service account with the Storage Object Viewer role to the VM

C.Create an API key and store it as an environment variable on the VM

D.Grant the VM's IP address access to the bucket using a VPC firewall rule

AnswerB

Service accounts attached to VMs allow applications to authenticate automatically via the metadata server. This eliminates the need to manage credentials directly.

Why this answer

Option B is correct because attaching a service account with the Storage Object Viewer role to the Compute Engine VM is the recommended and secure method for authenticating to Cloud Storage. The VM automatically obtains OAuth 2.0 access tokens for the service account via the metadata server, eliminating the need to manage or embed credentials in the application code.

Exam trap

Google Cloud often tests the misconception that API keys or IP-based firewall rules can control access to Cloud Storage, when in fact Cloud Storage relies solely on IAM roles and OAuth 2.0 tokens for authentication and authorization.

How to eliminate wrong answers

Option A is wrong because embedding a developer's user account credentials in a configuration file violates security best practices, exposes long-lived credentials, and ties the application to an individual user's permissions rather than a dedicated identity. Option C is wrong because API keys are not designed for authenticating as a specific identity; they identify the project making the call, not the caller, and lack the granular access control of IAM roles, making them unsuitable for accessing Cloud Storage objects. Option D is wrong because VPC firewall rules control network traffic at the IP/port level, not access to Cloud Storage objects; Cloud Storage uses IAM permissions for object-level access, and IP-based access control is not supported for bucket operations.

Full explanation →

446

MCQmedium

A startup processes uploaded videos — each video upload triggers transcoding that takes 5–30 minutes. Users should get an immediate response after upload, not wait for transcoding. The transcoding system must handle burst uploads. Which architecture fits?

A.Upload the video and synchronously wait for transcoding to complete before responding

B.Publish a transcoding job to Cloud Pub/Sub after upload; respond immediately; workers consume and process jobs asynchronously

C.Use Cloud Spanner to store video metadata and transcode synchronously in a Cloud SQL stored procedure

D.Deploy the transcoding directly in the API server and scale the API server horizontally for bursts

AnswerB

The user gets an instant acknowledgment. Cloud Pub/Sub buffers the jobs. Autoscaling workers consume messages and transcode — decoupled, scalable, and burst-tolerant.

Why this answer

Option B is correct because it decouples the upload from the transcoding process using Cloud Pub/Sub, allowing the API to respond immediately to the user while workers asynchronously process the transcoding jobs. This pattern handles burst uploads by buffering messages in Pub/Sub and scaling workers independently, ensuring no upload is lost even under high load.

Exam trap

Google Cloud often tests the misconception that synchronous processing or scaling the API server alone can handle long-running tasks, but the trap here is that immediate response and burst handling require asynchronous decoupling via a message queue like Pub/Sub, not just horizontal scaling.

How to eliminate wrong answers

Option A is wrong because synchronous waiting for transcoding (5–30 minutes) would block the HTTP response, violating the requirement for an immediate user response and causing timeouts or poor user experience. Option C is wrong because Cloud Spanner is a globally distributed relational database, not a transcoding engine, and running transcoding synchronously in a Cloud SQL stored procedure is impossible—stored procedures cannot perform video processing tasks. Option D is wrong because deploying transcoding directly in the API server would block the request thread for minutes, preventing horizontal scaling from solving the burst issue (each instance would still be tied up per upload), and it couples compute-intensive work with the stateless API layer.

Full explanation →

447

MCQmedium

A developer is running a batch process on a Compute Engine instance that needs to write logs to Cloud Logging. The instance uses the default Compute Engine service account. What must be done?

A.Ensure the instance's access scopes include logging.write

B.No action needed, the default service account has logging write access

C.Create a custom service account with the required roles

D.Add the Logging Admin role to the service account

AnswerA

Access scopes limit API access; logging.write scope must be set.

Why this answer

The default Compute Engine service account has the `logging.logWriter` role by default, but access scopes act as an additional permission layer on Compute Engine instances. Even if the IAM role is present, the instance must have the `logging.write` access scope enabled to allow the service account to write logs to Cloud Logging. Option A is correct because explicitly setting the access scope ensures the API call to `logging.write` is permitted at the instance level.

Exam trap

Google Cloud often tests the distinction between IAM roles and access scopes, trapping candidates who assume that having the correct IAM role alone is sufficient for a Compute Engine instance to call an API.

How to eliminate wrong answers

Option B is wrong because while the default service account has the `logging.logWriter` IAM role, the instance's access scopes must also include `logging.write`; without it, the API call is blocked at the instance metadata level. Option C is wrong because creating a custom service account is unnecessary—the default service account already has the required IAM role, and the issue is solely about access scopes. Option D is wrong because adding the Logging Admin role (`roles/logging.admin`) grants excessive permissions (e.g., deleting logs) and does not address the access scope restriction; the `logging.logWriter` role is sufficient and already assigned.

Full explanation →

448

MCQmedium

A monitoring alert fires at 3 AM — the team's GKE Pods are being evicted. Investigation shows node memory is at 98%. Pods without resource requests are being evicted first. What is the long-term fix to prevent evictions?

A.Set higher memory limits on the Pods being evicted

B.Add explicit memory requests (and optionally limits) to all Pod specs

C.Disable node-level eviction by modifying kubelet configuration

D.Add more nodes to the cluster to increase available memory

AnswerB

Pods without requests have BestEffort QoS and are evicted first. Setting memory requests elevates Pods to Burstable QoS. Matching requests and limits creates Guaranteed QoS — the most eviction-resistant class.

Why this answer

B is correct because setting explicit memory requests ensures the Kubernetes scheduler can accurately place Pods on nodes with sufficient resources, preventing the node from being overcommitted. Without requests, Pods are treated as burstable or best-effort, making them the first candidates for eviction under the kubelet's Quality of Service (QoS) classes when node memory pressure hits 98%. This is a long-term fix because it enforces proper resource governance at the scheduling level, not just a reactive measure.

Exam trap

Google Cloud often tests the misconception that raising limits or adding capacity is the fix, but the real issue is the absence of requests, which prevents the scheduler from making informed placement decisions and leaves Pods in the lowest QoS class.

How to eliminate wrong answers

Option A is wrong because raising memory limits without adjusting requests does not improve scheduling accuracy; limits only cap usage, but the Pod still lacks a guaranteed reservation, so it remains in a lower QoS class and is still evicted first under pressure. Option C is wrong because disabling kubelet eviction (via --eviction-hard or --eviction-soft flags) would allow the node to run out of memory entirely, leading to system OOM kills or node instability, which is not a valid long-term fix. Option D is wrong because adding nodes only distributes the load temporarily; without requests, new Pods will still be placed without guarantees, and the same eviction pattern will recur on any node under memory pressure.

Full explanation →

449

Multi-Selectmedium

A company uses Cloud Armor to protect an HTTP Load Balancer. They want to allow traffic only from specific IP ranges (198.51.100.0/24 and 203.0.113.0/24) and block common web attacks like SQL injection and XSS. Which TWO actions should they take?

Select 2 answers

A.Set up Cloud NAT to provide outbound internet access for the instances.

B.Configure VPC firewall rules on the subnet to allow only the IP ranges.

C.Enable predefined WAF rules (e.g., OWASP Top 10) in the Cloud Armor security policy.

D.Create a Cloud Armor security policy with an allow rule for the IP ranges and a default deny rule for all other traffic.

E.Enable Cloud CDN to cache static content from the backend.

AnswersC, D

WAF rules block common web attacks like SQL injection and XSS.

Why this answer

Option A creates a security policy with an allow rule for the IP ranges and a deny rule for all other traffic, which is necessary to restrict access. Option C enables WAF rules in Cloud Armor, which blocks common web attacks. Option B (Cloud CDN caching) does not affect access control.

Option D (VPC firewall rules at instance level) is not relevant because Cloud Armor works at the load balancer. Option E (Cloud NAT) is for outbound traffic, not inbound security.

Full explanation →

450

MCQmedium

A developer has an App Engine Standard application ready to deploy. The app.yaml file is in the current working directory. Which command deploys the application?

A.gcloud app create --config=app.yaml

B.gcloud app deploy

C.gcloud appengine deploy app.yaml

D.gcloud run deploy --platform=appengine

AnswerB

`gcloud app deploy` reads the app.yaml in the current directory, builds the application, and deploys it to App Engine Standard.

Why this answer

The `gcloud app deploy` command is the correct way to deploy an App Engine Standard application when the `app.yaml` file is present in the current working directory. This command automatically detects the configuration file and uploads the application code to the specified App Engine service, handling the deployment process including staging, versioning, and traffic migration.

Exam trap

The trap here is that candidates confuse `gcloud app deploy` with `gcloud app create` or Cloud Run commands, or they misremember the exact subcommand syntax, leading them to choose invalid options like `gcloud appengine deploy`.

How to eliminate wrong answers

Option A is wrong because `gcloud app create` is used to create a new App Engine application (project) in a region, not to deploy code; it does not accept a `--config` flag for deployment. Option C is wrong because `gcloud appengine deploy` is not a valid gcloud command; the correct subcommand is `gcloud app deploy`, and the syntax `app.yaml` as an argument is not required when it is in the current directory. Option D is wrong because `gcloud run deploy` is used for Cloud Run services, not App Engine; the `--platform=appengine` flag is invalid as Cloud Run does not support that platform.

Full explanation →

Google Associate Cloud Engineer (ACE) — Questions 376–450