Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1161Question →

An enterprise supply chain platform processes high-throughput freight tracking telemetry using a microservices application deployed on Google Kubernetes Engine (GKE), backed by Cloud SQL for PostgreSQL. The development team is preparing to release a major version update that includes non-backward-compatible database schema changes. The business requires zero downtime during release and immediate rollback capabilities if application errors increase. Which TWO implementation steps must the cloud architect mandate to safely execute this release?

Select all that apply

Show answer & explanation

Answer: Apply an expand-contract database migration pattern by introducing additive schema changes (new columns/tables) and maintaining dual-write support before initiating application deployment.; Configure GKE Native Ingress traffic splitting to incrementally route canary traffic to the new microservice revision while monitoring SLO error budgets.

Answer

The cloud architect must implement an expand-contract database migration pattern to ensure backward compatibility and configure GKE Native Ingress traffic splitting to safely run a canary release.
To achieve zero downtime when database schemas change, the expand-contract (parallel change) pattern must be applied so the database supports both application versions concurrently. Paired with GKE Ingress traffic splitting (canary deployment), traffic can be gradually routed to the new release while monitoring error budgets.

Step-by-Step Solution

1
Decouple database schema deployment from application deployment using the expand-contract strategy.
Database changes become non-breaking and additive, ensuring both older and newer versions of the GKE application microservices can run concurrently against the database.
Prevents database lockouts and application failures during traffic migration.
2
Deploy the new microservice workload alongside the existing version in GKE and leverage GKE Native Ingress to manage traffic distribution.
A small percentage of traffic (canary) is shifted to the new release to validate behavior under actual production load.
Reduces blast radius and enables instant rollback by shifting traffic weight back to 0% if SLI metric regressions are detected.

Key Concept

Release Management and Deployment Strategies (Blue-Green, Canary, Rolling)
Question 1162Question →

A digital publishing organization is preparing to deploy a serverless document indexing architecture on Google Cloud using Cloud Functions, Eventarc, and Firestore. The lead architect must establish a pre-flight testing and validation procedure to ensure automated infrastructure deployment, quota readiness, and operational stability before releasing to production. Which validation procedure represents Google Cloud best practices for testing technical solutions?

Show answer & explanation

Answer: Perform automated dry-run plan validation of Infrastructure as Code templates, verify regional project quotas for Cloud Functions and Firestore prior to provisioning, and run synthetic load tests in an isolated staging environment with least-privilege service accounts.

Answer

The correct validation procedure requires executing automated dry-run plan checks for Infrastructure as Code templates, pre-verifying regional GCP quotas for dependent services, and conducting synthetic stress tests in an isolated staging environment using least-privilege service accounts.
Comprehensive technical solution validation requires verifying prerequisites (such as regional quota headroom), performing dry-run syntax and plan checks on IaC configurations, and executing load tests in a dedicated staging environment with strict security posture.

Step-by-Step Solution

1
Pre-flight Quota & IaC Validation
Confirm resource availability and verify template syntax without altering live infrastructure.
Requesting quota increases beforehand prevents silent provisioning failures during high-throughput validation.
2
Staging Provisioning with Remote State Management
Provision identical staging resources using version-controlled, remote-backed IaC state.
Ensures environment consistency and prevents state lock or corruption issues.
3
Synthetic Load Testing & Perimeter Controls
Validate performance, reliability, and security under expected traffic conditions.
Confirms that the technical solution meets functional requirements without exposing data or exceeding platform boundaries.

Key Concept

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

A healthcare company hosts microservices across multiple Google Cloud projects under an organization resource. The operations team requires a centralized observability solution that achieves two main goals:
1. Operational metrics from all workload projects must be visible in a single dashboard without granting engineers administrative or broad resource access to workload projects.
2. Audit logs and critical error logs across all projects must be forwarded automatically to a central security project in real time for ingestion, while keeping lower-severity debug logs localized to their source project.

Which TWO architectural steps should you take to satisfy these requirements according to Google Cloud best practices?

Select all that apply

Show answer & explanation

Answer: Configure an aggregated Log Router sink at the Google Cloud Organization level with an inclusion filter for audit logs and error severities, targeting a Pub/Sub topic in the central security project.; Create a Cloud Monitoring Metrics Scope in a central scoping project and add the workload projects as monitored projects.

Answer

The correct architecture requires creating an aggregated Log Router sink at the organization level to forward selected audit and high-severity logs, and configuring a Cloud Monitoring Metrics Scope in a central project to aggregate metric monitoring across projects.
Establishing an aggregated Log Router sink at the organization level automatically routes specified security audit and high-severity log streams into a central Pub/Sub topic across all projects under the organization resource. Combining this with a Cloud Monitoring Metrics Scope allows operators to view telemetry from multiple projects within a single monitoring workspace without granting elevated IAM roles on workload projects.

Step-by-Step Solution

1
Configure centralized logging aggregation
An organization-level aggregated Log Router sink uses an inclusion filter to capture relevant security audit logs and high-severity error logs across all child projects and send them to a Pub/Sub topic or BigQuery dataset in the security project.
Aggregated sinks eliminate manual per-project configuration and guarantee compliant centralized logging.
2
Set up multi-project metric visibility
A central Monitoring scoping project is created, and all application workload projects are registered as monitored projects within its Metrics Scope.
This grants operators single-pane visibility over performance metrics across multiple projects without granting wide project-level IAM roles.

Key Concept

Multi-Project Observability with Aggregated Sinks and Cloud Monitoring Metrics Scopes
Question 1164Question →

A healthcare provider is deploying a microservice on Google Kubernetes Engine (GKE) in Google Cloud project `prod-apps`. The microservice requires read-only access to a database password stored securely in GCP Secret Manager located in a separate project, `prod-secrets`. Security governance policy strictly mandates eliminating long-lived service account JSON keys, enforcing least-privilege IAM permissions, and avoiding manual credential management inside pod environments. Which architectural approach satisfies these security and operational requirements?

Show answer & explanation

Answer: Enable GKE Workload Identity on the cluster, bind the Kubernetes Service Account to a dedicated GCP IAM Service Account in `prod-apps`, and grant the GCP IAM Service Account the Secret Manager Secret Accessor role on the specific secret in `prod-secrets`.

Answer

Enable GKE Workload Identity on the cluster, bind the Kubernetes Service Account to a dedicated GCP IAM Service Account in `prod-apps`, and grant the GCP IAM Service Account the Secret Manager Secret Accessor role on the specific secret in `prod-secrets`.
The solution leveraging GKE Workload Identity establishes keyless authentication between Kubernetes Pods and Google Cloud APIs. Granting `roles/secretmanager.secretAccessor` specifically on the target secret resource in project `prod-secrets` satisfies both cross-project access and least-privilege security requirements.

Step-by-Step Solution

1
Establish keyless identity federation
GKE Workload Identity maps the Kubernetes Service Account (KSA) to a GCP IAM Service Account (GSA) without requiring static JSON keys.
Eliminates long-lived service account key management and rotation overhead in compliance with security guidelines.
2
Configure cross-project IAM access control
Grant the GCP IAM Service Account the `roles/secretmanager.secretAccessor` role on the target secret in project `prod-secrets`.
Enforces least-privilege read access strictly limited to the required secret resource.

Key Concept

Workload Identity and Cross-Project Least-Privilege Secret Access
Question 1165Question →

An enterprise security team needs to establish automated secret rotation for database credentials stored in GCP Secret Manager according to Google Cloud recommended security practices. What is the correct sequence of steps to configure this automated rotation workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the Pub/Sub topic, granting the Secret Manager Service Agent the Pub/Sub Publisher role on that topic, deploying the rotation Cloud Function, granting its runtime service account the Secret Manager Secret Version Manager role, and finally configuring the rotation schedule on the target secret in Secret Manager.
To set up automated secret rotation in GCP Secret Manager using Cloud Functions, resources and permissions must be provisioned in dependency order. First, the Pub/Sub topic must be created to receive rotation events. Next, the Secret Manager Service Agent requires the Pub/Sub Publisher role on that topic. Then, the rotation Cloud Function is deployed, and its dedicated runtime service account is granted the Secret Manager Secret Version Manager role under least-privilege principles. Finally, the target secret in Secret Manager is updated with the rotation schedule pointing to the Pub/Sub topic.

Step-by-Step Solution

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

Key Concept

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

A software development team is building an automated CI/CD pipeline task in Cloud Build using the Python Google API Client Library to configure Cloud Logging export sinks across multiple Google Cloud projects. Security policy strictly prohibits storing long-lived service account private keys in source code or storage buckets. To comply with security policies while ensuring seamless API access, how should the team configure authentication for the Python script?

Show answer & explanation

Answer: Configure the script to rely on Application Default Credentials (ADC) using the attached Cloud Build service account, which has been granted fine-grained IAM roles on the target projects.

Answer

Configure the script to rely on Application Default Credentials (ADC) using the attached service account with fine-grained IAM roles on target projects.
The Google Cloud SDK automatically discovers identity credentials via Application Default Credentials (ADC) when running inside GCP environments such as Cloud Build. By attaching a service account to the build job and assigning fine-grained IAM roles on target projects, the Python script authenticates seamlessly without using static key files or broad primitive permissions.

Step-by-Step Solution

1
Analyze the authentication requirements for Google Cloud SDKs running inside managed GCP runtime environments.
Identified that native GCP execution environments (like Cloud Build) automatically supply credentials via Application Default Credentials (ADC).
ADC eliminates the need to create, manage, or store long-lived service account key files.
2
Determine the appropriate IAM privilege strategy for cross-project programmatic API interaction.
Grant specific predefined or custom IAM roles (such as Logging Admin) on target projects to the execution service account.
Adheres to the principle of least privilege without relying on broad primitive roles.

Key Concept

Application Default Credentials (ADC) and programmatic GCP authentication best practices.
Question 1167Question →

A global media streaming platform hosts its microservices on Google Kubernetes Engine (GKE). The platform team is designing a progressive delivery strategy using Google Cloud Deploy to automate release rollouts across production clusters. The operational objective requires deploying new service revisions using a canary release pattern, gradually advancing traffic from 10% to 100%, while continuously validating application metrics against Cloud Monitoring. If the canary revision's HTTP 5xx error rate exceeds 1% during any evaluation phase, the deployment pipeline must automatically halt progress and roll back traffic to the previous stable release without manual intervention. Which architecture and release configuration best fulfills these requirements?

Show answer & explanation

Answer: Define a Cloud Deploy delivery pipeline with progressive canary targets and integrated Cloud Deploy verify jobs that execute automated metric checks against Cloud Monitoring, automatically invoking a pipeline rollback phase if pre-configured error thresholds are breached.

Answer

The optimal solution is to define a Cloud Deploy delivery pipeline with progressive canary targets and integrated Cloud Deploy verify jobs that query Cloud Monitoring metrics, automatically triggering pipeline rollbacks upon error threshold violations.
Google Cloud Deploy provides native support for canary release strategies and progressive delivery pipelines. By configuring Cloud Deploy verification steps (using Cloud Deploy verify), the pipeline can evaluate Cloud Monitoring metrics after each phase. If metrics such as HTTP 5xx error rates exceed designated thresholds, Cloud Deploy automatically halts promotion and rolls back traffic to the previous stable release, fully satisfying operational reliability requirements without manual intervention.

Step-by-Step Solution

1
Establish Progressive Delivery Targets
Cloud Deploy configures target phases (e.g., 10%, 25%, 50%, 100%) to route traffic safely to new application revisions.
Canary deployment strategies minimize blast radius by exposing a fraction of production traffic to new code releases.
2
Integrate Verification Jobs with Operational Monitoring
Cloud Deploy verify executes automated test suites or metric assertions querying Cloud Monitoring during each rollout phase.
Automated verification ensures empirical validation of service health (such as HTTP 5xx error rates) prior to promoting the release.
3
Configure Automated Rollback Rules
Upon detecting metric threshold breaches (e.g., error rate > 1%), Cloud Deploy halts advancement and reverts traffic to the last known good revision.
Automated rollback prevents sustained user impact and fulfills strict availability SLOs.

Key Concept

Progressive Delivery and Automated Verification with Google Cloud Deploy
Question 1168Question →

An online retail platform processes customer orders in the primary region `europe-west1` and maintains a warm standby disaster recovery setup in `europe-west4`. The architecture uses Cloud SQL for PostgreSQL with cross-region asynchronous read replicas and Compute Engine Managed Instance Groups (MIGs) fronted by Cloud Load Balancing and Cloud DNS. Business operational requirements specify a Recovery Point Objective (RPO) of under 1 minute and a Recovery Time Objective (RTO) of under 15 minutes. During a total regional failure of `europe-west1`, which TWO actions must be executed as part of the regional disaster recovery failover runbook? Select 2 response options.

Select all that apply

Show answer & explanation

Answer: Promote the cross-region read replica of Cloud SQL in `europe-west4` to a standalone primary database instance.; Update Cloud DNS routing policies to direct traffic to the active Cloud Load Balancer endpoint in `europe-west4`.

Answer

Executing disaster recovery for this scenario requires promoting the cross-region Cloud SQL read replica in the failover region and updating Cloud DNS routing policies to direct client traffic to the secondary region's load balancer.
Promoting the cross-region Cloud SQL read replica in `europe-west4` converts it into an independent read-write primary database, preserving near real-time data to satisfy the sub-minute RPO. Concurrently, modifying Cloud DNS routing policies shifts global application traffic to the secondary load balancer endpoint, meeting the sub-15-minute RTO requirement.

Step-by-Step Solution

1
Promote the secondary database instance
The Cloud SQL cross-region read replica in `europe-west4` becomes a read-write primary instance, fulfilling the RPO < 1 minute requirement.
Asynchronous cross-region replication maintains near real-time data synchronization between primary and failover regions.
2
Cut over application traffic via DNS
Cloud DNS updates routing to target the Cloud Load Balancer in `europe-west4`, restoring public availability within the RTO target.
Traffic redirection to the standby compute resources completes the operational failover path.

Key Concept

Disaster Recovery Execution and Cross-Region Failover Sequence
Question 1169Question →

A software enterprise is designing a comprehensive perimeter defense architecture on Google Cloud. Match each enterprise network security requirement with the most appropriate Google Cloud perimeter security mechanism.

Click a left item, then click its matching right item

Items

Prevent authorized internal users and compromised compute resources from exfiltrating sensitive data in BigQuery datasets to unauthorized external Google Cloud projects.
Inspect incoming HTTPS traffic at the global load balancer edge to mitigate Layer 7 application attacks, block malicious IP ranges, and enforce rate limiting.
Enforce mandatory organization-wide baseline ingress firewall rules that apply across all VPC networks and cannot be overridden by project-level administrators.
Allow private on-premises workloads to securely access Google APIs (such as Cloud Storage) over Cloud Interconnect without exposing traffic to the public internet or utilizing public IP addresses.

Matches

Show answer & explanation

Answer

1 matches VPC Service Controls Service Perimeter; 2 matches Google Cloud Armor Security Policy; 3 matches Hierarchical Firewall Policy; 4 matches Private Service Connect / Private Google Access.
Each requirement directly aligns with its target GCP perimeter control: VPC Service Controls protect against data exfiltration across API boundaries; Cloud Armor protects public endpoints against Layer 7 and DDoS attacks at the edge; Hierarchical Firewall Policies enforce centralized network rules across the organization hierarchy; and Private Service Connect / Private Google Access enable secure, private routing to Google APIs over hybrid connections.

Step-by-Step Solution

1
Analyze requirement 1 (Data exfiltration prevention across project boundaries).
IAM roles control who can access resources, but do not prevent authorized users from copying data out to unapproved external projects. VPC Service Controls create a perimeter boundary around services like BigQuery to prevent data exfiltration.
VPC Service Controls restrict API communication between resources inside a perimeter and unauthorized resources outside.
2
Analyze requirement 2 (Edge WAF and Layer 7 protection).
Cloud Armor integrates directly with Cloud Load Balancing to block OWASP Top 10 vulnerabilities, enforce geo-blocking, and rate-limit HTTP(S) traffic.
Cloud Armor is the primary GCP edge security product for application-level threat mitigation.
3
Analyze requirement 3 (Organization-wide non-overridable network security baselines).
Hierarchical Firewall Policies are evaluated before VPC network-level firewall rules and can delegated or locked at the organization/folder level.
Hierarchical firewalls ensure organizational compliance across multi-tenant project structures.
4
Analyze requirement 4 (Private Google API access from on-premises over hybrid connectivity).
Private Service Connect and Private Google Access allow internal networks to access Google managed services using private endpoint IPs over Cloud Interconnect or Cloud VPN.
Private access mechanisms eliminate the need for public IP addresses when accessing GCP storage and database APIs.

Key Concept

Google Cloud Perimeter Security Architecture and Network Controls
Question 1170Question →

An enterprise organization operates multiple Google Cloud projects under a single Organization resource. The operations and security teams require a centralized logging and observability solution. They need to aggregate high-severity application errors and security audit logs into a central location for long-term compliance analysis, while simultaneously reducing log ingestion costs by filtering out non-critical debug telemetry from individual projects. Which TWO configuration steps should the Cloud Architect recommend to fulfill these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure an aggregated Log Router sink at the Organization level with a inclusion filter for audit logs and high-severity events targeted to a central BigQuery dataset.; Configure log exclusion filters on individual project default log sinks to drop debug logs with severity lower than INFO before ingestion.

Answer

The optimal solution requires configuring an aggregated Log Router sink at the Organization level targeting BigQuery for centralized audit compliance, along with log exclusion filters on project default sinks to prevent ingestion of low-severity debug telemetry.
To meet enterprise observability requirements across multiple projects, Google Cloud recommends using an aggregated Log Router sink at the Organization level to route audit and high-priority logs to a centralized BigQuery dataset. Simultaneously, configuring exclusion filters for low-severity logs (severity < INFO) on project sinks prevents ingestion of unnecessary debug telemetry, directly optimizing cost while preserving operational visibility.

Step-by-Step Solution

1
Centralize cross-project audit and high-severity logs.
Create an organization-level aggregated Log Router sink with an inclusion filter targeting BigQuery.
Aggregated sinks capture logs across all projects under the organization resource efficiently.
2
Optimize Cloud Logging ingestion costs.
Apply exclusion filters for severity < INFO on project default log sinks.
Excluding verbose debug logs before ingestion directly controls Cloud Logging costs while preserving essential operational and error logs.

Key Concept

Organization-level aggregated log sinks combined with targeted log exclusion filters satisfy central compliance storage while optimizing log ingestion costs.
Question 1171Question →

A enterprise SaaS payroll platform runs its primary application tier on Compute Engine Managed Instance Groups (MIGs) and its transactional database on Cloud SQL for PostgreSQL in the primary region `us-east1`. The business continuity requirement specifies a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 2 hours, with strict budget limits preventing a full multi-region active-active deployment. During a scheduled disaster recovery failover exercise to the secondary region `us-central1`, the database read replica was successfully promoted, but compute instance creation in `us-central1` failed due to insufficient regional vCPU quota limits. Which architectural solution should the cloud architect implement to guarantee successful disaster recovery execution while adhering to the RPO, RTO, and cost constraints?

Show answer & explanation

Answer: Pre-request and maintain sufficient regional vCPU quotas in the secondary region, and deploy a warm-standby MIG with a minimal baseline instance count that scales out when Cloud DNS failover triggers.

Answer

Pre-request and maintain sufficient regional vCPU quotas in the secondary region, and deploy a warm-standby MIG with a minimal baseline instance count that scales out when Cloud DNS failover triggers.
The correct answer addresses both the operational bottleneck (vCPU quota limits) and the business constraints (15-min RPO, 2-hr RTO, cost limits). Pre-requesting regional quotas guarantees that GCP will permit scaling in the target region during an emergency. Maintaining a minimal warm-standby Managed Instance Group keeps compute costs low during normal operation while allowing rapid auto-scaling upon Cloud DNS failover.

Step-by-Step Solution

1
Analyze DR Constraints
Identified RPO = 15 minutes, RTO = 2 hours, and strict cost boundaries preventing active-active deployment.
Determines the appropriate disaster recovery pattern (Warm Standby / Pilot Light).
2
Identify Cause of Failover Failure
Compute Engine instance creation failed in the target region due to insufficient vCPU quotas.
GCP quotas are per-region; expanding workloads rapidly in a target DR region during failover requires pre-allocated quota buffer.
3
Select Correct Remediation Architecture
Maintain a warm-standby MIG with minimal capacity and pre-approved vCPU quotas in the secondary region.
Satisfies the 2-hour RTO by permitting rapid scaling while preventing unexpected deployment failures due to quota exhaustion.

Key Concept

Disaster Recovery Execution and Regional Quota Management
Question 1172Question →

A connected vehicle technology provider operates an API service on Google Cloud Run backed by Cloud SQL for PostgreSQL. The engineering team needs to release a new version of the microservice that introduces a schema modification adding a new column required by the application. The release must guarantee zero downtime and allow seamless immediate rollback to the previous Cloud Run revision if anomalies occur during deployment. Which deployment and database migration strategy should the Cloud Architect recommend?

Show answer & explanation

Answer: Apply an expand-contract schema pattern by adding the new column as optional first, deploy the new Cloud Run revision using revision traffic splitting for canary testing, backfill the data, and update the column constraint after verifying release stability.

Answer

Apply an expand-contract schema pattern by adding the new column as optional first, deploy the new Cloud Run revision using revision traffic splitting for canary testing, backfill the data, and update the column constraint after verifying release stability.
To achieve zero downtime and maintain immediate rollback capabilities during release management, database updates must follow the expand-contract pattern. Adding new fields as optional (nullable) ensures that the currently running version of the service remains fully operational while the new revision is deployed to Cloud Run. Cloud Run natively supports splitting traffic between revisions to perform canary testing. Once the new revision is validated and receiving 100% of traffic, data backfilling and schema constraints can be finalized safely.

Step-by-Step Solution

1
Ensure database schema backward compatibility using the expand-contract pattern
Both the legacy application revision and the new application revision can query the database without errors.
During canary deployments or blue-green switches, multiple application versions run simultaneously against the shared database.
2
Deploy the new revision to Cloud Run and split traffic
Gradual canary testing (e.g., 10% traffic to new revision, 90% to old revision) is established.
Cloud Run supports native revision traffic splitting without needing additional compute infrastructure like GKE.
3
Complete data backfill and contract the schema
The new column constraint is enforced once all active traffic uses the new application version.
Completes the migration safely without disrupting live operations or preventing instant rollback during testing.

Key Concept

Database Backward Compatibility in Canary and Blue-Green Deployments (Expand-Contract Pattern)
Question 1173Question →

An automotive telemetry company ingests real-time vehicle diagnostics through an application running on Google Cloud and stores aggregated analytics inside BigQuery. The architecture team must enforce strict perimeter security to satisfy two mandatory requirements:
1. Incoming HTTP(S) traffic from public vehicles must be inspected and filtered at the network edge against Layer 7 web application attacks and SQL injection attempts.
2. Internal service accounts and authorized developers must be restricted from copying or exfiltrating sensitive BigQuery datasets to unauthorized external Cloud Storage buckets, even if they hold valid IAM read permissions.

Which TWO security controls should you implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure a Google Cloud Armor security policy containing preconfigured WAF rules and attach it to the backend service of the Global External HTTP(S) Load Balancer.; Create a VPC Service Controls service perimeter surrounding the project hosting BigQuery and configure restricted Google API access to block unauthorized data exfiltration.

Answer

Implement a Google Cloud Armor security policy attached to the Global External HTTP(S) Load Balancer backend service, and define a VPC Service Controls perimeter enclosing the BigQuery project.
Combining Google Cloud Armor at the HTTP(S) load balancer edge with a VPC Service Controls perimeter around sensitive BigQuery workloads provides defense-in-depth: Cloud Armor mitigates web application attacks and SQL injections from incoming public traffic, while VPC Service Controls establishes a isolation boundary that blocks unauthorized data transfers to external Cloud Storage buckets, even by identities with valid IAM roles.

Step-by-Step Solution

1
Address Layer 7 edge protection requirements for public HTTP(S) ingress.
Attach Cloud Armor security policies with WAF rule sets to the Global External Load Balancer backends to block SQL injection and OWASP Top 10 threats at the network edge.
Cloud Armor inspects incoming web traffic before it reaches the backend compute workload.
2
Address data exfiltration prevention requirements for internal BigQuery data access.
Enclose the project containing BigQuery within a VPC Service Controls service perimeter.
VPC Service Controls restricts communication with Google APIs to trusted network boundaries, preventing authorized identities from copying data to resources outside the perimeter.

Key Concept

Perimeter defense combining Cloud Armor for Layer 7 edge security and VPC Service Controls for data exfiltration prevention
Question 1174Question →

A healthcare enterprise is establishing a pre-flight deployment validation procedure on Google Cloud for a patient telemetry microservices application running on private Google Kubernetes Engine (GKE) clusters with sensitive datasets protected by VPC Service Controls. The validation procedure must ensure infrastructure readiness, pipeline safety, and service quality prior to directing live production traffic to new software releases. Which TWO validation practices should be included in the automated pre-deployment testing procedure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Verify regional compute and quota availability in the target GCP project using Service Usage APIs or Cloud Monitoring prior to triggering automated infrastructure deployment.; Execute automated canary deployments using Cloud Deploy with traffic shifting to validate key Service Level Indicators (SLIs) against Service Level Objectives (SLOs) before completing the rollout.

Answer

The validation procedure should include verifying regional resource quota availability prior to deployment and executing automated canary deployments with Cloud Deploy to evaluate SLIs against defined SLO thresholds before completing full production releases.
A robust pre-flight validation strategy requires checking regional quota availability prior to resource creation to prevent provisioning failures, along with executing progressive canary deployments using Cloud Deploy to measure live telemetry against SLOs before full promotion.

Step-by-Step Solution

1
Assess pre-flight quota readiness
Ensure sufficient CPU, memory, and regional API quotas exist before creating resources, avoiding mid-deployment failures.
Large automated deployments fail if project quotas are exceeded, creating inconsistent environment states.
2
Implement progressive traffic validation with canary releases
Route a small percentage of production traffic to the new software release while Cloud Deploy monitors application health metrics.
Validating SLIs against SLOs in production with small traffic percentages confirms technical performance while limiting blast radius.

Key Concept

Technical Solution Testing and Validation Procedures
Question 1175Question →

An organization runs an automated Python script on a third-party continuous integration (CI) platform outside Google Cloud. The script programmatically uploads build artifacts to Cloud Storage and writes log entries to Cloud Logging. To adhere to Google Cloud security and operational best practices for programmatic interactions from external environments, which TWO actions should the engineering team perform?

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity Federation between the external CI provider and Google Cloud to allow short-lived credential exchange.; Initialize Google Cloud Client Libraries using Application Default Credentials (ADC) to automatically detect credentials from the runtime environment.

Answer

The team should configure Workload Identity Federation for keyless authentication from the external CI environment and initialize Google Cloud Client Libraries using Application Default Credentials (ADC) to automatically load short-lived tokens.
Workload Identity Federation allows external workloads (such as third-party CI runners) to securely exchange external OIDC tokens for short-lived Google Cloud service account credentials without managing long-lived JSON keys. Initializing SDK client libraries with Application Default Credentials (ADC) enables application code to seamlessly pick up credentials from standard environment configurations.

Step-by-Step Solution

1
Establish keyless authentication from external environment
External CI runner exchanges OIDC tokens for short-lived GCP service account tokens via Workload Identity Federation.
Avoids creating and storing long-lived service account JSON keys.
2
Use Application Default Credentials in application code
SDK automatically detects credential location from environment variables without code modification.
Ensures standard programmatic interaction across different development and execution environments.

Key Concept

Keyless programmatic authentication using Workload Identity Federation and Application Default Credentials (ADC)
Question 1176Question →

An enterprise IoT platform ingests telemetry from connected vehicles and serves real-time data to fleet analytics dashboards via a Cloud Load Balancer and backend service. The Site Reliability Engineering (SRE) team defines a Service Level Objective (SLO) requiring 99.9% successful HTTP responses over a rolling 30-day window. The SRE team needs an operational alerting mechanism that detects active, severe budget consumption promptly while eliminating alert fatigue from brief transient errors or slow, non-critical budget consumption. Which alerting strategy should the Cloud Architect recommend?

Show answer & explanation

Answer: Configure a multi-window, multi-burn-rate alert policy in Cloud Monitoring that evaluates error budget consumption across both short-term and long-term lookback windows simultaneously.

Answer

Configure a multi-window, multi-burn-rate alert policy in Cloud Monitoring that evaluates error budget consumption across both short-term and long-term lookback windows simultaneously.
The correct recommendation is to implement a multi-window, multi-burn-rate alerting policy. This approach checks both short-term lookback windows (to quickly detect high-severity, rapid budget depletion) and longer lookback windows (to confirm the burn is sustained and avoid alerting on brief self-resolving spikes). This matches Google Cloud SRE standards for reliable SLO alerting without triggering alert fatigue.

Step-by-Step Solution

1
Analyze the reliability requirement and SLO parameters.
The target SLO is 99.9% availability over a 30-day rolling window, allowing a total 0.1% error budget.
Alerting logic must align directly with error budget consumption velocity rather than raw infrastructure metrics.
2
Evaluate alerting strategies against SRE best practices to prevent alert fatigue while maintaining quick response times.
Static single-window threshold alerts produce false positives on transient spikes and delay notifications during rapid outages.
Google SRE best practices recommend multi-window, multi-burn-rate alerts to balance alert speed and precision.
3
Select the optimal alerting policy mechanism in GCP Cloud Monitoring.
Combining short lookback windows (for high burn rate detection) and long lookback windows (to ensure sustained budget consumption) ensures alerts fire only when the 30-day budget is genuinely threatened.
This satisfies the requirement to notify promptly during critical events while avoiding alert fatigue.

Key Concept

Multi-window, multi-burn-rate alerting for SRE Error Budget management in Cloud Monitoring
Question 1177Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

An enterprise organization operates a web microservice on a Compute Engine Managed Instance Group (MIG) placed behind an External Application Load Balancer. The site reliability engineering team needs to implement a release management policy that supports automated progressive rollout based on real-time HTTP 5xx telemetry, allowing automatic rollback if health thresholds are breached. Furthermore, the accompanying CI/CD automation pipeline must maintain Infrastructure as Code (IaC) state securely without risk of state corruption, while observing strict least-privilege identity controls. Which deployment strategy and configuration should the cloud architect recommend?

Show answer & explanation

Answer: Configure a canary release using MIG instance template versioning with target pools and Cloud Monitoring alerts for automated rollback. Configure the CI/CD pipeline to store Terraform state in a Cloud Storage bucket backend with object versioning and state locking enabled, using granular predefined IAM roles for deployment execution.

Answer

The recommended solution is to use a canary release with MIG instance template versioning combined with Cloud Monitoring alerts for automated rollbacks, alongside a Cloud Storage backend with object versioning and state locking using granular IAM roles.
The correct strategy combines native Compute Engine MIG instance template versioning for progressive canary releases with Cloud Monitoring for automated health monitoring and rollback. Storing Terraform state in Google Cloud Storage with object versioning and state locking secures IaC state against race conditions and state loss, while granular predefined IAM roles preserve security governance.

Step-by-Step Solution

1
Define the canary deployment strategy using Compute Engine MIG instance templates
Allows incremental traffic allocation to new application versions with real-time monitoring of error metrics.
MIGs support target pools and dual-version instance templates to safely test new software releases in production.
2
Implement Cloud Storage remote backend for IaC state management
State file is stored securely with object versioning and lock management enabled.
Prevents concurrent execution conflicts and data corruption during automated CI/CD pipeline runs.
3
Enforce least-privilege security controls on deployment service accounts
Limits pipeline privileges to required infrastructure management tasks only.
Avoids security risks associated with assigning broad primitive IAM roles like Owner or Editor.

Key Concept

Release Management and Deployment Strategies
Question 1179Question →

A renewable energy utility enterprise is building a smart-grid telemetry platform on Google Cloud. The infrastructure requires a multi-layered perimeter security model to meet strict compliance guidelines. Match each perimeter security requirement on the left with the corresponding Google Cloud security control mechanism on the right that fulfills it.

Click a left item, then click its matching right item

Items

Protect public HTTPS web application endpoints against SQL injection (SQLi), cross-site scripting (XSS), and volumetric Layer 7 denial-of-service attacks.
Prevent unauthorized data exfiltration from BigQuery and Cloud Storage buckets to external Google Cloud locations, even if IAM service account keys are compromised.
Apply organization-wide SSH access rules to VM instances dynamically based on fine-grained resource metadata rather than IP subnet ranges.
Enable workloads in isolated private VPC subnets without external IP addresses to consume Google APIs securely over internal IP endpoints.

Matches

Show answer & explanation

Answer

1 matches Google Cloud Armor security policies; 2 matches VPC Service Controls service perimeter; 3 matches Hierarchical firewall policies using secure tags; 4 matches Private Service Connect (PSC) endpoints.
Each requirement maps to its specific GCP architectural component: Google Cloud Armor inspects edge HTTP(S) traffic for WAF threats; VPC Service Controls prevents perimeter exfiltration of Google API data; Hierarchical firewall policies with secure tags apply centralized policy based on instance metadata; and Private Service Connect endpoints enable internal IP connectivity to Google APIs.

Step-by-Step Solution

1
Identify protection mechanism for Layer 7 web attacks and DDoS
Google Cloud Armor is Google's edge Web Application Firewall (WAF) and anti-DDoS service.
It handles public HTTPS endpoint protection against XSS, SQLi, and rate limiting.
2
Identify perimeter control for exfiltration prevention across Google Cloud services
VPC Service Controls establishes perimeter boundaries around Google APIs and storage resources.
VPC SC prevents data exfiltration by enforcing authorization at the API perimeter level beyond identity-based IAM controls.
3
Determine organization-level management of instance firewalls via metadata
Hierarchical firewall policies combined with secure tags.
Hierarchical policies enforce top-down rules across the resource hierarchy while secure tags allow rules to target specific instances dynamically.
4
Identify private Google API routing mechanism for internal networks
Private Service Connect (PSC) endpoints for Google APIs.
PSC endpoints map Google APIs to internal IP addresses inside the user's VPC network without requiring public IPs or public internet routing.

Key Concept

Perimeter Security and Access Control Mechanisms in GCP
Question 1180Question →

An enterprise financial institution operates a critical transaction ledger service on Compute Engine Managed Instance Groups (MIGs). The application is heavily network I/O-bound and database connection-bound during peak trading hours. During recent market volatility, transaction latency spiked significantly because the MIG autoscaler failed to add instances, even though overall CPU utilization remained low at approximately 35%35\%. When the operations team attempted an emergency manual scale-out to absorb the load, instance creation failed due to exceeding the regional compute API resource limits. Which combined auto-scaling configuration and capacity planning strategy should a Cloud Architect implement to ensure system reliability during sudden market volatility events?

Show answer & explanation

Answer: Configure the MIG autoscaler using a custom Cloud Monitoring metric that tracks active database connection pool utilization, and proactively request regional quota increases alongside target capacity reservations prior to high-volatility periods.

Answer

Configure the MIG autoscaler using a custom Cloud Monitoring metric that tracks active database connection pool utilization, and proactively request regional quota increases alongside target capacity reservations prior to high-volatility periods.
For I/O-bound or connection-bound applications where CPU usage remains low during latency degradation, auto-scaling policies must evaluate custom metrics (such as active database connections or request queue depth). Additionally, auto-scaling cannot succeed if regional resource quotas are exceeded; proactive quota requests combined with Compute Engine capacity reservations ensure physical capacity and administrative limit availability during high-demand events.

Step-by-Step Solution

1
Identify the primary bottleneck for the workload
Recognize that CPU utilization (35%35\%) is not saturated, whereas database connection pool saturation represents an I/O bottleneck.
Standard CPU metrics will not trigger auto-scaling when the bottleneck is I/O or external resource pool limits.
2
Select an appropriate autoscaling signal
Implement a custom Cloud Monitoring metric representing database connection pool exhaustion or pending request queues.
Custom metrics allow autoscalers to scale out instances based on true workload indicators rather than CPU/memory defaults.
3
Address infrastructure capacity constraints
Submit regional quota increase requests and establish Compute Engine capacity reservations in advance of anticipated volatility events.
Regional quota increases prevent API provisioning failures, and reservations ensure required Compute Engine VM capacity is guaranteed in target zones.

Key Concept

Custom Metric Autoscaling and Capacity Reservation Management
PreviousPage 59 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin