Examkin

All practice questions

174 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1Question →

An enterprise architecture team is designing an automated progressive delivery release pipeline using Google Cloud Deploy for a microservice deployed on Google Kubernetes Engine (GKE). The pipeline must enforce container image provenance via Binary Authorization and perform automated canary metric verification prior to full traffic shifting.

Arrange the following pipeline execution steps in the correct chronological order from source build to final production rollout.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the progressive delivery pipeline is: 1) Cloud Build compiles the image and generates a Binary Authorization attestation with Cloud KMS, 2) Cloud Build pushes the image to Artifact Registry and registers a release in Cloud Deploy, 3) Cloud Deploy provisions a canary rollout with 10% traffic routing, 4) Cloud Monitoring verifies SLIs during the observation window, and 5) Cloud Deploy advances the phase to route 100% of production traffic.
The deployment pipeline follows a logical progressive delivery workflow: artifact compilation and Binary Authorization attestation signing (via Cloud KMS in Cloud Build) must precede release registration in Google Cloud Deploy. Once registered, Cloud Deploy executes canary traffic shifting (routing 10% traffic), followed by automated SLI evaluation via Cloud Monitoring during an observation window. Only after metric verification completes successfully can Cloud Deploy promote the deployment phase to shift 100% of production traffic.

Step-by-Step Solution

1
Generate build artifacts and attestations in CI
Container image is built and signed via Cloud KMS for Binary Authorization enforcement.
Binary Authorization requires attestations to exist prior to image deployment in protected target environments.
2
Store artifact and trigger Continuous Delivery pipeline
Artifact is stored in Artifact Registry and a Cloud Deploy release is instantiated.
Cloud Deploy releases depend on immutable image digest references stored in Artifact Registry.
3
Execute initial canary phase deployment
Canary pod revision is deployed to GKE with 10% traffic split.
Progressive delivery starts with limited traffic exposure to restrict potential impact from regressions.
4
Perform automated metrics analysis
Cloud Monitoring validates error rates and latency SLIs over the observation period.
Automated telemetry checking confirms system stability before expanding deployment scope.
5
Promote to full production traffic
Cloud Deploy routes 100% of traffic to the new revision.
Successful metric evaluation allows the pipeline to conclude with full production promotion.

Key Concept

Automating Continuous Deployment Pipelines and Release Strategies using Google Cloud Deploy, Binary Authorization, and Canary Analysis
Question 2Question →

An enterprise organization is establishing a secure continuous integration and continuous delivery (CI/CD) pipeline on Google Cloud to deploy containerized applications to Google Kubernetes Engine (GKE) under strict Binary Authorization compliance policies. Arrange the operational pipeline stages in the correct chronological order from the initial developer code check-in to successful pod scheduling in the cluster.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for a secure GKE CI/CD pipeline starts with the developer code commit triggering Cloud Build, followed by image creation and unit testing, uploading the image to Artifact Registry for automated Container Analysis vulnerability scanning, cryptographically signing the image via Cloud KMS to create a Binary Authorization attestation, and finally evaluating the attestation at the GKE admission controller during pod deployment.
A secure GCP continuous deployment pipeline enforces supply chain security in a strict linear sequence: Source Code Repository Trigger -> Automated Compilation & Unit Testing -> Artifact Storage & Vulnerability Scanning -> Policy Attestation Signature via Cloud KMS -> Runtime Enforcement at GKE Admission.

Step-by-Step Solution

1
Identify the pipeline trigger stage
Developer pushes code to version control, which invokes the Cloud Build webhook trigger.
CI/CD execution begins with source revision control events.
2
Identify artifact construction and local verification
Cloud Build compiles, unit tests, and packages application binaries into a container image.
Code must pass local quality gates prior to repository registration.
3
Identify vulnerability evaluation stage
The container image is pushed to Artifact Registry, triggering Container Analysis scanning.
Artifact Registry integration is necessary for automated vulnerability and metadata extraction.
4
Identify attestation creation stage
Upon successful scan results, Cloud Build requests Cloud KMS signing to generate a Binary Authorization attestation.
Attestations certify that compliance and security standard checks passed.
5
Identify final runtime deployment admission
GKE Binary Authorization admission controller verifies the attestation signature before allowing pod scheduling.
Binary Authorization enforces trust policies at runtime deploy time in the Kubernetes API server.

Key Concept

End-to-End Secure Software Supply Chain Integration with Cloud Build, Artifact Registry, Container Analysis, and Binary Authorization
Question 3Question →

A multinational financial services enterprise hosts its core payment authorization pipeline across two Google Cloud regions (primary in us-central1, secondary in us-east4). The enterprise requires a quarterly Business Continuity and Disaster Recovery (BCP/DR) drill to validate cross-region failover efficiency under an RPO target of under 1 minute and an RTO target of under 15 minutes. As the Lead Cloud Architect, you must sequence the technical steps for executing and verifying this DR validation exercise without causing unintended data loss or unexpected service failure. Arrange the operational steps below in the correct execution sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution order is: 1) Audit compute quota limits and capacity reservations in us-east4; 2) Check Cloud Monitoring cross-region replication lag; 3) Promote standby database in us-east4 and update Cloud DNS routing policies; 4) Run automated synthetic transaction suites in us-east4 to verify integrity and RTO; 5) Configure reverse replication from us-east4 back to us-central1.
The proper DR validation sequence starts with pre-flight checks (confirming compute quotas and capacity reservations, followed by checking replication lag against RPO metrics). Next, the failover is executed by promoting the DR database and updating DNS routing. Afterwards, functional integrity and RTO metrics are validated using synthetic transaction tests. Finally, reverse replication is established back to the primary region to prepare for clean failback without data loss.

Step-by-Step Solution

1
Pre-flight resource availability verification
Confirmed sufficient regional quotas and reserved compute capacity in the DR target region (us-east4).
Failing to check compute quotas beforehand can cause Compute Engine instance creation to fail during switchover.
2
RPO compliance verification
Verified replication lag is within the required 1-minute window.
Initiating failover when replication lag is high violates RPO objectives and leads to unrecoverable data loss.
3
Failover execution and traffic redirection
Secondary database promoted to write mode and active network traffic redirected to us-east4.
Database promotion and DNS record updates transition the secondary site to active primary status.
4
Failover validation and RTO timing verification
Synthetic transaction suite executed cleanly and total failover time measured against RTO SLA.
Post-failover validation ensures the secondary environment operates reliably under real transaction conditions.
5
Failback preparation and reverse synchronization
Reverse replication initialized from us-east4 back to us-central1.
Re-establishing reverse replication preserves data written to us-east4 during the validation drill before returning primary operations to us-central1.

Key Concept

Developing Procedures for Business Continuity and Disaster Recovery Validation
Estimated Time:2m 30s
Question 4Question →

An enterprise security architect is designing an automated credential rotation workflow for a PostgreSQL database. The database credentials must be stored in Google Cloud Secret Manager, encrypted using a Customer-Managed Encryption Key (CMEK) stored in Cloud KMS, and automatically rotated every 30 days using a dedicated Cloud Run rotation service triggered by Pub/Sub notifications. You must establish the secure lifecycle configurations and IAM bindings following the principle of least privilege. What is the correct sequence of steps to configure this automated secret rotation workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps begins by granting the Secret Manager Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the CMEK key. Next, create the rotation Pub/Sub topic and the Secret Manager secret configured with CMEK. Third, grant the Secret Manager Service Agent the Pub/Sub Publisher role on the topic. Fourth, deploy the Cloud Run rotation service bound to a service account with the Secret Manager Secret Version Manager role. Finally, set the 30-day automatic rotation schedule on the secret.
The lifecycle of automated Secret Manager rotation with CMEK requires precise prerequisite sequencing. First, the Secret Manager Service Agent must have `cloudkms.cryptoKeyEncrypterDecrypter` permissions on the Cloud KMS key to allow secret creation and version encryption. Second, the secret can be created using CMEK alongside the designated Pub/Sub topic reference. Third, the Secret Manager Service Agent must be granted `pubsub.publisher` on the Pub/Sub topic so rotation events can be sent. Fourth, the Cloud Run rotation handler service must be deployed with a service account possessing `roles/secretmanager.secretVersionManager` to handle payload generation and updating credentials. Finally, applying the rotation schedule on the secret activates the end-to-end automated workflow without execution errors.

Step-by-Step Solution

1
Authorize Secret Manager to access Cloud KMS
Secret Manager Service Agent receives cloudkms.cryptoKeyEncrypterDecrypter on the CMEK key.
Secret Manager cannot write or wrap secrets using CMEK until its system-generated service agent has explicit encryption and decryption permissions.
2
Provision Pub/Sub topic and CMEK-encrypted Secret
The Pub/Sub notification channel and CMEK-encrypted secret object exist in Secret Manager.
Creating the secret object requires active KMS access and specifies the topic where rotation events will be published.
3
Authorize Secret Manager to publish Pub/Sub events
Secret Manager Service Agent receives pubsub.publisher on the topic.
Secret Manager must be granted publishing rights so that rotation schedule events can reach the Pub/Sub topic.
4
Deploy rotation service with appropriate IAM identity
Cloud Run service is deployed using a custom service account with secretmanager.secretVersionManager.
The compute worker performing credential rotation needs permissions to read secret versions, write new versions, and update database passwords.
5
Activate automatic rotation schedule
The secret's rotation schedule is set to 30 days.
Enabling rotation on the secret initiates automated lifecycle events, which depend on all underlying IAM permissions and endpoints being fully configured.

Key Concept

Secret Manager Automated Rotation Lifecycle with CMEK and Service Accounts
Question 5Question →

An enterprise intermodal freight operator is designing a modernized fleet telemetry system on Google Cloud. As the Principal Cloud Architect, you must translate high-level business requirements into a production-ready solution following Google Cloud architecture framework best practices. Place the architectural design phases in the correct sequential order, starting from initial business abstraction down to physical infrastructure deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with defining the Conceptual Architecture (functional business capabilities), followed by formulating the Logical Architecture (component boundaries and data flows), specifying the Physical Architecture component mapping (selecting Google Cloud services), and finally executing Physical Resource Deployment (provisioning via Infrastructure-as-Code).
The standard architectural design progression begins with the Conceptual Architecture (establishing high-level functional capabilities from business needs), progresses to the Logical Architecture (defining technology-agnostic data flows, security boundaries, and component interfaces), transitions to Physical Architecture selection (mapping logical blocks to specific Google Cloud services such as Cloud Pub/Sub and Bigtable), and culminates in Physical Deployment (instantiating actual GCP infrastructure via IaC).

Step-by-Step Solution

1
Identify the conceptual design phase
Map business requirements and SLA/SLO expectations into vendor-neutral functional capabilities.
Designing starts at the highest abstraction layer to ensure alignment with business goals before choosing technical components.
2
Determine the logical component structure
Define data movement patterns, security boundaries, and architectural patterns (e.g., event-driven ingestion, stream processing).
Logical modeling organizes interaction patterns and data contracts without locking into specific Cloud vendor SKUs.
3
Select physical Google Cloud products
Map logical tiers to physical GCP services like Pub/Sub, Cloud Bigtable, BigQuery, and VPC Service Controls.
Physical selection requires matching technical constraints (throughput, latency, compliance) to actual cloud service specs.
4
Provision physical infrastructure
Write and apply declarative IaC templates (Terraform) to deploy VPC networks, IAM roles, KMS keys, and compute clusters.
Deployment is the final execution stage where concrete infrastructure resources are instantiated in the target GCP projects.

Key Concept

Architectural Abstraction Layers (Conceptual -> Logical -> Physical)
Question 6Question →

An enterprise organization is restructuring its software delivery lifecycle to establish an end-to-end secure, automated CI/CD pipeline for deploying a critical microservice to Google Kubernetes Engine (GKE). The security policy mandates least-privilege access, container vulnerability scanning, cryptographic image attestation using Binary Authorization, Terraform state validation, and controlled canary traffic routing. Place the operational stages of this deployment pipeline in the correct chronological order from initial source submission to full production release.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with Cloud Build compiling the container image and performing static security and vulnerability analysis via Artifact Analysis. Once validated, Cloud Build uses Cloud KMS to generate a cryptographic Binary Authorization attestation and pushes the image and signature to Artifact Registry. Next, Cloud Build uses Workload Identity Federation with a dedicated user-managed service account to validate infrastructure state via `terraform plan`. Cloud Deploy then initiates deployment to GKE, where Binary Authorization verifies the KMS signature before establishing a 10% canary traffic allocation. Finally, Cloud Monitoring evaluates canary stability metrics against defined Service Level Indicators (SLIs) before Cloud Deploy automatically promotes the release to 100% production traffic.
The sequence follows Google Cloud best practices for secure SDLC and progressive delivery. Artifact vulnerability scanning must precede attestation signing so that only clean images receive KMS signatures. Infrastructure state validation via Terraform and Workload Identity Federation ensures environment readiness. GKE Binary Authorization enforces the signature requirement at cluster admission during Cloud Deploy canary launch. Finally, canary health observation against Cloud Monitoring SLIs ensures automated, risk-managed full promotion.

Step-by-Step Solution

1
Perform initial artifact construction and security scanning.
Container image built and checked for vulnerabilities via Container Analysis prior to artifact signing.
Security checks must run immediately at artifact creation to prevent compromised code from proceeding further into the pipeline.
2
Sign the validated container image and push to Artifact Registry.
A cryptographic attestation linked to Cloud KMS is produced and stored along with the container image.
Binary Authorization policies require a verified attestation signature tied to a compliant image digest before cluster admission.
3
Validate infrastructure state changes.
Terraform plans are generated against remote GCS backends using short-lived credentials via Workload Identity Federation.
Least-privilege service account authentication ensures infrastructure drift and state lock checks complete securely before deployment.
4
Trigger canary deployment under admission policy control.
GKE Binary Authorization validates the KMS signature and Cloud Deploy routes 10% of live traffic to the canary workloads.
Admission control prevents unauthorized container execution while canary deployment minimizes blast radius for new code.
5
Evaluate canary health metrics and complete production promotion.
Cloud Monitoring confirms error budget integrity and SLI health, triggering 100% traffic rollout.
Automated metrics verification ensures production stability before full rollout.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Analysis
Question 7Question →

An enterprise Site Reliability Engineering (SRE) team is implementing an automated incident response and notification suppression pipeline on Google Cloud for a mission-critical financial settlement service. The pipeline must detect SLO degradation, prevent alert storms during active outages, execute automated self-healing without relying on long-lived service account keys or primitive IAM roles, and archive operational telemetry for post-mortems. In what chronological sequence should the SRE team structure the operational steps for this automated incident lifecycle?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with configuring multi-window multi-burn-rate SLO alerting, followed by publishing incident payloads to Pub/Sub while enabling Cloud Monitoring Muting Rules, invoking a Workload Identity-authenticated Cloud Run remediation handler for diagnostic log extraction, executing targeted recovery using granular IAM roles, and concluding with metric stabilization verification, un-muting alerts, and exporting incident telemetry to BigQuery.
The proper operational order reflects Google Cloud SRE best practices: (1) Detection using multi-window multi-burn-rate SLO alerts ensures precise identification of error budget depletion; (2) Event decoupling via Pub/Sub paired with Cloud Monitoring Muting Rules prevents alert storms during active mitigation; (3) Automated triage workers leverage Workload Identity to inspect correlation logs securely; (4) Targeted remediation executes using least-privilege IAM roles; and (5) Metrics are verified for recovery before resolving the incident, removing muting rules, and streaming telemetry to BigQuery for post-mortem analysis.

Step-by-Step Solution

1
Detect error budget depletion via Cloud Monitoring multi-window multi-burn-rate alerting policies.
High-fidelity incident alert triggers upon identifying sustained consumption of the service error budget.
SLO multi-burn-rate logic prevents false positives and detects rapidly evolving outages as the initial entry point of the incident lifecycle.
2
Publish alert event to Cloud Pub/Sub and enable Cloud Monitoring Muting Rules.
Incident event dispatches to automated pipelines while downstream notification channels are suppressed.
Alert suppression prevents alert fatigue and notification storms across operations teams while automated remediation is underway.
3
Trigger Cloud Run triage container using Workload Identity federation to inspect Cloud Logging traces.
Diagnostic context is securely fetched without static service account keys or primitive roles.
Automated handlers must query log correlation IDs to confirm failure modes prior to executing stateful remediation actions.
4
Perform infrastructure mitigation using least-privilege IAM service account permissions.
Service baseline health is restored via automated traffic re-routing or canary rollback.
Remediation acts on confirmed telemetry to stabilize the application layer.
5
Verify metric stabilization in Cloud Monitoring, lift muting rules, and stream incident telemetry to BigQuery.
The incident state automatically resolves and historical telemetry is stored for SRE post-mortems.
Formal incident closure requires verifying recovery in Monitoring baselines before resetting alert mutes and capturing post-mortem data.

Key Concept

End-to-end GCP incident management lifecycle using SLO multi-burn-rate alerting, Pub/Sub orchestration, Muting Rules for alert fatigue mitigation, Workload Identity security, and post-incident analytics.
Estimated Time:3m 0s
Question 8Question →

An enterprise web application deployed across primary region `us-central1` and secondary recovery region `us-east4` experiences a total regional failure in `us-central1`. The application uses a Pilot Light DR pattern comprising a Cloud SQL PostgreSQL cross-region read replica and a minimal regional Managed Instance Group (MIG) in `us-east4`. To achieve recovery without split-brain data corruption or premature exposure of unvalidated endpoints, in what exact sequence should the SRE team execute the disaster recovery failover runbook tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence for regional DR failover is: 1) Isolate `us-central1` compute and database write paths to eliminate split-brain risk, 2) Promote the `us-east4` Cloud SQL cross-region read replica to standalone primary, 3) Scale up the `us-east4` Managed Instance Group to full capacity, 4) Execute synthetic health and data integrity checks against the internal `us-east4` endpoint, and 5) Update Global Load Balancer backends to direct ingress traffic to `us-east4`.
In GCP enterprise DR execution, ensuring data consistency and split-brain prevention is the highest priority. The primary degraded region must first be fenced off by revoking write access. Next, the secondary database replica is promoted to primary so that compute nodes have a valid write target. Then, the pilot-light MIG is scaled to full capacity to accommodate production traffic. Next, internal synthetic validation tests verify system readiness. Finally, the Global Load Balancer backend configuration is updated to route public client traffic to the secondary region.

Step-by-Step Solution

1
Isolate the primary region
Primary database and compute components are locked from receiving new writes, preventing data divergence.
Before promoting a secondary database, the primary region must be fenced off so that transient network recoveries do not cause split-brain data writes.
2
Promote the database replica
The Cloud SQL replica in `us-east4` becomes an independent primary database.
Application services cannot process state-changing user transactions until a writeable primary database is established.
3
Scale up compute capacity
The pilot-light MIG expands instances to handle production request volumes.
Compute resources must be provisioned and connected to the newly promoted database before receiving production workload demands.
4
Perform synthetic validation
Smoke tests confirm schema integrity, connection pool behavior, and application startup cleanliness.
Directing live user traffic to an unvalidated secondary stack risks mass request drops or silent application failures.
5
Shift global ingress traffic
The Global External Load Balancer routes user requests to the fully healthy secondary region.
Traffic shifting completes the failover procedure once end-to-end operational readiness is validated.

Key Concept

Disaster Recovery Failover Execution & Split-Brain Prevention
Question 9Question →

A global supply chain enterprise operates a critical order management platform with a warm standby disaster recovery topology across Google Cloud regions `us-central1` (primary) and `europe-west3` (secondary). The application relies on Cloud SQL for PostgreSQL with asynchronous cross-region read replication. Following an unrecoverable regional disaster in `us-central1`, the operational engineering team must execute the disaster recovery runbook to restore service while ensuring data consistency and preventing split-brain states. In what sequential order should the operational team execute the disaster recovery failover tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins by stopping ingress traffic and revoking write permissions on the primary region to prevent split-brain updates. Next, promote the cross-region Cloud SQL read replica in the secondary region to a standalone read-write database instance. Third, scale up the secondary Compute Engine managed instance groups to handle full application load. Fourth, update Cloud DNS routing policies to direct client traffic to the secondary region endpoints. Finally, re-establish disaster recovery redundancy by enabling backup schedules and creating a new cross-region read replica from the newly promoted primary instance.
The correct operational order minimizes data loss and prevents split-brain scenarios. First, isolating the degraded primary stops incoming transactions and lets asynchronous replication finish applying in-flight logs. Second, promoting the database replica enables write capabilities in the secondary region. Third, scaling up compute capacity ensures the secondary application tier can handle the incoming user load. Fourth, modifying DNS records steers user traffic to the active secondary region. Finally, restoring backup schedules and creating a new cross-region replica re-establishes disaster recovery protection.

Step-by-Step Solution

1
Isolate the primary region workload
Prevents split-brain conditions and ensures all in-flight asynchronous database replication logs settle.
Promoting a replica while writes are still hitting the primary can lead to data divergence or corrupted application state.
2
Promote the secondary database replica
The Cloud SQL instance in `europe-west3` becomes a standalone primary database supporting read and write operations.
Application services cannot function properly without a writable persistent storage layer.
3
Provision and scale compute capacity in the secondary region
Compute Engine managed instance groups scale out to 100% target production size.
Ensures the application tier has sufficient resources to process production traffic without failure or severe latency degradation.
4
Redirect traffic via Cloud DNS
Client application traffic flows to the secondary region load balancer.
Traffic must only be routed once the underlying storage and compute layers are fully operational and ready to serve requests.
5
Re-establish disaster recovery redundancy
Automated backups are configured and a new secondary replica is provisioned in a third region or restored environment.
Leaves the enterprise with continuous DR protection following the primary region loss.

Key Concept

Disaster Recovery Failover Sequence and Split-Brain Prevention
Question 10Question →

An enterprise operating a multi-folder Google Cloud resource hierarchy needs to stream all Data Access audit logs and Security Command Center (SCC) Premium findings to a third-party SIEM hosted on Google Kubernetes Engine (GKE). The security architecture must adhere to the principle of least privilege and ensure zero log loss. What is the correct sequence of steps to implement this centralized logging and threat export pipeline?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: First, provision the Pub/Sub topic and subscription in the central SecOps project. Second, create the organization-level aggregated log sink with include-children enabled. Third, grant the sink's writer identity the Pub/Sub Publisher role on the topic. Fourth, configure the SCC continuous export at the organization level pointing to the Pub/Sub topic. Fifth, bind the GKE Workload Identity service account to the Pub/Sub Subscriber role on the subscription.
Building a centralized security logging pipeline in Google Cloud requires creating target ingestion infrastructure (Pub/Sub topic/subscription) before referencing it in log sinks or SCC exports. Once the aggregated sink is created with `--include-children`, GCP generates a service account (writer identity) that must be explicitly granted `roles/pubsub.publisher` on the topic. After establishing log flow authorization, SCC continuous export is configured. Finally, the consumer SIEM workload on GKE is authorized using Workload Identity with `roles/pubsub.subscriber` on the subscription.

Step-by-Step Solution

1
Provision Pub/Sub Topic and Subscription
Destinations are created and ready to receive streaming logs and findings.
Log sinks and continuous exports require an existing target resource URI during creation validation.
2
Create Organization-Level Aggregated Log Sink
Aggregated log sink is instantiated across all folders/projects and generates a unique writer identity service account.
Creating the sink defines the filter rules and generates the service account identity needed for IAM authorization.
3
Authorize Log Sink Writer Identity
Writer identity is granted `roles/pubsub.publisher` on the destination Pub/Sub topic.
Google Cloud log sinks do not automatically receive write access to destination resources across project boundaries.
4
Configure SCC Continuous Export
Security Command Center streams real-time threat findings to the Pub/Sub topic.
Continuous export streams findings as they occur once the target Pub/Sub topic infrastructure is established.
5
Grant Subscriber Permissions via Workload Identity
SIEM workload on GKE securely pulls audit logs and findings using Workload Identity.
Adheres to least privilege security requirements for application ingestion without managing exported service account keys.

Key Concept

Organization-level log aggregation, service account authorization for log sinks, Security Command Center continuous export, and GKE Workload Identity integration.
Estimated Time:3m 0s
Question 11Question →

A regulatory compliance audit requires a healthcare organization to capture all Google Cloud Data Access audit logs across all projects and securely retain them for seven years. The solution must ensure that log data is encrypted using customer-managed encryption keys (CMEK) and protected against premature deletion or tampering by any privileged user, including organization admins. In which chronological order should a Cloud Security Architect perform the required implementation steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by enabling Data Access audit logging at the organization level, provisioning a Cloud KMS key and granting the Cloud Logging service agent necessary crypto permissions, building the CMEK-encrypted log bucket with a 7-year retention window, creating the organization-aggregated log sink targeting this bucket, and finally locking the log bucket retention policy.
The sequence follows the logical dependency chain for secure compliance logging in GCP: first generating the required audit log stream (Data Access logs), then preparing encryption keys and granting key-access permissions to the logging service agent, followed by creating the target CMEK-enabled log bucket with the required retention period. Next, the organization-level aggregated sink is configured to route logs to the target bucket. Finally, after verification, the retention policy is locked to enforce immutable WORM compliance.

Step-by-Step Solution

1
Configure organization-wide Audit Config policy to capture Data Access logs for the designated services.
GCP services begin generating Data Access audit trail logs for data read and write calls across all current and future projects.
Data Access logs are disabled by default due to high volume, so they must be explicitly turned on at the hierarchy root.
2
Provision a KMS Key Ring and Key, then assign roles/cloudkms.cryptoKeyEncrypterDecrypter to the logging service service account.
Cloud Logging is authorized to use the customer-managed key for encrypting and decrypting log data.
Creating a CMEK-encrypted log bucket will fail if the Cloud Logging service account lacks active encrypter/decrypter permissions on the specified key.
3
Provision a custom Cloud Logging bucket with 2555 days of retention bound to the created Cloud KMS key.
A secure, CMEK-backed log bucket destination is established within Cloud Logging.
The log sink destination must exist and be properly configured before an aggregated sink can start routing log entries to it.
4
Establish an organization-level aggregated log sink pointing to the custom log bucket with an explicit filter targeting Data Access logs.
Data Access audit logs generated across all child projects and folders automatically aggregate into the custom CMEK log bucket.
Aggregated sinks catch logs across the entire organizational hierarchy, avoiding project-by-project manual sink management.
5
Execute the bucket retention lock command against the custom log bucket.
The retention policy becomes permanent and immutable, enforcing strict compliance against deletion.
Locking the policy enforces WORM (Write Once Read Many) guarantees required by legal and regulatory frameworks.

Key Concept

Organization-level CMEK-encrypted log retention and immutable bucket lock implementation for compliance audit logging.
Estimated Time:2m 30s
Question 12Question →

An enterprise organization is establishing an automated, highly reliable Infrastructure as Code (IaC) continuous integration and deployment pipeline using Cloud Build and Terraform to provision multi-region production environments on Google Cloud. The architecture must guarantee state safety, strictly enforce security guardrails before resource creation, and prevent deployment rollouts if operational verification fails. In what sequential order should the pipeline execute these environment provisioning steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with authenticating and acquiring the backend state lock, followed by generating the plan with automated policy validation, applying the resource changes, executing post-provisioning verification tests, and finally recording deployment audit logs while releasing the state lock.
A reliable IaC deployment pipeline follows a strict sequence: lock state and authenticate, validate plan against security policies, apply changes, verify live health post-deployment, and unlock state while logging audit events.

Step-by-Step Solution

1
Authenticate using keyless service account impersonation and acquire the GCS backend state lock.
Establishes secure, short-lived IAM credentials and prevents concurrent state file access.
Acquiring state lock prior to execution ensures state consistency and prevents race conditions across CI/CD workers.
2
Run static analysis and policy checking tools against the output of 'terraform plan'.
Identifies compliance violations and security misconfigurations prior to resource deployment.
Evaluating infrastructure plans against policy-as-code ensures security and compliance guardrails are enforced before infrastructure modification.
3
Execute 'terraform apply' targeting the specified GCP environment configuration.
Provisions and configures GCP infrastructure components defined in the Terraform configuration files.
Resource creation can only safely proceed after the plan passes both syntax and policy validation checks.
4
Run automated post-deployment validation and health verification testing.
Confirms operational readiness, network routing, and service health against SLO criteria.
Verifying infrastructure functionality ensures that misconfigured resources are detected before routing live business workloads.
5
Log pipeline deployment completion metrics and release the remote GCS state lock.
Completes the pipeline execution lifecycle and frees the state file for subsequent pipeline runs.
Unlocking the state backend and updating compliance audit trails must be executed as the final step in the pipeline lifecycle.

Key Concept

Reliable Infrastructure as Code Pipeline Lifecycle and State Lock Management
Estimated Time:3m 0s
Question 13Question →

An operations engineer needs to set up automated alerts whenever specific application error log entries occur in Google Cloud. Order the steps required to configure an operational alert using a custom log-based metric and Cloud Monitoring.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for configuring operational alerts based on log events is: 1) Define the filter query in Cloud Logging, 2) Create a custom log-based metric from the filter, 3) Configure an alerting policy in Cloud Monitoring referencing the custom metric, and 4) Attach notification channels to the alerting policy.
The logical sequence for establishing operational alerting from raw logs begins by defining a log filter in Cloud Logging. Next, a custom log-based metric is created to extract data or count matching log lines over time. Then, Cloud Monitoring uses this log-based metric to build an alerting policy with specific threshold triggers. Finally, notification channels are associated with the policy to complete the alert delivery setup.

Step-by-Step Solution

1
Filter Logs in Cloud Logging
Specific error log entries are isolated from general log streams.
Before metrics or alerts can be built, the exact criteria matching the desired log entries must be identified.
2
Generate Log-based Metric
A continuous metric stream is made available to Cloud Monitoring based on log occurrence count or extracted values.
Cloud Monitoring requires metric data to evaluate threshold alerts over time.
3
Create Cloud Monitoring Alerting Policy
Alert condition threshold rules are defined against the log-based metric.
The monitoring system evaluates incoming metric data against defined operational thresholds.
4
Attach Notification Channels & Enable Policy
The operational alerting pipeline is fully functional and alerts appropriate personnel upon breach.
Without designated notification channels, alerts cannot reach operations teams.

Key Concept

Configuring Log-Based Metrics and Operational Alerting in GCP
Estimated Time:1m 0s
Question 14Question →

An enterprise needs to perform an offline bulk migration of 200 TB of archive data from an on-premises data center to Google Cloud Storage using a Transfer Appliance. In what chronological sequence should the cloud architect perform the key steps of this transfer strategy?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with requesting and receiving the Transfer Appliance, followed by connecting and copying encrypted data locally, shipping the device back to Google for ingestion, and concluding with checksum integrity verification in Cloud Storage.
The correct workflow for offline migration using Transfer Appliance requires procuring the physical hardware first, copying and encrypting data locally, shipping the appliance to Google for data ingestion, and validating object integrity in Cloud Storage once upload completes.

Step-by-Step Solution

1
Device Procurement
The physical Transfer Appliance is delivered to the on-premises data center.
Hardware must be on site before local staging can start.
2
Local Data Ingestion
The 200 TB of archive data is written to and encrypted on the appliance.
Data must be loaded onto the device locally using high-speed network interfaces.
3
Return Shipment & Cloud Ingestion
Google receives the device and uploads the data into the designated Cloud Storage bucket.
Physical transportation to Google avoids consuming external network bandwidth.
4
Post-Transfer Validation
Objects in Cloud Storage are confirmed accurate and ready for operational use.
Final validation ensures no corruption occurred during transport and ingestion.

Key Concept

Offline Data Transfer Lifecycle using Transfer Appliance
Estimated Time:1m 0s
Question 15Question →

An operations team needs to set up automated alerting for specific application error logs occurring in a Compute Engine environment. Order the configuration steps from first to last to establish a complete log-based alerting workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with defining the log filter query in Cloud Logging, followed by building a custom log-based metric, configuring the Cloud Monitoring alert policy threshold on that metric, and finally attaching notification channels to deliver the alerts.
To alert on log events, you must first construct a log filter query in Cloud Logging to identify matching log lines. Second, you convert those matching logs into a time-series metric by creating a log-based metric. Third, you set up an alert policy within Cloud Monitoring that monitors the log-based metric threshold. Finally, you attach notification channels to the alert policy to notify personnel when the condition is violated.

Step-by-Step Solution

1
Construct the log query filter in Cloud Logging
Specific error log entries are precisely selected from the project log streams.
Log-based metrics require a precise filter string to select which log events should be counted.
2
Create a custom counter log-based metric
A new time series metric (logging.googleapis.com/user/<metric_name>) is generated whenever matching log events arrive.
Cloud Monitoring cannot directly set alert policies on raw unstructured logs; log entries must first be converted into numerical metric time-series data.
3
Create an Alert Policy in Cloud Monitoring using the log-based metric
Threshold condition and aggregation window (e.g., rate of error logs > 5 over 5 minutes) are established.
Alerting policies evaluate conditions against metric time series data to determine incident status.
4
Configure and attach notification channels to the Alert Policy
Alert notifications are routed to on-call engineers via SMS, Email, PagerDuty, or Webhooks when incidents open.
Notification channels direct alert state changes to operational teams.

Key Concept

Configuring custom log-based metrics and operational alert policies in Google Cloud Monitoring
Estimated Time:1m 30s
Question 16Question →

A cloud engineering team needs to safely migrate an existing local Terraform state file to a secure Google Cloud Storage (GCS) remote backend with state locking enabled. Arrange the operational steps in the correct sequence to complete this migration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with provisioning the private GCS bucket with Object Versioning enabled, adding the GCS backend configuration block to the Terraform module, executing terraform init to migrate the state data, and finally verifying remote state creation before deleting the local state file.
Safely migrating Terraform state requires provisioning the remote GCS bucket with Object Versioning first, defining the backend block in the Terraform code second, executing terraform init to copy existing local state into GCS third, and removing local state files fourth to maintain a single source of truth.

Step-by-Step Solution

1
Provision Destination GCS Bucket
A secure GCS bucket configured with Object Versioning and uniform bucket-level access is available.
Google Cloud Storage must exist to host state files and provide Cloud KMS/IAM lock capabilities.
2
Configure Terraform Backend
The backend configuration is declared in code.
Terraform requires explicit backend parameters in code to identify the migration target.
3
Run State Migration Command
Local state file contents are securely uploaded to GCS.
Executing terraform init triggers Terraform's internal state migration mechanism.
4
Post-Migration Verification and Cleanup
Local state artifacts are deleted, establishing GCS as the single source of truth.
Removing redundant local state files prevents unauthorized access and operational confusion.

Key Concept

Terraform GCS Remote Backend State Migration
Estimated Time:1m 30s
Question 17Question →

A DevOps engineer needs to migrate an existing local Terraform state file to a Google Cloud Storage (GCS) remote backend for shared team access. What is the correct sequence of steps to migrate the local Terraform state to the GCS remote backend?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the GCS storage bucket with versioning, followed by declaring the GCS backend in the Terraform code, executing terraform init to migrate state, and finally confirming successful migration before cleaning up local state files.
The GCS bucket must be created first because Terraform requires an existing bucket to initialize its remote state. Once the bucket exists, the backend configuration block is added to code. Running terraform init detects the new backend configuration and performs the migration from local disk to GCS. Finally, verification and cleanup ensure all team members use the single remote source of truth.

Step-by-Step Solution

1
Provision the destination storage bucket in Google Cloud
A secure GCS bucket with versioning enabled is ready to accept state files
Terraform cannot automatically create the remote backend bucket during backend initialization if it does not exist
2
Add the backend backend 'gcs' block to main.tf or provider configuration
Terraform configuration is updated with remote state directives
Terraform requires the explicit bucket name and prefix to connect to the remote backend
3
Execute terraform init
Terraform detects the backend change and transfers state from local disk to GCS
The initialization command performs the state migration process interactively or automatically
4
Verify remote state in GCS and remove local state files
Single source of truth is established in remote storage without duplicate local state
Removing redundant local state files prevents accidental state drift and local execution

Key Concept

Terraform GCS Remote Backend State Migration Workflow
Question 18Question →

An enterprise is planning a near-zero downtime database migration from an on-premises PostgreSQL database to Google Cloud SQL for PostgreSQL using Database Migration Service (DMS). Place the following migration steps in the correct chronological execution order from initial preparation to final cutover.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequential order for a Database Migration Service baseline and CDC workflow is: first configure source WAL and private network access, then provision Cloud SQL and establish schema structures, launch the initial full data snapshot transfer, monitor CDC replication latency until synced, and finally halt source writes, promote Cloud SQL, and update application connection endpoints.
A structured online migration requires enabling WAL logging and network connectivity first, provisioning the destination schema, running the full baseline dump via DMS, monitoring CDC until lag reaches near zero, and performing final application cutover.

Step-by-Step Solution

1
Configure network and source logging prerequisites
WAL and private connectivity ready for streaming
Database Migration Service requires network line-of-sight and WAL configuration to track change data.
2
Provision Cloud SQL instance and apply schema DDL
Target database ready to receive snapshot data
The destination database environment must be structured with matching schema DDL prior to snapshot ingestion.
3
Initiate snapshot data loading via DMS
Baseline historical dataset transferred to Cloud SQL
Initial full dump populates the baseline state before delta sync can occur.
4
Track continuous CDC stream lag
Target database continuously synced with ongoing source writes
Monitoring CDC lag ensures the destination is in sync prior to executing scheduled cutover windows.
5
Execute cutover and promote target instance
Application traffic directed to new Cloud SQL database
Pausing source writes and promoting target database completes the migration cleanly without missing data.

Key Concept

Homogeneous database migration sequencing using Google Cloud Database Migration Service (DMS) with continuous CDC.
Estimated Time:2m 0s
Question 19Question →

A multinational retail enterprise is planning to migrate its core e-commerce database (a 40 TB PostgreSQL instance) and associated 300 TB object store from an on-premises data center to Google Cloud (Cloud SQL for PostgreSQL and Cloud Storage). The enterprise mandates continuous data synchronization prior to cutover to comply with a strict maximum allowed maintenance window of 30 minutes. What is the correct sequence of steps to plan and execute this zero-data-loss migration strategy?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution sequence is: Establish hybrid network connectivity -> Perform baseline data and database snapshot transfer -> Configure continuous CDC via Database Migration Service -> Freeze on-premises writes, wait for zero replication lag, and promote target database -> Redirect application traffic to GCP endpoints and validate operational status.
A structured database migration designed for strict SLA maintenance windows must follow a logical dependency chain: 1) Secure network connectivity via Interconnect, 2) Bulk initial baseline transfer for large static storage and initial database snapshot, 3) Real-time CDC streaming via Database Migration Service to minimize divergence, 4) Controlled maintenance window freeze of source write operations, confirmation of zero replication lag, and promotion of target instance, and 5) Final application endpoint redirection and validation.

Step-by-Step Solution

1
Establish network connectivity foundation
Hybrid connectivity via Dedicated or Partner Interconnect with Cloud Router BGP sessions established.
Secure, reliable, high-throughput private communication must precede any bulk or streaming data movement between environments.
2
Execute initial bulk baseline load
300 TB object data transferred via Storage Transfer Service and 40 TB database snapshot restored onto Cloud SQL target.
Establishes the initial historical data baseline in Google Cloud before starting delta capture.
3
Enable continuous Change Data Capture (CDC)
GCP Database Migration Service (DMS) actively streams logical write-ahead logs (WAL) from on-premises PostgreSQL to Cloud SQL.
Maintains low replication lag and near-real-time parity between source and target databases while production remains live.
4
Execute cutover and promote target instance
On-premises application writes are stopped, DMS sync achieves zero-second lag, continuous replication is stopped, and Cloud SQL target is promoted to standalone primary.
Guarantees zero data loss and prepares the target database to accept new write operations within the 30-minute maintenance window.
5
Redirect traffic and complete migration
Application configuration endpoints updated to target Cloud SQL and Cloud Storage; health checks pass.
Completes final transition of user requests to the GCP infrastructure.

Key Concept

Minimal-downtime database and data migration using baseline snapshot transfer and continuous CDC replication via GCP Database Migration Service.
Question 20Question →

A Cloud Architect needs to migrate an existing local Terraform state file containing critical production Google Cloud resources to a secure Google Cloud Storage (GCS) remote backend with state locking and CMEK encryption. Arrange the operational steps in the correct chronological order to safely complete this backend migration while maintaining resource integrity.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with provisioning and securing the remote GCS bucket, adding the `backend "gcs"` configuration to the Terraform code, executing `terraform init -migrate-state` to copy state data, running `terraform plan` to verify zero drift, and finally purging local state file artifacts.
Migrating Terraform state safely requires creating the remote GCS backend infrastructure first, declaring the backend in HCL, using the CLI tool's dedicated `-migrate-state` command to copy existing resource records under a state lock, verifying state synchronization via a plan, and lastly removing legacy local state files.

Step-by-Step Solution

1
Provision GCS storage bucket with object versioning, CMEK, and minimal IAM permissions.
Secure storage destination for remote state management is established.
The GCS bucket must exist and have proper state locking and security controls before Terraform can communicate with it.
2
Add the `backend "gcs"` block into the Terraform root configuration.
Terraform configuration points to the targeted GCS bucket.
Terraform needs backend definitions in HCL to recognize the change from local backend to remote GCS storage.
3
Execute `terraform init -migrate-state`.
Local state contents are safely copied into GCS state storage under state lock protection.
The `-migrate-state` flag explicitly instructs Terraform to copy existing local state metadata to the newly configured backend.
4
Run `terraform plan` to validate infrastructure synchronization.
Confirmation of zero resource changes or state corruption.
Validation against live Google Cloud resources ensures that state pointers were migrated without drift.
5
Remove local `terraform.tfstate` files.
Prevention of concurrent local executions and credential exposure.
Deleting local state files enforces central GCS state usage across team members.

Key Concept

Terraform Remote State Migration to Google Cloud Storage
Page 1 / 9Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin