All practice questions

1598 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

An enterprise organization requires centralized control over network firewall rules across all Google Cloud projects. The security team must enforce a global policy that denies all incoming SSH traffic on TCP port 22 to virtual machines across all projects. Project-level network administrators must still be able to manage application-specific firewall rules for their own workloads without the ability to override or bypass the organization's SSH restriction. Which architectural solution should the cloud architect recommend?

Create a hierarchical firewall policy at the organization level with a rule that denies ingress traffic on TCP port 22, and attach it to the organization node.

Configure a VPC Service Controls perimeter encompassing all projects, and define an ingress rule blocking TCP port 22 network connections.

Connect all spoke VPC networks to a central hub VPC using VPC Network Peering, and define the port 22 deny rule strictly within the hub VPC.

Assign project network administrators the primitive Owner role (roles/owner) on their respective projects while relying on project-level default VPC firewall rules.

Show answer & explanation

Answer: Create a hierarchical firewall policy at the organization level with a rule that denies ingress traffic on TCP port 22, and attach it to the organization node.

Answer

The correct architecture is to create a hierarchical firewall policy at the organization level with a rule that denies ingress traffic on TCP port 22, attached to the organization node.

Hierarchical firewall policies allow organization administrators to define rules that are evaluated before any project-level firewall rules. By creating a deny rule for TCP port 22 at the organization level, the policy is enforced across all current and future projects under that node, ensuring project-level administrators cannot override the restriction.

Step-by-Step Solution

Analyze firewall rule evaluation hierarchy in Google Cloud VPC.

Hierarchical firewall policies enforced at the organization or folder level take precedence over all project-level firewall rules.

Security teams can enforce baseline rules centrally that lower-level admins cannot override.

Configure the organization-level firewall policy.

Create a rule blocking ingress TCP port 22 traffic and attach the policy to the organization resource node.

This guarantees that all virtual machines across all child projects systematically deny incoming SSH traffic.

Key Concept

Hierarchical Firewall Policies

Question 1222Question →

A multinational retail enterprise is designing hybrid connectivity between its on-premises data centers in two distinct metropolitan areas and a primary Google Cloud Virtual Private Cloud (VPC). The architecture requires a sustained peak throughput of 15 Gbps and an enterprise availability SLA of 99.99%. Additionally, the network engineering team intends to peer the primary VPC with a vendor's VPC using VPC Network Peering and expects on-premises hosts to route through the primary VPC into the vendor VPC. Which network architecture should a Cloud Architect recommend?

Provision a 99.99% SLA Dedicated Interconnect topology with four VLAN attachments across two metropolitan areas using Cloud Routers, and establish direct connectivity to the vendor network because VPC Network Peering is non-transitive.

Deploy multiple High Availability (HA) Cloud VPN tunnels with Cloud Routers across both regions to meet the 99.99% SLA, and configure custom route exchange to allow on-premises traffic to transit the peered VPC network.

Provision a 99.99% SLA Dedicated Interconnect topology across two metropolitan areas, and rely on standard VPC Network Peering to automatically transit on-premises traffic through the primary VPC to the vendor VPC.

Establish a single 100 Gbps Partner Interconnect circuit backed up by an HA VPN tunnel, and configure Cloud Router to export local network routes dynamically across the peered VPC connection.

Show answer & explanation

Answer: Provision a 99.99% SLA Dedicated Interconnect topology with four VLAN attachments across two metropolitan areas using Cloud Routers, and establish direct connectivity to the vendor network because VPC Network Peering is non-transitive.

Answer

The architect should recommend provisioning a 99.99% SLA Dedicated Interconnect topology with four VLAN attachments across two metropolitan areas using Cloud Routers, and establishing direct hybrid connectivity to the vendor network.

The correct recommendation is to provision a 99.99% SLA Dedicated Interconnect topology using four VLAN attachments across two metros/edge domains with Cloud Routers, while establishing separate direct connectivity to the vendor network. Dedicated Interconnect handles 15 Gbps bandwidth effortlessly with enterprise SLA coverage, and direct connectivity to the vendor is necessary because VPC Network Peering is non-transitive and cannot forward on-premises traffic across peered VPCs.

Step-by-Step Solution

Evaluate bandwidth and SLA constraints for hybrid connectivity.

A 15 Gbps sustained throughput requirement exceeds practical HA VPN tunnel scaling and requires Dedicated Interconnect (available in 10 Gbps or 100 Gbps circuits). For a 99.99% availability SLA, Google Cloud mandates four VLAN attachments across two edge availability domains in two distinct metropolitan locations.

Dedicated Interconnect provides enterprise-grade low-latency high-bandwidth connectivity and official 99.99% SLA topologies.

Analyze cross-network routing through VPC Network Peering.

VPC Network Peering is strictly non-transitive. On-premises networks connected to the primary VPC via Interconnect cannot reach resources in a peered partner VPC through the primary VPC.

To connect on-premises to the vendor VPC, a separate hybrid connection, Network Connectivity Center, or VPN/Interconnect directly to the vendor environment must be established.

Key Concept

Dedicated Interconnect 99.99% Availability Architecture & VPC Peering Non-Transitivity

Estimated Time:2m 0s

Question 1223Question →

A global medical device company is architecting a patient telemetry platform on Google Cloud. The solution must enforce a strict Recovery Point Objective (RPO) of zero, maintain a 99.999% availability service level agreement (SLA), and guarantee strong global consistency for transactional data across multiple geographic regions. Furthermore, the frontend HTTP ingestion service consists of lightweight, stateless REST API endpoints that must dynamically scale to zero during idle periods without incurring baseline infrastructure management overhead. Which architecture satisfies these high-availability and technical requirements?

Deploy the stateless HTTP ingestion services on Cloud Run across multiple regions behind a Global External HTTP(S) Load Balancer, and store transactional data in a multi-region Cloud Spanner instance configuration.

Deploy the stateless HTTP ingestion services on a multi-region Google Kubernetes Engine (GKE) Standard cluster, and store transactional data in Cloud SQL for PostgreSQL configured with cross-region asynchronous read replicas.

Deploy the stateless HTTP ingestion services on Cloud Run behind a Global External HTTP(S) Load Balancer, and persist transactional records to a highly available regional Cloud SQL for MySQL instance with cross-region database backups.

Deploy the stateless HTTP ingestion services across regional Compute Engine Managed Instance Groups (MIGs), using a pilot-light disaster recovery strategy that restores database state from multi-region Cloud Storage buckets.

Show answer & explanation

Answer: Deploy the stateless HTTP ingestion services on Cloud Run across multiple regions behind a Global External HTTP(S) Load Balancer, and store transactional data in a multi-region Cloud Spanner instance configuration.

Answer

Deploying stateless ingestion microservices on Cloud Run integrated with a multi-region Cloud Spanner instance behind a Global External HTTP(S) Load Balancer.

The combination of Cloud Run and multi-region Cloud Spanner behind a Global External HTTP(S) Load Balancer meets all constraints: Cloud Run scales stateless HTTP microservices down to zero without cluster management overhead, while multi-region Cloud Spanner provides a 99.999% SLA with synchronous multi-region replication ensuring strong consistency and zero RPO.

Step-by-Step Solution

Evaluate compute tier requirements

Cloud Run is selected over GKE or Compute Engine MIGs because it natively supports stateless container execution, zero-scaling, and eliminates node management overhead.

The requirement specifies stateless HTTP microservices that dynamically scale to zero with minimal operational management overhead.

Evaluate data persistence tier requirements for availability and consistency

Multi-region Cloud Spanner is selected over Cloud SQL regional or cross-region replica setups.

Cloud Spanner utilizes Paxos consensus and TrueTime across multiple regions to guarantee strong external consistency, zero RPO, and a 99.999% uptime SLA.

Validate global routing and high availability architecture

Global External HTTP(S) Load Balancer routes traffic to the nearest healthy Cloud Run region.

This guarantees seamless multi-region failover and high availability for the HTTP ingestion layer.

Key Concept

Designing Multi-Region High Availability and Zero-RPO Architectures on GCP

Question 1224Question →

A real-time payment reconciliation API deployed on Google Kubernetes Engine (GKE) has a Service Level Objective (SLO) of $99.9\%$ successful requests measured over a $30$ -day rolling window. During a given $30$ -day period, the API receives a total of $80,000,000$ valid requests. What is the maximum number of failed requests allowed during this period before the service exhausts its error budget?

Show answer & explanation

Answer: 80000

Answer

The maximum number of allowed failed requests before exhausting the error budget is 80,000 requests.

The error budget represents the fraction of bad requests tolerated while maintaining the defined SLO. For a

99.9\%

target across

80,000,000

total requests, the allowable error rate is

0.1\%

(

0.001

). Multiplying

80,000,000

requests by

0.001

yields exactly

80,000

allowed failed requests.

Step-by-Step Solution

Calculate the allowable failure rate

Failure rate =

1 - 0.999 = 0.001

(

0.1\%

)

The error budget is the inverse of the target Service Level Objective (SLO).

Calculate the absolute error budget in number of requests

Error Budget =

80,000,000 \times 0.001 = 80,000

requests

Applying the failure rate fraction to the total request volume yields the total count of failed requests tolerated within the SLO window.

Key Concept

Calculating Request-Based Error Budgets for SLO Management

Question 1225Question →

An engineering team is building an industrial IoT telemetry processing microservice that queries Cloud Bigtable. To validate data access patterns, they need an automated integration testing harness that executes on local developer workstations and CI runners without accessing live Google Cloud resources or needing GCP credentials. Which strategy correctly configures the microservice's client SDKs to interact with a locally started Bigtable emulator?

Start the Bigtable emulator using the gcloud CLI and set the BIGTABLE_EMULATOR_HOST environment variable to the emulator's network address in the execution environment.

Provision a dedicated single-node Google Kubernetes Engine (GKE) cluster in a development project to host Bigtable testing pods for local integration runs.

Assign the primitive Owner IAM role (roles/owner) to a local service account key file and pass its file path to the emulator startup command.

Grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to test runners so they can generate temporary service account keys to connect to live Bigtable instances during test execution.

Show answer & explanation

Answer: Start the Bigtable emulator using the gcloud CLI and set the BIGTABLE_EMULATOR_HOST environment variable to the emulator's network address in the execution environment.

Answer

Start the Bigtable emulator using the gcloud CLI and set the BIGTABLE_EMULATOR_HOST environment variable to the emulator's network address in the execution environment.

Starting the emulator via the gcloud CLI and exporting the BIGTABLE_EMULATOR_HOST environment variable causes official Google Cloud SDKs to intercept requests and send them to the local emulator, eliminating the need for cloud network access or GCP IAM credentials.

Step-by-Step Solution

Identify the requirement for offline integration testing without GCP credentials or live resources.

Local gcloud emulators must be utilized to bypass cloud network dependencies and IAM credential validation.

Google Cloud provides local emulators via gcloud CLI for testing services like Cloud Bigtable locally.

Determine how official GCP client libraries discover the local emulator endpoint.

Setting the environment variable BIGTABLE_EMULATOR_HOST instructs the SDK to route traffic to the local emulator process.

GCP SDKs automatically check standard emulator environment variables before attempting remote API calls.

Key Concept

Cloud Bigtable Emulator Configuration

Question 1226Question →

A global healthcare provider is designing a telemetry ingestion platform on Google Cloud for real-time monitoring of medical devices. The solution must achieve an SLA of 99.99% availability, zero Recovery Point Objective (RPO = 0) for incoming event streams, and seamlessly scale to absorb unpredictable traffic spikes without manual intervention. Additionally, strict security governance mandates that internal application services must be protected against data exfiltration to unauthorized external storage locations, even if service account credentials are compromised. Which architecture best satisfies these technical, availability, and security requirements with minimal operational overhead?

Deploy stateless ingestion container services on Cloud Run in multiple GCP regions, fronted by a Global External Application Load Balancer with Serverless Network Endpoint Groups (NEGs), stream events directly into multi-region Cloud Pub/Sub, and enclose the Cloud Run and Pub/Sub resources within a VPC Service Controls perimeter.

Deploy a Google Kubernetes Engine (GKE) Autopilot cluster in a single region with multi-zonal node pools running containerized ingestion microservices, buffer stream data using a highly available Cloud SQL for PostgreSQL database instance, and configure Horizontal Pod Autoscaling (HPA) based on CPU metrics.

Deploy Cloud Run services in a primary region fronted by a Regional External HTTP(S) Load Balancer, stream data into regional Cloud Storage buckets, and rely exclusively on fine-grained IAM service account roles to prevent application instances from transmitting data to external storage locations.

Deploy regional Compute Engine Managed Instance Groups (MIGs) across separate VPC networks connected via VPC Network Peering to a central shared VPC hub, relying on transitive routing across the peered VPCs to deliver telemetry traffic during a regional outage.

Show answer & explanation

Answer: Deploy stateless ingestion container services on Cloud Run in multiple GCP regions, fronted by a Global External Application Load Balancer with Serverless Network Endpoint Groups (NEGs), stream events directly into multi-region Cloud Pub/Sub, and enclose the Cloud Run and Pub/Sub resources within a VPC Service Controls perimeter.

Answer

Deploy stateless ingestion container services on Cloud Run in multiple GCP regions, fronted by a Global External Application Load Balancer with Serverless NEGs, stream events into multi-region Cloud Pub/Sub, and enforce a VPC Service Controls perimeter around Cloud Run and Pub/Sub.

The correct solution leverages multi-region Cloud Run services fronted by a Global External Application Load Balancer with Serverless Network Endpoint Groups (NEGs) to ensure automatic failover and 99.99% availability with zero infrastructure management. Ingesting stream data via Cloud Pub/Sub guarantees zero RPO through multi-zone synchronous replication. Enclosing Cloud Run and Pub/Sub within a VPC Service Controls perimeter prevents unauthorized data exfiltration beyond defined network boundaries, satisfying all security governance mandates.

Step-by-Step Solution

Evaluate compute and load balancing for high availability (99.99% SLA) and operational overhead.

Multi-region Cloud Run behind a Global External Application Load Balancer using Serverless NEGs provides instant serverless auto-scaling and cross-region failover without infrastructure management.

Serverless containers handle unpredictable bursty telemetry workloads effortlessly while maintaining multi-region redundancy.

Evaluate data ingestion store for RPO = 0 streaming capabilities.

Cloud Pub/Sub configured across multiple regions synchronously replicates published messages across zones before acknowledging publish requests.

This guarantees zero RPO and durability against zonal and regional failures.

Evaluate security requirements for exfiltration prevention.

VPC Service Controls establishes a security boundary around GCP APIs and services (Cloud Run and Cloud Pub/Sub).

IAM roles specify WHO can access resources, but VPC Service Controls restricts WHERE data can move, blocking unauthorized transfers even if IAM credentials are compromised.

Key Concept

Designing multi-region serverless architectures with Global Load Balancing, Pub/Sub event streaming, and VPC Service Controls for exfiltration protection.

Question 1227Question →

A company needs to connect its on-premises data center to a Google Cloud Virtual Private Cloud (VPC) to support a steady daily transfer requirement of 1.5 Gbps. The connectivity solution must support high availability with a 99.99% Service Level Agreement (SLA) while minimizing overall infrastructure costs. Which hybrid connectivity architecture should you recommend?

Configure an HA VPN deployment with two active-active IPsec tunnels operating over an Internet connection.

Provision a 10 Gbps Dedicated Interconnect connection between the on-premises router and Google Cloud.

Establish VPC Network Peering directly between the on-premises network and the Google Cloud VPC.

Deploy a Google Kubernetes Engine (GKE) cluster hosting self-managed IPsec gateway pods across two zones.

Show answer & explanation

Answer: Configure an HA VPN deployment with two active-active IPsec tunnels operating over an Internet connection.

Answer

The optimal solution is to configure an HA VPN deployment with two active-active IPsec tunnels, meeting the 1.5 Gbps requirement and 99.99% SLA at minimal cost.

Google Cloud HA VPN provides up to 3 Gbps bandwidth per tunnel and guarantees a 99.99% availability SLA when properly configured with redundant tunnels across topological pairs. Because the throughput requirement is 1.5 Gbps, HA VPN satisfies all availability and technical constraints while avoiding the high costs of Dedicated Interconnect.

Step-by-Step Solution

Evaluate bandwidth requirements

1.5 Gbps throughput is required, which falls within the capacity of Google Cloud HA VPN (up to 3 Gbps per tunnel).

Choosing Dedicated Interconnect for under 3 Gbps leads to excessive operational costs.

Evaluate availability requirements

HA VPN provides a 99.99% availability SLA when properly configured with two tunnels across distinct VPN gateways or interfaces.

Meets the high availability requirement specified in the scenario.

Key Concept

High Availability Hybrid Networking with HA VPN

Question 1228Question →

A media streaming provider is preparing for a live sports event expected to cause a 10x traffic surge on its I/O-bound metadata API service, which is deployed on Compute Engine Managed Instance Groups (MIGs). During previous high-traffic events, the service experienced request timeouts because CPU-based autoscaling reacted too slowly to memory and network connection bottlenecks, and automated scaling requests were blocked by regional compute resource limits. Which TWO actions should you take to optimize capacity planning and ensure seamless workload scaling during the upcoming event?

Select all that apply

Configure the Managed Instance Group (MIG) autoscaling policy to scale based on Cloud Monitoring custom metrics such as active HTTP connections or queue depth, and proactively request regional Compute Engine quota increases ahead of the event.

Implement scheduled scaling policies on the Managed Instance Groups to pre-provision baseline instance capacity prior to the expected event start time.

Migrate the stateless API microservice to a multi-region Google Kubernetes Engine (GKE) enterprise cluster to automatically bypass regional compute quota constraints.

Maintain MIG autoscaling based strictly on average CPU utilization while relying on automated system quota scaling during peak traffic hours.

Show answer & explanation

Answer: Configure the Managed Instance Group (MIG) autoscaling policy to scale based on Cloud Monitoring custom metrics such as active HTTP connections or queue depth, and proactively request regional Compute Engine quota increases ahead of the event.; Implement scheduled scaling policies on the Managed Instance Groups to pre-provision baseline instance capacity prior to the expected event start time.

Answer

To optimize capacity planning and scaling, you should configure MIG autoscaling based on custom I/O metrics while submitting proactive regional quota increase requests, and set up scheduled scaling policies to pre-provision capacity before the event starts.

The combination of using relevant custom metrics (active HTTP connections/queue depth) for I/O-bound workloads, proactively requesting regional compute quota increases, and using scheduled scaling policies to pre-warm instance groups effectively addresses both latency response delays and quota capacity exhaustion during planned peak events.

Step-by-Step Solution

Identify the scaling metric bottleneck for I/O-bound workloads.

Recognize that CPU utilization is an inadequate metric for I/O-bound services and replace it with custom metrics (e.g., active connection count or HTTP request queue depth).

I/O-bound workloads saturate network threads or database connection pools well before CPU limits are reached.

Evaluate regional project quota requirements.

Submit quota increase requests for Compute Engine resources in the target regions prior to the planned traffic event.

Autoscaling cannot exceed project regional quotas; quota increases require administrative approval time.

Address known temporal traffic spikes.

Configure scheduled autoscaling rules on the MIG to scale up instances ahead of the event start time.

Pre-provisioning baseline capacity eliminates warm-up latency and prevents request drops when traffic begins abruptly.

Key Concept

Capacity Planning and Workload Autoscaling Optimization

Question 1229Question →

An enterprise financial transaction platform running on Google Cloud maintains a warm standby disaster recovery setup in region `us-east4` to handle regional failures of its primary environment in `us-central1`. Following a catastrophic loss of `us-central1`, the cloud architecture team must initiate the regional failover runbook. Arrange the following execution steps in the correct chronological sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for regional failover execution is: 1) Promote the cross-region database read replica to primary status, 2) Scale up the secondary Managed Instance Groups to full production capacity, 3) Reconfigure the Global HTTP(S) Load Balancer backend services to target the secondary region, and 4) Update Cloud DNS routing policies to finalize domain redirection.

Executing a disaster recovery failover requires establishing data write availability first (promoting the database replica), expanding compute capacity second (scaling MIGs), switching internal traffic routing third (updating Load Balancer backends), and finalizing external ingress routing last (updating DNS policies). This order guarantees zero write-block failures and prevents capacity overload.

Step-by-Step Solution

Establish persistence write capability by promoting the secondary database replica.

Database write availability is restored in the target disaster recovery region (`us-east4`).

Promoting the database replica first prevents application connection failures and data corruption when application instances spin up.

Provision required compute workload capacity in the disaster recovery region.

Managed Instance Groups in `us-east4` expand to meet production traffic demands.

Application nodes must be fully scaled and running healthy instances before accepting production traffic workloads.

Shift global load balancing target backends to the newly scaled instance groups.

Load balancer health checks pass and traffic is pointed to secondary regional backends.

Updating backend service definitions directs regional ingress traffic toward active compute resources.

Update Cloud DNS routing policies to broadcast the endpoint shift globally.

External client traffic transitions entirely to the active disaster recovery environment.

DNS update is the external entry point change that completes the end-to-end failover sequence.

Key Concept

Disaster Recovery Regional Failover Execution Sequence

Estimated Time:2m 0s

Question 1230Question →

An organization plans to migrate a single-region, on-premises relational PostgreSQL database to Google Cloud. The application requires standard ACID transactional compliance and predictable performance within a single GCP region, with no requirement for global scale or multi-region availability. Which Google Cloud managed database service should the architect choose to minimize operational complexity and cost?

Cloud SQL for PostgreSQL

Cloud Spanner

Cloud Storage configured with Customer-Supplied Encryption Keys (CSEK)

Cloud Bigtable with Identity and Access Management (IAM) policy bindings

Show answer & explanation

Answer: Cloud SQL for PostgreSQL

Answer

Cloud SQL for PostgreSQL is the optimal choice for a single-region relational database workload requiring standard ACID compliance.

Cloud SQL for PostgreSQL is a fully managed relational database service designed for workloads operating within a single region. It provides full PostgreSQL compatibility, standard ACID compliance, and easy maintenance at a significantly lower cost compared to multi-region scaling solutions.

Step-by-Step Solution

Analyze workload storage requirements

The application requires a relational database (PostgreSQL) with ACID compliance operating strictly within a single GCP region.

Determining relational model requirements and regional scope eliminates non-relational and multi-region database services.

Compare candidate GCP database services

Cloud SQL supports managed single-region PostgreSQL, whereas Cloud Spanner is optimized for multi-region global scale.

Choosing Cloud SQL aligns database capabilities with workload scale while preventing over-provisioning and excess costs.

Finalize database selection

Select Cloud SQL for PostgreSQL.

Cloud SQL satisfies all technical requirements with minimal management effort and optimal cost efficiency.

Key Concept

Selecting Cloud SQL over Cloud Spanner for single-region relational workloads

Estimated Time:45s

Question 1231Question →

Match each Google Cloud hybrid connectivity mechanism or network topology pattern to its defining architectural characteristic and deployment requirement.

Click a left item, then click its matching right item

Show answer & explanation

Answer

Dedicated Interconnect matches direct physical fiber colocation; HA VPN matches encrypted IPsec over public internet; Partner Interconnect matches service provider connectivity; VPC Network Peering matches non-transitive internal VPC connections.

Each hybrid networking option aligns with specific availability, encryption, bandwidth, and physical location requirements. Dedicated Interconnect provides direct physical connections for high capacity; Partner Interconnect bridges customer environments via service provider partners; HA VPN routes encrypted IPsec traffic dynamically over public internet using BGP; VPC Network Peering enables direct, non-transitive internal VPC connectivity.

Step-by-Step Solution

Analyze high-bandwidth and physical colocation requirements.

Dedicated Interconnect pairs with physical fiber links at Google edge facilities.

Dedicated Interconnect is specifically designed for enterprise workloads needing direct physical circuits at 10 Gbps or 100 Gbps capacities.

Analyze internet-based encrypted hybrid routing needs.

HA VPN with Cloud Router pairs with IPsec tunnels utilizing BGP dynamic routing.

HA VPN secures traffic over the public internet using IPsec, whereas Interconnect connections are unencrypted by default.

Evaluate hybrid connectivity for sites lacking direct Google facility presence.

Partner Interconnect pairs with third-party service provider connections.

Partner Interconnect allows organizations to connect through enterprise ISPs/telecom partners to reach Google Cloud.

Evaluate VPC-to-VPC internal routing topology rules.

VPC Network Peering pairs with internal non-transitive VPC interconnectivity.

VPC Network Peering connects distinct VPCs directly on the internal GCP backbone without enabling transitive hops.

Key Concept

Designing hybrid network connectivity using Dedicated Interconnect, Partner Interconnect, HA VPN, and VPC Peering

Question 1232Question →

An enterprise operations team is preparing to update a stateless web application running on a Compute Engine Managed Instance Group (MIG) positioned behind an Internal Application Load Balancer. During previous release cycles, updating the instance template caused service disruption because existing instances were terminated before new instances became fully operational. The team needs to configure a rolling update strategy that guarantees maximum available capacity is preserved throughout the release without incurring service downtime. Which configuration strategy should the cloud architect recommend?

Configure the MIG rolling update policy with maxSurge set to a value greater than zero and maxUnavailable set to zero, while ensuring load balancer health checks verify instance readiness.

Configure the load balancer health check endpoint to query the deep backend database connection pool directly to determine when new MIG instances are ready for traffic.

Maintain the MIG update parameters and deployment automation state within unversioned local state storage on the deployment worker node to speed up execution.

Grant the deployment service account the primitive Owner IAM role on the project to override instance creation delays and force immediate MIG instance termination.

Show answer & explanation

Answer: Configure the MIG rolling update policy with maxSurge set to a value greater than zero and maxUnavailable set to zero, while ensuring load balancer health checks verify instance readiness.

Answer

Configure the MIG rolling update policy with maxSurge set to a value greater than zero and maxUnavailable set to zero, while ensuring load balancer health checks verify instance readiness.

Configuring a Compute Engine Managed Instance Group rolling update with maxSurge set above zero and maxUnavailable set to zero ensures that new instances with the updated template are brought online and verified healthy before any existing instances are removed. This guarantees that total active serving capacity never drops below the required baseline during deployment.

Step-by-Step Solution

Analyze capacity requirements during rolling updates for Compute Engine MIGs.

Identified that capacity must not drop below 100% of the target size during the release window.

Setting maxUnavailable to 0 prevents the MIG manager from deleting active instances before replacement instances are healthy.

Determine the surge capacity mechanism for replacement instances.

Setting maxSurge > 0 permits the MIG to temporarily create extra instances above the target size.

Surging creates replacement instances first, allowing them to pass health checks before older instances are drained and deleted.

Evaluate health check configuration best practices for load balancing and deployment verification.

Health checks should test application endpoint readiness locally rather than deep backend database dependencies.

Deep dependency checks risk cascading instance unhealthy status across the entire pool during database load spikes.

Key Concept

MIG Rolling Update Capacity Preservation (maxSurge vs maxUnavailable)

Question 1233Question →

A media publishing enterprise is migrating its legacy digital asset archiving platform from an on-premises data center to Google Cloud. The existing architecture consists of a stateless Java HTTP API service that processes metadata requests and an 8 TB on-premises MySQL relational database. The workload must remain operational throughout a 30-day migration window.

The enterprise wants to eliminate infrastructure management overhead, adopt managed cloud services, and ensure zero-downtime database schema updates during migration. Which TWO architecture and migration strategies should you recommend?

Select all that apply

Containerize the stateless Java API service and deploy it to Cloud Run to handle incoming metadata requests.

Use Database Migration Service (DMS) for continuous replication from on-premises MySQL to Cloud SQL, and apply an expand-contract pattern for schema updates.

Deploy the stateless Java API service onto a dedicated Google Kubernetes Engine (GKE) cluster with custom node pools.

Migrate the 8 TB relational database directly to Cloud Spanner to ensure multi-region global horizontal scaling.

Show answer & explanation

Answer: Containerize the stateless Java API service and deploy it to Cloud Run to handle incoming metadata requests.; Use Database Migration Service (DMS) for continuous replication from on-premises MySQL to Cloud SQL, and apply an expand-contract pattern for schema updates.

Answer

The optimal solution is to containerize the stateless API for deployment on Cloud Run and use Database Migration Service (DMS) with Cloud SQL alongside an expand-contract database schema pattern.

Deploying the containerized stateless service to Cloud Run eliminates server and cluster maintenance debt while providing automatic scaling. Pairwise, using Database Migration Service (DMS) with Cloud SQL enables continuous data synchronization from the on-premises MySQL instance, while the expand-contract pattern ensures backward-compatible schema changes without application downtime.

Step-by-Step Solution

Evaluate compute modernization choices for the stateless web API.

Cloud Run is selected over GKE because it automatically scales stateless HTTP containers without requiring cluster management.

Reduces operational technology debt and eliminates fixed compute management overhead.

Select database migration and schema refactoring strategy for the 8 TB relational database.

Database Migration Service (DMS) is chosen for continuous replication to Cloud SQL, paired with an expand-contract pattern for zero-downtime schema changes.

Cloud SQL easily handles 8 TB MySQL workloads without the refactoring complexity of Spanner, while DMS ensures minimal cutover downtime.

Key Concept

Legacy cloud migration strategies balancing compute serverless replatforming and database continuous replication.

Estimated Time:2m 0s

Question 1234Question →

A renewable energy analytics company uses Terraform to manage its Google Cloud infrastructure across multiple projects. During a recent operational incident, an engineer manually modified server instance types and firewall rules directly in the Google Cloud Console. The automated CI/CD pipeline subsequently failed during execution due to state drift between live resources and version-controlled Terraform code. The cloud architecture team must resolve the configuration drift while ensuring long-term IaC governance and compliance. Which strategy should the cloud architect recommend?

Update the Terraform configuration files to reflect any intended console modifications, run terraform plan to inspect differences, execute terraform apply to reconcile live state with code, and restrict direct Console edit permissions.

Allow manual Cloud Console modifications for emergency incidents and run terraform refresh in the CI/CD pipeline to automatically overwrite repository configuration files with live state.

Delete the remote state file stored in the Cloud Storage backend and execute terraform init to regenerate state directly from active Google Cloud resources.

Grant the Owner primitive IAM role to the deployment service account to bypass backend state locking errors and force infrastructure updates.

Show answer & explanation

Answer: Update the Terraform configuration files to reflect any intended console modifications, run terraform plan to inspect differences, execute terraform apply to reconcile live state with code, and restrict direct Console edit permissions.

Answer

Reconcile configuration drift by updating Terraform HCL code to match valid changes or executing terraform apply to revert unauthorized edits, while restricting direct Cloud Console mutation access through IAM least privilege.

The correct approach enforces Infrastructure as Code best practices by reconciling code and live infrastructure, then enforcing least-privilege IAM controls so all future changes flow through automated pipelines.

Step-by-Step Solution

Inspect out-of-band changes using terraform plan

Identify exact resource properties modified manually in the Cloud Console compared to desired code definitions.

Understanding state divergence is required before deciding whether to incorporate or revert live changes.

Reconcile version-controlled code and execute terraform apply

Bring live Google Cloud infrastructure back into full alignment with repository HCL definitions.

Infrastructure as Code requires version-controlled repository definitions to be the single authoritative source of truth.

Enforce IAM least privilege and CI/CD execution boundaries

Remove direct write access to production resources from individual users, requiring all modifications to pass through audited automated pipelines.

Preventing unauthorized manual edits eliminates recurring infrastructure drift.

Key Concept

Building and Managing Infrastructure as Code (IaC)

Question 1235Question →

A healthcare enterprise runs its electronic health record (EHR) analytics system on Google Cloud. The primary deployment operates in region `us-central1` using Cloud SQL for PostgreSQL and Compute Engine Managed Instance Groups (MIGs). To meet disaster recovery (DR) objectives of Recovery Time Objective (RTO) under 15 minutes and Recovery Point Objective (RPO) under 1 minute while minimizing baseline idle infrastructure costs, you implement a warm standby pattern in region `us-east4`. You configure a cross-region read replica for Cloud SQL and maintain a minimal scaled-down MIG in `us-east4`. During a simulated regional failover drill in `us-east4`, the Cloud SQL read replica is successfully promoted to primary, but scaling out the DR MIG to handle production traffic fails immediately with instance provisioning errors. What is the most likely root cause of this failure during DR execution?

The organization did not proactively request and verify sufficient regional Compute Engine CPU and instance quotas in us-east4 prior to executing the failover.

The architecture failed to replace Cloud SQL with Cloud Spanner, which is required to achieve cross-region replication with an RPO under 1 minute.

The replication traffic exceeded HA VPN tunnel throughput caps between GCP regions, blocking MIG compute instance startup.

The DR MIG instances could not communicate with the database because VPC Network Peering between primary and DR VPCs does not support transitive routing.

Show answer & explanation

Answer: The organization did not proactively request and verify sufficient regional Compute Engine CPU and instance quotas in us-east4 prior to executing the failover.

Answer

The organization did not proactively request and verify sufficient regional Compute Engine CPU and instance quotas in us-east4 prior to executing the failover.

When executing a regional failover using a pilot light or warm standby pattern, scaling up Compute Engine Managed Instance Groups in the recovery region requires available resource quotas (such as regional CPU limits and IP allocations). Because GCP quotas are managed per region, failing to request and verify quota increases in the secondary region in advance causes immediate instance provisioning failures when scaling out during a DR event.

Step-by-Step Solution

Analyze the disaster recovery strategy and architecture components

Warm standby strategy using Cloud SQL cross-region read replica and a scaled-down MIG in the secondary region (us-east4).

Understanding the baseline state helps identify which component failed during scale-out.

Evaluate the symptom observed during DR execution

Database promotion succeeded, but MIG auto-scaling/scale-out failed immediately with instance provisioning errors.

The failure occurred specifically when attempting to rapidly allocate compute capacity in the secondary region.

Identify GCP platform constraints in secondary regions

GCP quotas (e.g., N2 CPUs, In-Use IP addresses) are regional. A secondary region with low default quotas will reject rapid scale-out requests.

Ensuring capacity availability requires proactively requesting quota increases in secondary DR regions well before an actual failover event.

Key Concept

Disaster Recovery Execution and Regional Resource Quota Planning

Estimated Time:1m 30s

Question 1236Question →

An automotive manufacturer is implementing a vehicle telemetry diagnostics endpoint deployed within a single Google Cloud region ( $us-east4$ ). The service accepts incoming HTTP REST webhooks from connected vehicles to log maintenance metrics into a standard relational database. Telemetry traffic is highly variable, experiencing sudden traffic surges during morning rush hours and long periods of near-zero activity overnight. Which architectural design meets the availability and regional relational storage requirements while minimizing overall cost and operational overhead?

Deploy the stateless REST API on Cloud Run and store relational data in Cloud SQL for PostgreSQL.

Deploy the stateless REST API on a regional Google Kubernetes Engine (GKE) cluster and store relational data in Cloud Spanner.

Deploy the stateless REST API on a GKE Standard cluster maintaining a minimum of three worker nodes and store relational data in Cloud SQL for PostgreSQL.

Provision Compute Engine virtual machines using 3-year Committed Use Discounts (CUDs) behind a Load Balancer and store relational data in Cloud SQL for PostgreSQL.

Show answer & explanation

Answer: Deploy the stateless REST API on Cloud Run and store relational data in Cloud SQL for PostgreSQL.

Answer

Deploying the stateless REST API on Cloud Run combined with Cloud SQL for PostgreSQL as the relational storage layer.

Deploying the API on Cloud Run paired with Cloud SQL for PostgreSQL directly aligns compute and storage resources with business cost requirements. Cloud Run automatically scales to zero instances when vehicle traffic drops overnight, eliminating idle compute expenses. Cloud SQL provides a fully managed relational database within a single region (

us-east4

) without the overhead or expense of multi-region database systems.

Step-by-Step Solution

Analyze the compute workload characteristics and business cost requirements.

The API is stateless with variable traffic and long idle periods overnight.

Serverless compute platforms like Cloud Run scale to zero instances, eliminating idle compute costs, whereas GKE clusters or Compute Engine VMs maintain baseline costs.

Evaluate data storage requirements against cost and architecture constraints.

The application requires a standard relational database operating within a single Google Cloud region (

us-east4

Cloud SQL for PostgreSQL satisfies single-region relational database needs at a significantly lower baseline cost than Cloud Spanner, which is optimized for multi-region global consistency.

Combine compute and storage choices to form the optimal cloud solution architecture.

Cloud Run paired with Cloud SQL for PostgreSQL offers minimal operational overhead and optimal cost efficiency.

This combination minimizes total cost of ownership while fully meeting functional business requirements.

Key Concept

Selecting serverless compute and appropriate regional relational storage to optimize cost for bursty workloads with idle periods.

Question 1237Question →

An enterprise media streaming provider is architecting its core backend services on Google Cloud for global live broadcast events. The system must meet the following technical requirements:
- Achieve a $99.99\%$ multi-region availability SLA for stateless subscriber entitlement validation requests.
- Ensure zero Recovery Point Objective (RPO) and synchronous multi-region consistency for transactional subscriber entitlement writes during a regional outage.
- Prevent authorized internal identity principals from exfiltrating database content to external Google Cloud projects.
- Minimize operational management overhead for the stateless API compute tier.

Which TWO architectural components should you combine to fulfill these requirements? (Select TWO)

Select all that apply

Deploy the stateless entitlement validation API on Cloud Run across multiple regions behind a Global External Application Load Balancer.

Provision dedicated Google Kubernetes Engine (GKE) clusters in multiple regions with custom ingress controllers to host the stateless entitlement validation API.

Store subscriber entitlement records in a Multi-Region Cloud Spanner instance and enclose the database service inside a VPC Service Controls security perimeter.

Store subscriber entitlement records in a High Availability (HA) Regional Cloud SQL for PostgreSQL instance with cross-region read replicas.

Rely exclusively on fine-grained IAM roles (`roles/spanner.databaseUser`) to restrict database permissions and prevent data exfiltration.

Show answer & explanation

Answer: Deploy the stateless entitlement validation API on Cloud Run across multiple regions behind a Global External Application Load Balancer.; Store subscriber entitlement records in a Multi-Region Cloud Spanner instance and enclose the database service inside a VPC Service Controls security perimeter.

Answer

The optimal architecture combines deploying the stateless API on Cloud Run across multiple regions behind a Global External Application Load Balancer, and storing transactional database records in a Multi-Region Cloud Spanner instance protected by a VPC Service Controls perimeter.

The combination of Cloud Run behind a Global External Application Load Balancer and Multi-Region Cloud Spanner with VPC Service Controls satisfies all functional constraints. Cloud Run handles stateless API requests across regions with minimal operational effort. Multi-Region Cloud Spanner uses synchronous Paxos replication to deliver zero RPO across regional outages. VPC Service Controls establishes a perimeter boundary that prevents authorized identities from transferring sensitive database content to external, unapproved Google Cloud projects.

Step-by-Step Solution

Analyze the stateless API compute tier requirements.

Cloud Run combined with a Global External Application Load Balancer delivers serverless regional failover, sub-second global latency routing, and

99.99\%

availability without cluster maintenance overhead.

Serverless containers fulfill the low operational overhead mandate while the global load balancer provides automatic multi-region failover.

Analyze the database tier availability and data loss constraints.

Multi-Region Cloud Spanner provides synchronous global replication using Paxos consensus, guaranteeing transactional integrity and zero RPO even during regional outages.

Regional databases such as Cloud SQL use asynchronous cross-region replication, which exposes writes to data loss during regional disaster events.

Evaluate the data exfiltration prevention requirement.

Enclosing the database within a VPC Service Controls perimeter blocks egress data transfers to external, non-authorized Google Cloud resources.

IAM authorization checks user identity but does not enforce network/resource context boundaries required to stop data exfiltration.

Key Concept

Designing multi-region high availability architectures combining serverless compute, globally consistent database storage with zero RPO, and VPC Service Controls security perimeters.

Question 1238Question →

A company is designing a web application hosted in a single Google Cloud region. The solution requires storing structured relational operational data with full ACID transaction support, as well as storing large volume unstructured user-uploaded media files served over HTTP. Which TWO Google Cloud storage solutions should the architect select to meet these requirements cost-effectively? (Select TWO)

Select all that apply

Cloud Spanner for storing the single-region structured relational database workload

Cloud SQL for storing the single-region structured relational database workload

Cloud Storage for storing and serving the unstructured user-uploaded media files

Transfer Appliance for serving live unstructured user-uploaded media files over HTTP

Show answer & explanation

Answer: Cloud SQL for storing the single-region structured relational database workload; Cloud Storage for storing and serving the unstructured user-uploaded media files

Answer

The correct architecture combines Cloud SQL for the single-region relational database workload and Cloud Storage for storing unstructured media files.

Cloud SQL provides a fully managed single-region relational database with full ACID compliance for structured operational data, while Cloud Storage provides highly scalable object storage suited for serving unstructured media files directly via HTTP.

Step-by-Step Solution

Analyze relational database requirements

The requirement calls for a single-region, ACID-compliant relational database. Cloud SQL is the ideal fit as it delivers fully managed relational database features without the cost overhead of globally distributed solutions.

Single-region relational workloads do not require multi-region horizontal scaling.

Analyze unstructured file storage requirements

User-uploaded media files require scalable object storage accessible over HTTP, which is the core capability of Cloud Storage.

Cloud Storage provides durable object storage with direct HTTP access capabilities.

Key Concept

Selecting GCP database and storage services based on data structure, regional scope, and access patterns.

Question 1239Question →

A healthcare provider is extending its primary on-premises data center to Google Cloud to run high-throughput data analytics on patient records. The hybrid connection requires a predictable bandwidth of at least 8 Gbps with low latency. Additionally, a third-party diagnostics partner operating in a separate VPC is connected to the provider's central hub VPC via VPC Network Peering and needs access to the on-premises database servers. Which network architecture should a Cloud Architect design to satisfy these requirements?

Provision a 10 Gbps Dedicated Interconnect connection between the on-premises data center and the central hub VPC, and configure a Dedicated Interconnect or VPN transit setup for the partner VPC because VPC Network Peering does not support transitive routing to on-premises networks.

Provision a 10 Gbps Dedicated Interconnect connection between the on-premises data center and the central hub VPC, and rely on the existing VPC Network Peering connection to route partner VPC traffic directly to the on-premises data center.

Deploy three HA VPN tunnels combined using ECMP with Cloud Router to meet the 8 Gbps bandwidth requirement, and allow partner traffic to traverse the hub VPC to on-premises over the VPC Network Peering link.

Configure Carrier Peering to achieve 8 Gbps throughput across public IP space, and add static custom routes to the central hub VPC to enable transitive routing for the partner VPC.

Show answer & explanation

Answer: Provision a 10 Gbps Dedicated Interconnect connection between the on-premises data center and the central hub VPC, and configure a Dedicated Interconnect or VPN transit setup for the partner VPC because VPC Network Peering does not support transitive routing to on-premises networks.

Answer

Provision a 10 Gbps Dedicated Interconnect connection for the required throughput and establish a dedicated transit connection for the partner VPC because VPC Network Peering is non-transitive.

Dedicated Interconnect is required to support bandwidth demands of 8 Gbps with low latency. Furthermore, because GCP VPC Network Peering does not support transitive routing, resources in a peered VPC cannot route through the hub VPC's Cloud Router/Interconnect to reach an on-premises network unless explicit transit architecture (such as Network Connectivity Center or dedicated gateway connections) is deployed.

Step-by-Step Solution

Evaluate hybrid bandwidth requirement

Requirements specify at least 8 Gbps throughput, which exceeds standard HA VPN tunnel capacities (3 Gbps per tunnel) and mandates Dedicated Interconnect (10 Gbps or 100 Gbps circuits).

Dedicated Interconnect provides direct physical connections extending private IP routing at enterprise bandwidth levels.

Analyze VPC Network Peering routing capabilities for the partner VPC

VPC Network Peering is strictly non-transitive; traffic from the partner VPC cannot traverse the hub VPC to reach the on-premises Interconnect endpoint.

Google Cloud VPC Network Peering does not advertise routes learned from Cloud Router / Interconnect to other peered VPC networks.

Synthesize the complete hybrid network topology

Use Dedicated Interconnect for high-bandwidth core connectivity, and implement explicit transit architecture (such as Network Connectivity Center or separate Interconnect/VPN) for partner connectivity.

This satisfies both the bandwidth requirement and the technical boundary of non-transitive peering.

Key Concept

Hybrid network design requires choosing Dedicated Interconnect for bandwidth > 3 Gbps and accounting for the non-transitive behavior of VPC Network Peering.

Question 1240Question →

An enterprise financial clearinghouse is architecting a core payment processing backend on Google Cloud. The system must achieve a 99.999% availability SLA, support immediate multi-region failover, and maintain a Recovery Point Objective (RPO) of 0 and a Recovery Time Objective (RTO) of less than 5 seconds for strongly consistent relational transaction records during a total regional outage. The application layer consists of stateless HTTP authorization microservices. Which architectural design meets all technical availability, RPO, and RTO requirements while minimizing operational overhead?

Deploy a multi-region Cloud Spanner instance across multiple GCP regions for the database layer, paired with stateless Cloud Run services deployed across those same regions, fronted by a Global External Application Load Balancer.

Deploy a Cloud SQL for PostgreSQL instance with High Availability (HA) enabled across two zones in a primary region, configured with an asynchronous cross-region read replica in a secondary region, fronted by a Global External Application Load Balancer routing to Cloud Run.

Deploy a multi-region Cloud Spanner instance for data storage, and provision multi-zone Google Kubernetes Engine (GKE) clusters in each region with custom ingress controllers and custom failover scripts to run the stateless microservices.

Deploy a multi-region Cloud Spanner instance fronted by a Global External Application Load Balancer routing to Cloud Run, configuring the load balancer HTTP health checks to execute synchronous SQL read/write transactions against Cloud Spanner.

Show answer & explanation

Answer: Deploy a multi-region Cloud Spanner instance across multiple GCP regions for the database layer, paired with stateless Cloud Run services deployed across those same regions, fronted by a Global External Application Load Balancer.

Answer

Deploying a multi-region Cloud Spanner instance paired with multi-region Cloud Run services fronted by a Global External Application Load Balancer satisfies the 99.999% SLA, zero RPO, and sub-5-second RTO requirements with minimal operational management.

Combining a multi-region Cloud Spanner deployment with multi-region Cloud Run container instances behind a Global External Application Load Balancer delivers a globally resilient architecture. Cloud Spanner uses Paxos consensus across regions to guarantee synchronous writes with strong consistency (RPO=0) and automatic transparent leader election during regional loss (RTO < 5 seconds). Global External Application Load Balancing routes client traffic via Anycast to the nearest healthy Cloud Run instance, meeting the 99.999% SLA while minimizing operational infrastructure management.

Step-by-Step Solution

Analyze data tier requirements (RPO=0, RTO<5s, strongly consistent relational data across regions).

Identify that only Cloud Spanner configured in a multi-region topology provides synchronous multi-region replication and automatic failover supporting RPO=0 and instantaneous RTO for relational databases.

Cloud SQL relies on asynchronous replication across regions, which cannot guarantee RPO=0 during a regional disaster.

Analyze compute and networking tier requirements (stateless microservices, multi-region high availability, minimal operational overhead).

Select Cloud Run in multiple regions fronted by a Global External Application Load Balancer.

Global External Application Load Balancing provides Anycast IP routing with automatic sub-second failover to the nearest healthy backend region, while Cloud Run provides fully managed serverless compute.

Evaluate load balancer health check configuration best practices.

Ensure health checks target shallow application endpoint status rather than executing synchronous database read/write queries.

Deep dependency health checking causes cascading outages when downstream database latency occurs.

Key Concept

Designing Multi-Region High Availability Architectures for Zero RPO Relational Workloads

Estimated Time:2m 30s

PreviousPage 62 / 80Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept