Examkin

All practice questions

174 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 121Question →

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 122Question →

A Cloud Architect is establishing permission governance for a renewable energy management platform in Google Cloud. Arrange the levels of the Google Cloud resource hierarchy in order from the highest ancestor node at the top down to the individual resource level at the bottom to illustrate how inherited IAM permissions propagate downward.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct hierarchy order from top to bottom is Organization Node, followed by Folder Node, Project Node, and finally Resource Node.
Google Cloud IAM enforces policy inheritance down a strict four-level hierarchy: Organization -> Folder -> Project -> Resource. Permissions granted at higher levels automatically propagate down to all contained child nodes.

Step-by-Step Solution

1
Identify the root ancestor in Google Cloud IAM resource management.
The Organization node is identified as the root element (level 1).
In Google Cloud, the Organization node represents the company domain and sits at the top of the resource hierarchy.
2
Identify the intermediate grouping layer designed for organizational unit management.
The Folder node is identified as the level directly beneath the Organization (level 2).
Folders allow organizing projects into sub-trees for environment separation (e.g., Prod, Dev) and policy inheritance.
3
Identify the core administrative boundary where APIs and billing are enabled.
The Project node is placed below Folders (level 3).
Projects are child elements of Folders or Organizations and hold service resource instances.
4
Identify the actual GCP service instance level where data and compute reside.
The Resource node is identified as the lowest leaf node (level 4).
Individual services (e.g., GCS bucket, Compute Engine instance) are created inside projects and inherit IAM policies from all parent nodes.

Key Concept

Google Cloud Resource Hierarchy and IAM Policy Inheritance
Question 123Question →

What is the correct sequential order of steps in Google Cloud for managing an automated alerting lifecycle and incident response, starting from metric detection to post-incident review?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with Cloud Monitoring detecting a metric threshold breach and opening an incident, followed by sending notification payloads via Pub/Sub, running automated diagnostic triage scripts, notifying on-call personnel for remediation, and concluding with incident closure and post-incident threshold refinement.
The standard incident management workflow begins with automated metric breach detection in Cloud Monitoring. Next, the alert engine dispatches messages via Pub/Sub notification channels. Automated handlers (such as Cloud Run) extract diagnostic logs to triage the event. On-call engineers use this context to resolve the issue, and finally, the incident is closed and followed by a blameless post-mortem review.

Step-by-Step Solution

1
Identify the detection phase.
Cloud Monitoring evaluates metrics and opens an incident upon threshold violation.
Alerting systems require a condition breach to initiate an incident payload.
2
Identify the notification dispatch phase.
Cloud Monitoring publishes the incident details to a Pub/Sub notification channel.
Notification channels route alerts from Monitoring to downstream integrations.
3
Identify the automated remediation/triage phase.
Cloud Run consumes the Pub/Sub alert event to query Cloud Logging for diagnostics.
Automated event handlers enhance incident context before human intervention.
4
Identify the human incident response phase.
On-call engineers receive alerts, acknowledge the issue, and execute mitigation.
Engineers resolve complex root causes once automated enrichment provides context.
5
Identify the post-incident learning phase.
The team closes the incident and conducts a post-mortem to update alert policies.
Continuous operational improvement relies on post-incident threshold review.

Key Concept

Incident Management Lifecycle and Automated Alerting
Question 124Question →

Your organization operates a real-time transaction processing API on Google Cloud. To maintain strict reliability standards, you are implementing an automated incident management and escalation workflow using Google Cloud Observability tools. Order the operational steps sequentially from initial anomaly detection to full incident resolution and notification.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with Cloud Monitoring detecting an SLO error budget burn rate breach, followed by publishing an alert event to a Pub/Sub topic notification channel, triggering an automated Cloud Run remediation service to restore performance capacity, and concluding with Cloud Monitoring verifying metric recovery and resolving the incident.
In GCP Site Reliability Engineering practices, incident management starts with metric-driven anomaly detection (SLO burn rate evaluation). Upon detecting a breach, Cloud Monitoring uses Pub/Sub notification channels to asynchronously trigger automated remediation code (such as Cloud Run or Cloud Functions). Once the automated action restores service metrics, Cloud Monitoring validates recovery and marks the incident resolved.

Step-by-Step Solution

1
Detect metric anomaly using SLO burn rate alerting policy
An alert incident is created in Cloud Monitoring when latency SLIs breach the error budget threshold.
Incident response workflows begin with automated threshold detection based on SLIs/SLOs.
2
Dispatch incident payload to automated notification channel
A structured incident message is delivered to a GCP Pub/Sub topic.
Pub/Sub serves as an asynchronous event bus decoupler for downstream automated remediation.
3
Trigger event-driven remediation service
Cloud Run consumes the Pub/Sub message and executes mitigation steps to scale up compute infrastructure.
Automated response minimizes Mean Time to Resolution (MTTR) before human escalation.
4
Verify metric stabilization and auto-close incident
Cloud Monitoring registers normal SLI levels, closes the open incident, and logs final resolution.
Alert policies automatically mark incidents resolved once conditions return below threshold levels for the re-evaluation duration.

Key Concept

Event-driven automated incident management and escalation pipelines using Cloud Monitoring, Pub/Sub, and Cloud Run.
Question 125Question →

Your organization is establishing an automated incident management workflow in Google Cloud to rapidly mitigate unexpected latency spikes in a critical microservice. Place the following operational and technical steps in the correct chronological order from initial detection setup to post-incident validation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Configure a Cloud Monitoring alerting policy based on microservice latency threshold conditions, 2) Attach a Google Cloud Pub/Sub topic notification channel to the configured alerting policy, 3) Execute automated remediation via an event-driven Cloud Run function triggered by incoming Pub/Sub alert messages, and 4) Verify incident resolution and post-remediation service health using Cloud Monitoring dashboards.
The workflow follows a standard event-driven incident lifecycle in GCP: first establishing detection thresholds in Cloud Monitoring, next integrating an asynchronous Pub/Sub notification channel, then triggering automated serverless remediation upon incident creation, and finally confirming metric normalization on operational dashboards.

Step-by-Step Solution

1
Define threshold detection rules
Cloud Monitoring policy actively monitors latency telemetry for condition breaches.
Automated incident management requires explicit SLI/SLO threshold boundaries to trigger alerts.
2
Bind Pub/Sub notification channel to the policy
Alert state transitions publish structured incident payloads to the designated Pub/Sub topic.
Pub/Sub provides an asynchronous, decoupled broker for event-driven automation in GCP.
3
Trigger programmatic remediation
Cloud Run function ingests the alert event and scales backend resources or adjusts traffic routing.
Automated mitigation logic must execute in response to alert notifications to reduce mean time to resolution (MTTR).
4
Validate service recovery
Cloud Monitoring metrics confirm latency has subsided and error budgets are preserved.
Post-incident verification confirms the automated action successfully resolved the incident without manual intervention.

Key Concept

Automated Incident Escalation and Event-Driven Remediation
Question 126Question →

A cloud architecture team at a healthcare informatics enterprise is transitioning manually provisioned Google Cloud VPC networks and subnetworks into an automated Infrastructure as Code (IaC) workflow managed by Terraform. The team must establish remote state management with state locking, avoid resource recreation, and ensure existing production workloads experience zero downtime during the adoption process. What is the correct sequence of steps to safely import these unmanaged GCP infrastructure resources into Terraform state and align the HCL configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with establishing the Cloud Storage backend configuration and versioning, followed by running terraform init to initialize backend locks. Next, empty or skeleton resource blocks must be declared in HCL so that terraform import commands can bind GCP resource URIs to state addresses. Finally, running terraform plan and adjusting HCL attributes until zero differences remain ensures complete state and code parity without service disruption.
The sequence correctly follows Google Cloud and Terraform best practices for brownfield adoption: 1) Backend setup (GCS bucket + code block), 2) Workspace initialization (terraform init), 3) HCL block declaration, 4) Resource state import (terraform import), and 5) Plan validation and attribute alignment (terraform plan).

Step-by-Step Solution

1
Configure the GCS remote backend bucket with versioning and add the backend "gcs" block to HCL.
Defines the centralized remote state target and locking storage.
Remote state infrastructure must exist prior to initializing Terraform.
2
Run terraform init.
Connects the local workspace to the GCS backend and downloads provider plugins.
State locking and remote storage initialization must precede state modification commands.
3
Declare empty HCL resource blocks (e.g., google_compute_network and google_compute_subnetwork).
Establishes addressable targets within the Terraform configuration.
Terraform import requires an addressable HCL resource block target to bind imported attributes.
4
Execute terraform import commands targeting specific GCP resource URIs.
Populates the GCS remote state file with actual GCP resource attributes.
Brings unmanaged live infrastructure into Terraform state without making runtime changes.
5
Run terraform plan and refine HCL parameters until output indicates 'No changes'.
Achieves complete parity between local code, remote state, and live GCP resources.
Prevents terraform apply from inadvertently modifying or destroying production resources.

Key Concept

Brownfield Infrastructure Import and IaC State Alignment
Question 127Question →

An enterprise architecture team is designing an automated continuous integration and continuous delivery (CI/CD) pipeline on Google Cloud to securely build, verify, and release containerized microservices to Google Kubernetes Engine (GKE). The pipeline architecture incorporates Cloud Build, Artifact Registry, Binary Authorization, and Cloud Deploy. In what chronological sequence should the pipeline stages execute from initial code submission to final production deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the GCP CI/CD pipeline is: 1) Cloud Build compiles source code and builds the container image; 2) Artifact Registry stores the image and Container Analysis scans for vulnerabilities; 3) Binary Authorization verifies scan results and signs the image digest; 4) Cloud Deploy creates a release and deploys to staging GKE; 5) Cloud Deploy verifies staging health and promotes the release to production GKE.
The pipeline logically flows from artifact creation (Cloud Build) to storage/security scanning (Artifact Registry and Container Analysis), governance attestation (Binary Authorization), staging deployment orchestration (Cloud Deploy), and finally automated production promotion following verification.

Step-by-Step Solution

1
Trigger Continuous Integration Build
Cloud Build compiles source code and produces a container artifact.
Source code compilation and artifact generation are the initial steps in any CI/CD workflow.
2
Store and Scan Artifact
The container image is pushed to Artifact Registry and scanned for vulnerabilities.
Artifacts must be centralized and security-scanned before validation or deployment.
3
Cryptographic Attestation
Binary Authorization attestors verify scan compliance and sign the artifact digest.
Binary Authorization policies require an attestation before GKE admission controllers allow deployment.
4
Staging Release Rollout
Cloud Deploy creates a pipeline release and deploys the attested container to the staging target.
Progressive delivery tools require signed digests before initiating target deployments.
5
Verification and Production Promotion
Staging integration tests validate application health before advancing to production.
Automated verification ensures zero-downtime production deployment gating.

Key Concept

Secure GCP CI/CD Pipeline Lifecycle with Cloud Build, Artifact Registry, Binary Authorization, and Cloud Deploy
Question 128Question →

A cloud operations team is establishing an automated incident management and escalation architecture on Google Cloud for a high-throughput healthcare data ingestion service. The team needs to build a workflow that moves from reliability metric definition to alert trigger routing, automated remediation execution, and alert suppression. In what chronological sequence should the cloud architect configure these operational components?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with establishing SLIs/SLOs, configuring the multi-window burn-rate alerting policy, binding a Pub/Sub notification channel, deploying the Cloud Run automated remediation worker, and finally setting up a Cloud Monitoring Muting Rule to suppress secondary alerts during active mitigation.
The proper architectural sequence begins by defining SLIs and SLOs to establish an error budget baseline. Next, a multi-window burn-rate alerting policy evaluates error budget consumption. When triggered, the policy publishes incident notifications to a Pub/Sub topic channel. A Cloud Run remediation service consumes these Pub/Sub messages to execute automated fixes. Finally, Cloud Monitoring Muting Rules suppress secondary alert noise while remediation takes effect.

Step-by-Step Solution

1
Establish foundational reliability metrics.
SLIs and SLOs are created in Cloud Monitoring, defining the service error budget.
You cannot monitor error budget consumption or trigger burn-rate alerts without first defining the baseline SLI and target SLO.
2
Configure the alerting logic based on error budget consumption.
A multi-window, multi-burn-rate alerting policy is established.
Evaluating burn rate requires the defined SLO and error budget to calculate short and long time window consumption.
3
Connect the alert policy to an event-driven messaging channel.
Cloud Monitoring posts incident payload metadata to a designated Pub/Sub topic.
Programmatic incident workflows require event-driven notification channels to pass alert details to automation handlers.
4
Implement automated remediation handlers.
A Cloud Run worker consumes the Pub/Sub event payload and initiates infrastructure or application mitigations.
The remediation service depends on Pub/Sub alert messages to trigger mitigation logic.
5
Suppress redundant secondary notifications.
A Cloud Monitoring Muting Rule suppresses downstream alert floods during remediation.
Muting rules ensure engineers are not spammed by collateral alerts while the automated fix is actively resolving the primary issue.

Key Concept

Incident Response and Automated Alerting Workflow Design
Estimated Time:2m 30s
Question 129Question →

An enterprise Cloud Architecture team is establishing an end-to-end automated incident detection and self-healing remediation workflow on Google Cloud for a microservice encountering resource exhaustion. Arrange the operational steps in the correct chronological order from initial alerting setup through incident resolution.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence follows the full lifecycle of automated incident detection and remediation: configuring alerting policies with Pub/Sub notification targets, publishing alert payloads upon metric breach, triggering event-driven remediation functions, executing API remediation calls to restore workload health, and auto-closing the incident in Cloud Monitoring upon metric recovery.
The proper operational order follows a logical incident lifecycle: proactive monitoring configuration, metric breach detection with event publishing via Pub/Sub, serverless event ingestion and payload parsing, execution of automated API remediation scripts, and final auto-closure of the incident state by Cloud Monitoring upon verified service recovery.

Step-by-Step Solution

1
Configure Cloud Monitoring alert policies and notification targets
Sets baseline alert thresholds and establishes the Pub/Sub integration pathway.
Alerting policies and messaging channels must be provisioned prior to handling live operational incidents.
2
Emit incident event payload to Pub/Sub
Publishes structured incident metadata when performance thresholds are exceeded.
Cloud Monitoring decouples detection from remediation by delivering alerts via Pub/Sub messaging.
3
Ingest payload via event-driven Cloud Function
Parses resource identifiers and operational context securely using service account IAM roles.
Remediation functions require parsed message attributes to identify specific failing resources.
4
Execute programmatic remediation API calls
Restores instance health through automated lifecycle management commands.
Direct action against Cloud APIs mitigates operational outages without human intervention.
5
Validate metric recovery and resolve incident state
Updates incident telemetry and auto-closes open incident tickets in Monitoring.
Cloud Monitoring automatically closes incidents once consecutive healthy evaluation periods pass.

Key Concept

Automated Incident Lifecycle Management and Event-Driven Remediation in Google Cloud
Question 130Question →

A security architect is configuring keyless authentication for an external CI/CD runner to fetch database credentials stored in GCP Secret Manager. To comply with zero-trust security standards and prevent credential leakage, the architect decides to implement Workload Identity Federation using OpenID Connect (OIDC). What is the correct chronological sequence of administrative steps required to establish keyless authentication and retrieve the secret payload?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the Workload Identity Pool, adding the OIDC Workload Identity Provider, provisioning a dedicated target Service Account with least privilege, binding the external principal using the Workload Identity User role, and finally exchanging the external OIDC token for a short-lived GCP access token via STS.
The correct order follows the standard setup lifecycle for Workload Identity Federation: first establishing the infrastructure container (Workload Identity Pool), then configuring provider authentication parameters (OIDC Provider), provisioning a target identity with least privilege (Service Account with Secret Accessor role), mapping authorization between the external identity and target identity (Workload Identity User role), and executing runtime short-lived token exchange via STS.

Step-by-Step Solution

1
Establish the federated container by creating a Workload Identity Pool.
Workload Identity Pool is created in the target GCP project.
The pool serves as the trust boundary for external workloads.
2
Configure the OIDC Provider within the Workload Identity Pool.
Google Cloud IAM can validate external JWT assertions against the issuer and audience.
Provider settings enable validation and attribute extraction from third-party tokens.
3
Create the target Service Account and assign the Secret Manager Secret Accessor role.
The Service Account gains granular access to read secret versions without broad project-level permissions.
Adheres to the principle of least privilege.
4
Grant the Workload Identity User role on the Service Account to the external workload principal.
The external OIDC principal is authorized to impersonate the GCP Service Account.
Establishes authorization for token impersonation.
5
Perform runtime token exchange via the Security Token Service (STS) and request the secret payload.
The workload receives a short-lived GCP access token and successfully reads the secret payload.
Completes the keyless authentication workflow securely without long-lived keys.

Key Concept

Workload Identity Federation lifecycle for external keyless authentication to Secret Manager
Question 131Question →

Your organization is executing a zero-downtime canary deployment for a critical payment-processing microservice on Google Kubernetes Engine (GKE) backed by Cloud SQL for PostgreSQL. The deployment requires adding a mandatory database column without causing application downtime or transaction failures for live users. Sequence the operational steps in the correct order to safely complete this deployment strategy.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The proper sequence follows the expand-contract deployment pattern: first, perform an additive database migration to add the column as nullable; second, initiate a canary deployment with partial traffic shifting; third, promote the release to 100% traffic upon validation; and fourth, finalize the contract phase by applying the NOT NULL constraint to the database column.
Safely deploying application updates dependent on database schema changes requires decoupled, backward-compatible steps. The additive schema migration (Expand) must precede canary traffic shifting. Once the canary release is validated and promoted to 100% traffic across all instances, restrictive schema changes (Contract) can be safely applied.

Step-by-Step Solution

1
Execute Expand DDL Migration
The new column is added as nullable to the database schema.
Existing application instances running version 1 do not supply data for the new column and would crash if strict non-null constraints were enforced prematurely.
2
Deploy Canary Revision and Route Partial Traffic
Version 2 microservice receives 10% of traffic via GKE ingress/Cloud Deploy orchestration.
Allows real-world metric evaluation of version 2 without exposing the entire user base to potential release defects.
3
Promote Version 2 to Full Production Traffic
100% of incoming requests are handled by version 2 instances.
Ensures complete transition off legacy version 1 code before locking down schema contracts.
4
Execute Contract DDL Migration
Column schema is updated to NOT NULL and deprecated fields are cleaned up.
Maintains database data integrity once all active workload instances write compliance data.

Key Concept

Expand-Contract (Parallel Change) Pattern for Database Zero-Downtime Releases
Question 132Question →

A cloud security architect is establishing permission inheritance across a newly created Google Cloud resource hierarchy for an automated compliance audit tool. Arrange the following implementation steps in the correct sequential order, starting from top-level organization governance down to granular resource-level access enforcement.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying Organization-level IAM bindings, followed by creating dedicated Folder nodes, then assigning predefined IAM roles at the Project level, and finally attaching conditional IAM policy bindings on specific Cloud Storage buckets.
In Google Cloud, permissions flow downwards through the resource hierarchy: Organization → Folders → Projects → Resources. Setting up policy governance follows this top-down structure, establishing organization-wide baselines first, structuring organizational folder units next, configuring project IAM roles third, and finally applying fine-grained resource-level bindings at the bottom.

Step-by-Step Solution

1
Establish root organization governance
Organization-level IAM bindings provide baseline visibility that inherits down the resource hierarchy.
Permissions in Google Cloud inherit downwards from the Organization root node to all descendant folders, projects, and resources.
2
Construct folder hierarchy boundaries
Folders organize projects into logical groupings under the Organization node.
Structuring folders enables administrative grouping before assigning project-specific or environment-specific security controls.
3
Grant project-level roles
Predefined roles bound at the project level control service account access within that project scope.
Project IAM policies narrow down broad organization permissions to project-specific workload requirements.
4
Enforce resource-level conditional access
Resource-level policy bindings restrict access to specific assets like Cloud Storage buckets.
Applying bindings directly to individual resources provides the most granular enforcement of least privilege at the leaf nodes of the hierarchy.

Key Concept

Resource Hierarchy Permission Inheritance and Downward IAM Policy Flow
Question 133Question →

During a major regional outage in Google Cloud, your operations team must execute a manual disaster recovery runbook to fail over a web application and its database from the primary region to a secondary standby region. In what order should you perform the following disaster recovery execution steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: first, promote the cross-region database read replica to standalone primary status; second, update secondary application workload connections to point to the new database; third, update Cloud DNS routing policies to direct user traffic to the secondary region; and fourth, verify application telemetry and functionality.
Executing disaster recovery requires ensuring data tier readiness prior to application connection updates and traffic redirection. Promoting the cross-region database replica ensures a writable database exists. Reconfiguring the secondary application instances allows them to communicate with the database. Updating Cloud DNS shifts user traffic safely to the secondary region. Finally, operational telemetry verification ensures business continuity success.

Step-by-Step Solution

1
Promote Database Replica
Database in the secondary region becomes writable.
Data persistence layer readiness is required before application instances can execute stateful operations.
2
Reconfigure Secondary Application Workloads
Secondary application instances target the new writable database endpoint.
Prevents database connection failures when incoming requests start arriving.
3
Reroute External Network Traffic via Cloud DNS
User requests are directed to the secondary region's load balancer.
Traffic should only be introduced once backend infrastructure is fully reconfigured and ready.
4
Perform System Validation and Telemetry Checks
Confirmed disaster recovery failover completion and operational stability.
Validates that business continuity objectives have been met under live operational conditions.

Key Concept

Disaster Recovery Failover Execution Sequence
Estimated Time:1m 0s
Question 134Question →

A DevOps engineer needs to configure a local development workstation to run Python scripts that interact programmatically with Cloud Storage APIs using short-lived credentials via Service Account Impersonation. Corporate security policy strictly prohibits downloading JSON service account keys to local workstations. Place the operational steps in the correct chronological order to configure Application Default Credentials (ADC) with service account impersonation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for configuring service account impersonation for Application Default Credentials (ADC) is: 1) Authenticate user identity via `gcloud auth login`, 2) Grant the Service Account Token Creator role to the user identity on the target service account, 3) Generate impersonated ADC using `gcloud auth application-default login --impersonate-service-account=...`, and 4) Run the code using standard Google Cloud Client Libraries.
The sequence follows the standard IAM lifecycle for keyless developer access: first establish user identity, grant necessary IAM permissions (`roles/iam.serviceAccountTokenCreator`), configure local ADC for impersonation via the gcloud CLI flag, and finally launch the application code which seamlessly consumes ADC.

Step-by-Step Solution

1
Authenticate user identity
The local environment obtains OAuth tokens for the individual user account.
Before requesting credentials on behalf of another entity, the operator's primary user identity must be authenticated with GCP.
2
Assign IAM impersonation permission
User account gains `roles/iam.serviceAccountTokenCreator` on the target service account resource.
IAM authorization is required to create short-lived OAuth tokens or signed JWTs for a target service account.
3
Generate impersonated ADC local config
Application Default Credentials file `application_default_credentials.json` is updated with impersonation parameters.
Using the `--impersonate-service-account` flag configures ADC to fetch short-lived tokens automatically instead of using static key files.
4
Execute application code with Cloud SDK/Client Libraries
Client libraries load ADC credentials and send API requests signed by the impersonated service account.
Google Cloud Client Libraries default to searching standard ADC paths, enabling secure keyless programmatic access.

Key Concept

Service Account Impersonation with Application Default Credentials (ADC)
Estimated Time:1m 30s
Question 135Question →

An enterprise energy company is establishing an automated testing and release validation pipeline for a mission-critical IoT telemetry ingestion platform on Google Cloud. To ensure system stability, capacity readiness, and security compliance prior to production cutover, sequence the technical solution validation steps in the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for testing and validating the technical solution is: 1) Execute dry-run plan validations using IaC, 2) Audit regional GCP quotas and submit increase requests, 3) Provision the staging environment and execute synthetic load tests, and 4) Configure VPC Service Controls perimeters and IAM roles prior to cutover.
Validating technical cloud solutions requires a structured, multi-phase procedure. First, dry-run IaC checks ensure code correctness without modifying resources. Next, verifying and requesting regional quotas guarantees that cloud capacity is available. Once quota limits are secured, staging environments can be provisioned to run synthetic load and SLO validation tests. Finally, security perimeters and access controls are locked down immediately prior to production traffic cutover to safeguard data boundaries.

Step-by-Step Solution

1
Perform static configuration and IaC plan validation.
Infrastructure templates and dependency graphs are validated without mutating environment state.
Catching configuration syntax errors early avoids invalid deployment attempts and state lock issues.
2
Verify and request regional quota capacity.
GCP quota limits for compute and network resources are confirmed and expanded.
GCP quota approval can require processing time; validating quotas before environment creation avoids mid-deployment quota exhaustion.
3
Deploy staging infrastructure and run automated load/stress testing.
System performance, auto-scaling capabilities, and error rates are evaluated against SLO targets.
Synthetic load validation requires a fully provisioned staging setup with guaranteed quota allocations.
4
Enforce security perimeters and access control policies.
VPC Service Controls boundaries and IAM policies are locked down.
Final security controls should be validated and activated right before live traffic cutover to restrict unauthorized data access.

Key Concept

Developing Procedures to Test and Validate Technical Solutions
Estimated Time:2m 0s
Question 136Question →

An enterprise security team needs to establish automated secret rotation for database credentials stored in GCP Secret Manager according to Google Cloud recommended security practices. 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 starts with creating the Pub/Sub topic, granting the Secret Manager Service Agent the Pub/Sub Publisher role on that topic, deploying the rotation Cloud Function, granting its runtime service account the Secret Manager Secret Version Manager role, and finally configuring the rotation schedule on the target secret in Secret Manager.
To set up automated secret rotation in GCP Secret Manager using Cloud Functions, resources and permissions must be provisioned in dependency order. First, the Pub/Sub topic must be created to receive rotation events. Next, the Secret Manager Service Agent requires the Pub/Sub Publisher role on that topic. Then, the rotation Cloud Function is deployed, and its dedicated runtime service account is granted the Secret Manager Secret Version Manager role under least-privilege principles. Finally, the target secret in Secret Manager is updated with the rotation schedule pointing to the Pub/Sub topic.

Step-by-Step Solution

1
Create the Pub/Sub topic
The messaging channel for rotation notifications is established.
Pub/Sub acts as the decoupled notification layer between Secret Manager and the rotation worker function.
2
Grant publisher permissions to the Secret Manager Service Agent
Secret Manager is authorized to publish rotation events to the Pub/Sub topic.
Without roles/pubsub.publisher on the topic, Secret Manager cannot send rotation triggers.
3
Deploy the rotation Cloud Function
The function handling credential generation and database updates is deployed.
The Cloud Function logic must exist to process incoming Pub/Sub rotation events.
4
Grant IAM roles to the Cloud Function's runtime service account
The function has least-privilege permissions (roles/secretmanager.secretVersionManager) to write new secret versions.
The function service account must be empowered to update Secret Manager with the newly generated credential versions.
5
Enable rotation schedule on the Secret Manager secret
Automated secret rotation lifecycle is activated.
Linking the secret to the Pub/Sub topic and defining the rotation interval triggers automated execution.

Key Concept

Secret Manager Automated Secret Rotation Architecture and Service Account Least Privilege Lifecycle
Question 137Question →

An enterprise SaaS platform hosts an AI-powered data processing service on Google Kubernetes Engine (GKE) backed by Cloud SQL for PostgreSQL. The team needs to execute a zero-downtime release that includes both a non-breaking database schema modification and a new application version deployment using a canary release strategy. What is the correct sequence of operational steps to perform this release safely?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying backward-compatible additive database changes, followed by deploying the canary application workload to GKE, routing a small fraction of traffic for monitoring, promoting the release to 100% traffic while decommissioning old pods, and finally executing destructive database cleanup changes.
To achieve zero downtime during releases involving database schema changes, the Expand-Contract pattern must be used. First, the database schema is updated additively so both old and new code function correctly. Next, the canary release is deployed to GKE and assigned a small fraction of traffic via GKE Gateway / Service Mesh traffic splitting. Once validated, the new version is fully promoted to serve 100% of production traffic and old pods are retired. Only after all old code is completely decommissioned can destructive contract schema changes be safely applied.

Step-by-Step Solution

1
Perform the Expand database migration.
Database contains new structural fields without breaking the active legacy application.
Applying destructive or breaking schema changes first would instantly crash running application pods that rely on the old schema.
2
Deploy the new container image version to GKE.
Canary deployment pods are running and ready to receive traffic.
The workload must exist in a ready state before routing live traffic to it.
3
Configure canary traffic splitting.
A small portion of live user requests (e.g., 5%) are served by the canary deployment.
Allows real-world validation against SLOs and error budgets while limiting potential impact.
4
Complete full rollout and decommission old pods.
100% of traffic hits the new version and zero pods run the old code version.
Ensures no active workloads rely on old schema structures before proceeding to cleanup.
5
Perform the Contract database migration.
Deprecated database fields are removed.
Unused columns and tables can now be safely removed without risking runtime errors.

Key Concept

Expand-Contract Database Schema Migration paired with Canary Deployment
Estimated Time:1m 30s
Question 138Question →

A media publishing enterprise needs to onboard existing, manually provisioned Google Cloud infrastructure—specifically Cloud Storage buckets and Compute Engine instances—into a managed Terraform workflow backed by a secure remote state. What is the correct sequence of operational steps to safely import these resources and ensure configuration alignment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with provisioning the remote GCS backend bucket with versioning and uniform access, followed by configuring the backend and running `terraform init`. Next, matching declarative Terraform HCL resource blocks are defined, after which `terraform import` binds the live GCP resources to state addresses. Finally, `terraform plan` is executed to confirm zero configuration drift.
Safely incorporating existing (brownfield) Google Cloud infrastructure into Terraform requires establishing the infrastructure state lifecycle in a precise sequence. First, the GCS bucket for remote backend state must be created with state protection features (versioning and uniform bucket-level access). Second, `terraform init` initializes the workspace to connect to this remote backend. Third, HCL resource definitions are written to provide the schema target. Fourth, `terraform import` maps the existing live infrastructure IDs into the remote state file. Finally, `terraform plan` validates that no unintended drift or destructive actions will occur when managing the resources declaratively going forward.

Step-by-Step Solution

1
Provision remote state bucket in GCS
A secure GCS bucket with versioning and uniform bucket-level access is available for state storage.
Remote state backend storage must be provisioned before Terraform can use it to maintain state and lock state during operations.
2
Configure backend and initialize Terraform
Terraform working directory is initialized and linked to the GCS remote backend.
Initializing Terraform establishes remote state management and locks access to prevent concurrent state modifications.
3
Define target resource HCL blocks
Declarative resource code blocks exist in Terraform files corresponding to live infrastructure.
`terraform import` requires target resource addresses defined in HCL prior to binding existing live infrastructure.
4
Import existing GCP resources into Terraform state
The Terraform state file is updated with attribute metadata from live GCP resources.
Importing binds existing infrastructure instances to Terraform state without destroying or recreating them.
5
Validate synchronization with terraform plan
Verification confirms that zero infrastructure changes or destructions are pending.
Running a plan immediately after import verifies that the declarative HCL matches the imported live state.

Key Concept

Brownfield resource import into Terraform state using secure GCS remote backend governance
Question 139Question →

An enterprise financial transaction platform running on Google Cloud maintains a warm standby disaster recovery setup in region `us-east4` to handle regional failures of its primary environment in `us-central1`. Following a catastrophic loss of `us-central1`, the cloud architecture team must initiate the regional failover runbook. Arrange the following execution steps in the correct chronological sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for regional failover execution is: 1) Promote the cross-region database read replica to primary status, 2) Scale up the secondary Managed Instance Groups to full production capacity, 3) Reconfigure the Global HTTP(S) Load Balancer backend services to target the secondary region, and 4) Update Cloud DNS routing policies to finalize domain redirection.
Executing a disaster recovery failover requires establishing data write availability first (promoting the database replica), expanding compute capacity second (scaling MIGs), switching internal traffic routing third (updating Load Balancer backends), and finalizing external ingress routing last (updating DNS policies). This order guarantees zero write-block failures and prevents capacity overload.

Step-by-Step Solution

1
Establish persistence write capability by promoting the secondary database replica.
Database write availability is restored in the target disaster recovery region (`us-east4`).
Promoting the database replica first prevents application connection failures and data corruption when application instances spin up.
2
Provision required compute workload capacity in the disaster recovery region.
Managed Instance Groups in `us-east4` expand to meet production traffic demands.
Application nodes must be fully scaled and running healthy instances before accepting production traffic workloads.
3
Shift global load balancing target backends to the newly scaled instance groups.
Load balancer health checks pass and traffic is pointed to secondary regional backends.
Updating backend service definitions directs regional ingress traffic toward active compute resources.
4
Update Cloud DNS routing policies to broadcast the endpoint shift globally.
External client traffic transitions entirely to the active disaster recovery environment.
DNS update is the external entry point change that completes the end-to-end failover sequence.

Key Concept

Disaster Recovery Regional Failover Execution Sequence
Estimated Time:2m 0s
Question 140Question →

A fintech startup has manually provisioned a production environment in Google Cloud consisting of Cloud Pub/Sub topics and BigQuery datasets via the GCP Console. To bring these resources under Infrastructure as Code (IaC) governance, the cloud architecture team needs to safely import the resources into Terraform state while setting up a centralized Cloud Storage (GCS) backend for state storage. In what sequence should the engineering team execute the following operational steps to import the existing infrastructure without accidental resource destruction?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Write matching HCL configuration and GCS backend declarations, 2) Run terraform init to connect to the remote backend, 3) Execute terraform import using full GCP resource IDs, 4) Run terraform plan to verify zero configuration drift, and 5) Commit the verified HCL code to version control.
Safely bringing existing (brownfield) Google Cloud infrastructure under Terraform management requires first writing corresponding HCL code and backend settings, initializing the backend via `terraform init`, executing `terraform import` with exact GCP resource IDs, validating zero drift using `terraform plan`, and finally committing code to Git for CI/CD integration.

Step-by-Step Solution

1
Declare HCL resource definitions and backend settings
Local HCL files represent the expected resource schemas and point state to GCS.
Terraform needs defined resource addresses and a configured remote backend before state initialization.
2
Initialize Terraform working directory with `terraform init`
Provider plugins are downloaded and the GCS backend connection is established.
Remote state tracking and backend locking must be active before binding live cloud infrastructure.
3
Run `terraform import` targeting GCP resource IDs
Existing BigQuery dataset and Pub/Sub topic state records are populated into the remote GCS state file.
Importing maps real GCP infrastructure to Terraform state keys without recreating resources.
4
Run `terraform plan` to detect drift
Output shows 'No changes. Your infrastructure matches the configuration.'
Guarantees HCL declarations exactly reflect the live resource attributes, preventing accidental deletion upon future applies.
5
Commit HCL configurations to Git source repository
Version control tracks infrastructure state and enables CI/CD automation.
Formalizes IaC management and enables automated pipeline governance.

Key Concept

Infrastructure as Code (IaC) Brownfield Resource Import Workflow
PreviousPage 7 / 9Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin