Scenario practice questions

A company is migrating an on-premises PostgreSQL database (5 TB) to Cloud SQL. They need minimal downtime and automated schema conversion if needed. Which GCP service should they use?

Trap 1: Datastream

Datastream provides change data capture for replicating ongoing changes into Cloud SQL, but it does not perform schema conversion or the bulk initial load of a 5 TB database. It is the right tool for continuous replication during cutover, not for the migration itself, so it fails the schema-conversion requirement.

Trap 2: Migrate for Compute Engine (formerly Velostrata)

Migrate for Compute Engine replicates VM workloads to Compute Engine, not database schemas into Cloud SQL, so it cannot perform the required schema conversion or minimal-downtime PostgreSQL migration. It is tempting because it excels at lift-and-shift VM migrations where source servers must run unchanged on Google Compute Engine.

Trap 3: Transfer Appliance

Transfer Appliance physically ships data to Cloud Storage, offering no direct Cloud SQL import, replication, or schema conversion, so downtime and conversion needs go unmet. It is tempting for bulk offline transfers of very large datasets where network bandwidth is the limiting factor and no live cutover is required.

A
Database Migration Service (DMS)
Database Migration Service performs continuous replication from the on-premises PostgreSQL source to Cloud SQL, keeping downtime to a minimum during cutover. Its built-in schema conversion handles incompatible objects automatically, satisfying the automated conversion requirement for the 5 TB migration.
B
Datastream
Why it fails: Datastream provides change data capture for replicating ongoing changes into Cloud SQL, but it does not perform schema conversion or the bulk initial load of a 5 TB database. It is the right tool for continuous replication during cutover, not for the migration itself, so it fails the schema-conversion requirement.
C
Migrate for Compute Engine (formerly Velostrata)
Why it fails: Migrate for Compute Engine replicates VM workloads to Compute Engine, not database schemas into Cloud SQL, so it cannot perform the required schema conversion or minimal-downtime PostgreSQL migration. It is tempting because it excels at lift-and-shift VM migrations where source servers must run unchanged on Google Compute Engine.
D
Transfer Appliance
Why it fails: Transfer Appliance physically ships data to Cloud Storage, offering no direct Cloud SQL import, replication, or schema conversion, so downtime and conversion needs go unmet. It is tempting for bulk offline transfers of very large datasets where network bandwidth is the limiting factor and no live cutover is required.

Question 2easymulti select

A company runs a batch processing job that uses preemptible VMs. The job occasionally fails due to VM preemption. They want to improve reliability without significantly increasing cost. Which TWO actions should they take? (Choose TWO.)

Trap 1: Use sole-tenant nodes to reduce risk of preemption

Sole-tenant nodes only guarantee physical host exclusivity; they do not exempt workloads from preemption, so failures continue. It is tempting because sole-tenant nodes genuinely address compliance and licensing isolation, which is the correct choice when regulatory separation, not preemption resilience, is the requirement.

Trap 2: Switch to regular (non-preemptible) VMs

Regular VMs eliminate preemption entirely but bill at full on-demand rates, breaching the requirement to avoid significant cost increases. It is tempting because non-preemptible instances genuinely suit latency-sensitive or stateful workloads, which is the correct choice when reliability outweighs cost.

Trap 3: Increase the number of preemptible VMs

Adding more preemptible VMs increases parallel capacity but each instance remains reclaimable, so the job still fails when capacity is withdrawn. It is tempting because horizontal scaling genuinely improves throughput for interruption-tolerant work, which is correct when the goal is speed rather than reliability.

A
Use a managed instance group with autoscaling and preemptible VMs
A managed instance group automatically recreates preempted VMs, directly addressing the reliability constraint while retaining preemptible pricing. Autoscaling maintains capacity by adding instances when demand rises, so the batch job recovers without manual intervention. This satisfies the requirement to improve resilience without significantly increasing cost, since preemptible rates still apply.
B
Use sole-tenant nodes to reduce risk of preemption
Why it fails: Sole-tenant nodes only guarantee physical host exclusivity; they do not exempt workloads from preemption, so failures continue. It is tempting because sole-tenant nodes genuinely address compliance and licensing isolation, which is the correct choice when regulatory separation, not preemption resilience, is the requirement.
C
Switch to regular (non-preemptible) VMs
Why it fails: Regular VMs eliminate preemption entirely but bill at full on-demand rates, breaching the requirement to avoid significant cost increases. It is tempting because non-preemptible instances genuinely suit latency-sensitive or stateful workloads, which is the correct choice when reliability outweighs cost.
D
Implement a retry mechanism in the job to re-run failed tasks
Preemption terminates tasks mid-execution, so a retry mechanism re-runs failed tasks once replacement VMs appear. This directly addresses the intermittent failure mode without changing the compute tier, preserving the cost constraint while improving job completion reliability.
E
Increase the number of preemptible VMs
Why it fails: Adding more preemptible VMs increases parallel capacity but each instance remains reclaimable, so the job still fails when capacity is withdrawn. It is tempting because horizontal scaling genuinely improves throughput for interruption-tolerant work, which is correct when the goal is speed rather than reliability.

Question 3hardmultiple choice

An organization wants to deploy a containerized microservices architecture on Google Kubernetes Engine (GKE) and minimize operational overhead. They do not need to manage the node infrastructure and are willing to accept some limitations on node configuration. Which GKE mode should they choose?

Trap 1: GKE Standard mode with zonal cluster

GKE Standard mode, zonal or regional, requires the customer to provision, scale and patch node pools, so operational overhead remains. It is tempting because Standard permits full node configuration control, but the scenario explicitly forgoes that control to minimise overhead, which Autopilot mode provides.

Trap 2: Compute Engine with container-optimized OS and instance groups

Standard mode requires you to provision and manage Compute Engine node pools yourself, so operational overhead stays with your team. It is tempting because instance groups suit bespoke node images or GPU shapes, but the stem explicitly rules out node management and accepts configuration limits, which Autopilot satisfies.

Trap 3: Cloud Run for Anthos

Cloud Run for Anthos runs serverless workloads on an existing Anthos cluster and does not provide a managed GKE control plane with node pools. It is tempting because it removes node management, but the scenario requires deploying microservices on GKE itself, which Autopilot mode satisfies.

A
GKE Standard mode with zonal cluster
Why it fails: GKE Standard mode, zonal or regional, requires the customer to provision, scale and patch node pools, so operational overhead remains. It is tempting because Standard permits full node configuration control, but the scenario explicitly forgoes that control to minimise overhead, which Autopilot mode provides.
B
Compute Engine with container-optimized OS and instance groups
Why it fails: Standard mode requires you to provision and manage Compute Engine node pools yourself, so operational overhead stays with your team. It is tempting because instance groups suit bespoke node images or GPU shapes, but the stem explicitly rules out node management and accepts configuration limits, which Autopilot satisfies.
C
Cloud Run for Anthos
Why it fails: Cloud Run for Anthos runs serverless workloads on an existing Anthos cluster and does not provide a managed GKE control plane with node pools. It is tempting because it removes node management, but the scenario requires deploying microservices on GKE itself, which Autopilot mode satisfies.
D
GKE Autopilot mode
GKE Autopilot provisions and manages the nodes itself, so the organisation never handles node infrastructure, directly satisfying the minimal-operational-overhead constraint. Its trade-off is restricted node configuration, which the stem explicitly accepts, making it the fitting mode.

Question 4hardmultiple choice

Refer to the exhibit. All five nginx pods are scheduled on the same node (default-pool-1). What is the most likely reason?

Network Topology

Trap 1: The node auto-scaler has not created additional nodes yet, but the…

Autoscaler lag would delay new nodes, yet the stem states other nodes already exist, so scheduling could spread pods across them. That rules out capacity as the cause; an affinity or selector constraint pinning pods to default-pool-1 explains the concentration.

Trap 2: The pods have a nodeSelector that matches only default-pool-1.

A nodeSelector matching only default-pool-1 would indeed pin pods there, but the exhibit shows other nodes present and schedulable, so the constraint is not the observed cause. Node selectors are correct when workloads must target specific hardware or labelled pools deliberately.

Trap 3: The resource requests are too high, so the scheduler packed pods…

Incorrect: The total requests for 5 pods are 2500m CPU and 5Gi memory, which would easily fit on one e2-standard-2 node (2 vCPU, 8GB RAM), but the other nodes also have capacity. The scheduler would spread by default.

A
The node auto-scaler has not created additional nodes yet, but the other nodes are present.
Why it fails: Autoscaler lag would delay new nodes, yet the stem states other nodes already exist, so scheduling could spread pods across them. That rules out capacity as the cause; an affinity or selector constraint pinning pods to default-pool-1 explains the concentration.
B
The pods have a nodeSelector that matches only default-pool-1.
Why it fails: A nodeSelector matching only default-pool-1 would indeed pin pods there, but the exhibit shows other nodes present and schedulable, so the constraint is not the observed cause. Node selectors are correct when workloads must target specific hardware or labelled pools deliberately.
C
The other nodes have taints that the pods do not tolerate.
Taints on other nodes repel pods lacking matching tolerations, so the scheduler cannot place them there. With no tolerations defined in the pod spec, every other node rejects the nginx pods, leaving default-pool-1 as the only viable target and concentrating all five replicas on it.
D
The resource requests are too high, so the scheduler packed pods onto one node due to resource constraints on the others.
Why it fails: Incorrect: The total requests for 5 pods are 2500m CPU and 5Gi memory, which would easily fit on one e2-standard-2 node (2 vCPU, 8GB RAM), but the other nodes also have capacity. The scheduler would spread by default.

Question 5mediummultiple choice

A company runs batch analytics workloads each night on Compute Engine VMs. The workloads are fault-tolerant and can be interrupted. The finance team wants to reduce compute costs. Which Compute Engine pricing model should they use?

Trap 1: Committed use discounts (1-year or 3-year)

Committed use discounts require a 1- or 3-year spend commitment for steady, predictable usage; nightly interruptible batch workloads gain nothing and lock in cost. They suit continuously running production VMs whose usage is stable over the term.

Trap 2: Sustained use discounts

Sustained use discounts apply automatically to VMs running for a large portion of the billing month; nightly batch jobs run only hours, so discounts never accrue. They suit long-running, always-on instances rather than short, interruptible bursts.

Trap 3: Sole-tenant nodes

Sole-tenant nodes provide physical server isolation for licensing or compliance requirements, not interruptible cost savings. They bill for the entire node regardless of workload usage, so nightly batch jobs would pay for idle capacity. Spot VMs suit fault-tolerant, interruptible workloads by offering steep discounts when capacity is reclaimed.

A
Committed use discounts (1-year or 3-year)
Why it fails: Committed use discounts require a 1- or 3-year spend commitment for steady, predictable usage; nightly interruptible batch workloads gain nothing and lock in cost. They suit continuously running production VMs whose usage is stable over the term.
B
Preemptible VMs
Preemptible VMs suit fault-tolerant batch jobs because they cost up to 80% less than standard instances, though Compute Engine may terminate them within 24 hours. Since the nightly analytics workloads can be interrupted without harm, this discount directly satisfies the finance team's cost-reduction constraint.
C
Sustained use discounts
Why it fails: Sustained use discounts apply automatically to VMs running for a large portion of the billing month; nightly batch jobs run only hours, so discounts never accrue. They suit long-running, always-on instances rather than short, interruptible bursts.
D
Sole-tenant nodes
Why it fails: Sole-tenant nodes provide physical server isolation for licensing or compliance requirements, not interruptible cost savings. They bill for the entire node regardless of workload usage, so nightly batch jobs would pay for idle capacity. Spot VMs suit fault-tolerant, interruptible workloads by offering steep discounts when capacity is reclaimed.

Question 6easymulti select

A development team uses BigQuery for analytical queries. They want to reduce query costs for a large table that is frequently filtered by a date column and a customer_id column. Which TWO table design strategies will reduce the amount of data scanned? (Choose 2)

Trap 1: Create an index on customer_id.

BigQuery tables are columnar and cannot use traditional indexes; clustering on customer_id is the mechanism that prunes scanned data. An index is tempting because it is the standard relational tuning tool, and would be correct on row-store systems such as Cloud SQL or SQL Server.

Trap 2: Use wildcard tables with date suffixes.

Wildcard tables with date suffixes still scan every matching table unless the query filters on the _TABLE_SUFFIX pseudo-column, so they do not themselves prune data. They are tempting because they organise date-sharded datasets, and would be correct for querying across many legacy daily export tables.

Trap 3: Normalize the table into multiple tables.

Normalisation splits columns across tables but does not reduce bytes scanned for date and customer_id filters; partitioning and clustering do. It is tempting because normalisation is a classic modelling practise, and it would be correct when the goal is eliminating update anomalies rather than lowering query cost.

A
Partition the table by date.
Partitioning by date divides the table into segments, so queries filtering on the date column prune irrelevant partitions and scan only matching ones. This directly reduces bytes scanned, satisfying the cost-reduction goal for date-filtered analytical queries.
B
Create an index on customer_id.
Why it fails: BigQuery tables are columnar and cannot use traditional indexes; clustering on customer_id is the mechanism that prunes scanned data. An index is tempting because it is the standard relational tuning tool, and would be correct on row-store systems such as Cloud SQL or SQL Server.
C
Use wildcard tables with date suffixes.
Why it fails: Wildcard tables with date suffixes still scan every matching table unless the query filters on the _TABLE_SUFFIX pseudo-column, so they do not themselves prune data. They are tempting because they organise date-sharded datasets, and would be correct for querying across many legacy daily export tables.
D
Normalize the table into multiple tables.
Why it fails: Normalisation splits columns across tables but does not reduce bytes scanned for date and customer_id filters; partitioning and clustering do. It is tempting because normalisation is a classic modelling practise, and it would be correct when the goal is eliminating update anomalies rather than lowering query cost.
E
Cluster the table on customer_id.
Clustering on customer_id physically co-locates rows sharing that value, so filters on customer_id prune blocks before scanning. This directly reduces bytes read for the frequently filtered column, satisfying the cost-reduction constraint. Pair it with date partitioning to cover both filter predicates.

Question 7easymultiple choice

A logistics company is planning its first Google Cloud landing zone. It has three business units that must be billed separately, a central network team that manages shared VPCs, and a security team that needs to apply guardrails across everything. Which resource hierarchy design should the architect recommend?

Trap 1: Create one project per business unit, place all projects directly…

Flat placement under the organization makes it hard to delegate administration and to apply different policies per business unit, since every project is a direct child. Labels can help with billing reports but do not participate in the IAM or policy inheritance model, so security guardrails cannot be scoped to a business unit. This design also complicates separating shared networking from application projects.

Trap 2: Create a single project for the whole company and use IAM roles and…

A single project cannot satisfy separate billing per business unit because billing is tracked at the project level, and it creates a shared quota and IAM blast radius across all teams. Labels alone do not enforce isolation. Shared VPC and environment separation are also difficult to model cleanly inside one project, making this design unsuitable for a multi-unit landing zone.

Trap 3: Create one organization per business unit, each with its own…

A Google Cloud organization maps to a single identity domain, and creating multiple organizations for one company is not the intended model and duplicates identity and policy management. It also prevents central guardrails from being applied uniformly. VPC peering between separate organizations does not replace shared VPC for centrally managed networking and adds unnecessary complexity.

A
Create one project per business unit, place all projects directly under the organization node, and use labels to separate billing and security policies.
Why it fails: Flat placement under the organization makes it hard to delegate administration and to apply different policies per business unit, since every project is a direct child. Labels can help with billing reports but do not participate in the IAM or policy inheritance model, so security guardrails cannot be scoped to a business unit. This design also complicates separating shared networking from application projects.
B
Create folders per business unit and per environment under the organization, place application projects inside those folders, and create a separate shared networking project owned by the central network team.
Folders allow policies and IAM to be inherited and scoped per business unit and environment, satisfying the security team's need for guardrails. Placing application projects inside environment folders keeps production and non-production separated. A dedicated shared networking project, owned centrally, is the standard pattern for shared VPC host projects and keeps network administration distinct from application ownership, supporting separate billing.
C
Create a single project for the whole company and use IAM roles and labels to separate business units, environments, and network administration.
Why it fails: A single project cannot satisfy separate billing per business unit because billing is tracked at the project level, and it creates a shared quota and IAM blast radius across all teams. Labels alone do not enforce isolation. Shared VPC and environment separation are also difficult to model cleanly inside one project, making this design unsuitable for a multi-unit landing zone.
D
Create one organization per business unit, each with its own projects, and link them with VPC peering for shared network services.
Why it fails: A Google Cloud organization maps to a single identity domain, and creating multiple organizations for one company is not the intended model and duplicates identity and policy management. It also prevents central guardrails from being applied uniformly. VPC peering between separate organizations does not replace shared VPC for centrally managed networking and adds unnecessary complexity.

Question 8mediummulti select

A team needs to set up alerting for a production service. They want to receive notifications when the 99th percentile latency exceeds 500ms for 5 minutes. Which two Cloud Monitoring components are required? (Choose two.)

Answer choices are not available in this preview. Open the full question page for the complete review.

Question 9mediummultiple choice

Refer to the exhibit. A user reports that the instance 'batch-vm' is unavailable. Based on the output, what is the most likely cause of the unavailability?

Network Topology

Trap 1: The VM was stopped manually by a user.

The exhibit's status shows the instance terminated or stopped by the system or a scheduled operation, not a manual user action; manual stops appear differently. It tempts because users commonly stop batch VMs, but the displayed reason indicates an automated or policy-driven shutdown.

Trap 2: The VM lost its external IP address.

Losing an external IP affects inbound connectivity, not the instance's reported state; the exhibit shows the VM itself not running. It tempts because unreachable instances often stem from networking, but the status field here points to the instance lifecycle rather than address assignment.

Trap 3: The VM crashed due to an out-of-memory error.

The exhibit shows the instance stopped or terminated, not memory exhaustion; an OOM crash would leave the VM running or show a host error. OOM is tempting because batch workloads consume memory heavily, but the displayed status indicates an administrative stop instead.

A
The VM was stopped manually by a user.
Why it fails: The exhibit's status shows the instance terminated or stopped by the system or a scheduled operation, not a manual user action; manual stops appear differently. It tempts because users commonly stop batch VMs, but the displayed reason indicates an automated or policy-driven shutdown.
B
The preemptible VM was terminated by Google due to its preemptible nature.
Preemptible VMs run at lower cost but Google can reclaim them at any time with a 30-second warning, stopping the instance abruptly. The exhibit's terminated status and preemptible flag confirm this involuntary reclaim, not a crash or quota issue.
C
The VM lost its external IP address.
Why it fails: Losing an external IP affects inbound connectivity, not the instance's reported state; the exhibit shows the VM itself not running. It tempts because unreachable instances often stem from networking, but the status field here points to the instance lifecycle rather than address assignment.
D
The VM crashed due to an out-of-memory error.
Why it fails: The exhibit shows the instance stopped or terminated, not memory exhaustion; an OOM crash would leave the VM running or show a host error. OOM is tempting because batch workloads consume memory heavily, but the displayed status indicates an administrative stop instead.

Question 10hardmultiple choice

A global e-commerce site uses an external HTTPS load balancer with a backend service pointing to a managed instance group. Some users report 503 errors during peak traffic. The backend instances are healthy and not overloaded. What is the most likely cause?

Trap 1: The CDN cache is not warming up properly

CDN cache warming affects hit ratio and origin latency, not load balancer 503 responses, and the stem describes a backend service rather than CDN behaviour. It is tempting because cache misses during traffic spikes can degrade performance, making warming the right answer when origin load from cold caches is the actual problem.

Trap 2: The backend service's health check interval is too short

A short health check interval probes backends more frequently, which does not produce 503s when instances are healthy; capacity exhaustion or connection draining does. It is tempting because tuning health checks is a common remedy when backends are wrongly marked unhealthy, which is the correct fix for that different symptom.

Trap 3: The SSL certificate is expired

An expired SSL certificate causes TLS handshake failures and browser certificate warnings, not intermittent 503s under peak load. It is tempting because certificate expiry is a frequent cause of HTTPS outages, and it would be the correct diagnosis if all users failed consistently rather than only some during peaks.

A
The CDN cache is not warming up properly
Why it fails: CDN cache warming affects hit ratio and origin latency, not load balancer 503 responses, and the stem describes a backend service rather than CDN behaviour. It is tempting because cache misses during traffic spikes can degrade performance, making warming the right answer when origin load from cold caches is the actual problem.
B
The backend service's health check interval is too short
Why it fails: A short health check interval probes backends more frequently, which does not produce 503s when instances are healthy; capacity exhaustion or connection draining does. It is tempting because tuning health checks is a common remedy when backends are wrongly marked unhealthy, which is the correct fix for that different symptom.
C
The SSL certificate is expired
Why it fails: An expired SSL certificate causes TLS handshake failures and browser certificate warnings, not intermittent 503s under peak load. It is tempting because certificate expiry is a frequent cause of HTTPS outages, and it would be the correct diagnosis if all users failed consistently rather than only some during peaks.
D
The load balancer's max rate per backend is configured too low
The max rate per backend setting caps requests per second sent to each instance; when set too low, the load balancer sheds excess traffic and returns 503s even though instances are healthy. Raising this limit resolves the throttling-induced errors during peak load.

Question 11mediummultiple choice

A security engineer wants to prevent data exfiltration from a project 'prod-data' by ensuring that only approved VPC networks can access BigQuery datasets. Which GCP service should be used?

Trap 1: Private Google Access

Private Google Access only lets VM instances without external IP addresses reach Google APIs; it grants no control over which networks may query a dataset. VPC Service Controls perimeters are the mechanism that restricts BigQuery access to approved networks and blocks exfiltration.

Trap 2: Cloud Armor

Cloud Armor filters HTTP(S) traffic at the edge against web attacks and DDoS; it never authorises BigQuery API calls. VPC Service Controls draws a perimeter around the dataset so only approved networks reach it, which is the exfiltration control required here.

Trap 3: Cloud NAT

Cloud NAT provides outbound internet connectivity for private instances; it enforces no access policy on Google APIs. Restricting BigQuery to approved networks requires a VPC Service Controls perimeter, which denies requests originating outside the defined boundary.

A
Private Google Access
Why it fails: Private Google Access only lets VM instances without external IP addresses reach Google APIs; it grants no control over which networks may query a dataset. VPC Service Controls perimeters are the mechanism that restricts BigQuery access to approved networks and blocks exfiltration.
B
Cloud Armor
Why it fails: Cloud Armor filters HTTP(S) traffic at the edge against web attacks and DDoS; it never authorises BigQuery API calls. VPC Service Controls draws a perimeter around the dataset so only approved networks reach it, which is the exfiltration control required here.
C
Cloud NAT
Why it fails: Cloud NAT provides outbound internet connectivity for private instances; it enforces no access policy on Google APIs. Restricting BigQuery to approved networks requires a VPC Service Controls perimeter, which denies requests originating outside the defined boundary.
D
VPC Service Controls
VPC Service Controls builds a service perimeter around BigQuery, restricting access to approved VPC networks and blocking data exfiltration even by authorised identities. This directly enforces the network-origin constraint on the prod-data project's datasets, which IAM alone cannot achieve.

Question 12hardmultiple choice

The exhibit shows a command to create a Compute Engine instance. The instance is intended to run a web server that needs to access Cloud Storage buckets using its service account. However, the web server fails to read from a storage bucket. What is the most likely cause?

Exhibit

Refer to the exhibit.

gcloud compute instances create my-instance \
    --zone=us-central1-a \
    --machine-type=n1-standard-4 \
    --image-family=ubuntu-2004-lts \
    --image-project=ubuntu-os-cloud \
    --boot-disk-size=50GB \
    --boot-disk-type=pd-ssd \
    --scopes=cloud-platform \
    --service-account=my-sa@project.iam.gserviceaccount.com \
    --tags=http-server,https-server

Trap 1: The service account is not attached to the instance

If no service account is attached, the instance uses the default Compute Engine service account, which may lack Storage Object Viewer on the bucket, causing reads to fail. Attaching the intended service account and granting it bucket IAM roles resolves this. This option is correct whenever the instance genuinely lacks an attached service account.

Trap 2: The tags http-server and https-server block outbound traffic

The http-server and https-server tags are network tags that enable inbound firewall rules for web traffic; they do not restrict outbound traffic to Cloud Storage. Egress to Google APIs is governed by IAM permissions and access scopes. These tags would be relevant when configuring inbound HTTP or HTTPS access to the web server itself.

Trap 3: The boot disk type is SSD, which is not compatible with Cloud…

Boot disk type is unrelated to Cloud Storage access; SSD and standard persistent disks both support the same network and IAM permissions. The failure stems from the instance's identity or scopes, not its disk. SSD would be the correct choice when the requirement is higher disk throughput for the boot volume, not storage bucket access.

A
The service account is not attached to the instance
Why it fails: If no service account is attached, the instance uses the default Compute Engine service account, which may lack Storage Object Viewer on the bucket, causing reads to fail. Attaching the intended service account and granting it bucket IAM roles resolves this. This option is correct whenever the instance genuinely lacks an attached service account.
B
The tags http-server and https-server block outbound traffic
Why it fails: The http-server and https-server tags are network tags that enable inbound firewall rules for web traffic; they do not restrict outbound traffic to Cloud Storage. Egress to Google APIs is governed by IAM permissions and access scopes. These tags would be relevant when configuring inbound HTTP or HTTPS access to the web server itself.
C
The boot disk type is SSD, which is not compatible with Cloud Storage
Why it fails: Boot disk type is unrelated to Cloud Storage access; SSD and standard persistent disks both support the same network and IAM permissions. The failure stems from the instance's identity or scopes, not its disk. SSD would be the correct choice when the requirement is higher disk throughput for the boot volume, not storage bucket access.
D
The service account lacks IAM permissions to read from Cloud Storage
The instance's attached service account has no IAM role granting storage.objects.get on the bucket, so Cloud Storage returns 403 regardless of network or scope settings. Access scopes only gate the API surface; IAM bindings authorise the actual read, making missing permissions the direct cause of the failure.

Question 13mediummultiple choice

The exhibit shows a Cloud Storage bucket IAM policy. A developer (admin@example.com) wants to upload a file to the bucket but gets a permission denied error. What is the most likely reason?

Exhibit

Refer to the exhibit.

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:admin@example.com"
      ]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "serviceAccount:my-sa@project.iam.gserviceaccount.com"
      ]
    }
  ]
}

Trap 1: An organization policy denies all write operations

No evidence of org policy.

Trap 2: The developer is not a member of the project

Project membership is not required to access a bucket; bucket-level IAM bindings grant access independently of project roles. Project membership matters for project-wide permissions, but the denial stems from the bucket policy's actual bindings, which the exhibit shows omitting this developer.

Trap 3: The service account my-sa overrides the developer's permissions

IAM is additive: no service account can subtract a principal's granted roles, so my-sa cannot override admin@example.com's permissions. The binding granting the developer storage.objects.create is simply absent from the bucket policy. Service account impersonation matters only when a workload authenticates as that account rather than as the developer.

A
An organization policy denies all write operations
Why it fails: No evidence of org policy.
B
The developer is not a member of the project
Why it fails: Project membership is not required to access a bucket; bucket-level IAM bindings grant access independently of project roles. Project membership matters for project-wide permissions, but the denial stems from the bucket policy's actual bindings, which the exhibit shows omitting this developer.
C
The service account my-sa overrides the developer's permissions
Why it fails: IAM is additive: no service account can subtract a principal's granted roles, so my-sa cannot override admin@example.com's permissions. The binding granting the developer storage.objects.create is simply absent from the bucket policy. Service account impersonation matters only when a workload authenticates as that account rather than as the developer.
D
The developer is assigned only the objectViewer role
The objectViewer role grants read-only access to objects, so it cannot authorise uploads. Uploading requires storage.objects.create, which objectViewer excludes. The permission denied error therefore stems from the developer lacking a write-capable role such as objectCreator or objectAdmin, matching the stem's upload constraint.

Question 14mediummulti select

A company wants to implement a zero-trust access model for internal web applications running on Compute Engine. They need to authenticate users using corporate credentials and enforce context-aware access based on device posture and IP address. Which TWO services should they use?

Trap 1: VPC Service Controls

VPC Service Controls builds a service perimeter around Google Cloud APIs to block data exfiltration, but it neither authenticates users nor evaluates device posture or IP context. It is tempting because it underpins zero-trust data boundaries, and would be correct when the requirement is preventing data movement across project perimeters.

Trap 2: Cloud VPN

Cloud VPN provides an encrypted IPsec tunnel between on-premises networks and a VPC, so it cannot authenticate individual users against corporate credentials or assess device posture. It is tempting because it secures connectivity, and would be correct when the requirement is extending a private network to Google Cloud.

Trap 3: Cloud Armor

Cloud Armor provides edge security: WAF rules, DDoS protection and IP-based allow/deny policies. It does not authenticate users or evaluate device posture. Identity-Aware Proxy performs that context-aware authentication against corporate credentials. Cloud Armor is tempting for its IP filtering, but it operates at the network perimeter, not the identity layer.

A
VPC Service Controls
Why it fails: VPC Service Controls builds a service perimeter around Google Cloud APIs to block data exfiltration, but it neither authenticates users nor evaluates device posture or IP context. It is tempting because it underpins zero-trust data boundaries, and would be correct when the requirement is preventing data movement across project perimeters.
B
Cloud VPN
Why it fails: Cloud VPN provides an encrypted IPsec tunnel between on-premises networks and a VPC, so it cannot authenticate individual users against corporate credentials or assess device posture. It is tempting because it secures connectivity, and would be correct when the requirement is extending a private network to Google Cloud.
C
Cloud Identity
Cloud Identity provides the corporate credential directory and user authentication, which IAP then consumes to verify identity. It supplies the identity plane needed for zero-trust access to the Compute Engine applications, satisfying the corporate credentials requirement.
D
Cloud Armor
Why it fails: Cloud Armor provides edge security: WAF rules, DDoS protection and IP-based allow/deny policies. It does not authenticate users or evaluate device posture. Identity-Aware Proxy performs that context-aware authentication against corporate credentials. Cloud Armor is tempting for its IP filtering, but it operates at the network perimeter, not the identity layer.
E
Identity-Aware Proxy (IAP)
Identity-Aware Proxy enforces context-aware access to Compute Engine applications, evaluating device posture and IP address before granting access. It provides the zero-trust enforcement point that authenticates users via corporate credentials and applies the required contextual conditions.

Question 15easymultiple choice

A company wants to store backup data that is accessed rarely but must be available for retrieval within minutes. Which Cloud Storage class is appropriate?

Trap 1: Standard

Standard offers the lowest latency but carries the highest storage cost, defeating the purpose of rarely accessed backup data. It is tempting because Standard guarantees immediate retrieval, and it would be the correct choice if the data were accessed frequently or required the lowest possible latency rather than minutes.

Trap 2: Coldline

Coldline enforces a 90-day minimum storage duration and is designed for infrequent access, but its retrieval pricing and latency profile target archival rather than minute-level availability. It tempts because it is cheaper than Standard for rarely accessed data, which suits long-term retention without rapid retrieval needs.

Trap 3: Archive

Archive has retrieval latency of hours, so it cannot meet a minutes-based availability requirement. It is tempting because Archive is the cheapest class for rarely accessed backup data, and it would be the correct choice if the stem allowed retrieval times measured in hours rather than minutes.

A
Standard
Why it fails: Standard offers the lowest latency but carries the highest storage cost, defeating the purpose of rarely accessed backup data. It is tempting because Standard guarantees immediate retrieval, and it would be the correct choice if the data were accessed frequently or required the lowest possible latency rather than minutes.
B
Nearline
Nearline suits data accessed less than once a month but requiring retrieval within seconds, offering lower storage cost than Standard while meeting the minutes-level availability constraint; Coldline and Archive impose longer minimum durations and higher retrieval latency.
C
Coldline
Why it fails: Coldline enforces a 90-day minimum storage duration and is designed for infrequent access, but its retrieval pricing and latency profile target archival rather than minute-level availability. It tempts because it is cheaper than Standard for rarely accessed data, which suits long-term retention without rapid retrieval needs.
D
Archive
Why it fails: Archive has retrieval latency of hours, so it cannot meet a minutes-based availability requirement. It is tempting because Archive is the cheapest class for rarely accessed backup data, and it would be the correct choice if the stem allowed retrieval times measured in hours rather than minutes.

Question 16mediummultiple choice

A developer wants to deploy a Cloud Function that is triggered whenever a new object is created in a Cloud Storage bucket. Which trigger type should they choose?

Trap 1: Firestore trigger

Firestore triggers respond to document create, update, and delete events in Firestore, not to object creation in a Cloud Storage bucket, so the function would never fire for uploads. Firestore triggers are correct when the application must react to changes in a Firestore document instead.

Trap 2: Pub/Sub trigger

A Pub/Sub trigger fires on messages published to a topic; Cloud Storage does not publish object-creation notifications to Pub/Sub unless you configure that notification separately, so it does not directly bind to bucket events. Pub/Sub triggers are correct when reacting to messages your own publishers emit.

Trap 3: HTTP trigger

An HTTP trigger invokes the function only when an HTTP request reaches its endpoint; object creation in a bucket emits no such request, so nothing invokes it. HTTP triggers are correct when the function must be called on demand by a client, webhook, or external service.

A
Firestore trigger
Why it fails: Firestore triggers respond to document create, update, and delete events in Firestore, not to object creation in a Cloud Storage bucket, so the function would never fire for uploads. Firestore triggers are correct when the application must react to changes in a Firestore document instead.
B
Cloud Storage trigger
A Cloud Storage trigger fires on object events such as finalise or create, which is precisely the event the stem requires. It is delivered through Eventarc, so the function runs whenever a new object lands in the bucket, satisfying the "new object created" constraint without polling.
C
Pub/Sub trigger
Why it fails: A Pub/Sub trigger fires on messages published to a topic; Cloud Storage does not publish object-creation notifications to Pub/Sub unless you configure that notification separately, so it does not directly bind to bucket events. Pub/Sub triggers are correct when reacting to messages your own publishers emit.
D
HTTP trigger
Why it fails: An HTTP trigger invokes the function only when an HTTP request reaches its endpoint; object creation in a bucket emits no such request, so nothing invokes it. HTTP triggers are correct when the function must be called on demand by a client, webhook, or external service.

Question 17mediummulti select

A security team needs to detect and redact personally identifiable information (PII) in documents stored in Cloud Storage before sharing them with external partners. Which two Google Cloud services should they use together? (Choose two.)

Trap 1: Cloud KMS

Cloud KMS manages encryption keys and performs cryptographic operations; it neither detects PII patterns nor redacts matched text. It is tempting because KMS is the correct choice when the requirement is encrypting data at rest or managing customer-managed keys, rather than inspecting document content.

Trap 2: Cloud Dataflow

Dataflow is a stream and batch processing runner, not a PII detection or redaction engine; it cannot identify sensitive data types itself. It is tempting because Dataflow pipelines commonly orchestrate Cloud Storage input and output, so it would be the right choice for transforming or moving the documents after detection.

Trap 3: Cloud NAT

Cloud NAT provides outbound internet connectivity for private instances; it never inspects or modifies document content. It is tempting because NAT appears in secure network architectures, and would be the right choice when private subnets need egress without external IP addresses.

A
Cloud Data Loss Prevention (DLP) API
The Cloud DLP API inspects content, identifies PII using infoType detectors, and performs de-identification such as redaction or masking. It satisfies the detection and redaction requirement directly, providing the inspection engine that processes documents before external sharing.
B
Cloud Storage
Cloud Storage holds the source documents and acts as the integration point: DLP jobs scan buckets or objects in place, and redacted output is written back to a bucket. It satisfies the stem's constraint that PII resides in Cloud Storage before partner sharing.
C
Cloud KMS
Why it fails: Cloud KMS manages encryption keys and performs cryptographic operations; it neither detects PII patterns nor redacts matched text. It is tempting because KMS is the correct choice when the requirement is encrypting data at rest or managing customer-managed keys, rather than inspecting document content.
D
Cloud Dataflow
Why it fails: Dataflow is a stream and batch processing runner, not a PII detection or redaction engine; it cannot identify sensitive data types itself. It is tempting because Dataflow pipelines commonly orchestrate Cloud Storage input and output, so it would be the right choice for transforming or moving the documents after detection.
E
Cloud NAT
Why it fails: Cloud NAT provides outbound internet connectivity for private instances; it never inspects or modifies document content. It is tempting because NAT appears in secure network architectures, and would be the right choice when private subnets need egress without external IP addresses.

Question 18hardmulti select

Which THREE factors should be considered when choosing a Google Cloud region for deploying a low-latency application serving global users? (Choose three.)

Trap 1: Pricing differences between regions due to variations in compute…

Regional pricing variation affects cost, not the round-trip latency users experience, so it does not address the stated low-latency requirement. It would be the correct factor when the primary constraint is minimising spend on compute and storage.

Trap 2: Number of zones in the region to ensure high availability.

Zone count within a region governs fault tolerance and availability, not the network distance between users and serving infrastructure. It would be the correct factor when the requirement is resilience against zone-level failures rather than latency.

A
Proximity to your user base to minimize network latency.
Placing the region close to users shortens the physical network path, directly reducing round-trip latency for a global low-latency application. Distance is the dominant factor because light-speed propagation through fibre cannot be optimised away by configuration.
B
Availability of the specific Google Cloud services required by the application.
Service availability varies by region, so a region lacking the required compute, database, or AI products forces redesign or cross-region calls that add latency. Selecting a region where every dependency is offered locally satisfies the stem's low-latency constraint, since in-region service access avoids inter-region network hops.
C
Pricing differences between regions due to variations in compute and storage costs.
Why it fails: Regional pricing variation affects cost, not the round-trip latency users experience, so it does not address the stated low-latency requirement. It would be the correct factor when the primary constraint is minimising spend on compute and storage.
D
Compliance with data residency requirements (e.g., GDPR, CCPA).
Data residency obligations dictate which jurisdictions may store or process user data, so GDPR or CCPA constraints can eliminate otherwise suitable regions regardless of latency. Satisfying the stem's global-user scenario requires filtering candidate regions by legal admissibility first, then optimising placement among the compliant subset.
E
Number of zones in the region to ensure high availability.
Why it fails: Zone count within a region governs fault tolerance and availability, not the network distance between users and serving infrastructure. It would be the correct factor when the requirement is resilience against zone-level failures rather than latency.

Question 19hardmultiple choice

A company uses Cloud Armor to protect their HTTP Load Balancer from DDoS attacks. Recently, they experienced a targeted attack that bypassed Cloud Armor's predefined rules. The attack involved a high rate of legitimate-looking requests from a small set of IPs that made the application unresponsive. The team needs to block the attack quickly without affecting legitimate users. What should they do?

Trap 1: Increase the load balancer's capacity to absorb the attack.

Adding capacity absorbs traffic but does not block the attack, so costs rise while the application stays unresponsive; the malicious requests still reach the backend. It is tempting because scaling handles legitimate traffic spikes, but here the requirement is to stop the offending sources, not to serve them.

Trap 2: Configure rate limiting with a threshold based on the normal…

Rate limiting caps requests per client over time but permits the attacking IPs to keep sending below the threshold, leaving the application unresponsive. It is tempting because it handles volumetric floods, yet the stem requires immediate blocking of specific sources, which a deny list achieves.

Trap 3: Add the attacking IPs to a Cloud Armor deny list.

A deny list blocks the identified IPs immediately, but the stem says the attack came from a small set of IPs; if those rotate or are spoofed, the block fails and legitimate users behind shared addresses suffer. It is tempting as a fast manual fix, yet it is not the durable control the scenario needs.

A
Increase the load balancer's capacity to absorb the attack.
Why it fails: Adding capacity absorbs traffic but does not block the attack, so costs rise while the application stays unresponsive; the malicious requests still reach the backend. It is tempting because scaling handles legitimate traffic spikes, but here the requirement is to stop the offending sources, not to serve them.
B
Configure rate limiting with a threshold based on the normal traffic pattern.
Why it fails: Rate limiting caps requests per client over time but permits the attacking IPs to keep sending below the threshold, leaving the application unresponsive. It is tempting because it handles volumetric floods, yet the stem requires immediate blocking of specific sources, which a deny list achieves.
C
Enable Google Cloud Armor Adaptive Protection.
Adaptive Protection applies machine-learning baselining to detect Layer 7 volumetric anomalies, such as the legitimate-looking request flood from few IPs, and generates a tailored WAF rule to block it. Predefined rules cannot profile this behaviour, so this satisfies the requirement to block quickly without affecting legitimate users.
D
Add the attacking IPs to a Cloud Armor deny list.
Why it fails: A deny list blocks the identified IPs immediately, but the stem says the attack came from a small set of IPs; if those rotate or are spoofed, the block fails and legitimate users behind shared addresses suffer. It is tempting as a fast manual fix, yet it is not the durable control the scenario needs.