Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1461Question →

A video streaming platform is preparing to launch a new automated encoding pipeline on Google Cloud. The infrastructure consists of private Google Kubernetes Engine (GKE) clusters and compute node pools managed using Terraform. To validate the technical solution prior to full production deployment, the cloud architecture team must establish a pre-deployment testing procedure that validates infrastructure automated provisioning, security boundaries, and capacity limits. Which testing and validation procedure should the Lead Cloud Architect recommend?

Show answer & explanation

Answer: Pre-request necessary regional compute quotas, store Terraform state in Cloud Storage with object versioning enabled, and restrict GKE control plane access to authorized internal IP ranges during deployment validation.

Answer

Pre-request necessary regional compute quotas, store Terraform state in Cloud Storage with object versioning enabled, and restrict GKE control plane access to authorized internal IP ranges during deployment validation.
The correct answer addresses all validation pillars for testing technical solutions on GCP: ensuring capacity quota availability prior to testing, securing IaC state management in remote versioned storage, and enforcing control plane access perimeters on private GKE clusters.

Step-by-Step Solution

1
Assess environment capacity constraints prior to executing validation testing.
Identify regional quota requirements to ensure cluster node auto-scaling and test workloads do not fail due to API quota exhaustion.
Quota increases require lead time and must be requested before performing deployment stress tests.
2
Ensure Infrastructure as Code (IaC) pipeline state integrity.
Configure Cloud Storage remote state backend with versioning and object locking.
Prevents state corruption and race conditions when multiple deployment validation scripts run in parallel.
3
Validate network access controls for compute resources.
Restrict GKE master endpoint access using control plane authorized networks.
Ensures testing environments maintain security compliance without leaving administration endpoints open to unauthorized networks.

Key Concept

Technical solution pre-deployment validation procedures covering infrastructure quota readiness, IaC state integrity, and endpoint security controls.
Question 1462Question →

A global healthcare platform processes diagnostic imaging metadata using Compute Engine Managed Instance Groups (MIGs) in primary region us-central1 and maintains a cross-region read replica of its Cloud SQL PostgreSQL database in us-east4 for disaster recovery. The organization mandates a Recovery Time Objective (RTO) of under 15 minutes and a Recovery Point Objective (RPO) of under 1 minute. During a scheduled disaster recovery drill in us-east4, promoting the database replica succeeds, but application compute instances fail to launch at scale, causing a prolonged outage. Which architectural adjustment should the Cloud Architect implement to ensure reliable execution during a regional failover?

Show answer & explanation

Answer: Pre-request sufficient Compute Engine resource quotas in us-east4 and maintain a minimal pre-provisioned warm standby MIG capacity that auto-scales upon failover.

Answer

Pre-request sufficient Compute Engine resource quotas in us-east4 and maintain a minimal pre-provisioned warm standby MIG capacity that auto-scales upon failover.
Pre-allocating regional Compute Engine quotas in the DR region (us-east4) and maintaining a minimal warm standby compute footprint guarantees that capacity is reserved and ready to accept traffic immediately. This meets both the 1-minute RPO (via continuous DB replication) and 15-minute RTO targets.

Step-by-Step Solution

1
Analyze DR requirements and identify cause of failover failure.
The failover failed because compute instances could not scale up quickly enough due to unverified quotas and cold start overhead in the target region.
Meeting an RTO under 15 minutes requires both available infrastructure capacity and sufficient service quota.
2
Evaluate compute scaling and quota provisioning options for the target DR region.
Pre-requesting regional Compute Engine quota and running a minimal warm standby MIG ensures baseline availability and guaranteed resource allocation.
Default quotas in secondary regions may not match primary workloads, causing instance creation failures during sudden failover events.

Key Concept

Disaster Recovery Execution and Regional Quota Planning
Question 1463Question →

An enterprise payment processing service hosted on Google Cloud Run processes asynchronous webhook notifications. The Site Reliability Engineering (SRE) team is defining service level indicators (SLIs), service level objectives (SLOs), and alerting strategies to balance release velocity with availability. Which TWO strategies should the team implement to ensure effective SLO management and alerting?

Select all that apply

Show answer & explanation

Answer: Define the SLI as the ratio of valid HTTP responses (non-5xx status codes) to total HTTP requests measured at the Google Cloud HTTP(S) Load Balancer.; Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to page on-call engineers when a significant percentage of the monthly error budget is consumed rapidly.

Answer

The team should define the SLI as the ratio of valid HTTP responses (non-5xx) to total requests at the load balancer level, and configure multi-window, multi-burn-rate alerts in Cloud Monitoring to track error budget consumption rates.
Defining the SLI as a ratio of successful HTTP requests to total requests measured at the load balancer provides a direct, user-focused metric. Pairing this with multi-window multi-burn-rate alerts in Cloud Monitoring allows SRE teams to detect critical error budget exhaustion events while suppressing false alarms caused by short-lived traffic anomalies.

Step-by-Step Solution

1
Identify valid Service Level Indicators (SLIs) for HTTP services.
Selected the HTTP request success ratio measured at the ingress load balancer as an accurate metric for user experience.
SLIs must quantify service performance from the user's perspective rather than tracking internal system metrics like CPU load.
2
Select an optimal alerting strategy for SLO and Error Budget management.
Selected multi-window, multi-burn-rate alerting based on error budget consumption.
Burn-rate alerting evaluates how fast the service consumes its allowed downtime budget over dynamic time windows, preventing unnecessary paging while capturing true reliability threats.

Key Concept

Defining user-centric SLIs and implementing error budget burn-rate alerts
Question 1464Question →

An enterprise retail organization is updating its deployment automation for containerized web services running on Google Cloud Run backed by a Cloud SQL for PostgreSQL database. The release pipeline is managed via Cloud Build and uses Terraform for infrastructure provisioning. The principal architect must ensure zero-downtime releases, prevent service degradation during rollbacks, enforce secure infrastructure state persistence, and adhere to least-privilege security controls. Which TWO architectural practices should the engineering team implement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Decouple database modifications from application releases by applying backward-compatible schema changes using the expand-contract pattern before shifting production traffic to new Cloud Run revisions.; Persist Terraform infrastructure state files in a versioned Cloud Storage bucket with object locking while assigning fine-grained, predefined IAM roles to the Cloud Build service account.

Answer

The engineering team must decouple database migrations from code deployments using the expand-contract pattern to maintain backward compatibility during traffic splitting, and store Terraform state in a centralized versioned Cloud Storage bucket with predefined IAM roles assigned to the CI/CD pipeline service account.
Safe, zero-downtime deployment pipelines on Google Cloud require decoupling database schema changes from application updates. The expand-contract pattern ensures that old and new revisions of a Cloud Run service can access the database simultaneously without breaking functionality during traffic splitting or rollbacks. Additionally, managing infrastructure automation with Terraform requires a secure, shared backend using a versioned Cloud Storage bucket with object locking to avoid state corruption, along with least-privilege predefined IAM roles for the deployment service account.

Step-by-Step Solution

1
Analyze database migration strategy for zero-downtime release management.
Identify that progressive traffic shifting across Cloud Run revisions requires database schema backward compatibility so both active revisions function concurrently.
Direct breaking schema migrations break active instances of the previous application version during rollout or rollback.
2
Evaluate Infrastructure as Code (IaC) state backend and security practices.
Select a remote versioned Cloud Storage bucket with object locking for Terraform state and restrict CI/CD identity permissions to predefined IAM roles.
Ephemeral state storage causes concurrency conflicts and state corruption, while primitive IAM roles expose the Google Cloud environment to unnecessary security risks.
3
Assess distractor configurations against Google Cloud operational best practices.
Reject choices recommending simultaneous breaking database migrations, local state storage with primitive IAM roles, or unverified quota limits.
These anti-patterns introduce downtime risk, state corruption, and operational quota exhaustion.

Key Concept

Zero-downtime deployment strategies require backward-compatible database schema evolution (expand-contract) and secure, centralized IaC state persistence using fine-grained IAM controls.
Question 1465Question →

An enterprise security team is hardening service account lifecycle management across a multi-project Google Cloud organization. Automated deployment pipelines hosted on an external CI/CD platform currently authenticate using exported long-lived JSON service account keys. The security policy mandates eliminating all long-lived service account keys and preventing project developers from generating new service account keys, while maintaining least-privilege deployment access. Which architectural solution fulfills these security requirements?

Show answer & explanation

Answer: Enforce the iam.disableServiceAccountKeyCreation organization policy constraint across the organization hierarchy, and configure Workload Identity Federation to allow the external CI/CD platform to exchange short-lived OIDC tokens for GCP IAM service account tokens.

Answer

Enforce the iam.disableServiceAccountKeyCreation organization policy constraint across the organization hierarchy, and configure Workload Identity Federation to allow the external CI/CD platform to exchange short-lived OIDC tokens for GCP IAM service account tokens.
Enforcing the 'iam.disableServiceAccountKeyCreation' Organization Policy constraint blocks the creation of service account keys across the GCP resource hierarchy. Paired with Workload Identity Federation, external workloads (such as third-party CI/CD systems) can securely authenticate using short-lived federated credentials directly exchanged with GCP STS, eliminating the operational risks of long-lived JSON keys.

Step-by-Step Solution

1
Analyze security constraints regarding service account key lifecycle.
Identified the requirement to eliminate long-lived exported service account JSON keys completely and block future key creation.
Exported JSON keys pose severe security risks as credentials can be leaked or mismanaged outside Google Cloud.
2
Evaluate key prevention enforcement mechanisms.
Applying the Organization Policy constraint 'iam.disableServiceAccountKeyCreation' globally prevents any identity from creating external service account keys.
Organization policies provide programmatic guardrails across resource hierarchies regardless of individual IAM permissions.
3
Determine the optimal authentication pattern for external CI/CD workloads.
Workload Identity Federation enables keyless authentication by federating external OpenID Connect (OIDC) identity providers with Google Cloud IAM service accounts.
External pipelines can obtain short-lived federated access tokens dynamically without generating or storing persistent credentials.

Key Concept

Service Account Lifecycle Security and Workload Identity Federation
Estimated Time:1m 30s
Question 1466Question →

A financial enterprise hosts sensitive customer data within a Google Cloud project containing BigQuery datasets and Cloud Storage buckets. The enterprise policy mandates that authorized internal service accounts must access Google APIs, but data must strictly be prevented from being exfiltrated to external Google Cloud projects or unauthorized public Internet destinations. Which architectural solution should you implement to satisfy these security constraints?

Show answer & explanation

Answer: Configure a VPC Service Controls service perimeter around the project, and define explicit perimeter egress and ingress rules alongside Private Service Connect endpoints for Google APIs.

Answer

Configure a VPC Service Controls service perimeter around the project, and define explicit perimeter egress and ingress rules alongside Private Service Connect endpoints for Google APIs.
VPC Service Controls creates a security perimeter around Google Cloud resources like BigQuery and Cloud Storage. By restricting network ingress and egress and using Private Service Connect endpoints, organizations prevent data exfiltration to unauthorized storage locations or external projects, even if the request originates from a valid, credentialed IAM identity.

Step-by-Step Solution

1
Analyze security and exfiltration requirements
Identified the need to prevent authorized identities from exfiltrating data outside the trusted boundary.
Standard IAM permissions grant access to read data, but cannot restrict where an authorized user or service account writes or copies that data.
2
Evaluate perimeter control mechanisms in GCP
Determined that VPC Service Controls creates a isolation perimeter around Google Cloud APIs and services (e.g., BigQuery, Cloud Storage).
VPC Service Controls prevents data copy/exfiltration across perimeter boundaries regardless of IAM privilege level.
3
Design private connectivity for perimeter access
Selected Private Service Connect endpoints combined with perimeter ingress/egress rules to enable secure, controlled API access.
Provides private IP connectivity to Google managed services without exposure to public endpoints while respecting perimeter boundaries.

Key Concept

VPC Service Controls data exfiltration prevention
Question 1467Question →

An enterprise SaaS provider hosts an event-driven data ingestion service on a Compute Engine Managed Instance Group (MIG). The service pulls messages from a Cloud Pub/Sub topic and writes structured output to a database. During peak periods, the queue length in Pub/Sub increases significantly, causing data processing latencies that breach Service Level Objectives (SLOs), even though average VM CPU utilization stays below 35% because the workload is heavily I/O-bound. Furthermore, a scheduled global marketing campaign next month is projected to increase incoming message volume by 400%. Which strategy should a Cloud Architect implement to ensure operational reliability and adequate capacity during peak workloads and the upcoming event?

Show answer & explanation

Answer: Configure target-tracking autoscaling for the MIG based on a custom Cloud Monitoring metric for Cloud Pub/Sub unacknowledged message count, and proactively request a Compute Engine regional CPU quota increase prior to the marketing campaign.

Answer

The optimal solution is to scale the Compute Engine Managed Instance Group using a custom Cloud Monitoring metric representing Cloud Pub/Sub queue depth, while requesting regional resource quota increases in advance of anticipated high-volume traffic events.
For I/O-bound queue processing microservices, CPU utilization is insufficient as a scaling trigger because instances spend significant time waiting on external calls while message backlogs accumulate. Utilizing Cloud Monitoring custom metrics based on Pub/Sub unacknowledged message depth allows the Managed Instance Group to scale precisely based on outstanding work. Additionally, preparing for major planned traffic increases requires auditing project quotas and requesting regional Compute Engine quota increases in advance, as GCP hard quotas do not scale automatically without explicit requests.

Step-by-Step Solution

1
Identify the scaling metric mismatch for I/O-bound workloads
Recognize that CPU utilization is an inadequate metric for queue-based microservices where worker nodes spend time waiting on I/O operations.
When processing Pub/Sub queues, workers may experience latency while CPU remains idle, making queue backlog metrics (unacknowledged messages or message age) the appropriate scaling signal.
2
Establish custom metric autoscaling on Compute Engine MIG
Export Pub/Sub metric `pubsub.googleapis.com/subscription/num_undelivered_messages` to Cloud Monitoring and set it as the target-tracking metric for MIG autoscaling.
Target-tracking on queue length allows the autoscaler to dynamically maintain a consistent number of messages per instance, automatically expanding capacity during queue spikes.
3
Perform capacity planning for anticipated traffic spikes
Evaluate current regional Compute Engine quota limits against projected 400% load increases and submit quota requests prior to the event.
Resource quotas are enforced at the GCP project/region level and cannot automatically burst beyond limits without prior quota approval from Google Cloud.

Key Concept

Auto-scaling metric selection for I/O-bound queue workers and proactive capacity quota management
Estimated Time:2m 0s
Question 1468Question →

An enterprise financial platform runs its core transaction processing application on Compute Engine Managed Instance Groups (MIGs) with a Cloud SQL for PostgreSQL database in `us-east1`. The organization implements a Warm Standby disaster recovery strategy in `us-west1` to achieve a Recovery Point Objective (RPO) of under 1 minute and a Recovery Time Objective (RTO) of under 15 minutes. During a regional outage drill, the DR execution failover fails because the standby compute tier cannot scale up to match production traffic, and the secondary database tier cannot process incoming write transactions. Which TWO operational steps must be incorporated into the disaster recovery execution runbook to resolve these failures? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Promote the cross-region Cloud SQL read replica in `us-west1` to a standalone primary database instance.; Pre-request and maintain sufficient Compute Engine regional resource quotas in `us-west1` prior to failover execution.

Answer

The disaster recovery execution runbook must include promoting the cross-region Cloud SQL read replica in the target region to a standalone writable primary instance and pre-requesting sufficient Compute Engine regional resource quotas in advance.
Promoting the Cloud SQL read replica in the failover region converts it to a primary database capable of serving read/write traffic, fulfilling low RPO requirements. Pre-requesting compute quotas in the target region ensures that Managed Instance Groups can scale up immediately without hitting API quota bottlenecks, fulfilling the RTO requirement.

Step-by-Step Solution

1
Analyze database failover requirements for RPO < 1 minute
Identified that cross-region asynchronous replication via Cloud SQL read replicas satisfies RPO < 1 minute, but requires explicit replica promotion to become writable upon primary region failure.
Cloud SQL read replicas operate in read-only mode until promoted to standalone instances during a regional disaster recovery event.
2
Analyze compute auto-scaling requirements for RTO < 15 minutes
Identified that scaling up Managed Instance Groups in a secondary region during an emergency failover requires pre-allocated regional resource quotas.
Requesting quota increases during an active disaster introduces delay and uncertainty, which breaches the strict RTO boundary.

Key Concept

Warm Standby Disaster Recovery Execution for Compute and Database Tiers
Question 1469Question →

An engineering team runs a batch data processing service on Google Compute Engine that programmatically uploads thousands of generated reports to Google Cloud Storage using the official Google Cloud Client Library for Python. During high-concurrency batch operations, the application frequently fails due to rate limiting errors (HTTP status code 429 Too Many Requests). Which approach should the developers take to handle these API rate limit errors reliably while following Google Cloud best practices?

Show answer & explanation

Answer: Configure truncated exponential backoff with randomized jitter when retrying failed API requests.

Answer

Configure truncated exponential backoff with randomized jitter when retrying failed API requests.
When programmatically interacting with GCP APIs using SDKs or client libraries, encountering HTTP 429 rate limits requires handling transient errors gracefully. Truncated exponential backoff with randomized jitter increases the delay between successive retry attempts while adding randomness to prevent synchronized retry requests across parallel batch instances.

Step-by-Step Solution

1
Identify the root cause of the programmatic interaction failure.
The HTTP 429 status code indicates transient rate limiting and quota throttling when calling Google Cloud APIs.
High-concurrency batch processing can briefly overwhelm default API rate limits.
2
Evaluate standard cloud API error-handling strategies.
Truncated exponential backoff with jitter systematically increases wait times between consecutive retries and introduces randomized variance.
This prevents retry synchronization (thundering herd problem) and allows the backend service time to recover.

Key Concept

Programmatic interaction retry strategies and API rate limit management
Question 1470Question →

An enterprise ride-hailing platform ingests real-time driver location updates via an HTTP API hosted on a Google Cloud Compute Engine Managed Instance Group (MIG). During daily rush hours, incoming traffic rapidly increases tenfold, causing severe request latency and dropped connections. Monitoring reveals that VM instance CPU utilization remains around 25%, well below the 70% CPU autoscaling target, because worker threads are blocked waiting for database connection pools. Furthermore, the platform team anticipates an additional fivefold growth in peak load for an upcoming national event. Which workload optimization and capacity planning strategy should you implement to resolve the latency issues and guarantee infrastructure availability?

Show answer & explanation

Answer: Reconfigure the MIG autoscaling policy to scale based on Cloud Monitoring custom metrics such as active HTTP requests or connection queue depth, and submit a regional vCPU quota increase request well in advance of the national event.

Answer

Reconfigure the MIG autoscaling policy to scale based on custom metrics (such as active HTTP requests or queue depth) rather than CPU utilization, and request a regional vCPU quota increase prior to the peak event.
The correct choice addresses both workload scaling efficiency and capacity planning constraints. For I/O-bound HTTP services, scaling on custom metrics like queue depth or active connection count ensures the MIG expands capacity before latency degrades. Simultaneously, submitting quota requests before anticipated high-demand events prevents automated scaling from hitting regional resource caps.

Step-by-Step Solution

1
Analyze the scaling metric bottleneck.
Identified that CPU utilization is an ineffective scaling metric for I/O-bound workloads where threads wait on database connection pools.
When workloads are constrained by I/O or connection thread pools, CPU usage remains low despite severe request queueing.
2
Select appropriate autoscaling metric for I/O-bound API workloads.
Configured Cloud Monitoring custom metrics reflecting HTTP request rate or queue depth.
Queue depth and active connection counts accurately signal workload pressure for I/O-bound applications, triggering timely instance scaling.
3
Perform proactive capacity planning for anticipated traffic spikes.
Evaluated regional resource quota limits and requested vCPU quota increases prior to the national event.
Autoscaling mechanisms are bounded by GCP regional quotas. If quota increases are not approved prior to high-demand events, instance creation will fail.

Key Concept

Workload-driven autoscaling metric selection and proactive regional quota management for high-burst events.
Estimated Time:1m 30s
Question 1471Question →

An enterprise architecture team is integrating an on-premises application with Google Cloud services. The application requires access to database credentials stored in Secret Manager. To comply with corporate security governance, the solution must strictly eliminate the risk of long-lived service account key leaks, avoid primitive roles, and follow Google Cloud recommended least privilege standards. Which architecture meets these security requirements?

Show answer & explanation

Answer: Configure Workload Identity Federation with the on-premises OpenID Connect (OIDC) identity provider, grant the targeted service account the Secret Manager Secret Accessor role, and allow external workloads to exchange security tokens for short-lived credentials.

Answer

Configure Workload Identity Federation with the on-premises identity provider and grant the service account the Secret Manager Secret Accessor role for short-lived credential access.
The correct approach uses Workload Identity Federation to establish trust between the on-premises OIDC/SAML identity provider and Google Cloud Cloud IAM. This allows the application to exchange external credentials for short-lived Google Cloud access tokens, removing the need to manage or store persistent service account JSON keys while enforcing least privilege through the Secret Manager Secret Accessor role.

Step-by-Step Solution

1
Identify key requirements
The requirement demands accessing Secret Manager from on-premises without exporting long-lived service account keys.
Eliminating service account key management reduces security exposure from key leaks.
2
Select identity strategy
Federate external identities using Workload Identity Federation (OIDC/SAML).
Workload Identity Federation enables workloads running outside Google Cloud to impersonate service accounts using short-lived access tokens.
3
Apply least-privilege IAM roles
Assign `roles/secretmanager.secretAccessor` to the target service account.
This predefined role grants read access to secret payloads without administrative permissions or overly broad primitive access.

Key Concept

Workload Identity Federation and Least Privilege Secret Access
Question 1472Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological validation sequence begins with verifying regional resource quotas and IaC staging configuration, followed by synthetic load testing to establish baseline SLIs, streaming mirrored production traffic for data correctness validation, executing fault-injection tests for resiliency compliance, and concluding with a canary rollout monitored via error budgets.
A structured cloud solution validation procedure progresses from static environment and quota verification to isolated synthetic load testing, live shadow traffic comparison, resiliency testing under simulated failure conditions, and finally controlled canary release monitoring.

Step-by-Step Solution

1
Pre-flight Environment & Quota Validation
Staging environment is verified to have adequate CPU, IP address, and API quotas for testing without running into resource constraints.
Running performance tests without pre-verifying quotas leads to artificial failures caused by GCP service limits rather than architectural flaws.
2
Synthetic Baseline & Load Testing
Pipeline throughput, backpressure metrics, and worker autoscaling behavior are established under controlled stress conditions.
Synthetic data isolating performance parameters ensures the system handles target peak throughput before introducing live payloads.
3
Shadow Traffic & Data Quality Validation
Real-world payload variations and schema edge cases are processed and validated against legacy reference outputs without impacting live data.
Shadow testing isolates production data edge-cases while guaranteeing zero operational impact on live operations.
4
Fault-Injection & Chaos Testing
Automated recovery, subscriber checkpointing, and high-availability guarantees are confirmed under failure scenarios.
Resiliency procedures must be verified against actual outages before trusting the system with production workloads.
5
Canary Production Rollout
Production traffic is progressively shifted while observing SLI metrics and error budget burn rates.
Canary releases provide a controlled final verification step with limited blast radius.

Key Concept

Developing Procedures to Test and Validate Technical Solutions
Question 1473Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with applying backward-compatible database schema changes (expand phase), followed by deploying the canary workloads to GKE, routing a small percentage of live traffic for SLI validation, shifting 100% of production traffic to the new revision and decommissioning legacy pods, and finally removing legacy database columns (contract phase).
The expand-contract pattern dictates that database changes must be introduced non-destructively prior to code releases (expand phase). Application workloads are then deployed and progressively tested using traffic splitting (canary deployment) controlled by service mesh or load balancers. Once 100% of traffic is promoted to the new code and old pods are removed, destructive database cleanups (contract phase) can safely execute.

Step-by-Step Solution

1
Execute the expand phase of the database migration in Cloud Spanner.
New columns or tables exist alongside legacy structures without breaking currently running application versions.
Decoupling database deployment from application code deployment ensures zero downtime and prevents schema mismatch errors during canary testing.
2
Provision the new version of the GKE application workload without shifting traffic.
Canary pods are running, healthy, and ready to accept traffic.
Workloads must pass health and readiness checks before receiving live user traffic.
3
Initiate progressive traffic splitting via Anthos Service Mesh to route 5% of user traffic to the canary workload.
Real user requests hit the canary revision while automated monitoring evaluates SLIs against SLO targets.
Canary analysis isolates risk to a small fraction of users and enables rapid automated rollback if error budgets are threatened.
4
Promote the new application version to 100% traffic and decommission legacy workloads.
All incoming production traffic lands on the new application revision.
Full migration guarantees that no active workloads rely on the old application version.
5
Execute the contract phase database migration in Cloud Spanner.
Deprecated database fields and old columns are removed safely.
Removing schema components before all active instances are updated causes runtime queries to fail.

Key Concept

Expand-Contract Database Migrations and Progressive Delivery Alignment
Question 1474Question →

An enterprise healthcare provider operates an electronic health records (EHR) API Gateway on Google Cloud with a defined Service Level Objective (SLO) of 99.9%99.9\% availability over a rolling 3030-day window (43,20043,200 minutes). Over the current 3030-day window, the service experienced two incidents while maintaining constant request volume: a database outage resulted in a complete service failure (100%100\% error rate) lasting 1515 minutes, and a downstream service throttling issue resulted in a partial degradation (40%40\% error rate) lasting 4545 minutes. What is the remaining allowable error budget in minutes for this 3030-day window?

Show answer & explanation

Answer: 10.2

Answer

The remaining allowable error budget for the 30-day window is 10.2 minutes.
The total allowable error budget for a 99.9% SLO over 30 days (43,200 minutes) is 0.001×43,200=43.20.001 \times 43,200 = 43.2 minutes. Incident 1 (100% failure for 15 minutes) consumes 15.0 minutes. Incident 2 (40% failure for 45 minutes under uniform traffic) consumes 45×0.40=18.045 \times 0.40 = 18.0 minutes. Total consumed budget is 15.0+18.0=33.015.0 + 18.0 = 33.0 minutes. Subtracting the consumed budget from the total allowable budget leaves 43.2−33.0=10.243.2 - 33.0 = 10.2 minutes.

Step-by-Step Solution

1
Calculate the total allowable error budget for a 99.9% availability SLO over 30 days (43,200 minutes).
Total Error Budget = 43,200×(1−0.999)=43.243,200 \times (1 - 0.999) = 43.2 minutes.
An SLO of 99.9% permits a maximum error rate of 0.1% across the entire rolling window.
2
Compute the effective downtime minutes consumed during the total outage incident.
Incident 1 Budget Consumed = 15 minutes×100%=15.015 \text{ minutes} \times 100\% = 15.0 minutes.
A 100% error rate for 15 minutes consumes 15 full minutes of error budget.
3
Compute the effective downtime minutes consumed during the degraded state incident.
Incident 2 Budget Consumed = 45 minutes×40%=18.045 \text{ minutes} \times 40\% = 18.0 minutes.
Under uniform traffic, a partial outage with a 40% error rate for 45 minutes consumes equivalent error budget proportional to the failure fraction (45×0.4045 \times 0.40).
4
Sum the error budget consumed across both operational incidents.
Total Consumed = 15.0+18.0=33.015.0 + 18.0 = 33.0 minutes.
Combining the impact of full and partial outages gives the total budget spent.
5
Subtract total consumed budget from total allowable budget.
Remaining Error Budget = 43.2−33.0=10.243.2 - 33.0 = 10.2 minutes.
This yields the remaining margin of unreliability permitted before breaching the SLO target.

Key Concept

SLO Error Budget Calculation for Partial and Total Outages
Question 1475Question →

An enterprise retail organization is establishing an automated validation procedure on Google Cloud to ensure their microservices architecture can handle anticipated traffic spikes during an upcoming flash sale event. The lead cloud architect must design a pre-flight validation process within the deployment pipeline to verify resource readiness before expanding infrastructure across multiple target regions. Which approach best satisfies both technical solution testing and business continuity requirements?

Show answer & explanation

Answer: Implement automated pre-flight validation steps in the CI/CD pipeline to check regional API and compute resource quotas using the Cloud Quotas API prior to executing infrastructure deployment, requesting quota increases in advance where necessary.

Answer

Implement automated pre-flight validation steps in the CI/CD pipeline to check regional API and compute resource quotas using the Cloud Quotas API prior to executing infrastructure deployment, requesting quota increases in advance where necessary.
The correct strategy incorporates automated quota checks using the Cloud Quotas API as part of pre-flight testing prior to executing large-scale infrastructure changes. This ensures that regional resource limits are evaluated early in the deployment pipeline, allowing teams to request necessary quota increases before business-critical scaling events occur.

Step-by-Step Solution

1
Analyze deployment validation prerequisites for large-scale infrastructure expansion.
Identified that resource quotas must be verified before attempting large-scale resource allocation.
Google Cloud enforces per-region and per-project quotas that can halt automated deployment pipelines if exceeded.
2
Integrate quota checking into pre-flight CI/CD deployment procedures.
Automated pipeline queries the Cloud Quotas API to compare target capacity against current quota limits.
Proactive quota validation prevents deployment failure mid-rollout and provides actionable advance notice for quota request increases.

Key Concept

Pre-flight Quota and Environment Validation in GCP Solution Testing
Question 1476Question →

A global logistics company runs its real-time package routing platform in Google Cloud. The core backend relies on a Compute Engine Managed Instance Group (MIG) and a Cloud SQL for PostgreSQL database located in primary region `us-central1`. To achieve a Recovery Point Objective (RPO) under 1 minute and a Recovery Time Objective (RTO) under 15 minutes, the team designed a Warm Standby disaster recovery (DR) pattern in secondary region `us-east4` using cross-region Cloud SQL read replicas. During an unannounced DR failover simulation, database promotion succeeded within 2 minutes, but spinning up additional backend instances in `us-east4` failed due to regional Compute Engine resource quota limits, causing an RTO breach. Which architectural adjustment should the Cloud Architect implement to ensure reliable DR execution while maintaining the Warm Standby strategy?

Show answer & explanation

Answer: Proactively request and maintain sufficient Compute Engine regional quotas in `us-east4` while running a minimal baseline instance footprint in the secondary Managed Instance Group that automatically scales out upon failover.

Answer

Proactively request and maintain sufficient Compute Engine regional quotas in `us-east4` while running a minimal baseline instance footprint in the secondary Managed Instance Group that automatically scales out upon failover.
The correct strategy for Warm Standby disaster recovery requires proactive capacity planning. Pre-requesting regional Compute Engine quotas ensures GCP will permit the required number of instances to launch. Maintaining a minimal baseline instance footprint in the secondary region ensures application config validation and fast auto-scaling within the 15-minute RTO target.

Step-by-Step Solution

1
Analyze DR requirements and execution bottleneck
The scenario specifies a Warm Standby pattern requiring RPO < 1 min and RTO < 15 min. The failure point was insufficient compute resource quota in the secondary region during failover scaling.
Warm Standby requires secondary compute infrastructure to be ready to scale out rapidly without hitting API or capacity constraints.
2
Evaluate regional quota management for DR execution
GCP resource quotas are region-specific and must be explicitly requested ahead of time. Quota approvals cannot be performed instantaneously during emergency failover.
Ensuring quota availability prior to a disaster guarantees that autoscaling policies can provision required compute nodes.
3
Align compute footprint with Warm Standby pattern
Pre-provisioning a minimal baseline MIG in the DR region ensures deployment templates and network connectivity are verified continuously, allowing seamless scale-out when failover occurs.
A minimal active footprint in the secondary region satisfies RTO bounds while optimizing baseline operational costs.

Key Concept

Disaster Recovery Execution & Quota Management
Question 1477Question →

An enterprise fleet management company processes batch vehicle telemetry and sensor logs uploaded by 50,000 connected delivery vans at the end of each shift. The processing architecture uses Compute Engine Managed Instance Groups (MIGs) consuming messages from a Cloud Pub/Sub topic. During peak shift handovers, message processing backlogs increase rapidly, but worker VMs fail to scale out quickly enough because autoscaling is triggered only by CPU load. Furthermore, sudden cluster scaling periodically fails due to reaching regional vCPU quota limits in us-central1. Which TWO actions should the Cloud Architect take to resolve the processing backlog and ensure reliable infrastructure scaling capacity? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the MIG autoscaler to use a custom metric tracking the number of unacknowledged Pub/Sub messages per worker instance.; Perform proactive capacity planning by auditing workload growth and submitting regional vCPU quota increase requests prior to high-volume events.

Answer

The Cloud Architect should configure the MIG autoscaler to scale based on Pub/Sub queue depth custom metrics per worker instance and proactively submit regional vCPU quota increase requests in advance of peak load periods.
For message-driven consumer workloads on Google Cloud Compute Engine, autoscaling should be tied to custom metrics such as Pub/Sub unacknowledged message depth per instance rather than CPU utilization. Additionally, to avoid VM creation failures during rapid autoscaling events, cloud architects must perform capacity planning and request regional vCPU quota increases in advance.

Step-by-Step Solution

1
Analyze workload characteristics and metric bottlenecks.
Identified that CPU utilization is an inadequate autoscaling metric for queue-based batch consumer workloads.
Queue workers may be network or I/O bound while waiting for message batches, causing CPU-based autoscalers to lag behind growing message backlogs.
2
Select the appropriate scaling signal.
Configured Pub/Sub unacknowledged message count per instance as the custom metric for the MIG autoscaler.
Tracking queue depth directly aligns worker VM provisioning with actual backlog size.
3
Address compute capacity limits.
Forecast peak compute requirements and request regional vCPU quota increases prior to deployment bursts.
Proactive quota management prevents instance provisioning failures when autoscaling triggers rapid compute expansion.

Key Concept

Workload autoscaling using custom queue metrics and proactive regional capacity quota planning.
Question 1478Question →

A logistics enterprise operates a real-time shipment tracking service running on Compute Engine Regional Managed Instance Groups (MIGs) fronted by an External HTTP(S) Load Balancer. The application persists state in a Cloud SQL for PostgreSQL database. The development team is preparing to deploy a major release that contains breaking database schema alterations. The deployment policy requires zero downtime and a rapid, zero-downtime rollback capability if errors occur after traffic migration. Which deployment and database migration strategy should the cloud architect recommend?

Show answer & explanation

Answer: Implement an expand-contract database schema pattern to support both legacy and new application versions concurrently, provision the new application code in a Green MIG, validate the deployment, and update the load balancer backend service to switch traffic from Blue to Green.

Answer

The cloud architect should implement an expand-contract database schema migration pattern so the database concurrently supports both old and new application versions. The team can then deploy the release to a Green MIG, validate it, and route load balancer traffic to the Green MIG with minimal risk.
Executing a successful Blue-Green deployment for applications backed by relational databases requires an expand-contract (additive) schema evolution. By making database changes additive first, both the active Blue MIG and the newly created Green MIG can run concurrently against Cloud SQL. Once the Green MIG is validated, the External HTTP(S) Load Balancer seamlessly updates its backend service target to complete the release with zero downtime.

Step-by-Step Solution

1
Decouple database schema changes using the expand-contract pattern.
Database additions (columns/tables) are backward-compatible with the active Blue application version.
Prevents breaking active user requests running on the legacy Blue deployment while preparing for the Green deployment.
2
Provision and validate the Green MIG.
The new version runs isolated alongside Blue and communicates cleanly with the expanded schema.
Allows verification of application health prior to exposing production traffic.
3
Update Load Balancer backend traffic routing from Blue MIG to Green MIG.
Traffic shifts cleanly to Green; if issues arise, traffic can immediately shift back to Blue without database corruption.
Achieves zero downtime and immediate rollback capability for Blue-Green deployments.

Key Concept

Blue-Green Deployment with Backward-Compatible (Expand-Contract) Database Schema
Estimated Time:2m 0s
Question 1479Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order establishes authentication first, grants token creation permissions second, configures local Application Default Credentials with impersonation flags third, and executes application code using standard SDK auto-discovery fourth.
Configuring secure SDK programmatic interaction requires authenticating the user identity first, ensuring the identity has the Service Account Token Creator role on the target service account second, configuring local ADC with the --impersonate-service-account flag third, and finally executing the application code using native client library auto-discovery fourth.

Step-by-Step Solution

1
Authenticate user identity
User credentials established in gcloud CLI context
Impersonation requires an authenticated primary identity capable of making initial GCP IAM calls.
2
Grant IAM permissions on the target service account
User authorized with Service Account Token Creator role on the target service account
Without roles/iam.serviceAccountTokenCreator on the target resource, ADC impersonation requests will fail with permission denied errors.
3
Generate impersonation-configured ADC credentials
ADC file created locally referencing the target service account for impersonation
Running gcloud auth application-default login with the --impersonate-service-account flag configures local SDKs to delegate calls through short-lived service account tokens.
4
Run SDK application code
SDK requests succeed authenticated as the target service account without service account keys
Standard client library initialization relies on ADC resolution without requiring explicit credential files or code changes.

Key Concept

Service Account Impersonation via Application Default Credentials (ADC)
Question 1480Question →

A biomedical research institute manages sensitive genomic datasets stored across Google Cloud Storage buckets and BigQuery datasets. Although strict Identity and Access Management (IAM) controls are enforced, security audits reveal a risk that authorized internal researchers could accidentally or maliciously copy sensitive data into external Cloud Storage buckets residing outside the organization's control. Which architectural control should the cloud architect implement to prevent data exfiltration to external resources?

Show answer & explanation

Answer: Configure a VPC Service Controls perimeter encompassing the BigQuery and Cloud Storage resources to restrict service data access to specified boundary boundaries.

Answer

The correct strategy is to establish a VPC Service Controls perimeter around the BigQuery and Cloud Storage resources.
The option advocating VPC Service Controls is correct because VPC Service Controls allow organizations to establish defense-in-depth perimeters around Google Cloud managed services (such as Cloud Storage and BigQuery). This prevents data exfiltration by blocking API calls that attempt to move data to external projects or non-approved environments, even when the user or service account has legitimate IAM read permissions.

Step-by-Step Solution

1
Analyze the security requirement
Identified the risk of data exfiltration by authorized identities with valid IAM read privileges.
IAM permissions control access authentication and authorization, but do not constrain where authorized data can be transferred.
2
Evaluate perimeter control mechanisms
VPC Service Controls create a boundary preventing API access and data copying outside the boundary.
VPC Service Controls restrict Google Cloud service APIs (e.g., Cloud Storage and BigQuery) so data cannot leave the defined service perimeter.

Key Concept

VPC Service Controls for Data Exfiltration Prevention
PreviousPage 74 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin