All practice questions

174 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

A global telematics company operates an automated fleet tracking system in Google Cloud. The primary streaming pipeline runs in `us-central1`, ingesting real-time data via Cloud Pub/Sub, processing it with Cloud Dataflow, and storing state in a regional Cloud Bigtable cluster. In the event of a catastrophic failure in `us-central1`, the operational recovery runbook requires executing a controlled regional failover to `us-east4` with zero data loss for persistent state. What is the correct sequential order of operational steps to execute this disaster recovery failover runbook?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational failover sequence begins by redirecting client ingress traffic via Cloud DNS to the secondary Cloud Pub/Sub topic, followed by draining the primary Cloud Dataflow pipeline to preserve inflight data, promoting the target Cloud Bigtable cluster app profile to us-east4, and finally launching the failover Cloud Dataflow processing job in us-east4.

Executing regional failover for streaming systems requires a strict sequence: first, redirect client traffic at the ingress layer (DNS/PubSub) so new data buffers safely in the secondary region; second, drain the degraded region's stream processing engine (Dataflow) to preserve inflight data and adhere to RPO zero targets; third, promote the replicated database layer (Cloud Bigtable) by updating routing app profiles; fourth, spin up the secondary stream processing workers in the recovery region to resume normal operations.

Step-by-Step Solution

Adjust Cloud DNS traffic routing to point client devices to the secondary ingestion Pub/Sub topic in us-east4.

New telemetry stream data is safely buffered in the failover region's Pub/Sub topic.

Immediate DNS traffic redirection stops new workload accumulation in the failing region and prevents client connection timeouts.

Issue a drain command to the primary Cloud Dataflow streaming pipeline operating in us-central1.

Inflight records stored in Pub/Sub and Dataflow pipeline buffers are processed and committed to Cloud Bigtable before job termination.

Draining ensures RPO requirements are met without dropping records currently residing in pipeline memory.

Update Cloud Bigtable App Profiles to route application traffic to the replicated instance cluster in us-east4.

The database storage tier in us-east4 is configured as the active target for read/write queries.

Storage cluster app profiles must be switched after inflight primary writes are finished to prevent split-brain conditions or data inconsistency.

Start the secondary Cloud Dataflow streaming job in us-east4 reading from the failover Pub/Sub subscription.

Stream ingestion and processing fully resume in the failover region.

The failover data processing pipeline can safely start once both the ingress queue and storage layer are properly configured in the secondary region.

Key Concept

Disaster Recovery Execution Order for Streaming and Storage Workloads

Question 162Question →

A DevOps team needs to allow an application running on an external AWS EC2 instance to retrieve database credentials from GCP Secret Manager without creating or downloading service account keys. Sequence the steps required to establish Workload Identity Federation and securely access the secret following Google Cloud security best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Create a Workload Identity Pool and AWS Provider in Google Cloud. 2) Grant the AWS IAM role permission to impersonate the GCP service account using the Workload Identity User role. 3) Grant the GCP service account the Secret Manager Secret Accessor role. 4) Exchange the AWS credentials for short-lived GCP tokens via the Security Token Service API to retrieve the secret.

Configuring Workload Identity Federation requires establishing trust with the external AWS provider first. Next, the external identity must be authorized to impersonate the designated GCP service account using the `roles/iam.workloadIdentityUser` role. Then, the GCP service account must be granted the specific secret access permission (`roles/secretmanager.secretAccessor`). Finally, the external application uses STS to exchange its native AWS security token for short-lived GCP credentials to fetch the secret payload.

Step-by-Step Solution

Establish federation baseline

Workload Identity Pool and AWS Provider configured in GCP IAM

Google Cloud must recognize and validate assertion tokens issued by AWS IAM.

Bind external identity to GCP service account

IAM policy binding added for `roles/iam.workloadIdentityUser`

Allows authenticated AWS identities matching attribute conditions to impersonate the GCP service account.

Authorize secret access

GCP service account assigned `roles/secretmanager.secretAccessor`

Enforces least privilege by granting payload reading rights only to the service account, avoiding primitive roles.

Token exchange and runtime retrieval

Short-lived GCP access token generated and used to read secret

Eliminates static long-lived credentials by using short-lived tokens generated on demand via STS.

Key Concept

Workload Identity Federation for external workloads accessing GCP Secret Manager

Question 163Question →

A smart grid utility company is deploying a new real-time meter analytics platform on Google Cloud using Cloud Pub/Sub, Dataflow, and BigQuery. You need to establish a structured testing and validation procedure to verify system throughput, data accuracy, and resilience prior to releasing the architecture into full production. In what chronological order should you execute the following testing and validation steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological validation sequence begins with verifying regional resource quotas and IaC staging configuration, followed by synthetic load testing to establish baseline SLIs, streaming mirrored production traffic for data correctness validation, executing fault-injection tests for resiliency compliance, and concluding with a canary rollout monitored via error budgets.

A structured cloud solution validation procedure progresses from static environment and quota verification to isolated synthetic load testing, live shadow traffic comparison, resiliency testing under simulated failure conditions, and finally controlled canary release monitoring.

Step-by-Step Solution

Pre-flight Environment & Quota Validation

Staging environment is verified to have adequate CPU, IP address, and API quotas for testing without running into resource constraints.

Running performance tests without pre-verifying quotas leads to artificial failures caused by GCP service limits rather than architectural flaws.

Synthetic Baseline & Load Testing

Pipeline throughput, backpressure metrics, and worker autoscaling behavior are established under controlled stress conditions.

Synthetic data isolating performance parameters ensures the system handles target peak throughput before introducing live payloads.

Shadow Traffic & Data Quality Validation

Real-world payload variations and schema edge cases are processed and validated against legacy reference outputs without impacting live data.

Shadow testing isolates production data edge-cases while guaranteeing zero operational impact on live operations.

Fault-Injection & Chaos Testing

Automated recovery, subscriber checkpointing, and high-availability guarantees are confirmed under failure scenarios.

Resiliency procedures must be verified against actual outages before trusting the system with production workloads.

Canary Production Rollout

Production traffic is progressively shifted while observing SLI metrics and error budget burn rates.

Canary releases provide a controlled final verification step with limited blast radius.

Key Concept

Developing Procedures to Test and Validate Technical Solutions

Question 164Question →

A Principal Cloud Architect is designing an automated, zero-downtime progressive deployment process for a critical order-processing microservice hosted on Google Kubernetes Engine (GKE) backed by Cloud Spanner. The release involves a breaking application change that relies on an updated database schema. To prevent service disruption and data loss, the rollout must follow the expand-contract pattern combined with a progressive canary traffic migration managed via Cloud Deploy and Anthos Service Mesh. In which sequential order should the DevOps team execute these release steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying backward-compatible database schema changes (expand phase), followed by deploying the canary workloads to GKE, routing a small percentage of live traffic for SLI validation, shifting 100% of production traffic to the new revision and decommissioning legacy pods, and finally removing legacy database columns (contract phase).

The expand-contract pattern dictates that database changes must be introduced non-destructively prior to code releases (expand phase). Application workloads are then deployed and progressively tested using traffic splitting (canary deployment) controlled by service mesh or load balancers. Once 100% of traffic is promoted to the new code and old pods are removed, destructive database cleanups (contract phase) can safely execute.

Step-by-Step Solution

Execute the expand phase of the database migration in Cloud Spanner.

New columns or tables exist alongside legacy structures without breaking currently running application versions.

Decoupling database deployment from application code deployment ensures zero downtime and prevents schema mismatch errors during canary testing.

Provision the new version of the GKE application workload without shifting traffic.

Canary pods are running, healthy, and ready to accept traffic.

Workloads must pass health and readiness checks before receiving live user traffic.

Initiate progressive traffic splitting via Anthos Service Mesh to route 5% of user traffic to the canary workload.

Real user requests hit the canary revision while automated monitoring evaluates SLIs against SLO targets.

Canary analysis isolates risk to a small fraction of users and enables rapid automated rollback if error budgets are threatened.

Promote the new application version to 100% traffic and decommission legacy workloads.

All incoming production traffic lands on the new application revision.

Full migration guarantees that no active workloads rely on the old application version.

Execute the contract phase database migration in Cloud Spanner.

Deprecated database fields and old columns are removed safely.

Removing schema components before all active instances are updated causes runtime queries to fail.

Key Concept

Expand-Contract Database Migrations and Progressive Delivery Alignment

Question 165Question →

An organization requires developers to run local test scripts against Google Cloud APIs using short-lived credentials instead of static JSON key files. A security policy dictates that developers must authenticate as a target service account via service account impersonation using Application Default Credentials (ADC). In what sequence should a platform engineer configure the local environment and code execution pipeline to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order establishes authentication first, grants token creation permissions second, configures local Application Default Credentials with impersonation flags third, and executes application code using standard SDK auto-discovery fourth.

Configuring secure SDK programmatic interaction requires authenticating the user identity first, ensuring the identity has the Service Account Token Creator role on the target service account second, configuring local ADC with the --impersonate-service-account flag third, and finally executing the application code using native client library auto-discovery fourth.

Step-by-Step Solution

Authenticate user identity

User credentials established in gcloud CLI context

Impersonation requires an authenticated primary identity capable of making initial GCP IAM calls.

Grant IAM permissions on the target service account

User authorized with Service Account Token Creator role on the target service account

Without roles/iam.serviceAccountTokenCreator on the target resource, ADC impersonation requests will fail with permission denied errors.

Generate impersonation-configured ADC credentials

ADC file created locally referencing the target service account for impersonation

Running gcloud auth application-default login with the --impersonate-service-account flag configures local SDKs to delegate calls through short-lived service account tokens.

Run SDK application code

SDK requests succeed authenticated as the target service account without service account keys

Standard client library initialization relies on ADC resolution without requiring explicit credential files or code changes.

Key Concept

Service Account Impersonation via Application Default Credentials (ADC)

Question 166Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Promote the cross-region Cloud SQL read replica in us-east4 to a standalone primary database instance, 2) Update application configuration settings in us-east4 to reference the connection endpoint of the newly promoted database instance, 3) Scale up the warm standby Managed Instance Group (MIG) in us-east4 to full production capacity, and 4) Update Cloud DNS routing policies to direct production domain traffic to the us-east4 External HTTP(S) Load Balancer.

Executing disaster recovery requires prioritizing data write availability first, followed by application binding, compute scaling, and finally DNS traffic cutover. Promoting the database replica ensures a writable backend. Rebinding application instances ensures writes hit the new primary database. Scaling up the compute tier ensures sufficient capacity. Switching Cloud DNS last prevents sending live user requests to an unready or under-provisioned environment.

Step-by-Step Solution

Promote the cross-region Cloud SQL read replica in us-east4.

The read replica becomes an independent, writable database instance in the failover region.

Promoting the database first ensures that write operations can be accepted immediately when application instances initiate connections.

Update application configurations to point to the promoted database endpoint.

The application workload in us-east4 is successfully linked to the new primary database.

Application instances must target the active writable database rather than the former read replica endpoint.

Scale up the Managed Instance Group (MIG) in us-east4.

The compute tier reaches full production serving capacity.

Warm standby compute instances must be scaled out to handle production load prior to accepting public internet traffic, avoiding resource exhaustion.

Update Cloud DNS routing policy to fail over traffic to us-east4.

Global ingress traffic is redirected to the healthy, provisioned load balancer in us-east4.

DNS failover should always be executed last after backend data integrity and compute capacity are completely ready to process user requests.

Key Concept

Disaster Recovery Failover Sequencing

Question 167Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with deploying the Cloud Run rotation function, creating the target Pub/Sub topic, granting the Secret Manager Service Agent publisher permissions on that topic, subscribing the Cloud Run function to the topic, and finally enabling the rotation schedule on the secret linked to the topic.

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

Step-by-Step Solution

Deploy the rotation application logic

The Cloud Run function is ready to handle credential regeneration and payload versioning.

The rotation target must exist prior to configuring event bindings and notification triggers.

Create the event messaging topic

A Pub/Sub topic is provisioned to receive rotation signals.

Secret Manager relies on Pub/Sub topics as event sinks for rotation notifications.

Authorize the Secret Manager Service Agent

The service agent for Secret Manager gains `roles/pubsub.publisher` on the Pub/Sub topic.

By default, Secret Manager cannot publish notification messages to custom Pub/Sub topics without explicit IAM permission.

Bind the Pub/Sub topic to the Cloud Run function

An Eventarc trigger or Pub/Sub subscription connects the topic to the function.

This establishes the trigger path so published rotation events immediately execute the function code.

Enable rotation schedule on the secret

Secret Manager starts tracking rotation intervals and publishing events.

Attaching the topic and rotation schedule to the secret completes the workflow and starts automated rotation.

Key Concept

Secret Manager Event-Driven Automated Rotation Lifecycle

Question 168Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Promote the cross-region Cloud SQL read replica in us-central1 to a standalone primary database instance; 2) Update the internal Cloud DNS endpoint record to resolve database traffic to the newly promoted instance in us-central1; 3) Resize the secondary Compute Engine Managed Instance Group (MIG) in us-central1 from zero to full operational capacity; 4) Update the Cloud Load Balancing backend service configuration to divert incoming ingress traffic to the us-central1 MIG.

Executing a disaster recovery failover requires establishing data tier write availability first (database promotion), configuring internal service discovery, scaling out compute resources in the secondary region, and finally updating global ingress routing to direct user traffic to the newly active region.

Step-by-Step Solution

Promote the database replica in the failover region.

A writable primary database instance is available in us-central1.

Compute workloads cannot process requests without access to a writable database instance.

Reconfigure internal network endpoints (Cloud DNS).

Internal database hostname resolves to the us-central1 instance IP.

Application nodes require correct database connection strings and DNS resolution before serving traffic.

Provision compute capacity in us-central1.

Compute Engine MIG scales up and passes initial startup and health checks.

Application instances must be running and healthy before receiving live user requests.

Shift global ingress traffic to the secondary region.

External user requests route to us-central1.

Diverting traffic at the load balancer is executed only after backend dependencies and compute instances are operational.

Key Concept

Disaster Recovery Regional Failover Execution Order

Estimated Time:1m 30s

Question 169Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for provisioning infrastructure via IaC is: 1) Authenticate via Workload Identity Federation; 2) Run `terraform init` to initialize the workspace and lock the Cloud Storage state backend; 3) Run `terraform plan` and execute automated policy-as-code compliance checks; 4) Submit the speculative plan artifact for formal peer approval; 5) Run `terraform apply` with the approved plan file to provision resources and release the backend state lock.

Following Google Cloud SRE and enterprise IaC best practices, automated environment provisioning requires a strict sequence. First, the runner authenticates keylessly using Workload Identity Federation. Second, `terraform init` establishes remote state locking in Cloud Storage to block conflicting parallel executions. Third, a speculative `terraform plan` is evaluated using automated policy-as-code guardrails. Fourth, the generated plan artifact undergoes mandatory peer review to fulfill change management requirements. Finally, `terraform apply` executes the approved plan artifact and releases the backend lock.

Step-by-Step Solution

Authenticate runner via Workload Identity Federation

Pipeline receives temporary IAM service account token

Eliminates long-lived service account key security risks in automated CI/CD pipelines.

Initialize Terraform backend with Cloud Storage state locking

Backend initialized and Cloud Storage object lock acquired

Ensures state consistency and protects state files from concurrent mutation.

Generate speculative execution plan and run policy-as-code validation

Speculative plan created and validated against security guardrails

Catches misconfigurations and policy violations prior to actual resource creation.

Submit plan artifact for human review and approval gate

Approval recorded for the immutable plan file

Enforces governance controls and prevents plan drift between review and deployment.

Apply approved plan artifact and release state lock

GCP resources created/updated and backend state lock released

Executes the precise reviewed state changes idempotently.

Key Concept

Infrastructure as Code Provisioning Workflow and State Locking Lifecycle

Question 170Question →

An online retail platform experiences a complete outage in its primary Google Cloud region (us-east1). The platform architecture uses Cloud SQL for PostgreSQL with a cross-region read replica in us-central1, and a Compute Engine Managed Instance Group (MIG) deployed as a warm standby in us-central1 running at 10% capacity. As the Cloud Architect, you must execute the emergency disaster recovery failover runbook to restore operational production capabilities in us-central1. In what sequence should you execute the failover tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for disaster recovery execution is: 1) Promote the cross-region Cloud SQL read replica in us-central1 to standalone primary, 2) Scale up the warm standby Managed Instance Group in us-central1 to 100% capacity, 3) Update application configurations and execute health checks, 4) Update Cloud DNS routing policies to shift live user traffic to us-central1.

The correct failover sequence ensures data consistency and minimal service disruption: first promote the read replica to enable database write operations, next scale up compute capacity to handle production throughput, then update configuration and verify service health, and finally update DNS records to route end-user traffic to the failover region.

Step-by-Step Solution

Promote the cross-region Cloud SQL read replica in us-central1.

The replica becomes an independent read-write database instance.

Promoting the database first establishes the single source of truth for write operations before application instances are scaled up.

Scale up the warm standby Managed Instance Group (MIG) capacity.

Compute instances in us-central1 reach 100% target production capacity.

Adequate compute capacity must be running and ready to handle target operational load before opening traffic endpoints.

Update application database connections and run readiness checks.

Application workloads establish connections to the promoted database and pass synthetic readiness tests.

Validation ensures application instances are fully operational and will not drop requests during cutover.

Update Cloud DNS routing policy records.

Live user traffic is directed to the restored application infrastructure in us-central1.

Public traffic routing is updated last to prevent blackholing user requests while infrastructure is being promoted.

Key Concept

Disaster Recovery Failover Execution Sequencing

Question 171Question →

An interactive game streaming platform needs to transition its manually provisioned Google Cloud Bigtable clusters and Cloud Storage assets into Terraform management. The platform team requires a safe operational workflow that uses a remote Google Cloud Storage (GCS) backend with state locking to prevent state corruption or service disruption. Arrange the operational steps in the correct sequence to import existing cloud resources into Terraform state.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Write the Terraform HCL code blocks and backend configuration, 2) Run `terraform init` to initialize the remote backend, 3) Execute `terraform import` to bind GCP resource IDs to state, 4) Run `terraform plan` to verify zero drift or unwanted changes, and 5) Execute `terraform apply` to commit the baseline state.

Safely bringing brownfield resources into Terraform management requires defining matching HCL configurations, initializing the GCS remote backend to secure state locks, importing existing GCP resource IDs into state, verifying zero unexpected diffs via `terraform plan`, and finally applying to lock in baseline operational state.

Step-by-Step Solution

Define HCL resource definitions and backend configuration

Local HCL files describe the target infrastructure schema and specify the GCS state bucket location.

Terraform requires code declarations and backend configuration before state operations can be performed.

Execute `terraform init`

The GCS remote state backend is initialized and Google Cloud provider plugins are downloaded.

Backend initialization establishes connectivity and locking mechanisms required for state storage.

Run `terraform import` commands

Live GCP infrastructure objects are mapped to Terraform resource addresses inside the GCS remote state file.

Importing populates state with existing resource attributes without recreating live infrastructure.

Perform `terraform plan` verification

Terraform compares declared HCL with the imported state and outputs a diff report.

Verification ensures that declared configuration attributes match existing GCP resource parameters to prevent accidental destruction.

Run `terraform apply`

The baseline state synchronization is finalized and locked under remote IaC pipeline governance.

Applying completes the import process and verifies that the live environment is fully managed via IaC.

Key Concept

Brownfield Infrastructure as Code Import Workflow

Question 172Question →

A Cloud Architect is establishing a progressive release process using Google Cloud Deploy to update a microservice running on a Google Kubernetes Engine (GKE) cluster. To guarantee reliability and automated health verification before full traffic cutover, place the following deployment pipeline steps in the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with pipeline definition, followed by release creation for the initial canary workload, execution of automated verification tests, promotion to 100% traffic, and maintaining the previous release state for rollback readiness.

A progressive delivery strategy requires defining pipeline rules first, deploying to a limited canary tier second, validating health via automated verification third, promoting to full production fourth, and maintaining previous release history for rapid rollback fifth.

Step-by-Step Solution

Configure the pipeline declarative manifests.

Cloud Deploy and Skaffold configurations establish the delivery target stages and progressive traffic phases.

Infrastructure and pipeline configuration must exist prior to artifact deployment.

Instantiate the release in Cloud Deploy.

Container images and Kubernetes manifests are rendered and deployed to the initial 10% canary phase on GKE.

Creating a release triggers the actual rendering and initial phase deployment.

Run automated verification tasks.

Cloud Deploy verification containers execute tests to measure application health and SLIs on the canary workload.

Automated testing ensures defects are caught while blast radius is limited to canary traffic.

Promote the release to full traffic cutover.

Traffic shifts completely (100%) to the new workload across the GKE cluster upon successful verification.

Promotion gates validate health before replacing the active production version.

Maintain rollback readiness.

The target retains history of the previous stable release manifest.

Preserving previous release states ensures immediate operational recovery if unexpected issues arise post-release.

Key Concept

Progressive Canary Deployment Automation with Cloud Deploy

Question 173Question →

An enterprise cloud engineering team needs to safely transition manually provisioned Google Cloud SQL databases and Cloud Storage buckets into Terraform management while establishing a remote backend for state storage. Order the following operational steps in the correct logical sequence to complete this brownfield IaC onboarding workflow while preventing state corruption or resource re-creation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: 1) Write the HCL configuration code and specify the backend, 2) Run terraform init to configure backend state storage and provider plugins, 3) Execute terraform import commands to map live resources to state, and 4) Run terraform plan to validate zero drift before active management.

The correct sequence begins by defining the resource blocks and backend parameters in HCL. Next, initializing the workspace (`terraform init`) downloads the GCP provider and connects to the GCS remote backend. Once initialized, existing GCP resources can be bound to the state file using `terraform import`. Finally, running `terraform plan` confirms that the HCL definitions perfectly mirror the imported resources, ensuring future automation will not cause unwanted resource replacement.

Step-by-Step Solution

Define configuration and backend

HCL code is declared with backend metadata.

Terraform needs resource block declarations and backend settings before initialization.

Initialize Terraform backend

Provider plugins are downloaded and GCS remote backend is activated.

Backend initialization establishes state locking mechanisms in Cloud Storage before state modifications occur.

Import live infrastructure into state

Remote state file is populated with existing resource attributes.

Terraform import updates state metadata so Terraform becomes aware of existing GCP resources.

Validate state alignment via plan

Verification confirms zero proposed modifications.

Validating alignment ensures HCL configuration accurate matches live infrastructure prior to applying continuous deployments.

Key Concept

Brownfield Infrastructure as Code Adoption and Resource Import Workflow

Question 174Question →

An operations team is establishing an automated canary deployment process for a critical stateless application running on Google Kubernetes Engine (GKE) behind an External HTTP(S) Load Balancer. The deployment pipeline must minimize user risk by using progressive traffic routing and metrics validation. Arrange the steps in the correct chronological order to complete a safe canary release.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for a progressive canary release is: 1) Deploy the candidate release version alongside the existing stable workload, 2) Configure traffic splitting on the backend service to route 5% of traffic to the candidate version, 3) Monitor Cloud Monitoring metrics against SLIs over an observation window, 4) Progressively increase traffic to 100%, and 5) Decommission the old stable workload resources.

A progressive canary release follows a strict sequence: first, the candidate version must be deployed in parallel without receiving traffic. Second, traffic splitting is introduced at a small ratio to limit the blast radius. Third, Cloud Monitoring metrics are evaluated over an observation window to ensure SLIs match SLO requirements. Fourth, traffic is incrementally shifted to 100% upon successful evaluation. Finally, legacy workloads are decommissioned.

Step-by-Step Solution

Provision candidate workload pods

Candidate release running and healthy in parallel with stable workload

Workload pods must be active and passing health checks prior to accepting live requests.

Initialize traffic split

5% of production traffic routed to candidate pods, 95% remains on stable pods

Limits blast radius in case the candidate release contains undetected regressions.

Evaluate operational telemetry

SLIs confirmed within SLO error budget boundaries

Automated verification ensures candidate stability before committing more user traffic.

Complete traffic migration

100% of live traffic routed to candidate release

Gradually scaling traffic completes the transition once stability is validated.

Clean up baseline resources

Old stable deployment deleted; candidate becomes new baseline

Frees compute capacity and avoids configuration drift.

Key Concept

Progressive Canary Release and Traffic Splitting Management

PreviousPage 9 / 9

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes