Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 941Question →

An enterprise organization maintains two Virtual Private Cloud (VPC) networks, vpc-core and vpc-analytics, located in separate Google Cloud projects. The vpc-core network connects to an on-premises enterprise network using a Cloud Router and Dedicated Interconnect, dynamically learning on-premises IP subnets via BGP. A network administrator establishes a VPC Network Peering connection between vpc-core and vpc-analytics. Virtual machine instances hosted within vpc-analytics must be able to reach on-premises destinations using the existing Cloud Router in vpc-core. Which configuration is required on the VPC Network Peering connection to satisfy this connectivity requirement?

Show answer & explanation

Answer: Configure the VPC Network Peering configuration in vpc-core to export custom routes, and configure the peering configuration in vpc-analytics to import custom routes.

Answer

Configure the VPC Network Peering configuration in vpc-core to export custom routes, and configure the peering configuration in vpc-analytics to import custom routes.
VPC Network Peering exchanges subnet routes by default, but to share dynamically learned BGP routes (such as those learned over Cloud Router from an Interconnect), custom route flags must be configured. The network originating or holding the routes must export custom routes, and the peer network consuming those routes must import custom routes.

Step-by-Step Solution

1
Identify the routing requirement across peered VPC networks.
Dynamic BGP routes learned from on-premises via Cloud Router in vpc-core need to be visible in vpc-analytics.
By default, VPC Network Peering only exchanges subnet routes, not dynamically learned routes or static custom routes.
2
Determine the appropriate custom route flags on the peering relationship.
The vpc-core network must set export_custom_routes to true, and vpc-analytics must set import_custom_routes to true.
This configuration explicitly authorizes the propagation of custom dynamic routes across the VPC Network Peering boundary.

Key Concept

VPC Network Peering Custom Route Exchange
Question 942Question →

A financial services firm is provisioning a relational database on Google Cloud to process transactional ledger records confined strictly within a single GCP region. The system architecture requires full ACID compliance, automated point-in-time recovery, multi-zone high availability, and customer-managed encryption keys (CMEK) integrated with Cloud KMS. The platform engineering team must manage all infrastructure using Terraform and ensure that multiple engineers can execute provisioning safely without risk of state corruption or concurrent execution conflicts. Which architecture provisioning design fulfills all business and operational requirements?

Show answer & explanation

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

Answer

Deploy a Cloud SQL instance with High Availability enabled and CMEK encryption, while maintaining Terraform state in a remote Cloud Storage bucket with object versioning and state locking.
The correct strategy leverages Cloud SQL to fulfill single-region high-availability relational requirements with CMEK integration, combined with a Google Cloud Storage Terraform remote backend configured with object versioning and state locking to protect infrastructure state during team operations.

Step-by-Step Solution

1
Select the appropriate database service based on regional scale and transactional requirements.
Cloud SQL provides full ACID compliance, regional HA across zones, and native CMEK encryption without the high cost and global overhead of Cloud Spanner.
The scenario explicitly mandates single-region transactional processing, making Cloud SQL the optimal relational database engine.
2
Select the appropriate encryption key model.
Customer-Managed Encryption Keys (CMEK) via Cloud KMS meet organizational enterprise security policies while enabling key lifecycle management in GCP.
CMEK allows central control and auditing in Cloud KMS without forcing administrators to maintain raw CSEK key material.
3
Configure the Infrastructure as Code (IaC) state management strategy.
A Cloud Storage remote backend using object versioning and state locking via Cloud Storage prevents race conditions and state corruption.
Multi-engineer teams require explicit lock management and backup history when running Terraform automation.

Key Concept

Provisioning Cloud SQL database instances with CMEK and managing Terraform state securely via remote GCS backends.
Question 943Question →

A digital news publishing company rapidly migrated its microservices to Google Cloud to meet a tight launch deadline. A post-launch architectural assessment reveals significant technical debt: development teams have been making out-of-band manual configuration changes directly in the Cloud Console, resulting in severe infrastructure drift, and compute workloads rely on the default compute service account equipped with the primitive Editor role. You need to establish automated infrastructure governance and remediate this technical debt while ensuring minimal operational disruption. Which strategy should you recommend?

Show answer & explanation

Answer: Import existing cloud resources into Terraform state using infrastructure-as-code import workflows, enforce all future updates through an automated CI/CD pipeline, and replace primitive service account permissions with specific predefined roles based on least privilege.

Answer

Import existing cloud resources into declarative IaC state files, route all changes through automated deployment pipelines, and replace broad primitive Editor roles with granular predefined IAM roles following least privilege.
The optimal strategy for mitigating technical debt from rapid cloud adoption involves adopting declarative Infrastructure as Code (such as Terraform) by importing existing resources, automating updates via CI/CD, and auditing permissions to replace primitive roles with minimal predefined IAM roles. This establishes sustainable governance and enforces security best practices.

Step-by-Step Solution

1
Assess current technical debt sources
Identified two core areas of debt: unmanaged manual console changes (configuration drift) and excessive IAM privileges (primitive Editor role on service accounts).
Technical debt mitigation requires addressing both operational governance and security vulnerabilities systematically.
2
Bring existing infrastructure under automated control
Import unmanaged GCP resources into Terraform state and restrict modification rights strictly to CI/CD service accounts.
Declarative Infrastructure as Code managed via continuous deployment pipelines prevents configuration drift and establishes an auditable single source of truth.
3
Remediate service account security debt
Audit workload permission requirements and grant minimum necessary predefined or custom IAM roles.
Replacing primitive roles with fine-grained roles enforces the principle of least privilege and reduces potential blast radius.

Key Concept

Technical Debt Mitigation via Infrastructure as Code Governance and IAM Least Privilege
Estimated Time:1m 30s
Question 944Question →

A financial brokerage firm based in Japan is migrating its customer portfolio database and analytics warehouse to Google Cloud. To satisfy national data sovereignty mandates and strict internal governance standards, the cloud architecture must enforce two key requirements:
1. All underlying storage resources containing customer records must be strictly restricted to Google Cloud regions within Japan.
2. Authorized internal data analysts querying datasets in BigQuery must be prevented from exfiltrating sensitive data to external, non-compliant Google Cloud storage resources or projects.

Which TWO architectural measures should you implement to satisfy these compliance and data governance requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Define an Organization Policy constraint using Resource Locations (`constraints/gcp.resourceLocations`) restricted to Japan location groups across the target resource hierarchy.; Configure a VPC Service Controls security perimeter around the projects containing BigQuery and storage resources to prevent data movement outside approved perimeter boundaries.

Answer

To meet the compliance requirements, you should configure an Organization Policy constraint for Resource Locations restricting provisioning to Japan regions, and establish a VPC Service Controls security perimeter around the analytical workloads to prevent data exfiltration.
Data residency is enforced using Resource Location organization policy constraints to guarantee resources are provisioned strictly within Japan regions. Data exfiltration controls require VPC Service Controls, which enforce perimeter boundaries around Google Cloud services (such as BigQuery) to prevent users from copying sensitive datasets to external projects.

Step-by-Step Solution

1
Address data sovereignty and residency requirements
Enforce the `constraints/gcp.resourceLocations` Organization Policy constraint set to Japan locations across the resource hierarchy.
Organization policies centrally prevent users and deployment tools from creating storage or compute resources outside compliant geographic boundaries.
2
Address data exfiltration and governance controls
Construct a VPC Service Controls perimeter enclosing the project hosting BigQuery and Cloud Storage resources.
VPC Service Controls protect against data exfiltration by restricting network communication and data copying operations between protected services and unauthorized external GCP projects or locations.

Key Concept

Data sovereignty enforcement via Resource Locations organization policy paired with data exfiltration prevention using VPC Service Controls.
Question 945Question →

An enterprise retail supply chain company migrated its inventory tracking microservices to Google Cloud using a rapid rehosting approach. A post-migration architecture review identifies two critical technical debt risks: infrastructure modifications are executed manually by developers using local Terraform state files saved on individual laptops, and application service accounts have been assigned the primitive Project Editor role (`roles/editor`) to avoid access permission errors. Which TWO architecture refactoring steps should the Lead Cloud Architect recommend to mitigate this technical debt? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Migrate Terraform state management to a central Google Cloud Storage bucket with object versioning and object locking enabled, and enforce infrastructure changes through a continuous integration pipeline.; Replace primitive project roles on service accounts with fine-grained predefined or custom IAM roles scoped strictly to the specific resources required by each microservice.

Answer

The architect should migrate Terraform state files to a centralized Cloud Storage backend with object versioning and state locking enforced via automated CI/CD pipelines, and replace broad primitive Project Editor roles on service accounts with fine-grained, resource-scoped IAM roles.
Remediating technical debt resulting from rapid rehosting requires addressing governance and security anti-patterns. Implementing a remote Cloud Storage backend for Terraform ensures state locking and version history, while executing deployments through automated CI/CD pipelines prevents manual drift. Additionally, replacing broad primitive Project Editor roles with targeted predefined roles enforces least-privilege access for application service accounts.

Step-by-Step Solution

1
Assess Infrastructure as Code state management technical debt.
Identified risk: Storing Terraform state locally causes configuration drift, state corruption, and lack of locking during updates.
Centralizing state management in Cloud Storage with backend locking and CI/CD automation secures state history and standardizes deployments.
2
Assess identity and access management technical debt.
Identified risk: Primitive Editor roles grant overly broad permissions across all project resources.
Applying the principle of least privilege by scoping predefined or custom IAM roles to specific microservice dependencies removes excess project-level access.

Key Concept

Assessing and Mitigating Technical Debt in Cloud Architectures
Question 946Question →

A global logistics enterprise manages its multi-tenant Google Cloud architecture using Terraform within Cloud Build continuous integration pipelines across separate development, staging, and production GCP organizations. The lead cloud architect must design an Infrastructure as Code (IaC) execution and security framework that satisfies four critical requirements:
1. CI/CD pipeline runners must authenticate without storing long-lived service account JSON keys in repositories or build secrets.
2. Terraform execution across environments must isolate state files to prevent concurrent state locks and accidental cross-environment modifications.
3. Automated pipeline service accounts must enforce least-privilege security scoping tailored to each environment.
4. Unsanctioned configuration changes made directly through the Cloud Console or gcloud CLI must be automatically detected and safely aligned with declared IaC configurations.

Which architecture meets all requirements while following Google Cloud recommended best practices?

Show answer & explanation

Answer: Authenticate Cloud Build using Workload Identity Federation to eliminate service account keys. Store state in distinct Cloud Storage buckets per environment configured with Object Versioning and state locking. Grant environment-specific fine-grained IAM roles to dedicated pipeline service accounts, and run scheduled automated terraform plan checks alongside Cloud Asset Inventory feeds to detect and reconcile configuration drift.

Answer

The optimal solution uses Workload Identity Federation for keyless authentication, distinct Cloud Storage buckets per environment with Object Versioning and state locking, fine-grained IAM roles assigned to dedicated service accounts, and scheduled automated terraform plan runs paired with Cloud Asset Inventory feeds to detect and remediate drift.
The solution leveraging Workload Identity Federation, isolated Cloud Storage state buckets with versioning/locking, fine-grained per-environment IAM roles, and automated drift monitoring via scheduled plans fully addresses all four enterprise requirements while strictly adhering to Google Cloud architecture standards.

Step-by-Step Solution

1
Evaluate authentication and credential management requirements
Identify Workload Identity Federation as the Google Cloud recommended method to authenticate CI/CD runners without long-lived service account JSON keys.
Storing static service account keys in build runners introduces risk of key exposure and management overhead.
2
Establish secure remote state storage and environment isolation
Configure separate Cloud Storage buckets per environment with Object Versioning enabled for state history and locking mechanisms to prevent concurrent writes.
Isolating environments into separate buckets prevents cross-environment blast radius and accidental state lock contention.
3
Define IAM privilege scoping for pipeline execution
Assign fine-grained, predefined or custom IAM roles (e.g., Compute Network Admin, Storage Admin) specific to each environment's dedicated service account.
Avoids primitive roles like Owner or Editor, ensuring compliance with the principle of least privilege.
4
Implement automated drift detection and remediation
Schedule periodic terraform plan pipelines and leverage Cloud Asset Inventory real-time notification feeds to detect live infrastructure differences against declared IaC files.
Allows automated pipeline remediation (terraform apply) to realign infrastructure without manual state tampering or manual audit delays.

Key Concept

Enterprise IaC Governance: Keyless CI/CD Authentication, Remote State Isolation, Least Privilege IAM, and Automated Drift Detection
Question 947Question →

An enterprise architecture team is designing an automated CI/CD pipeline using Cloud Build to provision infrastructure resources via Terraform across multiple environments. The pipeline must execute automatically upon code commits, maintain security compliance under the principle of least privilege, and prevent state corruption during concurrent executions. Which design strategy should the team implement?

Show answer & explanation

Answer: Store the Terraform state file in a remote Cloud Storage bucket with object versioning and state locking enabled, and assign fine-grained predefined roles to a custom service account assigned to the Cloud Build trigger.

Answer

The team should store the Terraform state in a remote Cloud Storage bucket configured with state locking and object versioning, while executing Cloud Build triggers under a custom service account bound to fine-grained predefined IAM roles.
Centralizing Terraform state management within a Cloud Storage bucket that supports state locking and versioning protects against concurrency errors and state corruption. Pairing this backend with custom Cloud Build service accounts that use specific predefined IAM roles ensures that automated deployments operate with minimal required privileges.

Step-by-Step Solution

1
Configure remote backend storage for Infrastructure as Code (IaC)
Cloud Storage bucket created with state locking and object versioning enabled.
Prevents state corruption and concurrency race conditions during parallel CI/CD pipeline executions.
2
Enforce principle of least privilege for CI/CD execution identity
Custom service account provisioned with minimum necessary predefined IAM roles required for resource provisioning.
Avoids over-privileged primitive role grants and minimizes security blast radius.

Key Concept

CI/CD Pipeline Design for IaC Automation with Secure State Management and Least Privilege
Question 948Question →

A DevOps team is configuring Terraform to manage Google Cloud infrastructure for a new application environment. To prevent simultaneous deployments from causing state file corruption and concurrency conflicts, what is the Google Cloud recommended practice for managing the Terraform state backend?

Show answer & explanation

Answer: Configure a central Google Cloud Storage (GCS) bucket backend with object versioning enabled to support automatic state locking.

Answer

Configure a central Google Cloud Storage (GCS) bucket backend with object versioning enabled to support automatic state locking.
Configuring a Google Cloud Storage (GCS) bucket as a remote backend allows Terraform to utilize GCS object lock features to block concurrent updates while keeping historical versions of state for disaster recovery.

Step-by-Step Solution

1
Identify the primary operational requirement for multi-user Infrastructure as Code (IaC) deployment.
Recognize that concurrent executions require state locking and historical recovery capabilities.
Without state locking, simultaneous Terraform apply operations can cause race conditions and state corruption.
2
Evaluate Google Cloud backend options for Terraform.
Select Google Cloud Storage (GCS) as the official remote backend.
GCS provides native object locking via strong consistency and object versioning for rollback capabilities.

Key Concept

Terraform Remote Backend and State Locking in Google Cloud Storage
Question 949Question →

A financial services organization is implementing a CI/CD pipeline using Cloud Build to automate the deployment of multi-tier cloud infrastructure defined in Terraform. The security team requires that the pipeline strictly enforce least-privilege security controls and prevent credentials exposure when creating resources and deploying applications under specific workload service accounts. Which architectural approach should the cloud architect choose for the Cloud Build pipeline configuration?

Show answer & explanation

Answer: Configure Cloud Build to execute using a dedicated custom pipeline service account with specific resource permissions, and grant this pipeline service account the Service Account User role on the target runtime service accounts.

Answer

The optimal strategy is to run Cloud Build using a dedicated custom service account assigned minimal specific permissions, and grant that custom service account the Service Account User role (`roles/iam.serviceAccountUser`) on the target workload service accounts.
Running Cloud Build with a dedicated custom service account configured with granular, minimal permissions meets enterprise security compliance. Granting `roles/iam.serviceAccountUser` on specific target workload identities allows the pipeline service account to attach those identities to newly deployed resources (such as GKE nodes or Cloud Run services) without requiring administrative rights over service accounts or excessive primitive roles.

Step-by-Step Solution

1
Analyze security and governance requirements for CI/CD deployment execution.
Identified that least-privilege access and secure workload deployment require isolating pipeline execution credentials from target compute identities.
Default or overly permissive service accounts expose the environment to security risks and audit non-compliance.
2
Evaluate IAM role bindings required for CI/CD automation of compute and storage resources.
Determined that the `roles/iam.serviceAccountUser` role permits Cloud Build to attach specified target service accounts to resources without needing full administrative control over those identities.
This separation enforces least privilege and avoids the risks associated with primitive roles or key generation.
3
Verify state management strategy for Terraform within Cloud Build pipelines.
Confirmed that remote versioned Cloud Storage backends with state locking must be used rather than ephemeral local disk storage.
Remote state backends prevent concurrent pipeline executions from causing state corruption and loss of infrastructure tracking.

Key Concept

CI/CD Pipeline Security and Least-Privilege IAM Design with Cloud Build
Question 950Question →

A cloud platform team needs to provision a high-throughput Cloud Bigtable database environment for a real-time analytics application on Google Cloud. The deployment must comply with corporate security standards requiring Customer-Managed Encryption Keys (CMEK) for data at rest, and governance policies requiring application workload separation using App Profiles. In which sequence should the platform engineering team execute these provisioning steps to ensure successful deployment without authorization or dependency failures?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct provisioning order is: 1) Create the Cloud KMS KeyRing and CryptoKey, 2) Grant the Cloud Bigtable Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role, 3) Provision the Cloud Bigtable instance and cluster specifying the CMEK key URI, and 4) Create the Bigtable tables and configure App Profiles.
The deployment sequence must follow Google Cloud resource dependency and security authorization requirements. First, the Cloud KMS key must be created to obtain a valid resource path. Second, the service-managed Cloud Bigtable Service Agent account (`[email protected]`) must be granted the Cloud KMS CryptoKey Encrypter/Decrypter role so GCP can access the key. Third, the Cloud Bigtable instance and cluster are created using the KMS key URI. Finally, tables and App Profiles are deployed into the running instance to complete application onboarding.

Step-by-Step Solution

1
Create the Cloud KMS KeyRing and CryptoKey in the designated deployment region.
A valid KMS key resource identifier is instantiated.
Downstream IAM role assignments and resource encryption references depend on the existence of the KMS key.
2
Bind the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role to the Cloud Bigtable Service Agent on the CryptoKey.
The Bigtable service account gains permission to wrap and unwrap data encryption keys.
Attempting to create a CMEK-encrypted instance without granting this role first causes immediate provisioning failure during key validation.
3
Deploy the Cloud Bigtable instance and cluster referencing the CMEK key URI.
The parent database infrastructure is provisioned and encrypted.
Parent instance infrastructure must be fully provisioned before child objects such as tables and app profiles can be created.
4
Create Bigtable tables and set up App Profiles for application workload isolation.
Database tables and routing profiles become operational for client applications.
Child resources depend strictly on an existing, ready Cloud Bigtable instance.

Key Concept

Cloud Bigtable CMEK Provisioning Workflow and Resource Dependency Management
Question 951Question →

A global retail enterprise hosts its online storefront services on Google Kubernetes Engine (GKE) and stores all container build artifacts in Artifact Registry. The security compliance policy dictates that all container images must be continuously scanned for newly discovered OS and language package vulnerabilities upon storage, and any runtime container anomalies or out-of-band process executions on GKE nodes must be detected automatically without installing third-party host agents. Which architectural solution fulfills these security requirements with minimal operational overhead?

Show answer & explanation

Answer: Enable vulnerability scanning in Artifact Registry for continuous image analysis, and activate Security Command Center Premium to utilize Container Threat Detection and Event Threat Detection.

Answer

Enable vulnerability scanning in Artifact Registry for continuous image analysis, and activate Security Command Center Premium to utilize Container Threat Detection and Event Threat Detection.
Enabling Artifact Registry vulnerability scanning ensures automated continuous vulnerability discovery for stored container images. Combining this with Security Command Center (SCC) Premium provides built-in, agentless runtime threat detection (including Container Threat Detection and Event Threat Detection) for GKE clusters without requiring custom host agents or managing extra infrastructure.

Step-by-Step Solution

1
Identify container image scanning requirements
Artifact Registry vulnerability scanning provides automated, continuous scanning of container images for operating system and language-pack vulnerabilities upon push.
This satisfies the requirement for container build artifact vulnerability management with zero custom infrastructure management.
2
Identify agentless runtime threat detection requirements for GKE
Security Command Center (SCC) Premium includes Container Threat Detection and Event Threat Detection.
Container Threat Detection monitors GKE container audit logs and node memory in an agentless manner to flag suspicious binaries, reverse shells, or anomalous processes.
3
Synthesize the fully managed Google Cloud native security design
Combining Artifact Registry vulnerability scanning with SCC Premium Container Threat Detection satisfies both continuous image scanning and agentless runtime threat detection.
This approach minimizes operational overhead while maintaining strict adherence to enterprise security compliance standards.

Key Concept

Managed Vulnerability Scanning and Agentless Threat Detection
Question 952Question →

A global telehealth provider is translating its conceptual architectural design for an emergency vitals monitoring platform into a physical Google Cloud architecture. The logical design specifies three core requirements: real-time streaming ingestion of wearable device vitals, zero-infrastructure serverless microservices for data processing to minimize operational overhead, and a security perimeter preventing authorized users from copying Patient Health Information (PHI) to external Google Cloud projects. Which combination of Google Cloud services correctly maps to this physical architecture?

Show answer & explanation

Answer: Cloud Pub/Sub for streaming ingestion, Cloud Run for serverless microservices, Cloud Bigtable for time-series vitals storage, and VPC Service Controls for perimeter security.

Answer

Cloud Pub/Sub for streaming ingestion, Cloud Run for serverless microservices, Cloud Bigtable for time-series vitals storage, and VPC Service Controls for perimeter security.
The correct physical architecture maps conceptual streaming ingestion to Cloud Pub/Sub, serverless compute with zero cluster management to Cloud Run, high-throughput time-series metrics storage to Cloud Bigtable, and perimeter data exfiltration protection to VPC Service Controls.

Step-by-Step Solution

1
Map ingestion tier requirement to physical GCP service
Cloud Pub/Sub is selected for decoupled, real-time streaming ingestion of wearable device vitals with dynamic scaling.
Conceptual streaming telemetry requires high-throughput message ingestion without server management.
2
Map compute tier requirement to physical GCP service
Cloud Run is selected for stateless container execution without infrastructure management overhead.
The requirement specifies zero-infrastructure serverless microservices, making Cloud Run optimal over GKE.
3
Map storage tier and security perimeter requirements to physical GCP services
Cloud Bigtable is selected for scalable time-series telemetry storage, and VPC Service Controls is selected for perimeter security.
Cloud Bigtable handles high-write time-series data cost-effectively (unlike Cloud Spanner), while VPC Service Controls prevents data exfiltration that IAM alone cannot block.

Key Concept

Mapping conceptual architectural layers (ingestion, compute, storage, security) to physical GCP services based on operational, scale, and compliance constraints.
Question 953Question →

A enterprise security team requires a central CI/CD pipeline built on Cloud Build to provision infrastructure via Terraform and deploy containerized workloads onto a private Google Kubernetes Engine (GKE) cluster. The workload infrastructure and Cloud Storage bucket hosting the Terraform backend are isolated within a VPC Service Controls (VPC-SC) security perimeter. Pipeline workers run in a Cloud Build Private Pool peered to the target VPC. The pipeline fails during execution when attempting to modify GKE resources and interact with the remote Terraform backend. Which architectural modification correctly resolves the execution failure while adhering to Google Cloud security best practices and least privilege?

Show answer & explanation

Answer: Configure an Ingress policy in the VPC Service Controls perimeter allowing the Cloud Build service account access to Cloud Storage and GKE API services, grant `roles/iam.serviceAccountUser` on the runtime service account, and use a versioned, locked Cloud Storage backend for Terraform state.

Answer

Configure an explicit Ingress policy in the VPC Service Controls perimeter targeting the Cloud Build service account for Cloud Storage and GKE endpoints, grant the Service Account User role (`roles/iam.serviceAccountUser`) on the target compute/runtime service accounts, and manage Terraform state in a Cloud Storage bucket with object versioning and state locking enabled inside the perimeter.
The solution correctly addresses all security and functional requirements: updating the VPC Service Controls perimeter with an explicit Ingress rule enables the Cloud Build worker identity to communicate with protected GCP APIs (GKE and Cloud Storage); assigning `roles/iam.serviceAccountUser` respects the principle of least privilege required for workload deployment; and storing Terraform state in a versioned Cloud Storage backend within the perimeter prevents configuration drift while maintaining strict perimeter security.

Step-by-Step Solution

1
Analyze perimeter restriction failures
Identified that Cloud Build Private Pool execution requires explicit VPC Service Controls ingress/egress authorization rules or service perimeter membership to access resources protected inside the perimeter.
VPC-SC blocks requests to protected Google APIs (such as Cloud Storage state buckets and GKE control planes) even if standard IAM permissions are present.
2
Evaluate IAM privilege requirements
Determined that Cloud Build service accounts require `roles/iam.serviceAccountUser` to attach runtime service accounts to GKE resources, rather than broad administrative roles.
Principle of least privilege dictates granting impersonation/usage rights instead of full service account administration.
3
Validate IaC state management strategy
Confirmed that Infrastructure as Code state must reside in a protected, versioned Cloud Storage bucket with object locking.
Ephemeral runner storage causes state drift, loss, and concurrency issues in automated pipeline execution.

Key Concept

Secure Enterprise CI/CD Pipeline Integration with VPC Service Controls, IAM Least Privilege, and IaC State Governance
Question 954Question →

An organization is establishing baseline operational standards for managing Google Cloud resources using Terraform. The cloud engineering team needs to ensure state concurrency locking, state change history tracking, and safe automated deployments. Which two configurations or practices should the team implement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure a Google Cloud Storage (GCS) bucket as a remote backend for centralized state storage.; Enable Object Versioning on the Google Cloud Storage backend bucket.

Answer

The team should configure a Google Cloud Storage bucket as the remote backend and enable Object Versioning on that bucket.
Configuring a Cloud Storage backend ensures state file centralization with native locking capabilities, while enabling Object Versioning guarantees state file backup history and recovery options.

Step-by-Step Solution

1
Identify state locking and storage requirements for collaborative Infrastructure as Code workflows.
Centralizing state storage in Google Cloud Storage provides multi-user access control and automatic state locking.
Remote state management ensures developers and automated CI/CD pipelines work against a single source of truth without concurrent execution risks.
2
Determine the mechanism required to maintain historical state records.
Enabling Object Versioning on the backend Cloud Storage bucket enables tracking and rollback of state files.
Object Versioning keeps a detailed history of state file updates and guards against accidental deletion or corruption.

Key Concept

Centralized Terraform state management using Cloud Storage with Object Versioning
Question 955Question →

An enterprise architecture team is designing a Continuous Integration and Continuous Delivery (CI/CD) pipeline on Google Cloud using Cloud Build to build container images and execute deployments to Google Kubernetes Engine (GKE). To enforce strict enterprise security standards and the principle of least privilege throughout the build and deployment lifecycle, which TWO architectural practices should the team implement?

Select all that apply

Show answer & explanation

Answer: Execute Cloud Build triggers using a dedicated custom service account provisioned only with necessary fine-grained roles rather than using the default Cloud Build service account.; Grant the build pipeline's service account the Service Account User role (roles/iam.serviceAccountUser) on the target GKE runtime service account.

Answer

The team should execute Cloud Build triggers using a dedicated custom service account with minimal predefined roles, and grant that service account the Service Account User role on the target runtime service account.
Secure CI/CD architecture on GCP requires isolating build pipeline identities by attaching dedicated custom service accounts with fine-grained predefined roles to Cloud Build triggers. Furthermore, to deploy workloads safely, the build pipeline service account requires the Service Account User role on the specific runtime service account assigned to the GKE application pods.

Step-by-Step Solution

1
Identify identity management best practices for Cloud Build.
Using a dedicated custom service account ensures that pipeline permissions are limited strictly to what the build job requires, avoiding excessive permissions.
Default service accounts often hold broad default permissions that present a security risk if compromised.
2
Determine the necessary IAM permission model for deploying to GKE workloads.
The build pipeline requires impersonation rights over the workload's runtime identity via the roles/iam.serviceAccountUser role.
This allows the build runner to attach the runtime identity to GKE pods without granting the pipeline full administrative control over IAM resources.

Key Concept

Least Privilege Security Architecture for CI/CD Pipelines
Question 956Question →

A healthtech platform processes sensitive patient data across hybrid environments and is designing a deployment pipeline using Google Cloud native services. The pipeline must deploy containerized microservices to multiple private Google Kubernetes Engine (GKE) clusters across staging and production environments. The enterprise architecture board mandates strict data exfiltration prevention during the build phase and strict privilege separation so build workers cannot directly deploy workloads or alter cluster infrastructure. Which TWO architectural configurations should the team implement to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Execute Cloud Build jobs inside a Cloud Build Private Pool integrated with a VPC Service Controls security perimeter, granting the build service account minimal permissions to write artifacts to Artifact Registry.; Decouple delivery by utilizing Cloud Deploy pipelines where target service accounts manage cluster rollouts, ensuring Cloud Build lacks direct IAM credentials to administer the target GKE clusters.

Answer

The team should execute Cloud Build jobs in Private Pools within a VPC Service Controls perimeter while restricting artifact permissions, and use Cloud Deploy to separate release creation from GKE deployment execution privileges.
The correct strategy combines network isolation during compilation with role separation during deployment. Executing builds inside Cloud Build Private Pools attached to a VPC Service Controls perimeter blocks egress data exfiltration routes. Separating build tasks from deployment execution via Cloud Deploy ensures that build triggers do not maintain administrative privileges over private GKE clusters.

Step-by-Step Solution

1
Analyze build phase network security and data exfiltration constraints.
Standard Cloud Build runs on multi-tenant worker pools with default internet egress. Utilizing Cloud Build Private Pools peered into a VPC protected by VPC Service Controls prevents outbound exfiltration.
VPC Service Controls establishes a network perimeter around Google Cloud resources that IAM alone cannot enforce.
2
Establish separation of duties between Continuous Integration (CI) and Continuous Delivery (CD).
Delegating deployment orchestration to Cloud Deploy prevents Cloud Build from needing administrative cluster credentials or direct access to private GKE control planes.
Principle of least privilege requires that container image build tools cannot directly modify production workload states.

Key Concept

Secure CI/CD Pipeline Design with Cloud Build Private Pools, VPC Service Controls, and Cloud Deploy
Estimated Time:2m 0s
Question 957Question →

A multinational pharmaceutical company is migrating its legacy clinical trial data management platform to Google Cloud. During executive steering committee sessions, business leaders expressed deep concerns regarding operational disruption, security posture, and potential project launch delays caused by resource bottlenecks. The existing infrastructure team lacks extensive Google Cloud experience and is hesitant about changing operational workflows. To address stakeholder requirements and manage organizational change effectively while mitigating deployment risks, which TWO actions should the Lead Cloud Architect recommend? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Perform an early audit of projected resource requirements and submit requests for regional quota increases well ahead of scheduled migration phases.; Establish structured technical training programs for operational teams and transition permissions using principle-of-least-privilege predefined or custom IAM roles.

Answer

The Lead Cloud Architect should proactively request regional quota increases prior to deployment execution and implement structured team training alongside least-privilege predefined or custom IAM roles.
Proactively requesting quota increases ensures technical readiness and prevents launch delays, directly addressing business timeline concerns. Concurrently, delivering structured upskilling while implementing fine-grained custom or predefined IAM roles manages organizational change smoothly without exposing sensitive clinical data to security risks.

Step-by-Step Solution

1
Analyze business stakeholder requirements regarding timeline reliability and security compliance.
Identified key risks: capacity delays and operational disruption caused by team skill gaps or security violations.
Business stakeholders require guaranteed launch timelines and strong security governance during migration.
2
Evaluate infrastructure readiness and lead time constraints for Google Cloud resources.
Proactive regional quota increases prevent sudden provisioning errors during large-scale rollout.
Quota approvals can require lead time from Google Cloud support, making advance requests essential.
3
Formulate an organizational change management strategy focused on team enablement and least-privilege access.
Providing targeted training mitigates staff hesitation, while predefined/custom IAM roles preserve security.
Technical change management requires upskilling staff rather than compromising security with overly permissive roles.

Key Concept

Analyzing stakeholder needs and managing change through proactive resource quota planning and least-privilege governance enablement.
Question 958Question →

An operations team is preparing to deploy an updated revision of a web application on Google Cloud. To minimize risk, they want to route a small portion of live user traffic to the new revision first to observe error rates and latency before proceeding with a complete rollout. Which deployment strategy best fulfills this requirement?

Show answer & explanation

Answer: Canary deployment with incremental traffic splitting

Answer

Canary deployment with incremental traffic splitting is the correct choice because it exposes the new software version to a small subset of production traffic to test operational metrics before full rollout.
A canary deployment routes a small percentage of live production traffic (such as 5% or 10%) to a newly released application revision while keeping the majority of traffic on the stable revision. This allows monitoring metrics like latency and HTTP error rates under real conditions before completing the rollout.

Step-by-Step Solution

1
Identify the deployment requirement
The requirement specifies sending a small fraction of live user traffic to a new software release to monitor stability prior to full deployment.
Understanding whether full cutover, rolling update, or canary testing is required forms the baseline for selecting the deployment pattern.
2
Evaluate deployment strategies against the requirement
Canary deployment natively supports routing a configured percentage of live user traffic to a target release.
Canary releases provide real-user testing under low-risk conditions, allowing automated or manual rollback if error rates increase.

Key Concept

Canary Deployment Strategy
Question 959Question →

A central platform engineering team is establishing automated infrastructure management and software deployment patterns across multiple Google Cloud projects. The team currently relies on long-lived service account JSON keys exported to external CI/CD pipelines, stores Terraform state files locally on runner build agents, and grants broad administrative permissions to prevent pipeline failures during resource creation. You are advising the development and operations teams on how to re-architect their deployment pipeline workflow to adhere to Google Cloud security and operational best practices while enforcing least privilege and preventing state corruption. Which TWO recommendations should you provide?

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity Federation for the external CI/CD pipeline to authenticate to Google Cloud using short-lived tokens instead of service account keys.; Migrate Terraform state files to a Cloud Storage backend with object versioning and state locking enabled using Cloud Spanner or Cloud Storage native locks.

Answer

The correct recommendations are configuring Workload Identity Federation for external CI/CD pipelines to eliminate service account JSON keys, and migrating Terraform state management to a Cloud Storage remote backend with versioning and state locking.
Configuring Workload Identity Federation replaces vulnerable long-lived service account JSON keys with short-lived, auto-expiring OIDC credentials for external pipelines. Moving Terraform state to a remote Cloud Storage bucket with object versioning and state locking prevents concurrent pipeline runs from corrupting infrastructure state and ensures state history is safely maintained.

Step-by-Step Solution

1
Analyze authentication requirements for external operations tools.
Identify that exporting and storing service account JSON keys in external CI/CD tools creates a security liability. Using Workload Identity Federation allows short-lived token exchange via OIDC.
Google Cloud security best practices explicitly recommend eliminating long-lived service account keys in favor of federated identities.
2
Evaluate Infrastructure as Code state management strategy.
Determine that local or git-based state files lead to concurrency conflicts, corruption, and secret exposure. Cloud Storage backends provide native encryption, state locking, and object versioning.
Centralized, locked remote state backends guarantee reliable and safe concurrent IaC executions across dev and ops teams.
3
Assess IAM permissions and role assignment practices.
Reject broad primitive roles (such as Project Owner) and administrative service account roles in favor of fine-grained predefined or custom roles mapped to specific deployment actions.
Adhering to least privilege reduces the blast radius of compromised deployment credentials.

Key Concept

Advising Development and Operation Teams on Secure CI/CD Automation and IaC State Governance
Question 960Question →

An autonomous drone logistics company organizes its Google Cloud resource hierarchy into regional folders under a top-level organization node. A security team needs to grant a regional operations team permission to manage Compute Engine virtual machines (deploy, start, stop) and attach existing service accounts to these VMs within the 'North-America-Ops' folder. The solution must strictly adhere to the principle of least privilege and eliminate administrative access over service account configurations. Which TWO IAM configuration steps should the security team implement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Bind the Compute Instance Admin (v1) predefined role (roles/compute.instanceAdmin.v1) to the regional operations team's Google Group at the 'North-America-Ops' folder level.; Bind the Service Account User role (roles/iam.serviceAccountUser) to the regional operations team's Google Group on the specific service accounts assigned to the workload.

Answer

The security team should grant the Compute Instance Admin (v1) role at the regional folder level and grant the Service Account User role on the specific workload service accounts.
To satisfy least privilege while managing Compute Engine instances across multiple projects in a folder, the Compute Instance Admin (v1) role should be bound at the folder level. To allow binding specific service accounts to instances without granting permission to manage service account IAM policies or keys, the Service Account User role must be granted on those specific service accounts.

Step-by-Step Solution

1
Determine the minimal predefined compute role scoped to the folder level
Compute Instance Admin (v1) permits VM management across all child projects under the target folder.
Folder-level binding leverages IAM resource hierarchy inheritance while enforcing scoped instance management.
2
Identify the role required to bind service accounts to Compute Engine instances
Service Account User (roles/iam.serviceAccountUser) provides the necessary permission (iam.serviceAccounts.actAs) without administrative privileges.
Least privilege requires restricting administrative capabilities over service account key and policy management.

Key Concept

Resource hierarchy inheritance and fine-grained service account delegation using standard IAM roles
PreviousPage 48 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin