All practice questions

1598 questions

All types1,598 Multiple choice815 Multiple select537 Numeric8 Matching64 Ordering174

A digital banking enterprise hosts its transaction processing platform on Google Cloud. The application architecture exposes two key endpoints: an `ExecuteInstantPayment` API where request latency over $2000\text{ ms}$ incurs financial compliance penalties and customer loss, and a `GenerateMonthlyStatement` API where batch report generation can be delayed by several hours without business revenue impact. The engineering team needs to establish a Site Reliability Engineering (SRE) framework that aligns technical operational metrics with actual business risk. Which TWO implementation strategies should the team execute? (Select TWO.)

Select all that apply

Establish a strict latency SLI for `ExecuteInstantPayment` measuring the proportion of successful requests completed under

2000\text{ ms}

, paired with an SLO that triggers deployment freezes when error budget burns excessively.

Define the target percentage of

99.9\%

availability as the SLI metric while using the rolling 30-day aggregated metric measurement as the SLO metric.

Set a relaxed availability and latency SLO for `GenerateMonthlyStatement` relative to `ExecuteInstantPayment`, allowing the batch system to consume error budget during peak load without incurring unnecessary over-provisioning costs.

Enforce a unified

99.99\%

availability SLO across both endpoints to ensure consistent enterprise infrastructure standards across all microservices.

Show answer & explanation

Answer: Establish a strict latency SLI for `ExecuteInstantPayment` measuring the proportion of successful requests completed under $2000\text{ ms}$ , paired with an SLO that triggers deployment freezes when error budget burns excessively.; Set a relaxed availability and latency SLO for `GenerateMonthlyStatement` relative to `ExecuteInstantPayment`, allowing the batch system to consume error budget during peak load without incurring unnecessary over-provisioning costs.

Answer

The correct strategies are to establish a latency SLI for instant payments tied to the

2000\text{ ms}

penalty threshold with error-budget deployment freezes, and to set a lower, more relaxed SLO for monthly statement generation to avoid over-engineering non-critical workloads.

Aligning technical service level objectives with business impact requires setting precise SLIs that capture real business degradation (such as the

2000\text{ ms}

penalty threshold for instant payments) and establishing differentiated SLOs so non-critical batch processes do not consume unnecessary operational costs or trigger false-alarm engineering overhead.

Step-by-Step Solution

Analyze business impact across endpoints

Identified that `ExecuteInstantPayment` has severe financial penalties beyond

2000\text{ ms}

, while `GenerateMonthlyStatement` tolerates significant latency.

SLOs and SLIs must directly reflect business risk and user experience rather than uniform arbitrary technical targets.

Define valid SLIs and SLOs for high-impact endpoint

Created a latency SLI measuring request duration

\leq 2000\text{ ms}

and tied SLO error budget burn rate to feature release policies.

SLIs measure actual operational compliance against defined metrics, while SLOs enforce governance when error budgets deplete.

Differentiate service targets for low-impact workload

Applied a looser SLO to statement generation, preserving budget and infrastructure cost.

Over-engineering availability for non-critical services increases cloud operational expenditure without adding business value.

Key Concept

Aligning Technical SLOs/SLIs with Business Objectives

Question 822Question →

A SaaS logistics organization operates an automated dispatch platform on Google Cloud. High-priority route-settlement API requests generate direct transaction revenue and carry strict contractual SLA financial penalties for downtime. Conversely, secondary background reporting queries carry no financial penalties and minimal operational impact. Currently, the reliability engineering team monitors system health using a single, aggregated Service Level Indicator (SLI) that measures the ratio of successful requests across all combined HTTP endpoints against a unified 99.9% Service Level Objective (SLO). During a recent release, a bug in background reporting endpoints produced a surge of HTTP 5xx errors that consumed 85% of the total monthly error budget. This triggered an automatic freeze on all feature deployments, despite the revenue-generating route-settlement APIs remaining at 100% availability. How should the Cloud Architect adjust the monitoring and reliability design to align technical service level objectives with business impact?

Deconstruct the aggregated monitoring design by establishing distinct SLIs for route-settlement APIs versus background reporting endpoints, and assign independent SLOs and separate error budgets aligned with the business criticality of each service tier.

Define the target 99.9% availability threshold directly as the active SLI metric in Cloud Monitoring, and set up static threshold alerts to notify on-call engineers whenever total 5xx request rates exceed 0.1% within any 5-minute rolling window.

Increase the overall unified SLO target from 99.9% to 99.99% across all combined service endpoints to expand the absolute error budget buffer and absorb error spikes from secondary reporting queries.

Deploy a dedicated cold-standby multi-region disaster recovery deployment for background reporting endpoints to eliminate secondary reporting failures from consuming primary operational error budgets.

Show answer & explanation

Answer: Deconstruct the aggregated monitoring design by establishing distinct SLIs for route-settlement APIs versus background reporting endpoints, and assign independent SLOs and separate error budgets aligned with the business criticality of each service tier.

Answer

The Cloud Architect should deconstruct the aggregated monitoring design by establishing distinct Service Level Indicators (SLIs) for route-settlement APIs versus background reporting endpoints, assigning independent Service Level Objectives (SLOs) and separate error budgets aligned with the business criticality of each service tier.

To align technical service level objectives with business objectives, services must be categorized by business criticality. Revenue-generating transaction endpoints with SLA penalty risks require high-availability SLOs and dedicated error budgets. Low-impact reporting endpoints should have relaxed SLOs and separate error budgets. Decoupling these indicators ensures that failures in non-critical components do not consume the error budget of critical services or trigger unnecessary release freezes.

Step-by-Step Solution

Analyze business impact across application endpoints

Identified route-settlement APIs as revenue-critical with financial SLA penalties, while background reporting carries low business impact.

Business objectives and financial risks differ significantly across endpoint types, requiring tiered operational targets.

Evaluate current SLI/SLO alignment

Discovered that a single aggregated SLI pools critical and non-critical traffic, causing non-critical reporting failures to unfairly burn the shared error budget and block deployment velocity.

Aggregating disparate endpoints into one SLI obscures service health and misaligns engineering toil with actual business risk.

Decouple telemetry metrics and error budget policies

Defined dedicated SLIs/SLOs for critical transaction paths (e.g., 99.9% SLO) and looser goals for non-critical reporting (e.g., 99.0% SLO), each with independent error budgets.

Tiered SLOs isolate error budgets so that non-critical outages do not stall feature delivery for revenue-generating services.

Key Concept

SLA/SLO/SLI Business Alignment & Error Budget Governance

Estimated Time:3m 0s

Question 823Question →

A global logistics organization is establishing an automated Infrastructure as Code (IaC) deployment pipeline to provision a transactional relational database handling order processing across North America and Europe. The workload requires multi-continent scale with strict ACID transaction guarantees. Security governance mandates that encryption keys must be managed through a centralized cloud key management service rather than requiring client applications to transmit raw key material during API operations. Additionally, the engineering team requires that the IaC state configuration prevents concurrent modification conflicts and supports state recovery. Which combination of database service, key management model, and IaC state storage best satisfies these requirements?

Provision Cloud Spanner configured with Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS, and configure the Terraform remote backend using a Cloud Storage bucket with object versioning and state locking enabled.

Provision Cloud SQL for PostgreSQL configured with Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS, and store the Terraform state file in a Cloud Storage bucket with object versioning enabled.

Provision Cloud Spanner configured with Customer-Supplied Encryption Keys (CSEK) provided in each API header, and maintain the Terraform state file locally within a shared version-controlled Git repository.

Provision Cloud Spanner configured with Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS, and store the Terraform state in an unversioned Cloud Storage bucket without state locking.

Show answer & explanation

Answer: Provision Cloud Spanner configured with Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS, and configure the Terraform remote backend using a Cloud Storage bucket with object versioning and state locking enabled.

Answer

Provision Cloud Spanner using Customer-Managed Encryption Keys (CMEK) in Cloud KMS, combined with a Cloud Storage Terraform backend that enables object versioning and state locking.

The correct strategy combines Cloud Spanner (which natively delivers multi-continent global ACID relational transactions), Customer-Managed Encryption Keys via Cloud KMS (fulfilling corporate key governance without raw key transmission), and a Cloud Storage remote backend for Terraform featuring object versioning and state locking (protecting IaC state integrity).

Step-by-Step Solution

Evaluate database requirements for multi-continent ACID transactions

Identify Cloud Spanner as the required storage system because Cloud SQL does not scale across multiple continents with active-active relational consistency.

Cloud Spanner uses TrueTime and distributed consensus to deliver globally distributed relational ACID transactions.

Identify key management requirements

Select Customer-Managed Encryption Keys (CMEK) backed by Cloud KMS rather than Customer-Supplied Keys (CSEK).

CMEK allows central policy governance and automated rotation via Cloud KMS without forcing client applications to store or transmit raw key material.

Determine automated IaC state management best practices

Configure a remote backend on Cloud Storage with both object versioning and state locking enabled.

State locking prevents concurrent executions from corrupting the state file, and object versioning allows recovery from accidental state corruption.

Key Concept

Provisioning globally distributed relational databases with CMEK and securing IaC state backends

Estimated Time:1m 30s

Question 824Question →

A financial services enterprise is designing a comprehensive container security and threat management architecture on Google Cloud for their Google Kubernetes Engine (GKE) microservices. The lead cloud security architect must select and configure specific Google Cloud security services to meet security enforcement, threat monitoring, and vulnerability scanning requirements across the supply chain and runtime environments. Match each Google Cloud security service on the left with its corresponding architectural requirement on the right.

Click a left item, then click its matching right item

Show answer & explanation

Answer

Binary Authorization maps to enforcing cryptographic image attestation at deployment time; Artifact Analysis Container Scanning maps to automated image scanning and continuous CVE monitoring in Artifact Registry; Security Command Center Event Threat Detection maps to real-time stream log analysis for threat detection; GKE Security Posture Dashboard maps to auditing workload configuration and container OS vulnerabilities in cluster management views.

Each selected security tool fulfills a specific role in a defense-in-depth container security strategy: Binary Authorization enforces policy checks at GKE deployment time; Artifact Analysis handles vulnerability scanning in Artifact Registry; Event Threat Detection performs log stream threat analysis; and the GKE Security Posture Dashboard delivers runtime workload configuration auditing and vulnerability assessment.

Step-by-Step Solution

Evaluate the requirement for preventing unauthorized image deployment to GKE.

Binary Authorization integrates with GKE admission controllers to enforce signature-based attestation checks before container deployment.

Ensures only trusted, signed images built by approved CI/CD pipelines can execute in the cluster.

Determine the service for registry-level image vulnerability scanning.

Artifact Analysis automatically scans images stored in Artifact Registry and maintains an updated CVE status through continuous scanning.

Provides early detection of package vulnerabilities prior to container deployment.

Identify the organization-wide threat detection service utilizing log streams.

Security Command Center Event Threat Detection parses log streams in near real-time to identify threat signatures.

Detects suspicious security events across Google Cloud resources without needing container-level agent installation.

Match the cluster-native workload security posture and configuration scanner.

GKE Security Posture Dashboard surfaces configuration risks and runtime vulnerability assessments natively within GKE.

Gives cluster administrators direct visibility into Kubernetes workload vulnerabilities and compliance drift.

Key Concept

Mapping Google Cloud container security, vulnerability scanning, and threat detection services to supply chain and runtime security requirements.

Question 825Question →

An enterprise healthcare organization stores sensitive patient diagnostic datasets in Google Cloud Storage. Corporate regulatory compliance mandates that all data at rest must be encrypted using Customer-Managed Encryption Keys (CMEK) hosted in Cloud KMS, key rotation must be automated annually without requiring re-encryption of existing data, and key access permissions must strictly adhere to the principle of least privilege. Which configuration strategy satisfies these security and compliance requirements?

Supply a raw 256-bit AES Customer-Supplied Encryption Key (CSEK) header with every upload request and run a scheduled on-premises script to regenerate and supply new raw key material annually.

Configure the Cloud Storage bucket with a Cloud KMS CMEK key, grant the Cloud Storage Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the key, and set an automated 365-day rotation schedule on the CryptoKey.

Configure the Cloud Storage bucket with a Cloud KMS key and grant the Editor primitive IAM role to the project service account so that it can manage both Cloud KMS resources and storage bucket objects.

Enclose the Cloud Storage bucket inside a VPC Service Controls perimeter and rely on perimeter ingress/egress rules to enforce data encryption without assigning key IAM roles to service identities.

Show answer & explanation

Answer: Configure the Cloud Storage bucket with a Cloud KMS CMEK key, grant the Cloud Storage Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role on the key, and set an automated 365-day rotation schedule on the CryptoKey.

Answer

Configure the Cloud Storage bucket using a Customer-Managed Encryption Key (CMEK) stored in Cloud KMS, assign the Cloud KMS CryptoKey Encrypter/Decrypter role specifically to the Cloud Storage Service Agent, and define an automated 365-day rotation schedule on the key.

To satisfy customer-managed encryption (CMEK) requirements in Google Cloud Storage with least privilege, key management must be delegated to Cloud KMS. The Google-managed Cloud Storage Service Agent requires the dedicated `roles/cloudkms.cryptoKeyEncrypterDecrypter` role on the CryptoKey to perform cryptographic operations. Configuring an automatic 365-day rotation period directly on the Cloud KMS key ensures compliance without manual intervention or data re-encryption.

Step-by-Step Solution

Identify key management architecture requirements

Cloud KMS CMEK is required (eliminating raw key management models like CSEK).

Compliance specifies managing keys in Cloud KMS rather than supplying raw keys on every HTTP request.

Apply least privilege IAM roles for CMEK

The Cloud Storage Service Agent (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) requires roles/cloudkms.cryptoKeyEncrypterDecrypter.

Cloud Storage performs encryption and decryption operations asynchronously using its managed service agent identity, not primitive user/editor roles.

Configure key rotation schedule

Set a 365-day rotation period on the Cloud KMS CryptoKey.

Automated key rotation generates new key versions periodically without modifying existing encrypted data or requiring manual key re-upload.

Key Concept

Cloud Storage CMEK Integration and Cloud KMS Service Agent IAM Least Privilege

Estimated Time:1m 30s

Question 826Question →

An online retail organization operates workloads across two regions using a single Virtual Private Cloud (VPC) network with subnets in us-central1 and europe-west1. On-premises data centers in both regions are connected to Google Cloud via Dedicated Interconnect attachments bound to regional Cloud Routers. The networking team requires that if the Dedicated Interconnect link in europe-west1 fails, on-premises traffic from europe-west1 must automatically fail over to reach workloads in us-central1 via the us-central1 Interconnect path. Which VPC network dynamic routing configuration should you implement to meet this requirement?

Set the VPC network dynamic routing mode to Global so that Cloud Routers advertise all VPC subnets to on-premises routers across all regions.

Establish VPC Network Peering between subnets in us-central1 and europe-west1 so that dynamic BGP routes can be transitively exchanged across regions.

Replace the Dedicated Interconnect in europe-west1 with an HA VPN gateway because Cloud Interconnect connections do not support cross-region dynamic routing.

Configure VPC Service Controls perimeter egress rules to explicitly permit inter-regional BGP route propagation between Cloud Routers.

Show answer & explanation

Answer: Set the VPC network dynamic routing mode to Global so that Cloud Routers advertise all VPC subnets to on-premises routers across all regions.

Answer

Set the VPC network dynamic routing mode to Global so that Cloud Routers advertise all VPC subnets to on-premises routers across all regions.

Configuring the VPC dynamic routing mode to Global enables Cloud Routers in a specific region (such as us-central1) to advertise all subnets within the VPC, including those in other regions, to on-premises routers. This creates high availability and automatic cross-region failover for hybrid connectivity over Dedicated Interconnect.

Step-by-Step Solution

Analyze the requirement for multi-region hybrid failover in a single VPC.

Identified that subnets in us-central1 need to be reachable over BGP via the europe-west1 Interconnect connection (and vice versa) in case of link failure.

By default, regional dynamic routing restricts Cloud Routers to advertising only subnets located in the local region of the Cloud Router.

Evaluate Google Cloud VPC dynamic routing modes.

Global dynamic routing mode enables Cloud Routers in any region to learn and advertise routes to all subnets across the entire VPC network.

Configuring the VPC dynamic routing mode to Global ensures cross-region route propagation across Cloud Interconnect and Cloud Router endpoints.

Key Concept

VPC Dynamic Routing Modes (Regional vs. Global)

Estimated Time:1m 30s

Question 827Question →

A financial services organization based in Singapore is migrating its core transactional platform to Google Cloud. To comply with regional regulatory compliance and data sovereignty mandates, the enterprise must ensure that all storage resources and key management services are strictly restricted to the asia-southeast1 region. Additionally, any access by Google support engineers to customer data for operational tasks must require prior explicit approval from the customer's security team. Which TWO architectural mechanisms should a Cloud Architect implement to fulfill these compliance requirements?

Select all that apply

Enforce an Organization Policy using the Resource Locations constraint (constraints/gcp.resourceLocations) limited to the asia-southeast1 region.

Enable Access Approval at the organization or project level to mandate explicit customer authorization before Google support personnel can inspect resources.

Mandate Customer-Supplied Encryption Keys (CSEK) across all storage services to manually govern key storage locations.

Grant the primitive IAM Owner role (roles/owner) to the internal compliance team to oversee resource deployment geographic restrictions.

Show answer & explanation

Answer: Enforce an Organization Policy using the Resource Locations constraint (constraints/gcp.resourceLocations) limited to the asia-southeast1 region.; Enable Access Approval at the organization or project level to mandate explicit customer authorization before Google support personnel can inspect resources.

Answer

Enforce an Organization Policy using the Resource Locations constraint (constraints/gcp.resourceLocations) limited to the asia-southeast1 region, and enable Access Approval at the organization or project level to mandate explicit customer authorization before Google support personnel can inspect resources.

Data residency and sovereign access requirements are effectively satisfied by pairing the Resource Locations organization policy constraint (to programmatically restrict resource and KMS location boundaries) with Access Approval (to enforce explicit customer approval for Google support interventions).

Step-by-Step Solution

Address the regional data sovereignty mandate for resources and key management.

Configure the constraints/gcp.resourceLocations Organization Policy to allow resource creation only in asia-southeast1.

Organization Policies restrict resource creation geographically across all supported Google Cloud services within the resource hierarchy.

Address the constraint regarding Google support administrative access oversight.

Configure Access Approval for the GCP organization or target project.

Access Approval provides a human-in-the-loop mechanism requiring customer authorization before Google personnel can access data for support or troubleshooting.

Key Concept

Data Sovereignty and Support Access Control via Resource Location Constraints and Access Approval

Question 828Question →

A retail company is auditing its automated CI/CD pipeline built with Cloud Build to deploy microservices to Cloud Run and provision resources using Terraform. The audit reveals two major compliance and operational risks: build jobs currently run using the broad default Compute Engine service account, and Terraform execution state is stored on local ephemeral build runner storage, causing state locks to fail during concurrent build executions. Which combination of security and operational refactoring should the Cloud Architect recommend to remediate these issues?

Configure Cloud Build triggers to use a custom service account granted minimal required IAM roles, and migrate the Terraform state backend to a Cloud Storage bucket with object versioning and state locking enabled.

Grant the primitive Owner role to the default Compute Engine service account to prevent pipeline permission errors, and store the Terraform state in a Cloud Storage bucket without versioning.

Grant the Service Account Admin role directly to developers so they can modify pipeline execution accounts, while keeping Terraform state files on local build runner storage.

Configure a custom service account for Cloud Build, but maintain the Terraform state file on local persistent disks attached to build worker instances to avoid network storage overhead.

Show answer & explanation

Answer: Configure Cloud Build triggers to use a custom service account granted minimal required IAM roles, and migrate the Terraform state backend to a Cloud Storage bucket with object versioning and state locking enabled.

Answer

The architect should configure Cloud Build to run using a custom service account with least privilege permissions and configure a Cloud Storage remote backend for Terraform state locking and versioning.

Configuring Cloud Build triggers to use a custom service account restricted to necessary IAM roles adheres strictly to the principle of least privilege. Simultaneously, utilizing a Cloud Storage remote backend with state locking resolves concurrent execution conflicts and safeguards Terraform state integrity through versioning.

Step-by-Step Solution

Address pipeline identity security

Replace the default Compute Engine service account on Cloud Build triggers with a dedicated custom service account assigned only the specific IAM permissions needed for deployment.

Default service accounts have broad access (such as Editor) which violates least privilege security requirements.

Address infrastructure state management

Configure Terraform to use a Google Cloud Storage (GCS) backend with state locking enabled.

A remote GCS backend provides distributed state locking to prevent race conditions during concurrent deployments and object versioning for audit/recovery.

Key Concept

CI/CD Pipeline Security Least Privilege and Remote IaC State Lock Management

Question 829Question →

An enterprise cloud architecture team at a global aviation safety oversight agency is developing a regulatory compliance analytics platform. Place the architectural design phases in the correct sequential order, starting from the highest conceptual abstraction down to concrete Google Cloud infrastructure deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with defining conceptual business domain entities and compliance rules, followed by designing logical service boundaries and technology-agnostic data flows, then mapping logical components to specific Google Cloud products, and finally specifying detailed physical IaC parameters like subnets, IAM bindings, and CMEK settings.

The standard enterprise architecture lifecycle progresses hierarchically from Conceptual (defining business entities, governance goals, and regulatory boundaries) to Logical (defining functional data flows, service boundaries, and security domains independent of technology choices), followed by Physical Product Mapping (matching logical blocks to GCP offerings like Pub/Sub, Dataflow, and BigQuery), and concluding with Physical Configuration Specification (specifying exact IaC code, subnets, IAM, and encryption keys).

Step-by-Step Solution

Identify the Conceptual Architecture phase

Established business rules, domain data definitions, and compliance requirements without technical or vendor commitments.

Architecture planning must begin by capturing business intent and governance boundaries before determining technical design.

Identify the Logical Architecture phase

Created component boundaries, data processing flows, and security zones independently of cloud providers.

Logical modeling structures functional capabilities and relationships without tying the design to specific physical services.

Identify the Physical Resource Selection phase

Selected concrete GCP services (Pub/Sub, Dataflow, BigQuery) matching logical requirements.

Physical design translates vendor-agnostic functional blocks into actual target cloud service implementations.

Identify the Physical Infrastructure Provisioning phase

Formulated IaC manifests containing specific VPC subnets, IAM permissions, and CMEK encryption keys.

Detailed physical configuration parameters are required for deployment automation, operational management, and security enforcement.

Key Concept

Sequential Translation from Conceptual to Logical and Physical Architectures

Estimated Time:1m 30s

Question 830Question →

An enterprise security team is establishing access governance for a new Google Cloud deployment. In what top-down order should an administrator perform these steps to implement resource hierarchy and IAM permissions according to Google Cloud best practices?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence configures governance top-down starting at the Organization node, establishing Folders for structural grouping, creating Projects within those folders, and finally applying granular least-privilege IAM bindings at the Project or Resource level.

Google Cloud access governance flows down the resource hierarchy: Organization → Folders → Projects → Resources. Defining baseline controls at the Organization level ensures global policy enforcement. Creating Folders allows environment-level grouping. Provisioning Projects provides the compute/storage containers. Finally, assigning granular IAM roles at the Project or Resource level achieves least privilege.

Step-by-Step Solution

Configure top-level policy constraints and organization-wide IAM policies at the Organization node.

Establishes baseline security boundaries that inherit across all descendant resources.

Governance best practices require establishing high-level security controls before workload resources are created.

Construct environment or department Folders under the Organization node.

Organizes projects into manageable administrative units.

Folders allow applying common IAM roles and organization policies to groups of projects.

Deploy individual GCP Projects inside the folder hierarchy.

Provides discrete containers for hosting GCP services and resources.

Projects must exist within folders before service APIs can be enabled and workloads deployed.

Assign fine-grained predefined or custom IAM roles at the Project or specific Resource level.

Enforces least-privilege access control tailored to workload needs.

Specific permissions should be granted at the most targeted resource boundary to prevent overly broad privilege propagation.

Key Concept

Google Cloud Resource Hierarchy and IAM Inheritance Governance

Question 831Question →

A global logistics enterprise migrated its order tracking platform to Google Cloud under tight deadline constraints. A post-migration architecture review identified two primary sources of technical debt causing operational friction:
1. Infrastructure deployment pipelines fail frequently due to state corruption and concurrency conflicts because Terraform state files are stored on local build worker drives.
2. A simple, stateless HTTP microservice used solely for tracking payload validation is hosted on a dedicated standard Google Kubernetes Engine (GKE) cluster, resulting in high operational management overhead and idle compute costs.

Which combination of architectural refactoring actions best mitigates this technical debt while adhering to Google Cloud recommended practices?

Store Terraform state in a Google Cloud Storage bucket configured with object versioning and state locking, and refactor the tracking payload validation microservice to run on Cloud Run.

Commit Terraform state files directly into the application source control repository for versioning, and refactor the tracking payload validation microservice to run on Cloud Run.

Store Terraform state in a Google Cloud Storage bucket configured with object versioning, and migrate the stateless payload validation logic into a high-availability Cloud Spanner instance.

Store Terraform state in a Google Cloud Storage bucket configured with object versioning, and assign the primitive Project Owner role to CI/CD pipeline service accounts to resolve deployment permission errors.

Show answer & explanation

Answer: Store Terraform state in a Google Cloud Storage bucket configured with object versioning and state locking, and refactor the tracking payload validation microservice to run on Cloud Run.

Answer

Store Terraform state in a Google Cloud Storage bucket configured with object versioning and state locking, and refactor the tracking payload validation microservice to run on Cloud Run.

Migrating Terraform state management to a Google Cloud Storage bucket with object versioning provides automated object locking during concurrent execution pipelines, preventing configuration drift and state file corruption. Concurrently, migrating a simple stateless HTTP payload validation service from standard GKE to Cloud Run eliminates Kubernetes cluster management overhead, control plane costs, and manual node pool maintenance while enabling serverless scale-to-zero compute.

Step-by-Step Solution

Analyze the technical debt accrued in the Infrastructure as Code (IaC) lifecycle.

Identified that local Terraform state storage causes concurrency conflicts and state file corruption across deployment runners.

Google Cloud Storage provides native remote backend support for Terraform with automated file locking and versioning.

Evaluate compute engine requirements for the stateless validation microservice.

Hosting a lightweight, stateless HTTP validation microservice on standard GKE imposes unnecessary cluster management overhead, master node baseline costs, and scaling configuration complexity.

Cloud Run is a fully managed serverless container platform ideal for stateless HTTP workloads, removing cluster infrastructure maintenance entirely while reducing cost via scale-to-zero capabilities.

Synthesize the optimal mitigation strategy adhering to GCP best practices.

Combine Cloud Storage for centralized Terraform state management with Cloud Run for serverless container execution.

This paired solution directly addresses operational toil, cost inefficiency, and deployment instability.

Key Concept

Mitigating operational and architectural technical debt using managed serverless compute (Cloud Run) and centralized remote IaC state backends (Cloud Storage).

Estimated Time:2m 0s

Question 832Question →

An enterprise travel platform hosted on Google Cloud experiences significant user churn during flash sales. While infrastructure monitoring reports 99.99% VM uptime, business stakeholders note that high latency during the payment validation step causes customers to abandon their bookings. The Site Reliability Engineering (SRE) team needs to realign operational monitoring to directly reflect business impact and prevent revenue loss. Which TWO actions should the SRE team take to align technical service levels with business objectives? (Select TWO)

Select all that apply

Define a latency Service Level Indicator (SLI) measured as the proportion of successful payment API requests completed in under

500\text{ ms}

at the user-facing load balancer.

Define the Service Level Indicator (SLI) target as an availability goal of

99.9\%

over a rolling 30-day window to set operational alerting thresholds.

Establish a Service Level Objective (SLO) tied to an error budget policy that freezes non-urgent feature releases when payment latency breaches threaten checkout conversion rates.

Configure static CPU utilization alerts on backend Compute Engine instances to trigger PagerDuty notifications whenever CPU usage exceeds

85\%

for 5 minutes.

Show answer & explanation

Answer: Define a latency Service Level Indicator (SLI) measured as the proportion of successful payment API requests completed in under $500\text{ ms}$ at the user-facing load balancer.; Establish a Service Level Objective (SLO) tied to an error budget policy that freezes non-urgent feature releases when payment latency breaches threaten checkout conversion rates.

Answer

The team should define a user-facing latency SLI based on successful payment calls completed within

500\text{ ms}

and establish an SLO tied to an error budget policy that governs feature deployment velocity based on checkout impact.

Defining a latency SLI at the user-facing load balancer accurately captures customer experience for payment validation. Tying that SLI to an SLO with an error budget policy ensures that when user experience degrades, engineering effort is redirected from new features to service reliability, directly mitigating business revenue loss.

Step-by-Step Solution

Identify the user-facing metric (SLI) that directly reflects business performance.

Selected the ratio of successful requests meeting the

500\text{ ms}

latency threshold measured at the entry load balancer.

SLIs must quantify the actual performance experienced by users rather than internal system resource availability.

Align operational governance (SLO and Error Budget) with business outcomes.

Established an SLO error budget policy that halts non-critical feature releases when latency targets are breached.

Error budget policies enforce business alignment between reliability engineering and product feature development.

Key Concept

Aligning user-centric SLIs and error-budget-driven SLOs with business impact

Question 833Question →

A development team is establishing an automated Infrastructure as Code (IaC) deployment pipeline using Terraform on Google Cloud. As a Cloud Architect, you are advising the operations team on foundational security and state management best practices. Which TWO recommendations should you provide to ensure secure, concurrent, and reliable deployments? (Select TWO answers.)

Select all that apply

Store the Terraform state file in a Google Cloud Storage backend with object versioning and state locking enabled.

Grant CI/CD service accounts fine-grained predefined or custom IAM roles adhering to the principle of least privilege.

Store Terraform state files on the local filesystem of developer workstations or CI runners to maximize execution speed.

Assign the primitive Owner role to the deployment service account to ensure pipeline tasks never fail due to missing permissions.

Grant the Service Account Admin role to developers who need to run infrastructure deployment scripts from their local machines.

Show answer & explanation

Answer: Store the Terraform state file in a Google Cloud Storage backend with object versioning and state locking enabled.; Grant CI/CD service accounts fine-grained predefined or custom IAM roles adhering to the principle of least privilege.

Answer

The architect should advise the team to store Terraform state in a Cloud Storage bucket with object versioning and state locking enabled, and to grant deployment service accounts least-privilege predefined or custom IAM roles.

Centralizing Terraform state management using a Google Cloud Storage bucket with versioning and object locking ensures multi-user concurrency protection and disaster recovery for IaC state. Concurrently, granting specific predefined or custom roles to deployment service accounts enforces the principle of least privilege without exposing administrative control over unrelated resources.

Step-by-Step Solution

Analyze the state management requirement for team deployments.

Local state files cause race conditions and risk loss. A central Cloud Storage backend with state locking handles concurrent access safely.

Terraform state locks prevent multiple pipeline runs from corrupting infrastructure state simultaneously.

Analyze the security privileges for the automated pipeline service account.

Primitive roles like Owner grant overly broad access across resources, whereas fine-grained roles follow security best practices.

Adhering to least-privilege IAM controls prevents potential security exfiltration or unintended resource disruption.

Key Concept

Advising operations and development teams on Cloud Storage Terraform backends and least-privilege IAM service account configuration.

Question 834Question →

An enterprise insurance company hosts its critical claims processing platform on Google Cloud, with primary services running in us-central1 and a disaster recovery target in us-east4. The business requires a Recovery Point Objective (RPO) of under 1 minute and a Recovery Time Objective (RTO) of under 15 minutes. As part of establishing a routine Business Continuity and Disaster Recovery (BCP/DR) validation procedure, the Cloud Architect must implement a testing process that verifies full regional failover capability without disrupting ongoing production operations in us-central1. Which procedure should the Cloud Architect implement to validate the DR plan?

Pre-verify and reserve required regional resource quotas in us-east4, provision a sandboxed test environment using a restored database point-in-time clone in us-east4, execute synthetic transactional failover workloads, and validate DNS failover routing policies without altering primary production endpoints.

Rearchitect the workload to use a cold-standby backup strategy in us-east4 utilizing nightly Cloud Storage bucket exports, and validate the DR plan by restoring database backups into us-east4 during scheduled maintenance windows.

Initiate a unannounced live production traffic redirection to us-east4 via Cloud DNS during peak business hours, relying on Google Cloud auto-scaling to request and provision additional compute instance quota dynamically as traffic shifts.

Replace the existing multi-region database with a single-zone Cloud SQL instance in us-central1 with a cross-region read replica in us-east4, and test DR validation by executing manual replica promotion scripts during testing drills.

Show answer & explanation

Answer: Pre-verify and reserve required regional resource quotas in us-east4, provision a sandboxed test environment using a restored database point-in-time clone in us-east4, execute synthetic transactional failover workloads, and validate DNS failover routing policies without altering primary production endpoints.

Answer

The optimal DR validation procedure involves pre-verifying regional resource quotas in us-east4, executing validation against an isolated sandboxed environment with database clones, and validating DNS routing policies without impacting active production workloads.

Pre-verifying regional resource quotas and using isolated test environments with synthetic workloads allows comprehensive DR validation of compute capacity, application integrity, and DNS routing without risking production downtime or violating tight RPO/RTO constraints.

Step-by-Step Solution

Assess RPO and RTO constraints against testing safety requirements.

Identified that validation must run safely without risking production outage or data corruption while ensuring the target region can handle the full workload.

DR testing procedures should validate operational readiness in an isolated manner before or alongside live failover drills.

Ensure compute and storage resource quota availability in the failover target region (us-east4).

Prevents failure during traffic shifting caused by hitting project quota limits in the secondary region.

Quotas are managed per region; failing to request quota increases ahead of failover testing guarantees infrastructure provisioning errors.

Validate application logic and failover workflows in a sandboxed target environment using synthetic load and isolated database copies.

Verifies data consistency, application health, and automated DNS routing without interrupting us-central1 production operations.

Safe BCP/DR validation procedures ensure full execution of failover mechanisms without imposing production downtime.

Key Concept

Disaster Recovery Validation and Quota Management

Question 835Question →

An enterprise platform engineering team is preparing an automated pipeline to deploy a secure Cloud SQL for PostgreSQL database instance. The solution must strictly enforce network isolation using Private Service Access and enforce data encryption at rest using a Customer-Managed Encryption Key (CMEK). In what sequence should the cloud architect arrange the implementation steps to provision this infrastructure successfully without service dependency failures?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct provisioning order requires setting up security and network dependencies prior to resource creation: first create and authorize the KMS key, second allocate private IP peering via Private Service Access, third provision the Cloud SQL instance referencing the key and network, and finally create internal databases and user credentials.

The correct sequence respects resource dependencies in Google Cloud. Configuring the Cloud KMS key and granting necessary IAM permissions to the Cloud SQL Service Agent is required first so the API can validate key access. Establishing Private Services Access (VPC peering and private IP allocation) is required second so the private IP interface can be bound. Provisioning the Cloud SQL instance referencing both the network and the CMEK key comes third. Finally, creating logical database schemas and application users inside the instance comes last because these resources depend on the active instance engine.

Step-by-Step Solution

Configure encryption infrastructure and IAM permissions

Cloud KMS CryptoKey is created and the Cloud SQL Service Agent ([email protected]) has permissions to encrypt and decrypt.

Cloud SQL API calls specify the CMEK key during creation; if the service agent lacks permissions at creation time, deployment fails immediately.

Set up private networking infrastructure

Internal IP block is reserved in the VPC and VPC Network Peering is established with Google's Service Networking tenant project.

Private Service Access must exist for Cloud SQL to assign a private IP address from the designated range.

Execute Cloud SQL instance creation

Cloud SQL instance is created in a private subnet, encrypted with CMEK.

Both prerequisites (network peering and KMS permissions) are satisfied, allowing the instance resource to instantiate.

Configure databases and application users

PostgreSQL database schemas and user identities are configured.

Logical database structures exist inside the database instance and can only be created on a running instance.

Key Concept

Dependency-Ordered Cloud Provisioning for CMEK and Private Service Access

Question 836Question →

A biomedical research institute is migrating its containerized genomic data processing workloads to Google Kubernetes Engine (GKE). The chief information security officer requires an architectural design that satisfies two strict security mandates: first, only container images that have been cryptographically verified and signed by the internal CI/CD build pipeline may be deployed to cluster nodes; second, any potential runtime container escapes or malicious hypervisor-level syscall anomalies must be detected out-of-band without adding sidecar agents to application pods. Which combination of Google Cloud services and configurations fulfills these requirements?

Enforce Binary Authorization policies backed by Cloud KMS attestors for deployment validation, and enable Security Command Center Premium utilizing Container Threat Detection and Event Threat Detection.

Configure VPC Service Controls perimeters around Artifact Registry and Cloud Storage to block unverified deployments and inspect runtime container kernel calls.

Grant the primitive IAM Owner role to the GKE cluster node service account to enable automated container image signature checking and continuous runtime threat prevention.

Disable control plane authorized networks on the private GKE cluster so Security Command Center can inspect container image layers and block unverified deployments.

Show answer & explanation

Answer: Enforce Binary Authorization policies backed by Cloud KMS attestors for deployment validation, and enable Security Command Center Premium utilizing Container Threat Detection and Event Threat Detection.

Answer

The solution requiring Binary Authorization policies backed by Cloud KMS attestors along with Security Command Center Premium (Container Threat Detection and Event Threat Detection) correctly satisfies both requirements. Binary Authorization ensures that only container images cryptographically signed during the CI/CD build process are allowed to run on GKE nodes. Security Command Center Premium's Container Threat Detection performs out-of-band kernel tracing on GKE nodes to identify container escapes, reverse shells, and malicious execution without requiring sidecar proxies.

Step-by-Step Solution

Analyze deployment verification requirements

Identified the need for cryptographic image signing and policy enforcement prior to deployment.

Binary Authorization integrates with GKE and Cloud KMS attestors to block any container image that lacks a valid signature from the authorized CI/CD pipeline.

Analyze runtime threat detection requirements

Identified the need for agentless, kernel/audit log runtime monitoring.

Security Command Center Premium includes Container Threat Detection, which monitors node kernel instrumentation to detect container escapes and suspicious binaries out-of-band without needing sidecar containers.

Combine services to formulate the complete architecture

The architecture pairs Binary Authorization for pre-deployment gating with SCC Premium for runtime threat detection.

This combined solution satisfies both mandate criteria efficiently and securely.

Key Concept

Container Attestation and Runtime Threat Detection

Estimated Time:2m 30s

Question 837Question →

A global healthcare analytics company is establishing an automated technical solution testing and validation procedure for a high-throughput patient telemetry processing system on Google Cloud prior to production release. The validation environment uses Infrastructure as Code (IaC) pipelines, private Google Kubernetes Engine (GKE) clusters, and VPC Service Controls perimeters.

During dry-run validation tests, the execution suite encounters three critical failures:
1. Concurrent CI/CD pipeline validation runs fail due to Terraform state locks failing or state corruption.
2. Automated testing agents deployed inside a dedicated management VPC subnet are rejected when attempting to run cluster validation commands against the private GKE control plane.
3. Synthetic load testing fails prematurely because worker node provisioning halts during peak scaling simulation.

Which comprehensive validation procedure should the cloud architect implement to resolve these issues and ensure end-to-end technical solution validation?

Configure a Cloud Storage remote backend with state locking and object versioning for IaC pipelines, add the management subnet CIDR to GKE master authorized networks, and audit and request regional compute quota increases prior to running scale validation tests.

Store Terraform state files in unversioned local workspace storage across CI/CD runners, grant the Service Account Admin role to test execution workers to bypass GKE endpoint restrictions, and request quota extensions dynamically inside test scripts during scaling runs.

Disable master authorized networks entirely on the private GKE cluster to allow public API access during validation, rely on local Git repositories to track IaC state changes, and configure load balancer health checks to query backend database endpoints directly during load testing.

Temporarily remove VPC Service Controls perimeters during test execution to prevent exfiltration blocks, store Terraform state files in public Cloud Storage buckets, and rely on project-level default quotas without requesting regional quota adjustments prior to testing.

Show answer & explanation

Answer: Configure a Cloud Storage remote backend with state locking and object versioning for IaC pipelines, add the management subnet CIDR to GKE master authorized networks, and audit and request regional compute quota increases prior to running scale validation tests.

Answer

The correct architecture validation procedure is to configure a Cloud Storage remote backend with state locking and object versioning for IaC pipelines, add the management subnet CIDR to GKE master authorized networks, and audit and request regional compute quota increases prior to running scale validation tests.

The solution correctly addresses all three technical solution testing constraints. First, using a Cloud Storage remote backend with state locking ensures that concurrent automated deployment runs do not corrupt Terraform state. Second, defining master authorized networks for the specific management subnet CIDR ensures that automated test runners inside the VPC can communicate with the private GKE control plane endpoint without exposing it publicly. Third, proactively requesting regional compute quota increases prior to stress testing guarantees that load tests evaluate autoscaling capabilities accurately without hitting GCP resource limit barriers.

Step-by-Step Solution

Resolve IaC pipeline concurrency errors

Configuring Cloud Storage with state locking (via Cloud KMS/GCS native locking) prevents race conditions and state corruption across automated concurrent validation runs.

Infrastructure as Code validation procedures require reliable state consistency across parallel test executions.

Resolve private GKE control plane access restrictions

Adding the management subnet CIDR to the GKE master authorized networks allows test runner agents within the VPC to reach the private cluster API endpoint securely.

Private GKE clusters block all incoming traffic to the control plane by default unless explicit authorized network IP ranges are configured.

Resolve load test provisioning bottlenecks

Auditing and submitting quota increase requests for regional CPU, memory, and IP resources prior to stress testing ensures that autoscaling validation is not halted by default GCP quota bounds.

Quota increases can take time to process and must be secured before executing large-scale performance and capacity validation tests.

Key Concept

Developing procedures to test and validate technical solutions requires verifying IaC state integrity, private network control plane accessibility, and quota capacity preparedness before executing automated validation runs.

Estimated Time:3m 0s

Question 838Question →

A global logistics provider is establishing a enterprise-wide FinOps governance framework across 60 GCP projects. The current infrastructure consists of three main workload patterns: a core suite of legacy enterprise applications running 24/7 on Compute Engine with stable baseline CPU utilization; an unpredictable batch data processing workflow using BigQuery; and multiple transient, low-traffic web microservices for internal dev/test environments deployed on standard GKE clusters. The Chief Financial Officer requires a strategy that minimizes waste, establishes accurate departmental chargeback, and optimizes overall cloud spend without sacrificing operational flexibility. Which combination of cost optimization and governance practices should the Cloud Architect recommend?

Purchase Compute Committed Use Discounts (CUDs) for the predictable 24/7 Compute Engine baseline, migrate transient low-traffic internal web microservices to Cloud Run to eliminate idle cluster overhead, utilize BigQuery Enterprise edition autoscaling slots, and implement mandatory resource labeling tied to BigQuery Billing exports for automated chargeback.

Purchase 3-year standard Committed Use Discounts matching peak aggregate capacity across all GKE dev/test nodes, retain on-demand BigQuery pricing, and assign Owner primitive IAM roles to team leads so they can modify resource sizing directly in the GCP console.

Migrate all legacy application databases and batch data analytics storage to a single global multi-region Cloud Spanner instance to centralize billing management and leverage volume discounts across all projects.

Consolidate all workloads—including transient dev/test services and legacy batch jobs—into a large, statically provisioned regional GKE cluster running 24/7 to aggregate resource usage under a single project invoice.

Show answer & explanation

Answer: Purchase Compute Committed Use Discounts (CUDs) for the predictable 24/7 Compute Engine baseline, migrate transient low-traffic internal web microservices to Cloud Run to eliminate idle cluster overhead, utilize BigQuery Enterprise edition autoscaling slots, and implement mandatory resource labeling tied to BigQuery Billing exports for automated chargeback.

Answer

The correct strategy combines Compute Committed Use Discounts (CUDs) for the steady 24/7 baseline VMs, migrates transient dev/test microservices to serverless Cloud Run to avoid idle node costs, utilizes BigQuery slot autoscaling for variable batch jobs, and enforces resource labels paired with BigQuery billing export for departmental chargeback.

The solution properly maps each architectural pattern to its optimal FinOps pricing mechanism. Stable 24/7 workloads benefit from Compute CUDs for heavy baseline savings. Low-traffic transient microservices incur zero idle costs when run on Cloud Run due to scaling to zero. Variable analytics workloads avoid peak on-demand costs through BigQuery slot autoscaling. Standardized labels coupled with BigQuery billing export fulfill the organizational chargeback governance requirement.

Step-by-Step Solution

Analyze workload resource patterns

Identified steady-state 24/7 VM usage, unpredictable batch processing, and transient/low-traffic dev/test web services.

Different compute and data patterns require distinct pricing and platform models to optimize cost efficiency.

Select commitment and compute platforms

Apply Compute CUDs to the 24/7 baseline VMs, transition transient web services from GKE to serverless Cloud Run, and use BigQuery edition slot autoscaling.

CUDs offer substantial discounts on stable baselines, Cloud Run scales to zero during idle periods, and slot autoscaling avoids paying high on-demand rates or over-provisioning slots for bursty BigQuery queries.

Establish FinOps governance and chargeback

Implement mandatory resource labeling and export detailed Cloud Billing data to BigQuery.

Granular billing export combined with standardized key-value labels enables accurate multi-project cost allocation and chargeback reporting.

Key Concept

FinOps Cloud Cost Optimization and Governance Frameworks

Question 839Question →

An online interactive media enterprise is analyzing its continuous integration and continuous delivery (CI/CD) software development lifecycle (SDLC) pipeline. The pipeline uses Cloud Build to execute Terraform configurations that provision application infrastructure across Google Cloud projects. A technical audit reveals security and operational vulnerabilities in how the pipeline executes build steps and manages deployment state. Which architectural recommendation should the Cloud Architect make to align the CI/CD pipeline with Google Cloud security and reliability best practices?

Attach a dedicated custom service account with minimal required predefined roles to the Cloud Build trigger, and store the Terraform state in a Cloud Storage bucket with object versioning and state locking enabled.

Grant the primitive Owner role to the default Cloud Build service account to prevent permission errors during deployment, and store the Terraform state in a standard Cloud Storage bucket without versioning.

Grant the Service Account Admin role to the pipeline service account so it can manage compute instances and service account keys, while storing state files in local workspace storage.

Maintain the Terraform state file on the ephemeral local disk of the Cloud Build worker instance to minimize build latency and rely solely on standard IAM to prevent exfiltration.

Show answer & explanation

Answer: Attach a dedicated custom service account with minimal required predefined roles to the Cloud Build trigger, and store the Terraform state in a Cloud Storage bucket with object versioning and state locking enabled.

Answer

Configuring Cloud Build to execute using a dedicated custom service account with granular, least-privilege predefined roles reduces the blast radius of build execution. Pairing this with a remote Cloud Storage backend configured with object versioning and state locking guarantees concurrent execution protection, state persistence, and disaster recovery for Infrastructure as Code.

Step-by-Step Solution

Analyze CI/CD security requirements for Cloud Build execution.

Identify that using a dedicated custom service account with fine-grained predefined roles enforces least privilege, replacing default high-privilege accounts.

Default or primitive roles expose the entire cloud environment to privilege escalation if build scripts are compromised.

Analyze Infrastructure as Code (IaC) state management best practices for pipeline-driven Terraform deployments.

Determine that remote backend storage in Cloud Storage with state locking and object versioning is required.

Remote state in Cloud Storage prevents state corruption, enables concurrent lock management, and versioning allows state recovery.

Key Concept

CI/CD Pipeline Security and Infrastructure as Code State Management

Estimated Time:1m 30s

Question 840Question →

You are advising a development and operations team on best practices for securing CI/CD deployment pipelines and managing Google Cloud infrastructure. The team currently authenticates external deployment agents using long-lived service account keys saved in git repositories and grants primitive Owner roles to build scripts. Which TWO architectural recommendations should you provide to improve security and compliance? (Select TWO.)

Select all that apply

Configure Workload Identity Federation for external CI/CD pipelines to eliminate the need for downloadable long-lived service account keys.

Grant fine-grained, predefined or custom IAM roles adhering strictly to the principle of least privilege instead of primitive roles.

Store Terraform infrastructure state files on local build agent storage without remote versioning to speed up pipeline execution times.

Assign the Service Account Admin role to the deployment pipeline service account so it can elevate permissions dynamically during build steps.

Embed JSON service account private keys inside base container images so applications can authenticate automatically across all staging environments.

Show answer & explanation

Answer: Configure Workload Identity Federation for external CI/CD pipelines to eliminate the need for downloadable long-lived service account keys.; Grant fine-grained, predefined or custom IAM roles adhering strictly to the principle of least privilege instead of primitive roles.

Answer

The team should implement Workload Identity Federation to remove long-lived service account keys from pipelines, and assign fine-grained, predefined IAM roles following the principle of least privilege instead of broad primitive roles.

Advising operations teams on cloud best practices requires establishing secure deployment foundations. Utilizing Workload Identity Federation allows CI/CD systems to exchange external identity tokens for short-lived Google Cloud credentials without storing persistent keys. Combining this with fine-grained, least-privilege IAM roles ensures build scripts can perform required deployment tasks without exposing broad administrative permissions.

Step-by-Step Solution

Analyze current credential management anti-patterns.

Identify that saving static JSON service account keys in repositories poses a severe credential leak vulnerability.

Google Cloud recommends keyless authentication using Workload Identity Federation for external CI/CD platforms.

Evaluate IAM permissions governance.

Replace primitive Owner roles with least-privilege predefined or custom IAM roles tailored strictly to required deployment actions.

Primitive roles grant overly broad access across resources, increasing blast radius in the event of pipeline compromise.

Key Concept

Credential-less authentication via Workload Identity Federation and least-privilege IAM configuration for dev/ops automation.

PreviousPage 42 / 80Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept