All practice questions

174 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

An site reliability engineering (SRE) team needs to create an operational alert system for a mission-critical web application on Google Cloud. The alert must fire whenever HTTP 500 status codes exceed a rate of 50 occurrences within a 5-minute window. The team must construct a log-based metric from application logs and link it to an alerting policy that sends alerts via an external Webhook notification channel. In what sequence should the SRE team perform the following tasks to establish this monitoring pipeline?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Construct and test the log filter query in Log Explorer, 2) Create the user-defined log-based metric using the query, 3) Configure and verify the Webhook notification channel, and 4) Build the alerting policy using the log-based metric, threshold conditions, and notification channel.

The workflow follows a strict dependency chain: First, the log entry criteria must be tested in Log Explorer. Second, a custom log-based metric must be defined from that query so Cloud Monitoring can generate time-series data points. Third, the Webhook notification channel must be provisioned so alerting destinations exist. Finally, the Cloud Monitoring alerting policy is created, selecting the metric stream, configuring threshold evaluation, and linking the notification channel.

Step-by-Step Solution

Filter log payload

Validated Cloud Logging query specifying severity and resource payload attributes for HTTP 500 errors.

Before creating a metric, the exact filter criteria must be verified to prevent capturing unwanted log events or missing target errors.

Generate custom metric stream

User-defined counter metric registered in Cloud Logging.

Cloud Monitoring cannot monitor log entries directly; log entries must first be mapped into custom time-series metric data by Cloud Logging.

Establish notification endpoints

Active, verified Webhook notification channel registered in Cloud Monitoring settings.

Alerting policies require a target notification channel during or after creation to deliver incident notifications upon breach.

Configure alert policy and attach channels

Enabled Cloud Monitoring alerting policy monitoring the log-based metric threshold and pointing to the notification channel.

The alerting policy synthesizes the metric threshold condition and notification delivery target into a functional alerting rule.

Key Concept

Configuring custom log-based metrics and operational alert policies in GCP Cloud Operations suite

Estimated Time:2m 0s

Question 22Question →

Your team needs to migrate a monolithic local Terraform state file (`terraform.tfstate`) managing production GCP resources to an enterprise remote backend hosted on Google Cloud Storage (GCS) with object versioning and state locking. Place the steps in the correct order to perform this state migration safely without losing resource state or creating concurrency issues.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for migrating local Terraform state to a GCS remote backend begins by adding the backend block, running terraform init, approving the automatic state copy prompt, and validating remote locking before removing local state files.

The migration process requires declaring the backend configuration first, invoking backend initialization via terraform init, approving the state transfer to GCS, and finally validating state lock functionality before removing local state backups.

Step-by-Step Solution

Add the backend 'gcs' configuration block to the Terraform code.

Defines the target Google Cloud Storage bucket and prefix for remote state management.

Terraform requires explicit backend block definitions to locate target state storage.

Execute 'terraform init' in the workspace directory.

Terraform identifies the backend change and initiates backend migration workflows.

The init command parses new provider and backend settings to set up state transfer.

Confirm the state copy operation when prompted by Terraform.

Local state entries are safely copied into the target GCS bucket.

Interactive confirmation ensures state tracking continuity without destroying managed resource mappings.

Run 'terraform plan' to test remote state locking and clean up the local tfstate file.

Remote backend operation is validated and local state file duplication is eliminated.

Prevents future accidental usage of local state files while validating GCS backend permissions.

Key Concept

Migrating local Terraform state to remote Google Cloud Storage (GCS) backend with state locking.

Question 23Question →

An enterprise gaming company is planning to migrate its mission-critical PostgreSQL database and associated multi-terabyte media storage from an on-premises data center to Google Cloud (Cloud SQL for PostgreSQL and Cloud Storage) with minimal operational downtime. What is the correct sequence of steps to execute this migration strategy while ensuring zero data loss and minimal service interruption?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Establish dedicated network connectivity via Cloud Interconnect and set up target GCP IAM roles and VPC infrastructure, 2) Initiate initial baseline data transfer for media files to Cloud Storage via Storage Transfer Service and start continuous Database Migration Service (DMS) CDC replication, 3) Verify data consistency, schema validation, and monitor CDC replication lag between the on-premises database and Cloud SQL, 4) Place the on-premises database in read-only mode, allow final CDC catch-up, and promote the Cloud SQL instance to primary, and 5) Update client application database connection strings and DNS records to direct production traffic to GCP.

The correct sequence follows GCP migration best practices: pre-provisioning secure network and IAM foundations, establishing baseline file transfers alongside continuous database replication (CDC), validating sync status, executing a zero-loss cutover (setting source read-only, draining CDC, promoting target), and re-pointing application endpoints.

