Examkin

All practice questions

174 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 141Question →

Your organization is establishing an automated, reliable environment provisioning workflow using Terraform and Cloud Build on Google Cloud. What is the correct sequence of steps to safely establish the infrastructure configuration pipeline from initial state storage setup to resource deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with creating the GCS state bucket with versioning, configuring the execution service account and IAM permissions, writing Terraform configurations referencing the GCS backend, running terraform init to configure the backend connection, and finally executing terraform plan and terraform apply.
Establishing IaC automation requires creating prerequisites (GCS state bucket and IAM Service Account), defining configuration code referencing those prerequisites, running terraform init to link the environment, and executing terraform plan and terraform apply to deploy resources safely.

Step-by-Step Solution

1
Provision remote state bucket
A secure GCS bucket with versioning is created to hold terraform.tfstate.
Backend storage infrastructure must exist prior to declaring backend initialization.
2
Configure service account and IAM access
A service account with least-privilege permissions and bucket storage access is generated.
The automated deployment pipeline requires authorized identity access to resources and state storage.
3
Define Terraform code and backend configuration
Terraform files declare GCP providers and link to the GCS backend bucket.
Infrastructure definition files must specify the target state storage location before initialization.
4
Initialize backend via terraform init
Provider plugins are downloaded and remote state lock mechanisms are established.
Initialization binds the workspace context to the remote state infrastructure.
5
Execute terraform plan and terraform apply
Resource modifications are evaluated for drift and successfully provisioned.
Specifying plan before apply guarantees changes are inspected prior to resource creation.

Key Concept

Terraform Automated Environment Provisioning Sequence
Question 142Question →

A retail organization wants to bring a manually created Google Cloud Storage bucket used for transactional archives under Terraform management without destroying the existing bucket. Which sequence of operational steps must the Cloud Architect execute to safely import the bucket into the Terraform state using declarative import configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Declare the resource and import blocks in the HCL configuration file, 2) Execute terraform plan to inspect the import plan without introducing resource destruction, 3) Execute terraform apply to bind the live resource into the remote Cloud Storage state file while acquiring backend locks, and 4) Remove the temporary import block from the configuration.
The correct sequence follows Google Cloud and Terraform best practices for brownfield IaC onboarding: configuration declaration (resource and import blocks), plan verification to prevent resource destruction, apply execution to update state safely with remote backend locking, and post-import cleanup of temporary import metadata.

Step-by-Step Solution

1
Define the target resource block along with an import block specifying the HCL address and live GCP bucket name.
Terraform configuration is prepared with declarative import metadata.
Terraform requires both the HCL schema target and live resource mapping to process an import.
2
Run terraform plan.
The plan output displays an import action without showing any resource replacements or deletions.
Running plan validates that configuration definitions match live infrastructure attributes, preventing accidental destruction.
3
Run terraform apply.
The live resource state is imported into the Google Cloud Storage backend state file.
Applying the plan persists the imported resource into state while maintaining state lock integrity.
4
Remove the import block from the code repository.
The configuration contains only standard resource blocks for ongoing deployment operations.
Leaving import blocks after state registration causes redundant evaluation during future CI/CD execution.

Key Concept

Declarative Infrastructure as Code resource import workflow and state management
Question 143Question →

An enterprise platform engineering team is configuring an automated Cloud Build pipeline to provision a isolated staging environment on Google Cloud using Terraform. Place the procedural steps in the correct order to execute a secure, reliable environment provisioning workflow following Google Cloud best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for environment provisioning is: 1) Authenticate pipeline identity via Workload Identity Federation, 2) Initialize Terraform backend and acquire GCS state lock, 3) Generate a deterministic execution plan artifact, 4) Apply the saved execution plan artifact, and 5) Run post-deployment validation tests and release state locks.
The sequence follows GCP enterprise reliability best practices: establish identity authentication first via Workload Identity Federation, initialize the remote backend to lock state and prevent concurrent updates, generate a deterministic plan artifact to lock in expected changes, apply the exact plan artifact to provision resources, and complete post-provisioning integration testing before releasing state locks.

Step-by-Step Solution

1
Authenticate pipeline service account
Pipeline worker gains temporary authorization without relying on long-lived service account keys.
Workload Identity Federation provides least-privilege security before any backend or API calls occur.
2
Initialize Terraform remote backend
GCS backend establishes connection and acquires state lock.
Remote state initialization is necessary before state drift evaluation or execution planning.
3
Generate plan artifact (`terraform plan -out=tfplan`)
Speculative plan artifact is calculated and saved.
Saving the plan artifact prevents race conditions where cloud state changes between plan and apply steps.
4
Apply the saved plan artifact (`terraform apply tfplan`)
GCP resources are created and configured exactly as planned.
Passing the stored plan guarantees idempotency and deterministic deployment.
5
Execute post-deployment validation
Environment reliability is confirmed and lock is released.
Automated validation ensures operational readiness before declaring successful deployment.

Key Concept

Automated Environment Provisioning & IaC State Lifecycle
Estimated Time:1m 30s
Question 144Question →

An enterprise financial organization is deploying a globally distributed relational database using Cloud Spanner to process cross-border transactions. Security compliance mandates that all database storage must be encrypted using Customer-Managed Encryption Keys (CMEK) managed in a dedicated central security project, and the database schema must be initialized prior to attaching automated backup policies. In what sequential order should the cloud engineering team execute the provisioning and configuration workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by granting the Cloud Spanner Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter IAM role on the central KMS key. Next, provision the multi-region Cloud Spanner instance. Follow this by creating the Cloud Spanner database while specifying the CMEK key URI. Then, execute DDL statements to populate tables and schema definitions. Finally, establish the automated database backup schedule and Point-in-Time Recovery policy.
The correct workflow adheres to cloud security dependency management and resource hierarchy principles. First, pre-requisite IAM permissions must be granted to the Cloud Spanner Service Agent on the Cloud KMS key in the security project. Second, the parent Cloud Spanner instance must be provisioned. Third, the Cloud Spanner database is created while passing the CMEK key URI so that initial storage allocation is encrypted with the custom key. Fourth, DDL statements are executed against the running database to establish tables and indexes. Fifth, automated backup schedules and PITR retention policies are configured to protect the initialized schema and incoming data.

Step-by-Step Solution

1
Grant Cloud KMS IAM Role to Service Agent
The Spanner Service Agent receives permission to call Cloud KMS encrypt and decrypt operations.
If permissions are missing when database creation is invoked, the CMEK authorization check fails immediately.
2
Provision Cloud Spanner Instance
Compute node/processing unit resources and multi-region replication topology are allocated.
Cloud Spanner databases exist logically within a parent Cloud Spanner instance environment.
3
Create Spanner Database with CMEK Parameter
An encrypted database container is initialized with underlying storage bound to the specified Cloud KMS key.
CMEK settings in Cloud Spanner cannot be applied retroactively after standard Google-managed key creation.
4
Apply DDL Schema Definitions
Tables, interleave relationships, indexes, and database-level IAM access roles are created.
Database schema definition requires an active, accessible database target.
5
Attach Automated Backup Schedule Policy
Recurring snapshot backups and PITR windows are activated for operational disaster recovery.
Backup policies protect populated data structures and rely on the complete schema setup.

Key Concept

Cloud Spanner Provisioning and CMEK Integration Workflow
Question 145Question →

An engineering team is building a secure CI/CD pipeline on Google Cloud Platform to deploy a microservice to Cloud Run. Arrange the following SDLC pipeline stages in the correct chronological order from developer commit to full production deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the GCP CI/CD deployment pipeline is: 1) Developer commits source code to Cloud Source Repositories, 2) Cloud Build executes unit tests and builds the container image, 3) Artifact Analysis scans the image for vulnerabilities before storing in Artifact Registry, 4) Cloud Build deploys the new revision to Cloud Run with a 10% canary traffic split, and 5) Cloud Build routes 100% of traffic to the new revision after health checks pass.
The correct sequence follows Google Cloud CI/CD best practices: Source Commit -> Build & Test -> Security Vulnerability Scan -> Canary Traffic Deployment -> 100% Traffic Promotion.

Step-by-Step Solution

1
Identify the pipeline trigger stage.
Developer commit to source control initiates the continuous integration workflow.
Automated pipelines are triggered by code changes pushed to repository branches.
2
Identify the build and integration testing stage.
Cloud Build compiles the container image and runs unit tests.
Code must pass automated tests and build successfully prior to artifact storage.
3
Identify the security governance stage.
Artifact Analysis scans the container image for vulnerabilities before pushing to Artifact Registry.
Vulnerability scanning ensures compromised dependencies are identified before deployment.
4
Identify the initial deployment strategy.
Cloud Build creates a Cloud Run revision with a 10% canary traffic split.
Canary releases minimize blast radius by validating the update against real production traffic.
5
Identify the final production promotion stage.
Shift 100% of production traffic to the new Cloud Run revision.
Full promotion occurs only after metric monitoring verifies the canary release is stable.

Key Concept

Sequencing CI/CD pipeline stages from source code trigger to vulnerability scanning and canary deployment on GCP.
Question 146Question →

An organization is establishing an automated, secure continuous integration and continuous delivery (CI/CD) pipeline on Google Cloud to deploy containerized applications to Google Kubernetes Engine (GKE). Arrange the following pipeline execution stages in the correct sequence from developer code commit to final production verification.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the CI/CD pipeline is: 1) Trigger Cloud Build via repository webhook on code commit, 2) Perform vulnerability scanning with Artifact Analysis before pushing to Artifact Registry, 3) Validate and execute Terraform IaC manifests against GKE, 4) Deploy to staging environment via Cloud Deploy for integration testing, and 5) Promote the release to production via Cloud Deploy with Cloud Monitoring verification.
The sequence follows Google Cloud SDLC best practices: Source trigger -> Build & Security scanning -> Infrastructure/Manifest update -> Staging deployment & testing -> Production promotion & health monitoring.

Step-by-Step Solution

1
Identify the entry point of the continuous integration process.
Code commit triggers the Cloud Build pipeline via webhooks to run unit tests.
CI/CD execution begins at the source control stage.
2
Determine the secure build and artifact generation step.
Images are scanned by Artifact Analysis for vulnerability checks prior to repository storage.
Security shift-left requires scanning artifacts before storing or using them.
3
Locate the infrastructure and environment configuration phase.
Terraform state is checked and GKE manifest changes are applied.
Infrastructure and deployment manifests must be updated with new image tags prior to application deployment.
4
Identify non-production deployment and testing.
Cloud Deploy deploys the application to the staging GKE cluster.
Applications must undergo integration tests in staging before reaching production.
5
Determine the final release promotion step.
Cloud Deploy promotes the build to production while monitoring health indicators.
Production promotion is the final phase of continuous delivery.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Sequencing and Security
Question 147Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Disaster Recovery Failover Execution Workflow
Question 148Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

A telecommunications enterprise is onboarding manually provisioned core network billing resources—including custom VPC subnetworks, firewall rules, and Cloud SQL database instances—into a managed Infrastructure as Code (IaC) workflow using Terraform. The cloud architecture team must safely import these brownfield Google Cloud resources into a remote Cloud Storage (GCS) backend while ensuring zero downtime and preventing state corruption. What is the correct chronological sequence of operational steps to safely import and govern these existing resources using Terraform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with writing matching HCL resource blocks and backend configuration, running `terraform init` to configure plugins and backend storage, executing `terraform import` to map live GCP resource IDs to state addresses, running `terraform plan` to confirm zero drift, and finally committing the verified configuration code to version control.
Safely bringing existing brownfield Google Cloud infrastructure into Terraform requires establishing matching HCL definitions and backend configuration first, initializing backend storage and provider plugins (`init`), mapping live GCP resource IDs into state metadata (`import`), verifying configuration alignment to ensure zero unexpected modifications (`plan`), and committing verified configuration files to Git.

Step-by-Step Solution

1
Construct matching HCL resource declarations and define the GCS backend block.
Target resource schemas and remote state storage mechanisms are declared.
Terraform requires existing HCL declarations and backend configurations before state binding can take place.
2
Run `terraform init` in the root module directory.
Provider binaries are retrieved and GCS state locking is established.
Workspace initialization is mandatory for Terraform to load provider schemas and connect to state backends.
3
Execute `terraform import` for each live GCP resource.
Live resource attributes are populated into the state file without disrupting live services.
Import binds physical cloud resource unique identifiers to declared HCL state objects.
4
Run `terraform plan` to evaluate configuration alignment.
Plan output validates zero pending changes or unexpected resource replacements.
Verification ensures the manually written HCL matches all imported live infrastructure properties.
5
Commit code and lockfiles to version control.
Baseline IaC governance and CI/CD versioning are established.
Version controlling validated HCL configurations prevents state divergence across engineering teams.

Key Concept

Brownfield Resource Import and IaC State Governance
Question 150Question →

An SRE team plans to execute a canary release for a critical service deployed on Google Kubernetes Engine (GKE) to safely introduce a new application revision. Order the following operational steps in the correct sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for conducting a canary release is to first deploy the new workload revision alongside the stable baseline, route a small fraction of traffic to it, monitor observability metrics for reliability, and finally shift 100% of traffic to the new revision while decommissioning old resources.
A standard canary release follows a structured progression: provision the new revision, split a small percentage of live traffic to test real-world behavior, evaluate telemetry against SLO performance standards, and finally promote the release to 100% traffic while terminating the old workload.

Step-by-Step Solution

1
Deploy the new container revision to GKE without routing production traffic to it yet.
The canary workload is running independently next to the production workload.
Allows verification of basic health checks before exposing any real user requests.
2
Update traffic splitting rules at the load balancer/ingress level to route 5% of traffic to the canary revision.
A controlled subset of users hits the new application code.
Limits exposure and potential business impact in case hidden defects exist.
3
Analyze error rates, latency distribution, and CPU/memory utilization using Cloud Monitoring and Logging.
Metrics confirm the canary revision meets defined SLOs without consuming excessive error budget.
Empirical verification of reliability is required before proceeding with full deployment.
4
Promote the canary revision to receive 100% of production traffic and scale down old pods.
Deployment is complete and resource utilization is optimized.
Finalizes the release lifecycle safely.

Key Concept

Canary Deployment Workflow and Traffic Splitting
Question 151Question →

Your Site Reliability Engineering (SRE) team is designing an end-to-end automated incident response and escalation workflow on Google Cloud to handle severe latency spikes in an enterprise web application. Place the operational steps in the correct chronological sequence from initial fault detection to incident resolution.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with Cloud Monitoring evaluating the SLI burn rate threshold, followed by publishing an alert payload to Pub/Sub, triggering a Cloud Function to execute automated remediation, and concluding with Cloud Monitoring verifying metric recovery to auto-resolve the incident.
The workflow follows a standard event-driven incident lifecycle: Detection (evaluating SLI burn rate) -> Notification (publishing to Pub/Sub) -> Action (executing programmatic remediation via Cloud Function) -> Verification & Resolution (monitoring SLI stabilization and closing the alert).

Step-by-Step Solution

1
Detect metric anomaly
Cloud Monitoring identifies an SLO burn rate condition breach over the specified evaluation window.
Alerting policies continuously monitor SLI metrics before triggering notification mechanisms.
2
Trigger notification channel
An incident payload is pushed to a Pub/Sub topic dedicated to operational automation.
Pub/Sub decouples alert detection from programmatic downstream remediation logic.
3
Execute automated mitigation
A Cloud Function processes the alert payload and dynamically updates infrastructure configurations.
Event-driven serverless functions provide immediate, hands-free self-healing capabilities.
4
Verify recovery and resolve
Metric values stabilize below the alert threshold, marking the incident state as resolved.
Cloud Monitoring validates that the remediation successfully restored service health before closing the alert.

Key Concept

Automated Incident Remediation and Alert Escalation Workflow
Question 152Question →

A security architect needs to configure secure, keyless developer access to GCP Secret Manager across Google Cloud projects. The compliance policy strictly prohibits generating or downloading external JSON service account keys. Place the steps required to establish secure service account impersonation for short-lived credential generation in the correct logical sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by defining the target service account identity, configuring least-privilege access permissions on Secret Manager resources, assigning the Service Account Token Creator role to developer user principals, and finally configuring application client tools to impersonate the service account via short-lived credentials.
The valid sequence establishes infrastructure identity first (target service account creation), applies least-privilege authorization to the Secret Manager resources next, assigns short-lived token generation permissions (Token Creator role) on the service account identity to user groups, and lastly configures the local developer execution environment to request impersonated credentials.

Step-by-Step Solution

1
Provision the target workload identity
A dedicated service account exists in the project containing the target secrets.
Security best practices mandate establishing a distinct service account principal dedicated to specific resource access.
2
Assign resource-level access permissions
The target service account is granted secretaccessor privileges on Secret Manager resources.
Enforcing the principle of least privilege ensures the service account can only perform allowed API actions on designated secrets.
3
Delegate impersonation permissions to user principals
Developer user identities are granted roles/iam.serviceAccountTokenCreator on the target service account resource.
Impersonation requires explicit IAM authorization allowing the user identity to mint short-lived credentials for the target service account.
4
Initialize client context for impersonated API calls
Developers run API calls using short-lived tokens generated on-the-fly without static key downloads.
Configuring client tooling to use impersonation flags seamlessly redirects request authorization through the IAM Credentials API.

Key Concept

Service Account Impersonation and Short-Lived Credentials Lifecycle Security
Question 153Question →

An enterprise online reservation platform hosts its core booking microservice on Google Kubernetes Engine (GKE) backed by a Cloud SQL for PostgreSQL database. The platform team needs to execute a zero-downtime release featuring a major application update and a breaking database schema migration. What is the correct sequence of steps to safely execute this blue-green deployment without service disruption or data corruption?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Execute the expand database migration to add new schema elements without breaking existing logic, 2) Deploy the Green microservice revision to GKE while keeping live traffic on Blue, 3) Update the HTTPRoute resource to shift traffic to Green, and 4) Execute the contract database migration to clean up legacy schema objects once Green stability is confirmed.
Executing a zero-downtime release with breaking database schema changes requires decoupled, backwards-compatible deployment phases. First, the database schema must be expanded by adding new columns as nullable or with defaults, allowing the running Blue version to operate uninterrupted. Next, the Green workload is deployed in parallel on GKE to verify its readiness. Traffic is then shifted instantly using GKE routing controls. Finally, after validating the Green release and draining Blue connections, a contract migration safely removes the legacy database columns.

Step-by-Step Solution

1
Expand Database Schema
Database supports both old and new application versions simultaneously.
Prevents database exceptions in the currently active Blue deployment when new database structures are introduced.
2
Deploy Green Environment
Green application version is running and healthy in GKE, isolated from user traffic.
Allows verification of new container pods without exposing live end-users to unverified pods.
3
Shift Traffic to Green
100% of production traffic is processed by the new Green application release.
Executes a zero-downtime cutover at the networking layer.
4
Contract Database Schema
Legacy schema columns and unused database objects are safely purged.
Completes the schema evolution lifecycle once rollback to the Blue version is no longer required.

Key Concept

Expand-Contract Database Migration Pattern in Blue-Green Deployments
Question 154Question →

A cloud architecture team needs to establish a standard Terraform workflow to manage Google Cloud infrastructure with remote state management. What is the correct sequence of steps to configure and execute this Infrastructure as Code workflow from start to finish?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations begins with creating the GCS remote state bucket, followed by configuring the backend in Terraform code, initializing the directory with `terraform init`, generating an execution plan with `terraform plan`, and finally applying the configuration with `terraform apply`.
The standard Terraform deployment sequence requires establishing backend state storage before initialization, initializing the working directory before planning changes, and reviewing an execution plan before applying infrastructure modifications to Google Cloud.

Step-by-Step Solution

1
Provision remote state storage infrastructure
A Cloud Storage bucket with versioning is ready to serve as the backend.
Terraform requires an existing storage location before it can bind its state remotely.
2
Configure the Terraform backend code block
The Terraform code points to the created Cloud Storage bucket.
Declarative backend configuration establishes the connection parameters for remote state tracking.
3
Run initialization command
Provider plugins are downloaded and the backend state storage connection is initialized.
`terraform init` must be executed before planning or applying infrastructure.
4
Run speculative plan preview
An execution plan is generated detailing resource additions, modifications, or deletions.
`terraform plan` ensures safety and operational predictability prior to resource mutation.
5
Apply infrastructure changes
GCP resources are created or modified and state is locked and updated in Cloud Storage.
`terraform apply` executes the planned actions against the live Google Cloud environment.

Key Concept

Terraform Remote State Workflow Lifecycle
Question 155Question →

A Site Reliability Engineering (SRE) team is implementing an end-to-end incident management and automated alerting workflow on Google Cloud to handle service level objective (SLO) breaches. In what sequence should the SRE team structure the automated detection, notification, triage, and human escalation pipeline? Arrange the steps in the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with defining the SLO and burn-rate alert policy in Cloud Monitoring, followed by attaching a Cloud Pub/Sub notification channel, executing automated diagnostic checks and alert muting via a Cloud Run subscriber, and finally escalating to the human on-call responder if manual intervention is required.
The correct workflow adheres to Google SRE best practices for incident response: establishing measurement baselines (SLO burn-rate alerting), publishing incident events asynchronously (Cloud Pub/Sub), executing automated triage and alert suppression (Cloud Run subscriber), and escalating remaining critical incidents to human responders.

Step-by-Step Solution

1
Establish detection baselines
Cloud Monitoring multi-window burn-rate alert policy is configured.
SLO error budget depletion must be monitored before any downstream alerting or event processing can occur.
2
Configure event notification channels
Alert notifications are routed asynchronously to Cloud Pub/Sub.
Pub/Sub decouples metric detection from incident response actions, allowing multiple downstream subscribers to consume alert events.
3
Execute automated triage and alert suppression
Cloud Run subscriber ingests the incident payload, gathers logs, and suppresses noise.
Automated first-response scripts prevent alert storms and enrich incident context prior to paging human operators.
4
Escalate to human responders
On-call engineers receive enriched incident details on their paging system.
Human intervention should be reserved for unresolved or high-impact incidents requiring manual decision-making.

Key Concept

Automated Incident Management and Alert Escalation Lifecycle
Question 156Question →

A global media streaming platform hosts its live session state and metadata processing engine on Google Cloud across two regions. The primary active region is us-west1 and the passive disaster recovery region is us-east1. The architecture utilizes Cloud Bigtable for high-throughput session state, Google Kubernetes Engine (GKE) for stateless microservices, and Cloud DNS routing policies for external traffic management. A catastrophic zone-wide power failure has disabled the us-west1 infrastructure. What is the correct sequence of steps to execute the regional failover runbook to restore full operational capacity in us-east1 while maintaining data consistency?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by updating Cloud DNS to isolate ingress traffic from us-west1, followed by reconfiguring the Cloud Bigtable application profile to single-cluster routing in us-east1, then scaling GKE compute resources in us-east1 using capacity reservations, and finally validating SLIs before routing live production traffic to us-east1.
Executing a disaster recovery failover requires strict adherence to dependency order: first, isolate traffic to halt invalid writes to the primary region; second, reconfigure stateful database application profiles to target the standby region; third, scale compute resources using capacity reservations; fourth, verify monitoring health metrics before opening live traffic ingress to the secondary region.

Step-by-Step Solution

1
Isolate the failing region by updating Cloud DNS routing policy.
Prevents ongoing transactions from failing or causing data inconsistency in us-west1.
Traffic isolation must precede failover actions to stop split-brain state creation.
2
Reconfigure Cloud Bigtable application profile for single-cluster routing to us-east1.
Ensures all incoming state updates target the healthy us-east1 Bigtable cluster.
Stateful data tier routing must be explicitly reconfigured before compute microservices attempt writes.
3
Scale the secondary GKE deployment in us-east1 to full production capacity.
Secondary compute nodes and pods expand to process 100% of production traffic.
Stateless compute capacity must be fully provisioned while the database tier is ready.
4
Verify service metrics in Cloud Monitoring and shift external load balancer ingress traffic.
Full production traffic is safely served out of us-east1 without downtime or data corruption.
Validation of health check endpoints and SLIs ensures the failover was successful before public traffic cutover.

Key Concept

Disaster Recovery Execution and Regional Failover Ordering
Question 157Question →

An e-commerce platform hosted on Google Kubernetes Engine (GKE) backed by Cloud SQL for PostgreSQL is executing a zero-downtime release for its order processing microservice. The update introduces breaking database schema changes. To maintain service availability throughout the rollout, the engineering team must combine an Expand-Contract database migration pattern with a Blue-Green deployment strategy.

Which sequence represents the correct chronological order of steps from FIRST to LAST to safely execute this zero-downtime deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Apply non-destructive additive database migrations (Expand phase); 2) Deploy the new application version (Green environment) on GKE; 3) Update Cloud Load Balancing to shift live traffic to the Green environment; 4) Execute destructive database cleanup operations (Contract phase).
Executing a zero-downtime release with breaking database schema changes requires an Expand-Contract pattern combined with Blue-Green deployment. First, the database is expanded with additive, backward-compatible schema modifications so both old and new code versions can run. Second, the new Green application version is deployed alongside the Blue version. Third, traffic is shifted at the Cloud Load Balancer level from Blue to Green. Fourth, once the Blue version is safely drained and stopped, destructive schema cleanups (Contract phase) remove deprecated database fields.

Step-by-Step Solution

1
Apply additive schema migrations (Expand phase)
The database schema supports both the current schema columns/tables and the new required columns/tables simultaneously.
Applying database migrations additively ensures that currently running instances (Blue) do not fail when querying the database while the database is updated.
2
Deploy the Green application environment
The new version of the microservice runs on GKE in parallel with the Blue version without receiving live customer traffic.
Deploying Green instances in isolation allows internal health checks and smoke testing against the expanded database schema before user traffic is introduced.
3
Shift production traffic to the Green environment
Cloud Load Balancing routes all incoming user requests to the Green pods.
Switching traffic at the load balancer level instantly shifts user traffic to the validated Green version while keeping the Blue environment idle as an immediate rollback target if needed.
4
Execute destructive schema migrations (Contract phase)
Deprecated database columns and tables are removed, and the Blue application environment is decommissioned.
Removing deprecated columns can only occur after all dependencies on the old schema are removed and the old Blue application instances are turned off.

Key Concept

Expand-Contract Database Migration with Blue-Green Deployments
Question 158Question →

A platform engineer needs to configure a software developer's local environment to run Python scripts that programmatically manage Google Cloud Storage buckets using Google Cloud Client Libraries. Enterprise security policy strictly prohibits downloading JSON service account keys. The scripts must run using the identity and permissions of a target service account. Place the operational steps in the correct chronological sequence to establish secure programmatic access via Application Default Credentials (ADC) with service account impersonation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with granting the user identity the Service Account Token Creator role on the target service account, followed by authenticating the user session via gcloud auth login, generating local ADC with impersonation using gcloud auth application-default login --impersonate-service-account, and finally running Python code that initializes Google Cloud Client Libraries using standard ADC auto-discovery.
To enable secure local programmatic interaction with GCP APIs without downloading key files, IAM impersonation permissions must first be granted via the Service Account Token Creator role on the target service account. The developer then logs in with user credentials using gcloud auth login. Next, Application Default Credentials (ADC) are configured with impersonation via gcloud auth application-default login --impersonate-service-account. Finally, the Python application code initializes Google Cloud Client Libraries using standard ADC detection, executing securely under the target service account identity.

Step-by-Step Solution

1
Assign the Service Account Token Creator IAM role on the target service account
The developer identity acquires permission to generate tokens on behalf of the service account
Service account impersonation requires explicit token creation permissions granted on the target service account resource.
2
Authenticate user credentials with gcloud auth login
An active user credential session is stored locally for gcloud CLI operations
gcloud requires an authenticated principal session to authorize token exchange requests for service account impersonation.
3
Generate local ADC configured for service account impersonation
Application Default Credentials file is written referencing the impersonated service account email
Executing gcloud auth application-default login with the --impersonate-service-account flag configures the local ADC configuration for seamless SDK consumption.
4
Initialize Google Cloud Client Library in application code
The application makes API calls authorized under the target service account identity without downloading private keys
Google Cloud SDK client libraries automatically locate the ADC configuration file and handle short-lived token requests behind the scenes.

Key Concept

Application Default Credentials (ADC) with Service Account Impersonation
Estimated Time:2m 0s
Question 159Question →

An enterprise engineering team is implementing a zero-downtime Blue-Green release process on Google Cloud for a critical transactional service backed by a Cloud Spanner database. The release includes non-backward-compatible application logic and database schema changes. In which logical sequence should the team perform the deployment operations to ensure zero service disruption and safe rollback capabilities?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: First, apply additive database schema changes (expand phase). Second, deploy and validate the new version in the isolated green environment. Third, switch live traffic to the green environment using the Cloud Load Balancer. Fourth, execute destructive schema cleanup (contract phase) after decommissioning the legacy blue environment.
Safe release management with database migrations requires an expand-contract pattern. Additive database changes must precede application deployment so the active environment remains unaffected. Next, the new code version is deployed to an isolated green environment for verification. Once validated, traffic is shifted atomically at the load balancer layer. Finally, after the legacy blue environment is drained and decommissioned, destructive database cleanup (contract phase) can safely run.

Step-by-Step Solution

1
Execute expand-phase DDL operations on the database.
Database supports both old and new schema fields simultaneously without breaking the active production version.
Prevents database errors in the currently active blue environment while preparing the database for the new software version.
2
Deploy and test the new release in the green environment.
The green environment is fully provisioned, initialized, and health-checked without accepting public traffic.
Ensures that application startup, dependencies, and diagnostic endpoints are fully functional prior to traffic cutover.
3
Shift production traffic to the green environment.
Cloud Load Balancer directs incoming end-user requests to the green environment instances.
Achieves zero-downtime cutover while keeping the blue environment on standby for immediate rollback if unexpected errors occur.
4
Decommission the blue environment and execute contract-phase DDL cleanup.
Legacy compute resources are released and deprecated database fields are removed.
Completes the release lifecycle safely after confirming stability and closing the rollback window.

Key Concept

Zero-Downtime Blue-Green Deployments with Expand-Contract Database Schema Migration
Estimated Time:2m 30s
Question 160Question →

A financial services enterprise is establishing a release validation procedure for a mission-critical fraud detection processing system on Google Cloud. As the Principal Cloud Architect, you must sequence the testing and validation phases to ensure zero-downtime deployment, service quota adequacy, and technical solution verification prior to full customer traffic exposure. In what order should these deployment and validation steps be executed from first to last?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with IaC dry-run and IAM policy validation, followed by staging infrastructure provisioning with pre-flight quota and connectivity tests, followed by load and SLO validation under peak stress in staging, and concludes with a canary deployment in production.
A complete GCP architectural validation procedure follows a progressive shift-left methodology: static code/IaC verification comes first, followed by functional staging provisioning with quota checks, then stress and load testing for SLO adherence, and finally a controlled canary rollout to production.

Step-by-Step Solution

1
Validate IaC and IAM Security Boundaries
Identifies syntax errors, state conflicts, and permission violations prior to provisioning resources.
Static analysis and dry-run execution prevent broken or insecure infrastructure changes from attempting resource creation.
2
Provision Staging and Run Pre-flight Functional Tests
Verifies that API quotas, network paths, and synthetic telemetry process successfully.
Functional validation ensures all downstream dependencies and Cloud API limits are healthy before applying high traffic volume.
3
Execute Load and Resilience Stress Testing
Confirms system scaling behavior and SLO compliance under simulated operational peak traffic.
Load testing reveals performance bottlenecks and auto-scaling limits in a controlled staging environment prior to production exposure.
4
Initiate Canary Production Deployment
Gradually routes live traffic while evaluating error budgets and monitoring metrics.
Canary releases minimize customer impact in production, allowing safe rollback if telemetry indicates unexpected failures.

Key Concept

Phased Technical Solution Testing and Release Validation Strategy
PreviousPage 8 / 9Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin