Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 981Question →

An organization is operating three Virtual Private Cloud (VPC) networks in Google Cloud: vpc-frontend, vpc-hub, and vpc-backend. To centralize administration, vpc-frontend is peered with vpc-hub, and vpc-backend is also peered with vpc-hub. Compute Engine instances in vpc-frontend need to communicate directly with internal workloads in vpc-backend. Network administrators observe that traffic sent from vpc-frontend to vpc-backend is dropped, even though both networks are successfully peered with vpc-hub. Which network topology modification should be implemented to enable connectivity between vpc-frontend and vpc-backend?

Show answer & explanation

Answer: Establish a direct VPC Network Peering connection between vpc-frontend and vpc-backend.

Answer

Establish a direct VPC Network Peering connection between vpc-frontend and vpc-backend.
VPC Network Peering in Google Cloud is explicitly non-transitive. Traffic originating in one peered network cannot traverse a intermediate network to reach a third network. To allow direct communication between two spoke VPC networks, an explicit direct VPC Network Peering connection must be established between them.

Step-by-Step Solution

1
Identify the routing constraint in Google Cloud VPC Network Peering.
VPC Network Peering is strictly non-transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic from VPC A cannot reach VPC C through VPC B.
Google Cloud VPC routing rules suppress incoming peered traffic from being re-transmitted out through another peering interface.
2
Evaluate potential solutions to allow communication between vpc-frontend and vpc-backend.
Creating a direct VPC Network Peering link between vpc-frontend and vpc-backend allows both networks to exchange subnet routes directly.
Direct peering satisfies the non-transitive requirement while maintaining low-latency, internal Google network routing without performance bottlenecks.

Key Concept

VPC Network Peering Non-Transitivity
Question 982Question →

An organization is deploying a globally distributed transactional application requiring multi-region relational database storage with strong consistency across continents. Additionally, database audit logs must be exported to an automated infrastructure-as-code (IaC) provisioned object storage bucket, complying with cloud-native key management governance that avoids holding raw key material. Which TWO architectural and provisioning actions should the platform team take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Provision a Cloud Spanner instance configured with a multi-region instance configuration to handle global relational transactions.; Configure Customer-Managed Encryption Keys (CMEK) managed via Cloud KMS to protect the Cloud Storage bucket holding audit logs.

Answer

The team should provision a multi-region Cloud Spanner instance for globally consistent relational data and configure Customer-Managed Encryption Keys (CMEK) via Cloud KMS for protecting the Cloud Storage log bucket.
Provisioning a multi-region Cloud Spanner instance addresses the need for globally distributed, strongly consistent relational transactions. Configuring Customer-Managed Encryption Keys (CMEK) via Cloud KMS ensures full key management control over the Cloud Storage log bucket without exposing raw cryptographic keys in IaC code.

Step-by-Step Solution

1
Evaluate global relational database requirements.
Identify Cloud Spanner multi-region setup as the appropriate managed GCP service for global scale and strong consistency.
Cloud Spanner handles external consistency across geographic regions at enterprise scale.
2
Select the appropriate encryption key management approach for object storage.
Implement Customer-Managed Encryption Keys (CMEK) backed by Cloud KMS.
CMEK allows organization key management compliance without the operational risk of managing raw CSEK material in codebase files.

Key Concept

Multi-region database selection and secure storage bucket encryption provisioning
Question 983Question →

An autonomous mobility company processes real-time vehicle telemetry and operates customer routing APIs on Google Cloud across multiple projects under a unified Cloud Billing Account. The routing API experiences steady, highly predictable traffic year-round, whereas telemetry processing experiences extreme, unpredictable throughput spikes during sudden weather events and peak commuting hours. The finance team requires a FinOps governance framework that minimizes overall operational expenditure, avoids financial commitment risk for unpredictable workloads, and automates cost control enforcement. Which strategy should the Cloud Architect recommend to optimize cost efficiency and FinOps governance?

Show answer & explanation

Answer: Apply Spend-Based Flexible Committed Use Discounts (CUDs) at the Cloud Billing Account level for baseline compute and database usage, leverage Cloud Run request-driven scaling for telemetry processing bursts, and configure Organization-level budgets with Pub/Sub notifications for automated cost governance.

Answer

Apply Spend-Based Flexible Committed Use Discounts (CUDs) at the Cloud Billing Account level for baseline compute and database usage, leverage Cloud Run request-driven scaling for telemetry processing bursts, and configure Organization-level budgets with Pub/Sub notifications for automated cost governance.
The correct strategy combines Spend-Based Flexible Committed Use Discounts (CUDs) at the Cloud Billing Account level to cover predictable baseline spend across projects with request-based serverless autoscaling (Cloud Run) for unpredictable spikes. Furthermore, binding Organization-level Cloud Budgets to Pub/Sub enables automated FinOps remediation without operational or security compromises.

Step-by-Step Solution

1
Analyze workload predictability and separate steady-state baseline consumption from bursty workloads.
Identified steady API traffic suitable for commitments and unpredictable telemetry processing requiring dynamic scaling.
Applying long-term financial commitments to unpredictable workloads causes over-commitment waste, while paying on-demand rates for steady baselines wastes potential discount opportunities.
2
Select appropriate commitment models and serverless scaling components for each workload profile.
Selected Flexible CUDs across the billing account for steady baseline spend and Cloud Run serverless autoscaling for burst telemetry.
Flexible CUDs apply hourly spend discounts across regions and compute types without locking into specific machine specs, providing high efficiency and low commitment risk.
3
Implement automated organization-wide FinOps governance controls.
Configured organization-level Cloud Budgets wired to Pub/Sub topics and Cloud Functions for automated budget enforcement.
Programmatic budget alerts prevent cost overruns without relying on risky, manual administrative interventions.

Key Concept

FinOps Cost Optimization via Flexible CUDs and Automated Governance Controls
Question 984Question →

An enterprise logistics company migrated its fleet routing microservices to Google Cloud under tight deadlines. A post-migration technical debt assessment reveals two major risks: deployment pipelines rely on local Terraform state files stored on individual developer workstations, and the continuous deployment service accounts have been granted the project Owner primitive role to bypass permission errors. Which TWO architecture refactoring steps should you implement to mitigate this technical debt and enforce infrastructure governance? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Configure a Remote Backend using a Google Cloud Storage bucket with object versioning enabled and strict IAM permissions for state storage.; Replace primitive project Owner roles on deployment service accounts with least-privilege predefined or custom IAM roles scoped strictly to required infrastructure resources.

Answer

The correct architecture refactoring steps are configuring a Cloud Storage remote backend with object versioning for central Terraform state management, and replacing primitive Owner roles on continuous deployment service accounts with granular, least-privilege IAM roles.
Migrating to a Cloud Storage remote backend with object versioning solves state file concurrency conflicts and durability risks. Concurrently, replacing primitive project Owner roles with least-privilege predefined or custom IAM roles establishes robust security governance and eliminates privilege escalation vulnerabilities.

Step-by-Step Solution

1
Address IaC state management technical debt
Provision a secure Cloud Storage bucket configured with state locking and object versioning, moving local state to a managed remote backend.
Centralizing Terraform state prevents state drift, concurrency collisions, and loss of state file assets across isolated developer environments.
2
Remediate IAM security technical debt
Audit the exact permissions required by CI/CD pipelines and replace the primitive Owner role with fine-grained custom or predefined roles.
Removing primitive roles mitigates risk of privilege escalation and enforces least privilege access across deployment automation.

Key Concept

Technical Debt Mitigation for Infrastructure as Code and Security Governance
Question 985Question →

An organization is architecting an enterprise-wide CI/CD pipeline on Google Cloud to manage both infrastructure deployment using Terraform and microservice releases to private Google Kubernetes Engine (GKE) clusters across multiple isolated projects. The architecture must enforce strict security and compliance controls: build tasks must execute in a fully private network environment without internet exposure to prevent data exfiltration, infrastructure state must be protected against concurrency conflicts and corruption, and administrative permissions must strictly comply with the principle of least privilege. Which combination of GCP CI/CD toolchain configuration and architecture design satisfies all security and operational requirements?

Show answer & explanation

Answer: Execute Cloud Build build jobs using Cloud Build Private Pools attached to a peered VPC network within a VPC Service Controls perimeter. Maintain Terraform state in a Cloud Storage backend with object versioning and state locking enabled, and grant the pipeline service account fine-grained resource roles along with roles/iam.serviceAccountUser on target workload service accounts.

Answer

Execute Cloud Build build jobs using Cloud Build Private Pools attached to a peered VPC network within a VPC Service Controls perimeter. Maintain Terraform state in a Cloud Storage backend with object versioning and state locking enabled, and grant the pipeline service account fine-grained resource roles along with roles/iam.serviceAccountUser on target workload service accounts.
The solution utilizing Cloud Build Private Pools inside a VPC Service Controls perimeter provides complete network isolation without public IP exposure. Using a Cloud Storage backend configured with state locking and object versioning ensures concurrent Terraform executions do not corrupt state files. Finally, assigning fine-grained predefined roles paired with the Service Account User role enforces strict least privilege without granting administrative control over service accounts.

Step-by-Step Solution

1
Establish secure network execution environment
Cloud Build Private Pools peered to a private VPC within a VPC Service Controls perimeter block internet exposure and prevent unauthorized data egress.
Standard Cloud Build pools run in multi-tenant environments without native VPC access, making Private Pools necessary for private GKE cluster interaction and VPC Service Controls enforcement.
2
Configure secure IaC state management
Using Google Cloud Storage as a remote Terraform backend with object versioning and state locking enabled ensures concurrency control and disaster recovery.
Local or unversioned state storage leads to race conditions, state drift, and vulnerability to corruption during continuous integration pipelines.
3
Apply least-privilege IAM controls for pipeline execution
Granting granular roles and roles/iam.serviceAccountUser allows the pipeline service account to attach workload identities to GKE resources without full administrative access.
Granting primitive roles or service account admin rights creates excessive permissions and risks privilege escalation.

Key Concept

Enterprise Secure CI/CD Architecture with Cloud Build, Private Pools, VPC SC, and IaC State Management
Estimated Time:3m 0s
Question 986Question →

A global healthcare diagnostics company recently completed a rapid cloud migration of its patient telemetry monitoring platform to Google Cloud. A post-migration architecture audit revealed significant technical debt: infrastructure modifications are frequently executed directly through the GCP Console resulting in configuration drift, and application service accounts retain broad primitive Owner permissions to avoid deployment friction. Which strategy should the cloud architect recommend to mitigate this technical debt while establishing long-term governance?

Show answer & explanation

Answer: Import existing GCP resources into a version-controlled Infrastructure as Code state managed in Cloud Storage with object locking, replace primitive permissions with fine-grained predefined roles following least privilege, and enforce all changes through an automated CI/CD deployment pipeline.

Answer

Import existing GCP resources into a version-controlled Infrastructure as Code state managed in Cloud Storage with object locking, replace primitive permissions with fine-grained predefined roles following least privilege, and enforce all changes through an automated CI/CD deployment pipeline.
The correct answer systematically addresses both security and operational debt by locking infrastructure configurations into IaC backed by centralized state storage, restricting deployment access strictly to CI/CD pipelines, and applying least-privilege IAM roles to eliminate broad administrative access.

Step-by-Step Solution

1
Identify accumulated cloud technical debt areas
Discovered manual console modifications (configuration drift) and overly broad primitive IAM roles on application service accounts.
Technical debt assessment requires pin-pointing operational risk and security exposure in the current architecture.
2
Establish Infrastructure as Code (IaC) governance
Import resources into IaC state stored centrally in Cloud Storage with state locking and versioning, enforcing deployment strictly through automated CI/CD pipelines.
Automated pipelines eliminate manual console drift and establish auditable, reproducible deployment practices.
3
Remediate IAM security technical debt
Revoke primitive Owner roles and grant minimal, task-specific predefined or custom IAM roles.
Enforcing the principle of least privilege limits the impact of compromised service accounts and satisfies compliance requirements.

Key Concept

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

An enterprise DevOps team is setting up an automated CI/CD pipeline using Cloud Build to provision cloud infrastructure via Terraform. To adhere to security governance, the build execution must run using a dedicated deployment service account with minimal IAM privileges rather than elevated project-level permissions. Which IAM role configuration should you implement to allow the Cloud Build service account to act as the deployment service account?

Show answer & explanation

Answer: Grant the Service Account User role (roles/iam.serviceAccountUser) to the Cloud Build service account on the deployment service account resource.

Answer

Grant the Service Account User role (roles/iam.serviceAccountUser) to the Cloud Build service account on the specific deployment service account resource.
To allow a CI/CD build runner such as Cloud Build to impersonate a dedicated deployment identity, the Cloud Build service account must be granted the Service Account User role directly on the deployment service account resource. This provides the minimum privilege required to execute jobs under that identity.

Step-by-Step Solution

1
Determine the identity initiating the pipeline execution and the target identity needed for deployment.
Cloud Build runs using its service account, which needs to attach or act as a dedicated deployment service account.
Separating build triggers from execution service accounts enforces security boundary controls.
2
Identify the minimum necessary role for service account impersonation.
The Service Account User role (`roles/iam.serviceAccountUser`) allows an identity to impersonate or attach a specified service account.
This role grants usage permissions without providing administrative controls over the service account lifecycle.
3
Apply the role binding at the specific service account resource level.
The Cloud Build service account is granted `roles/iam.serviceAccountUser` directly on the target deployment service account.
Binding at the resource level restricts usage rights exclusively to the designated service account.

Key Concept

Least Privilege IAM Service Account Impersonation in Pipeline Automation
Question 988Question →

A DevOps team is establishing a secure continuous delivery pipeline on Google Cloud to deploy microservices to Google Kubernetes Engine (GKE) using Cloud Build, Artifact Registry, Binary Authorization, and Cloud Deploy. Place the operational steps of the deployment pipeline in the correct chronological order from initial code commit to final production deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order of the CI/CD pipeline execution is: (1) Push source code to Git to trigger Cloud Build, (2) Execute tests, build the container image, and push it to Artifact Registry, (3) Perform vulnerability scanning and sign a Binary Authorization attestation, (4) Create a Cloud Deploy release to deploy the workload to the staging cluster under Binary Authorization policy enforcement, and (5) Promote the release rollout to the production cluster upon validation.
The deployment sequence follows secure software supply chain best practices on Google Cloud: Source control trigger -> Cloud Build artifact generation -> Binary Authorization attestation signing -> Staging deployment via Cloud Deploy -> Production promotion.

Step-by-Step Solution