Step-by-Step Solution

Provision underlying network and access foundations.

Secure, high-bandwidth connection between on-premises and GCP VPC is established.

Data migration tools and replication streams require network routes and IAM permissions before initiation.

Start baseline storage migration and continuous database replication.

Historical media files land in Cloud Storage while database CDC catches up initial state.

Both file transfer and CDC replication run concurrently to minimize overall migration timeline.

Validate synchronization status and replication lag.

Target environment parity is confirmed with minimal CDC replication lag.

Cutting over without verifying synchronization risks data loss or extended cutover downtime.

Execute database cutover sequence: set source read-only, drain CDC stream, and promote target.

Target Cloud SQL instance becomes the writable primary database with zero lost transactions.

Locking writes at the source prevents data divergence and guarantees transactional consistency.

Re-point application traffic to the target GCP environment.

Production traffic successfully operates against GCP.

Final stage switches active workload to GCP once the target database is promoted and operational.

Key Concept

Staging continuous database and data transfer migrations to achieve minimal downtime and zero data loss on GCP.

Question 24Question →

An e-commerce enterprise is planning to migrate its on-premises relational database to Cloud SQL for MySQL with minimal operational downtime using GCP Database Migration Service (DMS). Place the following database migration steps in the correct chronological execution order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution order is: 1) Provision the target Cloud SQL instance and apply database schema definitions, 2) Configure continuous Change Data Capture (CDC) replication job parameters in Database Migration Service, 3) Execute the initial full baseline data snapshot migration from the source database to Cloud SQL, 4) Stop application write traffic to the source database, verify zero CDC replication lag, and switch application endpoints to Cloud SQL.

The correct sequence follows standard database migration best practices: first provision destination resources and schema, then establish CDC replication pipelines, perform the initial baseline bulk load, and finally pause write traffic to verify zero replication lag before switching application connection strings.

Step-by-Step Solution

Prepare target environment

Destination Cloud SQL instance created with appropriate schema structures ready to accept data

Data cannot be streamed into a destination that has not been provisioned with matching target schemas.

Establish continuous replication framework

DMS connection profile and CDC replication pipeline configured

Setting up the CDC pipeline beforehand ensures change logging is tracking transaction logs during data transfer.

Transfer historical baseline data

Full data snapshot copied to Cloud SQL while ongoing changes accumulate in replication stream

A baseline copy of existing data is required before incremental changes can be applied to align the target with the source.

Promote destination and cut over application endpoints

Downtime window minimized and Cloud SQL becomes the active production database

Pausing source write traffic ensures no new transactions occur while verifying zero CDC lag before updating application connection strings.

Key Concept

Minimal-Downtime Database Migration Cutover Sequencing

Question 25Question →

Your enterprise cloud architecture team needs to safely migrate an existing production Terraform deployment from local state management to a centralized remote backend on Google Cloud Storage with state locking and version control enabled. What is the correct sequence of operational steps required to complete this migration without data loss?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with provisioning and securing the target Cloud Storage bucket with versioning enabled, adding the backend configuration block to the Terraform code, executing terraform init to detect backend changes, confirming the state transfer prompt, and finally validating the remote state file while removing the local state file.

Migrating Terraform state to Google Cloud Storage requires preparing the destination infrastructure first (creating the versioned GCS bucket), defining the configuration (`backend "gcs"`), executing `terraform init` to register the new backend and transfer local state, confirming the interactive copy prompt, and finally validating remote state presence prior to local file cleanup.

Step-by-Step Solution

Provision the Cloud Storage bucket with versioning and IAM access controls.

A secure, versioned remote location is available for storing state files safely.

Terraform cannot write state to a non-existent or inaccessible backend bucket.

Declare the backend block in the Terraform root module.

The Terraform codebase specifies GCS as its remote backend.

Terraform needs backend definitions in code before it can re-initialize its working state directory.

Run terraform init.

Terraform identifies the change in backend provider and initiates state migration.

Backend changes require explicit re-initialization via the CLI.

Confirm the state copy prompt when requested by terraform init.

Local state entries are securely transferred to the GCS remote state object.

Ensures continuous tracking of infrastructure resources without resetting state.

Validate remote state object creation and remove local terraform.tfstate file.

State management is fully centralized remotely, preventing split-brain or stale state edits.

Leaving stale local state files can cause operational confusion or accidental local applies.

Key Concept

Terraform Remote State Migration to Google Cloud Storage

Estimated Time:1m 30s

Question 26Question →

A cloud architecture team is setting up an automated Continuous Delivery pipeline for a web service on Google Cloud using Cloud Build, Artifact Registry, and Cloud Deploy. What is the correct chronological sequence of steps to safely build, validate, and roll out a new software release to production?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with building and scanning the container image in Artifact Registry, followed by creating a Cloud Deploy release, deploying to a staging target for automated validation, and finally promoting the release to the production target for progressive canary rollout.

A standard automated deployment pipeline enforces strict stage dependencies: source code is first compiled into a container image and scanned for vulnerabilities in Artifact Registry; next, a Cloud Deploy release is initialized referencing this immutable artifact; the release is then deployed to staging for automated integration testing; finally, upon successful test completion, the release is promoted to production.

Step-by-Step Solution

Trigger Cloud Build to build the container image and upload it to Artifact Registry.

A secure container image artifact with scan results is available.

Build artifacts and security scans must exist prior to creating deployment manifests.

Execute gcloud deploy releases create to bundle the pipeline configuration and image digest.

An immutable Cloud Deploy release object is created.

Cloud Deploy requires a defined release object to manage target progressions and rollbacks.

Deploy the release to the non-production staging environment and run integration tests.

The release is validated in an isolated staging environment.

Testing in non-production environments catches integration issues before user impact.

Promote the validated Cloud Deploy release to the production target.

The application is deployed to production using the defined canary strategy.

Promotion executes the progressive rollout strategy safely after all prerequisite checks pass.

Key Concept

Automated Deployment Pipeline Order and Progression Gates

Question 27Question →

When configuring Terraform to use a Google Cloud Storage bucket as a secure remote backend for team collaboration, in what sequence should you execute the provisioning and configuration workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with creating the GCS bucket with Object Versioning, followed by writing the backend 'gcs' configuration block in Terraform, then running 'terraform init' to migrate state, and finally running 'terraform plan' to verify state locking and plan execution against the remote backend.

Establishing a remote Terraform state backend requires the storage infrastructure to exist first (GCS bucket creation with Object Versioning), declaring the storage destination inside the Terraform configuration, initializing the directory with 'terraform init' to establish remote state locking, and executing 'terraform plan' to verify operational readiness.

Step-by-Step Solution

Provision GCS Storage Bucket

A secure GCS bucket is available in GCP with Object Versioning enabled to prevent state corruption.

Terraform cannot store state in a GCS bucket that does not yet exist.

Declare Backend Configuration

The terraform block specifies backend 'gcs' with the target bucket and prefix.

Terraform requires code configuration to know where the state file should be stored remotely.

Initialize Terraform Backend

Terraform downloads the GCS provider plugin and migrates local state to the remote GCS bucket.

The initialization command establishes the remote backend connection.

Validate State Execution Plan

Terraform acquires a state lock on the GCS bucket and checks proposed changes against remote state.

Running plan confirms that remote state locking and reading work seamlessly.

Key Concept

Terraform GCS Remote Backend Provisioning Workflow

Question 28Question →

An enterprise architecture team is designing a database migration strategy to move an active, mission-critical PostgreSQL database from an on-premises data center to Cloud SQL for PostgreSQL with minimal downtime. Arrange the operational steps in the correct execution sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for a minimal-downtime database migration starts with network and target schema provisioning, followed by the initial bulk historical data load, enabling continuous Change Data Capture (CDC) replication, and concluding with a cutover window where source writes are paused, zero lag is verified, and traffic is re-routed.

A standard minimal-downtime database migration follows a structured lifecycle: establishing connectivity and target schema infrastructure first, carrying out an initial bulk snapshot export/import, initiating continuous CDC stream replication to catch up and maintain sync, and finally performing cutover by stopping source writes, draining replication queues to zero lag, and re-pointing application endpoints.

Step-by-Step Solution

Provision network connectivity and target database structure

Cloud Interconnect connects environments and Cloud SQL is initialized with the required schema.

Data transfer targets must be securely accessible and schema-ready before ingesting data.

Perform initial bulk baseline data load

Existing bulk records are transferred to establish a baseline snapshot in the target database.

CDC stream synchronization requires a base state snapshot to apply transaction deltas against.

Initiate continuous transaction log replication (CDC)

Live changes made to the source database stream continuously to the target database.

Continuous sync minimizes data lag during ongoing production operations prior to cutover.

Execute final cutover during maintenance window

Source writes are stopped, remaining replication log items apply, and applications connect to Cloud SQL.

Ensures zero data loss and data consistency across application clients during final cutover.

Key Concept

Minimal-Downtime Database Migration Pipeline Staging

Estimated Time:2m 0s

Question 29Question →

A Site Reliability Engineering (SRE) team needs to set up real-time operational alerting for high rates of HTTP 5xx application errors captured in Cloud Logging. What is the correct chronological sequence of steps to configure a log-based metric and activate an automated alerting policy in Google Cloud?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first construct a log filter in Cloud Logging, second create a custom log-based counter metric from the filtered logs, third create an Alerting Policy in Cloud Monitoring referencing the custom metric, and fourth configure the condition threshold and attach the notification channel.

To create operational alerts based on log patterns in Google Cloud, you must first isolate the relevant log messages using a log filter in Cloud Logging. Next, convert those filtered log entries into a numeric metric by creating a log-based counter metric. Once the metric is registered, navigate to Cloud Monitoring to create an Alerting Policy that selects this metric as its target. Finally, define the numerical threshold condition and attach the target notification channel to enable automated alerting.

Step-by-Step Solution

Construct a log filter in Cloud Logging.

HTTP 5xx application log events are accurately targeted and isolated from surrounding log streams.

Filters define the precise log criteria required to calculate operational metric counts.

Create a custom log-based counter metric.

Matching log occurrences are exposed as a numeric time-series metric to Cloud Monitoring.

Cloud Monitoring alerting policies operate on numerical metric time-series data rather than raw text logs.

Create an Alerting Policy referencing the log-based metric.

An alerting policy shell is bound to the new custom log metric resource.

The metric time-series must exist in Cloud Monitoring prior to selecting it within an alerting policy.

Specify threshold conditions and attach notification channels.

The alerting policy is fully configured and ready to trigger alerts upon threshold breaches.

Conditions define when an incident triggers, while notification channels dictate where alert notifications are routed.

Key Concept

Configuring custom log-based metrics and binding them to operational alerting policies in Google Cloud Observability.

Question 30Question →

An operations engineering team needs to set up automated alerting for unexpected HTTP 500 application error rates occurring in a Cloud Run service. The team wants to track these errors using a custom log-based metric and send real-time alerts to a dedicated Webhook notification channel. What is the correct sequence of steps to configure this logging, metric, and alerting pipeline?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The operational pipeline must be built logically from metric creation to alert delivery: first, create the custom log-based counter metric in Cloud Logging filtering for HTTP 500 logs; second, set up and verify the target Webhook notification channel in Cloud Monitoring; third, create the alerting policy targeting the log-based metric threshold; finally, attach the notification channel to the alerting policy and activate it.

Configuring operational alerting on log data requires a strict dependency sequence. First, the log entry pattern must be captured as a custom metric in Cloud Logging. Next, the target notification endpoint (Webhook) must be registered in Cloud Monitoring. Third, the alerting policy rule must be created using the metric time series as its condition source. Finally, the notification channel is linked to the policy to finalize alert delivery.

Step-by-Step Solution

Create the custom log-based counter metric in Cloud Logging using filter parameters for resource.type="cloud_run_revision" AND httpRequest.status=500.

Cloud Logging creates a metric descriptor and starts extracting time-series metric data into Cloud Monitoring whenever matching logs arrive.

Cloud Monitoring alerting policies cannot reference a log-based metric until the metric descriptor has been created in Cloud Logging.

Navigate to Cloud Monitoring Notification Channels and create a new Webhook endpoint channel.

A valid notification channel object is provisioned and available within the workspace.

Notification channels must be defined prior to assigning them to policy notification targets.

Define an alerting policy in Cloud Monitoring that monitors the rate of change or count of the custom log-based metric against a specific threshold.

The monitoring policy logic is established to evaluate incoming time-series points.

The policy defines when an incident is opened based on metric evaluation.

Bind the Webhook notification channel to the alerting policy and set the policy state to enabled.

The end-to-end logging, monitoring, and operational alerting pipeline is fully operational.

Linking the channel enables active incident routing upon threshold breaches.

Key Concept

Log-based metric and alerting policy configuration workflow in Google Cloud Observability

Question 31Question →

An enterprise logistics provider is migrating its core operational architecture from an on-premises data center to Google Cloud. The workload comprises a live $5\text{ TB}$ transactional PostgreSQL database migrating to Cloud SQL for PostgreSQL, along with $300\text{ TB}$ of unstructured document attachments migrating to Cloud Storage. The business demands continuous data replication with near-zero downtime during final cutover. Arrange the operational steps in the correct sequential order to execute this migration plan.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1) Establish connectivity, start continuous DMS CDC, and launch Storage Transfer Service initial bulk transfer; 2) Monitor replication lag and run delta syncs until synchronization parity is reached; 3) Set source database to read-only mode and run final incremental file transfer; 4) Verify zero replication lag, promote Cloud SQL to standalone primary, and update application connection endpoints; 5) Complete health validation checks and open write traffic on Google Cloud.

The migration cutover must proceed in a logical sequence to minimize downtime and prevent data loss. Baseline connectivity and replication (DMS CDC + Storage Transfer Service) are established first while the source remains active. Next, replication lag is monitored until parity is achieved. To prevent data divergence, write traffic on the source database is stopped by putting it in read-only mode, followed by a final incremental file transfer. After verifying zero replication lag, the Cloud SQL target instance is promoted to a standalone primary database and connection endpoints are updated. Finally, post-migration health checks validate system integrity before resuming production write traffic on GCP.

Step-by-Step Solution

Establish connectivity and start baseline replication tools.

Continuous CDC streaming begins via DMS alongside baseline Storage Transfer Service object ingestion without interrupting live source writes.

Data transfer tools must establish baseline copies and streaming CDC while the on-premises application remains fully operational.

Track replication lag and perform incremental synchronization.

Target Cloud SQL and Cloud Storage environments reach continuous near-zero latency synchronization with source data.

Verifying sync parity guarantees that the cutover window can be kept as brief as possible.

Quiesce source writes and trigger final delta syncs.

On-premises state is frozen to guarantee consistency while final transactions flush across the pipeline.

Preventing new writes eliminates data divergence and ensures strict zero-data-loss cutover.

Promote target database instance and rebind endpoints.

Cloud SQL becomes a standalone primary write instance, and application connection strings are pointed to GCP services.

Promoting Cloud SQL converts it from a replication target to the active master database.

Validate deployment health and resume production writes.

System end-to-end functionality is confirmed and production operations resume cleanly on GCP.

Final validation verifies that all application endpoints and data stores behave correctly under load before live user writes begin.

Key Concept

Database migration staging, CDC continuous replication, and cutover sequencing using GCP Database Migration Service and Storage Transfer Service.

Question 32Question →

An enterprise architecture team is implementing an automated Infrastructure as Code workflow to provision a multi-region Cloud Spanner database encrypted with Customer-Managed Encryption Keys (CMEK). Place the operational steps in the mandatory execution sequence required to successfully deploy the database and grant application access without permission or lifecycle failures.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The mandatory operational sequence is: 1) Create the Cloud KMS KeyRing/CryptoKey and grant the Cloud Spanner Service Agent the Encrypter/Decrypter role; 2) Provision the Cloud Spanner instance; 3) Provision the Cloud Spanner database specifying the KMS key in the encryption configuration; 4) Apply database IAM bindings for application service accounts.

Provisioning a CMEK-encrypted Cloud Spanner database requires strict prerequisite ordering: first, the Cloud Spanner service agent must be granted Cloud KMS encrypter/decrypter permissions on the key; second, the parent Spanner instance must be provisioned; third, the database is created using the KMS key configuration; finally, fine-grained IAM database user permissions are assigned to application service accounts.

Step-by-Step Solution

Configure Cloud KMS and IAM Delegation

The Cloud Spanner Service Agent is granted permissions to encrypt and decrypt data using the dedicated Cloud KMS key.

If CMEK encryption is specified during database creation without prior IAM delegation to the service agent, the API call will fail with a permission denied error.

Provision Spanner Instance

The parent Cloud Spanner instance is allocated with the specified node count and multi-region configuration.

Databases in Spanner must belong to an existing parent instance resource.

Provision Spanner Database with CMEK

The database is created inside the instance and encrypted using the authorized Cloud KMS key.

The Spanner service validates key existence and service account access during database initialization.

Bind Database IAM Roles

Application service accounts receive fine-grained read/write access to the newly created database.

Resource-level IAM policies for databases require the target database resource ID to exist.

Key Concept

Cloud Spanner CMEK Provisioning Dependencies and Lifecycle Ordering

Question 33Question →

A DevOps team is establishing an automated continuous delivery pipeline for a mission-critical web application on Google Kubernetes Engine (GKE) using Cloud Build, Artifact Registry, Binary Authorization, and Google Cloud Deploy. The deployment requirements mandate zero downtime, automated container security gates, and progressive canary traffic shifting with automated rollback capabilities. In what chronological sequence should the pipeline stages be executed to implement this secure release process?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence for the deployment pipeline is: 1) Build container image and generate Binary Authorization attestation signature in Cloud Build, 2) Create Cloud Deploy release and validate attestation via GKE Binary Authorization admission control, 3) Route 10% traffic to canary target with Cloud Monitoring metric validation, and 4) Advance rollout to route 100% of traffic to the production targets.

The correct release sequence begins with artifact compilation, vulnerability scanning, and Binary Authorization attestation signing during the build stage. Next, Cloud Deploy creates the release, triggering GKE Binary Authorization admission control to verify image signatures before scheduling pods. Once admitted, Cloud Deploy initiates canary deployment by shifting 10% of traffic while monitoring SLO metrics. Finally, upon metric validation, the rollout is advanced to shift 100% of production traffic.

Step-by-Step Solution

Build and Security Attestation

Container image created, scanned, and signed by a trusted attestor key.

Binary Authorization policy enforcement requires vulnerability scanning and valid cryptographically signed attestations before container deployment.

Release Delivery & Admission Control

Cloud Deploy release created and admitted into the GKE cluster.

Binary Authorization operates as a Kubernetes admission controller, evaluating container signatures prior to pod scheduling.

Canary Deployment & SLO Verification

Partial traffic (10%) directed to canary instances with active health verification.

Progressive delivery minimizes blast radius by testing real user traffic against canary instances before full release.

Full Production Promotion

Rollout advanced to 100% production traffic.

Once automated metrics confirm zero SLO regressions, the release is safely promoted across all production endpoints.

Key Concept

Automated Continuous Delivery Pipeline Sequencing with Security Attestation and Canary Delivery

Estimated Time:2m 0s

Question 34Question →

An operations engineering team needs to configure automated incident notifications based on specific error logs emitted by a workload running on Google Cloud. Order the steps required to establish a complete log-based alerting pipeline following Google Cloud observability best practices, starting from raw log evaluation to operational notification.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Construct a precise filter expression in Cloud Logging, 2) Define a custom log-based metric, 3) Configure an alerting policy in Cloud Monitoring using the custom metric, and 4) Attach notification channels to the alerting policy.

To create operational alerts driven by specific log occurrences, you must first define a filter expression in Cloud Logging to pinpoint the error logs. Next, transform those log events into numeric metric data by creating a custom log-based metric. Once the metric is ingested by Cloud Monitoring, construct an alerting policy that evaluates the metric against operational thresholds. Finally, associate notification channels with the alerting policy so that responders receive notifications when an incident is opened.

Step-by-Step Solution

Filter target logs in Cloud Logging

Relevant log entries matching the application failure criteria are isolated.

Cloud Logging requires a scope-limiting filter query to extract relevant log events from incoming log streams.

Create a log-based metric

Log occurrences are published as a time-series metric stream into Cloud Monitoring.

Cloud Monitoring alerting policies operate on numeric time-series metrics, not directly on text log records.

Create an alerting policy in Cloud Monitoring

An operational policy continuously checks the metric rate against defined thresholds.

Alerting policies evaluate conditions over specified time windows to detect incidents.

Associate notification channels

Operational alerts are automatically routed to team notification endpoints upon incident trigger.

Notification channels define target destinations (such as Slack, Email, or PagerDuty) for alert delivery.

Key Concept

Configuring Cloud Logging log-based metrics and Cloud Monitoring alerting workflows

Question 35Question →

In Google Cloud Platform (GCP), IAM permissions are inherited downward through the resource hierarchy structure. How should an architect sequence the GCP resource hierarchy levels in order of policy inheritance, starting from the highest level (broadest policy scope) down to the lowest level (most narrow policy scope)?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of the GCP resource hierarchy from broadest scope to most granular scope is: Organization node, Folder node, Project node, and Individual Resource.

In Google Cloud Platform, IAM policies are inherited transitively from parent to child. The resource hierarchy flows downwards starting from the Organization (root node), through Folders (grouping containers), to Projects (service boundaries), and finally to Individual Resources (leaf elements).

Step-by-Step Solution

Identify the root node of the GCP resource hierarchy.

The Organization node is established as position 1.

The Organization node represents the root level, and policies applied here inherit down to all child nodes in the enterprise.

Identify the intermediate grouping container node.

The Folder node is established as position 2.

Folders are created directly under the Organization node to group projects and sub-folders for departmental or environment governance.

Identify the service and billing boundary container node.

The Project node is established as position 3.

Projects sit inside Folders and act as the core administrative boundary for enabling GCP APIs, services, and billing.

Identify the leaf node containing specific GCP service components.

The Individual Resource is established as position 4.

Resources (such as BigQuery datasets or GCS buckets) reside within projects at the lowest level of the resource hierarchy.

Key Concept

GCP IAM Resource Hierarchy Policy Inheritance

Estimated Time:45s

Question 36Question →

A cloud operations team needs to deploy a new PostgreSQL database on Google Cloud using Cloud SQL and populate it using a local database dump file. What is the correct sequence of steps to provision the storage staging environment, transfer the dump, and populate the database?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating a Cloud Storage staging bucket, uploading the local database dump file to the bucket, provisioning the Cloud SQL instance, and finally granting IAM permissions to the Cloud SQL service account to execute the import job.

Provisioning database resources on Google Cloud when starting from a local dump requires a staging location. First, a Cloud Storage bucket is created to host the dump file. Second, the dump file is uploaded from the local environment into the bucket. Third, the Cloud SQL database instance is provisioned. Finally, the service account assigned to the Cloud SQL instance is granted permissions on the Cloud Storage bucket so the import operation can execute successfully.

Step-by-Step Solution

Create the staging storage bucket

A Cloud Storage bucket is available to receive object uploads.

Cloud SQL import operations require data to be hosted in Cloud Storage.

Upload the database dump file to Cloud Storage

The file is stored in Google Cloud and ready for Cloud SQL access.

Local files cannot be imported directly into Cloud SQL without first residing in a staging bucket.

Provision the Cloud SQL database instance

The database server is instantiated and running.

Target infrastructure must exist to accept the imported data schema and records.

Authorize the service account and run the import job

The database instance is populated with the staging data.

Cloud SQL uses its service account to read from Cloud Storage, requiring explicit IAM access prior to running the import.

Key Concept

Provisioning Cloud SQL and Cloud Storage staging pipelines

Question 37Question →

Your organization is establishing standardized Google Cloud Deployment Manager practices for provisioning cloud infrastructure across development environments. You need to create a reusable configuration and safely deploy it. In what order should you execute the steps to construct, validate, preview, and commit the deployment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with authoring the Jinja2/Python template and schema file, followed by building the top-level YAML configuration file. Next, execute the deployment creation with the --preview flag to validate proposed changes without provisioning, and finally run the deployment update command to commit and instantiate the infrastructure.

The correct workflow for managing complex Cloud Deployment Manager configurations starts at authoring reusable Jinja2 or Python templates with schemas to validate input properties. Once templates exist, a top-level YAML configuration imports them and sets environment variables. Using the Cloud SDK with the preview flag renders the proposed graph without creating resources, allowing verification. Finally, updating the previewed deployment commits the configuration to provision resources in Google Cloud.

Step-by-Step Solution

Define reusable template and schema files.

Establishes parameterized resource logic and strict input validation rules.

Deployment Manager requires underlying template definitions and schema parameters to exist before top-level configurations can reference them.

Construct the main YAML configuration file.

Passes specific environment variables into the imported templates.

The YAML configuration acts as the entry point that binds input variables to the schema-validated templates.

Run `gcloud deployment-manager deployments create --config <config.yaml> --preview`.

Renders and displays the complete resource manifest in a preview state without making resource allocations.

Previewing ensures architectural correctness and prevents unintended infrastructure changes before provisioning.

Run `gcloud deployment-manager deployments update <deployment-name>`.

Provisions and updates the actual Google Cloud infrastructure resources based on the previewed state.

This final command transforms the previewed allocation plan into active infrastructure.

Key Concept

Cloud Deployment Manager Template Lifecycle and Preview Operations

Question 38Question →

An enterprise architecture team is transitioning a critical Google Cloud infrastructure codebase from local execution to a centralized, collaborative Terraform model. To meet corporate security and operational standards, the team must migrate the local state file to a secure Google Cloud Storage (GCS) remote backend featuring state locking and least-privilege service account impersonation. Sequence the steps required to execute this state backend migration safely and correctly.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with provisioning and securing the target GCS bucket, adding the remote backend definition to the HCL configuration, establishing least-privilege service account impersonation, executing terraform init to migrate the state under state locks, and finally validating state integrity with terraform plan.

Migrating Terraform state safely requires creating the secured GCS storage resource first, configuring HCL backend settings, establishing IAM impersonation credentials, running terraform init to perform state transfer under state locks, and executing terraform plan to confirm operational readiness.

Step-by-Step Solution

Provision and secure the Google Cloud Storage bucket

A target GCS bucket exists with Object Versioning and uniform bucket-level access enabled to protect state integrity.

The GCS storage location must exist and be secured prior to pointing Terraform to it.

Configure the HCL backend block

The Terraform code declares the gcs backend with the target bucket and prefix.

Terraform needs backend configuration metadata to know where state data should be written.

Set up least-privilege Service Account impersonation

Authentication relies on short-lived service account tokens instead of persistent service account key files.

Impersonation must be configured before invoking initialization so state storage operations run under the correct identity.

Initialize the backend and migrate state

Terraform acquires a state lock on GCS and transfers the state content from local storage to the bucket.

The terraform init command detects backend changes and performs interactive or automated state migration.

Validate remote state operations

Terraform plan acquires the GCS lock, reads state, confirms zero unexpected drift, and releases the lock.

Post-migration verification ensures that remote lock acquisition works as expected and state corruption did not occur.

Key Concept

Remote Terraform State Management with GCS, Object Versioning, State Locking, and Service Account Impersonation

Question 39Question →

A global retail enterprise is preparing to migrate its $12\text{ TB}$ on-premises transactional PostgreSQL database to Cloud SQL for PostgreSQL with minimal operational downtime. The architecture team has selected Database Migration Service (DMS) with continuous replication. Arrange the operational phases below into the correct chronological sequence required to complete the migration safely.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: 1) Establish hybrid connectivity and connection profiles, 2) Start initial baseline dump and snapshot restore, 3) Enable continuous CDC streaming, 4) Set source application to read-only and allow replication lag to reach zero, 5) Promote target Cloud SQL instance and redirect application traffic.

Online database migrations require establishing infrastructure connectivity, loading a baseline data snapshot, maintaining real-time CDC synchronization, quiescing source writes to eliminate replication lag, and finally promoting the destination database for production cutover.

Step-by-Step Solution

Configure network connectivity and DMS connection profiles.

Secure communication channel between source PostgreSQL and GCP target environment is verified.

Data transfer cannot start without established network routing and authentication credentials.

Execute the baseline data load.

Initial historical snapshot (

12\text{ TB}

) is transferred to Cloud SQL.

A baseline snapshot provides the starting state for continuous change data replication.

Activate continuous Change Data Capture (CDC).

Ongoing transaction log changes stream automatically to Cloud SQL.

CDC keeps the cloud database synchronized while the on-premises database remains active in production.

Quiesce on-premises writes and monitor replication lag.

Replication lag drops to zero seconds, confirming full parity.

Prevents data loss or data state mismatch during final cutover.

Perform cutover and promote Cloud SQL instance.

Cloud SQL becomes the active primary database and application endpoints are updated.

Completes the migration workflow and finalized switchover to Google Cloud.

Key Concept

Continuous Online Database Migration and Cutover Sequencing with DMS

Estimated Time:2m 0s

Question 40Question →

An enterprise financial institution is planning the migration of its core transaction settlement platform to Google Cloud. As the Principal Cloud Architect, you must lead the architecture design process by translating high-level enterprise business requirements into a fully deployed cloud infrastructure. In what order should you execute the architectural design and translation steps, moving from initial conceptual design down to physical implementation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order follows a top-down architectural progression: first, construct the vendor-neutral Conceptual Architecture based on business goals and compliance metrics; second, build the Logical Architecture by defining functional components and data flows; third, map logical tiers to abstract cloud service paradigms; fourth, select concrete Google Cloud products matching technical requirements; and fifth, draft physical deployment specifications, network configurations, and IaC scripts.

Enterprise cloud solution design moves systematically from business vision to executable infrastructure. The process begins with a vendor-neutral Conceptual Architecture to capture SLAs, business processes, and compliance requirements. Next, the Logical Architecture defines subsystem components, data interaction flows, and integration interfaces. Then, logical components are mapped to generic cloud architectural paradigms. After that, specific physical Google Cloud products (such as Cloud Spanner, Pub/Sub, GKE Enterprise, and VPC SC) are selected to meet throughput and availability constraints. Finally, detailed physical deployment specifications—including subnet CIDRs, IAM bindings, and IaC Terraform code—are produced to enable automated environment provisioning.

Step-by-Step Solution

Establish the Conceptual Architecture layer.

Vendor-neutral definition of business capabilities, SLA goals, and compliance boundaries.

Architecture design must begin with business intent and governance requirements before evaluating tech stack options.

Construct the Logical Architecture layer.

Decomposition into functional subsystem tiers, data flows, and service contracts.

Logical tiering structures the data flow and system boundaries needed to satisfy conceptual business capabilities.

Map logical tiers to abstract cloud paradigms.

Identification of general category patterns (e.g., transactional storage, event messaging).

Connecting functional requirements to cloud design patterns bridges pure logical design with cloud technology concepts.

Select physical GCP services and topographies.

Specification of Cloud Spanner, Pub/Sub, GKE Enterprise, and VPC Service Controls.

Concrete GCP managed services are chosen based on their ability to fulfill the performance, availability, and security targets of the logical design.

Formulate physical deployment artifacts.

Definition of VPC subnet CIDR blocks, IAM role definitions, and Terraform IaC manifests.

Executable implementation artifacts and explicit network configurations represent the final step prior to automated provisioning.

Key Concept

Top-down Cloud Architecture Lifecycle (Conceptual -> Logical -> Physical)

PreviousPage 2 / 9Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept