Examkin

Ensuring Reliability of Operations

192 questions

All types192Multiple choice99Multiple select57Numeric8Ordering28
Question 1Question →

A digital banking organization operates a hybrid event-driven microservices platform across Google Kubernetes Engine (GKE) and Cloud Functions. The cloud operations team must establish an end-to-end observability and telemetry architecture to trace multi-service payment transactions in real time, aggregate critical logs, and protect against loss of high-severity application errors while managing costs. Which TWO architectural decisions should the cloud architect implement to fulfill these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Instrument microservices using OpenTelemetry SDKs to propagate trace context across GKE pods and Cloud Functions, exporting trace spans directly to Cloud Trace.; Establish folder-level Log Router sinks with explicit inclusion filters to continuously stream high-priority application telemetry and error logs to Pub/Sub and BigQuery.

Answer

The optimal solution combines OpenTelemetry context propagation to Cloud Trace for distributed transaction tracing across GKE and Cloud Functions, along with folder-level Log Router sinks using explicit inclusion filters to route critical log entries to BigQuery and Pub/Sub.
Implementing OpenTelemetry SDKs ensures trace context is seamlessly passed between GKE microservices and Cloud Functions, enabling Cloud Trace to map end-to-end request latency. Combining this with folder-level Log Router sinks using explicit inclusion filters allows the organization to reliably capture high-severity operational logs into BigQuery and Pub/Sub for auditing and real-time alerts.

Step-by-Step Solution

1
Analyze trace propagation requirements for multi-service environments
Identify OpenTelemetry as the GCP-recommended open standard for distributed context propagation across GKE and serverless platforms to enable end-to-end latency analysis in Cloud Trace.
Tracing asynchronous calls across GKE microservices and serverless Cloud Functions requires standardized context propagation headers.
2
Design central log aggregation and routing rules
Configure folder-level Log Router sinks using targeted inclusion filters rather than broad exclusion filters.
Inclusion filters guarantee that critical and error severity logs are reliably captured into analytical sinks like BigQuery without accidental dropped logs.

Key Concept

Unified Google Cloud Observability integration through OpenTelemetry distributed tracing and structured Log Router ingestion filtering.
Question 2Question →

An enterprise e-commerce platform hosts its core transaction services on Google Cloud Compute Engine instances and Cloud Run services. The cloud operations team notices escalating Google Cloud Logging ingestion costs driven by high-volume informational and debug logs. During a recent system outage, post-incident analysis revealed that critical error logs were missing because a broad exclusion filter was applied across all log entries. The lead cloud architect must reduce logging ingestion costs while ensuring that all high-severity error logs are retained in Cloud Logging for real-time operational alerting, and audit logs are archived to Cloud Storage for compliance. Which configuration strategy should the architect implement?

Show answer & explanation

Answer: Configure an exclusion filter on the _Default log bucket sink with the expression 'severity < ERROR' to exclude low-severity logs from ingestion into Cloud Logging, and create a separate log sink to export audit logs to Cloud Storage.

Answer

The architect should configure an exclusion filter on the _Default log bucket sink with the filter expression 'severity < ERROR' to prevent low-severity logs from being ingested into Cloud Logging, while maintaining a dedicated sink for exporting audit logs to Cloud Storage.
Configuring an exclusion filter on the _Default sink with 'severity < ERROR' prevents low-severity logs (DEBUG, INFO, NOTICE) from being ingested into the log bucket, directly addressing high storage costs. Because the filter only excludes logs below ERROR severity, all high-severity logs (ERROR, CRITICAL, ALERT, EMERGENCY) are retained for real-time observability and incident response. Creating a separate sink for Cloud Storage ensures compliance log retention goals are met independently.

Step-by-Step Solution

1
Analyze the logging requirements and cost drivers.
Informational and debug logs (severity below ERROR) drive up Cloud Logging ingestion costs, whereas logs with severity ERROR or higher are required for operational alerting.
Cloud Logging charges based on the volume of logs ingested into log buckets.
2
Determine the correct Cloud Logging exclusion filter logic.
Using 'severity < ERROR' as an exclusion filter on the _Default sink drops DEBUG, INFO, and NOTICE logs before ingestion, while allowing ERROR, CRITICAL, ALERT, and EMERGENCY logs to be stored in the bucket.
Exclusion filters prevent matching log entries from being ingested into specific sinks/buckets, directly controlling storage and ingestion costs.
3
Configure compliance routing for audit logs.
A dedicated log sink routes audit logs directly to Cloud Storage independently of log bucket exclusion filters.
Log Router sinks evaluate incoming logs prior to bucket ingestion, allowing parallel exports to Cloud Storage targets for long-term retention.

Key Concept

Cloud Logging Log Router Exclusion Filters and Sink Routing
Question 3Question →

An enterprise operations team needs to establish a centralized observability strategy across multiple Google Cloud projects. They must securely aggregate Cloud Audit Logs into BigQuery for security analytics while ensuring key operational alerts are triggered without exposing telemetry data to exfiltration risks. Which TWO configurations should the team implement to achieve these observability requirements?

Select all that apply

Show answer & explanation

Answer: Configure an aggregated Log Router sink at the organization level with a BigQuery dataset destination and a filter targeting Cloud Audit Logs.; Grant fine-grained predefined roles such as Logging Admin and Monitoring Notification Channel Editor to operational service accounts instead of primitive roles.

Answer

The team should configure an aggregated Log Router sink at the organization level targeting BigQuery for audit logs and grant fine-grained predefined IAM roles to operational service accounts.
Configuring an aggregated Log Router sink at the organization level allows central streaming of Cloud Audit Logs to BigQuery across all constituent projects. Complementing this with fine-grained predefined IAM roles ensures service accounts possess only necessary permissions for operational monitoring and log routing without over-privilege.

