Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1381Question →

An e-commerce company is preparing for an upcoming flash sale expected to increase traffic to five times normal peak volume on Google Cloud. As the Cloud Architect responsible for capacity planning and workload scaling optimization, which TWO actions should you recommend to ensure seamless infrastructure scaling and prevent availability bottlenecks? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Review regional GCP quota limits for CPU cores and IP addresses in advance, submitting quota increase requests prior to the event.; Configure Compute Engine Managed Instance Group (MIG) autoscaling policies based on custom application metrics such as request latency or HTTP queue depth.

Answer

Review regional GCP quota limits for CPU cores and IP addresses in advance, submitting quota increase requests prior to the event, AND configure Compute Engine Managed Instance Group (MIG) autoscaling policies based on custom application metrics such as request latency or HTTP queue depth.
Effective capacity planning requires requesting regional resource quota increases well ahead of anticipated high-volume events because quota requests are not instant. Additionally, configuring scaling policies to utilize custom workload metrics (such as queue depth or HTTP throughput) ensures instance groups scale out responsively when I/O or connection limits are reached.

Step-by-Step Solution

1
Evaluate project quota boundaries
Identify potential resource constraints (e.g., regional CPU limits) before traffic spikes occur.
Quota increases require administrative approval and time to process.
2
Optimize autoscaling signals
Ensure instance groups scale based on actual load bottlenecks (like incoming HTTP requests or queue length) rather than CPU alone.
Web workloads can saturate request queues or network sockets while CPU utilization remains low.

Key Concept

Capacity Planning and Infrastructure Workload Scaling Optimization
Estimated Time:1m 0s
Question 1382Question →

A financial services firm is migrating a mission-critical legacy transactional backend to Google Cloud over a 6-month phased rollout. The on-premises environment consists of a 40 TB relational database with high transaction volume, where legacy monolithic services and modernized cloud-native microservices must run concurrently against the data layer. Business requirements mandate zero downtime during application cutovers and continuous backward compatibility as database schemas evolve. Which strategy should the Cloud Architect recommend to manage database technology debt while ensuring continuous availability during the migration?

Show answer & explanation

Answer: Implement continuous Change Data Capture (CDC) from the on-premises database to Cloud SQL for PostgreSQL, and mandate an expand-contract database schema modification strategy so schema changes remain backward-compatible across active application versions.

Answer

Implement continuous Change Data Capture (CDC) from on-premises to Cloud SQL for PostgreSQL, paired with an expand-contract (decoupled) database schema migration strategy.
The correct strategy combines continuous online replication via Change Data Capture (CDC) with an expand-contract database migration design pattern. CDC maintains active data sync between on-premises and Cloud SQL environments during phased migration. The expand-contract pattern introduces non-breaking additive schema changes (expand) first, allowing legacy monolithic components and modernized cloud microservices to operate concurrently on shared data structures until legacy code is retired and old columns can be safely dropped (contract).

Step-by-Step Solution

1
Analyze continuous data replication requirements for phased migration.
Identify that live transaction synchronization requires an online Change Data Capture (CDC) engine to keep on-premises and Cloud SQL instances tightly synchronized.
Batch imports or offline transfers cannot support zero-downtime cutovers or concurrent multi-month parallel operations.
2
Evaluate database schema refactoring techniques for active migration environments.
Adopt the expand-contract (parallel change) pattern where database schema modifications are executed in additive phases (expand) before legacy code dependencies are decommissioned (contract).
This guarantees that both legacy monolithic components and modernized microservices can safely query the database simultaneously without breaking changes.

Key Concept

Legacy Database Modernization and Schema Evolution Management during Phased Migration
Question 1383Question →

An enterprise development team is setting up an automated CI/CD pipeline using a deployment service account to provision Compute Engine instances via Terraform. The deployed virtual machines need to run applications under a dedicated runtime service account. The team wants to allow the pipeline service account to attach this runtime service account to the virtual machines without granting excess administrative permissions. Which recommendation should you give to the development team?

Show answer & explanation

Answer: Grant the deployment service account the Service Account User role on the dedicated runtime service account.

Answer

Grant the deployment service account the Service Account User role on the dedicated runtime service account.
Granting the Service Account User role (roles/iam.serviceAccountUser) on the specific target service account allows the deployment pipeline to attach that service account to new Compute Engine instances. This fulfills the deployment requirement while adhering strictly to the principle of least privilege.

Step-by-Step Solution

1
Identify the required operational capability for the CI/CD deployment service account.
The pipeline needs permission to attach a specific runtime service account to Compute Engine instances.
Security best practices require restricting permission scope to only what is necessary for resource provisioning.
2
Evaluate Google Cloud IAM roles for service account attachment.
The Service Account User role (roles/iam.serviceAccountUser) permits an identity to attach a service account to a compute resource.
This role provides exact functional authorization without granting administrative capabilities over IAM resources.
3
Apply least privilege scoping.
Granting roles/iam.serviceAccountUser at the target service account resource level limits attachment rights strictly to that specific identity.
Resource-level IAM bindings prevent the deployment pipeline from attaching unauthorized service accounts.

Key Concept

Least privilege service account attachment and IAM scoping
Question 1384Question →

An enterprise organization operates multiple microservice workloads across Google Kubernetes Engine (GKE) and Compute Engine. The cloud operations team needs to centralize operational observability while optimizing logging ingestion costs. They want to filter out non-essential debug logs from storage while ensuring high-severity application errors and security audit logs are reliably preserved for incident investigation. Which log routing design best meets these observability and reliability requirements?

Show answer & explanation

Answer: Configure an aggregated Log Router sink at the organization level with explicit inclusion filters targeting severity levels of ERROR and above, while applying fine-grained exclusion filters for low-severity debug logs before exporting to a centralized BigQuery dataset.

Answer

Configure an aggregated Log Router sink at the organization level with explicit inclusion filters targeting severity levels of ERROR and above, while applying fine-grained exclusion filters for low-severity debug logs before exporting to a centralized BigQuery dataset.
Configuring an aggregated Log Router sink with targeted inclusion filters for ERROR severity logs and explicit exclusions for debug logs ensures that critical telemetry is centrally preserved for analysis while optimizing overall storage costs.

Step-by-Step Solution

1
Analyze logging and observability requirements
Identified the need to retain high-severity error and security audit logs while reducing storage costs by eliminating non-essential debug telemetry.
Observability requires reliable access to error logs during incidents without incurring unnecessary ingestion costs for debug logs.
2
Evaluate GCP Log Router capabilities
Log Router sinks with inclusion and fine-grained exclusion filters allow organization-wide aggregated routing.
Filtering at ingestion prevents unwanted log storage while ensuring high-priority diagnostic logs flow to central storage.
3
Select the optimal architecture
An aggregated sink with severity-based inclusion and targeted debug exclusion achieves both cost control and observability reliability.
This strategy maintains complete visibility into errors and security events without risking log loss or compliance violations.

Key Concept

Monitoring, Logging, and Observability Integration
Question 1385Question →

A global media streaming platform hosts microservices on Google Kubernetes Engine (GKE) and stores build artifacts in Artifact Registry. The security engineering team must establish an automated security monitoring baseline that continuously scans container images for software vulnerabilities upon push and detects kernel-level runtime threats (such as reverse shells or execution of unmanaged binaries) on GKE nodes without installing third-party agent software. Which GCP security architecture meets these requirements?

Show answer & explanation

Answer: Enable Security Command Center Premium Edition with Container Threat Detection (CTD) enabled for GKE, and configure Artifact Registry Automatic Vulnerability Scanning.

Answer

Enable Security Command Center Premium Edition with Container Threat Detection (CTD) enabled for GKE, and configure Artifact Registry Automatic Vulnerability Scanning.
Combining Security Command Center Premium's Container Threat Detection with Artifact Registry's automatic vulnerability scanning satisfies both requirements agentlessly and natively within Google Cloud.

Step-by-Step Solution

1
Identify the container vulnerability management requirement.
Artifact Registry Automatic Vulnerability Scanning monitors container image packages for CVEs upon registry upload.
Measures container security early in the CI/CD deployment pipeline.
2
Identify the agentless runtime threat detection requirement for GKE.
Container Threat Detection (part of Security Command Center Premium) offers native, agentless detection of kernel-level threats.
Analyzes container executions and underlying memory without adding operational overhead or third-party agent pods.

Key Concept

Container Security and Threat Detection in Google Cloud
Question 1386Question →

An SRE team is managing a high-throughput payment microservice hosted on Google Cloud. They want to ensure they receive operational alerts before their monthly service availability target is breached. Which alerting strategy should the team implement?

Show answer & explanation

Answer: Configure alerts based on multi-window error budget burn rates.

Answer

Configure alerts based on multi-window error budget burn rates.
Burn rate alerting measures the speed at which a service consumes its error budget. Using multi-window burn rate alerts ensures that severe incidents consuming significant budget trigger immediate alerts, while minor transient errors do not create unnecessary alert noise.

Step-by-Step Solution

1
Identify the primary operational reliability goal.
The goal is to alert on rapid consumption of the error budget before violating the Service Level Objective (SLO).
SLO management relies on tracking error budget consumption rather than raw metric blips or resource usage.
2
Evaluate alerting approaches against SRE best practices.
Multi-window burn rate alerts calculate consumption velocity over both short and long time windows.
Burn rate alerting ensures severe incidents trigger urgent notifications while suppressing transient, non-critical noise.

Key Concept

Error Budget Burn Rate Alerting
Estimated Time:1m 0s
Question 1387Question →

An operations team is defining reliability metrics and alerting policies for a telemetry data ingestion pipeline built on Google Cloud Pub/Sub and Cloud Dataflow. They want to adopt Google Cloud Site Reliability Engineering (SRE) best practices to measure service quality and manage operational alerts. Which of the following statements accurately describe the correct implementation of SLIs, SLOs, or error budgets for this service? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: The Service Level Indicator (SLI) is calculated as the ratio of successfully processed messages within a target latency threshold to the total number of valid incoming messages.; Alerting policies should evaluate multi-window error budget burn rates to trigger notifications before the error budget is exhausted.

Answer

The Service Level Indicator (SLI) is defined as the quantifiable ratio measuring successful events over total valid events, and operational alerting should be based on multi-window error budget burn rates rather than static resource metrics.
Defining the Service Level Indicator (SLI) as a quantifiable ratio of successful events over total valid events reflects actual user-perceived performance. Furthermore, configuring alerts around error budget burn rates ensures on-call engineers are paged when service degradation risks exhausting the error budget, adhering strictly to Google Cloud SRE practices.

Step-by-Step Solution

1
Define the Service Level Indicator (SLI) correctly
Identify that the SLI measures actual service performance as a ratio of good events to total events.
SLIs quantify performance based on user experience metrics such as latency or success rates.
2
Select the appropriate SRE alerting strategy
Choose multi-window error budget burn rate alerting over static metric threshold alerts.
Burn rate alerting reduces noise and ensures notifications correlate directly with threat to the service's error budget.

Key Concept

Defining SLIs as quantitative performance ratios and implementing multi-window error budget burn-rate alerts.
Question 1388Question →

A global online gaming studio hosts a competitive multiplayer platform on Google Cloud using Compute Engine Managed Instance Groups (MIGs) positioned behind regional External Application Load Balancers. The workload experiences predictable, extreme traffic surges during scheduled weekend global tournaments. During previous events, standard reactive autoscaling failed to provision compute instances quickly enough to absorb the rapid spike in player connections, and provisioning operations failed due to regional compute resource limitations. As the Lead Cloud Architect, you need to implement a proactive capacity planning and workload scaling strategy to ensure seamless scalability and prevent resource exhaustion during upcoming tournaments. Which TWO actions should you take to achieve this objective?

Select all that apply

Show answer & explanation

Answer: Configure schedule-based autoscaling policy rules on the Managed Instance Groups to scale out baseline instance capacity in advance of known tournament start times.; Perform proactive capacity planning by evaluating historical usage peak metrics and requesting regional vCPU quota increases well in advance of scheduled events.

Answer

To optimize infrastructure capacity and prevent service disruption during predictable high-volume events, cloud architects should establish schedule-based autoscaling rules to pre-provision compute instances prior to peak windows and conduct proactive quota management by requesting regional vCPU quota increases in advance.
Combining schedule-based autoscaling with proactive quota management addresses both compute initialization delays and infrastructure quota limits. Schedule-based scaling pre-provisions instance capacity before predictable surges occur, ensuring zero cold-start latency for incoming users. Proactively auditing and submitting regional quota increase requests ensures that GCP project limits do not block the Managed Instance Group from expanding to its required peak instance count.

Step-by-Step Solution

1
Analyze workload surge patterns and response latency of reactive scaling
Identified that reactive metric thresholds (such as CPU or request rate) lag behind instantaneous connection spikes, leading to cold-start delays during event launches.
Predictable surges require pre-allocation of compute capacity to ensure instances are fully initialized and healthy before traffic arrives.
2
Implement schedule-based autoscaling rules on Compute Engine MIGs
MIGs automatically scale up to required minimum baseline instance counts prior to the tournament start time.
Schedule-based scaling rules complement metric-based policies by absorbing initial burst traffic smoothly without initialization bottlenecks.
3
Evaluate regional resource quotas against projected peak load
Determined required regional vCPU, memory, and IP allocation capacity needed for peak instance counts during the tournament.
Autoscaling policies cannot exceed project-level regional quotas. Requesting quota increases prior to deployment prevents provisioning failures.

Key Concept

Proactive Workload Capacity Planning and Scheduled Autoscaling
Question 1389Question →

A financial services organization hosts a hybrid banking solution across Google Kubernetes Engine (GKE) and Cloud Run. During operational incidents, engineering teams struggle to correlate distributed trace contexts with application logs and performance metrics across service boundaries. The team needs to establish a unified observability architecture that propagates trace identifiers into Cloud Logging, aggregates metrics into Cloud Monitoring, and prevents high-cardinality metric labels from causing unexpected telemetry costs. Which architecture should the Cloud Architect recommend?

Show answer & explanation

Answer: Deploy the OpenTelemetry Collector to collect spans, metrics, and structured logs, configure W3C Trace Context propagation to embed trace IDs into log payloads, and aggregate high-cardinality attributes using OpenTelemetry processors before emitting data to Google Cloud Observability.

Answer

Deploy the OpenTelemetry Collector to collect spans, metrics, and structured logs, configure W3C Trace Context propagation to embed trace IDs into log payloads, and aggregate high-cardinality attributes using OpenTelemetry processors before emitting data to Google Cloud Observability.
Deploying the OpenTelemetry Collector with W3C Trace Context propagation enables automatic correlation of trace IDs with Cloud Logging entries across microservices. Utilizing OpenTelemetry batch and filter processors controls metric label cardinality before sending telemetry to Google Cloud Observability, balancing observability depth with cost control.

Step-by-Step Solution

1
Analyze trace and log correlation requirements across distributed microservices.
Identified that W3C Trace Context propagation embeds Trace IDs into structured application log payloads for seamless correlation in Cloud Logging.
Log-trace correlation requires consistent trace context injection across GKE and Cloud Run services.
2
Evaluate metric cardinality management at the telemetry collector layer.
Configured OpenTelemetry Collector processors to aggregate or strip high-cardinality labels prior to pushing metrics into Cloud Monitoring.
Uncontrolled metric cardinality generates excessive custom metric series in Cloud Monitoring, escalating operational costs.
3
Assess security and operational best practices.
Ensured minimal IAM role assignment (Monitoring Metric Writer, Logs Writer) and protected data egress paths.
Avoids primitive role vulnerabilities and ensures secure operational logging integration.

Key Concept

Unified Observability and Telemetry Integration via OpenTelemetry and Cloud Observability
Question 1390Question →

An enterprise SaaS platform hosts microservices on Google Kubernetes Engine (GKE) and manages container images using Artifact Registry. The security team requires an architecture that automatically scans container images for vulnerabilities upon push, prevents unsigned or untrusted images from being deployed to GKE clusters, and detects runtime threats such as reverse shells or unauthorized binaries. Which TWO security measures should the cloud security architect implement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable Container Analysis in Artifact Registry to perform automated vulnerability scanning, and configure Binary Authorization on GKE to enforce container image signature policies.; Enable Security Command Center (SCC) Premium to leverage Container Threat Detection and Event Threat Detection for real-time runtime threat monitoring.

Answer

The enterprise must enable Container Analysis for vulnerability scanning in Artifact Registry, configure Binary Authorization to enforce image signature verification before deployment to GKE, and enable Security Command Center Premium to utilize Container Threat Detection and Event Threat Detection for runtime threat detection.
Enabling Container Analysis alongside Binary Authorization secures the container pipeline by automatically identifying software vulnerabilities in Artifact Registry and ensuring that only digitally signed images are admitted to GKE clusters. Enabling Security Command Center Premium provides Container Threat Detection and Event Threat Detection to continuously monitor node behavior, suspicious processes, and audit logs for active runtime security threats.

Step-by-Step Solution

1
Configure vulnerability scanning and deployment signature verification.
Container Analysis automatically scans container images pushed to Artifact Registry for known vulnerabilities, while Binary Authorization validates attestation signatures before GKE admits the deployment.
This secures the software supply chain and prevents vulnerable or unapproved code from running in production GKE environments.
2
Enable runtime container threat detection.
Security Command Center Premium activates Container Threat Detection (monitoring node and container execution behavior) and Event Threat Detection (analyzing audit streams).
This detects active threats, binary modifications, and suspicious process executions at runtime.

Key Concept

Multi-layered container security and threat detection using Container Analysis, Binary Authorization, and Security Command Center Premium.
Question 1391Question →

An enterprise IoT platform ingests telemetry from 500,000 connected vehicles through an API gateway hosted on Google Kubernetes Engine (GKE) Autopilot. The SRE team defines a Service Level Objective (SLO) requiring 99.9% of valid telemetry ingestion requests to complete successfully with a latency of under 200 ms200\text{ ms} over a rolling 30-day window. Following a series of rapid feature releases, 80% of the monthly error budget was consumed within 4 days due to brief, high-intensity error spikes that went undetected by standard threshold alerts until budget exhaustion occurred. The product team requires a policy and monitoring design that halts non-critical feature deployments when budget consumption accelerates dangerously while minimizing false-positive alerts during short transient spikes. Which architecture and operational policy should the Site Reliability Engineer recommend?

Show answer & explanation

Answer: Implement multi-window, multi-burn-rate alerting in Cloud Monitoring based on short (1-hour/6-hour) and long (3-day) budget consumption windows, and establish an automated deployment gate that halts feature rollouts when the 1-hour burn rate exceeds 14.4×14.4\times or 3-day burn rate exceeds 1×1\times.

Answer

Implement multi-window, multi-burn-rate alerting based on short and long budget consumption windows, and enforce automated feature deployment gates tied to burn-rate thresholds.
The correct strategy uses Google SRE multi-window, multi-burn-rate alerts in Cloud Monitoring. A 2% error budget consumption over 1 hour corresponds to a burn rate of 14.4×14.4\times (since 100%/(30×24 hours)≈0.1388%100\% / (30 \times 24 \text{ hours}) \approx 0.1388\% per hour, and 2%/0.1388%≈14.42\% / 0.1388\% \approx 14.4). Enforcing multi-window lookbacks prevents false alarms from short transient spikes while instantly catching significant burns, and linking deployment gates to burn rates balances release velocity with SLO targets.

Step-by-Step Solution

1
Analyze error budget consumption behavior and identify why static alerts failed
Discovered that short, high-intensity error spikes rapidly burn monthly error budgets without triggering brief static threshold alarms.
Static metric thresholds do not measure the rate of error budget depletion relative to time.
2
Apply Google SRE best practices for burn-rate alerting
Selected multi-window multi-burn-rate alerting (e.g., 1-hour lookback at 14.4×14.4\times burn rate consuming 2% of monthly budget, and 3-day lookback at 1×1\times burn rate).
Multi-window alerting ensures fast alerts during catastrophic outages while avoiding noise for transient minor glitches.
3
Integrate error budget policy with CI/CD deployment pipelines
Automated deployment freezes occur when burn rate thresholds are exceeded, reserving remaining budget for operational stability.
Aligns development velocity directly with reliability metrics as mandated by SRE error budget policies.

Key Concept

Multi-window multi-burn-rate alerting and error budget governance
Estimated Time:3m 0s
Question 1392Question →

An enterprise application hosted in a primary Google Cloud region experiences a total regional failure. The cloud operations team must execute the Disaster Recovery (DR) failover runbook to switch service to a warm standby environment in a secondary region. What is the correct chronological sequence of operational steps to safely complete this failover?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: first promote the secondary database replica to primary, second scale up secondary compute capacity, third update Cloud DNS to redirect traffic, and fourth verify application performance and system health.
Executing a disaster recovery failover requires establishing data write availability first, provisioning sufficient compute capacity second, rerouting external traffic third, and finally verifying post-cutover system health.

Step-by-Step Solution

1
Promote cross-region database replica
Database in secondary region becomes writable and ready for application write operations
Application services cannot function correctly without a writable database tier
2
Scale up standby compute instances/clusters
Secondary region compute capacity matches production workload requirements
Prevents immediate compute resource exhaustion when traffic shifts
3
Modify Cloud DNS routing policy to point to secondary load balancer
User network requests begin migrating to the secondary region endpoint
Directs live traffic to the newly prepared secondary environment
4
Execute system health checks and monitoring validation
Confirms application functionality, latency, and error rates remain within SLOs
Validates business continuity execution success

Key Concept

Disaster Recovery Failover Execution Workflow
Question 1393Question →

An e-commerce organization is releasing a major upgrade to its core inventory microservice running on Google Kubernetes Engine (GKE) backed by a Cloud SQL for PostgreSQL database. The release requires a breaking database schema modification alongside application code changes. The architectural goal is to execute a zero-downtime canary deployment using Cloud Service Mesh for traffic management without breaching the service's Error Budget. In what sequence should the cloud team perform these release steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence begins with executing a non-destructive database schema expansion on Cloud SQL. Next, deploy the version 2 inventory microservice to GKE with zero incoming traffic. After staging, update Cloud Service Mesh routing policies to incrementally shift production traffic to version 2 while monitoring Service Level Indicators. Finally, once version 2 is handling 100% of traffic, decommission version 1 GKE pods and apply the database contract migration to remove legacy columns.
Executing a zero-downtime release with breaking database schema changes requires adhering to the Expand-Contract database pattern paired with canary deployment. Expanding the database schema first maintains full backward compatibility for version 1 workloads. Deploying version 2 to GKE allows readiness verification before handling live requests. Incrementally shifting traffic via Cloud Service Mesh ensures continuous observability against SLIs and error budgets. Finally, contracting the database schema and removing version 1 workloads occurs only after version 2 successfully handles 100% of production traffic.

Step-by-Step Solution

1
Execute the database expansion phase by creating new database columns as nullable or assigning default values.
The Cloud SQL database becomes fully compatible with both the legacy (v1) and newly developed (v2) microservice versions.
Prevents SQL runtime exceptions for active v1 pods while preparing the schema for v2 queries.
2
Provision version 2 Deployment resources in the target GKE cluster.
Version 2 pods achieve Ready status and pass health checks, but Cloud Service Mesh keeps their traffic weight at 0%.
Validates application startup and dependency connections safely before exposing the code to live end users.
3
Modify Cloud Service Mesh HTTPRoute weights to gradually adjust traffic percentage from v1 to v2.
Production traffic shifts gradually while operations teams monitor latency, HTTP error rates, and SLO budgets.
Enables early detection of regression bugs in production with instantaneous rollback capability if metrics degrade.
4
Terminate version 1 Deployment workloads in GKE and run DDL scripts to drop obsolete legacy columns from Cloud SQL.
Legacy compute resources are freed and database schema technical debt is cleared.
Contracting schema elements can only happen when no active workload in the architecture depends on legacy column definitions.

Key Concept

Expand-Contract Pattern with Canary Traffic Shifting
Question 1394Question →

A financial platform uses a Warm Standby disaster recovery architecture across two Google Cloud regions: `us-central1` (primary) and `us-east4` (secondary). Database state is continuously synchronized across regions using Cloud Spanner. The application tier runs on Google Kubernetes Engine (GKE) clusters in both regions. The `us-east4` application VPC is peered to a central hub VPC in `us-central1` that hosts core IAM and compliance microservices, while the `us-central1` application VPC is also peered directly to the same hub VPC. During a primary region outage in `us-central1`, the operations team updates Cloud DNS to direct traffic to the `us-east4` external Application Load Balancer and triggers GKE cluster scaling in `us-east4`.

Following the failover, incoming user requests to `us-east4` time out because pods cannot establish connections with the hub VPC microservices. Furthermore, GKE pod scaling stalls due to immediate CPU quota exhaustion in `us-east4`.

Which combination of architectural modifications and failover procedures will correctly eliminate these single points of failure and fulfill a Recovery Time Objective (RTO) of under 15 minutes?

Show answer & explanation

Answer: Deploy redundant compliance microservices in `us-east4` connected directly to the local VPC, eliminate reliance on transitive VPC peering across regions, and establish pre-allocated Compute Engine capacity reservations with pre-approved quota increases in `us-east4`.

Answer

Deploy redundant compliance microservices in the secondary region connected directly to the local VPC to remove transitive VPC peering dependencies, and maintain pre-allocated compute capacity reservations with pre-requested regional quotas.
The correct answer ensures true regional independence by eliminating cross-region dependencies on `us-central1` during a `us-central1` outage. GCP VPC Network Peering is non-transitive, meaning traffic cannot hop across peering connections. Deploying core services locally within `us-east4` removes cross-region bottlenecks. Concurrently, establishing pre-allocated compute capacity reservations and requesting regional resource quotas in advance guarantees that GKE nodes can scale immediately during failover without encountering quota limit errors.

Step-by-Step Solution

1
Analyze network path constraints during regional outage
GCP VPC Network Peering is strictly non-transitive. Traffic from `us-east4` app VPC cannot traverse the `us-central1` hub VPC to reach other peered networks, and relying on `us-central1` infrastructure during a `us-central1` regional outage breaks disaster recovery independence.
Regional failover targets must be self-contained or use high-availability cross-region routing architectures like Cloud Interconnect/Cloud VPN with dedicated regional redundancies.
2
Analyze compute scaling and quota mechanisms during DR execution
Dynamic quota increases take time to be approved by GCP support and cannot be guaranteed during an emergency. Pre-requested quotas and Compute Engine capacity reservations ensure capacity is available in `us-east4`.
Securing resource availability prior to failover is mandatory to prevent startup failures during failover execution.
3
Synthesize optimal BCDR architecture matching RTO < 15 min
Redundant local service deployment in `us-east4` paired with pre-reserved compute capacity meets the RTO target without single-region dependencies.
Eliminating cross-region hard dependencies and pre-provisioning capacity guarantees immediate workload availability.

Key Concept

Disaster Recovery Execution Dependencies and Multi-Region Network non-transitivity
Estimated Time:3m 0s
Question 1395Question →

A digital banking enterprise is designing an automated infrastructure deployment pipeline using Cloud Build and Terraform across multiple Google Cloud projects. The architecture team requires that the pipeline prevents configuration state loss and adheres to strict least-privilege security principles during execution. Which architecture design approach should the team implement?

Show answer & explanation

Answer: Configure Cloud Build to store Terraform state in a Cloud Storage backend with object versioning enabled, and grant the build worker service account the Service Account User role to impersonate a dedicated deployment service account.

Answer

Configure Cloud Build to store Terraform state in a Cloud Storage backend with object versioning enabled, and grant the build worker service account the Service Account User role to impersonate a dedicated deployment service account.
Storing state in a central Cloud Storage bucket with object versioning provides state locking, persistence, and recovery capability. Delegating execution by granting the `roles/iam.serviceAccountUser` role enables service account impersonation of a dedicated, fine-grained deployment service account, ensuring adherence to the principle of least privilege.

Step-by-Step Solution

1
Evaluate state storage requirements for Infrastructure as Code (IaC) in CI/CD pipelines.
Identify that Cloud Storage backends with versioning provide remote locking, persistence, and audit recovery for state files across automated runs.
Ephemeral local storage within build runners is discarded after execution completes.
2
Evaluate access control and service account privileges for pipeline execution.
Determine that the Cloud Build execution runner requires `roles/iam.serviceAccountUser` on a specific deployment service account to impersonate that account during deployment.
Primitive roles like Editor or administrative identities like Service Account Admin grant excessive, high-risk administrative privileges.

Key Concept

Secure CI/CD Pipeline Architecture for Infrastructure as Code
Estimated Time:1m 30s
Question 1396Question →

A digital media publishing enterprise operates its online platform and content delivery pipeline on Google Cloud. The workload consists of steady-state web API services alongside highly variable, unpredictable batch jobs for media encoding. The organization wants to establish central FinOps governance to increase cost transparency and optimize cloud spending across multiple department projects without introducing operational overhead. Which TWO recommendations should the Cloud Architect propose? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Export detailed Cloud Billing data to a centralized BigQuery dataset across the organization and configure Cloud Billing budgets with Pub/Sub notification channels.; Configure Cloud Storage Object Lifecycle Management policies to transition historical media assets to Coldline or Archive storage based on access frequency.

Answer

The Cloud Architect should recommend exporting detailed Cloud Billing data to BigQuery combined with Pub/Sub budget notifications, and implementing Cloud Storage Object Lifecycle Management policies to transition aging media files to lower-cost storage classes.
Centralized BigQuery billing export provides granular, organization-wide visibility required for chargeback and cost analytics, while Cloud Billing budget notifications via Pub/Sub enable programmatic governance. Additionally, Object Lifecycle Management automates moving infrequently accessed objects from Standard storage to cheaper Coldline or Archive storage, directly optimizing persistent storage costs.

Step-by-Step Solution

1
Analyze FinOps governance requirements for billing visibility and alerting across multiple projects.
Identified that organization-level BigQuery billing export enables cross-project cost analysis, and Pub/Sub notifications allow automated responses to budget thresholds.
Centralized visibility and programmatic alerting form the foundation of cloud financial management.
2
Evaluate storage lifecycle strategies for media assets.
Determined that Cloud Storage Object Lifecycle Management rules automatically move older, infrequently accessed media to Coldline/Archive storage.
Automating storage tiering reduces persistent storage unit costs without requiring application code modifications.
3
Identify misaligned cost optimization tactics in distractors.
Rejected standard CUDs for variable batch jobs, GKE cluster overhead for simple stateless APIs, and granting primitive billing roles to project leads.
Bursty workloads benefit from Spot VMs or Flex CUDs, serverless handles stateless microservices efficiently, and IAM roles must follow fine-grained least privilege principles.

Key Concept

FinOps Cost Governance and Lifecycle Optimization
Question 1397Question →

A renewable energy grid platform provisions its multi-project Google Cloud environment using Terraform managed through an automated continuous integration pipeline. During an unannounced operational incident, an on-call engineer manually altered a Cloud Storage telemetry bucket retention policy and added a Compute Engine VPC firewall rule via the Google Cloud Console. The Cloud Architecture team needs to reconcile this out-of-band infrastructure drift, align the codebase with the actual environment, and prevent future manual drift while preserving state concurrency and security best practices. Which approach should the team take?

Show answer & explanation

Answer: Run `terraform plan` to analyze the drift, update the Terraform configuration files to incorporate the required changes (or reject unintended modifications), and execute `terraform apply` through the automated pipeline using a dedicated service account configured with Workload Identity Federation and least-privilege IAM roles against a Cloud Storage state backend with object versioning and state locking enabled.

Answer

Run `terraform plan` to identify configuration drift, update the declarative configuration files to reflect the intended state, and execute `terraform apply` via a CI/CD pipeline using Workload Identity Federation with least-privilege IAM roles against a Cloud Storage backend configured with versioning and state locking.
The correct approach enforces Infrastructure as Code (IaC) governance by using `terraform plan` to detect infrastructure drift, updating the HCL code repository to re-establish a single source of truth, and executing deployments strictly through automated CI/CD pipelines. Authenticating via Workload Identity Federation avoids long-lived service account keys, using least-privilege IAM roles minimizes security exposure, and leveraging Cloud Storage with state locking and versioning guarantees state integrity and concurrency protection.

Step-by-Step Solution

1
Detect Infrastructure Drift
Execute `terraform plan` in the pipeline to compare the real-world infrastructure state against the declarative HCL configuration and identify out-of-band changes.
Declarative IaC workflows require identifying discrepancies between live cloud resources and the state file before taking corrective action.
2
Reconcile Configuration Code
Update the Terraform HCL codebase to include valid manual emergency fixes (e.g., updated bucket retention rules) or adjust code to safely delete unauthorized additions upon apply.
The version-controlled repository must remain the single source of truth for all cloud infrastructure definitions.
3
Enforce Pipeline Governance & State Locking
Apply updates exclusively via CI/CD using short-lived Workload Identity Federation tokens and fine-grained IAM roles, storing remote state in Cloud Storage with state locking and object versioning.
Prevents concurrency conflicts, state corruption, and security risks associated with primitive IAM permissions or manual console modifications.

Key Concept

IaC Drift Detection, Remote State Management, and CI/CD Governance
Question 1398Question →

An organization is executing a disaster recovery (DR) test to validate hybrid failover from their on-premises data center to a secondary Google Cloud Virtual Private Cloud (VPC-B). The on-premises environment connects directly to VPC-A using Cloud VPN, while VPC-A is connected to VPC-B using VPC Network Peering. During the DR test, on-premises workloads fail to reach resources in VPC-B. Which action should the cloud architect take to establish connectivity for the DR failover scenario?

Show answer & explanation

Answer: Deploy a direct hybrid connection such as Cloud VPN between the on-premises network and VPC-B, because VPC Network Peering does not support transitive routing.

Answer

Deploy a direct hybrid connection such as Cloud VPN between the on-premises network and VPC-B, because VPC Network Peering does not support transitive routing.
VPC Network Peering does not support transitive routing. Traffic originating on-premises over Cloud VPN entering VPC-A cannot traverse VPC Peering to reach VPC-B. Establishing direct VPN connectivity to VPC-B provides the necessary network pathway for disaster recovery execution.

Step-by-Step Solution

1
Identify the network topology constraint causing traffic failure during DR execution.
Recognize that VPC-A acts as an attempted transit network between on-premises Cloud VPN and peered VPC-B.
Google Cloud VPC Network Peering strictly enforces non-transitivity, preventing external traffic from traversing peered VPCs.
2
Select the appropriate hybrid network topology modification for disaster recovery connectivity.
Determine that a direct connection (such as Cloud VPN or Network Connectivity Center hub/spoke) must connect the on-premises router directly to VPC-B.
Direct hybrid connectivity ensures routes are advertised directly into the target DR VPC network.

Key Concept

VPC Network Peering Non-Transitivity in Disaster Recovery
Question 1399Question →

An operations team plans to perform a rolling update on a Compute Engine Managed Instance Group (MIG) serving a critical production application. The deployment configuration relies on creating additional temporary VM instances to maintain full service capacity during the rollout. Which pre-deployment step is essential to ensure the rolling update completes successfully without provisioning failures?

Show answer & explanation

Answer: Verify and request sufficient regional Compute Engine resource quotas in advance to handle the temporary surge in VM instances during the update.

Answer

Verify and request sufficient regional Compute Engine resource quotas in advance to handle the temporary surge in VM instances during the update.
Verifying and requesting sufficient regional Compute Engine resource quotas ensures that the extra VM instances required for max surge capacity during a rolling update can be provisioned without hitting project quota caps.

Step-by-Step Solution

1
Analyze the deployment strategy requirements.
Rolling updates in Compute Engine MIGs configured with max surge temporarily increase the total number of running VM instances beyond normal operating capacity.
Temporary replacement instances are created before old instances are taken offline to guarantee zero downtime.
2
Identify potential operational bottlenecks prior to execution.
If the required temporary instances exceed the project's regional CPU or instance quotas, GCP will fail to provision the new VMs.
Resource quotas are enforced at the GCP infrastructure layer and must be increased proactively.
3
Select the correct preventative strategy.
Checking and requesting regional quota increases prior to starting the release avoids deployment failure.
Quota limits cannot be bypassed dynamically by IAM permissions or pipeline automation.

Key Concept

Pre-deployment Quota Verification for Rolling Updates
Question 1400Question →

A global logistics enterprise provisions its multi-project Google Cloud environment using Terraform managed through an automated external CI/CD pipeline. Security policy strictly forbids generating and storing long-lived service account JSON keys in CI/CD secrets. Additionally, operational guidelines mandate that Terraform state files are fully protected against concurrent pipeline execution conflicts and that previous state versions are preserved for recovery in case of state corruption. Which implementation strategy meets all security and operational requirements?

Show answer & explanation

Answer: Authenticate the CI/CD pipeline using Workload Identity Federation to impersonate a fine-grained service account, and store the state file in a Google Cloud Storage bucket with Object Versioning enabled using the native GCS backend.

Answer

Authenticate the CI/CD pipeline using Workload Identity Federation to impersonate a fine-grained service account, and store the state file in a Google Cloud Storage bucket with Object Versioning enabled using the native GCS backend.
Workload Identity Federation allows external CI/CD workloads to impersonate GCP service accounts securely using short-lived tokens, fulfilling keyless security requirements. Cloud Storage (GCS) backend provides native state locking to prevent concurrent modifications and Object Versioning preserves historical state revisions for disaster recovery.

Step-by-Step Solution

1
Configure Workload Identity Federation on Google Cloud to map external CI/CD identity tokens to Google Cloud IAM service account identities.
Pipeline authenticates securely without storing long-lived service account JSON keys.
Meets enterprise security compliance for keyless authentication.
2
Configure the Terraform backend block to use the 'gcs' backend referencing a central Cloud Storage bucket.
Terraform state locks are managed natively via Cloud Storage object locking during execution.
Prevents race conditions and state corruption during concurrent pipeline runs.
3
Enable Object Versioning on the target Cloud Storage state bucket.
Historical state files are archived on every state file update.
Ensures state history is preserved for recovery in case of accidental state deletion or invalid state modifications.

Key Concept

Keyless authentication with Workload Identity Federation and GCS remote backend state locking/versioning
PreviousPage 70 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin