Google Associate Cloud Engineer ACE Questions 226–300 | Page 4/11

226

Multi-Selectmedium

A team is deploying a stateful application on GKE that requires each pod to have its own persistent disk. Which TWO Kubernetes resources are essential for this deployment? (Choose two.)

Select 2 answers

A.Deployment

B.ConfigMap

C.StatefulSet

D.Ingress

E.PersistentVolumeClaim (PVC)

AnswersC, E

StatefulSet is the correct workload API for stateful applications on GKE. It gives each pod a stable, unique network identity (e.g., `database-0`, `database-1`) and, via `volumeClaimTemplate`, provisions a dedicated PersistentVolume and PVC for each replica. Pods are created and scaled in ordinal order, ensuring predictable startup/shutdown sequences. This is ideal for databases, message brokers, and other apps that need sticky identity and per-pod persistent storage.

Why this answer

A StatefulSet is essential because it provides stable, unique network identifiers and ordered, graceful deployment and scaling for stateful applications, ensuring each pod maintains its identity and persistent storage binding across rescheduling. A PersistentVolumeClaim (PVC) is required to request and bind a persistent disk to each pod, enabling the pod to retain its data independently of other pods in the set.

Exam trap

Google Cloud often tests the misconception that a Deployment can handle stateful workloads with persistent storage, but the trap is that a Deployment does not guarantee stable pod identities or ordered PVC binding, causing data loss or identity conflicts when pods are rescheduled.

Full explanation →

227

MCQeasy

You are using Cloud Shell and need to access a file you created two weeks ago. What is the persistence behavior of Cloud Shell home directories?

A.Cloud Shell home directories are stored in Cloud Storage and are always available.

B.Cloud Shell home directories persist for 30 days after last use.

C.Cloud Shell home directories are temporary and are deleted after each session.

D.Cloud Shell home directories persist across sessions, with 5 GB of storage.

AnswerD

Cloud Shell provides each user with a persistent 5 GB home directory stored on a zonal persistent disk that is independent of the underlying compute instance. Because it is not tied to the VM's lifecycle, files you create remain available across all future Cloud Shell sessions, making it a reliable place to keep small scripts or configuration files.

Why this answer

Cloud Shell home directories are persistent across sessions and provide 5 GB of storage per user. This means files created in the home directory remain available even after the session ends, as long as the user's Cloud Shell environment is not deleted. The 5 GB limit is a key characteristic of Cloud Shell's persistent storage.

Exam trap

ACE often tests the specific persistence duration and storage limit of Cloud Shell home directories, and candidates may incorrectly assume they are temporary or have a different retention period.

How to eliminate wrong answers

Option A is wrong because while Cloud Shell home directories are backed by Cloud Storage, they are not 'always available' in the sense of being accessible without a Cloud Shell session; they are tied to the user's Cloud Shell environment. Option B is wrong because the persistence is not limited to 30 days after last use; the home directory persists until the user deletes it or the environment is reset. Option C is wrong because home directories are not temporary and are not deleted after each session; they persist across sessions.

Full explanation →

228

MCQhard

You are deploying a Cloud Run service revision that should initially receive 0% of traffic (for testing via a direct URL), while the existing revision continues to serve 100% of production traffic. Which `gcloud run deploy` flag achieves this?

A.`--no-traffic`

B.`--traffic=0`

C.`--revision-suffix=canary` with no traffic configuration

D.`--min-instances=0 --max-instances=0`

AnswerA

--no-traffic deploys the new revision while setting its traffic share to 0%, leaving the current live revision (or existing traffic split) untouched. The deploy creates an immutable revision with a unique URL that can trigger the revision in isolation, enabling you to test the new code with production settings and dependencies before promoting it. This is the standard pattern for safe canary or blue/green deployment on Cloud Run.

Why this answer

The `--no-traffic` flag on `gcloud run deploy` deploys a new revision but directs 0% of traffic to it, leaving the existing revision serving 100% of production traffic. This allows you to test the new revision via its direct URL without impacting live users. It is the correct and explicit way to achieve a zero-traffic deployment in Cloud Run.

Exam trap

The trap here is that candidates confuse traffic routing with instance scaling, assuming `--min-instances=0` or a bare `--traffic=0` would prevent traffic, when in fact Cloud Run requires explicit traffic management via `--no-traffic` or the `--traffic` flag with a revision identifier.

How to eliminate wrong answers

Option B is wrong because `--traffic=0` is not a valid flag; `gcloud run deploy` uses `--no-traffic` or `--traffic` with a revision name and percentage (e.g., `--traffic=new-revision=0`) but not a bare `=0`. Option C is wrong because `--revision-suffix=canary` only names the revision; without a traffic flag, the new revision automatically receives 100% of traffic by default, defeating the requirement. Option D is wrong because `--min-instances=0 --max-instances=0` controls instance scaling (allowing zero idle instances) but does not affect traffic routing; the new revision would still receive traffic unless explicitly prevented.

Full explanation →

229

MCQeasy

You want to receive notifications when a specific metric exceeds a threshold. Which Cloud Monitoring resource defines the condition and the action?

A.Alerting policy

B.Dashboard

C.Uptime check

D.Notification channel

AnswerA

An alerting policy is the correct resource in Google Cloud Monitoring for triggering notifications based on a specific metric condition. It contains one or more conditions (e.g., metric crosses a threshold for a set duration) and references a notification channel to deliver the alert. Without an alerting policy, no metric evaluation or notification can occur.

Why this answer

An alerting policy defines conditions (metric threshold) and notification channels.

Full explanation →

230

MCQmedium

A GKE Deployment runs a web application with 6 replicas across a 3-node cluster. To ensure no two replicas land on the same node (maximizing availability), which Pod spec configuration should be applied?

A.Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

B.Set podAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

C.Set topologySpreadConstraints with maxSkew: 1 and topologyKey: kubernetes.io/hostname

D.Set nodeSelector to a specific node for each replica

AnswerA

This creates a hard (required) anti-affinity rule that tells the scheduler: do not place a Pod on a node where a Pod matching the same selector already runs. Using topologyKey: kubernetes.io/hostname scopes that check to individual nodes, so the scheduler will only place one replica per node, even as nodes are added or removed. Because the rule is in the Pod spec, it is dynamic and self-managing, unlike manual node pinning. This is the standard declarative approach for achieving strict per-node exclusivity.

Why this answer

`podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` and `topologyKey: kubernetes.io/hostname` forces the scheduler to place each replica on a different node. This ensures that no two pods of the same Deployment run on the same Kubernetes node, maximizing availability by preventing a single node failure from taking down more than one replica.

Exam trap

Google Cloud often tests the distinction between `podAffinity` and `podAntiAffinity` — the trap here is that candidates confuse the two, or assume `topologySpreadConstraints` provides the same hard guarantee as anti-affinity, when it only enforces even distribution, not strict separation.

How to eliminate wrong answers

Option B is wrong because `podAffinity` attracts pods to the same node, which would cause replicas to co-locate, reducing availability. Option C is wrong because `topologySpreadConstraints` with `maxSkew: 1` distributes pods evenly across nodes but does not guarantee that no two replicas land on the same node; it only ensures a balanced distribution, which could still allow multiple replicas on one node if the cluster has fewer nodes than replicas. Option D is wrong because setting `nodeSelector` to a specific node for each replica is not dynamic and would require manual management; it also cannot guarantee anti-affinity across all replicas without complex scripting, and it violates the declarative nature of Kubernetes scheduling.

Full explanation →

231

MCQmedium

A company has multiple Google Cloud projects and wants to track costs by department. They have already applied labels to resources with key 'department'. What is the next step to view costs grouped by department?

A.Run gcloud billing accounts list and parse the output

B.Set up a budget alert with department labels

C.Enable billing export to BigQuery and run a query

D.Go to Billing > Reports and filter by 'department' label

AnswerD

The Cloud Billing Reports page provides a native console view of cost data and includes filtering by labels such as 'department'. Once you select the appropriate time range and filter by the 'department' label, the report dynamically groups costs by that label, giving you the required department-level breakdown instantly and without any additional configuration. This is the correct and most direct tool for this task.

Why this answer

Google Cloud Billing Reports natively supports grouping and filtering by resource labels, so once resources are labeled with the 'department' key, the next step is simply to open Billing > Reports and filter/group by that label. This provides an immediate, no-setup way to view cost breakdowns by department. No export or CLI parsing is required for this basic reporting need.

Exam trap

The trap here is assuming that viewing costs by label requires BigQuery export or a budget alert, when the built-in Billing Reports UI already supports label-based grouping with zero configuration.

How to eliminate wrong answers

Option A is wrong because 'gcloud billing accounts list' only enumerates billing accounts associated with the user — it returns account IDs and names, not cost data, and cannot group costs by label. Option B is wrong because budget alerts only notify when spending crosses thresholds; they do not produce grouped cost views by department. Option C is wrong because BigQuery billing export is an advanced analytics path that requires setup and is unnecessary when the built-in Reports UI already supports label filtering.

Full explanation →

232

MCQeasy

Refer to the exhibit. A developer tries to create a new project using the command `gcloud projects create my-project --name="My Project"` and receives the error 'Project ID my-project already exists.' What should the developer do?

A.Enable the Cloud Resource Manager API

B.Use a different project ID

C.Delete the existing project with the same ID

D.Use the --organization flag

AnswerB

Project IDs are globally unique across all of Google Cloud, so `my-project` is already claimed by another organisation and can never be reused. Supplying a different, unused ID satisfies that global uniqueness constraint, while the display name may remain "My Project" since names need not be unique.

Why this answer

The error indicates that the project ID 'my-project' is already taken globally. Project IDs must be unique across all of Google Cloud. The developer should choose a different project ID that is not in use.

Exam trap

The trap is confusing project ID with project name; candidates might think the --name flag can be used to avoid the conflict, but the ID must be unique regardless of the name.

How to eliminate wrong answers

Option A is wrong because enabling the Cloud Resource Manager API is not related to the error; the API is likely already enabled if the command is being processed. Option C is wrong because deleting the existing project is not advisable and may not be possible if the developer lacks permissions; also, project IDs are not immediately reusable after deletion. Option D is wrong because using the --organization flag does not resolve the uniqueness conflict; it only specifies the organization under which to create the project.

Full explanation →

233

MCQmedium

A Cloud Storage bucket contains sensitive PII data. You need to ensure that objects in this bucket are encrypted using a key that your security team controls, and that the key can be revoked if needed to render all data inaccessible. Which encryption option should you use?

A.Use Google-managed encryption keys (default).

B.Configure Customer-Managed Encryption Keys (CMEK) using Cloud KMS.

C.Enable Cloud Storage's built-in server-side encryption with AES-256.

D.Use Customer-Supplied Encryption Keys (CSEK) by embedding the key in each API request.

AnswerB

CMEK with Cloud KMS is the correct choice because it lets your security team directly manage the full lifecycle of the encryption key — creating it in a dedicated key ring, rotating it on a schedule, setting IAM permissions for who can use or manage it, and most importantly disabling or destroying it. Disabling the key immediately blocks all access to data encrypted under it (cryptographic shredding) without waiting for storage deletion, and every use of the key is recorded in Cloud Audit Logs. This gives auditors a clear, independent chain of custody over the encryption material, which satisfies internal security requirements that Google-managed keys cannot.

Why this answer

Customer-Managed Encryption Keys (CMEK) allow you to control and manage the key used for encrypting Cloud Storage objects via Cloud KMS. This enables key revocation, which immediately renders all data encrypted with that key inaccessible, meeting the security team's requirement for revocable control.

Exam trap

Google Cloud often tests the distinction between CMEK and CSEK, where candidates mistakenly choose CSEK thinking it gives more control, but CMEK is the only option that supports centralized key revocation without changing API call patterns.

How to eliminate wrong answers

Option A is wrong because Google-managed encryption keys (default) are controlled by Google, not your security team, and cannot be revoked by you. Option C is wrong because Cloud Storage's built-in server-side encryption with AES-256 is also Google-managed and does not provide customer-controlled key revocation. Option D is wrong because Customer-Supplied Encryption Keys (CSEK) require embedding the key in each API request, which does not allow centralized key management or revocation; the key is supplied per operation and not stored or managed by Cloud KMS.

Full explanation →

234

MCQmedium

Your GKE application's pods are being evicted frequently during periods of high traffic. You notice that pods without resource requests are being evicted first. The nodes are running at ~85% memory utilization. What should you do to reduce pod eviction?

A.Set memory requests and limits for all pods to match their actual memory usage.

B.Increase the node machine type to have more memory.

C.Configure pod disruption budgets (PDBs) to prevent eviction.

D.Enable cluster autoscaler to add nodes before memory pressure occurs.

AnswerA

Setting memory requests (and limits equal to requests) for every pod converts them from BestEffort or Burstable QoS to Guaranteed QoS, which places them last in the kubelet eviction order when memory pressure occurs. Requests also inform the scheduler, allowing it to place pods on nodes based on actual memory footprint, reducing the chance of overcommitting a node and triggering pressure in the first place. This directly fixes the root cause because it ensures every pod signals its memory needs and gets the appropriate eviction priority.

Why this answer

Setting memory requests and limits for all pods to match their actual memory usage ensures that the Kubernetes scheduler can accurately allocate resources and make informed scheduling decisions. Without requests, pods are treated as BestEffort QoS class, making them the first candidates for eviction under memory pressure (when nodes exceed ~85% utilization). By defining requests, pods are classified as Burstable or Guaranteed, which gives them higher priority during eviction and prevents unnecessary disruptions.

Exam trap

Google Cloud often tests the misconception that increasing node resources or adding nodes (autoscaling) solves eviction, when the real issue is the lack of resource requests that determines eviction priority under memory pressure.

How to eliminate wrong answers

Option B is wrong because simply increasing node memory does not address the root cause—pods without requests are still BestEffort and will be evicted first under any memory pressure, regardless of total node capacity. Option C is wrong because PodDisruptionBudgets (PDBs) only protect against voluntary disruptions (e.g., node drains), not involuntary evictions caused by node memory pressure (kubelet eviction). Option D is wrong because Cluster Autoscaler adds nodes only when pods are unschedulable due to resource shortages, not to prevent eviction of already-running pods; memory pressure eviction occurs before autoscaling can react.

Full explanation →

235

MCQhard

An organization is deploying a stateful application on Google Kubernetes Engine (GKE). The application requires persistent storage with high read/write performance and must be available across multiple zones for disaster recovery. Which storage solution should they use?

A.Cloud Filestore

B.Regional persistent disk

C.Local SSD

D.Zonal persistent disk

AnswerB

Regional persistent disks are block storage volumes that synchronously replicate data across two zones within a region, providing a multi-zone failure domain while maintaining high performance and low latency. They attach directly to Compute Engine VMs as boot or data disks, ensuring durable, consistent storage for stateful applications. This combination of performance and zone-redundant replication makes them the ideal choice for a stateful app that needs both high IOPS and disaster recovery without relying on manual snapshot restoration.

Why this answer

Regional persistent disks provide synchronous replication across two zones in the same region, ensuring data availability during a zonal failure. They offer high read/write performance suitable for stateful applications and can be attached to GKE pods via PersistentVolumeClaims, meeting the requirement for multi-zone disaster recovery.

Exam trap

Google Cloud often tests the distinction between zonal and regional persistent disks, where candidates mistakenly choose zonal disks for high performance without considering the multi-zone disaster recovery requirement, or they confuse Cloud Filestore's shared file access with the block storage performance needed for stateful applications.

How to eliminate wrong answers

Option A is wrong because Cloud Filestore is a managed NFS file server designed for shared file storage, not block storage, and its performance is lower than persistent disks for high-throughput workloads; it also introduces network latency. Option C is wrong because Local SSDs are ephemeral and tied to a single node, so data is lost if the node or pod is rescheduled, making them unsuitable for stateful applications requiring persistence across zones. Option D is wrong because Zonal persistent disks are confined to a single zone and cannot survive a zonal outage, failing the disaster recovery requirement for multi-zone availability.

Full explanation →

236

MCQmedium

You need to ensure that Cloud DLP scans all data uploaded to a specific Cloud Storage bucket and redacts any Social Security Numbers (SSNs) before storing the data. Which Cloud DLP feature and trigger enables this pattern?

A.Enable Cloud DLP auto-redaction on the Cloud Storage bucket via the GCS settings.

B.Configure Pub/Sub notifications on the bucket to trigger a Cloud Function that calls Cloud DLP to redact SSNs before the file is readable.

C.Use Cloud DLP's scheduled inspection job to scan the bucket daily and flag SSNs.

D.Apply an org policy that prevents storing SSNs in Cloud Storage.

AnswerB

This is correct because the standard event-driven pattern is to create a Pub/Sub topic, enable bucket notifications for OBJECT_FINALIZE events, and use a Cloud Function to call Cloud DLP's content inspection/de-identification API. The function applies an InspectConfig with the US_SOCIAL_SECURITY_NUMBER infoType and a DeidentifyConfig with a redaction transformation, then writes the redacted object, optionally deleting or quarantining the original. This runs synchronously upon object creation, ensuring the file is not publicly readable until PII is removed.

Why this answer

Cloud DLP cannot directly intercept and redact data at the point of upload to Cloud Storage. Instead, you must use Pub/Sub notifications on the bucket to trigger a Cloud Function, which calls the Cloud DLP API to inspect and redact SSNs before the file is stored or made readable. This pattern ensures redaction happens in near real-time as part of the upload pipeline.

Exam trap

Google Cloud often tests the misconception that Cloud DLP can be directly attached to a Cloud Storage bucket for automatic redaction, but in reality, you must orchestrate the inspection and redaction via an event-driven compute service like Cloud Functions.

How to eliminate wrong answers

Option A is wrong because Cloud Storage does not have a native 'auto-redaction' setting; Cloud DLP cannot be directly enabled on a bucket via GCS settings to perform real-time redaction. Option C is wrong because a scheduled inspection job only scans existing data periodically and does not redact data in real-time as it is uploaded, leaving a window where SSNs could be exposed. Option D is wrong because org policies cannot inspect or redact content within files; they only enforce structural constraints (e.g., location, encryption) and cannot prevent the storage of specific data patterns like SSNs.

Full explanation →

237

MCQeasy

You want to deploy a Cloud Function triggered by HTTP requests. The function is written in Node.js and the entry point function is named 'helloHttp'. Which command should you use?

A.gcloud functions deploy my-function --runtime nodejs16 --trigger-http --entry-point=helloHttp --region=us-central1

B.gcloud functions deploy --source . --runtime nodejs16 --trigger-http --entry-point=helloHttp

C.gcloud run deploy my-function --source . --runtime nodejs16 --entry-point=helloHttp

D.gcloud functions deploy my-function --runtime nodejs16 --trigger-topic my-topic --entry-point=helloHttp

AnswerA

This command is correct because it explicitly provides the required function name (`my-function`), specifies the Node.js 16 runtime, sets `--trigger-http` to create an HTTP-triggered Cloud Function, names the entry point (`helloHttp`) that matches the exported function in your source code, and pins the region (`us-central1`) to avoid ambiguity. In Cloud Functions, `--trigger-http` creates a public HTTPS endpoint and deploys the function to the specified location, making this the complete and valid invocation.

Why this answer

The correct command uses `gcloud functions deploy` with the required positional NAME argument (`my-function`), specifies `--runtime nodejs16`, uses `--trigger-http` for an HTTP-triggered function, and sets `--entry-point=helloHttp` to match the exported Node.js function name. The `--region` flag is also valid and commonly required for deterministic deployment. This combination satisfies all requirements stated in the question.

Exam trap

ACE often tests whether candidates confuse Cloud Functions and Cloud Run commands, or forget that `gcloud functions deploy` requires a NAME positional argument before any flags.

How to eliminate wrong answers

Option B is wrong because it omits the required function NAME positional argument, which `gcloud functions deploy` requires (the command syntax is `gcloud functions deploy NAME --runtime=...`); without a name the command fails. Option C is wrong because `gcloud run deploy` deploys to Cloud Run, not Cloud Functions, and Cloud Run does not accept `--runtime` or `--entry-point` flags in that form. Option D is wrong because `--trigger-topic my-topic` configures a Pub/Sub trigger, not an HTTP trigger, contradicting the requirement for HTTP invocation.

Full explanation →

238

MCQmedium

You are a new associate cloud engineer at a company that uses Google Cloud. You have been asked to set up a new project for a development team. Your manager wants you to ensure that the project is created under the correct organization node and that the team can immediately start using Compute Engine. You have been granted the Project Creator role at the organization level. What should you do first?

A.Run `gcloud projects create PROJECT_ID --organization=ORGANIZATION_ID`.

B.Run `gcloud projects create PROJECT_ID` without specifying an organization.

C.Run `gcloud beta projects create PROJECT_ID --organization=ORGANIZATION_ID`.

D.Run `gcloud projects create PROJECT_ID --folder=FOLDER_ID`.

AnswerA

This command creates a new project under the specified organization. The Project Creator role allows you to create projects, and specifying the organization ensures it is placed correctly. After creation, you can grant the team the necessary IAM roles and enable the Compute Engine API.

Why this answer

The correct command is `gcloud projects create` with the `--organization` flag to ensure the project is created under the correct organization. This satisfies the manager's requirement. After creation, you would need to enable the Compute Engine API and grant appropriate IAM roles to the team.

Exam trap

The trap here is assuming that creating a project without specifying an organization will automatically place it correctly, but it may default to a different organization or fail if multiple exist.

Full explanation →

239

MCQmedium

A company wants to use Customer-Managed Encryption Keys (CMEK) for a Cloud SQL instance. What must be done first?

A.Create a bucket and upload a key file.

B.Create a Cloud KMS key ring and key, and grant the Cloud SQL service account the cloudkms.cryptoKeyEncrypterDecrypter role.

C.Enable Cloud KMS API and use default encryption.

D.Set the --disk-encryption-key flag to an existing key in Cloud KMS.

AnswerB

This is the correct prerequisite for enabling CMEK on a Cloud SQL instance. You must create a key ring and a crypto key in Cloud KMS, then grant the Cloud SQL service account (e.g., service-<project>@gcp-sa-cloudsql.iam.gserviceaccount.com) the cloudkms.cryptoKeyEncrypterDecrypter role. That IAM binding lets Cloud SQL call Cloud KMS to encrypt and decrypt the data encryption keys used to protect the instance.

Why this answer

To use Customer-Managed Encryption Keys (CMEK) with Cloud SQL, you must first create a Cloud KMS key ring and key, then grant the Cloud SQL service account the cloudkms.cryptoKeyEncrypterDecrypter role. This allows Cloud SQL to use the key to encrypt the instance's data at rest. The service account must have permission to use the key for encryption and decryption operations.

Exam trap

ACE often tests the misconception that enabling the Cloud KMS API or using a key file is sufficient for CMEK, but the critical step is granting the Cloud SQL service account the correct IAM role on the KMS key.

How to eliminate wrong answers

Option A is wrong because CMEK for Cloud SQL uses Cloud KMS keys, not key files stored in a bucket; uploading a key file is not part of the CMEK setup. Option C is wrong because enabling the Cloud KMS API alone does not configure CMEK; default encryption uses Google-managed keys, not customer-managed keys. Option D is wrong because the --disk-encryption-key flag is used for Compute Engine persistent disks, not for Cloud SQL instances; Cloud SQL CMEK is configured via the Cloud SQL instance settings, not a flag.

Full explanation →

240

MCQhard

A DevOps engineer is configuring a managed instance group (MIG) for a stateless web application. They want to ensure that when new instances are created via rolling update or autoscaling, a startup script runs to install security patches and deploy the latest application code from a Cloud Storage bucket. What is the BEST way to achieve this?

A.Create a custom image with pre-installed patches and code, and use that image in the template

B.After the MIG is created, use gcloud compute ssh to run the script on each instance

C.Store the script in Cloud Storage and use gcloud compute instances add-metadata on each instance

D.Add the script to the instance template using the metadata key 'startup-script'

AnswerD

Adding the script to the instance template using the metadata key 'startup-script' is the recommended, automated approach because Compute Engine stores the metadata in the instance template and executes the script on every VM boot. The MIG automatically applies this metadata to all instances it creates, including during autoscaling, rolling updates, and instance recreation after a failure. This guarantees the configuration is consistently applied without manual intervention, and the script can be updated by editing the template and rolling out a new version of the MIG.

Why this answer

The best way to ensure a startup script runs on every new instance in a MIG is to embed it in the instance template using the metadata key 'startup-script'. The template is the blueprint for all instances created by the MIG, so any instance launched by autoscaling or rolling update automatically executes the script on boot.

Exam trap

The trap is choosing per-instance manual steps or custom images — candidates must recognize that MIG automation requires the startup script to be in the instance template, not applied after the fact.

How to eliminate wrong answers

Option A is wrong because a custom image with pre-installed patches and code becomes stale — it does not fetch the latest code from Cloud Storage at boot, so new instances would run outdated code. Option B is wrong because manually SSHing into each instance is not scalable, not automated, and does not apply to instances created later by autoscaling. Option C is wrong because adding metadata to existing instances does not affect future instances created by the MIG; the metadata must be in the instance template to propagate.

Full explanation →

241

MCQmedium

You are using Cloud Logging and want to export all logs from a specific Compute Engine instance to BigQuery for long-term analysis. You create a log sink with a filter for the instance's resource type and labels. What additional step is required to complete the export?

A.Create a Cloud Pub/Sub topic and configure a push subscription

B.Create a BigQuery dataset and grant the log sink's service account the BigQuery Data Editor role

C.Create a Cloud Storage bucket as a staging location

D.Enable BigQuery's streaming buffer on the dataset

AnswerB

This is the correct approach because BigQuery must already exist as a dataset for the log sink to write into, and the sink's underlying writer identity (the service account) needs the BigQuery Data Editor role (roles/bigquery.dataEditor) on that dataset to create tables and insert log entries. You first create the dataset, then configure the log sink with BigQuery as its destination, and after the sink is created you copy its service account ID and grant that service account the required IAM role. Without that grant, the sink will fail with permission errors when trying to deliver logs to BigQuery.

Why this answer

A log sink exports logs to a destination, but for BigQuery the destination dataset must exist and the sink's service account must be granted the BigQuery Data Editor role on that dataset. Without this IAM binding, the sink cannot write to BigQuery and the export fails.

Exam trap

ACE often tests whether candidates know that log sinks require explicit IAM grants to the sink's writer identity on the destination — creating the sink alone is insufficient.

How to eliminate wrong answers

Option A is wrong because Pub/Sub is used for streaming exports to third-party or custom consumers, not for direct BigQuery exports — the sink can target BigQuery directly. Option C is wrong because a Cloud Storage bucket is only needed for Cloud Storage exports or as a staging area for certain batch workflows, not for BigQuery sinks. Option D is wrong because the streaming buffer is an internal BigQuery mechanism for handling streaming inserts — it is not a configuration step required to enable a log sink export.

Full explanation →

242

MCQmedium

A company is migrating a legacy monolithic application to Google Cloud. The application requires persistent storage and must be highly available with automatic failover across zones. The workload has a moderate number of reads and writes. Which storage solution meets these requirements?

A.Compute Engine persistent disk attached to a VM in a managed instance group

B.Cloud Storage with object versioning

C.Cloud SQL with a regional (HA) configuration

D.Cloud Spanner

AnswerC

Cloud SQL with a regional (HA) configuration is the correct choice because it provides a fully managed relational database with automatic failover to a standby instance in a different zone within the same region. Data is synchronously replicated to the standby, so if the primary zone experiences an outage, Google Cloud promotes the standby with minimal disruption and no manual intervention. This gives the legacy monolithic application the ACID transactions, relational queries, and high availability it needs, at a cost and complexity level appropriate for moderate workloads.

Why this answer

Cloud SQL with a regional (HA) configuration provides a managed relational database with a primary instance in one zone and a standby in another, with automatic failover if the primary fails. It offers persistent storage, cross-zone high availability, and is well-suited to moderate read/write workloads typical of a migrated monolithic application. This matches the requirement for automatic failover across zones without the operational overhead of self-managed options.

Exam trap

The trap is over-engineering the answer — candidates see 'highly available' and jump to Spanner, but Spanner is for massive global scale, while Cloud SQL regional HA is the right fit for moderate workloads needing zonal failover.

How to eliminate wrong answers

Option A is wrong because a persistent disk attached to a VM in a managed instance group is zonal (or regional PD requires replication setup) and does not provide automatic database-level failover — it is infrastructure-level, not a managed HA database solution. Option B is wrong because Cloud Storage with object versioning is object storage, not a relational database, and does not provide the transactional persistence or failover semantics a legacy monolith requires. Option D is wrong because Cloud Spanner is a globally distributed, horizontally scalable relational database designed for massive scale and high throughput — it is overkill and more expensive for a moderate read/write monolithic workload.

Full explanation →

243

MCQhard

Your security team wants to prevent any user or service account from creating firewall rules that allow ingress from `0.0.0.0/0` (the internet) to any VM in your organization. Which approach enforces this without requiring per-project IAM changes?

A.Grant IAM deny policies that prevent the `compute.firewalls.create` permission across the organization.

B.Apply a hierarchical firewall policy at the organization level with a deny rule for ingress from 0.0.0.0/0, set to take precedence over project rules.

C.Use Security Command Center to detect and alert when 0.0.0.0/0 firewall rules are created.

D.Set the `compute.skipDefaultNetworkCreation` org policy constraint across the organization.

AnswerB

A hierarchical firewall policy applied at the organization level with a deny rule for ingress from 0.0.0.0/0 is the correct preventive control. Hierarchical firewall policies are evaluated before VPC firewall rules, and a deny rule in such a policy takes precedence over any project-level allow rule, regardless of that allow rule's priority. By setting the policy's association scope to the organization and giving the deny rule a sufficiently high precedence, all inbound traffic from the public internet is blocked across every project in the organization, and no project administrator can override it with a per-project firewall rule.

Why this answer

Hierarchical firewall policies at the organization level can include a deny rule for ingress from `0.0.0.0/0` with a priority that takes precedence over any project-level firewall rules. This enforces the restriction globally without requiring per-project IAM changes, as the policy is inherited by all projects in the organization.

Exam trap

Google Cloud often tests the distinction between preventive controls (like hierarchical firewall policies) and detective controls (like Security Command Center alerts), leading candidates to choose a detection-based option when the question explicitly asks for enforcement.

How to eliminate wrong answers

Option A is wrong because denying the `compute.firewalls.create` permission across the organization would block all firewall rule creation, not just those allowing ingress from `0.0.0.0/0`, and it would require per-project IAM changes if not applied at the org level via deny policies. Option C is wrong because Security Command Center can only detect and alert on the creation of such rules, not prevent them; it is a detective control, not a preventive one. Option D is wrong because the `compute.skipDefaultNetworkCreation` org policy constraint only prevents the automatic creation of default networks, not the creation of firewall rules that allow ingress from `0.0.0.0/0`.

Full explanation →

244

MCQhard

You are configuring Identity-Aware Proxy (IAP) for a web application running on Compute Engine. Users authenticate through IAP and are granted access based on their email addresses. However, some users report that they are prompted to sign in multiple times during the same session. What is the most likely cause?

A.The backend service is missing the IAP session cookie validation.

B.The users are accessing the application via different browsers.

C.The backend service does not support HTTPS.

D.The IAP session timeout is set too low.

AnswerD

A low IAP session timeout forces re-authentication once the session cookie expires, so users signing in repeatedly during one working session hit that limit. Raising the timeout to match the expected session duration satisfies the stem's requirement for continuous access, since IAP issues its own session cookie independent of the underlying Google identity.

Why this answer

The IAP session timeout determines how long a user's authenticated session remains valid before requiring re-authentication. If this timeout is set too low, users will be prompted to sign in multiple times during a single session, even if they are actively using the application. The default IAP session timeout is 1 hour, but it can be configured up to 24 hours; a low value directly causes repeated login prompts.

Exam trap

The trap here is that candidates often confuse session timeout with idle timeout or assume the issue is related to backend cookie handling, but Google specifically tests the understanding that IAP's configurable session TTL directly controls re-authentication frequency.

How to eliminate wrong answers

Option A is wrong because IAP session cookie validation is handled entirely by Google's IAP infrastructure, not the backend service; the backend only needs to trust the `X-Goog-Authenticated-User-Email` and `X-Goog-Iap-Jwt-Assertion` headers forwarded by IAP, and missing cookie validation would cause access denial, not repeated sign-in prompts. Option B is wrong because accessing the application via different browsers would create separate sessions, each requiring its own authentication, but the reported issue is repeated sign-ins within the same session, not across different browsers. Option C is wrong because IAP requires the backend service to use HTTPS (TLS) to protect the forwarded JWT headers; if the backend does not support HTTPS, IAP would fail to forward requests or the connection would be rejected, not cause multiple sign-in prompts.

Full explanation →

245

MCQmedium

You need to design a solution where a Cloud Function is triggered by HTTP requests from the internet, but it must also privately access a Cloud SQL instance that has no public IP. The Cloud Function should not expose the Cloud SQL instance to public traffic. Which configuration enables this?

A.Enable a public IP on the Cloud SQL instance and restrict access using Cloud SQL authorized networks.

B.Configure a Serverless VPC Access connector and attach it to the Cloud Function to access Cloud SQL via private IP.

C.Use Cloud SQL Auth Proxy on a Compute Engine VM as a jump host between the function and the database.

D.Deploy the Cloud Function in the same project as Cloud SQL; same-project resources can access each other privately by default.

AnswerB

A Serverless VPC Access connector bridges the Cloud Function's managed execution environment to your VPC network, allowing outbound requests over RFC 1918 private addresses. Attaching it to the function lets it reach the Cloud SQL instance's private IP without ever exposing a public endpoint, satisfying both connectivity and isolation. This is the only option that preserves the 'private IP only' security requirement.

Why this answer

A Serverless VPC Access connector allows a Cloud Function to connect to a Cloud SQL instance via its private IP, enabling private network communication without exposing the database to the internet. The connector bridges the serverless environment to a VPC, and the Cloud SQL instance must have private IP enabled. This satisfies the requirement of private access while the function itself remains publicly triggerable via HTTP.

Exam trap

Google Cloud often tests the misconception that resources in the same project can communicate privately by default, but the trap here is that Cloud Functions run outside your VPC and require explicit configuration (like a VPC connector) to access private IP resources such as Cloud SQL.

How to eliminate wrong answers

Option A is wrong because enabling a public IP on Cloud SQL and using authorized networks still exposes the instance to the internet, violating the requirement that the Cloud SQL instance should not be exposed to public traffic. Option C is wrong because using a Compute Engine VM as a jump host with Cloud SQL Auth Proxy introduces an unnecessary intermediary that adds latency, complexity, and a potential single point of failure, and is not the recommended or simplest solution for private access from a Cloud Function. Option D is wrong because same-project resources do not automatically have private network access; Cloud Functions run in a Google-managed environment outside your VPC by default, so they cannot reach Cloud SQL private IPs without a VPC connector or similar mechanism.

Full explanation →

246

MCQmedium

A startup is building a mobile app backend. Traffic is highly variable: 10 requests/second at night, peaking to 50,000 requests/second during business hours. The backend is stateless. Which compute option best handles this traffic variability with minimal cost and operational effort?

A.Compute Engine managed instance group with autoscaling.

B.Cloud Run with concurrency and max-instances configured.

C.GKE cluster with Horizontal Pod Autoscaler.

D.App Engine Standard environment with automatic scaling.

AnswerB

Cloud Run is a serverless container platform that automatically provisions instances based on incoming requests, and because each container instance can serve multiple concurrent requests (based on the concurrency setting), it can handle 50,000 RPS with a relatively small number of instances. With max-instances configured, you control the upper bound, receiving 429 errors if exceeded, but the default scaling can spin up thousands of instances in seconds to absorb spikes. When no traffic arrives at night, Cloud Run scales to zero instances, so you pay only for requests, making it the most cost-effective and responsive choice.

Why this answer

Cloud Run is the best choice because it is a fully managed serverless platform that scales from zero to thousands of requests per second automatically, handling the extreme variability from 10 to 50,000 requests/second without provisioning overhead. By configuring concurrency (e.g., 80 concurrent requests per container) and max-instances, you cap costs while Cloud Run's autoscaling adds or removes container instances based on incoming traffic, making it ideal for stateless workloads with minimal operational effort.

Exam trap

Google Cloud often tests the misconception that managed instance groups or GKE are more 'powerful' or 'flexible' for high traffic, but the trap here is ignoring the operational effort and cost of idle resources; candidates overlook that serverless options like Cloud Run can handle 50,000 req/s with proper concurrency tuning and are far simpler for stateless apps.

How to eliminate wrong answers

Option A is wrong because Compute Engine managed instance groups with autoscaling require you to manage virtual machine instances, patches, and scaling policies, leading to higher operational overhead and slower scaling response (minutes vs. seconds) compared to serverless options, and you pay for idle VMs even at low traffic. Option C is wrong because GKE with Horizontal Pod Autoscaler introduces cluster management complexity, node pool scaling delays, and Kubernetes control plane costs, which are unnecessary for a stateless app with variable traffic and increase operational effort. Option D is wrong because App Engine Standard environment, while serverless, has a hard limit of 500 concurrent requests per instance and a maximum of 10,000 requests/second in many regions, making it unable to handle the 50,000 requests/second peak without significant latency or errors, and it requires app to be written in specific supported runtimes.

Full explanation →

247

MCQeasy

A developer needs to deploy a containerized web application that experiences unpredictable traffic patterns, including long periods of no traffic. They want to minimize costs and only pay for resources when the application is serving requests. Which Google Cloud compute service is most suitable?

A.Cloud Run

B.Google Kubernetes Engine (GKE) Standard

C.Compute Engine with managed instance groups

D.Cloud Functions

AnswerA

Cloud Run scales container instances to zero when no requests arrive, billing only per request and consumed CPU/memory during execution. This satisfies the unpredictable-traffic and pay-only-when-serving constraints, unlike GKE node pools or Compute Engine VMs, which incur cost while idle.

Why this answer

Cloud Run is a serverless container platform that scales to zero when not in use, charging only for resources during request processing.

Full explanation →

248

MCQmedium

You need to allow a Cloud Function to write logs to Cloud Logging. The function uses a default service account. What IAM role should you grant to the service account?

A.roles/logging.logWriter

B.roles/cloudfunctions.serviceAgent

C.roles/logging.admin

D.roles/logging.viewer

AnswerA

roles/logging.logWriter is the predefined IAM role that contains the logging.logEntries.create permission, which is exactly what a Cloud Function needs to write log entries to Cloud Logging. Unlike broader roles, it does not include permissions to delete logs, manage log sinks, or modify log-based metrics, making it the least-privilege choice. Assigning this role to the function’s runtime service account allows both the Cloud Logging API and client libraries to write structured log entries on the function’s behalf.

Why this answer

The Cloud Function's default service account needs the `roles/logging.logWriter` role to write logs to Cloud Logging. This role grants the `logging.logEntries.create` permission, which is the minimum required for writing log entries. Without it, the function cannot send logs to Logging, even though it may have other permissions.

Exam trap

Google Cloud often tests the distinction between the Cloud Functions service agent (used for internal orchestration) and the default compute service account (used by the function itself), causing candidates to mistakenly choose `roles/cloudfunctions.serviceAgent` for log writing.

How to eliminate wrong answers

Option B is wrong because `roles/cloudfunctions.serviceAgent` is a predefined role for the Cloud Functions service agent (a Google-managed service account), not for the function's default compute service account; it grants permissions for Cloud Functions to call other services, not to write logs. Option C is wrong because `roles/logging.admin` grants full administrative access to Logging, including deleting logs and configuring sinks, which is excessive and violates the principle of least privilege for a simple log-writing task. Option D is wrong because `roles/logging.viewer` only allows reading logs (via `logging.logEntries.list` and `logging.logs.list`), not writing them.

Full explanation →

249

MCQhard

Your organization wants to enforce that all Compute Engine instances are created only in us-central1 and europe-west1. You need to implement this constraint across all projects in the organization. What should you do?

A.Apply an organization policy with constraint gcp.resourceLocations to allow only us-central1 and europe-west1.

B.Use VPC Service Controls to restrict access to Compute Engine API from other regions.

C.Use labels to tag instances and run a script to delete non-compliant ones.

D.Create an IAM policy denying the compute.instances.create permission in all other regions.

AnswerA

The gcp.resourceLocations organization policy constraint is a list constraint that defines the exact set of Google Cloud locations where new resources, including Compute Engine instances, may be created. Setting it to allow only us-central1 and europe-west1 at the organization or folder level makes non-compliance impossible at creation time, since the API call itself is rejected. This is a preventive, centralized governance mechanism that is inheritable across projects, making it the correct solution for enforcing geographic restrictions.

Why this answer

The correct approach is to apply an organization policy with the constraint gcp.resourceLocations (also known as Location Restriction) at the organization level, specifying allowed locations us-central1 and europe-west1. This constraint is enforced by the Organization Policy Service and prevents the creation of Compute Engine instances (and other resources) outside the allowed regions, regardless of IAM permissions. It provides centralized, preventive control across all projects in the organization.

Exam trap

ACE often tests the misconception that IAM policies can enforce regional restrictions, but IAM does not support conditions based on the region of a resource being created; the correct tool is Organization Policy constraints like gcp.resourceLocations.

How to eliminate wrong answers

Option B is wrong because VPC Service Controls are designed to mitigate data exfiltration risks by defining service perimeters around resources, not to restrict the regions where Compute Engine instances can be created; they control API access based on network context, not resource location. Option C is wrong because using labels and a script to delete non-compliant instances is a reactive, detective control that does not prevent creation and can lead to unintended deletions; it also requires custom automation and is not enforced by GCP natively. Option D is wrong because IAM policies do not support conditions based on region for the compute.instances.create permission; IAM conditions can use resource attributes but not the region of the instance being created, so this approach is not feasible.

Full explanation →

250

MCQeasy

A data analytics team needs to run a Spark job on a schedule. They want to minimize operational overhead and only pay for resources used during job execution. Which service should they use?

A.Create a Dataproc cluster and keep it running for ad-hoc jobs

B.Use Dataproc workflow templates with scheduled execution

C.Provision Compute Engine instances with Spark installed and start/stop them manually

D.Use BigQuery for all analytics

AnswerB

Workflow templates allow you to define a cluster configuration and job list, then instantiate it on a schedule via Cloud Scheduler or Dataproc's scheduled deletion. The template creates an ephemeral cluster at job start, runs the Spark job, and deletes the cluster after completion, ensuring you pay only for the duration of the job. This integrates natively with Cloud Scheduler and manages cluster lifecycle automatically.

Why this answer

Dataproc workflow templates allow you to define a Spark job as a workflow and schedule its execution using Cloud Scheduler or a cron-like mechanism. This minimizes operational overhead by automatically provisioning a cluster, running the job, and tearing down the cluster when finished, ensuring you only pay for resources used during execution.

Exam trap

Google Cloud often tests the distinction between persistent clusters (always-on) and ephemeral clusters (created on-demand), and the trap here is that candidates may assume any Dataproc usage is cost-effective, overlooking that only workflow templates with scheduled execution enforce automatic teardown.

How to eliminate wrong answers

Option A is wrong because keeping a Dataproc cluster running 24/7 incurs continuous compute costs, even when no jobs are running, which contradicts the requirement to pay only for resources used during job execution. Option C is wrong because manually provisioning and stopping Compute Engine instances with Spark installed introduces significant operational overhead and does not provide automated scheduling or lifecycle management. Option D is wrong because BigQuery is a serverless data warehouse for SQL-based analytics, not a Spark execution environment, and cannot run Spark jobs directly.

Full explanation →

251

MCQmedium

A company has a VPC with a subnet that has Private Google Access enabled. They want their Compute Engine instances to access Google APIs and services through internal IP addresses. Which additional configuration is required?

A.No additional configuration is required.

B.Configure Cloud NAT to enable access to Google APIs.

C.Set up Cloud VPN tunnels to Google APIs.

D.Create a VPC peering connection with the Google APIs VPC.

AnswerA

Private Google Access is a subnet-level setting that already routes traffic from VM instances with only internal IP addresses to Google APIs and services over Google's internal network. When this is enabled on the subnet, DNS resolution for googleapis.com automatically maps to Google's internal IP ranges, so the existing VPC routing handles API calls without any extra networking components. Therefore, no additional configuration is required.

Why this answer

Private Google Access allows Compute Engine instances with only internal IP addresses to reach Google APIs and services (such as Cloud Storage, BigQuery, and Pub/Sub) using internal IP addresses, without requiring an external IP or Cloud NAT. Once the subnet-level setting is enabled, no additional routing, NAT, or peering configuration is needed because Google APIs are reachable via the default route to the private Google access VIP (199.36.153.8/30 or the restricted.googleapis.com VIPs).

Exam trap

The trap here is confusing Private Google Access (internal access to Google APIs) with Cloud NAT (outbound internet access) — candidates often assume NAT is required for any outbound traffic, but Google APIs are a special case handled by PGA.

How to eliminate wrong answers

Option B is wrong because Cloud NAT is used to give instances without external IPs outbound internet access, not access to Google APIs — Private Google Access already handles Google API traffic internally. Option C is wrong because Cloud VPN tunnels are for connecting on-premises networks or other clouds to a VPC, not for reaching Google APIs from within GCP. Option D is wrong because VPC peering with a 'Google APIs VPC' is not a real configuration — Google APIs are reached through the default internet gateway route with Private Google Access, not through a peered VPC.

Full explanation →

252

MCQeasy

You have an Artifact Registry repository for Python packages (`format: python`). A developer needs to publish a new Python package to this repository. Which tool and configuration allows them to publish?

A.Use `pip install` pointing to the Artifact Registry URL to upload the package.

B.Use `twine upload` with the Artifact Registry Python repository URL as the repository target.

C.Use `docker push` to push the Python package as a container layer.

D.Use `gsutil cp` to copy the wheel file to the Artifact Registry bucket.

AnswerB

`twine upload` is the standard utility for publishing Python distribution packages (wheels and sdist archives) to a package index, and Artifact Registry's Python repositories implement the PyPI upload protocol. When invoked with the registry's repository URL as the `--repository-url` parameter and authenticated via Google Cloud credentials (e.g., a service account key or `gcloud auth login`), twine securely sends the package files to the correct format-specific endpoint. This is the only officially supported way to push Python packages into Artifact Registry, as it properly handles the package metadata and multipart upload that the PyPI protocol requires. Using twine ensures compatibility with the repository's authentication and validation mechanisms.

Why this answer

B is correct because `twine` is the standard tool for uploading Python packages to package indices, and Artifact Registry's Python repositories are compatible with the PyPI API. By specifying the Artifact Registry repository URL as the `--repository-url` target in `twine upload`, the developer can authenticate via a service account or OAuth token and publish the package directly.

Exam trap

Google Cloud often tests the distinction between tools for different artifact types (pip vs. twine, docker push vs. gsutil), and the trap here is that candidates may confuse `pip install` (download) with `twine upload` (publish) because both are Python-related commands.

How to eliminate wrong answers

Option A is wrong because `pip install` is used to download and install packages, not to upload or publish them; it has no capability to push artifacts to a repository. Option C is wrong because `docker push` is used to upload container images to a container registry, not Python wheel or source distribution files to a package repository. Option D is wrong because Artifact Registry for Python packages does not expose a GCS bucket interface; `gsutil cp` works only with Cloud Storage buckets, not with the PyPI-compatible API endpoints that Artifact Registry uses.

Full explanation →

253

MCQeasy

A developer needs to deploy a new version of a Cloud Run service that uses a custom container image stored in Artifact Registry. The service must be accessible only from within the same Google Cloud project and must not be reachable from the public internet. The developer wants to use the gcloud CLI to deploy. Which command should the developer use?

A.gcloud run deploy SERVICE --image=LOCATION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG --ingress=internal --allow-unauthenticated

B.gcloud run deploy SERVICE --image=LOCATION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG --ingress=all --allow-unauthenticated

C.gcloud run deploy SERVICE --image=LOCATION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG --ingress=internal --no-allow-unauthenticated

D.gcloud run deploy SERVICE --image=LOCATION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG --ingress=internal-and-cloud-load-balancing --allow-unauthenticated

AnswerC

The --ingress=internal flag restricts traffic to sources within the same project or VPC network, preventing public internet access. The --no-allow-unauthenticated flag requires authentication for all requests, ensuring the service is not publicly accessible. Deploying with the Artifact Registry image path is correct. This combination meets the requirement of internal-only access with authentication.

Why this answer

To make a Cloud Run service internal-only and require authentication, combine --ingress=internal with --no-allow-unauthenticated. The internal ingress setting ensures that only traffic from within the project or VPC network can reach the service, while disabling unauthenticated access enforces identity-based access control. This is the standard pattern for private microservices that should not be exposed to the public internet.

Exam trap

The trap here is confusing ingress control with authentication: setting --ingress=internal blocks public internet traffic but does not by itself require authentication, so --allow-unauthenticated must be replaced with --no-allow-unauthenticated to fully secure the service.

Full explanation →

254

MCQhard

You are managing a GKE cluster that runs a mixed workload: latency-sensitive web services and batch data processing jobs. The batch jobs run for hours and consume significant CPU/memory. During batch peaks, the web services experience CPU throttling. What is the best configuration to prevent batch jobs from impacting web service latency?

A.Set CPU requests and limits on batch job pods to be lower than web service pods.

B.Assign web service pods a higher PriorityClass and run batch jobs on a separate node pool with taints.

C.Use Horizontal Pod Autoscaler for batch jobs so they scale down during peak web traffic.

D.Enable Cluster Autoscaler so new nodes are added when batch jobs demand more resources.

AnswerB

Applying a higher PriorityClass to web service pods and placing batch jobs on a separate, tainted node pool is the architecturally correct solution. Node taints prevent batch pods from being scheduled onto web-service nodes (unless they tolerate the taint), providing hard isolation, while PriorityClass with preemption guarantees that if a web pod ever needs to be scheduled on a shared node, it will evict lower-priority batch pods. Together, these mechanisms ensure batch workloads cannot throttle web pods and that web traffic gets uninterrupted CPU resources.

Why this answer

It uses PriorityClass to ensure web service pods are scheduled and maintained over batch pods during resource contention, while placing batch jobs on a separate node pool with taints isolates their resource consumption. This prevents batch jobs from causing CPU throttling on latency-sensitive web services by guaranteeing that web pods have priority access to CPU cycles and that batch workloads do not share nodes with web pods.

Exam trap

Google Cloud often tests the misconception that resource limits alone (Option A) or autoscaling (Options C and D) can solve resource contention, when in reality priority and isolation mechanisms are required to guarantee QoS for latency-sensitive workloads.

How to eliminate wrong answers

Option A is wrong because setting CPU requests and limits lower on batch pods does not prevent them from consuming CPU when they are scheduled on the same node as web pods; CPU throttling occurs when the node's CPU is oversubscribed, and lower limits only cap the batch pod's usage but do not guarantee that web pods get CPU time first. Option C is wrong because Horizontal Pod Autoscaler (HPA) scales batch pods based on their own metrics (e.g., CPU utilization), not on web traffic; scaling down batch jobs during web peaks would require custom metrics or manual intervention, and HPA does not inherently prioritize web services. Option D is wrong because Cluster Autoscaler adds nodes when pods are unschedulable, but it does not prevent batch jobs from being scheduled on the same nodes as web pods; if batch jobs are already running on nodes with web pods, adding new nodes does not relieve the existing CPU contention on those nodes.

Full explanation →

255

Multi-Selecthard

A startup wants to control costs across multiple GCP projects. They want to track spending by department and set budget alerts. Which THREE actions should they take?

Select 3 answers

A.Assign labels to resources indicating department

B.Use Cloud Monitoring to track costs

C.Enable billing export to BigQuery

D.Create separate billing accounts for each department

E.Set up a budget with threshold alerts in the billing account

AnswersA, C, E

Labels attach department metadata directly to resources, and GCP propagates them into billing exports, enabling cost breakdown by department. This satisfies the stem's requirement to track spending per department, forming the foundation for budget alerts filtered on that label dimension.

Why this answer

Option A is correct because labels (key/value pairs such as department:finance) applied to resources are propagated into billing data, allowing spend to be broken down and filtered by department in cost reports and exports. Option C is correct because enabling billing export to BigQuery writes detailed Cloud Billing data (including labels, project, service, and SKU) to a dataset, enabling granular, queryable cost analysis across multiple projects. Option E is correct because budgets are created at the billing-account level and can trigger threshold-based alerts (e.g., at 50%, 90%, 100% of a specified amount) via Cloud Monitoring notification channels, which is exactly how the startup would monitor spending.

Option B is not appropriate because Cloud Monitoring tracks metrics, logs, and uptime for resources, not billing costs; cost visibility comes from Cloud Billing reports, budgets, and BigQuery export. Option D is not appropriate because creating separate billing accounts per department adds administrative overhead and fragments payment and reporting rather than enabling cost tracking by department within a shared account.

Exam trap

The trap is selecting Cloud Monitoring for cost tracking because the name sounds cost-adjacent — candidates must remember GCP separates operational monitoring (Cloud Monitoring) from cost monitoring (Cloud Billing).

Full explanation →

256

MCQmedium

You need to deploy a Cloud Function that is triggered by HTTP requests. You want to pass configuration parameters to the function at deployment time. Which approach should you use?

A.Store parameters in a Cloud Storage bucket and read them at runtime.

B.Edit the function code to hardcode the parameters.

C.Use the --set-env-vars flag with gcloud functions deploy.

D.Include the parameters in the HTTP request body.

AnswerC

The --set-env-vars flag injects key-value pairs as environment variables during gcloud functions deploy, making them readable by the function's runtime code. This passes configuration at deployment time without hardcoding values, satisfying the stem's requirement for supplying parameters when the HTTP-triggered function is created.

Why this answer

You can set environment variables at deployment time using the --set-env-vars flag with the gcloud functions deploy command. This allows passing configuration parameters without modifying the code. Option C is correct.

Full explanation →

257

MCQeasy

A developer wants to deploy a containerized web application that can scale to zero when not in use, and only pay for request processing time. Which compute service should they choose?

A.App Engine Flexible Environment

B.Cloud Functions

C.Cloud Run

D.Google Kubernetes Engine (GKE)

AnswerC

Cloud Run is a fully managed serverless platform that executes a container in response to HTTP requests and automatically scales the number of instances to zero when no traffic is arriving. Since you pay only for vCPU and memory during request processing, rounded up to 100ms increments, an idle service incurs no cost. This zero-idle scaling makes Cloud Run the most direct way to run a containerized web application with complete cost savings during inactivity.

Why this answer

Cloud Run is the correct choice because it is a managed compute platform that runs containerized applications in a serverless environment, automatically scaling to zero when there are no requests and charging only for the resources used during request processing (billed in 100-millisecond increments). This matches the requirement for a containerized web app that scales to zero and has pay-per-use pricing.

Exam trap

Google Cloud often tests the distinction between serverless compute options: candidates confuse Cloud Functions (for event-driven code) with Cloud Run (for containerized apps), or assume App Engine Flexible can scale to zero when it cannot.

How to eliminate wrong answers

Option A is wrong because App Engine Flexible Environment runs containers but does not scale to zero; it requires at least one instance to be running at all times, leading to continuous costs. Option B is wrong because Cloud Functions is serverless and scales to zero, but it is designed for event-driven functions, not containerized applications; it does not support arbitrary container images. Option D is wrong because Google Kubernetes Engine (GKE) is a Kubernetes orchestration service that can scale down, but it does not scale to zero by default (requires at least one node) and incurs costs for the underlying node pool even when idle.

Full explanation →

258

MCQmedium

You have a Cloud Run service that you want to update to use a new container image. You also want to keep the previous revision available in case you need to roll back. Which command should you use?

A.gcloud run deploy my-service --image gcr.io/my-project/my-app:v2

B.gcloud run revisions update my-service --image gcr.io/my-project/my-app:v2

C.gcloud run services update --image gcr.io/my-project/my-app:v2

D.kubectl set image service/my-service my-app=gcr.io/my-project/my-app:v2

AnswerA

Running 'gcloud run deploy my-service --image gcr.io/my-project/my-app:v2' is the correct way to update a Cloud Run service's container image. The deploy command prepares a new immutable revision with the specified image, makes it the latest revision, and automatically routes traffic to it according to your service's traffic policy. Existing revisions are preserved in the revision history, enabling immediate rollback via 'gcloud run services update-traffic' if the new revision misbehaves.

Why this answer

The command 'gcloud run deploy my-service --image gcr.io/my-project/my-app:v2' deploys a new revision of the Cloud Run service using the specified container image. By default, Cloud Run keeps previous revisions, allowing rollback. This is the standard and correct way to update a service.

Exam trap

The trap is thinking that 'gcloud run services update' can change the image, but it cannot; only 'gcloud run deploy' can, and candidates might also confuse Cloud Run with Kubernetes commands.

How to eliminate wrong answers

Option B is wrong because 'gcloud run revisions update' does not exist; revisions are immutable. Option C is wrong because 'gcloud run services update' is used to update service configuration (e.g., memory, env vars) but not to change the container image; the correct flag for image is not supported in that command. Option D is wrong because kubectl is for Kubernetes, not Cloud Run, and Cloud Run services are not managed via kubectl.

Full explanation →

259

MCQhard

An organization needs to run a batch analytics job daily that processes 500 GB of data stored in Cloud Storage. The job runs for 2 hours each day and can tolerate occasional failures. The team wants to minimize compute costs. Which compute option is most cost-effective?

A.Compute Engine with sole-tenant nodes

B.Compute Engine with preemptible VMs

C.Compute Engine with standard VMs and sustained use discount

D.Compute Engine with committed use discount for 1 year

AnswerB

Preemptible VMs are Compute Engine instances that are up to 80% cheaper than standard VMs and are ideal for fault-tolerant, batch workloads. They can be terminated by Google at any time within their maximum runtime of 24 hours, so the job must be checkpointed or designed to restart gracefully. Since the batch job runs daily and is inherently tolerant of interruption, using preemptible VMs maximizes cost savings without sacrificing correctness, making this the most cost-effective choice.

Why this answer

Preemptible VMs are correct because they cost up to 80% less than standard VMs and are ideal for fault-tolerant batch jobs that can tolerate occasional failures and run for a bounded 2-hour window. The workload's tolerance for interruption and its daily, non-continuous schedule align exactly with the preemptible VM use case, minimizing compute cost.

Exam trap

ACE often tests the distinction between discounts: candidates pick committed use discounts because they sound cheapest, but commitments require steady usage, and only preemptible/spot VMs match interruptible, short-duration batch workloads.

How to eliminate wrong answers

Option A is wrong because sole-tenant nodes are priced at a premium for physical isolation and compliance requirements, not cost optimization. Option C is wrong because standard VMs with sustained use discounts still cost significantly more than preemptible VMs and the discount only applies after substantial monthly usage. Option D is wrong because a 1-year committed use discount requires a continuous commitment and is designed for steady-state workloads, not a 2-hour daily batch job that would waste most of the commitment.

Full explanation →

260

MCQeasy

A team wants to create a consistent backup of a Compute Engine VM's boot disk before applying a major OS patch. The backup should be usable to restore the disk to a new VM if the patch fails. What is the recommended approach?

A.Create a custom VM image from the running instance using `gcloud compute images create`

B.Create a persistent disk snapshot using `gcloud compute disks snapshot`

C.Copy all files to a Cloud Storage bucket using gsutil rsync

D.Enable live migration for the VM — it automatically backs up state before migrations

AnswerB

Creating a persistent disk snapshot with `gcloud compute disks snapshot` captures the exact state of the disk at a point in time, including the boot sector, partition table, and all system files. For best consistency, you should stop the VM before taking the snapshot to flush caches and avoid changes during the operation, though `--guest-flush` (where available) can coordinate with the guest OS. Snapshots are stored incrementally in Cloud Storage and can be used to create a new disk or VM, making them a reliable backup mechanism.

Why this answer

A persistent disk snapshot captures a point-in-time, crash-consistent backup of the disk, including the boot disk, without requiring the VM to be stopped. Snapshots are the recommended method for backing up persistent disks because they support incremental backups, can be used to create new disks, and are optimized for restore operations to a new VM. This approach ensures the backup is usable for disaster recovery if the OS patch fails.

Exam trap

The trap here is that candidates confuse VM images (used for creating identical instances) with disk snapshots (used for backups), leading them to choose Option A, even though images require the VM to be stopped for consistency and are not designed for point-in-time recovery of a single disk.

How to eliminate wrong answers

Option A is wrong because creating a custom VM image from a running instance requires the instance to be stopped or the image creation process to quiesce the filesystem, which is not a consistent backup method for a live boot disk and is intended for creating reusable templates, not for point-in-time backups. Option C is wrong because using gsutil rsync to copy files to Cloud Storage does not capture the disk's boot sector, partition table, or system state, making it impossible to restore a bootable disk to a new VM; it only copies file-level data. Option D is wrong because live migration is a feature that moves a running VM between hosts without downtime and does not create any backup or snapshot of the disk; it is unrelated to backup creation.

Full explanation →

261

MCQmedium

A company wants to deploy a microservice on GKE. The deployment requires 3 replicas, and the service must be accessible via a fixed public IP address. Which Kubernetes resource should be used to expose the deployment?

A.Service of type LoadBalancer

B.Ingress resource

C.Service of type ClusterIP

D.Service of type NodePort

AnswerA

A Service of type LoadBalancer in GKE creates an external passthrough Network Load Balancer in Google Cloud, provisioning an external forwarding rule with a stable public IP address from a regional pool. This IP remains fixed for the lifetime of the Service unless the Service is deleted or a reserved static IP is explicitly configured, making it the correct choice for a microservice that needs a durable public endpoint without additional configuration.

Why this answer

A Kubernetes Service of type LoadBalancer provisions a cloud provider load balancer with an external IP that routes to the pods backing the deployment. On GKE, this creates a Google Cloud external passthrough Network Load Balancer with a stable public IP, which matches the fixed public IP requirement.

Exam trap

ACE often tests the confusion between Ingress (L7, HTTP routing, shared IP) and LoadBalancer Service (L4, dedicated external IP), causing candidates to pick Ingress when a fixed public IP for a raw service is required.

How to eliminate wrong answers

Option B is wrong because an Ingress resource requires an Ingress controller and typically provides HTTP(S) routing with a shared IP; it does not by itself guarantee a fixed public IP for a raw TCP service and adds unnecessary complexity. Option C is wrong because ClusterIP is only reachable inside the cluster and has no external IP. Option D is wrong because NodePort exposes a port on every node's IP, which is not a fixed public IP and is unsuitable for production external access.

Full explanation →

262

Drag & Dropmedium

Order the steps to set up a VPC network with a subnet, firewall rule allowing SSH, and a Compute Engine instance in that subnet.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence is to first create the VPC network and subnet, then create the firewall rule allowing SSH, and finally create the Compute Engine instance. This ensures that the network infrastructure is ready before the instance is launched, and SSH access is available immediately.

Full explanation →

263

MCQmedium

You need to enforce that all new Cloud Storage buckets in your organization use Uniform Bucket-Level Access (UBLA) and are created in one of three approved regions: `us-central1`, `us-east1`, or `europe-west1`. What is the most efficient way to enforce both constraints?

A.Write a Cloud Function triggered by bucket creation events to check and delete non-compliant buckets.

B.Apply `storage.uniformBucketLevelAccess` and `gcp.resourceLocations` org policies at the organization level.

C.Create a custom IAM role that removes the `storage.buckets.create` permission for disallowed regions.

D.Use Terraform to provision all buckets and include validation in the Terraform plan step.

AnswerB

Organization policies enforce constraints across all projects without per-bucket configuration. The `storage.uniformBucketLevelAccess` boolean constraint forces UBLA on every new bucket, while `gcp.resourceLocations` restricts creation to the three approved regions, satisfying both requirements centrally at the organization level.

Why this answer

Organization policies are the most efficient way to enforce constraints across all new Cloud Storage buckets because they are evaluated at resource creation time by the Cloud Resource Manager. The `storage.uniformBucketLevelAccess` policy enforces UBLA, and `gcp.resourceLocations` restricts the allowed locations, both applied at the organization level to cover all projects without per-bucket overhead.

Exam trap

Google Cloud often tests the distinction between preventive controls (organization policies) and detective/reactive controls (Cloud Functions, Terraform validation), and the trap here is assuming that a post-creation check or a tool-specific validation is sufficient when a native, pre-creation enforcement mechanism exists.

How to eliminate wrong answers

Option A is wrong because a Cloud Function triggered by bucket creation events is reactive and inefficient—it would delete non-compliant buckets after creation, causing unnecessary resource churn and potential data loss, and it cannot prevent the creation in the first place. Option C is wrong because IAM roles control permissions at the API level, not the allowed regions for bucket creation; removing `storage.buckets.create` for disallowed regions is not possible because IAM does not support location-based conditions for the create permission. Option D is wrong because using Terraform with validation in the plan step only enforces compliance within Terraform-managed buckets, but does not prevent non-compliant buckets from being created via the Console, gsutil, or other tools outside Terraform.

Full explanation →

264

MCQmedium

A GKE Pod needs to call the Cloud Storage API. The team wants to avoid creating and managing service account key files. What is the recommended approach?

A.Mount a service account JSON key file as a Kubernetes Secret and set GOOGLE_APPLICATION_CREDENTIALS

B.Enable Workload Identity on the GKE cluster and bind a Kubernetes ServiceAccount to a GCP IAM ServiceAccount

C.Rely on the GKE node's Compute Engine service account for all Pod authentication

D.Grant the GKE node pool's service account the Storage Admin role to cover all Pod needs

AnswerB

Workload Identity lets each Kubernetes ServiceAccount map to a dedicated GCP IAM ServiceAccount, so Pods authenticate through the GKE metadata server using short-lived OAuth2 tokens. This completely removes the need for static JSON key files, eliminating manual rotation and key-leak risk. It also enforces least privilege because each workload gets only the IAM permissions bound to its own service account. Enabling it requires the cluster, node pools, and the metadata server configuration, but it's the recommended modern pattern.

Why this answer

Workload Identity is the recommended approach because it allows a Kubernetes ServiceAccount in GKE to authenticate as a GCP IAM ServiceAccount without managing or storing any service account key files. This eliminates the security risk of key leakage and simplifies credential rotation. By binding the Kubernetes ServiceAccount to a GCP IAM ServiceAccount, Pods can directly call Cloud Storage APIs using the IAM permissions of the linked service account, with automatic token exchange via the GKE metadata server.

Exam trap

Google Cloud often tests the misconception that the node's Compute Engine service account is sufficient for Pod-level authentication, but the trap here is that this approach lacks Pod-level identity isolation and violates least privilege, whereas Workload Identity provides a secure, keyless, and granular solution.

How to eliminate wrong answers

Option A is wrong because mounting a JSON key file as a Kubernetes Secret reintroduces the management and security burden of static keys, which the team explicitly wants to avoid, and violates the principle of keyless authentication. Option C is wrong because relying on the GKE node's Compute Engine service account grants the same permissions to all Pods on the node, violating the principle of least privilege and making it impossible to scope permissions per Pod. Option D is wrong because granting the node pool's service account the Storage Admin role is an overly permissive approach that also applies to all Pods on the node, and it still uses the node's identity rather than a Pod-specific identity, failing to provide fine-grained access control.

Full explanation →

265

MCQmedium

A team's Cloud Build pipeline must: (1) run unit tests, (2) build a Docker image only if tests pass, (3) push the image to Artifact Registry. Which cloudbuild.yaml structure correctly enforces this sequential dependency?

A.Define all three steps in a single `steps` list — they run sequentially by default and stop on failure

B.Use `waitFor` with step IDs to create a dependency graph between all three steps

C.Define the steps in three separate cloudbuild.yaml files and chain them with Cloud Composer

D.Set `parallel: false` at the top level of cloudbuild.yaml to enforce sequential execution

AnswerA

Defining all three steps in a single `steps` list is the idiomatic Cloud Build approach because each step runs as its own container sequentially, in the order they appear. The build automatically stops at the first step that exits with a non-zero status, so a failing test prevents the build and push steps from ever executing. This implicit sequential ordering and fail-fast behavior exactly enforces the test-before-build-before-push dependency without any extra configuration.

Why this answer

Cloud Build executes steps in a `steps` list sequentially by default, and any step that exits with a non-zero status (e.g., test failure) immediately stops the entire pipeline. This enforces the required dependency: unit tests must pass before the Docker image is built, and the image must be built before it is pushed to Artifact Registry.

Exam trap

Google Cloud often tests the misconception that you must explicitly use `waitFor` to enforce step dependencies, when in fact Cloud Build runs steps in a list sequentially by default and stops on failure.

How to eliminate wrong answers

Option B is wrong because using `waitFor` with step IDs is unnecessary; Cloud Build already runs steps in a list sequentially by default, and adding explicit `waitFor` only adds redundant configuration without changing behavior. Option C is wrong because Cloud Composer is a workflow orchestration service for Apache Airflow, not designed for chaining Cloud Build pipelines; it would add unnecessary complexity and cost for a simple sequential dependency. Option D is wrong because there is no `parallel: false` top-level field in cloudbuild.yaml; Cloud Build controls parallelism via `waitFor` and step ordering, not a global flag.

Full explanation →

266

MCQmedium

A company wants to store archival data that is accessed less than once a year. The data must be preserved for 10 years. Which Cloud Storage storage class is most cost-effective?

A.Archive

B.Standard

C.Nearline

D.Coldline

AnswerA

Archive is the lowest-cost Cloud Storage class, designed for data accessed less than once a year, and it supports the 10-year retention requirement. Nearline and Coldline assume more frequent access, so they cost more for this pattern.

Why this answer

Google Cloud Storage Archive storage class is the most cost-effective for data accessed less than once a year and retained for 10 years. Archive has the lowest storage cost but higher retrieval costs and a minimum storage duration of 365 days. It is designed for long-term archival of data that is rarely accessed, making it ideal for this use case.

Exam trap

ACE often tests the difference between Coldline and Archive. Candidates may choose Coldline because it is also for infrequent access, but Archive is more cost-effective for data accessed less than once a year.

How to eliminate wrong answers

Option B is wrong because Standard storage is designed for frequently accessed data and has the highest storage cost. Option C is wrong because Nearline is for data accessed less than once a month, not less than once a year; it has higher storage cost than Archive. Option D is wrong because Coldline is for data accessed less than once a year, but Archive is even more cost-effective for data accessed less than once a year, with lower storage cost (though higher retrieval costs).

Full explanation →

267

MCQhard

A team is using Terraform to manage infrastructure in Google Cloud. After running terraform apply, they receive an error: 'Error 409: Resource already exists'. The team needs to resolve this without deleting and recreating the resource. What should they do?

A.Run 'terraform refresh' to update the state file.

B.Import the existing resource into Terraform state with 'terraform import'.

C.Set the 'create_before_destroy' lifecycle rule on the resource.

D.Change the resource name in the Terraform configuration.

AnswerB

terraform import explicitly binds an existing GCP resource to a specified resource address in Terraform state, using the syntax terraform import <address> <resource_id>. After import, Terraform considers the resource as managed, but you must still write matching configuration; otherwise a subsequent plan will show changes. This is the only direct way to bring an out-of-band resource under Terraform management.

Why this answer

The 'Error 409: Resource already exists' indicates that the resource was created outside of Terraform or the state file lost track of it. Running 'terraform import' brings the existing resource under Terraform management by adding its current attributes to the state file, allowing subsequent operations without deletion or recreation.

Exam trap

Google Cloud often tests the misconception that 'terraform refresh' can fix state mismatches for missing resources, but it only syncs attributes for resources already in state, not imports new ones.

How to eliminate wrong answers

Option A is wrong because 'terraform refresh' only updates the state file with current real-world attributes of resources already tracked in state; it cannot add a resource that is missing from state. Option C is wrong because 'create_before_destroy' is a lifecycle meta-argument that controls the order of creation and destruction during updates, not a mechanism to resolve a state mismatch or import an existing resource. Option D is wrong because changing the resource name in the configuration would cause Terraform to attempt creating a new resource with the new name, leaving the existing resource unmanaged and still causing a conflict if the original name is reused elsewhere.

Full explanation →

268

MCQhard

A company wants to grant a contractor read-only access to all Compute Engine instances in a specific project, but no other resources. Which IAM role should be assigned?

A.roles/compute.instanceAdmin.v1

B.roles/viewer

C.roles/compute.viewer

D.roles/iam.securityReviewer

AnswerC

This predefined role contains only read permissions for Compute Engine resources, including instances, disks, images, snapshots, instance templates, and usage metrics, and it allows you to see them in the Cloud Console without any write or administrative actions. It precisely matches the contractor's access need and nothing more, upholding the principle of least privilege. As the correct answer, it is the best fit for granting read-only access to Compute Engine resources only.

Why this answer

roles/compute.viewer is the correct choice because it grants read-only access to all Compute Engine resources, including instances, disks, and snapshots, within the project. It does not include permissions for other services like Cloud Storage or IAM, aligning with the principle of least privilege. This role is predefined by Google Cloud and is specifically designed for viewing Compute Engine resources without modification rights.

Exam trap

ACE often tests the distinction between project-level and service-specific roles, and candidates may incorrectly choose roles/viewer for its broad read-only access, forgetting that it grants access to all resources, not just Compute Engine.

How to eliminate wrong answers

Option A is wrong because roles/compute.instanceAdmin.v1 grants full control over Compute Engine instances, including create, delete, and modify permissions, which violates the read-only requirement. Option B is wrong because roles/viewer provides read-only access to all resources in the project, not just Compute Engine, thus granting excessive permissions. Option D is wrong because roles/iam.securityReviewer is for viewing IAM policies and audit logs, not for accessing Compute Engine instances.

Full explanation →

269

MCQmedium

A team needs to deploy a microservice that processes events from Pub/Sub and writes the results to Firestore. The service is stateless and should not incur cost when idle. The expected load is low but can spike unpredictably. Which compute service is the most cost-effective and operationally simple?

A.GKE Standard with a cluster autoscaler and a Pub/Sub sidecar

B.Compute Engine with a managed instance group and autoscaling based on Pub/Sub queue depth

C.Cloud Run for Anthos on-premises

D.Cloud Functions (2nd gen) triggered by Pub/Sub

AnswerD

Cloud Functions (2nd gen) is a fully managed, event-driven compute service that can be triggered directly by Pub/Sub messages via Eventarc. It scales automatically from zero to thousands of concurrent invocations and bills only for the time your code runs, so there is no idle capacity or cluster infrastructure to manage. This makes it the most cost-effective and operationally simple choice for processing sporadic events.

Why this answer

Cloud Functions (2nd gen) is a fully managed, event-driven serverless compute service that scales to zero when idle and is triggered natively by Pub/Sub. It is stateless by design, requires no cluster or instance management, and charges only for invocations and compute time, making it the most cost-effective and operationally simple choice for low, spiky workloads.

Exam trap

ACE often tests serverless selection by including managed-but-not-serverless options (GKE, MIGs) that sound operationally simple but still incur idle cost, so candidates must verify the 'scale to zero' and 'no cost when idle' requirements.

How to eliminate wrong answers

Option A is wrong because GKE Standard requires managing node pools, cluster upgrades, and a Pub/Sub sidecar, and it does not scale to zero — you pay for nodes even when idle, which violates the 'no cost when idle' requirement. Option B is wrong because a Compute Engine managed instance group still runs VMs (minimum instance count) and requires autoscaling configuration based on queue depth, incurring cost when idle and adding operational complexity. Option C is wrong because Cloud Run for Anthos on-premises runs on your own infrastructure, not in GCP, so it does not meet the serverless, pay-per-use cloud requirement and adds on-prem management overhead.

Full explanation →

270

MCQmedium

A microservices application has intermittent high latency. The team wants to identify which specific service-to-service call in the request chain is causing the slowdown. Which Cloud Operations tool is designed for this?

A.Cloud Monitoring Metrics Explorer

B.Cloud Logging log viewer

C.Cloud Trace

D.Cloud Profiler

AnswerC

Cloud Trace is the correct choice because it captures end-to-end request latency as distributed traces, recording each span with its duration and parent-child relationships across services. This lets you follow a single user request through the entire service chain and identify exactly which downstream call added the most delay, rather than merely showing aggregate trends or isolated logs.

Why this answer

Cloud Trace is designed to capture latency data for individual service-to-service calls in a distributed request chain. It provides end-to-end tracing by collecting trace spans from each microservice, allowing you to pinpoint which specific call is causing the slowdown. This makes it the correct tool for identifying the exact service-to-service latency bottleneck.

Exam trap

Google Cloud often tests the distinction between tools that monitor aggregate metrics (Cloud Monitoring) versus tools that trace individual request paths (Cloud Trace), and the trap here is that candidates confuse Cloud Profiler's code-level profiling with distributed tracing, leading them to pick D instead of C.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring Metrics Explorer aggregates metrics like CPU, memory, and request counts, but it does not trace individual request paths or provide per-call latency breakdowns across services. Option B is wrong because Cloud Logging log viewer collects and filters log entries, but it lacks the distributed tracing context needed to correlate spans and measure latency for each service-to-service hop. Option D is wrong because Cloud Profiler continuously analyzes CPU and memory usage of running code to identify performance hotspots within a single service, but it does not trace request flows or measure network latency between services.

Full explanation →

271

MCQhard

Your on-premises data center needs a dedicated, private connection to GCP with a guaranteed 10 Gbps bandwidth and SLA-backed availability. Internet-based VPN is not acceptable due to compliance requirements. Which connectivity option should you choose?

A.Cloud VPN with multiple tunnels for redundancy

B.Cloud Interconnect Dedicated (10 Gbps)

C.Partner Interconnect via a carrier partner

D.Cloud Router with BGP peering over the public internet

AnswerB

Dedicated Interconnect provides a private, physical 10 Gbps (or 100 Gbps) connection from your on-premises network to Google at a Google edge co-location facility. Traffic traverses only Google's global network and never the public internet, which directly satisfies the compliance requirement. This option also comes with a 99.9% uptime SLA, making it the most robust and compliant choice for high-bandwidth, low-latency connectivity.

Why this answer

Dedicated Interconnect provides a direct, private physical connection between your on-premises network and GCP, offering up to 10 Gbps per circuit with a 99.99% SLA. Since internet-based VPN is not acceptable due to compliance requirements, this option meets the need for dedicated bandwidth and SLA-backed availability without traversing the public internet.

Exam trap

The trap here is that candidates often confuse Partner Interconnect with Dedicated Interconnect, assuming Partner Interconnect can also provide a dedicated 10 Gbps connection, but Partner Interconnect is a shared connection through a carrier and does not offer the same dedicated bandwidth or SLA guarantees.

How to eliminate wrong answers

Option A is wrong because Cloud VPN uses the public internet and cannot guarantee 10 Gbps bandwidth or meet compliance requirements that prohibit internet-based connectivity. Option C is wrong because Partner Interconnect relies on a carrier partner's network and typically offers lower bandwidth options (e.g., 50 Mbps to 10 Gbps) with a shared infrastructure, not a dedicated 10 Gbps circuit with the same SLA as Dedicated Interconnect. Option D is wrong because Cloud Router with BGP peering over the public internet is still an internet-based VPN solution, which is explicitly not acceptable due to compliance requirements.

Full explanation →

272

Drag & Dropmedium

Order the steps to attach a persistent disk to a running Compute Engine instance and format/mount it.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for attaching a persistent disk to a running Compute Engine instance and formatting/mounting it is: first attach the disk to the instance using gcloud or the console, then SSH into the instance, format the disk (e.g., with mkfs) if it is new, and finally mount it to a directory (e.g., using mount). This ensures the disk is available and prepared for use.

Full explanation →

273

MCQmedium

A team wants to configure a Cloud Scheduler job to invoke a Cloud Run service endpoint every hour using HTTP POST. The Cloud Run service requires authentication. How should the Scheduler job be configured to authenticate?

A.Include a Bearer token in the Authorization header of the scheduled HTTP request

B.Configure the Cloud Scheduler job with OIDC authentication using a service account that has Cloud Run Invoker permission

C.Make the Cloud Run service publicly accessible and use Cloud Armor to restrict access to Cloud Scheduler IPs

D.Configure an API key for the Cloud Run service and include it in the scheduled request URL

AnswerB

Cloud Scheduler can authenticate HTTP targets using OIDC by automatically generating a short-lived Google-issued identity token for a configured service account. That token is placed in the Authorization header as 'Bearer <token>' for each scheduled request. The service account must be granted the roles/run.invoker role on the target Cloud Run service so that the token is accepted. This is the recommended pattern because the token is ephemeral, automatically rotated, and tied to a specific service, making it both secure and auditable.

Why this answer

Cloud Scheduler can authenticate to Cloud Run using OIDC (OpenID Connect) by attaching a service account to the job. The scheduler obtains an OIDC token for that service account and includes it as a Bearer token in the Authorization header. The service account must have the `run.invoker` IAM role on the Cloud Run service to authorize the invocation.

Exam trap

Google Cloud often tests the distinction between OIDC and OAuth 2.0 in Cloud Scheduler, and the trap here is that candidates mistakenly think a static Bearer token or an API key can be used for Cloud Run authentication, when in fact only OIDC (or OAuth 2.0 for Google APIs) is supported for service-to-service invocation.

How to eliminate wrong answers

Option A is wrong because a static Bearer token (e.g., a long-lived personal access token) is not a supported authentication method for Cloud Scheduler; Cloud Scheduler uses OIDC or OAuth 2.0 access tokens, not arbitrary tokens. Option C is wrong because making the Cloud Run service publicly accessible defeats the purpose of requiring authentication, and Cloud Armor cannot restrict access based on Cloud Scheduler IPs since Cloud Scheduler uses a dynamic IP range that is not reliably scoped. Option D is wrong because Cloud Run does not support API key authentication; API keys are used for Google Cloud APIs (e.g., Maps), not for invoking Cloud Run services.

Full explanation →

274

MCQhard

Your application uses Pub/Sub to process orders. You notice that the subscription backlog is growing. Which tool should you use to analyze the latency of each step in the processing pipeline?

A.Cloud Monitoring

B.Cloud Profiler

C.Cloud Logging

D.Cloud Trace

AnswerD

Cloud Trace provides distributed tracing with per-span and per-service latency breakdowns, capturing the full path of a message as it flows through Pub/Sub and downstream services. Its waterfall view and latency distributions reveal exactly which step—from publish to processing—contributes the most delay. It is the only tool among these options specifically designed to analyze per-step latency in a distributed, asynchronous pipeline.

Why this answer

Cloud Trace is designed to analyze latency and performance of distributed applications, including Pub/Sub processing pipelines. It provides detailed trace data showing the time taken by each step, helping identify bottlenecks. Cloud Monitoring provides metrics but not per-step latency breakdown, while Cloud Profiler is for code-level profiling and Cloud Logging for log analysis.

Exam trap

The trap is confusing Cloud Trace with Cloud Monitoring or Cloud Logging; candidates might think Monitoring provides detailed latency breakdowns, but it only offers aggregate metrics.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring aggregates metrics and alerts but does not provide detailed per-request latency tracing. Option B is wrong because Cloud Profiler analyzes CPU and memory usage of code, not end-to-end latency. Option C is wrong because Cloud Logging captures log events but lacks built-in latency analysis and visualization.

Full explanation →

275

Multi-Selectmedium

You are troubleshooting a slow Pub/Sub subscription. Which three steps should you take to diagnose the issue? (Choose three.)

Select 3 answers

A.Check the subscription's backlog in the Pub/Sub console or via gcloud pubsub subscriptions describe

B.Use Cloud Monitoring Metrics Explorer to view the subscription's backlog and ack messages count

C.Use Cloud Trace to analyze the latency of each Pub/Sub message

D.Use Cloud Debugger to inspect the subscriber code

E.Use Cloud Logging to check for subscriber errors or delivery failures

AnswersA, B, E

Checking the subscription's backlog, either in the Pub/Sub console or via the `gcloud pubsub subscriptions describe` command, gives a direct numeric measurement of how many messages are unacknowledged and waiting to be redelivered. A consistently growing backlog relative to the publish rate indicates the subscriber cannot keep up with the incoming flow. This is the first diagnostic step because it confirms whether the bottleneck is on the delivery side or the processing side without instrumenting any application code.

Why this answer

Cloud Monitoring (Metrics Explorer) can show subscription backlog, Cloud Logging can show subscriber errors, and checking the subscription's backlog via gcloud or console helps assess the issue. Cloud Trace is for HTTP-based services, not Pub/Sub directly. Cloud Debugger is for code debugging, not Pub/Sub monitoring.

Full explanation →

276

Multi-Selecteasy

A developer is deploying a new application on GKE and needs to configure a HorizontalPodAutoscaler (HPA). Which two resources are required for HPA to work correctly?

Select 2 answers

A.CPU utilization metrics

B.A Service

C.A ConfigMap

D.A Deployment

E.A NodePort service

AnswersA, D

CPU utilization metrics drive the Horizontal Pod Autoscaler's scaling decisions. By default, HPA reads the average CPU utilization across all pods in a target Deployment, comparing it against the target percentage you set relative to each pod's CPU request. This is the most common and default metric type, requiring pods to have explicit `resources.requests.cpu` values. Custom and external metrics can be used, but CPU utilization is the built-in, standard input for autoscaling.

Why this answer

HPA requires a deployment (or other scalable resource) and a target metric, usually CPU utilization. The HPA will scale the deployment based on the metric. A ConfigMap and a service are not strictly required for HPA.

Full explanation →

277

MCQmedium

A network security team wants to capture metadata about all TCP flows entering and leaving VMs in a specific subnet — source IP, destination IP, port, and bytes transferred — for security analysis. Which GCP feature collects this data?

A.Cloud Armor security policies with logging enabled

B.VPC Flow Logs enabled on the subnet

C.Cloud Packet Mirroring — captures all traffic for deep packet inspection

D.Firewall Rules Logging on each firewall rule

AnswerB

VPC Flow Logs, when enabled on a subnet, sample and collect metadata about every network flow that touches a VM interface in that subnet, including source/destination IP and port, protocol, bytes sent/received, and timing. These flow records are ingested into Cloud Logging and can be exported to BigQuery or Pub/Sub for anomaly detection, network forensics, or audit purposes. Because they cover all internal and external traffic regardless of protocol, they are the correct choice for connection-level visibility without capturing payloads.

Why this answer

VPC Flow Logs capture metadata (source/destination IP, port, protocol, bytes transferred) for all TCP (and UDP/ICMP) flows entering and leaving VM instances in a subnet. This feature is specifically designed for network monitoring and security analysis, recording flow-level logs without inspecting packet payloads. Enabling VPC Flow Logs on the subnet directly meets the requirement to collect the specified metadata for all TCP flows.

Exam trap

Google Cloud often tests the distinction between metadata-only logging (VPC Flow Logs) and full-packet capture (Cloud Packet Mirroring), causing candidates to mistakenly choose Packet Mirroring when only flow metadata is required.

How to eliminate wrong answers

Option A is wrong because Cloud Armor security policies with logging only log HTTP(S) requests that are evaluated against the policy, not all TCP flows at the subnet level, and they focus on application-layer traffic, not network flow metadata like bytes transferred. Option C is wrong because Cloud Packet Mirroring copies entire packets (including payloads) for deep packet inspection, which is overkill for metadata-only collection and incurs higher cost and complexity; it does not natively produce aggregated flow metadata. Option D is wrong because Firewall Rules Logging logs only connections that match a firewall rule (allow or deny), not all TCP flows in the subnet, and it records connection metadata but not bytes transferred per flow.

Full explanation →

278

Multi-Selecthard

An engineer needs to audit all Data Access logs for a project to detect unauthorized access to sensitive data. The engineer must ensure that logs are retained for 5 years and are immutable. Which THREE steps should the engineer take?

Select 3 answers

A.Configure the Cloud Storage bucket with a retention policy and enable object versioning

B.Enable Data Access audit logs for the relevant services in the project's IAM audit config

C.Use the default Logging retention of 30 days

D.Set up a Cloud Monitoring alert for any Data Access log entries

E.Create a log sink to export logs to a Cloud Storage bucket

AnswersA, B, E

The retention policy on the Cloud Storage bucket prevents objects from being deleted or overwritten for a specified duration, and object versioning preserves every version of each object, so even if an object is deleted or replaced, an immutable prior version remains. This is critical for compliance because audit logs must be tamper-proof and available for a multi-year period. However, this step alone does not capture logs; it secures the destination bucket where the log sink delivers exported log entries.

Why this answer

To achieve this, the engineer must: 1. Enable Data Access audit logs for the required services (e.g., Cloud Storage, BigQuery) in the project's IAM audit config. 2. Create a log sink that exports the logs to a Cloud Storage bucket (which provides cost-effective long-term retention). 3.

Configure the bucket with retention policy and object versioning to make logs immutable and protect against deletion. Using Logging's default retention is only 30 days, not 5 years. Cloud Monitoring does not store logs.

BigQuery is not ideal for immutable storage.

Full explanation →

279

MCQeasy

A project was accidentally deleted. A GCP administrator realizes the mistake 3 days later. What is the maximum time window in which the project can be restored?

A.24 hours — projects are permanently deleted after one day

B.7 days — projects enter a one-week soft-delete period

C.30 days — projects can be restored using `gcloud projects undelete` within this window

D.Projects are permanently deleted immediately and cannot be recovered

AnswerC

Deleted Google Cloud projects are not removed instantly; instead, they enter a soft-delete state for exactly 30 days. During this window, you can restore the project by running `gcloud projects undelete [PROJECT_ID]` or by using the Cloud Console's Resource Manager page. After 30 days, the project and its underlying resources are permanently purged and cannot be recovered. Note that the project ID must still be available and you need appropriate IAM permissions to perform the undelete.

Why this answer

Google Cloud projects have a 30-day soft-delete period after deletion. During this window, the project can be recovered using the `gcloud projects undelete` command or the Cloud Resource Manager API, restoring all associated resources and configurations.

Exam trap

The trap here is that candidates may confuse the 30-day project soft-delete period with shorter retention windows for other GCP services (like 7-day backup retention for Cloud SQL or 24-hour snapshot deletion), leading them to underestimate the recovery window.

How to eliminate wrong answers

Option A is wrong because projects are not permanently deleted after 24 hours; the soft-delete period is 30 days, not one day. Option B is wrong because the recovery window is 30 days, not 7 days; the 7-day figure might be confused with the retention period for some other GCP resources like Cloud SQL backups. Option D is wrong because projects are not permanently deleted immediately; they enter a recoverable soft-delete state for 30 days before permanent deletion.

Full explanation →

280

MCQhard

A public API receives global traffic but has been targeted by both volumetric DDoS attacks and SQL injection attempts in HTTP request parameters. Which single GCP service provides protection against both threats?

A.VPC firewall rules with deny rules for known attacker IPs

B.Cloud NAT to hide backend IP addresses

C.Cloud Armor security policies on the load balancer

D.Identity-Aware Proxy (IAP) to require authentication before accessing the API

AnswerC

Cloud Armor security policies attached to the external HTTP(S) load balancer deliver both volumetric DDoS mitigation at Google's global edge and layer 7 WAF rules, including preconfigured OWASP rules that detect and block SQLi payloads. Because it operates at the edge and inspects traffic before it reaches backends, it can filter attack traffic close to the source while allowing legitimate requests. This single service directly addresses both the DDoS flood and the SQL injection attempts described in the scenario.

Why this answer

Cloud Armor security policies, when attached to a Google Cloud HTTPS Load Balancer, provide both Layer 7 DDoS protection (via pre-configured WAF rules like 'modsecurity-crs' to block SQL injection) and volumetric DDoS defense (via rate limiting and adaptive protection). This makes it the single GCP service that directly addresses both threats mentioned in the question.

Exam trap

Google Cloud often tests the distinction between network-layer security (VPC firewall rules) and application-layer security (Cloud Armor WAF), leading candidates to mistakenly choose VPC firewall rules because they think 'deny rules' can block attacks, but they cannot inspect HTTP payloads for SQL injection.

How to eliminate wrong answers

Option A is wrong because VPC firewall rules operate at Layer 3/4 and cannot inspect HTTP request parameters for SQL injection patterns; they also rely on static IP deny lists, which are ineffective against volumetric DDoS attacks that use many distributed source IPs. Option B is wrong because Cloud NAT only provides outbound connectivity with source NAT for private instances and does not inspect or filter inbound HTTP traffic, so it cannot block SQL injection or DDoS attacks targeting the public API. Option D is wrong because Identity-Aware Proxy (IAP) enforces authentication and authorization at the application layer but does not provide any DDoS mitigation or SQL injection detection capabilities.

Full explanation →

281

MCQmedium

A platform engineer is deploying a Kubernetes Job that processes a batch of records. The Job should run 10 parallel workers, each processing a subset of records, and complete when all workers finish successfully. Which Job spec configuration achieves this?

A.Set replicas: 10 in the Job spec

B.Set parallelism: 10 and completions: 10 in the Job spec

C.Create 10 separate Job objects — one per worker

D.Set concurrency: 10 in the Job spec

AnswerB

Setting `parallelism: 10` and `completions: 10` in a Job spec is exactly the right way to run 10 workers in parallel while ensuring the Job is considered complete only after all 10 Pods have succeeded. `parallelism` controls the maximum number of Pods allowed to run at the same time, and `completions` tells the Job controller how many successful Pod runs are required overall. This is the standard configuration for a deterministic parallel batch job.

Why this answer

In Kubernetes, a Job's `parallelism` field specifies the number of Pods that can run concurrently, and `completions` specifies the total number of successful Pod completions required for the Job to be considered finished. Setting both to 10 ensures exactly 10 Pods run in parallel, each processing a subset of records, and the Job completes only when all 10 have succeeded.

Exam trap

Google Cloud often tests the distinction between Deployment fields (like `replicas`) and Job-specific fields (like `parallelism` and `completions`), trapping candidates who confuse the two or assume `replicas` applies to Jobs.

How to eliminate wrong answers

Option A is wrong because `replicas` is not a valid field in a Kubernetes Job spec; it is used in Deployments and StatefulSets to maintain a desired number of Pods, not to control parallel execution or completion count. Option C is wrong because creating 10 separate Job objects would result in 10 independent Jobs, each with its own lifecycle and status, rather than a single Job that tracks overall completion; this approach lacks coordination and does not guarantee that the batch is considered complete only when all workers finish. Option D is wrong because `concurrency` is not a valid field in a Kubernetes Job spec; it is a concept used in other systems (e.g., database connection pools) but not in the Job API, where parallelism controls concurrent Pod execution.

Full explanation →

282

MCQhard

You are on-call and receive a PagerDuty alert: `Cloud SQL CPU utilization > 90% for 15 minutes`. Checking `pg_stat_activity`, you find 200 connections with many in `idle` state and 15 queries running for > 5 minutes each. The long queries are table scans on a 500 GB unindexed table. What should you do IMMEDIATELY to restore service, and what is the root cause fix?

A.Restart the Cloud SQL instance to clear all connections and queries.

B.Terminate the long-running table scan queries immediately, then add indexes on the frequently queried columns as the root cause fix.

C.Increase Cloud SQL's CPU to a larger machine type to handle the current load.

D.Reduce `max_connections` to prevent new connections from adding load.

AnswerB

Use pg_stat_activity to identify the specific backend PIDs running the long table scans, then execute SELECT pg_terminate_backend(pid) to kill only those queries and restores the CPU headroom instantly without affecting other sessions. After that, create indexes on the columns used in the WHERE and JOIN clauses — preferably with CREATE INDEX CONCURRENTLY on PostgreSQL to avoid locking writes — so the optimiser can use Index Scan instead of Seq Scan, fixing the root cause. This combination yields immediate relief and a sustainable prevention of recurrence.

Why this answer

Terminating the long-running table scans immediately stops the CPU-intensive queries, restoring service. The root cause is the missing index on the 500 GB table, which forces sequential scans and high CPU usage. Adding indexes on frequently queried columns eliminates the need for full table scans, preventing recurrence.

Exam trap

Google Cloud often tests the distinction between immediate mitigation (terminating bad queries) and root cause fix (adding indexes), tempting candidates to choose a scaling or restart option that avoids addressing the fundamental indexing problem.

How to eliminate wrong answers

Option A is wrong because restarting the Cloud SQL instance kills all connections and queries indiscriminately, but the long-running scans will resume on restart if the root cause (missing index) is not addressed, and it causes unnecessary downtime. Option C is wrong because increasing CPU only masks the symptom; the unindexed scans will still consume excessive CPU on a larger machine, and it does not fix the underlying query performance issue. Option D is wrong because reducing max_connections does not stop the already-running long queries; it only prevents new connections, leaving the CPU-hogging scans active and service degraded.

Full explanation →

283

MCQeasy

You want to view the current IAM policy for a project in JSON format using the gcloud command-line tool. Which command should you run?

A.gcloud projects get-iam-policy <project-id> --format json

B.gcloud iam service-accounts get-iam-policy <service-account> --format json

C.gcloud iam policies get <project-id> --format json

D.gcloud projects describe <project-id> --format json

AnswerA

This is the correct command. `gcloud projects get-iam-policy` invokes the Cloud Resource Manager `getIamPolicy` API for the specified project, and the `--format json` flag requests the output as a structured JSON object containing the policy's `etag`, `version`, and `bindings`. It is the standard way to view all project-level IAM bindings.

Why this answer

The command 'gcloud projects get-iam-policy <project-id> --format json' retrieves the IAM policy for a project in JSON format. This command directly fetches the policy bindings and audit configs for the specified project.

Exam trap

ACE often tests the confusion between commands for different resources (project vs. service account) and invalid command syntax like 'gcloud iam policies get'.

How to eliminate wrong answers

Option B is wrong because it retrieves the IAM policy for a service account, not a project. Option C is wrong because 'gcloud iam policies get' is not a valid command; IAM policies are managed via resource-specific commands like 'gcloud projects get-iam-policy'. Option D is wrong because 'gcloud projects describe' returns project metadata, not the IAM policy.

Full explanation →

284

MCQmedium

An engineer needs to view the current IAM policy for a project in JSON format to analyze bindings. Which command should be used?

A.gcloud resource-manager folders get-iam-policy my-project --format json

B.gcloud projects get-iam-policy my-project --format yaml

C.gcloud projects get-iam-policy my-project --format json

D.gcloud iam policies get my-project --format json

AnswerC

This is the correct command. It uses the 'gcloud projects get-iam-policy' subcommand to retrieve the IAM policy for the specified project ID ('my-project') and sets the output format to JSON via '--format json'. The command returns the Policy object containing bindings, roles, members, etag, and version, all serialized in the requested JSON structure.

Why this answer

The command gcloud projects get-iam-policy PROJECT_ID --format json retrieves the IAM policy for the project in JSON format. Other commands either get policies for different resources or use a different format.

Full explanation →

285

MCQmedium

An organization has multiple projects under a folder. They want to grant a network admin the ability to create firewall rules in all projects in the folder. Which IAM policy binding achieves this with least privilege?

A.Grant roles/owner at the folder level

B.Grant roles/compute.admin at the project level for each project

C.Grant roles/compute.networkAdmin at the folder level

D.Grant roles/compute.securityAdmin at the folder level

AnswerD

Granting roles/compute.securityAdmin at the folder level is the most precise solution because this role includes the compute.firewalls.create, compute.firewalls.update, and compute.firewalls.delete permissions needed to manage firewall rules, but does not include broader permissions to manage instances, networks, or IAM. IAM policies at the folder level are inherited by all projects and resources within that folder, so this single binding covers every descendant project, including newly created ones. This follows least privilege by granting exactly the permissions needed for firewall rule management and nothing extra.

Why this answer

Grant the roles/compute.securityAdmin role at the folder level. This allows managing firewall rules across all projects under that folder. Granting at project level would require adding the role to each project individually.

The compute.networkAdmin role does not include firewall rule management.

Full explanation →

286

MCQeasy

You need to store a database password securely in Google Cloud. The password will be used by a Compute Engine instance. Which service should you use?

A.Secret Manager

B.Cloud Storage

C.Cloud KMS

D.Cloud Firestore

AnswerA

Secret Manager is the dedicated GCP service for securely storing secrets such as database passwords, API keys, and TLS certificates. It provides automatic encryption at rest and in transit, granular IAM-permission binding, versioning, and audit logging, enabling applications to retrieve secrets on demand via API without embedding them in code. As a fully managed and centralized secret store, it is purpose-built to safeguard database credentials in compliance with security best practices.

Why this answer

Google Cloud Secret Manager is designed to store, manage, and access sensitive data like passwords, API keys, and certificates. It provides versioning, IAM-based access control, and audit logging, making it the correct choice for storing a database password used by a Compute Engine instance.

Exam trap

ACE often tests the difference between Secret Manager (for secrets) and Cloud KMS (for encryption keys), tricking candidates into choosing KMS when asked to store a password.

How to eliminate wrong answers

Option B is wrong because Cloud Storage is for object storage and lacks the specialized secret management features (encryption, rotation, access auditing) required for sensitive credentials. Option C is wrong because Cloud KMS manages encryption keys, not arbitrary secrets; it can encrypt secrets but doesn't provide a secret store with versioning and access control for the secret value itself. Option D is wrong because Cloud Firestore is a NoSQL document database, not a secret management service; storing passwords there would be insecure and lack dedicated secret handling.

Full explanation →

287

MCQhard

A company has an organization with multiple folders and projects. They want to audit all IAM policy changes across the entire organization. Which approach meets the requirement with minimal effort?

A.View Admin Activity audit logs in Logs Explorer, which are enabled by default.

B.Use Organization Policy to deny IAM policy changes and monitor violations.

C.Enable Data Access audit logs for all services in the organization.

D.Enable audit logging on each project individually using gcloud logging sinks.

AnswerA

Admin Activity audit logs are enabled by default for every Google Cloud project and record all IAM policy changes, including modifications to roles, bindings, and service account keys. To see who changed permissions, you can go directly to the Logs Explorer and query protoPayload.methodName=SetIamPolicy without creating any sinks or enabling additional features. This is the only option that directly answers the question with zero configuration effort.

Why this answer

Admin Activity audit logs are enabled by default for all Google Cloud projects and organizations, and they automatically capture IAM policy changes (e.g., SetIamPolicy calls) at the organization, folder, and project levels. Because they are always on and aggregated at the organization level, you can view them in Logs Explorer without enabling anything or configuring per-project sinks. This meets the audit requirement with minimal effort.

Exam trap

ACE often tests the misconception that you must enable audit logs to see IAM changes, when in fact Admin Activity logs are on by default and already capture them; candidates may incorrectly choose Data Access logs or per-project sinks.

How to eliminate wrong answers

Option B is wrong because Organization Policy is a preventive control (e.g., constraints like constraints/iam.disableServiceAccountKeyCreation) that blocks or restricts actions; it does not provide an audit trail of IAM changes and would not help you audit them. Option C is wrong because Data Access audit logs record reads/writes of data (e.g., reading a Cloud Storage object) and are disabled by default; they are not needed to audit IAM policy changes, and enabling them for all services would generate massive volume and cost. Option D is wrong because Admin Activity logs are already enabled by default and aggregated at the organization level; creating per-project sinks is unnecessary and does not meet the 'minimal effort' requirement.

Full explanation →

288

MCQeasy

A new engineer wants to set up their local environment to interact with Google Cloud. Which command initializes the gcloud CLI and configures the project, region, and zone?

A.gcloud auth login

B.gcloud auth application-default login

C.gcloud init

D.gcloud config set project my-project

AnswerC

gcloud init is the correct command because it performs a complete guided initialization of the local gcloud environment: it authenticates using either a user account or service account, sets a default project, and optionally configures compute/region and compute/zone properties in a new or existing configuration. It also runs an initial diagnostic to verify the installation and, if needed, can re-initialize an existing configuration. This one command provides the foundational project and location context that other gcloud commands depend on.

Why this answer

The `gcloud init` command is the interactive setup wizard that authenticates the user, lets them select or create a Cloud project, and sets default compute region and zone in one flow. It writes these values into the active gcloud configuration so subsequent commands use them automatically. This is the canonical first-run command for a new engineer's workstation.

Exam trap

ACE often tests the distinction between authentication commands (`gcloud auth login`, `gcloud auth application-default login`) and the full initialization command (`gcloud init`), so candidates who see 'configure project, region, and zone' may wrongly pick an auth-only command.

How to eliminate wrong answers

Option A is wrong because `gcloud auth login` only obtains user credentials for the gcloud CLI and does not configure project, region, or zone. Option B is wrong because `gcloud auth application-default login` sets up Application Default Credentials for client libraries/SDKs, not the gcloud CLI's project/region/zone defaults. Option D is wrong because `gcloud config set project my-project` only sets a single property (the project) and does not authenticate or set region/zone, so it is a partial configuration step rather than initialization.

Full explanation →

289

Multi-Selecthard

A developer needs to allow a CI/CD system to deploy applications to Cloud Run. The CI/CD system uses a service account. Which two roles should be granted to that service account?

Select 2 answers

A.roles/cloudbuild.builds.builder

B.roles/run.invoker

C.roles/iam.serviceAccountUser

D.roles/run.admin

E.roles/storage.objectViewer

AnswersC, D

Granting roles/iam.serviceAccountUser lets the CI/CD service account impersonate the Cloud Run runtime service account, which Cloud Run requires when deploying a revision that runs as a specific identity. This satisfies the stem's need for the pipeline to act as that runtime identity during deployment.

Why this answer

Option D (roles/run.admin) is correct because deploying a new Cloud Run service or revision requires permissions such as run.services.create, run.services.update, and run.services.setIamPolicy, which are all contained in the Cloud Run Admin role. Option C (roles/iam.serviceAccountUser) is correct because Cloud Run deployments run under a runtime service account, and the deploying identity must have iam.serviceAccounts.actAs on that service account, which is granted by the Service Account User role. Option A (roles/cloudbuild.builds.builder) is not required since it only grants permissions to execute Cloud Build builds, not to deploy to Cloud Run.

Option B (roles/run.invoker) only allows invoking a deployed Cloud Run service and does not permit deployment. Option E (roles/storage.objectViewer) only grants read access to Cloud Storage objects and is unrelated to Cloud Run deployment.

Exam trap

ACE often tests the distinction between roles needed to deploy (run.admin) versus roles needed to invoke (run.invoker) and the separate requirement for serviceAccountUser to act as the runtime service account.

Full explanation →

290

MCQhard

After creating a new GCP project, an engineer attempts to delete it using `gcloud projects delete PROJECT_ID` but receives an error. What is the most likely cause?

A.The project still has running resources (e.g., VM instances)

B.The IAM policy prevents deletion

C.The project ID is invalid

D.The project is linked to a billing account that must be disabled first

AnswerD

Before a GCP project can be deleted, its billing account attachment must be removed by disabling billing or unlinking the billing account. GCP will reject the deletion if the project is still linked to an active Cloud Billing account, returning an error such as 'Project is linked to a billing account'. You must disable the project's billing association first, then retry the deletion. This is the typical failure after creating a new project because billing is enabled by default.

Why this answer

A project cannot be deleted if it has a billing account attached. The billing account must be disabled (disassociated) first.

Full explanation →

291

MCQhard

Refer to the exhibit. An engineer runs this command and sees the output. The instance is unable to reach the internet. What is the most likely reason?

A.VPC firewall rules are blocking egress traffic.

B.The instance needs a Cloud NAT gateway for outbound connectivity.

C.The instance does not have a public IP address.

D.The subnetwork is misconfigured.

AnswerC

The instance does not have a public IP address. The `gcloud compute instances describe` output displays the `networkInterfaces` section without any `accessConfigs`, which is where an external NAT IP would be defined. Without an entry such as `natIP: 34.123.45.67`, the instance has no public IPv4 address, and therefore no direct path for inbound or outbound internet traffic.

Why this answer

The instance cannot reach the internet because it lacks a public IP address. In Google Cloud, an instance without an external IP address cannot initiate outbound connections to the internet unless a Cloud NAT or a VM with a public IP is used as a proxy. The command output likely shows that the instance only has an internal IP, confirming this as the root cause.

Exam trap

Google Cloud often tests the misconception that Cloud NAT is always required for internet access, but the trap here is that an instance with a public IP can directly reach the internet without NAT, so the absence of a public IP is the primary issue.

How to eliminate wrong answers

Option A is wrong because VPC firewall rules are stateful and allow egress traffic by default; unless explicitly blocked, they would not prevent outbound connectivity. Option B is wrong because Cloud NAT is not required for instances with a public IP; it is only needed for instances without one to access the internet. Option D is wrong because a misconfigured subnetwork would affect internal routing or IP allocation, but the instance still has a valid internal IP and the subnet is correctly assigned; the issue is the lack of a public IP, not subnet configuration.

Full explanation →

292

Multi-Selectmedium

A team is deploying a web application on Cloud Run. The application needs to be available globally with low latency, and the team wants to use a custom domain with an SSL certificate. Which TWO actions are required to achieve this?

Select 2 answers

A.Set the --ingress=all flag on the Cloud Run service

B.Use Cloud CDN to cache content

C.Configure a custom domain mapping on the Cloud Run service

D.Deploy the Cloud Run service in multiple regions and use a multi-regional load balancer

E.Deploy the service as a Cloud Run for Anthos on GKE

AnswersC, D

Custom domain mapping on Cloud Run registers the domain and provisions a Google-managed TLS certificate so the domain points to the service's default URL. This is a mandatory step to expose the application at the customer's chosen domain. While it handles the domain mapping, it does not by itself provide multi-region low latency; that requires a global load balancer with multiple regional backends.

Why this answer

Cloud Run services are regional; to serve globally, you need a global load balancer (e.g., using an external HTTPS load balancer with serverless NEG). Mapping a custom domain to the service is also required.

Full explanation →

293

MCQeasy

Which service should be used to manage billing budgets and alerts?

A.Cloud Monitoring

B.Cloud Billing Budgets

C.Cloud Billing Reports

D.Cloud Logging

AnswerB

Cloud Billing Budgets is the purpose-built service for setting spend limits on a billing account or project, defining threshold percentages (e.g., 50%, 90%, 100%), and sending alerts via email or Pub/Sub when actual or forecasted costs exceed those thresholds. It integrates directly with Billing Account and can trigger automated responses like disabling resources or sending notifications, making it the correct tool.

Why this answer

Cloud Billing Budgets is the correct service because it is specifically designed to allow you to set spending limits (budgets) on your Google Cloud projects, billing accounts, or folders, and to configure alerts (e.g., email notifications or Pub/Sub messages) when actual or forecasted costs exceed those thresholds. This directly addresses the requirement to manage billing budgets and alerts, whereas other services focus on monitoring infrastructure performance or logging operational data.

Exam trap

Google Cloud often tests the distinction between 'monitoring' (Cloud Monitoring) and 'billing alerts' (Cloud Billing Budgets), leading candidates to incorrectly choose Cloud Monitoring because they associate 'alerts' with performance monitoring rather than cost management.

How to eliminate wrong answers

Option A (Cloud Monitoring) is wrong because it is a service for collecting metrics, uptime checks, and alerting on infrastructure performance (e.g., CPU usage, latency), not for managing billing budgets or cost-based alerts. Option C (Cloud Billing Reports) is wrong because it provides historical cost analysis and export capabilities (e.g., BigQuery exports) but does not allow you to set proactive budget thresholds or trigger alerts when spending exceeds limits. Option D (Cloud Logging) is wrong because it is a service for storing, searching, and analyzing log data from applications and services (e.g., using Logs Explorer), not for managing financial budgets or cost alerts.

Full explanation →

294

MCQhard

A Cloud Run service requires access to a private Cloud SQL instance in the same VPC. The Cloud SQL instance is not publicly accessible. How should the Cloud Run service connect to Cloud SQL without using the Cloud SQL Auth Proxy separately?

A.Use the Cloud SQL public IP with SSL required — Cloud Run can reach public IPs

B.Configure the Cloud Run service with `--add-cloudsql-instances` to connect via the built-in Auth Proxy

C.Deploy a separate Cloud SQL Auth Proxy container in the same Cloud Run service as a sidecar

D.Enable Serverless VPC Access connector to route Cloud Run traffic to the private Cloud SQL IP

AnswerB

Configuring the Cloud Run service with `--add-cloudsql-instances` is the native, recommended integration for Cloud SQL. This flag instructs Cloud Run to start the Cloud SQL Auth Proxy within the instance, creating a Unix socket at `/cloudsql/<INSTANCE_CONNECTION_NAME>` and using the service account to establish a secure TLS connection. It avoids managing proxy deployments, certificates, and public IP exposure while providing IAM-based authentication. This approach works for both public and private IP instances.

Why this answer

The Cloud Run service can use the `--add-cloudsql-instances` flag, which automatically deploys a built-in Cloud SQL Auth Proxy sidecar container within the same pod. This proxy establishes a secure, encrypted connection to the private Cloud SQL instance using the instance's private IP, without requiring the instance to have a public IP or the user to manage a separate proxy. The proxy authenticates via the service account attached to the Cloud Run service, enabling seamless and secure connectivity.

Exam trap

The trap here is that candidates often confuse Serverless VPC Access connectors with the Cloud SQL Auth Proxy, thinking that VPC connectivity alone is sufficient to reach a private Cloud SQL instance, but they miss that the proxy is required for authentication and encrypted tunneling even within the same VPC.

How to eliminate wrong answers

Option A is wrong because Cloud Run services can reach public IPs, but the Cloud SQL instance is explicitly not publicly accessible, so using a public IP with SSL would fail due to no public endpoint being available. Option C is wrong because deploying a separate Cloud SQL Auth Proxy container as a sidecar is unnecessary and redundant; the built-in proxy via `--add-cloudsql-instances` already handles this automatically without manual sidecar configuration. Option D is wrong because a Serverless VPC Access connector enables Cloud Run to reach resources in a VPC, but it does not provide the authentication and encryption that the Cloud SQL Auth Proxy offers; the connector alone cannot connect to Cloud SQL without additional proxy or private IP configuration.

Full explanation →

295

MCQhard

A service account needs to be able to create snapshots of disks in a specific project and store them in a different project. What is the correct IAM policy configuration?

A.Grant roles/compute.storageAdmin on both projects

B.Grant roles/viewer on both projects

C.Grant roles/compute.snapshotAdmin on the source project and roles/storage.objectAdmin on the target bucket

D.Grant roles/compute.instanceAdmin on the source project and roles/storage.objectAdmin on the target bucket

AnswerC

This pairing correctly separates concerns: roles/compute.snapshotAdmin on the source project includes compute.snapshots.create and compute.disks.get permissions, allowing the service account to initiate a snapshot from the persistent disk. Meanwhile, roles/storage.objectAdmin on the target bucket permits the service account to write the snapshot image as an object into that Cloud Storage bucket. This is the standard pattern for cross-project snapshotting, because the snapshot is staged as an object in the designated bucket.

Why this answer

Creating snapshots in one project and storing them in another requires distinct permissions: `roles/compute.snapshotAdmin` on the source project allows the service account to create snapshots, while `roles/storage.objectAdmin` on the target bucket (within the destination project) grants the necessary permissions to write snapshot data into the bucket. This separation follows the principle of least privilege and aligns with the cross-project snapshot workflow.

Exam trap

Google Cloud often tests the misconception that a single role like `compute.storageAdmin` or `compute.instanceAdmin` can handle cross-project snapshot operations, when in fact you need a combination of snapshot-specific and bucket-specific roles.

How to eliminate wrong answers

Option A is wrong because `roles/compute.storageAdmin` is a legacy role that grants broad storage permissions (including disks and images) but does not specifically allow snapshot creation across projects; it also over-provisions access. Option B is wrong because `roles/viewer` only provides read-only access and cannot create snapshots or write to a bucket. Option D is wrong because `roles/compute.instanceAdmin` on the source project allows managing instances but not creating snapshots of disks; snapshot creation requires `compute.snapshots.create` permission, which is not included in the instanceAdmin role.

Full explanation →

296

MCQhard

You need to drain a GKE node for maintenance. The node runs DaemonSet pods and pods using emptyDir volumes. Which kubectl drain command correctly handles these pods without causing disruption to critical system components?

A.kubectl drain NODE --force

B.kubectl drain NODE --ignore-daemonsets

C.kubectl drain NODE --delete-emptydir-data

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

AnswerD

Draining with `--ignore-daemonsets` leaves DaemonSet pods running, preserving node-level system components, while `--delete-emptydir-data` permits eviction of pods holding emptyDir volumes that would otherwise block the drain. Both flags together satisfy the stem's requirement to handle these pods without disrupting critical components.

Why this answer

The kubectl drain command evicts pods from a node. To handle DaemonSet pods (which should be ignored because they are managed by the DaemonSet controller) and pods with emptyDir volumes (which may need --delete-emptydir-data to force eviction), you use --ignore-daemonsets and --delete-emptydir-data.

Full explanation →

297

MCQmedium

A Cloud Function (gen2) is triggered by Pub/Sub messages. The function processes each message by calling three external APIs sequentially. The total processing time is 25 seconds per message. The Pub/Sub subscription's ack deadline is 10 seconds. What will happen, and how should you fix it?

A.Pub/Sub will wait indefinitely for the function to acknowledge; no issue occurs.

B.Messages will be redelivered before processing completes; extend the Pub/Sub subscription ack deadline to exceed 25 seconds.

C.The Cloud Function will automatically extend its own ack deadline via the Pub/Sub client library.

D.Increase the Cloud Function's memory to process faster and complete within 10 seconds.

AnswerB

In Pub/Sub push delivery, the ack deadline defines how long the service waits for the subscriber to acknowledge. If the Cloud Function runs longer than the subscription's ack deadline (commonly 10 seconds by default), Pub/Sub redelivers the message to another instance before processing finishes. Configure the subscription's ack deadline to a value greater than 25 seconds—for example, 60 seconds—so the function can complete and return 200 OK to acknowledge before any redelivery.

Why this answer

The Pub/Sub subscription has a 10-second ack deadline, but the Cloud Function takes 25 seconds to process each message. Since the function does not acknowledge the message within the deadline, Pub/Sub considers the message unacknowledged and redelivers it, causing duplicate processing. The fix is to increase the ack deadline to exceed 25 seconds, ensuring the function has enough time to complete processing and send an acknowledgment.

Exam trap

The trap here is that candidates assume Cloud Functions automatically handle Pub/Sub ack deadlines or that increasing resources speeds up I/O-bound operations, but the exam tests understanding of the explicit ack deadline configuration and the need to match it to processing time.

How to eliminate wrong answers

Option A is wrong because Pub/Sub does not wait indefinitely; it enforces the ack deadline and redelivers messages if no acknowledgment is received within that time. Option C is wrong because the Cloud Function (gen2) does not automatically extend the ack deadline; the Pub/Sub client library can be used to modify the ack deadline programmatically, but this is not automatic and requires explicit code. Option D is wrong because increasing memory does not reduce processing time for sequential external API calls; the bottleneck is network latency and API response times, not compute speed.

Full explanation →

298

Multi-Selecthard

An organization is designing a VPC network with connectivity to an on-premises network via Cloud VPN. They have multiple projects that need to share the VPN. Which three steps are required to implement this using Shared VPC? (Choose three.)

Select 3 answers

A.Attach the service project to the host project.

B.Create a Cloud VPN gateway in the host project.

C.Configure the VPN tunnels in the host project.

D.Enable the Shared VPC feature in the service project.

E.Create a Cloud Router in the service project.

AnswersA, B, C

Service projects must be attached to the host project to use shared resources.

Why this answer

Attaching the service project to the host project is a fundamental step in Shared VPC. This attachment allows the service project to use the host project's VPC network resources, including the Cloud VPN gateway and tunnels, enabling centralized connectivity without duplicating VPN infrastructure.

Exam trap

Google Cloud often tests the misconception that Shared VPC configuration steps are performed in the service project, but in reality, all networking resources (VPN gateway, tunnels, Cloud Router) must be created in the host project, and the service project is only attached to consume those resources.

Full explanation →

299

Multi-Selecteasy

A developer needs to set up a Google Cloud environment for a new project. Which TWO actions are required to enable billing and APIs for the project?

Select 2 answers

A.Enable the required APIs using the Cloud Console or gcloud.

B.Configure firewall rules before enabling any APIs.

C.Create a billing account and link it to the project.

D.Set up VPC networks for all regions.

E.Assign IAM roles to all users globally.

AnswersA, C

Enabling the required APIs through the Cloud Console or gcloud activates the specific services the project needs, such as Compute Engine or Cloud Storage. This satisfies the stem's API-enablement requirement, which is distinct from linking a billing account.

Why this answer

Option A is correct because enabling the required APIs is a mandatory step to make Google Cloud services available for the project; this can be done via the Cloud Console or with the gcloud command (for example, gcloud services enable). Option C is correct because a project must be associated with an active billing account to use billable services, which is done by creating a billing account and linking it to the project. Option B is incorrect because firewall rules are only needed for specific networking configurations and are not a prerequisite for enabling billing or APIs.

Option D is incorrect because VPC networks are not required for all regions and are unrelated to enabling billing and APIs. Option E is incorrect because assigning IAM roles globally to all users is not a requirement and would violate least-privilege principles.

Exam trap

ACE often tests the misconception that networking (firewall rules, VPCs) or broad IAM assignments are prerequisites for enabling billing and APIs, when the actual requirements are billing linkage and API enablement.

Full explanation →

300

MCQhard

Based on the exhibit, which type of traffic will successfully reach the instance?

A.HTTPS traffic (port 443) from the internet

B.All inbound traffic

C.HTTP traffic from the internet (port 80)

D.No traffic; the deny-all rule takes effect

AnswerC

Inbound HTTP packets have destination TCP port 80 and source IPs in 0.0.0.0/0, which exactly matches the custom ingress allow rule (protocol tcp, ports 80, priority 1000, applied to the instance's network tag). Because priority 1000 is lower than the deny-all rule's 2000, the allow rule is evaluated first and matches, so HTTP is permitted before the deny rule is ever considered. GCP firewall rules are stateful as well, so the return traffic for these HTTP connections is automatically allowed, making HTTP traffic from the internet successful.

Why this answer

The exhibit shows a firewall rule allowing inbound HTTP traffic (port 80) from 0.0.0.0/0, which permits any source on the internet to reach the instance on that port. Firewall rules in Google Cloud are stateful, so the corresponding outbound return traffic is automatically allowed. No other rule permits HTTPS or all traffic, and the implicit deny-all rule blocks anything not explicitly allowed.

Exam trap

Google Cloud often tests the misconception that the implicit deny-all rule blocks all traffic indiscriminately, but candidates must remember that explicit allow rules take precedence and permit matching traffic before the deny rule is evaluated.

How to eliminate wrong answers

Option A is wrong because the security group rules shown only allow TCP port 80 (HTTP), not port 443 (HTTPS); HTTPS traffic would be blocked by the implicit deny-all rule. Option B is wrong because security groups operate on a whitelist model—only explicitly permitted traffic is allowed, and the exhibit does not include a rule allowing all inbound traffic. Option D is wrong because the deny-all rule is the default implicit rule that applies only to traffic not matching an explicit allow rule; since HTTP traffic matches the explicit allow rule on port 80, it is permitted and the deny-all rule does not take effect for that traffic.

Full explanation →

Google Associate Cloud Engineer (ACE) — Questions 226–300