Step-by-Step Solution

1
Identify the proper GCP observability feature for centralized log aggregation across multi-project organizations.
An organization-level aggregated Log Router sink configured with a BigQuery destination and appropriate log filtering meets audit logging and analytical querying requirements efficiently.
Aggregated sinks collect log entries from child projects centrally without requiring manual per-project sink setup.
2
Select the appropriate access management posture for operational logging and monitoring service accounts.
Assign predefined, minimal-permission roles such as Logging Admin and Monitoring Notification Channel Editor.
Predefined roles align with IAM best practices by avoiding over-privileged primitive roles while enabling complete monitoring automation.

Key Concept

Centralized Log Aggregation and Observability IAM Least Privilege
Question 4Question →

A online gaming studio runs its real-time multiplayer backend in region `us-west1` (primary) and maintains a pilot light disaster recovery (DR) setup in region `us-east1`. During a simulated regional disaster recovery test, the team successfully promotes the cross-region database replica in `us-east1`. However, when the automated scaling scripts attempt to rapidly scale up the Managed Instance Groups (MIGs) in `us-east1` to handle the full production load, instance creation fails due to exceeding regional CPU limits (`QUOTA_EXCEEDED`). Which operational measure should the cloud architect implement to ensure reliable business continuity and failover execution?

Show answer & explanation

Answer: Proactively request and maintain sufficient compute resource quotas in the secondary region (`us-east1`) to cover full production capacity prior to initiating any DR failover.

Answer

Proactively request and maintain sufficient compute resource quotas in the secondary region (`us-east1`) to cover full production capacity prior to initiating any DR failover.
Ensuring operational reliability during a Disaster Recovery (DR) failover requires proactive capacity and quota planning. Because GCP quotas are enforced independently per region and project, a warm standby or pilot light architecture will fail to scale during a regional outage if the secondary region's compute quota is insufficient. Securing compute quota limits in advance ensures that scaling scripts can launch required instances immediately without encountering `QUOTA_EXCEEDED` errors.

Step-by-Step Solution

1
Identify the root cause of the DR failover failure.
The failover failed because the target DR region (`us-east1`) did not have adequate compute CPU quota requested in advance to accommodate full production instance scaling.
GCP enforces resource quotas on a per-region, per-project basis independently of active production workloads.
2
Evaluate operational requirements for disaster recovery execution.
To achieve target RTO during a pilot light failover, compute resources must be able to scale up instantly without reaching administrative quota caps.
Quota increases require evaluation and cannot be relied upon in real time during an active regional incident.
3
Select the correct mitigation practice.
Request regional quota increases in advance so that the target DR region's quota limits accommodate peak production capacity.
Pre-approved quota ensures seamless compute expansion during DR execution.

Key Concept

Disaster Recovery Quota Planning and Execution Reliability
Question 5Question →

A digital healthcare company runs patient telemetry and microservice workloads across Google Kubernetes Engine (GKE) clusters and on-premises infrastructure. The enterprise operations team needs to establish a centralized observability architecture. Requirements dictate that all administrative audit logs and application error events must be securely routed to a BigQuery dataset located in a dedicated compliance project for long-term retention. Additionally, operational metrics must stream into Cloud Monitoring, and non-essential debug logs must be filtered out without inadvertently dropping high-severity error events or audit records. Which architecture best meets these business and operational requirements following Google Cloud recommended practices?

Show answer & explanation

Answer: Deploy OpenTelemetry Collectors using standard Cloud Logging and Cloud Monitoring exporters. Configure an Organization-level Log Router aggregated sink with explicit inclusion filters targeting the compliance BigQuery dataset, while defining exclusion filters scoped strictly to low-severity debug logs.

Answer

Deploy OpenTelemetry Collectors using standard Cloud Logging and Cloud Monitoring exporters. Configure an Organization-level Log Router aggregated sink with explicit inclusion filters targeting the compliance BigQuery dataset, while defining exclusion filters scoped strictly to low-severity debug logs.
The solution using OpenTelemetry Collectors with standard exporters alongside an Organization-level Log Router aggregated sink ensures centralized compliance export to BigQuery while precisely filtering only low-severity debug logs to control costs without losing vital operational or audit data.

Step-by-Step Solution

1
Analyze observability and telemetry ingestion requirements
Identify that metrics require Cloud Monitoring integration while audit logs and errors require central BigQuery long-term retention.
Different operational telemetry types require distinct destination pipelines for monitoring vs compliance storage.
2
Evaluate central log routing and cost management strategies
Configure Organization-level Log Router aggregated sinks to centralize logs into BigQuery while restricting exclusion filters to debug logs.
Overbroad exclusion filters risk dropping high-severity error and audit logs needed for compliance and incident response.
3
Apply security and identity best practices
Avoid primitive IAM roles and rely on security perimeters combined with fine-grained IAM roles for audit data protection.
Primitive roles grant excessive privileges, and IAM alone cannot guarantee exfiltration protection without VPC Service Controls.

Key Concept

Centralized Log Routing, Observability Integration, and Cost Optimization Guardrails
Estimated Time:2m 0s
Question 6Question →

An enterprise Site Reliability Engineering (SRE) team is implementing an automated incident response and notification suppression pipeline on Google Cloud for a mission-critical financial settlement service. The pipeline must detect SLO degradation, prevent alert storms during active outages, execute automated self-healing without relying on long-lived service account keys or primitive IAM roles, and archive operational telemetry for post-mortems. In what chronological sequence should the SRE team structure the operational steps for this automated incident lifecycle?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with configuring multi-window multi-burn-rate SLO alerting, followed by publishing incident payloads to Pub/Sub while enabling Cloud Monitoring Muting Rules, invoking a Workload Identity-authenticated Cloud Run remediation handler for diagnostic log extraction, executing targeted recovery using granular IAM roles, and concluding with metric stabilization verification, un-muting alerts, and exporting incident telemetry to BigQuery.
The proper operational order reflects Google Cloud SRE best practices: (1) Detection using multi-window multi-burn-rate SLO alerts ensures precise identification of error budget depletion; (2) Event decoupling via Pub/Sub paired with Cloud Monitoring Muting Rules prevents alert storms during active mitigation; (3) Automated triage workers leverage Workload Identity to inspect correlation logs securely; (4) Targeted remediation executes using least-privilege IAM roles; and (5) Metrics are verified for recovery before resolving the incident, removing muting rules, and streaming telemetry to BigQuery for post-mortem analysis.

Step-by-Step Solution

1
Detect error budget depletion via Cloud Monitoring multi-window multi-burn-rate alerting policies.
High-fidelity incident alert triggers upon identifying sustained consumption of the service error budget.
SLO multi-burn-rate logic prevents false positives and detects rapidly evolving outages as the initial entry point of the incident lifecycle.
2
Publish alert event to Cloud Pub/Sub and enable Cloud Monitoring Muting Rules.
Incident event dispatches to automated pipelines while downstream notification channels are suppressed.
Alert suppression prevents alert fatigue and notification storms across operations teams while automated remediation is underway.
3
Trigger Cloud Run triage container using Workload Identity federation to inspect Cloud Logging traces.
Diagnostic context is securely fetched without static service account keys or primitive roles.
Automated handlers must query log correlation IDs to confirm failure modes prior to executing stateful remediation actions.
4
Perform infrastructure mitigation using least-privilege IAM service account permissions.
Service baseline health is restored via automated traffic re-routing or canary rollback.
Remediation acts on confirmed telemetry to stabilize the application layer.
5
Verify metric stabilization in Cloud Monitoring, lift muting rules, and stream incident telemetry to BigQuery.
The incident state automatically resolves and historical telemetry is stored for SRE post-mortems.
Formal incident closure requires verifying recovery in Monitoring baselines before resetting alert mutes and capturing post-mortem data.

Key Concept

End-to-end GCP incident management lifecycle using SLO multi-burn-rate alerting, Pub/Sub orchestration, Muting Rules for alert fatigue mitigation, Workload Identity security, and post-incident analytics.
Estimated Time:3m 0s
Question 7Question →

An enterprise financial platform hosts a high-throughput transaction processing API on Cloud Run backed by Cloud Spanner. The business alignment requires maintaining a rolling 30-day Service Level Objective (SLO) of 99.9% successful HTTP requests, while enabling feature teams to maintain rapid deployment velocity. The Site Reliability Engineering (SRE) team needs to establish an automated alerting strategy in Google Cloud Monitoring that minimizes alert fatigue from brief transient spikes while ensuring immediate paging for major outages that threaten the monthly error budget. Which alerting implementation should you configure?

Show answer & explanation

Answer: Configure multi-window, multi-threshold burn-rate alerts that page on-call engineers when consuming a significant percentage of the error budget over short lookback windows (such as 2% over 1 hour) and create ticket alerts for sustained lower burn rates over longer windows (such as 5% over 6 hours).

Answer

The SRE team should implement multi-window, multi-threshold burn-rate alerts based on error budget consumption rates.
Multi-window, multi-threshold burn rate alerting consumes metrics from Cloud Monitoring to calculate the exact speed at which the 30-day error budget is being depleted. By configuring a high burn rate threshold over a short window (e.g., 2% budget consumed in 1 hour, representing a 14.4x burn rate) for paging alerts, and a lower burn rate threshold over a longer window for ticket creation, the system balances rapid emergency incident response with protection against alert fatigue.

Step-by-Step Solution

1
Define the Service Level Indicator (SLI) and Service Level Objective (SLO)
The SLI is the ratio of successful HTTP requests to total requests, and the SLO is set to 99.9% over a 30-day rolling window, yielding an allowable error budget of 0.1%.
Establishing explicit measurement metrics and error budgets provides the foundation for alerting logic.
2
Evaluate alerting methods against alert fatigue and responsiveness trade-offs
Static threshold alerts fire on minor transient events, whereas error budget burn-rate alerts quantify the urgency based on how fast the error budget is being consumed relative to time.
Burn rate monitoring protects deployment velocity and engineer focus by filtering non-critical incidents.
3
Configure multi-window multi-threshold alert policies in Cloud Monitoring
Short lookback windows with high burn rate thresholds catch severe outages immediately, while long lookback windows with lower burn rate thresholds capture persistent, slow budget leaks.
Combining short and long lookback windows eliminates alert reset delays and prevents missed incidents.

Key Concept

Error Budget Burn Rate Alerting in Google Cloud SRE Practices
Estimated Time:3m 0s
Question 8Question →

A financial services organization runs a mission-critical payment processing workload on Google Cloud. To improve operational reliability and incident response, the SRE team needs to implement an automated alerting and self-healing incident management architecture. The solution must fulfill two requirements:
1. Alert the SRE team based on consumed service level objective (SLO) error budget rates to catch both rapid budget exhaustion and slow, persistent errors without triggering false positives from brief transient spikes.
2. Automatically trigger downstream remediation workflows securely during severe incidents without violating least-privilege principles.

Which TWO actions should the SRE team take to achieve these objectives?

Select all that apply

Show answer & explanation

Answer: Create Cloud Monitoring alerting policies utilizing multi-window multi-burn-rate conditions targeting the payment service SLO.; Configure Cloud Monitoring notification channels to publish alert events to a Cloud Pub/Sub topic that triggers a Cloud Function operating with fine-grained, minimal IAM roles.

Answer

The SRE team should implement multi-window multi-burn-rate alerting policies targeting the service SLO and route alert notifications to Cloud Pub/Sub to trigger a Cloud Function using fine-grained, minimal IAM roles.
The correct architecture uses multi-window multi-burn-rate alerting policies to monitor SLO error budget consumption accurately without alert fatigue, combined with Cloud Pub/Sub and Cloud Functions running under custom, least-privilege service accounts to execute automated self-healing workflows securely.

Step-by-Step Solution

1
Select alerting mechanism for SLO error budget management
Identify multi-window multi-burn-rate conditions in Cloud Monitoring as the recommended GCP standard for monitoring SLO budget consumption accurately.
Static threshold alerts cause alert fatigue or miss slow budget erosion, whereas multi-burn-rate monitoring prevents false positives and ensures timely alerts.
2
Select secure automated remediation mechanism
Publish Cloud Monitoring alert notifications to Pub/Sub to trigger Cloud Functions running under dedicated service accounts with least-privilege roles.
Decoupling automated incident remediation through Pub/Sub and Cloud Functions ensures reliable execution, and using minimal IAM permissions satisfies security standards.

Key Concept

Incident Management and Automated Alerting via SLO Burn Rates and Pub/Sub Remediation Workflows
Question 9Question →

A global gaming platform deployed on Google Cloud experiences periodic database latency spikes. These spikes cause temporary downstream HTTP 500 error bursts across Compute Engine backend instance groups. During these incidents, Cloud Monitoring generates hundreds of redundant notification emails per minute, causing severe alert fatigue. Furthermore, automated remediation scripts triggered directly by raw error thresholds attempt to reboot instance group VMs, leading to prolonged service degradation because load balancer health checks are configured to execute deep database queries. Which incident management and automated alerting architecture should you implement to eliminate alert storms and prevent cascading service outages during transient database latency?

Show answer & explanation

Answer: Transition alerting policies to multi-window burn rate conditions based on latency and error rate Service Level Indicators (SLIs), route alert notifications through Cloud Pub/Sub to trigger a Cloud Run remediation service that dynamically applies alerting silences during active incidents, and update backend load balancer health checks to query shallow HTTP health endpoints.

Answer

Implement multi-window error budget burn rate alerting policies paired with Cloud Pub/Sub and Cloud Run for automated incident muting, and switch load balancer health checks to shallow local endpoints.
The solution addresses both root causes: using multi-window SLO burn rate alerting prevents alert storms caused by transient spikes, while decoupling backend health checks (using shallow local endpoints) prevents load balancers from tearing down healthy compute nodes when downstream databases experience transient latency. Automated event handling via Pub/Sub and Cloud Run enables controlled alert suppression and remediation.

Step-by-Step Solution

1
Redesign alerting logic using Service Level Objectives (SLOs) and multi-window burn rate alerts in Cloud Monitoring.
Alerts trigger only when error budget consumption threatens the monthly target, eliminating alert storms from short transient spikes.
Multi-window burn rate alerting correlates short-term and long-term consumption windows to prevent false positives while remaining responsive to major outages.
2
Decouple health check probes from downstream backend dependencies.
Load balancers inspect shallow HTTP endpoints (e.g., local application process status) instead of executing deep database queries.
Deep dependency health checks cause load balancers to falsely mark instances as dead during transient database slowdowns, triggering cascading instance failures.
3
Automate incident notification routing and silence management via Cloud Pub/Sub and Cloud Run.
Notifications publish to Pub/Sub topics, triggering Cloud Run services that suppress duplicate alerts during active incidents.
Programmatic incident handling via Cloud Pub/Sub avoids uncoordinated script execution and prevents alert fatigue.

Key Concept

Multi-window SLO burn rate alerting and decoupled shallow health checking in enterprise GCP incident response.
Question 10Question →

An enterprise organization is updating its release management pipeline for a mission-critical web application hosted on Google Cloud. The architecture uses Google Kubernetes Engine (GKE) for compute services and Cloud Spanner for backend database operations. The organization plans to implement automated canary deployments using Cloud Deploy and Service Directory, with automated traffic shifting based on real-time Cloud Monitoring error budget burn-rate metrics. To maintain high availability during releases and prevent operational failures, which TWO architectural practices must be incorporated into the deployment pipeline? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Structure database schema updates to be strictly backward-compatible with previous application versions prior to initiating canary traffic shifts.; Maintain all Terraform deployment pipeline state files in a versioned Cloud Storage backend with object locking enabled.

Answer

The deployment strategy requires implementing backward-compatible database schemas before canary traffic splitting and maintaining IaC deployment state in versioned Cloud Storage buckets with locking enabled.
Safe canary releases require that both old and new code versions can run concurrently against shared backing stores; therefore, database schema changes must be backward-compatible (e.g., expand-contract pattern). Furthermore, reliable automated infrastructure delivery requires state files stored securely in remote versioned storage with locking mechanics to ensure deployment pipeline integrity.

Step-by-Step Solution

1
Analyze database dependency requirements during canary traffic splitting.
Identified that both old and new container versions must run simultaneously against the shared database.
Non-backward-compatible schema migrations will cause immediate failures for requests routed to the baseline version during a canary roll-out.
2
Evaluate Infrastructure as Code state management for automated deployment pipelines.
Determined that concurrent CI/CD pipeline executions risk state locking conflicts and state corruption.
Centralized Cloud Storage backends with versioning and state locking guarantee atomic state updates across pipeline runs.
3
Evaluate distractor configurations against GCP architecture anti-patterns.
Eliminated options advocating primitive IAM role assignment, deep dependency health check probes, and per-build cluster provisioning.
These represent security risk, operational instability, and unnecessary compute overhead respectively.

Key Concept

Release Management Reliability and Zero-Downtime Deployment Strategies
Question 11Question →

A financial platform hosts stateless microservices on Cloud Run connected to a Cloud SQL for PostgreSQL instance. The application team plans to release a major update that requires a breaking database schema change, specifically renaming a critical column and changing its data type. The team must execute a zero-downtime canary deployment using Cloud Run traffic splitting, while maintaining the ability to instantly roll back traffic to the previous application revision without causing runtime errors or data corruption for users on either revision. Which release management strategy should you implement?

Show answer & explanation

Answer: Implement an expand-contract database migration pattern by adding the new column alongside the existing column, deploying the new Cloud Run revision using gradual traffic splitting, and removing the legacy column only after the new revision is fully deployed and verified.

Answer

Implement an expand-contract database migration pattern by adding the new column alongside the existing column, deploying the new Cloud Run revision using gradual traffic splitting, and removing the legacy column only after the new revision is fully deployed and verified.
The correct strategy uses an expand-contract (also known as parallel run) database migration pattern. In canary deployments or blue-green releases, multiple application revisions run concurrently against the same database backend. To prevent runtime errors and ensure instant rollback capability, database schema changes must be non-breaking and backward-compatible. Adding the new column while writing to both columns ensures that the old application version continues working seamlessly alongside the canary version.

Step-by-Step Solution

1
Analyze deployment constraints
Identified the need for zero-downtime canary deployment with simultaneous operation of old and new application revisions against a shared database.
Canary deployments shift traffic incrementally, meaning both application versions must query the database at the same time.
2
Evaluate database schema compatibility strategy
Adopt the expand-contract (parallel run) pattern.
Breaking schema changes must be decoupled into multi-phase additive changes so legacy application instances do not fail when querying missing columns.
3
Design canary release lifecycle
Phase 1: Expand database with new column/dual-write capability. Phase 2: Deploy new Cloud Run revision and split traffic. Phase 3: Contract database by removing legacy column after full rollout.
Ensures full rollback capability at any stage during traffic migration without service downtime or query errors.

Key Concept

Decoupling Database Schema Migrations from Application Deployments (Expand-Contract Pattern)
Estimated Time:3m 0s
Question 12Question →

An enterprise organization operates a multi-tenant payment platform across dozens of Google Cloud projects. To satisfy strict security compliance and operational requirements, high-severity application errors and audit logs across all projects must be aggregated into a centralized BigQuery dataset managed by the Security Operations team. However, high log generation rates from non-production diagnostic logging threaten to cause excessive Cloud Logging ingestion and storage costs. Which log routing and governance architecture should the Lead Cloud Architect implement?

Show answer & explanation

Answer: Create an aggregated Log Router sink at the organization folder level using an inclusion filter that selects audit logs and entries with severity equal to or greater than ERROR, routing to the central BigQuery dataset, while applying exclusion filters in non-production projects targeting only diagnostic logs with severity less than ERROR.

Answer

Implement an organization-level aggregated Log Router sink configured with explicit inclusion filters for audit logs and error severity (severity >= ERROR), while using exclusion filters in non-production projects strictly for low-severity diagnostic logs (severity < ERROR).
Creating an aggregated Log Router sink at the organization or folder level ensures centralized compliance and operational log aggregation into BigQuery across all project environments. Configuring inclusion filters for audit logs and high severity levels (severity >= ERROR) combined with non-production exclusion filters for lower severity levels (severity < ERROR) successfully reduces storage costs without discarding critical incident diagnostic data.

Step-by-Step Solution

1
Evaluate central governance requirements for multi-project log aggregation.
Using an organization-level aggregated sink enables central collection of compliance audit logs and critical application errors across all current and future projects.
Centralizing log router sinks at the folder or organization root avoids administrative drift and missing logs from newly created projects.
2
Determine the appropriate inclusion and exclusion filter configuration to manage costs without losing vital operational metrics.
Set inclusion filters for `severity >= ERROR` and audit logs, while filtering out verbose info/debug logs (`severity < ERROR`) at non-production sources.
Excluding debug/info logs reduces Cloud Logging ingestion fees while guaranteeing that high-severity operational events remain fully visible.
3
Verify security and least-privilege role requirements for log export service accounts.
Ensure sink service accounts are granted fine-grained destination roles (e.g., BigQuery Data Editor) rather than primitive roles, and protect sensitive storage locations using VPC Service Controls.
Adheres to security best practices for least privilege and data exfiltration prevention.

Key Concept

Log Router aggregated sinks and inclusion/exclusion filter strategy for enterprise observability and cost optimization.
Question 13Question →

A multinational logistics company runs workload components across dozens of Google Cloud projects managed under a single Google Cloud Organization. The security operations team requires all Cloud Audit Logs and application error logs from all projects to be centralized in a dedicated compliance Google Cloud project for long-term storage and analysis. Simultaneously, the operations team needs to prevent low-severity debug log ingestion from ballooning operational costs across the organization. Which architectural strategy should a Cloud Architect implement to fulfill these requirements securely and efficiently?

Show answer & explanation

Answer: Create an organization-level aggregated Log Router sink with an inclusion filter selecting Cloud Audit Logs and logs with severity of ERROR or higher, pointing to the central project log bucket, and assign the sink service account the Logs Bucket Writer role on the destination resource.

Answer

Create an organization-level aggregated Log Router sink with an inclusion filter selecting Cloud Audit Logs and logs with severity of ERROR or higher, pointing to the central project log bucket, and assign the sink service account the Logs Bucket Writer role on the destination resource.
Creating an organization-level aggregated Log Router sink enables centralized log aggregation across all existing and future projects within the organization hierarchy. Specifying an inclusion filter for audit logs and error-level messages ensures only required compliance data is routed to the destination project, preventing costs associated with ingesting debug logs. Assigning the specific `roles/logging.bucketWriter` role to the sink service account satisfies security standards through fine-grained identity access.

Step-by-Step Solution

1
Identify the multi-project log aggregation requirement
Recognize that an organization-level aggregated Log Router sink is required to capture log events across all child projects systematically.
Creating sinks individually in dozens of projects creates administrative overhead and operational inconsistency.
2
Define log filtering to balance compliance and cost optimization
Filter for required logs using inclusion criteria (Cloud Audit Logs and severity >= ERROR) to avoid ingesting low-severity debug logs.
Including only required high-value log types at the sink level prevents low-severity logs from being stored in the central project.
3
Establish secure cross-project identity and access management
Grant the aggregated sink's unique service account the predefined `roles/logging.bucketWriter` role on the target central log bucket.
Google Cloud Log Router uses service accounts to write logs across project boundaries securely under least-privilege principles.

Key Concept

Organization-level Aggregated Log Router Sinks and Filtering
Question 14Question →

An enterprise web application deployed across primary region `us-central1` and secondary recovery region `us-east4` experiences a total regional failure in `us-central1`. The application uses a Pilot Light DR pattern comprising a Cloud SQL PostgreSQL cross-region read replica and a minimal regional Managed Instance Group (MIG) in `us-east4`. To achieve recovery without split-brain data corruption or premature exposure of unvalidated endpoints, in what exact sequence should the SRE team execute the disaster recovery failover runbook tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for regional DR failover is: 1) Isolate `us-central1` compute and database write paths to eliminate split-brain risk, 2) Promote the `us-east4` Cloud SQL cross-region read replica to standalone primary, 3) Scale up the `us-east4` Managed Instance Group to full capacity, 4) Execute synthetic health and data integrity checks against the internal `us-east4` endpoint, and 5) Update Global Load Balancer backends to direct ingress traffic to `us-east4`.
In GCP enterprise DR execution, ensuring data consistency and split-brain prevention is the highest priority. The primary degraded region must first be fenced off by revoking write access. Next, the secondary database replica is promoted to primary so that compute nodes have a valid write target. Then, the pilot-light MIG is scaled to full capacity to accommodate production traffic. Next, internal synthetic validation tests verify system readiness. Finally, the Global Load Balancer backend configuration is updated to route public client traffic to the secondary region.

Step-by-Step Solution

1
Isolate the primary region
Primary database and compute components are locked from receiving new writes, preventing data divergence.
Before promoting a secondary database, the primary region must be fenced off so that transient network recoveries do not cause split-brain data writes.
2
Promote the database replica
The Cloud SQL replica in `us-east4` becomes an independent primary database.
Application services cannot process state-changing user transactions until a writeable primary database is established.
3
Scale up compute capacity
The pilot-light MIG expands instances to handle production request volumes.
Compute resources must be provisioned and connected to the newly promoted database before receiving production workload demands.
4
Perform synthetic validation
Smoke tests confirm schema integrity, connection pool behavior, and application startup cleanliness.
Directing live user traffic to an unvalidated secondary stack risks mass request drops or silent application failures.
5
Shift global ingress traffic
The Global External Load Balancer routes user requests to the fully healthy secondary region.
Traffic shifting completes the failover procedure once end-to-end operational readiness is validated.

Key Concept

Disaster Recovery Failover Execution & Split-Brain Prevention
Question 15Question →

An engineering team is configuring an automated CI/CD release pipeline for a web service deployed on Google Cloud Run using Terraform for infrastructure provisioning. The application relies on Cloud SQL for persistent data storage. Which TWO deployment and infrastructure management practices should the team implement to ensure release reliability and zero-downtime deployments?

Select all that apply

Show answer & explanation

Answer: Perform database schema changes using multi-phase, backward-compatible updates before deploying new application code.; Configure Cloud Storage with object versioning as a remote backend for storing Terraform state files.

Answer

The team must perform database schema changes using multi-phase, backward-compatible updates before deploying new application code, and configure Cloud Storage with object versioning as a remote backend for storing Terraform state files.
Safe release management requires that database changes are backward-compatible so that both old and new application instances can run concurrently without errors during traffic migration. Additionally, reliable Infrastructure as Code deployments depend on centralized state management with locking and versioning enabled in Cloud Storage.

Step-by-Step Solution

1
Ensure Database Backward Compatibility
Database schemas support both the active version and the new application version simultaneously.
Prevents live traffic errors and broken queries during canary traffic shifting or blue-green rollouts.
2
Configure Centralized IaC Remote Backend
Terraform state is locked during updates and maintained with full version history.
Prevents state corruption and concurrency conflicts across CI/CD execution runs.

Key Concept

Zero-downtime release management and Infrastructure as Code state management
Question 16Question →

A healthcare enterprise is executing its disaster recovery strategy across Google Cloud regions us-central1 (primary) and us-east4 (secondary). The workload manages critical electronic health records and requires a strict Recovery Point Objective (RPO) of zero and a Recovery Time Objective (RTO) under 1 minute for database failover. Additionally, on-premises hybrid connectivity demands a sustained throughput of 15 Gbps for continuous data synchronization, and isolated spoke VPCs must route failover traffic through a central hub VPC to reach secondary regional services without establishing direct full-mesh peering between every spoke. Which combined Google Cloud architectural strategy meets all operational, performance, and disaster recovery execution requirements?

Show answer & explanation

Answer: Deploy Cloud Spanner using a multi-region instance configuration, provision Dedicated Interconnect for hybrid connectivity, and implement Network Connectivity Center with dynamic BGP routing for hub-and-spoke VPC architecture.

Answer

Deploying Cloud Spanner with multi-region synchronous replication satisfies the zero RPO and sub-minute RTO requirement. Dedicated Interconnect provides the required 15 Gbps hybrid bandwidth, and Network Connectivity Center enables non-transitive network routing limitations of standard VPC peering to be resolved.
The solution combining Cloud Spanner multi-region instance configuration, Dedicated Interconnect, and Network Connectivity Center satisfies all three explicit constraints: Cloud Spanner ensures RPO=0 via multi-region synchronous replication; Dedicated Interconnect reliably handles 15 Gbps hybrid traffic; and Network Connectivity Center enables managed hub-and-spoke routing without violating VPC peering transitivity boundaries.

Step-by-Step Solution

1
Evaluate data persistence requirements against RPO=0 and sub-minute RTO constraints.
Cloud SQL cross-region read replicas use asynchronous replication and manual/scripted promotion, which risks data loss (RPO > 0). Cloud Spanner multi-region configurations synchronously replicate writes across regions, ensuring RPO=0 and rapid automated failover.
Relational databases requiring absolute zero RPO across regions in GCP necessitate multi-region Cloud Spanner.
2
Assess hybrid network bandwidth requirements for 15 Gbps continuous sync.
HA VPN maxes out at 3 Gbps per tunnel (up to 5 Gbps in specific configurations) and requires complex multi-tunnel ECMP management for 15 Gbps. Dedicated Interconnect offers native 10 Gbps or 100 Gbps circuits suitable for high sustained throughput.
Dedicated Interconnect is the appropriate GCP pattern for sustained hybrid traffic above multi-gigabit thresholds.
3
Analyze hub-and-spoke VPC traffic routing constraints.
Standard VPC Network Peering is strictly non-transitive. Traffic cannot pass through a hub VPC to reach external or secondary regional destinations. Using Network Connectivity Center with Cloud Routers provides managed hub-and-spoke routing.
Transitive routing across spoke networks requires managed routing mechanisms such as Network Connectivity Center or VPN/Router appliance overlays.

Key Concept

Multi-region DR Execution with Cloud Spanner, Dedicated Interconnect, and Hub-and-Spoke Networking
Question 17Question →

An enterprise analytics application processes real-time telemetry and is deployed across two Google Cloud regions: `us-central1` (primary) and `us-west1` (secondary). The application uses Google Kubernetes Engine (GKE) clusters in both regions for stateless processing and a multi-region Cloud Bigtable instance for low-latency time-series data storage. A major regional utility failure renders all compute resources in `us-central1` completely unavailable. The disaster recovery plan mandates failing over active operations to `us-west1` with minimal Recovery Time Objective (RTO) while ensuring incoming client traffic is redirected and database operations resume cleanly. Which TWO operational steps must the response team execute to complete the disaster recovery failover?

Select all that apply

Show answer & explanation

Answer: Update the Cloud Bigtable app profile configuration to enforce single-cluster routing pointing to the cluster in `us-west1`.; Update the Cloud DNS failover routing policy or Global External Load Balancer backend service configuration to direct client traffic exclusively to the GKE ingress in `us-west1`.

Answer

To execute disaster recovery failover, the team must update the Cloud Bigtable app profile to direct database requests to the healthy cluster in the secondary region and update Cloud DNS routing or Global Load Balancer backends to direct ingress traffic to the secondary GKE deployment.
During a regional failover, operational execution requires redirecting application traffic to healthy compute infrastructure and ensuring stateful service app profiles or endpoints route requests to active database clusters in the surviving region. Updating Cloud Bigtable app profiles to target the surviving cluster and updating Cloud DNS/Load Balancing endpoints ensures rapid restoration of service with minimal RTO.

Step-by-Step Solution

1
Redirect database traffic at the application layer
Database queries from the secondary region are routed directly to the local, healthy Cloud Bigtable cluster.
Reconfiguring the app profile allows application instances in the surviving region to issue reads and writes against the local Bigtable cluster immediately.
2
Redirect incoming user and ingress traffic to the surviving region
Client traffic bypasses the impacted primary region and routes to the secondary GKE cluster.
Updating Cloud DNS routing policies or global load balancing backend weights ensures all public traffic is served by operational infrastructure.

Key Concept

Disaster Recovery Execution for Replicated Services and Traffic Steering
Question 18Question →

A global supply chain enterprise operates a critical order management platform with a warm standby disaster recovery topology across Google Cloud regions `us-central1` (primary) and `europe-west3` (secondary). The application relies on Cloud SQL for PostgreSQL with asynchronous cross-region read replication. Following an unrecoverable regional disaster in `us-central1`, the operational engineering team must execute the disaster recovery runbook to restore service while ensuring data consistency and preventing split-brain states. In what sequential order should the operational team execute the disaster recovery failover tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by stopping ingress traffic and revoking write permissions on the primary region to prevent split-brain updates. Next, promote the cross-region Cloud SQL read replica in the secondary region to a standalone read-write database instance. Third, scale up the secondary Compute Engine managed instance groups to handle full application load. Fourth, update Cloud DNS routing policies to direct client traffic to the secondary region endpoints. Finally, re-establish disaster recovery redundancy by enabling backup schedules and creating a new cross-region read replica from the newly promoted primary instance.
The correct operational order minimizes data loss and prevents split-brain scenarios. First, isolating the degraded primary stops incoming transactions and lets asynchronous replication finish applying in-flight logs. Second, promoting the database replica enables write capabilities in the secondary region. Third, scaling up compute capacity ensures the secondary application tier can handle the incoming user load. Fourth, modifying DNS records steers user traffic to the active secondary region. Finally, restoring backup schedules and creating a new cross-region replica re-establishes disaster recovery protection.

Step-by-Step Solution

1
Isolate the primary region workload
Prevents split-brain conditions and ensures all in-flight asynchronous database replication logs settle.
Promoting a replica while writes are still hitting the primary can lead to data divergence or corrupted application state.
2
Promote the secondary database replica
The Cloud SQL instance in `europe-west3` becomes a standalone primary database supporting read and write operations.
Application services cannot function properly without a writable persistent storage layer.
3
Provision and scale compute capacity in the secondary region
Compute Engine managed instance groups scale out to 100% target production size.
Ensures the application tier has sufficient resources to process production traffic without failure or severe latency degradation.
4
Redirect traffic via Cloud DNS
Client application traffic flows to the secondary region load balancer.
Traffic must only be routed once the underlying storage and compute layers are fully operational and ready to serve requests.
5
Re-establish disaster recovery redundancy
Automated backups are configured and a new secondary replica is provisioned in a third region or restored environment.
Leaves the enterprise with continuous DR protection following the primary region loss.

Key Concept

Disaster Recovery Failover Sequence and Split-Brain Prevention
Question 19Question →

An enterprise IoT telemetry platform processes high-throughput fleet analytics across Google Cloud. The primary workload runs in `us-central1`, while a secondary disaster recovery environment is staged in `us-east4`. The application tier uses Compute Engine Managed Instance Groups (MIGs) served by a Global External Application Load Balancer, and backend services rely on private inter-VPC communication and dedicated hybrid links to on-premises datacenters. During a complete outage in `us-central1`, the incident response team must execute the disaster recovery failover runbook to restore full operational capacity in `us-east4` within a strict RTO. Which of the following execution steps must the operations team perform to successfully execute this regional failover? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Verify regional compute resource quotas in `us-east4` and request quota increases in advance if required capacity exceeds current limits prior to scaling up target Managed Instance Groups.; Update Cloud DNS routing policies or Load Balancer backend service configurations to direct incoming application traffic exclusively to the healthy MIG backends in `us-east4`.

Answer

The correct execution steps are verifying and securing necessary regional vCPU and resource quotas in the failover region (`us-east4`) prior to scaling up backend workloads, and updating ingress traffic routing (via Cloud DNS policies or Load Balancer backend configurations) to direct application traffic to the active failover infrastructure.
Executing a successful regional disaster recovery failover requires both infrastructure readiness and traffic redirection. First, regional compute resource quotas in the failover region must be verified and expanded in advance so that scaling up Managed Instance Groups does not fail due to API quota limits. Second, once failover instances are active, ingress routing mechanisms such as Global Load Balancer backend service definitions or Cloud DNS failover routing policies must be updated to route live application traffic to the failover region.

Step-by-Step Solution

1
Evaluate Regional Resource Quotas
Ensure target compute capacity in `us-east4` can expand to support full operational load without encountering `QUOTA_EXCEEDED` API errors during MIG scale-up.
Google Cloud quotas are enforced regionally. Attempting a rapid failover scale-up without sufficient quota reserved or pre-approved will cause instance creation failures.
2
Perform Ingress Traffic Cutover
Update Load Balancer backend instance groups or Cloud DNS failover routing records to direct all user requests to the operational MIGs in `us-east4`.
Traffic must be explicitly redirected away from the impacted primary region (`us-central1`) to complete operational recovery.

Key Concept

Disaster Recovery Execution and Regional Failover Validation
Question 20Question →

A financial media company operates a real-time news analytics system hosted in Google Cloud's us-central1 region. The platform processes high-throughput data streams using Compute Engine Managed Instance Groups (MIGs) and stores user subscription profiles in Cloud SQL for PostgreSQL. The company requires a disaster recovery (DR) strategy for an unrecoverable outage in us-central1. The business mandates a Recovery Point Objective (RPO) of near zero (< 1 minute) and a Recovery Time Objective (RTO) under 15 minutes. To minimize idle infrastructure costs, compute resources in the secondary region (us-east4) should only be scaled up during an actual failover execution. Which disaster recovery execution strategy satisfies these requirements?

Show answer & explanation

Answer: Deploy a Pilot Light strategy: maintain cross-region read replicas for Cloud SQL in us-east4, and keep a minimal scaled-down MIG in us-east4; during failover, promote the Cloud SQL replica to primary and autoscaling expands the MIG.

Answer

Deploying a Pilot Light DR pattern with cross-region Cloud SQL read replicas and a minimal scaled-down Compute Engine MIG in the secondary region meets the near-zero RPO and 15-minute RTO requirements while optimizing cost.
The correct strategy combines continuous cross-region database replication (Cloud SQL read replica in us-east4) with a minimal compute footprint (scaled-down MIG). When a failure occurs in the primary region, promoting the database replica and scaling out the MIG fulfills the near-zero RPO and sub-15 minute RTO requirements without paying for full idle compute capacity.

Step-by-Step Solution

1
Evaluate RPO requirements against data replication patterns.
Near-zero RPO (< 1 min) requires continuous data replication. Cloud SQL cross-region read replicas provide continuous asynchronous replication to us-east4.
Backup-and-restore or periodic export dump strategies introduce data loss equal to the backup interval.
2
Evaluate RTO and cost requirements against compute failure strategy.
Keeping a minimal MIG footprint in us-east4 (Pilot Light) ensures rapid capacity expansion within minutes while keeping idle compute cost low.
Provisioning full duplicate infrastructure (Hot Standby) would incur unnecessary idle compute cost, while spinning up from scratch (Cold Standby) risks missing the 15-minute RTO.

Key Concept

Disaster Recovery Patterns (Pilot Light vs Warm/Cold Standby) and RPO/RTO Alignment in GCP
Page 1 / 10Next