1
Trigger continuous integration upon code commit.
Cloud Build pipeline execution is initiated by Git repository webhook integration.
CI pipelines begin with source code updates to validate changes early.
2
Build and store the container image.
Container image is compiled, verified via unit tests, and published to Google Cloud Artifact Registry.
Centralizing artifacts in Artifact Registry is required before vulnerability scanning or deployment can take place.
3
Enforce supply chain security via digital attestations.
Binary Authorization attestation is generated using Cloud KMS after security checks pass.
Binary Authorization policy mandates that container images carry valid signed attestations prior to cluster deployment.
4
Deploy workload to staging via Cloud Deploy.
Cloud Deploy creates a release and provisions the deployment into the staging GKE cluster.
Deploying to non-production environments first ensures runtime stability and validation before production promotion.
5
Promote release to production target.
Cloud Deploy executes the production deployment rollout.
Promoting through predefined target delivery pipelines guarantees progressive and reliable release management.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Design
Question 989Question →

A financial services organization is preparing to deploy a core transaction processing workload into a newly provisioned Google Cloud project. The architecture requires provisioning 250 Compute Engine N2 instances totaling 1,000 vCPUs in the `us-east4` region. During automated pre-deployment validation, the Infrastructure as Code (IaC) pipeline fails, reporting that the requested vCPU count exceeds default project limits. Which action should the Cloud Architect take to resolve this deployment blocker?

Show answer & explanation

Answer: Submit a regional quota increase request for N2 vCPUs in the us-east4 region via the Google Cloud Console or Quotas API prior to running the deployment pipeline.

Answer

Submit a regional quota increase request for N2 vCPUs in the us-east4 region via the Google Cloud Console or Quotas API prior to running the deployment pipeline.
Submitting a regional vCPU quota increase request directly addresses capacity enforcement in Google Cloud. Google Cloud enforces quotas on Compute Engine resources (such as vCPUs per machine series per region) to manage infrastructure capacity. When workload requirements exceed standard default project limits, an explicit request must be submitted via the Cloud Console or IAM/Quotas API before deployment.

Step-by-Step Solution

1
Identify the cause of the deployment failure
Recognize that the requested vCPU capacity exceeds default Google Cloud regional quota limits for the N2 machine family in `us-east4`.
GCP projects start with default quota allocations to prevent accidental over-provisioning and resource exhaustion.
2
Evaluate the appropriate GCP management mechanism
Determine that resource limits are controlled via Quotas rather than IAM permissions, CUD billing contracts, or IaC state configurations.
Quotas strictly enforce operational bounds independently of IAM roles or billing discount structures.
3
Formulate the proactive resolution step
Request an increase for the regional N2 vCPU quota in `us-east4` through the Cloud Console or Quotas API.
Proactive quota pre-provisioning ensures necessary capacity is allocated and approved before executing large-scale automated deployments.

Key Concept

Proactive Quota Management and Planning
Question 990Question →

A software development team is building a service that publishes and consumes messages using Google Cloud Pub/Sub. To facilitate fast offline testing without incurring cloud resource charges, a developer starts the Pub/Sub emulator locally using the command `gcloud beta emulators pubsub start`. Which environment variable must be set in the local application environment to ensure the Google Cloud Client Libraries automatically route requests to the local emulator instead of live GCP endpoints?

Show answer & explanation

Answer: PUBSUB_EMULATOR_HOST set to the host and port of the running emulator (e.g., localhost:8085)

Answer

The environment variable PUBSUB_EMULATOR_HOST must be set to the emulator's host and port address (for example, localhost:8085).
Google Cloud Pub/Sub client libraries automatically check for the presence of the PUBSUB_EMULATOR_HOST environment variable upon instantiation. When this variable contains a host and port (such as localhost:8085), the SDK routes all publisher and subscriber calls to the local emulator, bypassing authentication requirements and remote API calls.

Step-by-Step Solution

1
Identify the mechanism used by Google Cloud Client Libraries to detect local emulators.
Google Cloud Client Libraries for Pub/Sub check for specific host environment variables during initialization.
Emulators mimic GCP service endpoints locally so applications can run integration tests without internet access or GCP credentials.
2
Select the correct environment variable for the Cloud Pub/Sub emulator.
The standard variable name defined by GCP SDKs is PUBSUB_EMULATOR_HOST.
Defining PUBSUB_EMULATOR_HOST forces the client library to substitute production API endpoints with the specified local host and port.

Key Concept

Configuring Cloud Emulators for Local Testing
Estimated Time:45s
Question 991Question →

An enterprise platform engineering team is preparing to automate application deployment pipelines using an external CI/CD system to provision infrastructure across Google Cloud projects using Terraform and deploy microservices to Google Kubernetes Engine (GKE). You are advising the development and operations teams on security, state management, and operational release procedures. The solution must adhere to the principle of least privilege, protect deployment integrity, and minimize operational overhead. Which TWO recommendations should you provide to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity Federation to authenticate external CI/CD pipeline runners using short-lived credentials, and grant the pipeline service account the Service Account User role (roles/iam.serviceAccountUser) only on specific deployment service accounts.; Store Terraform state files in a central Cloud Storage bucket with Object Versioning enabled and uniform bucket-level access enforced to manage infrastructure state safely.

Answer

The correct recommendations are to configure Workload Identity Federation with fine-grained Service Account User permissions for external CI/CD runners, and to store Terraform state files in a Cloud Storage bucket configured with Object Versioning and uniform bucket-level access.
Configuring Workload Identity Federation allows external pipeline runners to authenticate securely without persistent service account keys, while restricting permissions to the Service Account User role on specific target accounts maintains least privilege. Additionally, using Cloud Storage with Object Versioning and uniform bucket-level access for Terraform remote state provides state locking, concurrency control, and resilience against state corruption.

Step-by-Step Solution

1
Evaluate authentication and credential management for external CI/CD pipelines.
Identify that long-lived service account keys present security risks, whereas Workload Identity Federation provides secure short-lived token exchange.
Eliminating static service account keys enforces cloud security best practices.
2
Evaluate identity and access permissions for deployment execution.
Determine that assigning roles/iam.serviceAccountUser scoped to specific workload service accounts follows least privilege, whereas primitive roles like Editor grant dangerous, excessive access.
Least privilege access prevents unauthorized modifications to surrounding infrastructure.
3
Evaluate Infrastructure as Code (IaC) state management strategy.
Determine that Cloud Storage backends supporting locking, Object Versioning, and uniform access prevent race conditions and state corruption, whereas git repository state storage introduces corruption and credential leakage risks.
Centralized remote backends with locking are required for reliable, collaborative Terraform execution.

Key Concept

Best practices for advising DevOps teams on GCP security integration, Workload Identity Federation, and secure Infrastructure as Code state management.
Estimated Time:2m 0s
Question 992Question →

A global logistics provider is establishing an automated testing and validation procedure for a critical order-processing engine deployed on Google Cloud. The deployment pipeline uses Infrastructure as Code (IaC) to provision regional GKE clusters and virtual networking resources. The lead architect must ensure the testing procedure automatically validates infrastructure availability constraints and state safety without compromising cluster security or least privilege access. Which TWO validation practices should be incorporated into the automated deployment procedure? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Include an automated pre-flight step in the deployment pipeline that queries Google Cloud Quotas APIs to verify regional resource quotas prior to executing IaC provisioning.; Configure the IaC deployment pipeline to store state files in a remote Cloud Storage bucket with Object Versioning and state locking enabled.

Answer

The correct validation practices are to include an automated pre-flight quota check against Google Cloud Quotas APIs prior to provisioning resources, and to store IaC state files in a remote Cloud Storage bucket with Object Versioning and state locking enabled.
Automating quota verification using Cloud Quotas APIs prevents deployment failures from unrequested quota limits, while using Cloud Storage with versioning and state locking protects IaC state integrity during testing runs.

Step-by-Step Solution

1
Analyze deployment validation requirements for quota capacity and infrastructure state safety.
Identified the need to prevent resource allocation failures and avoid Terraform state corruption during automated testing.
Large-scale infrastructure updates fail at runtime if quota limits are exceeded or if concurrent pipeline runs overwrite unversioned local state.
2
Evaluate the practice of automated quota verification.
Querying Cloud Quotas APIs pre-flight ensures sufficient regional quota before initiating resource deployment.
Failing to request or verify quotas in advance leads to mid-deployment failures and incomplete provisioning.
3
Evaluate IaC state backend management.
Configuring Cloud Storage with Object Versioning and locking provides safe concurrent state management for automated validation workflows.
Local unversioned state files lead to concurrency lock failures and state corruption across CI/CD execution environments.
4
Evaluate security constraints around private GKE access and IAM role assignment.
Confirmed that disabling master authorized networks exposes private clusters, and assigning Service Account Admin grants excessive rights.
Private GKE cluster endpoints should be accessed via internal runners or proxy bastions, and pipelines only require the Service Account User role for identity impersonation.

Key Concept

Developing automated testing procedures for infrastructure provisioning, quota validation, and state isolation in GCP CI/CD pipelines.
Question 993Question →

A financial analytics firm is moving internal auditing data to Google Cloud Storage. Company security policy mandates that encryption keys must be generated and managed inside Google Cloud hardware security modules (HSMs), key rotation must be controlled via policy, and service access must follow the principle of least privilege without granting administrative privileges over key management. Which encryption and key management strategy should you implement?

Show answer & explanation

Answer: Generate a Customer-Managed Encryption Key (CMEK) using Cloud KMS backed by Cloud HSM, and grant the Cloud Storage Service Agent the roles/cloudkms.cryptoKeyEncrypterDecrypter role on the key.

Answer

Generate a Customer-Managed Encryption Key (CMEK) using Cloud KMS backed by Cloud HSM, and grant the Cloud Storage Service Agent the roles/cloudkms.cryptoKeyEncrypterDecrypter role on the key.
The correct approach uses Customer-Managed Encryption Keys (CMEK) created in Cloud KMS with Cloud HSM protection. Assigning the predefined role `roles/cloudkms.cryptoKeyEncrypterDecrypter` to the Cloud Storage service agent strictly grants necessary cryptographic access without granting key administration rights, fulfilling both HSM key management and least privilege requirements.

Step-by-Step Solution

1
Analyze compliance and operational requirements
Identified the need for GCP-hosted HSM key management (CMEK/Cloud HSM) and automated policy-driven rotation without managing raw key material on-premises.
CMEK integrated with Cloud HSM satisfies mandatory hardware security and key management constraints within GCP.
2
Determine least-privilege IAM permissions for service integration
Selected the predefined role roles/cloudkms.cryptoKeyEncrypterDecrypter for the Cloud Storage service agent.
Granting specific cryptographic roles ensures the storage service can encrypt/decrypt objects without inheriting key management or administrative permissions.

Key Concept

Customer-Managed Encryption Keys (CMEK) with Cloud HSM provide hardware-backed key lifecycle management while enabling least-privilege access via granular IAM roles like CryptoKey Encrypter/Decrypter.
Question 994Question →

A platform engineering team is configuring automated infrastructure provisioning for a single-region transactional order processing system. The database must support standard relational SQL capabilities, provide automatic multi-zone failover within the region, and enforce data encryption at rest using keys rotated via Google Cloud KMS. Furthermore, the Infrastructure as Code (IaC) pipeline managed by multiple engineers must prevent concurrent state modifications and state corruption. Which architecture and provisioning setup fulfills these operational requirements?

Show answer & explanation

Answer: Provision a Cloud SQL instance configured for Regional High Availability with Customer-Managed Encryption Keys (CMEK), using a Cloud Storage backend with object versioning and state locking for Terraform state management.

Answer

Provision a Cloud SQL instance configured for Regional High Availability with Customer-Managed Encryption Keys (CMEK), using a Cloud Storage backend with object versioning and state locking for Terraform state management.
Cloud SQL Regional High Availability fulfills standard relational database requirements in a single region with automated zonal failover. Using Customer-Managed Encryption Keys (CMEK) allows key integration with Cloud KMS, fulfilling centralized rotation compliance. Enabling object versioning and state locking on the Cloud Storage backend ensures state integrity and concurrency protection for Infrastructure as Code automation.

Step-by-Step Solution

1
Select database service according to architectural scope
Cloud SQL Regional HA is selected over Cloud Spanner because the system is strictly single-region and requires standard relational database capabilities without multi-region global scale overhead.
Cloud SQL provides automatic cross-zone failover within a single region at optimal cost and complexity.
2
Choose encryption key strategy based on key management requirements
Customer-Managed Encryption Keys (CMEK) integrated with Cloud KMS are selected rather than Customer-Supplied Encryption Keys (CSEK).
CMEK allows organization control over key lifecycle and rotation policies within GCP Cloud KMS without requiring management of raw key bytes.
3
Configure backend state storage for IaC automation
Cloud Storage bucket backend is configured with object versioning and state locking enabled.
State locking prevents race conditions during concurrent execution, and versioning enables recovery in case of accidental corruption.

Key Concept

Provisioning Cloud SQL with CMEK and managing IaC state with lock-enabled Cloud Storage backends.
Question 995Question →

An enterprise investment bank is modernizing its portfolio risk analytics platform on Google Cloud. You are serving as the Lead Cloud Architect responsible for translating business requirements into a complete cloud solution architecture. In which chronological order should you execute the architectural design stages, from high-level domain mapping down to concrete GCP resource specification?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order follows the standard architecture design lifecycle: (1) Establish the Conceptual Architecture to capture business capabilities, (2) Develop the Logical Architecture to define functional components and data flows, (3) Map the Logical Architecture to Physical Architecture by selecting specific Google Cloud services, and (4) Detail the Physical Architecture implementation with concrete network, security, and resource parameters.
The standard architectural design process progresses systematically from business intent to concrete technical execution: Conceptual Architecture defines high-level business domain capabilities; Logical Architecture defines technology-neutral functional tiers and data flows; Physical Architecture service mapping selects specific GCP products; and Physical Architecture detailing establishes exact operational and security parameters for deployment.

Step-by-Step Solution

1
Identify the conceptual design phase.
Establish high-level business capabilities without technology lock-in.
Architecture starts with understanding business goals and domain boundaries at the conceptual level.
2
Identify the logical design phase.
Define technology-agnostic service tiers and interaction patterns.
Logical architecture structures the solution into functional modules and data flows based on conceptual requirements.
3
Identify the physical service selection phase.
Map logical tiers to concrete GCP services.
Physical design translates logical requirements into specific GCP products that satisfy SLA, throughput, and operational needs.
4
Identify the physical parameterization phase.
Configure concrete infrastructure parameters like subnet CIDRs, IAM bindings, and CMEK settings.
Final deployment readiness requires explicit configuration of network topologies, access rules, and security keys.

Key Concept

Sequential architectural translation from conceptual model (business focus) to logical model (functional tiers) to physical model (GCP product selection and explicit parameterization).
Question 996Question →

A digital B2B SaaS company operates two core microservices on Google Cloud: a synchronous Payment Processing Gateway that directly processes customer payments, and an asynchronous PDF Invoice Generator that produces monthly billing summaries. The business leadership requires technical service levels to accurately reflect financial business impact without incurring unnecessary operational overhead or alert fatigue. Which TWO architectural and operational strategies best align the technical SLOs and SLIs with these business objectives?

Select all that apply

Show answer & explanation

Answer: Define the Payment Processing Gateway Service Level Indicator (SLI) as the proportion of successful HTTP 2xx requests over total valid requests, and establish a high-stringency Service Level Objective (SLO) monitored via multi-window error budget burn-rate alerting.; Define the PDF Invoice Generator Service Level Indicator (SLI) based on task completion latency within an acceptable multi-hour window, establishing a relaxed Service Level Objective (SLO) with a generous error budget.

Answer

The team should define the Payment Gateway SLI as the ratio of successful HTTP requests paired with a strict SLO using error budget burn-rate alerts, while defining the PDF Invoice Generator SLI based on asynchronous task latency with a relaxed SLO and generous error budget.
Aligning technical service levels with business objectives requires distinguishing between synchronous, revenue-critical transactions and asynchronous batch operations. For the payment gateway, measuring successful HTTP request ratios (SLI) and applying error budget burn-rate alerts ensures immediate detection of revenue loss without alerting on transient spikes. For the invoice generator, establishing a latency-based SLI with a relaxed SLO prevents over-engineering non-critical background processes.

Step-by-Step Solution

1
Differentiate critical user-facing services from non-critical background workloads based on business impact.
Payment processing directly impacts revenue and requires strict availability goals, whereas batch invoice generation is asynchronous and tolerant to minor delays.
Business alignment requires spending engineering effort and tight error budgets only where customer friction or financial loss occurs.
2
Formulate appropriate Service Level Indicators (SLIs) for each service type.
Use successful HTTP request ratio for the synchronous payment API and completion latency over a multi-hour window for the asynchronous invoice generator.
SLIs must measure real user experience and functional satisfaction relevant to the workload type.
3
Implement error budget burn-rate alerting for high-priority services while setting relaxed targets for batch background services.
Prevents alert fatigue and over-engineering of non-critical components while preserving proactive alerting for revenue-critical paths.
Burn-rate alerting detects sustained budget consumption before severe outages occur.

Key Concept

Aligning Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with business impact requires tailoring metrics to workload criticality, utilizing error budget burn-rate alerts for synchronous paths, and allowing relaxed SLOs for asynchronous background tasks.
Question 997Question →

An enterprise insurance provider is translating its conceptual multi-tier architecture for a regional claims processing platform into a physical architecture on Google Cloud. The conceptual design specifies three core requirements: stateless web services that auto-scale to zero, a managed regional relational database supporting standard SQL transactions without global scaling needs, and a security perimeter preventing data exfiltration to unauthorized Google Cloud resources outside the organization. Which physical architecture on Google Cloud best fulfills these conceptual requirements while minimizing operational overhead and cost?

Show answer & explanation

Answer: Deploy Cloud Run for stateless web services, Cloud SQL for regional relational storage, and configure VPC Service Controls around the resources to prevent unauthorized data exfiltration.

Answer

The correct architecture deploys Cloud Run for stateless microservices, Cloud SQL for regional relational data, and VPC Service Controls to prevent data exfiltration.
The solution properly translates conceptual architectural tiering to physical GCP components: Cloud Run fits the stateless scale-to-zero HTTP web tier, Cloud SQL satisfies regional relational transaction requirements cost-effectively, and VPC Service Controls fulfills security isolation against exfiltration.

Step-by-Step Solution

1
Map the compute requirement (stateless web services with scale-to-zero capability) to physical GCP services.
Cloud Run is selected over GKE because it provides serverless execution with auto-scaling to zero and minimum management overhead.
GKE introduces baseline node management costs and setup overhead for stateless services.
2
Map the storage requirement (regional relational database with SQL support) to physical GCP services.
Cloud SQL is selected over Cloud Spanner.
Cloud Spanner is designed for globally distributed database workloads, making it overly expensive and complex for single-region relational needs.
3
Map the network security requirement (preventing data exfiltration to outside resources).
VPC Service Controls is selected to establish a security perimeter.
IAM permissions alone cannot prevent data exfiltration by authorized users or compromised service accounts transferring data outside the boundary.

Key Concept

Translating Conceptual Requirements into Optimal Physical GCP Architecture
Question 998Question →

An enterprise digital advertising platform recently migrated its ad attribution engine to Google Cloud. A post-migration technical debt assessment reveals two primary architectural risks: infrastructure changes are executed using unversioned Terraform state files stored on individual developer workstations, and background worker service accounts remain assigned primitive Project Editor roles. Which TWO actions should the cloud architect recommend to effectively mitigate this technical debt? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Configure a Cloud Storage remote backend with object versioning and state locking enabled for Terraform state management.; Replace the primitive Project Editor roles on service accounts with specific predefined IAM roles that grant minimal required permissions.

Answer

The architect should migrate Terraform state files to a Cloud Storage remote backend with versioning and object locking, and replace primitive Project Editor IAM roles on service accounts with minimal predefined roles.
Establishing a remote Cloud Storage backend with object versioning and locking resolves IaC state vulnerability and concurrency issues. Replacing primitive Editor roles with fine-grained predefined roles removes excessive access and enforces least privilege governance.

Step-by-Step Solution

1
Assess state management technical debt
Identified unversioned local state files as a major concurrency and corruption risk.
Centralizing state management in Cloud Storage with state locking guarantees consistent infrastructure provisioning across development teams.
2
Assess IAM technical debt
Identified over-privileged service accounts using Project Editor primitive roles.
Transitioning to narrow predefined roles aligns the environment with Google Cloud least-privilege security standards.

Key Concept

Remediating IaC state drift and IAM over-privilege technical debt in Cloud Architectures
Question 999Question →

An enterprise security architect is transitioning an external CI/CD pipeline hosted on Azure DevOps from legacy static service account keys to short-lived federated credentials using Workload Identity Federation to securely access Secret Manager secrets.

In which sequential order should the architect execute the steps to configure this keyless authentication and authorization workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the Workload Identity Pool and Provider, defining attribute mappings and conditions, assigning the workloadIdentityUser role to the external principal set on the target Service Account, granting the secretAccessor role to the Service Account on the secret, and finally executing the token exchange in the pipeline.
The sequence follows the logical dependency chain of Workload Identity Federation setup: first establishing trust via the Pool and Provider, defining mapped attribute conditions for security filtering, granting impersonation rights via workloadIdentityUser on the service account, granting least-privilege secret accessor permissions to the service account, and executing the client-side credential exchange.

Step-by-Step Solution

1
Establish the federated trust anchor by creating a Workload Identity Pool and an OIDC Provider.
Google Cloud STS is configured to accept tokens issued by the external Azure DevOps issuer.
You must create the pool and provider infrastructure before referencing them in attribute rules or IAM policy bindings.
2
Define attribute mappings and assertion conditions on the provider.
Claims from the Azure DevOps JWT are mapped to GCP principal attributes (e.g., google.subject, attribute.repository).
Attribute mappings establish fine-grained identity filters so only authorized repositories or environments can authenticate.
3
Bind roles/iam.workloadIdentityUser on the target Service Account to the mapped principal set.
The external workload identity is authorized to impersonate the specific GCP Service Account.
Workload Identity Federation relies on the workloadIdentityUser role on the service account resource to authorize impersonation.
4
Grant roles/secretmanager.secretAccessor to the GCP Service Account on the secret.
The Service Account gains least-privilege read access to Secret Manager secret versions.
The service account itself must possess resource-level authorization to read secret payloads.
5
Update the pipeline script to call the GCP Security Token Service (STS) and IAM Credentials API.
The pipeline acquires a short-lived access token and fetches secret values dynamically.
Credential exchange and secret fetching can only succeed after all underlying IAM roles and trust relationships are provisioned.

Key Concept

Workload Identity Federation and Service Account Lifecycle Security
Question 1000Question →

An energy utility enterprise is modernizing its smart grid analytics platform hosted on Google Kubernetes Engine (GKE). The security team requires a software supply chain security model that guarantees only verified, signed container images from approved build pipelines can be deployed. Additionally, they require automated detection of newly published vulnerabilities for images already stored in Artifact Registry. Which TWO security configurations should the cloud architect implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure Binary Authorization on the GKE cluster with an attestation policy requiring cryptographic signatures generated during the CI/CD build process.; Enable continuous vulnerability scanning in Artifact Registry to automatically scan container images upon ingestion and monitor for newly disclosed vulnerabilities.

Answer

The cloud architect should implement Binary Authorization on GKE with attestation policies to ensure container image supply chain integrity, and enable continuous vulnerability scanning in Artifact Registry to monitor stored images for newly published CVEs.
Binary Authorization enforces supply chain security by blocking un-attested container images at deployment time, while Artifact Registry continuous vulnerability scanning provides ongoing automated detection of newly discovered CVEs in stored container images.

Step-by-Step Solution

1
Evaluate deploy-time image validation requirements
Identify Binary Authorization as the Google Cloud service designed to enforce attestation policies and block unverified container images from deploying onto GKE clusters.
Binary Authorization verifies cryptographic signatures created during CI/CD before deployment.
2
Evaluate image repository threat scanning requirements
Identify Artifact Registry continuous vulnerability scanning as the mechanism to scan images on push and continuously re-evaluate stored images as new CVE disclosures occur.
Continuous scanning provides automated, proactive discovery of vulnerabilities without requiring manual image rebuilds or re-scans.
3
Reject excessive privilege and perimeter exposure proposals
Discard options advocating primitive IAM role assignments or removing control plane authorized network restrictions on private GKE clusters.
Primitive IAM roles break principle of least privilege governance, and exposing GKE control plane endpoints introduces severe perimeter vulnerabilities.

Key Concept

Multi-layered container security using Binary Authorization for deployment attestation and Artifact Registry for continuous vulnerability scanning
PreviousPage 50 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin