Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1481Question →

A video streaming platform hosts its user authentication and session management microservice on Google Cloud Run. The Site Reliability Engineering (SRE) team defines a monthly availability Service Level Objective (SLO) of 99.9%99.9\% based on the ratio of successful HTTP responses (2xx2\text{xx} and 3xx3\text{xx}) to total requests. To prevent alert fatigue while ensuring fast detection of rapid error budget consumption, which alerting strategy should the SRE team implement?

Show answer & explanation

Answer: Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to trigger when short-term (e.g., 5-minute and 1-hour) and long-term (e.g., 6-hour and 3-day) budget consumption rates exceed defined thresholds.

Answer

Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to trigger when short-term (e.g., 5-minute and 1-hour) and long-term (e.g., 6-hour and 3-day) budget consumption rates exceed defined thresholds.
Configuring multi-window, multi-burn-rate alerts in Cloud Monitoring is the Google SRE standard for monitoring SLO error budget consumption. It evaluates both short-term lookback windows (to quickly detect catastrophic outages) and long-term lookback windows (to detect subtle, persistent bugs draining the budget over days), while drastically reducing alert noise.

Step-by-Step Solution

1
Analyze the operational goal
The team needs an alerting strategy that detects both fast and slow exhaustion of the error budget without causing alert fatigue.
Alert fatigue occurs when alerts trigger on transient spikes or non-actionable events, whereas missing slow burn rates leads to unexpected SLO breaches.
2
Evaluate SRE best practices for Cloud Monitoring SLO alerting
Google SRE practices mandate multi-window, multi-burn-rate alerting.
Using multiple lookback windows (e.g., short 5-minute/1-hour windows paired with longer 6-hour/3-day windows) ensures high precision and recall by requiring sustained error budget consumption before notifying engineers.
3
Compare against static and infrastructure-based alerting options
Static single-window threshold alerts and infrastructure metric alerts fail to align directly with error budget burn rate dynamics.
Static metrics ignore error budget remaining capacity, and CPU utilization does not directly measure HTTP request availability.

Key Concept

Multi-window, multi-burn-rate alerting for SLO error budgets
Question 1482Question →

An enterprise fintech organization runs a core payment processing service on Cloud Run backed by a Cloud Spanner database. The engineering team is preparing to deploy a major release that includes a database schema modification requiring a mandatory new column. The architecture must maintain zero downtime during deployment and ensure immediate rollback capability without data corruption or service errors if automated metrics detect anomalies. Which release strategy should the Cloud Architect recommend?

Show answer & explanation

Answer: Apply an expand-and-contract schema migration pattern by making the new database column optional, deploy the updated Cloud Run service revision using traffic splitting for a progressive canary release, backfill data, and contract the schema after full traffic migration.

Answer

Apply an expand-and-contract schema migration pattern by making the new database column optional, deploy the updated Cloud Run service revision using traffic splitting for a progressive canary release, backfill data, and contract the schema after full traffic migration.
The expand-and-contract pattern decouples database updates from application code releases by ensuring all database modifications are backward-compatible. Combined with Cloud Run traffic splitting, this permits safe progressive canary rollouts and instant rollbacks.

Step-by-Step Solution

1
Expand the database schema with non-breaking changes
The new column is added to Cloud Spanner as optional/nullable, preserving compatibility with existing application code.
Ensures old and new application versions can operate concurrently against the same database state.
2
Deploy the new revision using Cloud Run traffic splitting
Traffic is gradually shifted to the new revision while health metrics and SLIs are continuously monitored.
Allows real-world verification with the ability to instantly roll back traffic without breaking active database sessions.
3
Contract the schema after retiring old application revisions
Backfill default values and alter the column to mandatory once 100% traffic is verified on the new revision.
Finalizes the database state cleanly without risking downtime or rollback errors.

Key Concept

Expand-Contract Database Schema Migration with Canary Traffic Shifting
Question 1483Question →

An online retail platform experiences a catastrophic regional failure in its primary region (us-central1). The application architecture consists of an active Managed Instance Group (MIG) and Cloud SQL primary in us-central1, with a scaled-down warm standby MIG and a cross-region Cloud SQL read replica in us-east4. Place the operational disaster recovery failover steps in the correct order to restore full production traffic in us-east4 with minimal data inconsistency.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Promote the cross-region Cloud SQL read replica in us-east4 to a standalone primary database instance, 2) Update application configuration settings in us-east4 to reference the connection endpoint of the newly promoted database instance, 3) Scale up the warm standby Managed Instance Group (MIG) in us-east4 to full production capacity, and 4) Update Cloud DNS routing policies to direct production domain traffic to the us-east4 External HTTP(S) Load Balancer.
Executing disaster recovery requires prioritizing data write availability first, followed by application binding, compute scaling, and finally DNS traffic cutover. Promoting the database replica ensures a writable backend. Rebinding application instances ensures writes hit the new primary database. Scaling up the compute tier ensures sufficient capacity. Switching Cloud DNS last prevents sending live user requests to an unready or under-provisioned environment.

Step-by-Step Solution

1
Promote the cross-region Cloud SQL read replica in us-east4.
The read replica becomes an independent, writable database instance in the failover region.
Promoting the database first ensures that write operations can be accepted immediately when application instances initiate connections.
2
Update application configurations to point to the promoted database endpoint.
The application workload in us-east4 is successfully linked to the new primary database.
Application instances must target the active writable database rather than the former read replica endpoint.
3
Scale up the Managed Instance Group (MIG) in us-east4.
The compute tier reaches full production serving capacity.
Warm standby compute instances must be scaled out to handle production load prior to accepting public internet traffic, avoiding resource exhaustion.
4
Update Cloud DNS routing policy to fail over traffic to us-east4.
Global ingress traffic is redirected to the healthy, provisioned load balancer in us-east4.
DNS failover should always be executed last after backend data integrity and compute capacity are completely ready to process user requests.

Key Concept

Disaster Recovery Failover Sequencing
Question 1484Question →

A DevOps engineering team is configuring an isolated CI/CD build container to run automated integration tests against a local Cloud Pub/Sub service instance. Which TWO configuration actions are required to ensure application client libraries interact exclusively with the local emulator without attempting to connect to live Google Cloud services? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Start the Pub/Sub emulator process inside the test container using the command `gcloud beta emulators pubsub start --host-port=0.0.0.0:8085`.; Export the `PUBSUB_EMULATOR_HOST` environment variable set to the emulator endpoint (e.g., `localhost:8085`).

Answer

The correct actions are starting the Pub/Sub emulator process with `gcloud beta emulators pubsub start --host-port=0.0.0.0:8085` and setting the `PUBSUB_EMULATOR_HOST` environment variable to route client library traffic to the local emulator endpoint.
Executing the command `gcloud beta emulators pubsub start` starts the local server process, while exporting `PUBSUB_EMULATOR_HOST` directs GCP client libraries to communicate with the local host instead of production Google endpoints, completely removing the need for cloud authentication.

Step-by-Step Solution

1
Initialize the emulator service
The local Pub/Sub emulator starts and listens for incoming connections on the specified port.
The gcloud CLI emulator component provides a local mock server implementation of the Cloud Pub/Sub service.
2
Configure environment variables for client libraries
The application SDKs automatically bypass authentication and send requests to the local host.
Google Cloud client libraries inspect specific environment variables (such as `PUBSUB_EMULATOR_HOST`) to override default endpoint routing and credentials requirements.

Key Concept

Cloud Pub/Sub Local Emulator Setup and Client Routing
Question 1485Question →

A startup is launching a simple, stateless HTTP REST API microservice to process incoming customer feedback forms. The traffic is highly unpredictable, with extended periods of zero incoming requests during off-peak hours. The business priority is to minimize total operational costs and eliminate idle infrastructure expenses with minimal management overhead. Which Google Cloud compute platform should the architecture team select?

Show answer & explanation

Answer: Deploy the containerized microservice to Cloud Run.

Answer

Deploying the containerized microservice to Cloud Run is the optimal solution because it automatically scales down to zero instances when idle, incurring zero compute costs during off-peak hours while minimizing cluster management overhead.
Cloud Run is designed for stateless containerized HTTP services. It automatically scales compute instances down to zero when no traffic is present, ensuring zero expenditure during idle hours while eliminating cluster maintenance tasks.

Step-by-Step Solution

1
Analyze workload characteristics and business requirements.
The workload consists of a simple stateless HTTP API with unpredictable traffic and idle off-peak periods. The goal is cost minimization and minimal overhead.
Identifying that the service is stateless and experiences periods of zero traffic directs the choice toward serverless compute platforms.
2
Evaluate candidate compute platforms against cost and operational criteria.
Cloud Run supports containerized HTTP workloads, scales automatically to zero, charges only for consumed CPU/memory during request processing, and requires no infrastructure management.
Traditional VM pools or GKE clusters maintain fixed baseline running costs regardless of incoming request volume.

Key Concept

Serverless Compute Right-Sizing and Scaling to Zero
Question 1486Question →

A financial company establishes an HA VPN connection between their on-premises network and a Hub VPC in Google Cloud. They then connect a Spoke VPC to the Hub VPC using VPC Network Peering. Workloads in the Spoke VPC are unable to communicate with hosts in the on-premises data center. What is the fundamental cause of this connectivity failure?

Show answer & explanation

Answer: VPC Network Peering does not support transitive routing, preventing traffic from passing from the Spoke VPC through the Hub VPC to the on-premises network.

Answer

VPC Network Peering does not support transitive routing, preventing traffic from passing from the Spoke VPC through the Hub VPC to the on-premises network.
VPC Network Peering in Google Cloud is strictly non-transitive. If VPC A is peered with VPC B, and VPC B is connected to an on-premises network via HA VPN or Interconnect, VPC A cannot reach the on-premises network through VPC B unless an explicit transit architecture (such as Network Connectivity Center or appliance proxies) is used.

Step-by-Step Solution

1
Analyze the network topology
On-premises network is connected to Hub VPC via HA VPN. Spoke VPC is peered with Hub VPC via VPC Network Peering.
Understanding the path helps identify where routing rules apply.
2
Evaluate VPC Network Peering routing behavior
VPC Network Peering is non-transitive by design.
Only directly peered networks can communicate; a peered network cannot act as an intermediate transit router to a third network (on-premises) without dedicated hub-and-spoke transit services like Network Connectivity Center.

Key Concept

VPC Network Peering Non-Transitivity
Question 1487Question →

A fintech enterprise operates an online payment processing API deployed on Google Cloud Run and backed by Cloud Spanner. The team has established a Service Level Objective (SLO) requiring 99.9%99.9\% of successful HTTP responses to serve within 200 ms over a rolling 30-day window. Recently, short transient spikes in latency triggered paging alerts that resolved themselves in under two minutes, causing alert fatigue for the SRE team. Meanwhile, a slow memory leak consumed 35%35\% of the monthly error budget over a 12-hour period without waking the on-call engineer. Which alerting strategy should the team implement in Cloud Monitoring to ensure timely notifications for critical incidents while eliminating false alarms?

Show answer & explanation

Answer: Implement a multi-window, multi-burn-rate alert policy in Cloud Monitoring that triggers high-priority pages based on short and long window error budget consumption rates.

Answer

Implement a multi-window, multi-burn-rate alert policy in Cloud Monitoring that triggers high-priority pages based on short and long window error budget consumption rates.
According to Google SRE principles and GCP Cloud Monitoring recommended practices, multi-window multi-burn-rate alert policies evaluate error budget consumption across both short and long lookback windows. This prevents transient momentary spikes from triggering unnecessary pages while ensuring that sustained degradation rapidly alerting on-call engineers before significant budget depletion occurs.

Step-by-Step Solution

1
Analyze the problem requirements and current alerting flaws.
Identified that transient spikes trigger false alarms (alert fatigue) while long sustained degradation fails to alert despite consuming a significant portion of the error budget.
Static time windows and fixed thresholds are either too sensitive to short spikes or too slow to catch sustained slow budget consumption.
2
Apply Google SRE best practices for SLO-based alerting.
Selected multi-window, multi-burn-rate alerting.
Burn-rate alerting measures how fast an application is consuming its error budget relative to the SLO target over multiple short (e.g., 1-hour) and long (e.g., 6-hour) lookback windows.

Key Concept

Multi-window, multi-burn-rate alerting for error budget management in SRE practices.
Question 1488Question →

An enterprise security architecture team needs to implement automated, event-driven secret rotation for database credentials using GCP Secret Manager, Cloud Pub/Sub, and a Cloud Run function. What is the correct sequence of steps to configure this automated rotation workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with deploying the Cloud Run rotation function, creating the target Pub/Sub topic, granting the Secret Manager Service Agent publisher permissions on that topic, subscribing the Cloud Run function to the topic, and finally enabling the rotation schedule on the secret linked to the topic.
Automated secret rotation in Google Cloud follows an event-driven pub/sub architectural model. First, the worker component (Cloud Run function) that interacts with database APIs and Secret Manager versions must be deployed. Second, a Pub/Sub topic acts as the event broker. Third, Secret Manager's service agent requires the Pub/Sub Publisher role on the topic to emit rotation events. Fourth, the Cloud Run function is subscribed to the topic so event delivery triggers rotation logic. Finally, setting the rotation frequency on the secret itself initiates the automated lifecycle.

Step-by-Step Solution

1
Deploy the rotation application logic
The Cloud Run function is ready to handle credential regeneration and payload versioning.
The rotation target must exist prior to configuring event bindings and notification triggers.
2
Create the event messaging topic
A Pub/Sub topic is provisioned to receive rotation signals.
Secret Manager relies on Pub/Sub topics as event sinks for rotation notifications.
3
Authorize the Secret Manager Service Agent
The service agent for Secret Manager gains `roles/pubsub.publisher` on the Pub/Sub topic.
By default, Secret Manager cannot publish notification messages to custom Pub/Sub topics without explicit IAM permission.
4
Bind the Pub/Sub topic to the Cloud Run function
An Eventarc trigger or Pub/Sub subscription connects the topic to the function.
This establishes the trigger path so published rotation events immediately execute the function code.
5
Enable rotation schedule on the secret
Secret Manager starts tracking rotation intervals and publishing events.
Attaching the topic and rotation schedule to the secret completes the workflow and starts automated rotation.

Key Concept

Secret Manager Event-Driven Automated Rotation Lifecycle
Question 1489Question →

An energy utility company operates a smart grid telemetry platform on Google Cloud. The primary workload runs in region `us-east1`, utilizing Compute Engine Managed Instance Groups (MIGs) behind an External HTTP(S) Load Balancer and a Cloud SQL for PostgreSQL database. To maintain a Warm Standby disaster recovery pattern targeting an RTO of less than 15 minutes and an RPO of less than 5 minutes in secondary region `us-central1`, the team maintains a cross-region Cloud SQL read replica and a baseline MIG of 2 instances in `us-central1`. During a simulated disaster recovery failover test where `us-east1` is declared offline, the automation script successfully promotes the Cloud SQL read replica in `us-central1` to standalone primary status and attempts to scale out the `us-central1` MIG to 50 instances to handle full production traffic. However, the MIG scaling operation fails immediately and cannot launch additional compute instances, causing the failover to stall. Which of the following is the most likely cause of this execution failure?

Show answer & explanation

Answer: The Google Cloud project lacks sufficient regional Compute Engine resource quota in `us-central1`, as quota increases were only granted for the primary region.

Answer

The Google Cloud project lacks sufficient regional Compute Engine resource quota in us-central1, as quota increases were only granted for the primary region.
In Google Cloud, compute resource quotas (such as N2 CPUs, Regional External IP addresses, and In-use IP addresses) are assigned on a per-region basis within a project. In a Warm Standby disaster recovery topology where instances are kept minimal in the recovery region, attempting to scale out rapidly from a low baseline to full production capacity during a DR event will fail if regional quotas in the target region have not been requested and increased in advance.

Step-by-Step Solution

1
Analyze the disaster recovery failover behavior and symptoms.
The database promotion succeeded, but expanding the Compute Engine Managed Instance Group from 2 to 50 instances in the failover region failed immediately.
Identifying whether the bottleneck is database replication, network routing, or infrastructure capacity constraint narrows down the failure domain.
2
Evaluate Google Cloud resource limit boundaries across regions.
Compute Engine CPU and instance quotas are project-specific and region-specific.
If a project has not pre-requested higher resource quotas in the backup region, scaling up instances during a regional DR event will trigger a quota exceeded error.
3
Select the root cause that directly prevents MIG capacity expansion.
Missing or insufficient regional quota pre-allocation in the DR region prevents instance creation.
Pre-requesting and regularly auditing resource quotas across primary and backup regions is a fundamental requirement for executing DR procedures.

Key Concept

Disaster Recovery Capacity & Quota Management
Question 1490Question →

An enterprise is designing a high-availability architecture on Google Cloud for a stateless web application requiring low latency across multiple regions. The application receives unpredictable traffic spikes and requires continuous availability even if an entire region experiences an outage. Which TWO architectural recommendations should you implement to satisfy these technical and availability requirements?

Select all that apply

Show answer & explanation

Answer: Deploy the stateless web backend across multiple Compute Engine Managed Instance Groups (MIGs) located in two different Google Cloud regions.; Place a Global External Application Load Balancer in front of the backend instances to route incoming user traffic to the nearest healthy regional instance group.

Answer

The correct architecture uses multi-region Compute Engine Managed Instance Groups (MIGs) fronted by a Global External Application Load Balancer.
High availability across regional outages requires deploying application backend instances in multiple Google Cloud regions. Deploying Managed Instance Groups across separate regions combined with a Global External Application Load Balancer allows traffic to automatically route to the closest healthy backend region, satisfying both low latency and seamless failover requirements.

Step-by-Step Solution

1
Analyze high-availability requirement across region outages
Identify that compute resources must be deployed in at least two distinct geographic regions.
Zonal or single-region deployments cannot survive a full Google Cloud regional disruption.
2
Select global load balancing mechanism for low latency and failover
Choose a Global External Application Load Balancer.
It uses Anycast IP routing to direct users to the nearest healthy backend region and handles seamless regional failover.

Key Concept

Designing Multi-Region High Availability with Global Load Balancing
Question 1491Question →

An organization deploys a microservice on Cloud Run in Project A that needs to retrieve sensitive database credentials stored in Secret Manager in Project B. The security team mandates that identity management must strictly enforce the principle of least privilege, avoid long-lived credential exports, and minimize management overhead. Which architectural design should you implement to satisfy these security requirements?

Show answer & explanation

Answer: Create a dedicated custom service account in Project A, attach it to the Cloud Run service, and grant this service account the Secret Manager Secret Accessor role on the target secret in Project B.

Answer

Attach a dedicated custom service account in Project A to the Cloud Run service and grant it the Secret Manager Secret Accessor role directly on the specific secret residing in Project B.
Attaching a dedicated custom service account to the Cloud Run service in Project A and granting it the Secret Manager Secret Accessor role on the specific secret in Project B provides secure cross-project authorization. This approach leverages Google Application Default Credentials (ADC) to eliminate long-lived service account keys while strictly observing the principle of least privilege.

Step-by-Step Solution

1
Identify the authentication mechanism
Cloud Run supports attached managed identities (service accounts) that generate short-lived tokens via Application Default Credentials (ADC).
Eliminates the risk of long-lived credential leakage from static JSON service account keys.
2
Apply resource-level IAM permissions across projects
Grant `roles/secretmanager.secretAccessor` to the Project A Cloud Run service account specifically on the secret resource in Project B.
Enforces least privilege by granting access only to the required secret without giving access to other project resources or administrative capabilities.

Key Concept

Cross-Project Secret Access with Least Privilege Service Accounts
Estimated Time:1m 30s
Question 1492Question →

A financial analytics company is migrating its real-time trade audit platform to Google Cloud. The application experiences a steady, predictable baseline traffic pattern during standard trading hours, but encounters extreme, unpredictable 10x traffic spikes during high-volatility market events. The transactional workload requires single-region relational database capabilities with ACID compliance and High Availability (HA). Regulatory governance mandates that raw audit log files must be stored immutably and rendered tamper-proof for seven years at the lowest possible operational and storage cost. Additionally, leadership requires an operational model that minimizes infrastructure management overhead and total cost of ownership (TCO). Which architectural design should you recommend?

Show answer & explanation

Answer: Deploy the application on Cloud Run connected via Serverless VPC Access to a High Availability Cloud SQL for PostgreSQL instance, enforce long-term audit log retention using Cloud Storage Archive class with a Bucket Lock retention policy, and purchase Flexible Committed Use Discounts (CUDs) to cover baseline compute capacity.

Answer

The optimal architecture deploys Cloud Run connected via Serverless VPC Access to a High Availability Cloud SQL instance, retains historical logs in Cloud Storage Archive class using Bucket Lock retention policies, and applies Flexible Committed Use Discounts for baseline compute cost optimization.
The combination of Cloud Run and Cloud SQL (HA) delivers a low-management, serverless compute model that automatically scales to handle 10x traffic spikes while keeping baseline compute costs minimal using Flexible CUDs. Storing raw logs in Cloud Storage Archive class with Bucket Lock ensures 7-year regulatory WORM compliance at the lowest possible cost per gigabyte.

Step-by-Step Solution

1
Evaluate compute scaling and FinOps optimization requirements.
Cloud Run provides serverless autoscaling from baseline to 10x traffic spikes with zero baseline overhead when idle. Applying Flexible Committed Use Discounts (CUDs) covers the predictable baseline cost while allowing spot/pay-as-you-go scaling for unpredictable spikes.
Resource-based CUDs provisioned for peak capacity cause severe financial waste during off-peak hours.
2
Select database technology based on locality and relational ACID requirements.
Cloud SQL for PostgreSQL in High Availability (regional) mode satisfies single-region relational ACID requirements at a fraction of Cloud Spanner's cost.
Cloud Spanner is designed for horizontally scaled, multi-region or globally distributed workloads and represents an over-engineered, costly choice for single-region relational needs.
3
Align long-term storage and regulatory compliance requirements with Cloud Storage classes.
Cloud Storage Archive class offers the lowest cost tier for long-term (7-year) cold log storage. Bucket Lock enclaves a WORM (Write Once, Read Many) compliance policy to guarantee immutability.
Standard storage tiers and active database storage (BigQuery) incur excessive ongoing storage costs for data that is rarely accessed.

Key Concept

Balancing compute autoscaling, database right-sizing, and storage tiering to optimize Total Cost of Ownership (TCO) while satisfying business availability and regulatory compliance requirements.
Question 1493Question →

A healthcare enterprise maintains sensitive patient analytics workloads inside a Google Cloud project secured by a VPC Service Controls perimeter protecting BigQuery and Cloud Storage. A data science team operates an automated pipeline from a separate, un-perimeterized operations project that requires reading datasets from BigQuery inside the perimeter and writing results to Cloud Storage. Security policies strictly prohibit exposing perimeter resources to the public internet or relaxing IAM permissions broadly. Which architectural solution securely grants the pipeline access while preserving the perimeter security boundary?

Show answer & explanation

Answer: Define VPC Service Controls Ingress and Egress rules to allow specific service account identities from the operations project to interact with protected services inside the perimeter.

Answer

Configure VPC Service Controls Ingress and Egress rules allowing explicit service account identities from the external project to communicate with perimeter resources.
VPC Service Controls Ingress and Egress rules provide a secure mechanism to allow explicitly authorized API traffic across a service perimeter boundary based on identity (e.g., service account email) and API attributes without disabling perimeter protections.

Step-by-Step Solution

1
Analyze the access requirement across perimeter boundaries.
Identified that resources in the un-perimeterized project need to call API methods on BigQuery and Cloud Storage protected within the perimeter.
VPC Service Controls block API access across perimeters by default unless explicit perimeter rules are configured.
2
Evaluate perimeter cross-boundary communication features.
Determine that VPC Service Controls Ingress and Egress policies permit fine-grained access based on identity (service account), source project/perimeter, and specific GCP services.
Ingress and Egress rules allow secure API calls without exposing data exfiltration risks or removing services from the perimeter.

Key Concept

VPC Service Controls Ingress and Egress rules
Question 1494Question →

A cloud architect needs to select the appropriate Google Cloud hybrid connectivity service for four distinct organizational requirements. Match each hybrid connectivity service on the left with its defining operational requirement on the right.

Click a left item, then click its matching right item

Items

Dedicated Interconnect
Partner Interconnect
HA VPN
Cloud Router

Matches

Show answer & explanation

Answer

Dedicated Interconnect matches establishing a direct physical fiber connection at a colocation facility. Partner Interconnect matches connecting through a supported third-party service provider. HA VPN matches providing an IPsec encrypted connection over the public internet with a 99.99% SLA. Cloud Router matches dynamically exchanging routes using BGP.
Dedicated Interconnect physically connects enterprise hardware directly to Google at a colocation site. Partner Interconnect uses third-party service providers to bridge physical network gaps. HA VPN delivers active-active IPsec tunnels over the public internet backed by a 99.99% SLA. Cloud Router uses BGP to dynamically advertise and learn routes between VPCs and on-premises environments.

Step-by-Step Solution

1
Identify the service providing direct physical infrastructure linkage.
Dedicated Interconnect is matched with direct physical fiber cabling at a Google colocation facility.
Dedicated Interconnect bypasses the public internet completely by extending private physical circuits directly into Google's colocation facilities.
2
Identify the service providing connectivity via external network providers.
Partner Interconnect is matched with connecting through a supported third-party service provider.
Partner Interconnect allows organizations to connect to GCP when their physical location does not reach a Google colocation facility directly.
3
Identify the service providing high-availability encrypted tunneling over public internet.
HA VPN is matched with IPsec encrypted connections offering 99.99% SLA.
HA VPN operates over the public internet using IPsec protocol while guaranteeing 99.99% SLA with dual active tunnels.
4
Identify the control plane service managing dynamic dynamic route propagation.
Cloud Router is matched with dynamic route exchange using BGP.
Cloud Router handles dynamic BGP peerings to automatically advertise and learn subnets between GCP VPCs and remote routers.

Key Concept

Differentiating GCP hybrid connectivity mechanisms (Dedicated Interconnect, Partner Interconnect, HA VPN) and dynamic routing mechanisms (Cloud Router).
Estimated Time:1m 0s
Question 1495Question →

A financial analytics company runs its core reporting application in region `us-east4` (primary) with a warm standby disaster recovery setup in region `us-central1` (secondary). The primary region experiences a prolonged physical infrastructure failure. The site reliability engineering (SRE) team must execute the manual failover runbook to restore operational service in `us-central1`. Sequence the operational steps below in the correct order to successfully execute the regional failover.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Promote the cross-region Cloud SQL read replica in us-central1 to a standalone primary database instance; 2) Update the internal Cloud DNS endpoint record to resolve database traffic to the newly promoted instance in us-central1; 3) Resize the secondary Compute Engine Managed Instance Group (MIG) in us-central1 from zero to full operational capacity; 4) Update the Cloud Load Balancing backend service configuration to divert incoming ingress traffic to the us-central1 MIG.
Executing a disaster recovery failover requires establishing data tier write availability first (database promotion), configuring internal service discovery, scaling out compute resources in the secondary region, and finally updating global ingress routing to direct user traffic to the newly active region.

Step-by-Step Solution

1
Promote the database replica in the failover region.
A writable primary database instance is available in us-central1.
Compute workloads cannot process requests without access to a writable database instance.
2
Reconfigure internal network endpoints (Cloud DNS).
Internal database hostname resolves to the us-central1 instance IP.
Application nodes require correct database connection strings and DNS resolution before serving traffic.
3
Provision compute capacity in us-central1.
Compute Engine MIG scales up and passes initial startup and health checks.
Application instances must be running and healthy before receiving live user requests.
4
Shift global ingress traffic to the secondary region.
External user requests route to us-central1.
Diverting traffic at the load balancer is executed only after backend dependencies and compute instances are operational.

Key Concept

Disaster Recovery Regional Failover Execution Order
Estimated Time:1m 30s
Question 1496Question →

A digital asset management platform operates a media processing API deployed on Google Cloud Run. The Site Reliability Engineering (SRE) team defines an availability Service Level Objective (SLO) of 99.95%99.95\% successful requests (HTTP non-5xx status codes) over a rolling 30-day measurement window. During a period where the service processed exactly 40,000,00040,000,000 total requests, an infrastructure outage caused 12,00012,000 request failures. How many additional failed requests can the API tolerate during this measurement window before completely exhausting its error budget?

Show answer & explanation

Answer: 8000

Answer

The service can tolerate an additional 8,000 failed requests before its error budget is completely exhausted.
For an availability SLO of 99.95%99.95\% on 40,000,00040,000,000 requests, the total error budget is 40,000,000×(1−0.9995)=20,00040,000,000 \times (1 - 0.9995) = 20,000 allowed error requests. Having already incurred 12,00012,000 errors, the remaining error budget is 20,000−12,000=8,00020,000 - 12,000 = 8,000 failed requests.

Step-by-Step Solution

1
Calculate the total allowable error budget in terms of request failures.
Total allowable error budget = 40,000,000×(1−0.9995)=20,00040,000,000 \times (1 - 0.9995) = 20,000 failed requests.
An availability SLO of 99.95%99.95\% allows an unreliability budget of 0.05%0.05\% (or 0.00050.0005) of total requests.
2
Calculate the remaining allowable error budget.
Remaining error budget = 20,000−12,000=8,00020,000 - 12,000 = 8,000 failed requests.
Subtracting the error budget already consumed by failures from the total budget yields the remaining capacity for bad requests.

Key Concept

Request-based Error Budget Calculation for Availability SLOs
Question 1497Question →

An enterprise architecture team for a global aerospace manufacturer is selecting Google Cloud networking solutions for various workloads during a multi-region migration. Match each Google Cloud networking service on the left with the architectural scenario requirement on the right that best justifies its implementation.

Click a left item, then click its matching right item

Items

Dedicated Interconnect
High Availability (HA) VPN
Partner Interconnect
VPC Network Peering

Matches

Show answer & explanation

Answer

Dedicated Interconnect matches the requirement for direct 10 Gbps/100 Gbps physical circuits at a Google edge location. HA VPN matches the requirement for 99.99% SLA IPsec encrypted connectivity over the public internet. Partner Interconnect matches the requirement for connecting via a third-party service provider where direct Google PoP access is absent. VPC Network Peering matches internal VPC-to-VPC communication without external gateways.
Each hybrid networking technology addresses distinct architecture criteria: Dedicated Interconnect delivers direct 10/100 Gbps physical circuits; HA VPN delivers SLA-backed 99.99% encrypted IPsec connectivity over the internet; Partner Interconnect connects sites via service provider networks where Google PoPs are unavailable; and VPC Network Peering provides high-bandwidth, private internal routing between VPC networks.

Step-by-Step Solution

1
Analyze high-bandwidth physical connection requirements
Dedicated Interconnect provides physical 10 Gbps or 100 Gbps connections directly to Google edge facilities.
When private throughput requirements exceed standard VPN capabilities and a direct facility connection is available, Dedicated Interconnect is required.
2
Evaluate encrypted internet-based connectivity needs
HA VPN fulfills IPsec encrypted tunnel requirements over public internet while guaranteeing 99.99% availability.
HA VPN uses active-active topologies with Cloud Router dynamic BGP routing to ensure 99.99% uptime for internet-bound hybrid traffic.
3
Determine connectivity options for remote geographical locations without Google PoPs
Partner Interconnect enables connection through supported service providers.
Partner Interconnect extends GCP private interconnect benefits to locations where the enterprise cannot colocate directly with Google.
4
Identify cloud-native intra-GCP networking mechanisms
VPC Network Peering connects separate VPCs internally within Google Cloud.
VPC Peering provides direct internal routing between VPCs without incurring performance bottlenecks or needing virtual gateways.

Key Concept

Selecting GCP Hybrid Connectivity and VPC Topology Solutions based on SLA, Bandwidth, Physical Location, and Routing Constraints
Question 1498Question →

Your organization is establishing an automated, enterprise-grade Infrastructure as Code (IaC) deployment pipeline for Google Cloud using Terraform and Cloud Build. Arrange the steps in the correct operational sequence to securely provision a new production environment while ensuring remote state locking, policy-as-code governance, and zero static credential storage.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for provisioning infrastructure via IaC is: 1) Authenticate via Workload Identity Federation; 2) Run `terraform init` to initialize the workspace and lock the Cloud Storage state backend; 3) Run `terraform plan` and execute automated policy-as-code compliance checks; 4) Submit the speculative plan artifact for formal peer approval; 5) Run `terraform apply` with the approved plan file to provision resources and release the backend state lock.
Following Google Cloud SRE and enterprise IaC best practices, automated environment provisioning requires a strict sequence. First, the runner authenticates keylessly using Workload Identity Federation. Second, `terraform init` establishes remote state locking in Cloud Storage to block conflicting parallel executions. Third, a speculative `terraform plan` is evaluated using automated policy-as-code guardrails. Fourth, the generated plan artifact undergoes mandatory peer review to fulfill change management requirements. Finally, `terraform apply` executes the approved plan artifact and releases the backend lock.

Step-by-Step Solution

1
Authenticate runner via Workload Identity Federation
Pipeline receives temporary IAM service account token
Eliminates long-lived service account key security risks in automated CI/CD pipelines.
2
Initialize Terraform backend with Cloud Storage state locking
Backend initialized and Cloud Storage object lock acquired
Ensures state consistency and protects state files from concurrent mutation.
3
Generate speculative execution plan and run policy-as-code validation
Speculative plan created and validated against security guardrails
Catches misconfigurations and policy violations prior to actual resource creation.
4
Submit plan artifact for human review and approval gate
Approval recorded for the immutable plan file
Enforces governance controls and prevents plan drift between review and deployment.
5
Apply approved plan artifact and release state lock
GCP resources created/updated and backend state lock released
Executes the precise reviewed state changes idempotently.

Key Concept

Infrastructure as Code Provisioning Workflow and State Locking Lifecycle
Question 1499Question →

A global aerospace engineering firm is designing a multi-tier hybrid network architecture to connect its on-premises data centers and remote manufacturing facilities to Google Cloud. Match each operational connectivity requirement on the left with the appropriate Google Cloud hybrid networking solution on the right.

Click a left item, then click its matching right item

Items

Provisioning 100 Gbps private, unencrypted bandwidth between a primary research data center and a VPC network with a 99.99% availability SLA requiring redundant circuits across two edge availability domains.
Establishing an encrypted IPsec connection over the public internet with a 99.99% availability SLA for a regional distribution facility.
Connecting a remote manufacturing plant requiring 200 Mbps sub-1G capacity where direct physical colocation with a Google edge facility is unavailable, leveraging a supported service provider.
Dynamically exchanging BGP routes to establish automatic topology updates and failover paths between on-premises routers and VPC subnets.

Matches

Show answer & explanation

Answer

Matching pairs: Dedicated Interconnect satisfies 100 Gbps private connectivity with a 99.99% SLA across edge availability domains; HA VPN with dual gateways satisfies encrypted public internet connectivity with a 99.99% SLA; Partner Interconnect satisfies sub-1 Gbps connectivity via a service provider; Cloud Router satisfies dynamic BGP route exchange.
Each operational requirement strictly maps to its corresponding Google Cloud networking component based on bandwidth thresholds, SLA guarantees, encryption needs, and service provider integration.

Step-by-Step Solution

1
Analyze high-bandwidth and physical direct connection requirements.
Requirements of 100 Gbps direct private connection with a 99.99% SLA align specifically with Dedicated Interconnect deployed across two edge availability domains.
Dedicated Interconnect directly links the enterprise facility to Google's edge colocation using 10 Gbps or 100 Gbps physical circuits.
2
Analyze encrypted public IPsec connectivity requirements with a 99.99% availability SLA.
Requires HA VPN featuring dual VPN gateways and active-active tunnels.
Classic VPN does not offer a 99.99% SLA; HA VPN is explicitly engineered to provide 99.99% availability over IPsec.
3
Analyze low-bandwidth service provider connectivity requirements.
Sub-1 Gbps capacity (200 Mbps) through an ISP service provider maps to Partner Interconnect.
Partner Interconnect allows connection through third-party service providers when direct connection facilities are inaccessible or bandwidth needs are under 1 Gbps.
4
Analyze dynamic routing requirements.
BGP dynamic route exchange maps to Cloud Router.
Cloud Router automates route propagation using BGP across hybrid interconnects and VPN tunnels.

Key Concept

Architecting Google Cloud hybrid connectivity options (Dedicated Interconnect, Partner Interconnect, HA VPN, Cloud Router) based on SLA, bandwidth, encryption, and service provider integration.
Question 1500Question →

A healthcare technology enterprise processes nightly batch workloads for genomic sequence analysis and stores raw sequence reads for 7 years to satisfy regulatory compliance mandates. The batch processing jobs are stateless, fault-tolerant, and execute for 4 hours each night. The raw sequence files are accessed frequently during the first 30 days after generation, but subsequent access occurs less than once per year for compliance audits. Which TWO architectural choices should you recommend to minimize overall infrastructure costs while satisfying operational and compliance requirements?

Select all that apply

Show answer & explanation

Answer: Provision Compute Engine Managed Instance Groups (MIGs) utilizing Spot VMs for the nightly batch processing pipeline.; Implement Cloud Storage Object Lifecycle Management rules to transition raw sequence files to Archive Storage after 30 days.

Answer

The correct recommendations are using Compute Engine Spot VMs in Managed Instance Groups for the batch processing workload and configuring Cloud Storage Object Lifecycle Management rules to transition raw data to Archive Storage after 30 days.
Using Spot VMs within Managed Instance Groups provides up to 80% compute cost savings for fault-tolerant, stateless batch workloads running for 4 hours daily. For storage, automating object transitions from Standard to Archive Storage after 30 days minimizes the total cost of ownership for 7-year compliance retention without impacting active processing performance.

Step-by-Step Solution

1
Analyze the compute workload characteristics and cost structure
The batch pipeline is stateless, fault-tolerant, and runs for only 4 hours daily.
Stateless and fault-tolerant workloads that execute for short durations achieve maximum cost savings by leveraging Spot VMs rather than committed baseline instances or 24/7 clusters.
2
Evaluate data access frequency and long-term compliance retention requirements
Files are accessed frequently for 30 days and retained for 7 years with sub-annual retrieval.
Using Standard Storage for the first 30 days handles active processing, while automatically transitioning objects to Archive Storage after 30 days minimizes 7-year storage costs.
3
Eliminate sub-optimal or over-engineered architectural options
Always-on GKE clusters, Cloud Spanner database storage for binary sequence blobs, and continuous CUD commitments introduce unnecessary expenditures.
Aligning service selections with actual operational lifecycles prevents paying for idle compute capacity and high-tier database storage.

Key Concept

Designing infrastructure for cost optimization by pairing Spot instances for fault-tolerant batch compute with automated lifecycle tiering for long-term compliance storage.
Estimated Time:2m 0s
PreviousPage 75 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin