Google Associate Cloud Engineer ACE Questions 451–525 | Page 7/11

451

MCQmedium

A data analytics team runs Apache Spark jobs to process large datasets. They need a managed cluster that provisions quickly, scales dynamically, and integrates with Cloud Storage and BigQuery. Which service should they use?

A.Cloud Dataflow

B.Cloud Dataproc

C.Cloud Composer

D.Cloud Run with a custom Spark container

AnswerB

Cloud Dataproc is the fully managed Apache Spark and Hadoop service on Google Cloud, purpose-built to run Spark jobs at scale. It offers fast cluster provisioning via ephemeral clusters, direct connectors to Cloud Storage and BigQuery for reading and writing data without ETL, and automatically manages the HDFS/YARN infrastructure. Because it is native to Spark and integrates with the Google Cloud ecosystem, it is the correct choice for executing Spark workloads.

Why this answer

Cloud Dataproc is the correct choice because it is a managed Spark and Hadoop service that provisions clusters in under 90 seconds, supports autoscaling, and natively integrates with Cloud Storage (via the gs:// connector) and BigQuery (via the BigQuery Storage API and Spark BigQuery connector). This makes it ideal for teams needing fast, dynamic, and integrated Spark job execution.

Exam trap

The trap here is that candidates confuse Cloud Dataflow (a Beam-based service) with a managed Spark service, or assume Cloud Run can handle dynamic Spark cluster scaling, when in fact only Cloud Dataproc provides the native Spark runtime and auto-scaling cluster management required for this use case.

How to eliminate wrong answers

Option A is wrong because Cloud Dataflow is a unified stream and batch data processing service based on Apache Beam, not Apache Spark, and it does not provide a managed Spark cluster. Option C is wrong because Cloud Composer is a managed Apache Airflow workflow orchestration service, not a compute engine for running Spark jobs; it can trigger Dataproc jobs but does not run Spark itself. Option D is wrong because Cloud Run is a serverless container platform that does not support dynamic cluster scaling for Spark workloads and lacks native integration with Cloud Storage and BigQuery for Spark; running a custom Spark container on Cloud Run would require manual cluster management and does not provide the managed, auto-scaling Spark environment that Dataproc offers.

Full explanation →

452

MCQeasy

Which gcloud CLI command authenticates a developer's local environment with their Google account?

A.gcloud config set account [EMAIL]

B.gcloud auth login

C.gcloud init --authenticate

D.gcloud accounts activate

AnswerB

`gcloud auth login` is the correct way to initiate interactive user authentication via Google's OAuth 2.0 flow. It opens a browser to obtain an access token and refresh token, then securely stores those credentials in your local `~/.config/gcloud/` directory. After this step, all `gcloud` commands automatically use these stored credentials for the active account, eliminating the need to re-authenticate for each command.

Why this answer

`gcloud auth login`, is correct because it initiates the OAuth 2.0 flow to authenticate the gcloud CLI with a user's Google account, storing the resulting credentials locally for subsequent API calls. This command is the standard way to authorize a developer's local environment for the first time or when switching users.

Exam trap

The trap here is that candidates confuse configuration commands (like `gcloud config set account`) with authentication commands, mistakenly thinking setting an account name is sufficient to establish credentials, when in fact it only selects a pre-existing authenticated account.

How to eliminate wrong answers

Option A is wrong because `gcloud config set account [EMAIL]` only sets the active account configuration to an already-authenticated account; it does not perform any authentication or credential acquisition. Option C is wrong because `gcloud init --authenticate` is not a valid gcloud command; `gcloud init` can configure a new environment and optionally trigger authentication, but the `--authenticate` flag does not exist. Option D is wrong because `gcloud accounts activate` is not a valid gcloud command; the correct command to switch between authenticated accounts is `gcloud config set account` or `gcloud auth login` to re-authenticate.

Full explanation →

453

MCQeasy

Which gcloud command creates a Compute Engine VM named 'web-01' using the e2-medium machine type in zone us-central1-a?

A.gcloud vm create web-01 --zone=us-central1-a --machine=e2-medium

B.gcloud compute instances create web-01 --zone=us-central1-a --machine-type=e2-medium

C.gcloud instances create web-01 --region=us-central1 --type=e2-medium

D.gcloud compute create-instance web-01 --zone=us-central1-a --size=e2-medium

AnswerB

This is the correct syntax. 'gcloud compute instances create' targets the Compute Engine service's 'instances' resource and the 'create' verb. The '--zone' flag designates the zonal location for the VM (required if no region-level default), and '--machine-type' specifies the predefined machine type (e.g., 'e2-medium'). This creates an instance in the current project with the given configuration.

Why this answer

The `gcloud compute instances create` command is the proper syntax for creating a Compute Engine VM, and it requires the `--machine-type` flag (not `--machine`) to specify the machine type. The zone is specified with `--zone`, and the VM name is provided as a positional argument.

Exam trap

Google Cloud often tests the exact command syntax, and the trap here is that candidates confuse the `gcloud compute instances create` command with shorter, non-existent variants like `gcloud vm create` or `gcloud instances create`, or they use incorrect flag names like `--machine` or `--size` instead of the correct `--machine-type`.

How to eliminate wrong answers

Option A is wrong because `gcloud vm create` is not a valid gcloud command; the correct resource hierarchy is `gcloud compute instances create`. Additionally, the flag for machine type is `--machine-type`, not `--machine`. Option C is wrong because it uses `--region=us-central1` instead of `--zone=us-central1-a`, and zones are required for VM creation (regions are used for regional resources like managed instance groups).

It also uses `--type=e2-medium` instead of `--machine-type=e2-medium`. Option D is wrong because `gcloud compute create-instance` is not a valid command; the correct verb is `instances create`. It also uses `--size=e2-medium` instead of `--machine-type=e2-medium`.

Full explanation →

454

MCQhard

A financial services company needs to run analytics queries on transaction data that arrives in real-time. The queries must return results within 2 seconds and the dataset grows by ~100 GB per day. The company also needs to retain all data for 7 years for regulatory compliance. Which architecture best satisfies these requirements?

A.Write transactions to Cloud Spanner; run analytics queries directly against Spanner.

B.Stream transactions through Pub/Sub → Dataflow → BigQuery; run analytics on BigQuery.

C.Store transactions in Cloud Bigtable and use Dataproc/Spark for analytics queries.

D.Use Cloud SQL for storage and Cloud Dataprep for analytics transformations.

AnswerB

This is the canonical Google Cloud streaming analytics architecture: Pub/Sub ingests transaction streams asynchronously, Dataflow provides exactly-once, auto-scaling transformations (including windowing and enrichment), and BigQuery stores the results in columnar, partitioned tables. BigQuery's Dremel execution engine and optional BI Engine provide sub-second-to-2-second query performance on recent data, while table partitioning and time-based expiration handle multi-year retention cost-effectively. This serverless pattern avoids managing infrastructure and scales seamlessly from low to very high streaming throughput, making it the only option that meets both the performance and retention requirements.

Why this answer

It uses Pub/Sub for real-time ingestion, Dataflow for stream processing, and BigQuery for analytics, which can handle 100 GB/day growth and return queries within 2 seconds using BigQuery's columnar storage and automatic sharding. BigQuery's 7-year retention is supported by its time-based partitioning and long-term storage at reduced cost, meeting regulatory compliance without manual intervention.

Exam trap

Google Cloud often tests the distinction between OLTP (Spanner, Cloud SQL) and OLAP (BigQuery) services, and candidates mistakenly choose Spanner for analytics because of its global scale and strong consistency, overlooking that it is not optimized for large-scale analytical queries with strict latency SLAs.

How to eliminate wrong answers

Option A is wrong because Cloud Spanner is designed for transactional (OLTP) workloads with strong consistency, not for large-scale analytics (OLAP); running complex analytics queries directly on Spanner would exceed the 2-second latency requirement and incur high costs due to its node-based pricing and row-oriented storage. Option C is wrong because Cloud Bigtable is a NoSQL wide-column store optimized for high-throughput, low-latency point lookups and time-series data, but it lacks native SQL analytics capabilities; using Dataproc/Spark adds overhead for query parsing and job scheduling, making it difficult to consistently return results within 2 seconds, and Bigtable's storage is not cost-effective for 7 years of retention at 100 GB/day. Option D is wrong because Cloud SQL is a relational database with limited scalability (max ~30 TB per instance) and is not designed for real-time streaming or petabyte-scale analytics; Cloud Dataprep is a data preparation tool for cleaning and transforming data, not for running analytics queries, and it cannot meet the 2-second query latency requirement.

Full explanation →

455

MCQmedium

An organization needs to audit all data access (read/write) to a Cloud Storage bucket for compliance. Which type of audit log should they enable?

A.System Event audit logs

B.Access Transparency logs

C.Admin Activity audit logs

D.Data Access audit logs

AnswerD

Data Access audit logs are the correct Cloud Audit Logs category for recording data-plane read/write operations, including Cloud Storage object GETs, BigQuery query reads, and Pub/Sub message publishes/pulls. They are typically disabled by default for most services and must be explicitly enabled for each service in the Audit Logs configuration, after which they deliver the who/what/when trail needed to audit data access across the organization.

Why this answer

Data Access audit logs record read and write operations on user data, including Cloud Storage object reads (e.g., storage.objects.get) and writes (e.g., storage.objects.create). They are specifically designed for auditing data access, unlike Admin Activity logs which capture configuration changes. Therefore, to audit all data access to a bucket, Data Access audit logs must be enabled.

Exam trap

ACE often tests the distinction between Admin Activity and Data Access logs, and candidates frequently confuse configuration changes with data access, leading them to choose Admin Activity logs when data access auditing is required.

How to eliminate wrong answers

Option A is wrong because System Event audit logs capture Google Cloud administrative actions that modify resource configurations, not data access. Option B is wrong because Access Transparency logs record actions taken by Google personnel, not customer data access. Option C is wrong because Admin Activity audit logs record configuration changes (e.g., bucket creation, IAM policy updates) but not data reads or writes.

Full explanation →

456

MCQmedium

A Cloud Run service needs to read secrets from Secret Manager. The service is deployed with a custom runtime service account. Which IAM role should be granted to the runtime service account, and on which resource?

A.Grant `roles/secretmanager.admin` on the project.

B.Grant `roles/secretmanager.secretAccessor` on the specific secret resource.

C.Grant `roles/viewer` on the project.

D.Grant `roles/secretmanager.secretVersionManager` on the secret.

AnswerB

The `roles/secretmanager.secretAccessor` role contains the exact `secretmanager.versions.access` permission required to retrieve the value of a secret version. By binding this role to the specific secret resource rather than the project or the version, the principal is limited to reading only that secret's payload and cannot enumerate or access other secrets. This scoped binding is the standard least-privilege pattern for granting a compute instance or service account access to a single secret.

Why this answer

The principle of least privilege dictates that the runtime service account should only have the minimum permissions required to access the specific secret. The `roles/secretmanager.secretAccessor` role provides exactly the `secretmanager.versions.access` permission needed to read the secret value, and granting it on the specific secret resource (rather than the project) scopes the permission to that secret only, preventing broader access.

Exam trap

Google Cloud often tests the principle of least privilege by offering broad project-level roles (like `roles/secretmanager.admin`) as distractors, tempting candidates to grant excessive permissions instead of scoping the role to the specific secret resource.

How to eliminate wrong answers

Option A is wrong because `roles/secretmanager.admin` grants full administrative control over all secrets in the project, including creating, updating, and deleting secrets, which violates the principle of least privilege and is unnecessary for a service that only needs to read a secret. Option C is wrong because `roles/viewer` is a basic role that provides read-only access to many Google Cloud resources but does not include the specific `secretmanager.versions.access` permission required to read the secret value from Secret Manager. Option D is wrong because `roles/secretmanager.secretVersionManager` includes permissions to manage secret versions (e.g., add, disable, destroy), which is excessive for a service that only needs to read the secret value.

Full explanation →

457

MCQeasy

A company wants to expose a web application running on Compute Engine instances behind a managed instance group. They need a single IP address that distributes incoming HTTP traffic across instances. Which type of load balancer should they use?

A.Internal TCP/UDP Load Balancer

B.External TCP/UDP Network Load Balancer

C.SSL Proxy Load Balancer

D.External HTTP(S) Load Balancer

AnswerD

This global Layer 7 load balancer is purpose-built for HTTP and HTTPS traffic, supporting URL path and host-based routing, SSL termination, and integration with Cloud CDN. It provides a single external anycast IP address to all clients and intelligently distributes requests to backend web servers. This meets the company's requirement to expose an external web application with a single IP.

Why this answer

The External HTTP(S) Load Balancer is a regional or global, proxy-based Layer 7 load balancer that provides a single external IP address for distributing incoming HTTP traffic across Compute Engine instances in a managed instance group. It supports HTTP and HTTPS protocols, health checks, and autoscaling, making it ideal for web applications.

Exam trap

The trap here is that candidates often confuse the External HTTP(S) Load Balancer with the External TCP/UDP Network Load Balancer, mistakenly thinking that any load balancer with an external IP can handle HTTP traffic, but the Network Load Balancer lacks Layer 7 features and is not optimized for HTTP workloads.

How to eliminate wrong answers

Option A is wrong because the Internal TCP/UDP Load Balancer is used for internal traffic within a VPC network, not for exposing a web application to the internet. Option B is wrong because the External TCP/UDP Network Load Balancer is a Layer 4 load balancer that forwards traffic based on IP and port, but it does not support HTTP-specific features like URL routing or SSL termination, and it is not the recommended choice for HTTP traffic distribution. Option C is wrong because the SSL Proxy Load Balancer is designed for terminating SSL/TLS connections and forwarding TCP traffic, but it does not handle HTTP protocol inspection or routing, and it is not the standard choice for distributing HTTP traffic.

Full explanation →

458

MCQeasy

A company wants to migrate an on-premises MySQL database to Cloud SQL with minimal downtime. Which service should they use?

A.Cloud SQL for MySQL

B.Cloud SQL with external replicas

C.Database Migration Service

D.Compute Engine with MySQL installed

AnswerC

Database Migration Service is the correct answer because it is a fully managed service that migrates MySQL (and other databases) from an on-premises source to Cloud SQL with minimal downtime. It works by taking an initial consistent snapshot of your source database, then continuously applying ongoing changes via the source's binary logging (binlog) until you're ready for a one-time cutover. This eliminates the need to manually coordinate export and import jobs, and it keeps your application online for the vast majority of the migration window.

Why this answer

Database Migration Service (DMS) is the correct choice because it is specifically designed to migrate on-premises MySQL databases to Cloud SQL with minimal downtime using continuous replication. It handles schema conversion, data transfer, and ongoing sync until you cut over, ensuring near-zero downtime without manual intervention.

Exam trap

The trap here is that candidates confuse the target service (Cloud SQL for MySQL) with the migration tool, or assume that external replicas can be used for migration, when in fact DMS is the only Google Cloud service purpose-built for minimal-downtime database migrations.

How to eliminate wrong answers

Option A is wrong because Cloud SQL for MySQL is the target service, not a migration tool; selecting it alone does not provide a migration mechanism or minimize downtime. Option B is wrong because Cloud SQL with external replicas is a high-availability or read-scaling feature, not a migration service; it cannot perform the initial data load or continuous replication from an on-premises source. Option D is wrong because Compute Engine with MySQL installed is a manual lift-and-shift approach that requires custom scripting, downtime for data export/import, and lacks automated replication, making minimal downtime difficult to achieve.

Full explanation →

459

MCQeasy

You need to store application logs from a Compute Engine instance in a way that allows you to search and analyze them later. The logs should be retained for 30 days. Which Google Cloud service should you use?

A.BigQuery

B.Cloud Logging

C.Cloud Storage

D.Cloud Monitoring

AnswerB

Cloud Logging is a fully managed service that ingests, stores, and allows you to search and analyze logs from Google Cloud resources, including Compute Engine instances. By default, logs are retained for 30 days, which matches the requirement. You can also create log sinks to export logs for longer retention if needed, but for the stated 30-day period, Cloud Logging alone is sufficient.

Why this answer

Cloud Logging is the native Google Cloud service for log ingestion, storage, and analysis. It automatically collects logs from Compute Engine instances and other resources, retains them for 30 days by default, and provides a powerful query language for searching. Other services like Cloud Storage or BigQuery can be used for export, but they are not designed for direct log management.

Exam trap

The trap here is confusing Cloud Monitoring with Cloud Logging; Monitoring is for metrics and alerting, while Logging is specifically for logs.

Full explanation →

460

MCQeasy

A company is deploying a GKE cluster in a new VPC. The cluster nodes need to communicate with a Cloud SQL instance that has a private IP address. The company wants to minimize data transfer costs and avoid using public IPs. What is the most cost-effective configuration?

A.Create a VPC-native cluster with private nodes and configure Private Service Access for Cloud SQL.

B.Create a cluster with public nodes and set up a Cloud VPN tunnel to Cloud SQL.

C.Create a VPC-native cluster with public nodes and whitelist the node IPs in Cloud SQL authorized networks.

D.Create a cluster with public nodes and use Cloud NAT for outbound traffic.

AnswerA

A VPC-native cluster with private nodes keeps pod and node traffic on internal addresses, and Private Service Access reaches Cloud SQL's private IP over the same VPC peering, avoiding public IPs and egress charges. This satisfies the cost and no-public-IP constraints.

Why this answer

Creating a VPC-native cluster with private nodes and configuring Private Service Access for Cloud SQL is the most cost-effective configuration because it keeps all traffic within the private network, avoids public IPs, and minimizes data transfer costs. Private Service Access allows direct private connectivity between the GKE cluster and Cloud SQL without additional network components.

Exam trap

The trap here is assuming that public nodes with whitelisting or VPN are sufficient, but they incur higher costs and are less secure; candidates might overlook Private Service Access as the native, cost-effective solution for private connectivity to Cloud SQL.

How to eliminate wrong answers

Option B is wrong because using public nodes and a Cloud VPN tunnel introduces additional cost and complexity, and public nodes may incur egress charges. Option C is wrong because public nodes with whitelisted IPs still use public internet for communication, which can incur data transfer costs and is less secure. Option D is wrong because public nodes with Cloud NAT for outbound traffic still require public IPs for nodes and may incur NAT costs, and it does not provide private connectivity to Cloud SQL.

Full explanation →

461

MCQmedium

A company is using Cloud NAT to allow private instances to access the internet. However, they notice that traffic from different instances appears to come from the same external IP address. What is the reason?

A.Cloud NAT is not configured correctly; traffic should come from different IPs.

B.Cloud NAT uses a single external IP by default unless you specify multiple.

C.The instances are using a shared VPC so NAT IP is shared.

D.Each instance is assigned a unique external IP by Cloud NAT.

AnswerB

When you create a Cloud NAT on a Cloud Router, the default address allocation is exactly one external IP address for the entire NAT gateway, unless you manually add more. This sole IP is used as the source address for all outbound connections from every instance in the subnets using that gateway. Therefore, the observed single source IP is the correct, expected result of the default NAT configuration.

Why this answer

Cloud NAT uses a source network address translation (SNAT) configuration that, by default, maps all outbound traffic from instances in a VPC network to a single external IP address. This is the expected behavior unless you explicitly configure multiple NAT IP addresses in a NAT gateway or use a Cloud Router with custom SNAT settings. Option B correctly identifies that Cloud NAT defaults to a single external IP unless you specify multiple.

Exam trap

Google Cloud often tests the misconception that Cloud NAT should assign unique external IPs per instance (like a public IP on a VM), when in fact the default behavior is SNAT with a single shared IP, and candidates may incorrectly assume a misconfiguration or shared VPC is the cause.

How to eliminate wrong answers

Option A is wrong because Cloud NAT is designed to allow multiple instances to share one or more external IPs; traffic appearing from the same IP is not a misconfiguration but the default behavior. Option C is wrong because a shared VPC does not inherently cause NAT IP sharing—Cloud NAT is configured per VPC network or subnetwork, and the IP sharing is a function of the NAT gateway's IP pool, not the VPC architecture. Option D is wrong because Cloud NAT does not assign unique external IPs to each instance; it performs SNAT so that all outbound traffic from the NAT gateway's configured IP range appears to originate from the same IP (or set of IPs) rather than per-instance.

Full explanation →

462

MCQhard

A data engineering team is deploying a streaming Dataflow pipeline that reads from Pub/Sub and writes to BigQuery. They need to ensure that each event is processed exactly once, even in the event of failures. Which Dataflow feature should they use?

A.Enable at-least-once delivery on the Pub/Sub subscription

B.Set the Dataflow pipeline to use the 'exactly_once' parameter in the pipeline options

C.Rely on Dataflow's exactly-once processing guarantees

D.Use Cloud Functions to deduplicate messages before sending to Dataflow

AnswerC

Dataflow's streaming engine provides exactly-once processing guarantees by checkpointing pipeline state and input cursors into durable cloud storage and by committing each input element exactly once to that state. Because Dataflow is built on the Apache Beam model, it handles deduplication automatically even when the source, such as Pub/Sub, has at-least-once delivery semantics; no additional pipeline settings are required.

Why this answer

Dataflow's streaming engine provides built-in exactly-once processing guarantees for sources like Pub/Sub and sinks like BigQuery. This is achieved through a combination of checkpointing, deterministic replay, and idempotent writes, ensuring that each record is processed exactly once even during worker failures or pipeline updates. No additional configuration or external deduplication is required.

Exam trap

Google Cloud often tests the misconception that exactly-once processing requires explicit configuration or external deduplication, when in fact Dataflow provides it as a default behavior for supported sources and sinks.

How to eliminate wrong answers

Option A is wrong because enabling at-least-once delivery on the Pub/Sub subscription would allow duplicate deliveries, which contradicts the requirement for exactly-once processing. Option B is wrong because there is no 'exactly_once' parameter in Dataflow pipeline options; Dataflow's exactly-once behavior is inherent to the service and not controlled by a pipeline option. Option D is wrong because using Cloud Functions to deduplicate messages before sending to Dataflow adds complexity and latency, and Dataflow already handles exactly-once processing natively without needing external deduplication.

Full explanation →

463

MCQeasy

Your company recently migrated to GCP and you are the new cloud administrator. You need to ensure that only specific members of the DevOps team can perform administrative actions on Compute Engine instances, such as starting, stopping, and resetting instances, but not creating or deleting them. You also want to prevent them from modifying firewall rules or other network settings. The team consists of 10 members. You have already created a custom role with the necessary permissions and assigned it to a Google Group that contains all team members. However, you receive a report that a team member was able to accidentally delete a production instance. Upon investigation, you find that the team member had been granted the roles/compute.instanceAdmin role in addition to your custom role by another administrator. What should be the best course of action to prevent this from happening again while still allowing the team to perform their intended tasks?

A.Remove the compute.instanceAdmin role from the team member and audit all user assignments for role conflicts.

B.Create an organization policy to block deletion of compute instances.

C.Remove the custom role from the team member and keep only the compute.instanceAdmin role.

D.Use IAM conditions on the custom role to enforce that instances can only be stopped during business hours.

AnswerA

Removing the compute.instanceAdmin role from the team member is the correct remediation because that role contains the instances.delete permission, which directly conflicts with the custom role's intent to allow only stop/start actions. Auditing all user assignments afterward is essential to catch similar role conflicts where a broader predefined role may override a more restrictive custom role, ensuring least privilege across the project.

Why this answer

The core issue is that the team member had an additional, more permissive role (roles/compute.instanceAdmin) that overrode the restrictions of your custom role. Removing that conflicting role from the specific user and auditing all assignments ensures that only the intended permissions are applied, preventing accidental deletions while preserving the team's ability to start, stop, and reset instances.

Exam trap

Google Cloud often tests the misconception that you can simply 'block' a specific action (like deletion) via a policy or condition, rather than understanding that IAM permissions are additive and the only way to prevent an action is to remove the role that grants it.

How to eliminate wrong answers

Option B is wrong because an organization policy to block deletion of compute instances would prevent all users, including legitimate administrators, from deleting instances, which is overly restrictive and does not address the root cause of conflicting role assignments. Option C is wrong because removing the custom role and keeping only compute.instanceAdmin would grant the team full administrative access, including the ability to create and delete instances and modify firewall rules, which directly violates the requirement to restrict those actions. Option D is wrong because IAM conditions that restrict stopping instances to business hours do not prevent deletion; they address a different constraint and do not resolve the conflict between the custom role and the compute.instanceAdmin role.

Full explanation →

464

MCQhard

A company is extending its on-premises network to Google Cloud using a Cloud VPN tunnel with dynamic routing (BGP). They have set up a Cloud Router in the VPN region. Which additional step is required for the Cloud Router to exchange routes with the on-premises router?

A.Create a static route for the on-premises network on the VPC

B.Configure a BGP session on the Cloud Router with the on-premises router's ASN and IP address

C.Assign an external IP address to the Cloud Router

D.Enable the IP forwarding feature on the VPN gateway

AnswerB

Configuring a BGP session on the Cloud Router with the on-premises router's ASN and IP address is the correct step because Cloud Router is a BGP speaker that must peer with the on-premises router over the VPN tunnel. Without explicitly configuring the peer ASN and IP address, the Cloud Router has no way to establish the BGP adjacency, which is essential for dynamically exchanging network routes. This configuration enables automatic route learning and failover, aligning with the requirement to extend the network using BGP.

Why this answer

For a Cloud VPN with dynamic routing (BGP), the Cloud Router must have a BGP session configured with the on-premises router. This session requires the on-premises router's ASN and its BGP peer IP address to exchange routes. Without this explicit BGP session configuration, the Cloud Router cannot establish a peering relationship or advertise/learn routes dynamically.

Exam trap

The trap here is that candidates often think Cloud Routers need an external IP (Option C) because they confuse Cloud Router with a physical router, but Cloud Routers are software-defined and communicate over the VPN tunnel using internal IPs.

How to eliminate wrong answers

Option A is wrong because creating a static route for the on-premises network on the VPC is unnecessary when using dynamic routing (BGP); BGP automatically exchanges routes, and static routes would conflict or be redundant. Option C is wrong because Cloud Routers do not require an external IP address; they operate within the VPC and communicate with the on-premises router via the VPN tunnel's internal IP addresses. Option D is wrong because IP forwarding is a VM-level setting (for instances acting as routers) and is not relevant to a Cloud VPN gateway; the VPN gateway inherently forwards traffic based on the routing table and BGP-learned routes.

Full explanation →

465

Multi-Selecthard

You are deploying a high-traffic web application on GKE. You need to automatically scale the number of pods based on CPU utilization. Which THREE steps are required to set up Horizontal Pod Autoscaling (HPA)?

Select 3 answers

A.Install the metrics-server in the cluster.

B.Enable Stackdriver Monitoring for the cluster.

C.Create a HorizontalPodAutoscaler resource (e.g., via kubectl autoscale).

D.Create a Deployment with resource requests for CPU.

E.Expose the Deployment as a Service of type LoadBalancer.

AnswersA, C, D

The metrics-server aggregates CPU and memory usage from kubelets via the Summary API and exposes them through the metrics.k8s.io API. The HorizontalPodAutoscaler (HPA) controller repeatedly queries that API to obtain current resource utilization; if no metrics-server is installed, the metrics API is unavailable and the HPA reports 'unable to retrieve metrics' and does not scale. It is the lightweight, cluster-local component that provides the raw numbers the HPA needs, whereas GCP's monitoring service is not directly consulted by the HPA.

Why this answer

To use HPA, you need a deployment (or other scalable resource), you need to apply the HPA resource (e.g., via kubectl autoscale), and you must have metrics-server installed to provide metrics. Creating a service is optional.

Full explanation →

466

MCQhard

An organization needs to deploy a microservices application on Google Kubernetes Engine. Each microservice has different resource requirements, and the team wants to optimize costs by using a mix of spot (preemptible) and regular nodes. They also need to ensure that critical services run on regular nodes. Which GKE feature allows this separation?

A.Use resource quotas to limit namespace resource usage

B.Use separate clusters for critical and non-critical services

C.Use node pools with taints and tolerations on the pods

D.Use vertical pod autoscaling

AnswerC

Create two node pools, e.g. a regular pool for critical services and a spot/preemptible pool for non-critical work, then taint the spot pool with a key such as spot=true:NoSchedule. Critical pods are deployed without the matching toleration, so the Kubernetes scheduler will never place them on spot nodes; non-critical pods include the toleration and can use the cheaper spot capacity. This precisely controls placement while keeping a single cluster and simplifying operations.

Why this answer

Node pools with taints and tolerations allow you to dedicate a pool of regular (non-preemptible) nodes to critical services by applying a taint to those nodes and a matching toleration only to the critical pods. Non-critical pods without the toleration will be scheduled onto spot node pools, achieving both cost optimization and workload separation.

Exam trap

The trap is choosing 'separate clusters' because it sounds like the cleanest separation — but the question asks for a GKE feature that enables separation within a deployment, and taints/tolerations with node pools is the native, cost-effective answer.

How to eliminate wrong answers

Option A is wrong because resource quotas limit aggregate CPU/memory/object counts per namespace — they do not control which node type a pod lands on. Option B is wrong because separate clusters for critical and non-critical services is operationally heavier and does not leverage GKE's native scheduling controls; it also increases management overhead and cost, defeating the optimization goal. Option D is wrong because vertical pod autoscaling adjusts a pod's CPU/memory requests based on usage — it has nothing to do with node selection or spot vs. regular node placement.

Full explanation →

467

Multi-Selecthard

You are deploying a new version of a microservice to Google Kubernetes Engine (GKE). You want to minimize downtime and ensure that traffic is only routed to pods that are ready to serve requests. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Configure a readiness probe for the pods.

B.Configure a liveness probe for the pods.

C.Expose the deployment using a LoadBalancer service.

D.Set the pod's restartPolicy to Always.

E.Use a rolling update strategy with maxSurge and maxUnavailable.

AnswersA, E

A readiness probe determines whether a pod is ready to accept traffic. When a pod fails the readiness probe, it is removed from the Service's endpoints, preventing traffic from being routed to it. This ensures that only healthy pods receive requests, which is essential for zero-downtime deployments and maintaining service availability during updates.

Why this answer

To minimize downtime during a deployment, you need both a readiness probe and a rolling update strategy. Readiness probes ensure that only pods that are ready to serve traffic are added to the Service's endpoints, while rolling updates gradually replace old pods with new ones, maintaining availability. Together, they prevent traffic from reaching unready pods and ensure a smooth transition.

Exam trap

The trap here is focusing on liveness probes or restart policies, which handle container restarts but do not control traffic routing during deployments.

Full explanation →

468

MCQhard

A Cloud Build pipeline builds a container image and pushes it to Artifact Registry. The next step needs to deploy the image to Cloud Run. The pipeline runs as the Cloud Build service account. What minimum permission does the Cloud Build SA need for the deployment step?

A.`roles/run.admin` only.

B.`roles/run.admin` and `roles/iam.serviceAccountUser` on the Cloud Run runtime service account.

C.`roles/owner` to ensure all necessary permissions are covered.

D.`roles/cloudbuild.builds.editor` on the Cloud Run project.

AnswerB

This is correct because Cloud Build's service account needs two distinct permissions to deploy to Cloud Run: `roles/run.admin` to create, update, and manage the Cloud Run service and its revisions, and `roles/iam.serviceAccountUser` granted on the runtime service account itself. The `iam.serviceAccountUser` role includes the `iam.serviceAccounts.actAs` permission, which allows the Cloud Build SA to specify that runtime SA when creating or updating a Cloud Run service. This pairing follows least privilege by giving exactly the permissions needed, no more.

Why this answer

The Cloud Build service account needs `roles/run.admin` to deploy services to Cloud Run, but it also requires `roles/iam.serviceAccountUser` on the Cloud Run runtime service account (the identity the Cloud Run service runs as) because the deployment step impersonates that runtime service account to create or update the service. Without the `iam.serviceAccountUser` permission, the deployment fails with a permission denied error, even if the Cloud Build SA has full Cloud Run admin rights.

Exam trap

Google Cloud often tests the nuance that deploying to Cloud Run requires not just Cloud Run permissions but also the ability to impersonate the runtime service account, leading candidates to incorrectly choose `roles/run.admin` alone.

How to eliminate wrong answers

Option A is wrong because `roles/run.admin` alone does not grant the Cloud Build service account the ability to impersonate the Cloud Run runtime service account; the `iam.serviceAccountUser` role is required on that runtime service account for the deployment to succeed. Option C is wrong because `roles/owner` is overly permissive and violates the principle of least privilege; the minimum permissions are `roles/run.admin` and `roles/iam.serviceAccountUser` on the runtime service account, not full project ownership. Option D is wrong because `roles/cloudbuild.builds.editor` only allows managing Cloud Build builds, not deploying to Cloud Run; it does not include any Cloud Run or IAM impersonation permissions.

Full explanation →

469

Multi-Selectmedium

You need to view the current gcloud configuration settings, including the active account, project, and compute region. Which TWO commands can you use? (Choose two.)

Select 2 answers

A.gcloud config list

B.gcloud config describe

C.gcloud projects list

D.gcloud auth list

E.gcloud info

AnswersA, E

Running `gcloud config list` displays all the active property settings in your current gcloud configuration, such as account, project, and compute region/zone, in a clean key=value format. You can use `gcloud config list --all` to view every settable property, including those with unset defaults. This is the standard, most direct way to inspect your working configuration.

Why this answer

gcloud config list displays all configuration properties. gcloud info provides detailed information, including configuration.

Full explanation →

470

Multi-Selecthard

An engineer is troubleshooting a Compute Engine instance that is unreachable via SSH. They suspect a firewall rule is blocking traffic. Which TWO actions should they take to diagnose the issue? (Choose 2)

Select 2 answers

A.Create a Cloud Monitoring alert for packet loss

B.View Cloud Logging for firewall rule logs

C.Run gcloud compute ssh --dry-run

D.Use Cloud Trace to analyze network latency

E.Check VPC firewall rules in Cloud Console

AnswersB, E

Viewing Cloud Logging for firewall rule logs is the direct way to see whether VPC firewall rules are dropping or allowing traffic. Firewall rule logging records each connection attempt with details like source IP, destination IP, port, protocol, and the action (allow or deny). If the Compute Engine instance is unreachable due to a firewall rule, these logs will show the denied packets, making this a reliable troubleshooting step.

Why this answer

In Cloud Logging, you can view firewall logs (if VPC flow logs are enabled, but firewall rules logging can be enabled per rule). Checking VPC firewall rules in the Cloud Console allows you to verify the rules. Cloud Trace is for latency, Cloud Monitoring for metrics, and gcloud compute ssh is for connecting, not diagnosing firewall rules.

Full explanation →

471

Multi-Selecteasy

A company is implementing cost optimization for their Google Cloud resources. Which two practices are recommended? (Choose two.)

Select 2 answers

A.Keep all resources in a single region to avoid data transfer costs.

B.Always use premium-tier networking for all traffic.

C.Use committed use discounts for predictable workloads.

D.Use preemptible VMs for all batch jobs irrespective of fault tolerance.

E.Delete unused static external IP addresses.

AnswersC, E

Committed use discounts (CUDs) are a cost-optimization tool that offer up to 70% lower vCPU, memory, and GPU prices for predictable workloads when you commit to 1- or 3-year usage. This aligns with cost optimization because steady-state baseline resources are paid at a large discount, and the commitment safeguards you against future price increases. However, CUDs are only effective if usage is consistent; they should be matched to historical baseline usage, not spikes.

Why this answer

Committed use discounts (CUDs) are recommended for cost optimization because they provide significant discounts (up to 70% for vCPUs and memory) in exchange for a commitment to use a minimum level of resources (e.g., 1-year or 3-year term) for predictable workloads. This aligns costs with actual usage patterns, reducing waste from on-demand pricing. Deleting unused static external IP addresses is also recommended because each static IP incurs a small hourly charge (e.g., $0.005/hour for a regional IP) even when not attached to a resource, so removing them eliminates unnecessary costs.

Exam trap

The trap here is that candidates often assume 'single region' avoids all data transfer costs (ignoring cross-zone charges) or that preemptible VMs are safe for any batch job, but the ACE exam tests the nuance that preemptible VMs require fault tolerance and that static IPs have ongoing costs even when idle.

Full explanation →

472

MCQmedium

A startup is building a web application using Cloud Run. They want to deploy multiple independent services that can communicate with each other internally, but each service should be deployed and scaled independently. Which deployment strategy should they use?

A.Create multiple Cloud Run services and use internal endpoints for communication

B.Deploy the application to App Engine Standard Environment

C.Use a single GKE cluster with multiple deployments and services

D.Deploy a single Cloud Run service with multiple containers

AnswerA

Each Cloud Run service is an independently managed, container-based microservice that autoscales from zero based on its own traffic, so building multiple services naturally satisfies the independent scaling and deployment requirement. Cloud Run provides internal HTTPS endpoints (such as the automatically generated per-service URL or requests routed through a VPC connector) that allow services to communicate without exposing traffic to the public internet. You can also use Cloud Run's service-to-service authentication to restrict calls between trusted services, ensuring secure and low-latency internal communication.

Why this answer

Cloud Run natively supports deploying multiple independent services, each with its own URL and scaling configuration. Internal communication between these services can be achieved using Cloud Run's built-in internal endpoints (e.g., using the `run.app` domain with internal traffic routing), which avoids exposing services to the public internet. This approach allows each service to scale independently based on its own request load, meeting the startup's requirement for independent deployment and scaling.

Exam trap

Google Cloud often tests the misconception that Cloud Run supports multiple containers per service (like a pod in Kubernetes), but Cloud Run services are single-container per revision, and multiple containers require separate services or a different platform like Cloud Run for Anthos.

How to eliminate wrong answers

Option B is wrong because App Engine Standard Environment is a fully managed platform that deploys a single application as a monolithic service; it does not natively support deploying multiple independent services that scale independently within the same project without using additional modules or services, which adds complexity and does not match the requirement for independent scaling. Option C is wrong because using a single GKE cluster with multiple deployments and services introduces the overhead of managing a Kubernetes cluster (node pools, networking, etc.) and is overkill for a simple web application; Cloud Run abstracts away cluster management entirely, making it a simpler and more cost-effective choice for independent services. Option D is wrong because a single Cloud Run service can only run one container per revision; multiple containers within a single service would share the same scaling behavior and cannot be deployed or scaled independently, which directly contradicts the requirement.

Full explanation →

473

Matchingmedium

Match each IAM role to its typical access level.

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

Concepts

Matches

Read-only access to resources

Read and modify resources

Full access including IAM management

Read access to browse the hierarchy

Read access to IAM policies

Why these pairings

IAM roles in GCP have predefined permissions: Viewer (read-only), Editor (read/write but no IAM), Owner (full control). Security Admin is a separate role for managing security policies.

Full explanation →

474

MCQmedium

A company is deploying a public-facing web application on Compute Engine behind a global HTTP(S) Load Balancer. The company wants to protect the application from common web attacks, such as SQL injection and cross-site scripting (XSS). Which Google Cloud security service should they enable?

A.VPC Service Controls

B.Cloud Armor

C.Cloud IDS

D.Identity and Access Management (IAM)

AnswerB

Cloud Armor provides edge security policies on the global HTTP(S) Load Balancer, with preconfigured WAF rules that block SQL injection and XSS at layer 7. It satisfies the requirement to filter common web attacks before traffic reaches the Compute Engine backends.

Why this answer

Cloud Armor is Google Cloud's web application firewall (WAF) and DDoS protection service that integrates with global external HTTP(S) Load Balancers. It provides preconfigured WAF rules based on the OWASP ModSecurity Core Rule Set to block SQL injection, XSS, and other common attacks, plus custom rules and adaptive protection. Enabling Cloud Armor on the load balancer's backend service is the correct way to filter malicious HTTP traffic.

Exam trap

ACE often tests the difference between Cloud Armor (L7 WAF for web attacks) and Cloud IDS (L3/L4 network intrusion detection) — candidates pick Cloud IDS because it sounds like it 'detects attacks,' but the requirement is to block SQLi/XSS at the application layer.

How to eliminate wrong answers

Option A is wrong because VPC Service Controls creates security perimeters around Google Cloud APIs and services to prevent data exfiltration, not to inspect HTTP payloads for SQLi/XSS. Option C is wrong because Cloud IDS is a network intrusion detection system that inspects traffic for malware and network-level threats, but it detects rather than blocks web application attacks at layer 7. Option D is wrong because IAM controls identity and authorization for Google Cloud resources, not the content of HTTP requests.

Full explanation →

475

MCQhard

You need to perform a rolling update of a GKE deployment and ensure that during the update, the new pods are ready before terminating the old ones. You have already set the update strategy to RollingUpdate. Which kubectl command sequence should you use to update the image and monitor the rollout?

A.gcloud container clusters upgrade my-cluster; kubectl get deployments

B.kubectl set image deployment/myapp myapp=gcr.io/myproject/myapp:v2; kubectl rollout status deployment/myapp

C.kubectl edit deployment myapp; kubectl get pods; kubectl delete pod old-pod

D.kubectl apply -f deployment.yaml; kubectl rollout undo deployment/myapp

AnswerB

kubectl set image updates the Deployment's pod template to gcr.io/myproject/myapp:v2, which triggers the Deployment controller to create a new ReplicaSet and incrementally replace old pods while respecting maxSurge/maxUnavailable. kubectl rollout status then blocks until the new ReplicaSet becomes ready and the old ReplicaSet is scaled down, confirming the rolling update completed successfully. This is the standard declarative workflow for updating an app version.

Why this answer

`kubectl set image` updates the container image on the deployment, which triggers the RollingUpdate strategy to create new pods and only terminate old ones once the new pods pass readiness probes. `kubectl rollout status` then blocks and reports the progress of that rollout until it completes or fails. Together they satisfy both the update and monitoring requirements.

Exam trap

ACE often tests the difference between updating a workload (`set image`) and rolling back (`rollout undo`), so candidates who see 'rollout' and grab the undo command pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because `gcloud container clusters upgrade` upgrades the GKE control plane or node version, not a workload's container image, and `kubectl get deployments` gives only a snapshot, not rollout progress. Option C is wrong because manually editing and deleting pods bypasses the controlled RollingUpdate and risks downtime; it also does not monitor rollout status. Option D is wrong because `kubectl rollout undo` rolls back to a previous revision, which is the opposite of performing the update.

Full explanation →

476

MCQmedium

A DevOps engineer creates a service account for a CI/CD pipeline. The pipeline needs to push container images to Artifact Registry. Which role grants the minimum required permission?

A.Artifact Registry Administrator

B.Artifact Registry Writer

C.Storage Object Creator on the underlying Cloud Storage bucket

D.Artifact Registry Reader

AnswerB

Artifact Registry Writer (roles/artifactregistry.writer) is the correct predefined role for a CI/CD pipeline that needs to push container images or packages. It grants exactly the permissions required to upload artifacts—e.g., artifactregistry.versions.create, artifactregistry.files.create, and artifactregistry.tags.create—without allowing destructive actions like deleting repositories or altering IAM policies. This aligns with least privilege because the pipeline only needs write access on an existing repository, not administrative control.

Why this answer

The Artifact Registry Writer role provides the minimal permissions needed to push container images to Artifact Registry, specifically the `artifactregistry.writer` permission. This role allows writing artifacts without granting broader administrative or read-only access, aligning with the principle of least privilege.

Exam trap

Google Cloud often tests the misconception that Artifact Registry is just a wrapper around Cloud Storage, leading candidates to choose Storage Object Creator, but in reality, Artifact Registry uses its own IAM roles and does not expose the underlying bucket for direct permission assignment.

How to eliminate wrong answers

Option A is wrong because Artifact Registry Administrator grants full control over all Artifact Registry resources, including deletion and permission management, which is excessive for a CI/CD pipeline that only needs to push images. Option C is wrong because Artifact Registry does not expose its underlying Cloud Storage bucket directly; permissions must be managed through Artifact Registry roles, not Storage Object Creator, which would not work due to the service's abstraction layer. Option D is wrong because Artifact Registry Reader only allows reading and listing artifacts, not writing or pushing new images.

Full explanation →

477

MCQmedium

An organization wants to use Cloud Storage to host a static website. The bucket name must match the domain name. They already own the domain 'example.com' and want to serve the site from 'www.example.com'. Which bucket name should they create?

A.example.com

B.www_example_com

C.example-com-bucket

D.www.example.com

AnswerD

The bucket must be named exactly www.example.com to serve content from that custom domain. When you create a bucket with this name, verify the domain in Cloud Console, and add a CNAME record from www.example.com to c.storage.googleapis.com, Cloud Storage automatically maps the bucket to the hostname. This exact match is required for HTTPS and proper static site hosting.

Why this answer

For Cloud Storage static website hosting, the bucket name must exactly match the domain used to serve the site. Since the site will be served from 'www.example.com', the bucket must be named 'www.example.com'. GCS requires globally unique bucket names, and the CNAME/A record for the domain must point to the bucket.

Exam trap

The trap here is assuming the bucket should be named after the apex domain ('example.com') rather than the exact hostname being served ('www.example.com') — candidates forget that GCS matches the Host header to the bucket name character-for-character.

How to eliminate wrong answers

Option A is wrong because 'example.com' would serve the apex domain, not the requested 'www.example.com' subdomain — the bucket name must match the hostname in the request. Option B is wrong because underscores are not valid characters in GCS bucket names (only lowercase letters, numbers, hyphens, and dots), and it does not match the domain anyway. Option C is wrong because the bucket name must exactly equal the domain name; 'example-com-bucket' does not match 'www.example.com' and would not serve the site correctly.

Full explanation →

478

MCQeasy

A company wants to automate the rotation of encryption keys for Cloud Storage buckets every 30 days. Which key type should be used?

A.Customer-Managed Encryption Keys (CMEK)

B.Google-managed encryption keys

C.Key Access Justification

D.Customer-Supplied Encryption Keys (CSEK)

AnswerA

Customer-Managed Encryption Keys (CMEK) is correct because it lets you control and automate key rotation through Cloud KMS. You define a rotation period (e.g., 30 days) on a key, and Cloud KMS automatically generates a new key version on that schedule while continuing to decrypt data with older versions. This provides both automated rotation and full auditability of when each version is used, which aligns with a company's requirement to rotate encryption keys without manual intervention.

Why this answer

Customer-Managed Encryption Keys (CMEK) allow the customer to control the key lifecycle, including rotation, through Cloud KMS. Because the customer owns and manages the key in KMS, they can set a rotation schedule (e.g., every 30 days) and automate it. Google-managed keys are rotated automatically by Google on a schedule the customer cannot control, and CSEK keys are supplied per-request and cannot be rotated by a schedule.

Exam trap

The trap is assuming that setting a rotation schedule on CMEK automatically re-encrypts existing data — it does not; rotation only creates new key versions, and existing objects must be rewritten to use them.

How to eliminate wrong answers

Option B is wrong because Google-managed encryption keys are rotated automatically by Google on Google's schedule, and the customer has no ability to set or automate a 30-day rotation policy. Option C is wrong because Key Access Justification is a control that provides justification for key access requests (an audit/access-transparency feature), not a key type used for encryption or rotation. Option D is wrong because Customer-Supplied Encryption Keys (CSEK) are provided with each API request and are not stored in Cloud KMS, so there is no built-in rotation mechanism — the customer would have to re-encrypt objects manually.

Full explanation →

479

MCQeasy

A small business is deploying a web application on Compute Engine and wants to ensure high availability. They have set up two instances in different zones behind a TCP load balancer. What should they also configure to detect and route traffic away from unhealthy instances?

A.Configure a health check on the load balancer.

B.Set a firewall rule to allow traffic only on port 80.

C.Use a global HTTP(S) load balancer instead.

D.Create a snapshot schedule for the persistent disks.

AnswerA

Configuring a health check on the load balancer enables scheduled probes to be sent to each backend instance on a designated port and path. If an instance fails to respond with the expected status code or TCP handshake after multiple attempts, it is automatically removed from the load balancer's backend pool. This stops new traffic from being routed to a failed or overloaded instance, which is exactly the detection required in this scenario.

Why this answer

A health check is required for the TCP load balancer to monitor the backend instances. It periodically probes the instances on a specified port and path, marking them as unhealthy if they fail to respond. The load balancer then stops routing new traffic to unhealthy instances, ensuring high availability by directing traffic only to healthy backends.

Exam trap

The trap here is that candidates often confuse health checks with firewall rules or backup strategies, thinking that allowing traffic or creating snapshots ensures availability, but only health checks provide the active monitoring needed to detect and route around failures.

How to eliminate wrong answers

Option B is wrong because a firewall rule allowing only port 80 controls network access but does not detect instance health or influence load balancer routing decisions. Option C is wrong because a global HTTP(S) load balancer is designed for HTTP/HTTPS traffic and cannot be used with a TCP load balancer; the question specifies a TCP load balancer, which requires a TCP health check. Option D is wrong because snapshot schedules are for backup and disaster recovery of persistent disks, not for real-time health detection or traffic routing.

Full explanation →

480

MCQmedium

You need to tag all Compute Engine VMs in your organization with a `cost-center` tag for billing allocation reports. The tag values must be controlled centrally — only predefined values should be allowed. Which GCP feature enables this?

A.Use Compute Engine labels — configure label keys and restrict values using an org policy.

B.Create Resource Manager Tag keys and values at the org level, then attach tags to VMs.

C.Use network tags on VMs and enforce allowed values via a custom org policy constraint.

D.Require teams to apply specific label values using a Terraform module, and enforce this via code review.

AnswerB

Resource Manager Tags are the intended mechanism for centrally governed, hierarchical cost attribution. Creating tag keys and enumerated values at the organization level allows an administrator to control both the schema (via the tagAdmin role) and which VMs receive the tags (via the tagUser role), ensuring out-of-band creation cannot introduce ad-hoc values. These tags are visible in the Cloud Billing cost breakdown report, satisfying the requirement to track spend by VM team. Unlike labels or network tags, resource tags have IAM and hierarchy support built in.

Why this answer

Resource Manager Tags (formerly 'tags' in the Resource Manager API) allow you to create tag keys and predefined tag values at the organization level, then attach those tags to resources like Compute Engine VMs. This ensures that only centrally controlled values can be used, meeting the requirement for controlled billing allocation. Labels, by contrast, are free-form key-value pairs and cannot have their values restricted natively by an org policy.

Exam trap

Google Cloud often tests the distinction between labels (free-form, no value restriction) and Resource Manager Tags (centrally controlled, predefined values), leading candidates to mistakenly choose labels because they are more commonly used for metadata.

How to eliminate wrong answers

Option A is wrong because Compute Engine labels are free-form key-value pairs; while you can use an org policy to restrict label keys, you cannot natively restrict label values to a predefined set using an org policy alone. Option C is wrong because network tags are used for firewall rules and networking, not for billing or resource metadata, and there is no native org policy constraint to enforce allowed values on network tags. Option D is wrong because relying on a Terraform module and code review does not provide a centrally enforced, programmatic control mechanism; it depends on human compliance and can be bypassed.

Full explanation →

481

Multi-Selecteasy

You need to set up an alerting policy to notify your team via email and Slack when a Compute Engine instance's CPU utilization exceeds 80% for 5 minutes. Which two resources must you configure? (Choose two.)

Select 2 answers

A.A Cloud Function to check CPU and send Slack message

B.A metric threshold condition on the 'compute.googleapis.com/instance/cpu/utilization' metric

C.An uptime check for the external IP of the instance

D.A notification channel of type 'email'

E.A log-based alert for the 'compute.googleapis.com/instance' log

AnswersB, D

The correct condition uses a metric threshold on the time series compute.googleapis.com/instance/cpu/utilization. This metric is emitted automatically from GCE instances and can be queried with a threshold (e.g., > 80%) aligned over a defined period such as 5 minutes. When the condition's duration (e.g., 'for 5 minutes') is met, the alerting policy enters the firing state and notifies any attached channels. This is the native, fully integrated way to alert on CPU load.

Why this answer

Option B is correct because a Cloud Monitoring alerting policy requires an alerting condition, and a metric threshold condition on 'compute.googleapis.com/instance/cpu/utilization' with a threshold of 80% and a duration of 5 minutes directly expresses the required trigger. Option D is correct because notification channels define where alerts are delivered; an 'email' notification channel is needed to notify the team via email (a Slack channel would be configured as an additional notification channel of type Slack). Option A is not required because Cloud Monitoring natively evaluates metrics and sends notifications without a Cloud Function.

Option C is not relevant because uptime checks test endpoint availability, not CPU utilization. Option E is not relevant because log-based alerts trigger on log entries, not on a CPU metric threshold.

Exam trap

ACE often tests the misconception that additional compute resources (like Cloud Functions) are needed for alerting, when Cloud Monitoring natively handles metric-based alerts.

Full explanation →

482

MCQmedium

You need to create a service account for a Compute Engine instance to allow it to access Cloud Storage objects. The service account should have minimal permissions. What is the recommended approach?

A.Create a service account and assign it to the instance using gcloud compute instances set-service-account after creation

B.Use the default compute engine service account and grant it roles/storage.objectAdmin

C.Create a service account, download a JSON key, and store it on the instance's local disk

D.Create a service account, grant it the required roles, and specify it when creating the instance using the --service-account flag

AnswerD

Creating a dedicated service account, granting it only the IAM roles the application needs, and passing it via the --service-account flag at instance creation time is the Google-recommended pattern. This attaches the identity to the instance without ever downloading a key, so the instance authenticates through the metadata server's short-lived OAuth tokens. It ensures least privilege and avoids the security risk of storing long-lived credentials on the VM.

Why this answer

The recommended approach is to create a dedicated service account, grant it only the required roles (e.g., roles/storage.objectViewer for read access), and attach it to the instance at creation time using the --service-account flag. This ensures the instance uses the least-privilege identity from the start and avoids the risks of default accounts or downloaded keys.

Exam trap

ACE often tests the misconception that downloading a JSON key is acceptable — the exam expects you to know that attached service accounts with least privilege are the recommended pattern, and keys should be avoided.

How to eliminate wrong answers

Option A is wrong because while you can change a service account after creation, the question asks for the recommended approach — attaching at creation is cleaner and avoids the instance running with default credentials in the interim. Option B is wrong because the default compute engine service account has broad permissions (Editor by default) and granting it roles/storage.objectAdmin violates least privilege. Option C is wrong because downloading a JSON key and storing it on disk is an anti-pattern — keys can be leaked, are hard to rotate, and Google recommends avoiding them in favor of attached service accounts.

Full explanation →

483

MCQeasy

A batch data processing job runs nightly for 4 hours and can tolerate interruption because it saves progress checkpoints every 15 minutes. Which VM option offers the greatest cost reduction?

A.Custom machine type VM with reduced memory

B.Spot VM

C.Sole-tenant node VM

D.Shielded VM

AnswerB

Spot VMs are Compute Engine instances that run on excess, unused capacity at a steep discount, often up to 91% compared to standard VM pricing. They are ideal for batch jobs that can tolerate interruption because Compute Engine can preempt a Spot VM with only 30 seconds' notice, so the workload must implement checkpointing or divide work into small restartable tasks. For a data processing batch job that is non-urgent and fault-tolerant, Spot VMs provide the greatest cost reduction while maintaining acceptable reliability.

Why this answer

Spot VMs offer significant cost reduction (up to 60-91% discount) compared to standard VMs, making them ideal for fault-tolerant, interruptible batch workloads. Since the job saves checkpoints every 15 minutes, it can resume from the last checkpoint if preempted, fully leveraging the cost benefit of Spot VMs.

Exam trap

Google Cloud often tests the misconception that custom machine types or sole-tenant nodes are cost-saving options, but the trap here is that Spot VMs are the only option that directly leverages preemptible pricing for interruptible workloads, while other options either increase cost or provide no cost benefit.

How to eliminate wrong answers

Option A is wrong because reducing memory on a custom machine type does not provide the same magnitude of cost savings as Spot VMs, and the question specifically asks for the greatest cost reduction. Option C is wrong because sole-tenant nodes are designed for dedicated hardware compliance or licensing requirements, and they are more expensive than standard VMs, offering no cost reduction. Option D is wrong because Shielded VMs provide security features (secure boot, vTPM, integrity monitoring) but do not reduce cost; they may even add a slight premium.

Full explanation →

484

Multi-Selecthard

A data engineering team wants to create a Cloud Storage bucket for storing sensitive analytics data. They require encryption at rest with customer-managed keys (CMEK) and want to restrict access to a specific service account. Which three steps are necessary?

Select 3 answers

A.Set the bucket's default encryption to use the KMS key

B.Enable uniform bucket-level access

C.Grant the service account roles/storage.objectAdmin on the bucket

D.Create a service account and download its JSON key

E.Create a Cloud KMS key ring and key in the same region as the bucket

AnswersA, C, E

Setting the bucket's default encryption to point at the KMS key is the step that activates customer-managed encryption for Cloud Storage. All objects uploaded after this change are automatically encrypted with the selected Cloud KMS key instead of Google-owned keys. Without this configuration, the key ring and key remain unused and the bucket continues using default encryption.

Why this answer

To use CMEK, you must create a Cloud KMS key ring and key, then configure the bucket to use that key. Access is controlled via IAM; granting the service account roles/storage.objectAdmin allows full object management. Note: The KMS key must be in the same region as the bucket.

Full explanation →

485

MCQeasy

You need to create a Google-managed SSL certificate for an external HTTPS load balancer. The domain is 'www.example.com'. Which command creates the certificate?

A.gcloud compute ssl-certificates create my-cert --certificate example.crt --private-key example.key

B.gcloud compute ssl-certificates create my-cert --certificate example.crt

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

D.gcloud compute ssl-certificates create my-cert --domains www.example.com --managed

AnswerC

The --domains flag is the correct mechanism to request a Google-managed certificate: gcloud will create an SslCertificate resource in MANAGED state, and Google's Certificate Authority will issue a certificate for the specified domain, handling the entire lifecycle including automatic renewal. No additional flags are required, because the presence of --domains unambiguously selects the managed provisioning mode. This command is the exact answer for creating a managed certificate via the gcloud CLI.

Why this answer

The correct command is gcloud compute ssl-certificates create with the --domains flag. This creates a Google-managed certificate that will be provisioned and renewed automatically.

Full explanation →

486

Multi-Selectmedium

An engineer is using gsutil to upload a large number of files to a Cloud Storage bucket. The upload is proceeding very slowly. Which two actions could improve the upload performance? (Choose two.)

Select 2 answers

A.Use the gsutil -m option to enable parallel multi-threading.

B.Increase the number of retries using gsutil -o Boto:num_retries=10.

C.Change the storage class of the bucket to Standard.

D.Set the parallel composite upload threshold to a value less than the size of the files being uploaded.

E.Set a custom ACL on the bucket to allow faster writes.

AnswersA, D

The -m flag enables gsutil's multithreaded, parallel execution mode, so many objects upload concurrently instead of sequentially. This directly addresses the stem's slow bulk upload by saturating available bandwidth across multiple threads rather than processing one file at a time.

Why this answer

Option A is correct because gsutil -m enables parallel multi-threaded/multi-processing transfers, which lets many files upload concurrently and dramatically improves throughput when uploading a large number of files. Option D is correct because enabling parallel composite uploads (by setting the threshold below the file size, e.g., gsutil -o GSUtil:parallel_composite_upload_threshold=150M) splits large files into chunks uploaded in parallel and then composed server-side, speeding up large-file uploads. Option B is incorrect because Boto:num_retries only controls how many times failed requests are retried; it does not increase throughput and can even slow things down.

Option C is incorrect because storage class affects pricing, availability, and access characteristics, not upload speed. Option E is incorrect because ACLs govern access permissions and have no effect on write performance.

Exam trap

ACE often tests the specific gsutil flags that improve performance, and candidates may confuse retry settings or storage classes with performance optimizations.

Full explanation →

487

MCQeasy

Which of the following is true about Cloud Shell?

A.Cloud Shell has 5 GB of persistent home directory storage.

B.Cloud Shell requires installation of gcloud and kubectl manually.

C.Cloud Shell only supports the gcloud CLI, not kubectl.

D.Cloud Shell provides a persistent VM that can run for hours.

AnswerA

Cloud Shell provides a temporary, ephemeral VM, but your home directory is backed by a persistent 5 GB disk in Google-managed storage. That 5 GB is the permanent part of the environment — it survives session restarts, VM recycling, and timeouts. This means any files you save under $HOME, including SSH keys, configuration files, and scripts, remain available across all future Cloud Shell sessions, while the compute instance itself is recreated as needed.

Why this answer

Cloud Shell provides a persistent 5 GB home directory ($HOME) that survives across sessions, so files stored there are retained even after the VM is recycled. This is a core feature of Cloud Shell that distinguishes it from a purely ephemeral terminal. The gcloud CLI, kubectl, and many other tools are pre-installed and pre-authenticated, so no manual setup is required.

Exam trap

The trap here is confusing Cloud Shell's persistent home directory storage with a persistent VM — candidates often assume the whole environment is durable, when only the 5 GB $HOME is.

How to eliminate wrong answers

Option B is wrong because Cloud Shell comes with gcloud, kubectl, and other tools pre-installed and pre-authenticated — no manual installation is needed. Option C is wrong because Cloud Shell supports kubectl (and many other CLIs) out of the box, not just gcloud. Option D is wrong because Cloud Shell is an ephemeral VM that is terminated after a period of inactivity (typically 20 minutes of no use, with a maximum session of 12 hours), not a persistent long-running VM.

Full explanation →

488

MCQeasy

You want to ensure that all Cloud Storage buckets in your organization require customer-managed encryption keys (CMEK). What is the most efficient way to enforce this?

A.Use Cloud Audit Logs to monitor for non-compliant buckets.

B.Create an Organization Policy with constraint 'storage.requireCustomerManagedEncryption'.

C.Use a service account to encrypt all objects with CMEK.

D.Set a bucket policy on each bucket to require CMEK.

AnswerB

The Organization Policy constraint `storage.requireCustomerManagedEncryption` is a boolean, preventive constraint that is evaluated by Cloud Resource Manager during bucket creation and update requests. Setting this constraint at the organization level forces every bucket in the hierarchy to specify a CMEK (Customer-Managed Encryption Key) from Cloud KMS or the request is rejected. This gives a centralized, automated guarantee of compliance without per-bucket manual configuration.

Why this answer

The Organization Policy constraint 'storage.requireCustomerManagedEncryption' is a centralized, scalable way to enforce CMEK across all Cloud Storage buckets in the organization. This policy is applied at the organization or folder level and automatically prevents the creation of new buckets without CMEK, while also blocking updates to existing non-compliant buckets. It is the most efficient method as it requires no per-bucket configuration or ongoing monitoring.

Exam trap

Google Cloud often tests the distinction between monitoring (Audit Logs) and enforcement (Organization Policies), and the trap here is that candidates may think monitoring is sufficient for compliance, when in fact only a proactive policy constraint can prevent non-compliant resources from being created.

How to eliminate wrong answers

Option A is wrong because Cloud Audit Logs only provide post-hoc visibility into bucket creation and configuration changes; they do not enforce or prevent non-compliant buckets from being created. Option C is wrong because using a service account to encrypt objects with CMEK does not enforce the requirement at the bucket level—objects can still be uploaded with Google-managed encryption keys if the service account is not used, and it does not prevent creation of buckets without CMEK. Option D is wrong because setting a bucket policy on each bucket is not scalable and does not prevent the creation of new buckets without CMEK; it also requires manual or scripted application to every existing and future bucket, which is inefficient and error-prone.

Full explanation →

489

MCQmedium

Two GCP projects, A and B, have VPC peering configured. Project A is peered with B, and Project B is peered with Project C. Can VMs in Project A reach VMs in Project C through Project B?

A.Yes — VPC peering automatically enables transitive routing through intermediate peered networks

B.No — VPC peering is non-transitive; A and C must be directly peered to communicate

C.Yes — if Project B has IP forwarding enabled, it acts as a router between A and C

D.It depends on the firewall rules in Project B's VPC

AnswerB

VPC peering in GCP is a one-to-one relationship that does not support transitive routing, so Project A's VPC can only reach the directly peered VPC in Project B, not any VPC that B happens to be peered with (like C). Even if B's VPC has a peering connection to C, routes learned from C are not propagated through B to A because GCP exchanges only the routes of the two directly peered networks. To allow A and C to communicate, you must create a direct VPC peering between Project A and Project C, or alternatively use a shared VPC, a Cloud VPN, or a proxy/load balancer to bridge the two networks.

Why this answer

VPC peering in Google Cloud is non-transitive. This means that if Project A is peered with Project B and Project B is peered with Project C, traffic from Project A cannot flow through Project B to reach Project C. Each peering connection is a direct, point-to-point link, and there is no routing of traffic across multiple peered networks unless explicitly configured with a separate mechanism like a VPN or a third-party appliance.

Therefore, VMs in Project A and Project C must be directly peered to communicate.

Exam trap

Google Cloud often tests the misconception that VPC peering behaves like a traditional router or switch, where traffic can be forwarded through intermediate networks, but in Google Cloud, VPC peering is strictly non-transitive, and candidates must remember that direct peering is required for communication between non-adjacent VPCs.

How to eliminate wrong answers

Option A is wrong because VPC peering does not automatically enable transitive routing; it is explicitly non-transitive by design in Google Cloud, and traffic cannot hop through an intermediate peered network. Option C is wrong because IP forwarding on instances in Project B does not enable transitive routing across VPC peering; IP forwarding is used for instances acting as routers or NAT gateways, but VPC peering itself does not support transitive routing regardless of IP forwarding settings. Option D is wrong because the issue is not about firewall rules; even if firewall rules in Project B allow all traffic, the fundamental non-transitive nature of VPC peering prevents communication between A and C through B.

Full explanation →

490

MCQeasy

An organization wants to run a stateless HTTP-based containerized application that scales to zero when not in use and charges only for request processing time. They do not want to manage any underlying infrastructure. Which compute option should they choose?

A.Compute Engine with managed instance group

B.Cloud Run

C.Cloud Functions

D.Google Kubernetes Engine (GKE) Standard

AnswerB

Cloud Run is the correct choice because it directly runs stateless HTTP container images in a fully managed, serverless environment, scaling from zero to handle traffic and back to zero when idle. You are billed only for compute resources used during request processing, not for paused instances, and it handles TLS, revisions, and autoscaling natively.

Why this answer

Cloud Run is a fully managed serverless platform for containerized HTTP applications that scales to zero when idle and bills only for request processing time (CPU/memory allocated during requests). It requires no infrastructure management and supports any containerized HTTP workload. This matches the requirement exactly.

Exam trap

ACE often tests the distinction between serverless containers (Cloud Run) and serverless functions (Cloud Functions), and whether candidates realize that GKE and MIGs do not scale to zero — pick the option that explicitly bills only for request processing.

How to eliminate wrong answers

Option A is wrong because Compute Engine with a managed instance group requires you to manage VMs, and it does not scale to zero — you pay for instances even when idle. Option C is wrong because Cloud Functions is for event-driven functions, not arbitrary containerized HTTP applications, and it has runtime restrictions. Option D is wrong because GKE Standard requires cluster and node management and does not scale to zero by default (nodes run continuously).

Full explanation →

491

MCQmedium

A cost-conscious team notices their GKE cluster's node pools have consistently high memory utilization (>90%) while CPU remains at 30%. Pods are occasionally OOMKilled. What should they do to balance resource efficiency and stability?

A.Switch node pool machine type to a memory-optimized series (e.g., m2-ultramem) and ensure Pod memory requests are accurate

B.Increase CPU limits for all Pods to use the available CPU capacity

C.Enable vertical pod autoscaling (VPA) set to Recreate mode as the only change

D.Reduce the number of replica Pods to lower memory consumption

AnswerA

Switching the node pool to a memory-optimized series like m2-ultramem gives each node a much higher RAM-to-vCPU ratio, directly resolving the memory pressure that causes OOMKills. Simultaneously aligning pod memory requests with actual usage lets the scheduler pack pods according to real footprint, and enables cluster autoscaler to add the right capacity. These changes together correct the capacity deficit.

Why this answer

The team has a memory-bound workload (high memory utilization, low CPU, OOMKills). Switching to a memory-optimized machine series (e.g., m2-ultramem) provides a higher memory-to-CPU ratio, directly addressing the memory pressure. Ensuring accurate Pod memory requests allows the scheduler to place Pods efficiently and prevents overcommitment, balancing resource efficiency with stability.

Exam trap

Google Cloud often tests the misconception that vertical scaling (VPA) alone can fix memory pressure without considering the node's physical resource ratio, leading candidates to pick Option C and overlook the need for a memory-optimized machine type.

How to eliminate wrong answers

Option B is wrong because increasing CPU limits does not address memory pressure or OOMKills; it wastes CPU capacity that is already underutilized and may cause unnecessary throttling or scheduling inefficiencies. Option C is wrong because enabling VPA in Recreate mode as the only change will adjust CPU and memory requests based on historical usage, but it does not change the underlying machine type's memory-to-CPU ratio; the node pool may still lack sufficient memory capacity, leading to continued OOMKills or failed VPA recommendations. Option D is wrong because reducing replica Pods lowers overall memory consumption but also reduces application throughput and availability; it does not fix the root cause of memory inefficiency per Pod and may violate stability or SLA requirements.

Full explanation →

492

MCQmedium

A company wants to track and forecast GCP spending across different departments. They have already set up labels on resources to indicate the department. Which additional step should they take to analyze costs by department in BigQuery?

A.Enable billing export to BigQuery in the Cloud Billing console

B.Use the Cloud Billing API to programmatically fetch cost data and write it to BigQuery

C.Run a scheduled query in BigQuery that calls the Cloud Billing API

D.Create a Cloud Function that captures billing events and inserts them into BigQuery

AnswerA

Enabling billing export to BigQuery in the Cloud Billing console is the native, fully managed integration for this use case. It automatically creates a set of BigQuery tables (e.g., gcp_billing_export_resource_v1) that contain detailed line items including cost, usage, labels, and resource hierarchy, updated on an ongoing basis. This export requires no custom code and provides the historical, labelled data needed to track and forecast GCP spending across departments using standard SQL and BI tools.

Why this answer

Enabling billing export to BigQuery in the Cloud Billing console is the native, supported mechanism that streams detailed cost and usage data — including labels — into a BigQuery dataset. Once enabled, department labels are available as columns, allowing cost analysis and forecasting by department. This is the standard first step before any BigQuery-based cost reporting.

Exam trap

ACE often tests whether candidates know the native billing export feature versus building custom pipelines, so the trap is selecting API-based or Cloud Function approaches when the console export is the correct, supported method.

How to eliminate wrong answers

Option B is wrong because the Cloud Billing API does not provide a direct write-to-BigQuery path; it returns cost data that you would have to transform and load yourself, which is unnecessary when native export exists. Option C is wrong because BigQuery scheduled queries cannot call the Cloud Billing API to ingest data; they only query existing datasets. Option D is wrong because Cloud Functions cannot capture billing events in real time for cost data; billing data is not event-streamed in that manner.

Full explanation →

493

MCQeasy

A developer runs `gcloud projects list` and receives the error: `ERROR: (gcloud.projects.list) PERMISSION_DENIED: The caller does not have permission`. The developer has the Viewer role on several projects. What is the most likely cause?

A.The developer does not have multi-factor authentication enabled.

B.The developer lacks `resourcemanager.projects.list` at the organization or folder level.

C.The gcloud SDK is outdated and must be updated.

D.The developer's account has been suspended by the billing administrator.

AnswerB

The permission `resourcemanager.projects.list` is evaluated against the parent resource (organization or folder) where the developer is attempting to list projects, not against each project individually. The Project Viewer role (roles/viewer) only grants permissions within a specific project, so while the developer can view a project they're already in, `gcloud projects list` needs an IAM role at the folder or organization level to enumerate all projects in that hierarchy. Without that permission at the parent, the API returns PERMISSION_DENIED even if the developer has viewer access to many projects.

Why this answer

The `gcloud projects list` command requires the `resourcemanager.projects.list` permission, which is granted at the organization or folder level, not at the individual project level. Even with the Viewer role on several projects, the developer lacks this specific permission at the resource hierarchy level above the projects, causing the PERMISSION_DENIED error.

Exam trap

Google Cloud often tests the misconception that project-level roles like Viewer are sufficient for listing projects, when in reality the `resourcemanager.projects.list` permission must be granted at a higher level in the resource hierarchy.

How to eliminate wrong answers

Option A is wrong because multi-factor authentication (MFA) is an account security feature that does not affect API permissions or gcloud command authorization; it is unrelated to IAM permission errors. Option C is wrong because an outdated gcloud SDK would typically cause version mismatch errors or deprecation warnings, not a PERMISSION_DENIED error, which is an IAM authorization issue. Option D is wrong because a suspended account would result in an authentication error (e.g., 'Account is disabled') or a billing-related error, not a permission denied error for a specific API call.

Full explanation →

494

Multi-Selectmedium

A company plans to deploy a containerized application on GKE Autopilot. They want to ensure high availability by running multiple replicas across different zones. They also need to expose the application via a load balancer with SSL termination. Which THREE resources should they create?

Select 3 answers

A.Service

B.StatefulSet

C.Ingress

D.ConfigMap

E.Deployment

AnswersA, C, E

A Service provides the stable virtual IP and load-balancing layer that distributes traffic across the application's pods, and it is the resource an Ingress or external load balancer targets for SSL termination, satisfying the exposure requirement in the stem.

Why this answer

A Deployment (E) is the correct workload controller for a stateless containerized application, allowing the company to declare multiple replicas that GKE Autopilot spreads across zones for high availability. A Service (A) is required to provide a stable virtual IP and load-balance traffic to those pod replicas, and on GKE it also provisions the underlying Google Cloud load balancer. An Ingress (C) is needed to expose the application externally and to configure SSL/TLS termination using a managed certificate or a TLS secret, which is exactly the load-balancer-with-SSL requirement.

A StatefulSet (B) is not appropriate because it is designed for stateful workloads needing stable network identities and persistent storage, which this stateless app does not require. A ConfigMap (D) only supplies non-sensitive configuration data and does not provide high availability, load balancing, or SSL termination.

Exam trap

The trap here is selecting StatefulSet instead of Deployment for stateless applications, or forgetting that Ingress is needed for SSL termination and external load balancing, while Service alone may not provide SSL termination.

Full explanation →

495

Multi-Selecthard

An organization needs to run a batch analytics job on BigQuery every night that processes terabytes of data. The job is critical and must complete within a specific time window. To optimize costs, they are considering using flat-rate pricing but want to minimize commitment risk. Which THREE factors should they evaluate?

Select 3 answers

A.The number of Cloud Storage buckets used for data staging

B.The cost of on-demand query pricing for the same workload

C.The cost of reserving dedicated hardware for Compute Engine

D.The number of slots needed to complete the job within the required time window

E.The availability of flex slots for short-term capacity needs

AnswersB, D, E

Comparing on-demand query pricing for the identical workload establishes the break-even baseline: if on-demand costs less than the flat-rate commitment, committing wastes money. This directly addresses minimising commitment risk by quantifying whether reserved capacity is justified for the nightly batch job.

Why this answer

The organization should evaluate B, the cost of on-demand query pricing for the same workload, because comparing on-demand BigQuery pricing against flat-rate commitment costs is the baseline needed to determine whether a reservation actually saves money for this nightly terabyte-scale job. They should also evaluate D, the number of slots needed to complete the job within the required time window, since flat-rate capacity is measured in slots and the reservation size must be sufficient to finish the batch analytics within the critical window. They should evaluate E, the availability of flex slots for short-term capacity needs, because flex slots provide a low-commitment, short-duration way to obtain dedicated BigQuery capacity, which directly addresses the goal of minimizing commitment risk.

Options A and C do not belong: the number of Cloud Storage buckets used for staging is irrelevant to BigQuery flat-rate slot commitment decisions, and reserving dedicated Compute Engine hardware is a different compute service and does not address BigQuery slot capacity or pricing.

Exam trap

Google Cloud often tests the misconception that storage infrastructure (like Cloud Storage buckets) or unrelated compute services (like Compute Engine) influence BigQuery pricing decisions, when in fact the focus should be on slot allocation and cost comparison with on-demand pricing.

Full explanation →

496

MCQeasy

A company wants to store event logs from multiple applications in a centralized location for future analysis. The logs are written frequently (thousands per second) and need to be retained for 90 days. The data is write-once, read-rarely. Which storage class and lifecycle rule combination is most cost-effective?

A.Set default storage class to Archive and use lifecycle rule to delete after 90 days

B.Set default storage class to Standard and use lifecycle rule to delete after 90 days

C.Set default storage class to Coldline and use lifecycle rule to delete after 90 days

D.Set default storage class to Nearline and use lifecycle rule to delete after 90 days

AnswerC

Coldline storage is designed for data that is expected to be accessed at most once per 90 days, making it a perfect match for a 90-day retention period. The lower per-GiB storage price compared to Standard and Nearline, combined with lifecycle deletion at 90 days, minimizes cost without incurring early deletion fees (Coldline has a 90-day minimum storage duration). This directly satisfies the requirement to store event logs for 90 days and then delete them.

Why this answer

For write-once, read-rarely data, Coldline storage class is cost-effective for data accessed less than once per 90 days. Set a lifecycle rule to delete objects after 90 days. Alternatively, use Standard for the first 30 days then move to Coldline, but the question asks for a combination.

The simplest is to set the default storage class to Coldline and a lifecycle rule to delete at 90 days.

Full explanation →

497

MCQmedium

You are managing a project and need to create a custom IAM role that allows only the permissions compute.instances.list and compute.instances.get. What is the correct way to create this role using gcloud?

A.gcloud iam service-accounts create viewer --permissions="compute.instances.list,compute.instances.get"

B.gcloud iam roles create viewer --organization=123456 --permissions="compute.instances.*"

C.gcloud iam roles create viewer --project=my-project --permissions="compute.instances.list,compute.instances.get"

D.gcloud iam custom-roles create viewer --project=my-project --permissions='compute.instances.list,compute.instances.get'

AnswerC

This is the correct command: `gcloud iam roles create` creates a custom role scoped to the specified project, and the `--permissions` flag explicitly lists the two required read-only permissions. Using specific permission names without wildcards enforces least privilege and aligns with IAM's requirement for fully qualified permission identifiers. The resulting role can then be bound to users or groups with `gcloud projects add-iam-policy-binding`.

Why this answer

The correct command to create a custom IAM role with specific permissions is 'gcloud iam roles create' with the --project flag and a comma-separated list of permissions. This creates a project-level custom role with exactly the permissions specified. The syntax matches the gcloud iam roles create command structure.

Exam trap

ACE often tests the exact gcloud command syntax for creating custom roles, and candidates may confuse it with service account creation or use incorrect command names like 'custom-roles'.

How to eliminate wrong answers

Option A is wrong because 'gcloud iam service-accounts create' creates a service account, not a custom role, and does not accept a --permissions flag. Option B is wrong because it uses a wildcard 'compute.instances.*' which grants more permissions than intended, and it specifies an organization instead of a project, which is not required for a project-level custom role. Option D is wrong because the command 'gcloud iam custom-roles create' does not exist; the correct command is 'gcloud iam roles create'.

Full explanation →

498

MCQmedium

An engineer is setting up Cloud Shell for the first time. They notice that their home directory persists across sessions. How much storage is allocated to the home directory in Cloud Shell?

A.10 GB

B.1 GB

C.20 GB

D.5 GB

AnswerD

Correct. Cloud Shell provisions a 5 GB persistent home directory, mounted at $HOME, that survives between sessions. This is the documented, fixed quota for free Cloud Shell usage, regardless of session time or usage patterns.

Why this answer

Google Cloud Shell provides 5 GB of persistent storage for the home directory, which is mounted across sessions so files survive VM recycling. This persistent disk is separate from the ephemeral boot disk that hosts the Cloud Shell VM itself. The 5 GB limit is the documented allocation for the $HOME directory.

Exam trap

ACE often tests exact quota values, and candidates frequently guess a larger round number (10 or 20 GB) instead of the documented 5 GB Cloud Shell home directory allocation.

How to eliminate wrong answers

Option A is wrong because 10 GB is not the documented Cloud Shell home directory allocation; it may be confused with other GCP free-tier storage quotas. Option B is wrong because 1 GB is far too small and does not match the Cloud Shell persistent disk size. Option C is wrong because 20 GB exceeds the documented Cloud Shell home directory quota and may be confused with persistent disk sizes on Compute Engine.

Full explanation →

499

MCQeasy

A company is using Cloud Run for a stateless application. The application sometimes fails with HTTP 503 errors when traffic spikes. Which action should the team take to improve reliability?

A.Configure a liveness probe with a higher initial delay.

B.Increase the maximum number of container instances.

C.Use Cloud Functions instead of Cloud Run.

D.Enable HTTP load balancing with Cloud CDN.

AnswerB

Raising the maximum number of container instances directly increases the scaling ceiling for the Cloud Run service, so the platform can allocate more instances when the current set is saturated. When all running instances are at full concurrency and the max instance count has been reached, excess requests are rejected with HTTP 503. By increasing this limit, the service can spawn additional containers to absorb the load, addressing the capacity shortfall at its root.

Why this answer

HTTP 503 errors during traffic spikes indicate that Cloud Run is scaling out but hitting the maximum number of container instances limit, causing new requests to be rejected. Increasing the maximum number of container instances allows Cloud Run to spin up more concurrent containers to handle the burst, directly improving reliability under load.

Exam trap

The trap here is that candidates confuse liveness probes (which check container health) with scaling mechanisms, or assume that adding a CDN or switching to Cloud Functions will magically absorb traffic spikes, when the root cause is simply hitting the instance cap.

How to eliminate wrong answers

Option A is wrong because a liveness probe with a higher initial delay only affects when the container is considered healthy after startup; it does not address capacity limits during traffic spikes. Option C is wrong because Cloud Functions has similar or stricter concurrency and scaling limits, and switching to it would not inherently solve capacity-related 503 errors. Option D is wrong because HTTP load balancing with Cloud CDN caches static content but does not increase the backend's ability to handle more concurrent requests; the 503 originates from Cloud Run's instance cap, not from network-level congestion.

Full explanation →

500

MCQmedium

A team wants to automatically restart any GKE Pod that fails a liveness probe three consecutive times. The probe should check HTTP GET /healthz on port 8080, starting after 30 seconds and checking every 10 seconds. Which Pod spec configuration implements this?

A.readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3

B.livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3

C.startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 3

D.lifecycle: postStart: httpGet: path: /healthz port: 8080

AnswerB

This is the correct configuration because a livenessProbe is the Kubernetes mechanism that determines whether a container is still healthy after it has started. The httpGet hits /healthz on port 8080 after a 30-second initial delay, then every 10 seconds; when the probe fails three consecutive times, the kubelet kills the container and restarts it according to the pod's restartPolicy. That exactly matches the requirement to restart a container that is running but has become unhealthy.

Why this answer

A livenessProbe with an HTTP GET on /healthz at port 8080, configured with initialDelaySeconds: 30, periodSeconds: 10, and failureThreshold: 3, will cause the kubelet to restart the Pod after three consecutive failed checks. This directly matches the requirement to restart on liveness probe failures, as liveness probes are specifically designed to determine if a container should be restarted.

Exam trap

Google Cloud often tests the distinction between readinessProbe and livenessProbe, trapping candidates who confuse 'restart on failure' with 'stop sending traffic on failure'.

How to eliminate wrong answers

Option A is wrong because it uses a readinessProbe, which only controls whether the Pod receives traffic from Services, not whether the container is restarted; readiness probes do not trigger restarts on failure. Option C is wrong because a startupProbe is used to delay other probes until the application has started, and it does not cause restarts after the initial startup phase; it also lacks the required initialDelaySeconds and periodSeconds. Option D is wrong because lifecycle hooks like postStart execute a command or HTTP request once after container creation, not as a recurring health check, and they cannot be configured with failure thresholds or periodic checks.

Full explanation →

501

MCQeasy

You need to deploy a new version of an App Engine standard environment application. The new version should receive 10% of traffic while the current version continues to receive 90%. Which command achieves this?

A.`gcloud app deploy --version=v2 --no-promote`

B.`gcloud app services set-traffic default --splits v1=0.9,v2=0.1`

C.`gcloud app versions migrate v2`

D.`gcloud app deploy --version=v2 --promote --stop-previous-version`

AnswerB

This is the exact command because it applies the required traffic split at the `default` service level without performing any new deployment. The `--splits` flag defines a percentage map: `v1=0.9` sends 90% of requests to v1, and `v2=0.1` sends the remaining 10% to v2. Both versions must already exist in the service, and this command is typically executed after deploying v2 with `--no-promote`. This achieves the canary pattern where the new version serves a small, controlled fraction of user traffic while the stable version handles the majority.

Why this answer

The `gcloud app services set-traffic` command explicitly splits traffic between versions of an App Engine service. By specifying `--splits v1=0.9,v2=0.1`, you direct 90% of requests to version v1 and 10% to version v2, without deploying a new version or promoting it. This is the standard method for gradual traffic migration in App Engine standard environment.

Exam trap

Google Cloud often tests the distinction between deploying a version (`deploy`), migrating all traffic (`migrate`), and splitting traffic (`set-traffic`), so the trap here is that candidates confuse `--no-promote` with traffic splitting, thinking it allocates a percentage of traffic when it actually just deploys without routing any traffic to the new version.

How to eliminate wrong answers

Option A is wrong because `gcloud app deploy --version=v2 --no-promote` deploys version v2 but does not split traffic; it leaves all traffic on the default version (v1), so v2 receives 0% of traffic. Option C is wrong because `gcloud app versions migrate v2` migrates all traffic to version v2 (100%), not a 10% split. Option D is wrong because `gcloud app deploy --version=v2 --promote --stop-previous-version` deploys v2, promotes it to receive all traffic, and stops the previous version, resulting in 100% traffic to v2, not a 10/90 split.

Full explanation →

502

MCQmedium

An engineer wants to authenticate to Google Cloud using their own user credentials and also set up application default credentials for a local development environment. Which sequence of gcloud auth commands should they use?

A.gcloud auth login then gcloud auth application-default login

B.gcloud auth application-default login then gcloud auth login

C.gcloud init then gcloud auth login

D.gcloud auth configure-docker then gcloud auth login

AnswerA

This is the correct setup sequence for local development. First, `gcloud auth login` authenticates your user account and stores credentials for gcloud CLI commands in the user's config directory. Then, `gcloud auth application-default login` creates the `application_default_credentials.json` file, which allows Google Cloud client libraries to discover credentials via Application Default Credentials. Having both ensures gcloud and code-based SDKs use the same identity.

Why this answer

The correct sequence is `gcloud auth login` first to authenticate the user's own credentials for gcloud CLI operations, then `gcloud auth application-default login` to set up Application Default Credentials (ADC) that client libraries and local apps use. This order ensures the user identity is established before ADC is configured.

Exam trap

ACE often tests the distinction between user authentication (gcloud auth login) and application default credentials (gcloud auth application-default login) — candidates assume they are the same or that order doesn't matter, but the question specifically tests the correct sequence and purpose.

How to eliminate wrong answers

Option B is wrong because reversing the order does not break anything functionally, but the question asks for the sequence that authenticates user credentials first and then sets up ADC — the standard documented order is login then ADC. Option C is wrong because `gcloud init` is for initializing a configuration (project, region, account) and does not set up ADC. Option D is wrong because `gcloud auth configure-docker` configures Docker credential helpers for Artifact Registry, unrelated to ADC.

Full explanation →

503

MCQhard

A company wants to migrate an on-premises PostgreSQL database to Google Cloud. They need a managed database service with high availability and automatic failover. The application uses many stored procedures and extensions specific to PostgreSQL. Which service should they choose?

A.Cloud Spanner

B.Bare Metal Solution

C.Cloud SQL for PostgreSQL

D.Firestore

AnswerC

Cloud SQL for PostgreSQL is a fully managed, PostgreSQL-compatible database service that supports the same SQL dialect, extensions, and client protocols as standard PostgreSQL. It enables a straightforward migration path for on-premises PostgreSQL databases using tools like Database Migration Service or pg_dump/pg_restore. Cloud SQL also provides automated backups, high availability, and scaling, making it the optimal choice for a direct PostgreSQL migration without application code changes.

Why this answer

Cloud SQL for PostgreSQL supports many PostgreSQL extensions and stored procedures. Cloud Spanner is not PostgreSQL-compatible; Firestore is NoSQL; Bare Metal Solution is for on-premises-like deployments, not managed.

Full explanation →

504

MCQeasy

Which of the following is required to enable Private Google Access on a subnet?

A.Configuring the subnet with --enable-private-ip-google-access

B.A Cloud Router in the same region

C.A Cloud NAT gateway

D.VPC peering with a Google-managed network

AnswerA

The subnet-level flag --enable-private-ip-google-access is the required element because it configures the VPC subnet to route traffic from instances without external IPs directly to Google's public API endpoints over the Google network. Without this flag, VMs that lack an external IP address cannot reach Google APIs and services, even if the subnet has a default route with an internet gateway. This flag is set per subnet, and enabling it on the relevant subnet is the fundamental prerequisite for Private Google Access.

Why this answer

Private Google Access is enabled per-subnet using the gcloud flag --enable-private-ip-google-access (or the equivalent 'Private Google Access: On' setting in the console). This allows VM instances that only have internal IP addresses to reach Google APIs and services (such as Cloud Storage, BigQuery, and the metadata server) using Google's internal routing, without requiring an external IP or NAT. The setting is scoped to the subnet, so each subnet must be configured individually.

Exam trap

ACE often tests the confusion between Private Google Access (internal-only access to Google APIs) and Cloud NAT (outbound internet access), causing candidates to pick Cloud NAT as a prerequisite.

How to eliminate wrong answers

Option B is wrong because a Cloud Router is used for dynamic routing via BGP (Cloud NAT and hybrid connectivity), not for enabling Private Google Access; PGA works purely through Google's internal network fabric. Option C is wrong because Cloud NAT provides outbound internet access for instances without external IPs, but it is not required for Private Google Access — PGA traffic never leaves Google's network and does not traverse NAT. Option D is wrong because VPC peering with a Google-managed network is unrelated to PGA; PGA is a per-subnet toggle, not a peering construct.

Full explanation →

505

MCQmedium

A team needs a GKE cluster named 'prod-cluster' in the us-central1 region with cluster autoscaling enabled, scaling between 3 and 10 nodes. Which command achieves this?

A.gcloud container clusters create prod-cluster --region=us-central1 --num-nodes=3 --enable-autoscaling --min-nodes=3 --max-nodes=10

B.gcloud kubernetes clusters create prod-cluster --location=us-central1 --autoscale=3:10

C.gcloud container cluster create prod-cluster --zone=us-central1 --scaling=3-10

D.kubectl create cluster prod-cluster --region=us-central1 --autoscale --min=3 --max=10

AnswerA

This is the correct command. `--region=us-central1` creates a regional GKE cluster that spans multiple zones within the region for high availability, while `--num-nodes=3` sets the initial node count. The `--enable-autoscaling` flag activates the node autoscaler, and `--min-nodes=3` / `--max-nodes=10` define the scaling boundaries, allowing the cluster to grow up to 10 nodes and shrink back to 3 based on workload demand.

Why this answer

It uses the `gcloud container clusters create` command with the `--enable-autoscaling` flag, which enables cluster autoscaler for the GKE cluster. The `--min-nodes=3` and `--max-nodes=10` flags define the scaling range, while `--num-nodes=3` sets the initial node count, ensuring the cluster starts with 3 nodes and can scale up to 10 as needed. The `--region=us-central1` specifies a regional cluster, which is appropriate for production workloads requiring high availability across zones.

Exam trap

Google Cloud often tests the distinction between `gcloud container clusters` (correct for GKE) and `gcloud kubernetes clusters` (invalid), as well as the requirement to use `--enable-autoscaling` with separate `--min-nodes` and `--max-nodes` flags instead of shorthand syntax like `--autoscale=3:10`.

How to eliminate wrong answers

Option B is wrong because `gcloud kubernetes clusters create` is not a valid gcloud command; the correct command uses `gcloud container clusters create`. Additionally, `--autoscale=3:10` is not a valid flag; the correct flags are `--enable-autoscaling`, `--min-nodes`, and `--max-nodes`. Option C is wrong because `--zone=us-central1` is invalid since us-central1 is a region, not a zone; a zone would be like `us-central1-a`.

Also, `--scaling=3-10` is not a valid gcloud flag; the correct syntax uses `--enable-autoscaling` with separate min and max flags. Option D is wrong because `kubectl create cluster` is not a valid kubectl command; kubectl is used to manage Kubernetes resources, not to create GKE clusters. Additionally, `--autoscale`, `--min`, and `--max` are not kubectl flags for cluster creation.

Full explanation →

506

MCQmedium

A data scientist wants to deploy a Python function that processes messages from a Pub/Sub topic whenever a new message arrives. The function should be stateless and run in a serverless environment. Which deployment command should be used?

A.gcloud run deploy my-function --source . --region us-central1 --trigger-topic my-topic

B.gcloud functions deploy my-function --runtime python39 --trigger-topic my-topic --entry-point my_entry --region us-central1

C.gcloud pubsub subscriptions create my-sub --topic my-topic --push-endpoint https://my-function-url

D.gcloud functions deploy my-function --runtime python39 --trigger-http --entry-point my_entry --region us-central1

AnswerB

gcloud functions deploy with --trigger-topic creates an event-driven Cloud Function subscribed to a Pub/Sub topic. The --runtime python39 specifies the Python 3.9 execution environment, --entry-point my_entry identifies the function name inside main.py to invoke, and --region sets the deployment location. This is the only valid command that directly deploys the function and wires it to the specified Pub/Sub topic.

Why this answer

The correct command is 'gcloud functions deploy' with '--trigger-topic', which deploys a Cloud Function (2nd gen or 1st gen) that is invoked by Pub/Sub messages. This matches the requirement for a stateless, serverless function triggered by a Pub/Sub topic. The runtime and entry point flags are also correctly specified.

Exam trap

ACE often tests the difference between deploying a function ('gcloud functions deploy') and creating a subscription ('gcloud pubsub subscriptions create') — candidates pick the subscription command thinking it 'connects' the function to the topic, but it does not deploy the function.

How to eliminate wrong answers

Option A is wrong because 'gcloud run deploy' deploys to Cloud Run, which is container-based and does not natively support '--trigger-topic' — Cloud Run uses Eventarc for Pub/Sub triggers, not a direct topic flag. Option C is wrong because it creates a Pub/Sub push subscription pointing to an existing HTTP endpoint; it does not deploy the function itself and assumes the function already exists. Option D is wrong because '--trigger-http' deploys an HTTP-triggered function, not a Pub/Sub-triggered one, so it would not automatically process messages from the topic.

Full explanation →

507

MCQeasy

A startup wants to host a static website (HTML, CSS, JS) globally with minimal latency and high availability. They expect low traffic initially but want to scale seamlessly. Which solution is most cost-effective and simple?

A.Compute Engine with nginx

B.App Engine standard environment

C.Cloud Functions with HTTP triggers

D.Cloud Storage bucket with Cloud CDN enabled

AnswerD

A Cloud Storage bucket can be configured for static website hosting, making it a serverless origin that serves HTML, CSS, and JS directly with no compute resources. Enabling Google Cloud CDN on that bucket—typically via an external HTTP(S) load balancer with a backend bucket—caches files at global edge locations for low-latency repeat access. This setup is highly available, requires zero infrastructure maintenance, and costs only for storage and network egress.

Why this answer

A Cloud Storage bucket with Cloud CDN enabled is the most cost-effective and simple solution for hosting a static website globally with minimal latency. Cloud Storage natively serves static content (HTML, CSS, JS) without provisioning servers, and Cloud CDN caches content at edge locations worldwide, reducing latency. It scales seamlessly from zero traffic to high demand without manual intervention, and costs are based only on storage and egress, making it ideal for low-traffic startups.

Exam trap

Google Cloud often tests the misconception that static websites require a compute layer (like App Engine or Compute Engine) to serve files, when in fact Cloud Storage with CDN is the simplest and most cost-effective serverless option for static content.

How to eliminate wrong answers

Option A is wrong because Compute Engine with nginx requires managing a virtual machine, which adds operational overhead and cost for idle resources, and does not provide global edge caching without additional configuration. Option B is wrong because App Engine standard environment is designed for dynamic web applications with server-side code, not purely static sites, and incurs costs for always-on instances even at low traffic. Option C is wrong because Cloud Functions with HTTP triggers is intended for event-driven, short-lived compute tasks, not for serving static files efficiently; it would incur per-invocation costs and cold start latency, and lacks built-in global CDN caching for static assets.

Full explanation →

508

MCQhard

A team is using gcloud configurations to manage multiple projects. They want to create a new configuration for a production project. How can they achieve this?

A.Run 'gcloud init' and select 'Create a new configuration'

B.Run 'gcloud config configurations create prod' then 'gcloud config set project prod-project'

C.Run 'gcloud config set project prod-project' with a flag to create new config

D.Edit the gcloud config file manually

AnswerB

The correct method is to first run gcloud config configurations create prod, which generates a new empty named configuration and automatically activates it. With the prod configuration active, gcloud config set project prod-project then sets the project property for that configuration, providing a clean, isolated environment for managing the prod project.

Why this answer

The correct command sequence is 'gcloud config configurations create prod' followed by 'gcloud config set project prod-project'. This creates a new named configuration and sets the active project within it. The 'gcloud config configurations create' command is specifically designed for this purpose.

Exam trap

ACE often tests the exact syntax for creating and managing gcloud configurations, and candidates may confuse 'gcloud init' with 'gcloud config configurations create' or assume that setting a project automatically creates a new configuration.

How to eliminate wrong answers

Option A is wrong because 'gcloud init' is an interactive command that initializes the gcloud CLI and can create a new configuration, but it is not the explicit command to create a named configuration for a specific project; it is more for initial setup. Option C is wrong because 'gcloud config set project' does not have a flag to create a new configuration; it only sets the project property in the current configuration. Option D is wrong because manually editing the gcloud config file is not recommended and error-prone; the CLI provides commands for configuration management.

Full explanation →

509

MCQhard

Your GKE cluster is running a deployment with a container image my-app:v1. You need to update it to my-app:v2 and monitor the rollout progress. Which commands should you use?

A.gcloud compute instances update-container and kubectl get events

B.kubectl edit deployment/my-app and change the image, then kubectl rollout undo if needed

C.kubectl set image deployment/my-app my-app=my-app:v2 followed by kubectl rollout status deployment/my-app

D.gcloud container clusters upgrade and kubectl get pods

AnswerC

kubectl set image deployment/my-app my-app=my-app:v2 imperatively updates the container image of the specified container in the Deployment, which immediately triggers a new ReplicaSet and rolling update. kubectl rollout status deployment/my-app then blocks and reports the status of that rollout until it completes, satisfying the requirement to update and monitor progress in one straightforward command sequence.

Why this answer

The correct approach uses `kubectl set image` to declaratively update the container image in the deployment, which triggers a rolling update, followed by `kubectl rollout status` to watch the rollout progress until completion. This is the standard Kubernetes-native workflow for image updates and monitoring.

Exam trap

The trap here is confusing GKE workload management with Compute Engine container management, or assuming `kubectl edit` is the preferred method for image updates when the exam expects the imperative `kubectl set image` + `kubectl rollout status` pattern.

How to eliminate wrong answers

Option A is wrong because `gcloud compute instances update-container` targets Compute Engine VMs running containers (via the container-vm or COS), not GKE deployments, and `kubectl get events` only shows cluster events, not rollout progress. Option B is wrong because while `kubectl edit` can change the image, it is an interactive manual edit rather than the recommended imperative command, and `kubectl rollout undo` is only used to roll back, not to monitor progress. Option D is wrong because `gcloud container clusters upgrade` upgrades the cluster's Kubernetes version, not a workload's image, and `kubectl get pods` shows pod status but not a structured rollout status.

Full explanation →

510

MCQhard

Your security team requires that all service accounts in your GCP organization older than 90 days that have not been used must be automatically disabled. They want a fully managed, serverless solution with no persistent infrastructure. Which architecture best meets these requirements?

A.Deploy a Compute Engine VM with a cron job that calls the IAM API nightly.

B.Use Cloud Scheduler to trigger a Cloud Function that queries Cloud Asset Inventory and disables stale service accounts.

C.Configure an org policy that automatically expires service accounts after 90 days.

D.Use Security Command Center to flag and manually disable unused service accounts.

AnswerB

Cloud Scheduler is a fully managed cron service that can invoke an HTTP-triggered Cloud Function on a defined schedule (e.g., nightly or weekly). The Cloud Function can call Cloud Asset Inventory's searchAllResources or searchAllIamPolicies to list service accounts and inspect the `lastAuthenticatedTime` property exposed for service accounts. Using the IAM API, the function can then disable stale accounts via `disableServiceAccount()`. This approach is entirely serverless, event-driven, and requires no persistent compute or manual intervention, making it the most efficient and aligned with Google Cloud best practices.

Why this answer

Cloud Scheduler can trigger a serverless Cloud Function on a schedule (e.g., nightly) to query Cloud Asset Inventory for service accounts older than 90 days with no last authentication time, then disable them via the IAM API. This meets the fully managed, serverless requirement with no persistent infrastructure (no VMs or servers to maintain).

Exam trap

Google Cloud often tests the misconception that Organization Policies can enforce time-based lifecycle actions on IAM resources, but they only provide static constraints (e.g., 'constraints/iam.disableServiceAccountCreation'), not dynamic expiration or usage-based disabling.

How to eliminate wrong answers

Option A is wrong because it uses a Compute Engine VM with a cron job, which requires persistent infrastructure (the VM) and is not fully managed or serverless. Option C is wrong because Organization Policies do not support automatic expiration or disabling of service accounts based on age or usage; they enforce constraints on resource locations, domains, or service states, not time-based lifecycle actions. Option D is wrong because Security Command Center (SCC) provides findings and recommendations but does not automatically disable resources; it requires manual intervention, which violates the 'automatically disabled' requirement.

Full explanation →

511

MCQeasy

A developer wants to deploy a Cloud Function that processes images uploaded to a Cloud Storage bucket. The function should be triggered automatically when an object is created. What is the best practice for setting up this trigger?

A.Use a Pub/Sub topic and a push subscription to invoke the Cloud Function

B.Create a Cloud Function with a Cloud Storage trigger and specify the bucket and event type

C.Use a Compute Engine instance to watch the bucket and call the function

D.Set up a Cloud Scheduler job to periodically scan the bucket and invoke the function

AnswerB

Creating a Cloud Function with a Cloud Storage trigger is the native event-driven integration: after you specify the bucket and the `google.storage.object.finalize` event type, Cloud Storage automatically invokes the function whenever a new object is written. No custom infrastructure, no polling, and no intermediate services are needed. This is the simplest, lowest-latency approach because the execution is driven directly by the storage event and automatically scales to zero when idle.

Why this answer

Cloud Functions natively supports Cloud Storage triggers via the `google.storage.object.finalize` event type, which fires when a new object is created in the specified bucket. This is the simplest and most reliable approach, as it eliminates the need for intermediate services and ensures low-latency, event-driven invocation directly from the storage layer.

Exam trap

Google Cloud often tests the misconception that Pub/Sub is required for all event-driven triggers, but Cloud Storage has a direct integration with Cloud Functions that avoids the overhead of an additional messaging layer.

How to eliminate wrong answers

Option A is wrong because using a Pub/Sub topic and push subscription adds unnecessary complexity and latency; Cloud Storage can directly trigger Cloud Functions without an intermediary, and Pub/Sub is typically used for decoupling or fan-out scenarios, not for direct storage events. Option C is wrong because using a Compute Engine instance to poll the bucket introduces compute cost, polling latency, and operational overhead, violating the serverless and event-driven best practices that Cloud Functions are designed for. Option D is wrong because Cloud Scheduler is a cron-based job scheduler for periodic tasks, not for real-time event triggers; it would introduce delays and inefficiency compared to the native event-driven trigger.

Full explanation →

512

MCQeasy

You need to alert when the CPU utilization of your Compute Engine instance exceeds 80% for 5 minutes. What should you create in Cloud Monitoring?

A.An uptime check

B.A metric threshold alerting policy

C.A log-based alert

D.A dashboard chart

AnswerB

In Cloud Monitoring, you create an alerting policy with a condition that uses a threshold for a metric such as 'compute.googleapis.com/instance/cpu/utilization'. The policy samples the metric stream over an alignment period and triggers when the value (e.g., average CPU utilization) crosses the threshold for a specified duration. This is exactly the native mechanism for CPU utilization alerts.

Why this answer

Alerting on a sustained CPU utilization threshold (over 80% for 5 minutes) requires a metric threshold alerting policy in Cloud Monitoring. This policy evaluates the CPU utilization metric against a threshold over a defined duration and triggers notifications when the condition is met. It is the standard mechanism for resource-based alerting.

Exam trap

The trap is confusing alerting mechanisms — candidates may pick uptime checks or log-based alerts because they sound like monitoring, but only a metric threshold policy evaluates numeric resource metrics over time.

How to eliminate wrong answers

Option A is wrong because an uptime check monitors endpoint availability (HTTP/TCP responses), not CPU utilization. Option C is wrong because a log-based alert triggers on log entries matching a filter, not on metric values like CPU percentage. Option D is wrong because a dashboard chart is a visualization tool — it displays metrics but does not evaluate conditions or send alerts.

Full explanation →

513

Multi-Selecteasy

A developer wants to deploy a new application on Google Cloud. The application consists of a frontend service that serves web traffic and a backend service that processes images. Both services need to be containerized. Which two compute options are serverless and support container deployment? (Choose 2)

Select 2 answers

A.Google Kubernetes Engine (GKE)

B.Cloud Functions (2nd gen)

C.Cloud Run

D.Compute Engine

E.Cloud Functions (1st gen)

AnswersB, C

Cloud Functions (2nd gen) is built on Cloud Run infrastructure and, unlike the 1st gen, supports deploying custom container images directly. It provides a fully managed, event-driven serverless execution environment that scales to zero and brings the same container runtime benefits as Cloud Run, while adding event-triggering capabilities like Pub/Sub, Cloud Storage, and HTTP invocations.

Why this answer

Cloud Run and Cloud Functions (2nd gen) both support container images and are serverless (no server management, scale automatically). GKE and Compute Engine are not serverless. Cloud Functions (1st gen) does not support containers.

Full explanation →

514

MCQmedium

An organization has deployed a Compute Engine VM instance running a web server. The web server is not responding to HTTP requests from the internet. The firewall rules allow ingress traffic on port 80 and 443 from any source (0.0.0.0/0). The VM has a public IP address and is in a VPC network with default subnets. What is the most likely cause of the issue?

A.The VM does not have an HTTP health check configured.

B.The web server service is not running on the VM.

C.The VPC network's default firewall rule blocks ingress traffic.

D.The VM is not in the same region as the global load balancer.

AnswerB

The web server service (such as Apache, Nginx, or another HTTP daemon) must be running and listening on the expected port for the VM to respond to HTTP requests. If the service is not installed, stopped, or crashed, the VM's network stack will still be reachable at the IP layer, but the TCP connection to port 80 or 443 will be refused or time out. Checking the service status with systemctl status nginx (or equivalent) is a standard first troubleshooting step. Without an active web server process, no HTTP response can be produced, which directly explains the failure.

Why this answer

The most likely cause of the web server not responding to HTTP requests, despite correct firewall rules and a public IP, is that the web server service (e.g., Apache, Nginx) is not running on the VM. Firewall rules only control network traffic; they do not ensure that the application process is listening on the specified ports. A simple `sudo systemctl status apache2` or `netstat -tlnp` would confirm whether the service is active.

Exam trap

Google Cloud often tests the misconception that firewall rules alone guarantee application availability, when in fact the application service must be running and listening on the correct port.

How to eliminate wrong answers

Option A is wrong because HTTP health checks are used by load balancers to monitor instance health, but they are not required for a standalone VM to respond to HTTP requests; the VM can serve traffic directly without any health check configuration. Option C is wrong because the default VPC firewall rules include an 'allow' rule for ingress traffic on ports 80 and 443 from 0.0.0.0/0, so they do not block the traffic; the issue is not firewall-related. Option D is wrong because a global load balancer is not mentioned in the scenario, and even if one were used, the VM does not need to be in the same region as the load balancer — global load balancers route traffic to backends in any region.

Full explanation →

515

MCQhard

You need to create a log-based metric that counts the number of 5xx errors from your application logs. The logs are in Cloud Logging and contain a field "httpRequest.status". Which filter should you use when creating the metric?

A.httpRequest.status:5*

B.severity=ERROR AND "5xx"

C.httpRequest.status = 500 OR httpRequest.status = 501 OR httpRequest.status = 502

D.httpRequest.status >= 500

AnswerD

This filter uses a comparison operator on the numeric field httpRequest.status. In Cloud Logging, filters support comparison operators like >= for numeric values, so this will match any log entry where the HTTP response status is 500 or higher, capturing all server error statuses (5xx). This is the recommended approach because it is concise and semantically correct.

Why this answer

Log-based metrics use Cloud Logging filter language to select log entries.

Full explanation →

516

MCQmedium

An organization needs to deploy a regional Cloud SQL MySQL instance with 4 vCPUs and 15 GB of memory. The instance should be highly available within a single region. Which gcloud command should they use?

A.gcloud sql instances create my-instance --tier=db-n1-standard-4 --region=us-central1 --database-version=MYSQL_8_0 --root-password=password123 --availability-type=REGIONAL

B.gcloud sql instances create my-instance --tier=db-n1-highmem-4 --region=us-central1 --database-version=MYSQL_8_0

C.gcloud sql instances create my-instance --tier=db-n1-standard-4 --region=us-central1 --database-version=MYSQL_8_0 --root-password=password123

D.gcloud sql instances create my-instance --tier=db-n1-standard-4 --region=us-central1

AnswerA

The REGIONAL availability type provisions a standby instance in a second zone within the same region, satisfying the high-availability constraint. The db-n1-standard-4 tier supplies exactly 4 vCPUs and 15 GB memory, matching the required sizing.

Why this answer

A regional (highly available) Cloud SQL instance requires the `--availability-type=REGIONAL` flag, which provisions a standby in a different zone within the same region and enables automatic failover. Option A includes this flag along with the correct tier, region, database version, and root password, making it the only command that satisfies all stated requirements.

Exam trap

ACE often tests the distinction between ZONAL and REGIONAL availability — candidates assume 'highly available' is the default and forget the explicit `--availability-type=REGIONAL` flag.

How to eliminate wrong answers

Option B is wrong because it uses `db-n1-highmem-4` (4 vCPU, 26 GB RAM), which does not match the 15 GB memory requirement, and it omits both the root password and the `--availability-type=REGIONAL` flag. Option C is wrong because it omits `--availability-type=REGIONAL`, so the instance would be created as ZONAL (non-HA) by default. Option D is wrong because it omits the database version, root password, and availability type — it would create a default-version zonal instance with no root password.

Full explanation →

517

Multi-Selecthard

A company wants to implement a least-privilege security model for a service account that needs to read secrets from Secret Manager and publish messages to Pub/Sub. Which TWO IAM roles should be granted? (Choose TWO)

Select 2 answers

A.roles/pubsub.publisher

B.roles/secretmanager.viewer

C.roles/secretmanager.secretAccessor

D.roles/pubsub.admin

E.roles/secretmanager.admin

AnswersA, C

roles/pubsub.publisher is the correct least-privilege choice because it contains only the pubsub.topics.publish permission, which is exactly what a producer needs to send messages to a Pub/Sub topic. It does not grant permission to create, delete, or modify topics, subscribe, or manage IAM, so a compromised token from this service account could not reconfigure messaging infrastructure.

Why this answer

Option A, roles/pubsub.publisher, is correct because it grants exactly the permission needed to publish messages to a Pub/Sub topic (pubsub.topics.publish) without granting administrative capabilities, which fits the least-privilege requirement. Option C, roles/secretmanager.secretAccessor, is correct because it provides the minimal permission to access the payload of a secret (secretmanager.versions.access), which is precisely what the service account needs to read secrets. Option B, roles/secretmanager.viewer, is not appropriate because it allows viewing secret metadata but not accessing the secret payload, so it would not satisfy the read-secrets requirement.

Option D, roles/pubsub.admin, is too broad since it grants full control over Pub/Sub resources, violating least privilege. Option E, roles/secretmanager.admin, is also overly permissive, granting full administrative control over Secret Manager rather than just read access.

Exam trap

ACE often tests the difference between viewer and accessor roles — candidates pick secretmanager.viewer thinking it allows reading the secret, but it only exposes metadata, not the payload.

Full explanation →

518

MCQeasy

A project manager wants to see how much each GCP service is costing the team this month, broken down by service. Where should they look?

A.IAM & Admin > Quotas

B.Cloud Monitoring > Cost metrics dashboard

C.Billing > Reports (filtered by service)

D.Resource Manager > Project settings > Cost summary

AnswerC

In Google Cloud, the Billing > Reports page is the primary cost analysis tool, presenting detailed spend data by service, SKU, project, location, and time period. You can filter the report by service to isolate, for example, Compute Engine versus Cloud Storage costs and view a grouped table or chart of the totals. This page reflects actual invoice data from the billing account, making it the definitive source for answering 'which service incurred the most cost.'

Why this answer

The Billing > Reports page in the Google Cloud Console allows you to filter costs by service, SKU, project, and other dimensions. This provides a granular breakdown of monthly spending per GCP service, which is exactly what the project manager needs.

Exam trap

Google Cloud often tests the distinction between cost reporting (Billing > Reports) and quota monitoring (IAM & Admin > Quotas), trapping candidates who confuse usage limits with cost breakdowns.

How to eliminate wrong answers

Option A is wrong because IAM & Admin > Quotas shows resource usage limits and current utilization, not cost breakdowns by service. Option B is wrong because Cloud Monitoring > Cost metrics dashboard displays billing metrics aggregated over time but does not provide a per-service cost breakdown; it is designed for monitoring and alerting on cost trends, not detailed service-level reports. Option D is wrong because Resource Manager > Project settings > Cost summary shows a high-level total cost for the project, not a breakdown by individual GCP service.

Full explanation →

519

MCQhard

A Cloud Build pipeline needs to deploy to Cloud Run but the pipeline's service account has only minimal permissions. Rather than granting it Cloud Run Admin, the team wants it to temporarily act as a more privileged deployment service account. Which technique enables this?

A.Download the deployment service account's JSON key and store it in Cloud Build secrets

B.Grant service account impersonation: give the Cloud Build SA the Service Account User role on the deployment SA

C.Add the Cloud Build SA as an Owner of the project

D.Enable service account delegation in the project's IAM settings

AnswerB

This is correct in concept, but the role should be Service Account User (roles/iam.serviceAccountUser), not Token Creator. The exam expects understanding that impersonation requires the actAs permission.

Why this answer

Service account impersonation is the correct technique. The Cloud Build service account needs the Service Account User role (roles/iam.serviceAccountUser) on the deployment service account, which grants the iam.serviceAccounts.actAs permission to temporarily act as it. The Token Creator role only allows token generation, not usage.

This approach avoids granting broad Cloud Run Admin permissions, adhering to least privilege. The other options are incorrect: A stores a static key (security risk), C grants excessive project-level Owner, and D is not a real IAM feature.

Exam trap

A common trap is confusing the Service Account User role (required for impersonation) with the Token Creator role (only for generating tokens). Candidates may also mistakenly think storing keys or using delegation is correct.

How to eliminate wrong answers

Option A is wrong because downloading a JSON key and storing it in Cloud Build secrets introduces a long-lived, static credential that violates security best practices (e.g., key rotation, exposure risk) and does not use temporary, auditable impersonation. Option C is wrong because adding the Cloud Build SA as an Owner of the project grants it full, permanent project-level control, which is far more permissive than needed and contradicts the goal of minimal permissions. Option D is wrong because 'service account delegation' is not a standard IAM setting; the correct mechanism is service account impersonation via the actAs permission and Token Creator role, not a project-level delegation toggle.

Full explanation →

520

MCQmedium

A company wants to migrate an on-premises PostgreSQL database to Google Cloud. They require automated backups, point-in-time recovery, and a 99.95% availability SLA. Which service should they choose?

A.Compute Engine with self-managed PostgreSQL

B.Cloud SQL for PostgreSQL

C.Cloud SQL for MySQL

D.Cloud Spanner

AnswerB

Cloud SQL for PostgreSQL is the managed relational database service natively compatible with PostgreSQL, so your existing schema, queries, and tools carry over. It automates daily backups with transaction log-based PITR by default, offers high availability via a regional failover replica, and carries a 99.95% SLA for the Standard and Enterprise editions. This directly satisfies the stated requirements without requiring you to operate the database infrastructure.

Why this answer

Cloud SQL for PostgreSQL is a fully managed database service that supports automated backups, point-in-time recovery (PITR), and offers a 99.95% availability SLA when configured with high availability (HA). It is specifically designed for PostgreSQL workloads, making it the ideal choice for migrating an on-premises PostgreSQL database to Google Cloud while meeting the stated requirements. The service handles routine tasks like patching, replication, and backups, allowing the company to focus on their application.

Exam trap

ACE often tests the distinction between managed and self-managed database services, and candidates may incorrectly assume that Compute Engine with self-managed PostgreSQL can meet the SLA and automation requirements without additional management overhead.

How to eliminate wrong answers

Option A is wrong because Compute Engine with self-managed PostgreSQL requires the company to manually configure and manage backups, PITR, and HA, and does not provide a managed SLA for the database. Option C is wrong because Cloud SQL for MySQL supports a different database engine (MySQL) and cannot run PostgreSQL workloads without migration and compatibility issues. Option D is wrong because Cloud Spanner is a globally distributed, horizontally scalable relational database that is not PostgreSQL-compatible and is overkill for a simple migration; it also does not support PostgreSQL syntax or tools natively.

Full explanation →

521

MCQeasy

A developer wants to use gcloud CLI with application default credentials (ADC) to authenticate to Google APIs from their local machine. Which command should they run first?

A.gcloud auth login

B.gcloud init

C.gcloud auth application-default login

D.gcloud config set auth/application_default true

AnswerC

gcloud auth application-default login is the correct command because it explicitly generates Application Default Credentials, storing them in the standard location (typically ~/.config/gcloud/application_default_credentials.json). These credentials are then picked up automatically by Google Cloud client libraries when no explicit service account key is supplied, enabling local development to use your user account's permissions as ADC.

Why this answer

Application Default Credentials (ADC) are separate from the user credentials stored by 'gcloud auth login'. To set up ADC for local development, the developer must run 'gcloud auth application-default login', which writes credentials to a well-known location (e.g., ~/.config/gcloud/application_default_credentials.json) that client libraries automatically discover. This is the first step required before using ADC with Google APIs locally.

Exam trap

The trap is confusing 'gcloud auth login' (CLI user auth) with 'gcloud auth application-default login' (ADC for client libraries) — candidates pick the more familiar 'gcloud auth login' and wonder why their code cannot authenticate.

How to eliminate wrong answers

Option A is wrong because 'gcloud auth login' authenticates the gcloud CLI itself for interactive commands, but it does not create ADC — client libraries using ADC will not find those credentials. Option B is wrong because 'gcloud init' is a setup wizard that configures gcloud (account, project, region), but it does not generate ADC files for application code. Option D is wrong because 'gcloud config set auth/application_default true' is not a real configuration property — there is no such flag; ADC is established by running the login command, not by setting a config value.

Full explanation →

522

MCQmedium

Your organization mandates that all service-to-service communication within a GKE cluster must be encrypted in transit using mutual TLS (mTLS). The team does not want to manage certificates or modify application code. Which solution meets these requirements?

A.Configure Kubernetes TLS Secrets and mount them as volumes in each pod.

B.Enable Anthos Service Mesh with mTLS policy set to STRICT mode.

C.Use Cloud Armor to enforce TLS between services within the cluster.

D.Enable GKE node-to-node encryption to encrypt all traffic between nodes.

AnswerB

Anthos Service Mesh (ASM), built on Istio, injects an Envoy sidecar proxy into each pod. The sidecars intercept all service-to-service traffic and automatically negotiate mutual TLS (mTLS) using SPIFFE identities derived from Kubernetes service accounts. In STRICT mode, the mesh rejects any plaintext connection, ensuring every communication path is both encrypted and mutually authenticated — all without modifying application code or managing certificates manually.

Why this answer

Anthos Service Mesh (ASM) with mTLS set to STRICT mode enforces mutual TLS between all services in the mesh without requiring any application code changes or manual certificate management. ASM automatically injects Envoy sidecar proxies that handle certificate issuance, rotation, and encryption, meeting the requirement for encrypted service-to-service communication with mTLS.

Exam trap

Google Cloud often tests the distinction between network-layer encryption (node-to-node) and application-layer mTLS (service-to-service), leading candidates to mistakenly choose node-to-node encryption as a solution for service-level mTLS requirements.

How to eliminate wrong answers

Option A is wrong because mounting Kubernetes TLS Secrets as volumes requires manual certificate management and application code changes to load and use the certificates, which violates the 'do not want to manage certificates or modify application code' requirement. Option C is wrong because Cloud Armor is a web application firewall that protects external HTTP(S) traffic at the edge of the GKE cluster, not internal service-to-service traffic within the cluster. Option D is wrong because GKE node-to-node encryption encrypts traffic between nodes at the network layer (IPsec), not at the application layer between individual pods/services, and does not provide mutual TLS authentication between services.

Full explanation →

523

MCQmedium

An engineer needs to enable Private Google Access for a subnet to allow instances without external IPs to access Google APIs and services. Which flag should be used when creating or updating the subnet?

A.--enable-google-access

B.--private-google-access

C.--enable-private-ip-google-access

D.--enable-private-ip

AnswerC

This is the correct flag. According to the gcloud compute networks subnets update documentation, "--enable-private-ip-google-access" modifies the subnet's privateIpGoogleAccess field, allowing VM instances without external IP addresses to reach Google APIs using the subnet's default route. This is the only flag listed that maps directly to the REST API parameter.

Why this answer

Private Google Access is enabled on a subnet using the `--enable-private-ip-google-access` flag. This allows instances in the subnet to reach Google APIs via the default route.

Full explanation →

524

MCQeasy

Which GCP service protects internet-facing applications against SQL injection, cross-site scripting (XSS), and other OWASP Top 10 attacks?

A.Cloud Firewall (VPC firewall rules)

B.Cloud Armor WAF with preconfigured OWASP Core Rule Set

C.Security Command Center's Web Security Scanner

D.Cloud Identity-Aware Proxy (IAP)

AnswerB

Cloud Armor WAF with the preconfigured OWASP Core Rule Set is the correct choice because it performs deep, content-aware inspection of each HTTP request at the Google Cloud load balancer edge. Its rules are based on the OWASP ModSecurity Core Rule Set, which includes signatures and heuristics specifically designed to detect SQL injection, cross-site scripting, and other Top-10 web application attacks. When a request matches a malicious pattern, Cloud Armor can deny it before it ever reaches your backend instances, giving you runtime protection rather than just a report or a network-level filter.

Why this answer

Cloud Armor WAF with the preconfigured OWASP Core Rule Set (CRS) is specifically designed to protect internet-facing applications from web application attacks, including SQL injection, cross-site scripting (XSS), and other OWASP Top 10 threats. It operates at the edge of Google's network, inspecting HTTP/HTTPS traffic against a set of rules that match known attack patterns, and can be integrated with Cloud Load Balancing to filter malicious requests before they reach the backend.

Exam trap

Google Cloud often tests the distinction between a WAF that inspects application-layer payloads (Cloud Armor) and network-layer firewalls (VPC firewall rules) or identity-based access controls (IAP), leading candidates to confuse perimeter security with application-layer protection.

How to eliminate wrong answers

Option A is wrong because Cloud Firewall (VPC firewall rules) operates at the network layer (L3/L4) and cannot inspect application-layer payloads such as SQL injection or XSS strings; it only filters based on IP addresses, ports, and protocols. Option C is wrong because Security Command Center's Web Security Scanner is a vulnerability scanning tool that identifies security flaws in web applications, not a real-time protection service that blocks attacks in transit. Option D is wrong because Cloud Identity-Aware Proxy (IAP) provides access control based on identity and context, but it does not inspect or filter HTTP request payloads for malicious content like SQL injection or XSS.

Full explanation →

525

Multi-Selecthard

A company wants to allow developers to create and manage secrets in Secret Manager, but prevent them from viewing secret values. Which TWO predefined roles should be combined to achieve this?

Select 2 answers

A.roles/secretmanager.admin

B.roles/secretmanager.secretAccessor

C.roles/secretmanager.secretManager

D.roles/secretmanager.secretVersionManager

E.roles/secretmanager.viewer

AnswersC, D

roles/secretmanager.secretManager grants permissions to create, get, list, update, and delete secret resources, plus view metadata, but deliberately omits secretmanager.versions.access. This lets developers fully manage the secret lifecycle without ever being able to view the sensitive payload, making it the correct least-privilege choice for the stated requirement to create and manage secrets while preventing access to values.

Why this answer

The roles/secretmanager.admin role includes permissions to create and manage secrets but not to access secret versions (i.e., view values). However, it includes the permission to access versions. Actually, the admin role includes secretmanager.versions.access, so it can view values.

To separate manage from view, you need roles/secretmanager.secretVersionManager (manage versions without access) and roles/secretmanager.secretManager (manage secrets). Wait, the correct combination is roles/secretmanager.secretVersionManager (create/disable/destroy versions) and roles/secretmanager.secretManager (create/update/delete secrets). Neither includes secretmanager.versions.access.

The roles/secretmanager.viewer allows viewing metadata but not values. The roles/secretmanager.secretAccessor allows accessing versions. To manage without viewing, combine roles that exclude access.

Check accurate roles: roles/secretmanager.admin includes all permissions including access. roles/secretmanager.secretManager includes manage secrets but not access versions? Let's verify: roles/secretmanager.secretManager has permissions: secretmanager.secrets.create, secretmanager.secrets.delete, secretmanager.secrets.get, secretmanager.secrets.update, secretmanager.secrets.list. It does NOT include secretmanager.versions.access. roles/secretmanager.secretVersionManager has permissions: secretmanager.versions.create, secretmanager.versions.disable, secretmanager.versions.destroy, secretmanager.versions.enable, secretmanager.versions.get, secretmanager.versions.list. It does NOT include secretmanager.versions.access.

So combining these two roles allows managing secrets and versions but not accessing the payload. roles/secretmanager.viewer allows viewing metadata but not accessing payload. roles/secretmanager.secretAccessor allows accessing payload. So the correct two are secretManager and secretVersionManager.

Full explanation →

Google Associate Cloud Engineer (ACE) — Questions 451–525