Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1041Question →

An enterprise e-commerce platform processes high-volume transaction traffic across Google Kubernetes Engine (GKE) clusters and Compute Engine instance groups. The operations team must design a centralized observability and logging strategy that satisfies three core requirements: route high-volume HTTP 200 OK access logs to Cloud Storage for cost-effective long-term compliance storage, stream application exception logs and high-severity errors to BigQuery for real-time security and operational analytics, and guarantee that no critical system errors or security audit logs are accidentally omitted during ingestion filter tuning. Which architectural design best meets these requirements while preventing operational log loss?

Show answer & explanation

Answer: Configure Log Router sinks with fine-grained inclusion filters that direct audit logs and high-severity errors to BigQuery, while creating a separate Cloud Storage sink with explicit exclusion filters scoped strictly to HTTP 200 OK payload statuses.

Answer

The optimal architecture configures Cloud Logging Log Router sinks with fine-grained inclusion filters to route audit and error logs to BigQuery, alongside a dedicated sink to Cloud Storage using narrow exclusion filters specifically targeted at low-severity HTTP access logs.
Configuring Cloud Logging Log Router sinks with specific inclusion filters for audit and error logs combined with targeted exclusion filters for low-severity HTTP access logs fulfills all analytical and compliance requirements while protecting against accidental loss of operational visibility.

Step-by-Step Solution

1
Analyze logging ingestion and destination requirements
Identified the need for dual export destinations: BigQuery for real-time analytics and Cloud Storage for long-term compliance storage.
Different log types require different retention, query latency, and cost profiles.
2
Evaluate Log Router exclusion and inclusion filter designs
Determined that exclusion filters must be strictly scoped to specific benign payload attributes (such as HTTP 200 status codes).
Overbroad exclusion filters risk dropping critical high-severity application errors or required audit logs.
3
Select the optimal GCP recommended pattern
Leveraged native GCP Log Router sinks with explicit inclusion and narrow exclusion rules.
Provides scalable, managed log routing without security risks or unvalidated log drops.

Key Concept

Cloud Logging Log Router Sinks and Exclusion Filters
Estimated Time:2m 0s
Question 1042Question →

An enterprise organization operates a hybrid microservices platform deployed across Google Kubernetes Engine (GKE) clusters and Cloud Run services in multiple Google Cloud projects. The Reliability and Governance team needs to implement a unified observability and compliance framework. The solution must achieve the following objectives:
1. Aggregate all audit logs and application error logs across all projects into a centralized dataset in BigQuery for long-term compliance retention and analytical querying, while preventing high-volume trace/debug logs from driving up storage costs.
2. Implement proactive, low-latency incident management that alerts on service reliability degradation based on error budget consumption, rather than firing false positives during short-term metric spikes.

Which TWO architectural actions should the team implement to satisfy these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure an organization-level aggregated Log Router sink destination targeting a central BigQuery dataset, using a log filter that includes Cloud Audit Logs and application logs with severity levels of WARNING and above.; Configure Cloud Monitoring alerting policies using multi-window burn-rate thresholds evaluated against defined Service Level Objectives (SLOs) rather than static CPU or memory threshold metrics.

Answer

The team should implement an organization-level aggregated Log Router sink targeting a central BigQuery dataset filtered for audit logs and severity levels of WARNING and above, and configure Cloud Monitoring alerting policies using multi-window burn-rate thresholds based on defined SLO error budgets.
Combining an organization-level aggregated sink with explicit log filtering for audit and high-severity logs achieves long-term compliance in BigQuery without unneeded cost overhead. Pairing this with multi-window burn-rate alerting in Cloud Monitoring ensures that incident responses are triggered accurately by real SLO error budget consumption rather than transient metrics.

Step-by-Step Solution

1
Evaluate central audit log and long-term compliance retention requirements
Identify that an organization-level aggregated sink in Cloud Logging can collect logs across all current and future child projects and stream them directly into a centralized BigQuery dataset.
Aggregated sinks provide centralized management and guarantee that all project logs are captured without individual project configuration.
2
Define log filtration criteria for cost and compliance optimization
Filter logs at the sink level to include Cloud Audit Logs and application entries with severity >= WARNING while excluding verbose debug/trace logs.
This prevents overbroad log exclusion while controlling BigQuery ingestion and storage costs.
3
Establish reliability incident alerting strategy
Configure Cloud Monitoring alerting policies using multi-window, multi-burn-rate logic on defined SLOs.
Burn-rate alerting measures consumption of error budgets across fast and slow windows, alerting operators to significant reliability impacts while eliminating false positives from transient spikes.

Key Concept

Centralized Observability Integration & Error Budget Alerting
Question 1043Question →

Your Cloud Operations team is designing an automated deployment pipeline for a high-availability microservice hosted on Google Kubernetes Engine (GKE) using GKE Enterprise Service Mesh and Cloud SQL. The application update introduces a database schema change. To ensure zero-downtime and preserve the service error budget, you must execute a canary release pattern using the expand-contract strategy.

Arrange the following steps in the correct chronological sequence to execute this release strategy safely.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying backwards-compatible database schema expansion to Cloud SQL, deploying candidate (v2) pods to GKE without external traffic, configuring the Service Mesh VirtualService for a 5% canary split, monitoring SLIs and error budgets during soak, and finally promoting v2 to 100% traffic while executing the database contract phase.
Safely deploying application updates with database changes requires decoupling schema expansion from schema contraction. Expanding the schema first ensures backwards compatibility for legacy v1 instances. Once v2 workload pods are provisioned on GKE, canary traffic splitting via Service Mesh allows real-time telemetry observation. After verifying SLI health, shifting 100% of traffic and executing the contract phase completes the zero-downtime release.

Step-by-Step Solution

1
Database Schema Expansion
Cloud SQL accepts queries from both v1 and v2 software versions without failure.
Applying non-breaking database schema changes (expand phase) ensures running v1 application instances continue operating without downtime when v2 is deployed.
2
Deploy Candidate Workload
v2 pods pass health checks on GKE while v1 continues handling 100% of live traffic.
Candidate containers must be provisioned and healthy before receiving live user requests.
3
Configure Service Mesh Canary Traffic Split
5% of inbound requests route to v2 pods and 95% continue to v1 pods.
Declarative traffic splitting via Service Mesh enables fine-grained exposure to test v2 under real user conditions.
4
SLI and Error Budget Soak Monitoring
Performance and reliability metrics confirm no regressions on the canary deployment.
Automated telemetry analysis ensures issue detection before exposing the full user base.
5
Full Promotion and Schema Contracting
100% of traffic routes to v2, v1 is retired, and legacy database structures are safely removed.
The contract phase finishes the release lifecycle after v1 is fully drained and retired.

Key Concept

Expand-Contract Database Migration in Canary Deployments
Question 1044Question →

An enterprise security policy prohibits the use of downloadable JSON service account keys on developer workstations. A developer needs to run a local Python application that uses Google Cloud Client Libraries to query BigQuery tables in Project-B using a target service account (`[email protected]`).

Arrange the following operational steps in the correct chronological order to configure local credentials and execute the application using Google Cloud best practices for service account impersonation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct workflow starts by authenticating the developer's identity with gcloud auth login, granting the Service Account Token Creator role on the target service account, initializing Application Default Credentials (ADC) with the service account impersonation flag, and finally executing the Python SDK application.
Proper setup of programmatic GCP interaction using service account impersonation requires authenticating the user identity first, delegating token creation privileges via roles/iam.serviceAccountTokenCreator on the target service account, generating impersonated Application Default Credentials locally, and finally running the SDK code which seamlessly picks up the ADC credentials.

Step-by-Step Solution

1
Authenticate user identity
Initializes active user credentials in gcloud CLI.
Service account impersonation requires an authenticated user identity to authorize the token generation request.
2
Assign IAM Token Creator role
User receives permission to impersonate the target service account.
Without roles/iam.serviceAccountTokenCreator granted on the service account, the gcloud ADC impersonation call will fail with a 403 Forbidden error.
3
Create impersonated Application Default Credentials
Creates a local ADC credential file pointing to the target service account.
Application Default Credentials allow Google Cloud Client Libraries to transparently acquire short-lived tokens without storing permanent keys.
4
Run the SDK application
Application authenticates as sa-b and successfully queries BigQuery.
Client libraries automatically resolve ADC from default environment paths and handle token lifecycle management implicitly.

Key Concept

Service account impersonation and Application Default Credentials (ADC) configuration
Question 1045Question →

A Cloud Architect is auditing permission inheritance for a team accessing data inside Google Cloud. Arrange the levels of the Google Cloud resource hierarchy in order from the highest scope of IAM policy inheritance (broadest level) to the most granular scope of IAM policy inheritance (lowest level).

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct evaluation order from broadest scope of inheritance to most granular scope is Organization Node Level, followed by Folder Level, Project Level, and finally Resource Level.
Google Cloud IAM follows a strict top-down resource hierarchy inheritance model: Organization -> Folder -> Project -> Resource. Permissions granted at a parent level automatically inherit down to all descendant nodes and cannot be restricted by lower-level policies.

Step-by-Step Solution

1
Identify the root container of the GCP resource hierarchy.
The Organization node is the root container.
IAM bindings at the Organization level apply globally across all sub-nodes.
2
Identify intermediate grouping structures beneath the Organization.
Folders act as intermediate grouping mechanisms.
Folders allow administrative isolation and IAM policy inheritance across groups of projects.
3
Identify the project container level.
Projects are the primary organizational units for resources.
IAM roles granted at the project level inherit down to all service instances inside that project.
4
Identify individual service resource nodes.
Individual resources form the leaves of the hierarchy tree.
Resource-level IAM policies (where supported, like Cloud Storage buckets) apply directly to that specific asset.

Key Concept

IAM policy inheritance down the Google Cloud Resource Hierarchy
Question 1046Question →

An enterprise gaming company is preparing to launch an online multiplayer game in a Google Cloud project located in the europe-west3 region. During automated load testing, deployment scripts failed because the required Compute Engine vCPUs exceeded the project's regional limit. The architecture team needs to establish an operational workflow to accommodate scaling requirements for anticipated high-traffic events while maintaining least-privilege security standards. Which strategy should the cloud architect recommend?

Show answer & explanation

Answer: Request a proactive regional quota increase for vCPUs in europe-west3 well in advance of scheduled events, and set up Cloud Monitoring alerts to track quota utilization thresholds.

Answer

Proactively request a regional quota increase for vCPUs in europe-west3 well in advance of scheduled events, and set up Cloud Monitoring alerts to track quota utilization thresholds.
Proactively requesting a regional quota increase prior to scheduled high-traffic events ensures that required infrastructure capacity is available when deployment scripts run. Integrating Cloud Monitoring alerts on quota usage metrics allows administrators to detect near-capacity scenarios early and request additional resources before outages happen.

Step-by-Step Solution

1
Assess regional resource demands
Determine peak anticipated vCPU capacity in the europe-west3 region prior to the event launch.
Regional resource quotas act as safety caps and must be evaluated before scaling events to ensure project capacity.
2
Submit a quota increase request
Request a quota increase through the Google Cloud Console Quotas interface ahead of time.
Google Cloud evaluates quota requests based on system capacity and account history, which requires review lead time.
3
Implement quota threshold monitoring
Configure Cloud Monitoring alerting policies using quota consumption metrics.
Automated alerts provide early warning when consumption reaches defined thresholds, allowing proactive adjustments before failure occurs.

Key Concept

Proactive Resource Quota Management and Threshold Monitoring
Question 1047Question →

A high-frequency fintech platform operates its core transaction processing engine on Google Cloud using Compute Engine managed instance groups alongside stateless validation microservices running on Cloud Run. The core transaction processing engine maintains a constant, predictable 24/7 baseline usage, whereas the validation microservices undergo unpredictable 10x traffic bursts during sudden financial market fluctuations. The platform engineering team also executes ad-hoc analytical queries against BigQuery to monitor fraud patterns. Which cost optimization strategy should a Cloud Architect recommend to maximize spend efficiency without sacrificing operational availability?

Show answer & explanation

Answer: Purchase spend-based Flexible Committed Use Discounts (CUDs) to cover the predictable baseline compute usage across Compute Engine and Cloud Run, while utilizing auto-scaling with Spot VMs for stateless burst capacity and standard on-demand slots for BigQuery ad-hoc queries.

Answer

Purchase spend-based Flexible Committed Use Discounts (CUDs) to cover the predictable baseline compute footprint across Compute Engine and Cloud Run, while utilizing auto-scaling with Spot VMs for stateless burst capacity and standard on-demand slots for BigQuery ad-hoc queries.
The solution correctly identifies that spend-based Flexible Committed Use Discounts (CUDs) should be applied to predictable, steady-state baseline usage across Compute Engine and Cloud Run. For erratic, high-volume traffic spikes, leveraging auto-scaling with Spot VMs or pay-as-you-go capacity ensures high cost efficiency without over-committing capital. Furthermore, keeping BigQuery on on-demand slot allocation avoids paying for idle reserved slots when queries are infrequent.

Step-by-Step Solution

1
Analyze workload patterns to separate predictable baseline consumption from bursty, variable consumption.
Identified constant 24/7 baseline compute across Compute Engine and Cloud Run, alongside erratic 10x traffic spikes.
FinOps best practices require aligning commitment models only to stable, non-variable baseline requirements.
2
Select the appropriate Google Cloud discount commitment mechanism for multi-service compute baselines.
Chosen spend-based Flexible CUDs, which offer hourly spend flexibility across Compute Engine and Cloud Run.
Flexible CUDs apply automatically across multiple compute products without tying the discount to specific machine types or regions.
3
Select cost-efficient mechanisms for stateless, unpredictable burst capacity and ad-hoc analytics.
Applied Spot VMs for fault-tolerant burst capacity and on-demand pricing for ad-hoc BigQuery queries.
Spot VMs provide significant cost reductions for batch/burst microservices without long-term monetary commitments.

Key Concept

FinOps Cost Governance and Flexible Committed Use Discount (CUD) Optimization
Estimated Time:2m 0s
Question 1048Question →

An online retail enterprise is implementing an automated, secure continuous integration and continuous delivery (CI/CD) pipeline on Google Cloud to deploy microservices to Google Kubernetes Engine (GKE). Arrange the operational steps in the correct sequence from initial code commit to production release.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of pipeline execution is: (1) Cloud Build compiles source code into a container image; (2) Container Analysis scans the image and Cloud KMS signs a Binary Authorization attestation; (3) The signed image and attestation metadata are stored in Artifact Registry; (4) Cloud Deploy creates a release and deploys to the Staging GKE cluster; (5) Binary Authorization enforces attestation checks while Cloud Deploy executes a progressive canary deployment to Production GKE.
A well-architected GCP CI/CD pipeline enforces continuous integration, security attestation, artifact immutability, and progressive delivery in a sequential flow: (1) Source compilation and image build in Cloud Build; (2) Vulnerability scanning via Container Analysis and signing via Cloud KMS; (3) Storing the signed artifact in Artifact Registry; (4) Initial rollout to a staging environment using Cloud Deploy; and (5) Enforcing Binary Authorization policy gates during a progressive canary release to the production GKE cluster.

Step-by-Step Solution

1
Identify the initial continuous integration build action.
Cloud Build executes upon code push to compile source code and build the container image.
Container creation is the prerequisite step before any scanning, artifact storage, or deployment can occur.
2
Determine the artifact security scanning and attestation sequence.
Container Analysis scans the newly built image and Cloud KMS generates a signed attestation.
Automated security scanning and attestation signing verify build integrity prior to storing the image in a release repository.
3
Identify the centralized artifact storage step.
The signed container image digest and attestation are uploaded to Artifact Registry.
Artifact Registry serves as the central, secure repository from which continuous delivery systems fetch validated artifacts.
4
Determine the initial delivery target deployment.
Cloud Deploy generates a pipeline release and deploys the artifact to the Staging GKE environment.
Continuous Delivery best practices require validating application releases in staging targets before promoting to production.
5
Identify the final admission control enforcement and production rollout.
Binary Authorization evaluates policy rules on the GKE cluster while Cloud Deploy performs a canary rollout to Production.
Binary Authorization acts as the mandatory runtime admission controller verifying image attestations prior to production traffic shifting.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Design with Cloud Build, Artifact Registry, Binary Authorization, and Cloud Deploy
Question 1049Question →

Your organization runs a web application behind a Google Cloud HTTP(S) Load Balancer. You are setting up health checks and automated alerting to ensure operational reliability. If backend database queries experience transient latency, you want to avoid cascading service failures where healthy application instances are mistakenly marked as unhealthy. Which configuration strategy should you implement for the load balancer health checks?

Show answer & explanation

Answer: Configure health check probes to hit a dedicated, shallow endpoint that verifies web process responsiveness without querying deep database dependencies.

Answer

Configure health check probes to hit a dedicated, shallow endpoint that verifies web process responsiveness without querying deep database dependencies.
Shallow health checks verify that the application server process itself is listening and accepting traffic without testing downstream dependencies. This design prevents transient database latency from causing the load balancer to mistakenly mark healthy compute instances as failed, avoiding cascading outages.

Step-by-Step Solution

1
Analyze the operational reliability requirement
Identified the need to prevent false health check failures during transient database latency.
Deep health checks cause load balancers to mark healthy compute instances as failing when only the underlying database is slow, triggering cascading failures.
2
Select the appropriate health check design pattern
Use a shallow HTTP endpoint (e.g., /healthz) that tests local web process availability.
Shallow endpoints ensure the load balancer only routes traffic to active server instances without overloading downstream resources.

Key Concept

Shallow vs. Deep Health Checking in Load Balancing
Question 1050Question →

An enterprise e-commerce platform hosted on Google Cloud experiences high traffic volatility during promotional events. Transient micro-spikes in compute resource usage currently trigger dozens of high-severity alerts, causing severe alert fatigue among on-call engineers. Additionally, during a recent incident, the Google Cloud HTTP Load Balancer marked all backend instances as unhealthy because its health checks were configured to execute deep SQL queries against a database that was experiencing temporary connection pool exhaustion, resulting in a cascading platform outage. The Lead Reliability Engineer must redesign the operational alerting and health checking architecture to reflect true customer impact and prevent cascading failures. Which combination of architectural practices should be implemented?

Show answer & explanation

Answer: Configure Cloud Monitoring alert policies using multi-window burn-rate conditions based on Service Level Objectives (SLOs), and update the load balancer health checks to target a shallow endpoint that only validates local process status.

Answer

Configure Cloud Monitoring alert policies using multi-window burn-rate conditions based on Service Level Objectives (SLOs), and update the load balancer health checks to target a shallow endpoint that only validates local process status.
The combination of multi-window burn-rate alerts and shallow load balancer health checks directly addresses both issues. Multi-window burn-rate alerting ensures that alerts trigger only when the error budget is consumed at a rate that threatens the SLO over both short and long lookback windows, eliminating false alarms from micro-spikes. Shallow health checks verify that the specific application instance process is responsive without testing backend database endpoints, preventing cascading failures across the compute pool when database latency occurs.

Step-by-Step Solution

1
Evaluate alerting strategy to eliminate alert fatigue from transient micro-spikes.
Transitioning from static metric thresholds to multi-window burn-rate alerting evaluates the rate of Error Budget consumption over multiple time windows (e.g., 1-hour and 6-hour windows), ensuring alerts fire only when sustained error rates threaten the overall Service Level Objective.
Sustained burn rates correlate directly with real user impact, preventing false alarms from brief operational spikes.
2
Evaluate load balancer health check configuration to prevent cascading service failures.
Replacing deep health checks (which query downstream databases or external services) with shallow health checks (which query a dedicated `/healthz` endpoint verifying only local process availability) isolates instance lifecycle management from dependency health.
If a downstream database becomes temporarily overloaded, removing healthy compute instances from load balancing exacerbates the outage instead of mitigating it.

Key Concept

Site Reliability Engineering (SRE) best practices for SLO-based multi-window burn-rate alerting and shallow load balancer health checks.
Question 1051Question →

An enterprise application hosted on Compute Engine instances behind an External Application Load Balancer experiences cascading service outages whenever downstream database queries undergo brief, transient latency spikes. Diagnostic logs indicate that load balancer health checks are configured to execute deep database queries directly, causing healthy web instances to be misidentified as unhealthy and removed from serving pools. Additionally, the operations team suffers from alert fatigue caused by fixed threshold alerts firing during minor latency spikes. Which architecture modification should you recommend to improve operational reliability and incident management?

Show answer & explanation

Answer: Reconfigure load balancer health checks to query a lightweight local HTTP endpoint that validates local process status, and establish Cloud Monitoring alerting policies based on SLO error budget burn rates.

Answer

Reconfigure load balancer health checks to query a dedicated, lightweight local health endpoint on the web servers, and implement Cloud Monitoring alerting policies using SLO error budget burn rates.
The correct strategy decouples load balancer health probing from downstream database dependencies by using a lightweight local endpoint, preventing cascading server drops. Additionally, leveraging error budget burn-rate alerts in Cloud Monitoring alerts operations teams based on true impact to customer SLOs rather than short-lived performance noise.

Step-by-Step Solution

1
Analyze load balancer health check behavior
Identify that deep health checks probing downstream databases cause healthy web instances to be marked unhealthy during transient database slowness, leading to cascading failures.
Load balancer health checks must only measure whether the immediate instance can accept traffic.
2
Decouple health probing logic
Configure health checks to hit a lightweight local HTTP endpoint (e.g., /healthz) that tests local web process viability without executing deep database calls.
Isolating local health checks prevents transient database latency from taking down the web serving tier.
3
Implement effective automated alerting for incident management
Use Cloud Monitoring to create burn-rate alerting policies on Service Level Objectives (SLOs).
Burn-rate alerting evaluates the rate at which the error budget is consumed over multiple time windows, preventing alert fatigue from transient spikes while alerting promptly on significant outages.

Key Concept

Incident Management and Automated Alerting
Question 1052Question →

An enterprise fintech platform processes algorithmic fraud analysis on Google Cloud across multiple projects under a central Cloud Billing account. The operational workload consists of a steady baseline of microservice API calls alongside unpredictable, highly bursty batch jobs during peak financial market trading hours. Currently, all virtual machines operate on standard pay-as-you-go pricing, database resources use standard configurations, and cost reporting is performed manually at month-end.

The FinOps leadership team wants to establish proactive cost governance and automated cost optimization while maintaining high availability for baseline traffic and minimizing financial risk. Which of the following strategies should the team implement? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Apply Flexible Committed Use Discounts (CUDs) to cover predictable baseline spend across compute services, and utilize Spot VMs for non-critical bursty batch processing.; Enable detailed Cloud Billing export to BigQuery in a dedicated administration project, and configure automated Pub/Sub budget alerts to trigger proactive spend notifications.

Answer

The organization should implement Flexible Committed Use Discounts (CUDs) to cover baseline compute spend alongside Spot VMs for bursty processing, and set up Cloud Billing export to BigQuery combined with Pub/Sub budget alerts for automated governance.
The correct strategy combines flexible spend commitments with Spot instance usage for variable workloads, alongside automated billing exports and programmatic budget notifications. Flexible CUDs allow spending flexibility across machine types and services without locking into static hardware sizes. Streaming billing data to BigQuery provides centralized FinOps analytics, while Pub/Sub billing alerts enable automated responses to budget events.

Step-by-Step Solution

1
Analyze workload patterns for compute cost optimization
Identify predictable baseline capacity suitable for spend-based Flexible CUDs and fault-tolerant batch capacity suitable for Spot VMs.
Flexible CUDs provide discounted rates across compute services for steady usage, while Spot VMs drastically reduce costs for fault-tolerant burst processing.
2
Establish FinOps governance and real-time visibility
Configure Cloud Billing export to BigQuery for central reporting and link budget alerts to Pub/Sub.
BigQuery billing exports enable deep analytical reporting, and Pub/Sub notifications facilitate real-time automated alerting when spending thresholds are breached.

Key Concept

FinOps Cloud Cost Governance and Compute Optimization
Question 1053Question →

An enterprise financial organization runs a mission-critical payment processing application on a Google Cloud Managed Instance Group (MIG) behind an External HTTP(S) Load Balancer. The SRE team faces two main operational challenges: first, frequent transient traffic bursts trigger alert storms that cause on-call engineer fatigue while failing to highlight sustained slow-burn reliability budget exhaustion; second, when specific corrupt payloads cause backend compute instances to fail, manual incident response causes elevated Mean Time to Resolution (MTTR).

The Site Reliability Engineering team needs an automated alerting and incident management pipeline that:
1. Accurately detects rapidly accelerating and slow-burn degradation of the request latency Service Level Objective (SLO) while preventing alert fatigue during temporary bursts.
2. Automatically isolates compromised VM instances for offline forensic analysis and replaces capacity without worsening backend load or risking cascading failure through deep load balancer health probes.

Which operational architecture should you recommend?

Show answer & explanation

Answer: Configure Cloud Monitoring Service Monitoring using multi-window, multi-burn-rate alert policies on latency SLIs. Route alerts through Pub/Sub to an automated Cloud Function that detaches failing instances from the MIG for forensic analysis, and maintain lightweight HTTP load balancer health check endpoints focused solely on local node health.

Answer

The optimal architecture uses Cloud Monitoring Service Monitoring with multi-window, multi-burn-rate alert policies tracking request latency SLIs, paired with Pub/Sub and Cloud Functions for automated instance isolation and lightweight load balancer health checks.
The solution employing multi-window, multi-burn-rate alerting on SLIs directly aligns with Google Cloud SRE practices. It prevents alert fatigue by requiring both short-window acceleration and long-window sustained consumption before alerting. Routing alert payloads via Pub/Sub to Cloud Functions enables automated cordoning, offline forensics, and MIG auto-healing, while lightweight health checks prevent cascading failures caused by downstream dependency degradation.

Step-by-Step Solution

1
Analyze the alerting requirement to address alert fatigue and slow-burn detection.
Identify that static metrics or single short windows fail, whereas Google SRE multi-window multi-burn-rate alerts evaluate both short-term fast consumption and long-term slow consumption of the error budget.
Multi-burn-rate alerts reduce false positives from temporary spikes while ensuring critical SLO breaches trigger timely notifications.
2
Evaluate the automated incident response mechanism.
Publishing alert events to a Pub/Sub topic allows a decoupled serverless function (Cloud Functions) to isolate/detach failing compute instances for forensic inspection while the MIG provisions healthy replacements.
Automating instance cordoning and replacement minimizes MTTR without requiring manual operator intervention.
3
Assess load balancer health check configuration.
Keep health checks lightweight (testing basic endpoint/port responsiveness) rather than executing heavy downstream database dependencies.
Deep dependency health checks cause cascading cluster failures when a downstream database experiences transient load.

Key Concept

Multi-window multi-burn-rate alerting and decoupled automated incident remediation in GCP
Question 1054Question →

An organization manages a fleet of 500 Compute Engine virtual machines hosting a latency-sensitive trading platform across multiple Google Cloud projects. The infrastructure engineering team implemented a unified log exclusion filter at the organization level (`resource.type="gce_instance" AND severity<ERROR`) on an aggregate Log Router sink to reduce Cloud Logging storage ingestion overhead. Shortly after applying this filter, automated incident response alerts stopped triggering for VM crash loops and system failures caused by memory exhaustion, even though the application services were uncommunicative. Upon investigation, engineers noticed that critical Linux kernel panic logs and systemd process failure events emitted by the OS were missing from their Monitoring dashboards and BigQuery security audit datasets. Which architectural modification should the team implement to restore operational visibility and automated incident alerting while retaining log storage cost control?

Show answer & explanation

Answer: Modify the organization log exclusion filter to explicitly exclude log messages only matching `severity<WARNING AND NOT logName:"logs/systemd" AND NOT logName:"logs/syslog"`, ensuring high-priority system daemon events bypass exclusion filters.

Answer

Refine the organization-level Log Router exclusion filter to preserve essential OS system logs (syslog and systemd) by excluding low-severity logs while explicitly retaining critical operational streams below ERROR severity.
The correct solution modifies the Log Router exclusion filter so that essential OS log streams (such as systemd daemons and system syslog events) are explicitly exempted from being discarded when filtering entries below ERROR severity. This restores automated alerting and observability while still excluding non-essential low-severity logs from compute instances.

Step-by-Step Solution

1
Analyze the impact of the current exclusion filter (`severity<ERROR`).
Identified that critical operational events (such as systemd process crashes or kernel driver messages) are frequently logged under INFO, NOTICE, or WARNING severities, causing them to be dropped before reaching storage or alerting mechanisms.
Exclusion filters drop log entries matching the filter criteria at the Cloud Logging router prior to routing to sinks.
2
Evaluate the target requirement for cost optimization versus observability integrity.
Determined that system logs (`logs/syslog` and `logs/systemd`) must be explicitly protected from exclusion using Boolean logical clauses in the Log Router filter.
Observability integration requires maintaining high-cardinality signal visibility for OS lifecycle events without ingesting non-essential debug noise.
3
Select the log router filter configuration that selectively preserves vital daemon streams.
Refining the exclusion query to prevent matching essential log streams ensures that system-level crash indicators remain accessible for Cloud Monitoring alerts and BigQuery auditing.
Log Router inclusion/exclusion expressions directly control ingestion policies across all downstream sinks.

Key Concept

Cloud Logging Router Exclusion Filters and System Observability Integration
Estimated Time:3m 0s
Question 1055Question →

A platform engineering team is setting up an automated integration testing pipeline for a multi-tenant application that executes complex transactions across Cloud Spanner and publishes event notifications to Cloud Pub/Sub. To minimize cost and avoid provisioning real cloud resources during pull request validations, the pipeline runs local emulator instances for both services inside ephemeral Docker containers. During test suite execution, developers report that tests requiring schema DDL modifications fail inside read-write transaction blocks, and event publishing calls attempt to authenticate against production endpoints using Google Application Default Credentials (ADC). Which combination of architectural and operational adjustments will resolve these integration testing failures while adhering to GCP best practices?

Show answer & explanation

Answer: Export the SPANNER_EMULATOR_HOST and PUBSUB_EMULATOR_HOST environment variables in the test runner environment, and separate database schema DDL execution from transaction runtime logic since the Cloud Spanner emulator processes DDL statements synchronously outside active read-write transactions.

Answer

Export the SPANNER_EMULATOR_HOST and PUBSUB_EMULATOR_HOST environment variables in the test runner environment, and separate database schema DDL execution from transaction runtime logic since the Cloud Spanner emulator processes DDL statements synchronously outside active read-write transactions.
Exporting the designated emulator host environment variables instructs GCP SDKs to bypass production authentication and route requests to local containerized emulators. Furthermore, structuring test suites to execute DDL schema migrations prior to transaction logic accommodates the specific constraints of the Cloud Spanner emulator.

Step-by-Step Solution

1
Analyze why client libraries attempt production ADC authentication during tests.
GCP SDK client libraries inspect service-specific environment variables such as SPANNER_EMULATOR_HOST and PUBSUB_EMULATOR_HOST. When exported, SDKs automatically redirect API calls to local emulator endpoints and disable OAuth2/ADC credential checks.
Prevents test traffic from attempting live authentication against GCP production endpoints during offline or CI test execution.
2
Identify Cloud Spanner emulator limitations regarding DDL execution.
The Cloud Spanner emulator processes DDL statements synchronously outside of active read-write transactions. Schema changes attempted within transactional code paths raise execution errors.
Aligns application test suite setup logic with the operational capabilities and constraints of the local Cloud Spanner emulator.

Key Concept

Cloud Spanner and Pub/Sub Emulator Environment Configuration and Operational Constraints
Estimated Time:3m 0s
Question 1056Question →

A financial analytics firm's platform operations team is standardizing their infrastructure provisioning workflow. Currently, engineers create static JSON service account keys locally and use them with Terraform to deploy resources, frequently relying on the project Editor role to avoid permission issues. You are advising the team on establishing secure, automated Infrastructure as Code (IaC) practices that align with Google Cloud best practices while minimizing operational overhead. Which architectural recommendation should you provide?

Show answer & explanation

Answer: Configure Workload Identity Federation to authenticate CI/CD pipelines short-lived tokens without service account keys, store Terraform state in a Cloud Storage backend with object versioning, and grant the deployment service account fine-grained predefined roles.

Answer

Configure Workload Identity Federation to authenticate CI/CD pipelines with short-lived tokens, store Terraform state in a Cloud Storage backend with object versioning enabled, and grant the deployment service account granular predefined roles.
Advising dev/ops teams on GCP deployment automation requires enforcing keyless authentication via Workload Identity Federation, implementing reliable remote IaC state management in Cloud Storage with object versioning, and using fine-grained predefined IAM roles to satisfy the principle of least privilege.

Step-by-Step Solution

1
Evaluate authentication and credential management requirements
Replace static, long-lived JSON service account key downloads with short-lived keyless authentication using Workload Identity Federation for external CI/CD runners.
Eliminates security risks associated with leaked or unrotated credentials.
2
Determine proper Infrastructure as Code state management
Configure a remote Google Cloud Storage (GCS) backend with state locking and object versioning.
Prevents state file corruption, enables multi-developer concurrency, and allows state rollback if needed.
3
Apply access control governance according to least privilege
Grant specific predefined roles (such as Compute Admin or Storage Admin) required for provisioning instead of primitive roles like Editor or Owner.
Restricts deployment permissions strictly to necessary resources and operations.

Key Concept

Advising Development and Operation Teams on Secure IaC Practices
Question 1057Question →

A media streaming organization is designing an automated CI/CD pipeline on Google Cloud to deploy microservice applications to Google Kubernetes Engine (GKE). The engineering team requires that code pushed to release branches automatically triggers container builds, executes security scanning, enforces image integrity verification prior to deployment, and manages progressive canary rollouts across staging and production with automated rollback capabilities upon metric anomalies. Which pipeline design best fulfills these requirements following Google Cloud best practices?

Show answer & explanation

Answer: Configure Cloud Build triggers for branch commits to build container images, store them in Artifact Registry, generate Binary Authorization attestations after scanning, and use Cloud Deploy pipelines to manage multi-target progressive rollouts with Cloud Monitoring metric alerts for automated rollbacks.

Answer

The optimal design uses Cloud Build triggers integrated with Artifact Registry and Binary Authorization for secure container building and signing, paired with Cloud Deploy to orchestrate progressive canary rollouts and metric-based automated rollbacks.
The solution leveraging Cloud Build, Artifact Registry, Binary Authorization attestations, and Cloud Deploy provides a complete, cloud-native CI/CD architecture. Cloud Build automates code testing and container compilation, Artifact Registry stores artifacts securely, Binary Authorization ensures image compliance, and Cloud Deploy coordinates multi-target progressive delivery with automated Cloud Monitoring rollback automation.

Step-by-Step Solution

1
Establish Continuous Integration and Security Controls
Cloud Build triggers automatically build container images upon code commits, push them to Artifact Registry, and generate Binary Authorization attestations based on Container Analysis security scans.
Ensures that only verified, vulnerability-scanned, and signed container images can be deployed to GKE clusters.
2
Configure Progressive Delivery with Cloud Deploy
Cloud Deploy receives the release artifact, managing progressive delivery (such as canary strategies) across staging and production targets with explicit promotion approvals.
Provides structured environment promotion and deployment strategy management tailored for GKE workloads.
3
Integrate Operational Monitoring for Automated Rollbacks
Cloud Deploy monitors deployment health indicators via Cloud Monitoring alerts and automatically initiates a rollback if deployment anomalies or errors occur.
Prevents faulty releases from degrading production availability without requiring manual intervention.

Key Concept

Cloud Build and Cloud Deploy Integration for Secure Automated Releases
Estimated Time:1m 30s
Question 1058Question →

An enterprise media organization operates a high-throughput video streaming platform hosted on Google Kubernetes Engine (GKE) behind a Global External Application Load Balancer. During peak live events, transient database latency causes load balancer health checks to fail across healthy GKE pods, resulting in cascading backend shutdowns and incident alert floods. Additionally, operations teams are overwhelmed by false-positive pages for short latency spikes while failing to detect slow, sustained error budget depletion. You need to re-architect the automated alerting and incident management strategy to improve system reliability and incident escalation. Which TWO architectural actions should you take? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Reconfigure the load balancer health check endpoints to target a shallow application status check (/healthz) that only verifies local pod process health.; Configure Cloud Monitoring alerting policies using multi-window, multi-burn-rate conditions based on Service Level Objective (SLO) error budget consumption.

Answer

The correct actions are to implement shallow health check endpoints for load balancing to prevent cascading failures, and to configure multi-window, multi-burn-rate alerting policies based on SLO error budget consumption in Cloud Monitoring.
The correct strategy combines shallow health checks with SLO burn-rate alerting. Shallow load balancer health checks (/healthz) verify local instance functionality without cascading failures when downstream databases slow down. Multi-window burn-rate alerts monitor the consumption rate of error budgets over long and short windows, dramatically decreasing false positives while prioritizing real outages.

Step-by-Step Solution

1
Analyze load balancer health check failure root cause
Identified that health checks hitting downstream database dependencies cause all backend pods to be marked unhealthy during transient database latency.
Health checks must isolate local container/process health from external service dependencies.
2
Redesign health check endpoint structure
Decoupled health checks by pointing them to a shallow endpoint (/healthz) that returns HTTP 200 based strictly on local application process readiness.
This prevents load balancing infrastructure from removing functional application pods when downstream services experience transient degradation.
3
Evaluate and replace alerting strategy
Replaced static metric threshold alerts with multi-window burn-rate alerting tied directly to SLO error budget consumption rates.
Burn-rate alerting accurately measures user-impacting trends across multiple time windows, avoiding false alarms from transient spikes while alerting promptly on critical outages.

Key Concept

Incident Management, Shallow Health Checks, and SLO Burn-Rate Alerting
Question 1059Question →

A cloud operations team wants to reduce overall Cloud Logging ingestion and storage costs by filtering out non-essential debug logs before they are written to the default log bucket, while preserving high-severity error logs for operational monitoring. Which approach aligns with Google Cloud recommended practices for controlling log ingestion costs?

Show answer & explanation

Answer: Configure a log exclusion filter in the log router sink specifying severe or error severity levels to be retained while excluding debug entries.

Answer

The optimal approach is to configure a log exclusion filter in the log router sink that targets debug-severity log entries while keeping high-severity entries.
Configuring exclusion filters in the log router allows organizations to drop specific low-priority logs like debug records before they enter log buckets, effectively reducing ingestion and storage costs while retaining vital error logs.

Step-by-Step Solution

1
Identify the requirement to reduce ingestion volume specifically for low-value debug logs without missing critical errors.
Recognize that log router exclusion filters inspect log entries prior to bucket ingestion.
Excluding log entries at the router prevents storage costs while maintaining fine-grained control over severity levels.
2
Evaluate Google Cloud Logging router filter syntax to drop `severity < ERROR` or specific `severity = DEBUG` records.
Targeted exclusion criteria ensure debug entries are filtered out while critical errors pass through to the log sink.
Fine-grained filtering avoids dropping important diagnostic data.

Key Concept

Cloud Logging Log Router Exclusion Filters
Question 1060Question →

A financial services organization operates a payment processing microservice on Google Kubernetes Engine (GKE) behind an internal HTTP(S) Load Balancer. During unexpected upstream partner outages, the service experiences severe error spikes that deplete its monthly availability Service Level Objective (SLO) error budget in less than an hour. However, the existing SRE alerting policy relies on a single-window 5-minute mean error rate threshold, which either fails to notify on-call engineers before significant budget consumption occurs or generates excessive false positives during brief traffic bursts. What alerting policy design in Cloud Monitoring should a Cloud Architect recommend to alert on critical error budget depletion while minimizing noise?

Show answer & explanation

Answer: Configure a multi-window, multi-burn-rate alerting policy based on the Service Level Indicator (SLI) that requires both a short lookback window (14 minutes) and a long lookback window (1 hour) to exceed a specific burn-rate threshold before triggering an incident.

Answer

Configure a multi-window, multi-burn-rate alerting policy based on the Service Level Indicator (SLI) that requires both a short lookback window and a long lookback window to exceed a specific burn-rate threshold before triggering an incident.
The correct approach implements multi-window, multi-burn-rate alerting on the service's SLO in Cloud Monitoring. By evaluating both a short lookback window (to verify the incident is ongoing) and a long lookback window (to verify substantial budget consumption), the SRE team ensures fast notification during severe outages while avoiding false alarms caused by brief metric spikes.

Step-by-Step Solution

1
Analyze the operational issue
Identified that single-window static threshold alerts cause false positives during transient traffic bursts and fail to protect against rapid SLO error budget consumption during severe incidents.
SRE best practices require alerts based on error budget burn rate rather than raw metric thresholds.
2
Evaluate SRE multi-window burn rate alert principles in Google Cloud Monitoring
Determined that multi-window multi-burn-rate alerting validates both recent severe consumption (short window) and sustained consumption (long window).
Using dual lookback windows ensures that alerts trigger quickly for high-severity budget-depleting events while suppressing alerts if the error rate immediately drops.
3
Select the optimal architecture solution
Selected the option recommending multi-window, multi-burn-rate policy configuration in Cloud Monitoring.
This aligns directly with Google SRE best practices for incident management and automated alerting.

Key Concept

Multi-window, multi-burn-rate SLO alerting in Cloud Monitoring
PreviousPage 53 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin