Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 701Question →

A global retail enterprise needs to establish hybrid network connectivity between its primary on-premises data center and a Google Cloud VPC network. The workload requires a sustained throughput of 15 Gbps, a 99.99% service availability SLA, and private connectivity that completely avoids the public internet. Which TWO actions must the network architect perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Provision two 10 Gbps Dedicated Interconnect connections in separate edge availability domains (metropolitan facilities).; Configure Cloud Routers in the target VPC region to establish dynamic BGP sessions with both on-premises routers.

Answer

The network architect must provision two 10 Gbps Dedicated Interconnect connections across separate edge availability domains and configure Cloud Routers in the target VPC region to establish dynamic BGP sessions with the on-premises routers.
To support a 15 Gbps workload with a 99.99% SLA over a private connection, Google Cloud requires Dedicated Interconnect connections deployed across two distinct edge availability domains (metropolitan locations). Additionally, Cloud Routers must be deployed in the target VPC region to establish dynamic BGP sessions with on-premises routers for automatic failover and routing table updates.

Step-by-Step Solution

1
Analyze bandwidth and privacy requirements
Requirements specify 15 Gbps bandwidth, 99.99% availability SLA, and private link avoiding public internet.
15 Gbps exceeds HA VPN maximum capacities and requires Dedicated Interconnect.
2
Determine physical circuit layout for 99.99% SLA
Two Dedicated Interconnect circuits in two distinct edge availability domains are needed.
Google Cloud's 99.99% SLA topology requirement for Interconnect mandates redundancy across edge locations.
3
Configure dynamic routing layer
Deploy Cloud Routers to establish dynamic BGP peering over the VLAN attachments.
Dynamic BGP via Cloud Router manages route advertising, traffic balancing, and automatic failover across redundant links.

Key Concept

Configuring 99.99% HA Dedicated Interconnect with Dynamic BGP Routing
Question 702Question →

A logistics enterprise needs to automatically identify misconfigurations���such as open network firewall rules and publicly accessible Cloud Storage buckets—across all projects in its Google Cloud organization. Furthermore, the compliance team must view administrative audit logs and security findings while strictly adhering to the principle of least privilege. Which architecture and access management strategy satisfies these security requirements?

Show answer & explanation

Answer: Enable Security Command Center Security Health Analytics at the organization level, and grant the compliance team the Security Center Findings Viewer (roles/securitycenter.findingsViewer) and Logs Viewer (roles/logging.viewer) predefined roles.

Answer

The correct strategy is to enable Security Command Center Security Health Analytics at the organization level and grant the compliance team the Security Center Findings Viewer and Logs Viewer roles.
Enabling Security Command Center Security Health Analytics at the organization level provides automated detection of vulnerabilities such as publicly exposed buckets and open firewalls across all project environments. Combining the Security Center Findings Viewer role with the Logs Viewer role provides the compliance team with precise, read-only access to audit logs and security findings in alignment with least-privilege security principles.

Step-by-Step Solution

1
Identify the automated scanning mechanism for infrastructure misconfigurations
Security Command Center Security Health Analytics scans GCP organization resources for vulnerabilities and misconfigurations like public storage buckets or open firewalls.
Centralizing Security Health Analytics at the organization level ensures uniform coverage across all current and future projects.
2
Select least-privilege IAM roles for reviewing findings and audit logs
The Security Center Findings Viewer role (roles/securitycenter.findingsViewer) permits viewing Security Command Center findings, and Logs Viewer (roles/logging.viewer) allows inspecting audit logs.
Predefined security roles satisfy auditor requirements without granting write or administrative privileges.

Key Concept

Centralized Security Logging and Security Command Center Governance
Question 703Question →

You need to configure secure, keyless authentication for an external GitHub Actions CI/CD pipeline accessing Google Cloud resources using Workload Identity Federation. What is the correct sequence of steps to establish this setup?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the target GCP Service Account with minimal IAM roles, creating the Workload Identity Pool and Provider for GitHub, granting the external GitHub principal the Workload Identity User role on the service account, and finally configuring the CI/CD workflow to request short-lived tokens.
Configuring Workload Identity Federation requires defining the target GCP Service Account first, establishing the Workload Identity Pool and OIDC Provider, granting the Workload Identity User role to authorize impersonation by the external identity, and lastly configuring the external workload to exchange tokens.

Step-by-Step Solution

1
Define target identity in GCP
A service account exists with specific permissions granted for resource deployment.
Before configuring external authentication, the target GCP resource identity and its permissions must be defined.
2
Establish external trust infrastructure
Workload Identity Pool and OIDC Provider are configured to recognize tokens from GitHub.
Google Cloud must be configured to trust token assertions from the external identity provider.
3
Authorize impersonation
The external principal is granted the Workload Identity User role on the target service account.
Impersonation rights must be granted so the validated external identity is allowed to act as the GCP service account.
4
Exchange tokens in CI/CD pipeline
Short-lived GCP credentials are used during workflow execution.
The pipeline uses its native OIDC token to request temporary GCP federated credentials.

Key Concept

Workload Identity Federation for keyless authentication
Question 704Question →

A cloud architect is establishing an automated deployment sequence to provision a high-availability Cloud SQL PostgreSQL database instance using Customer-Managed Encryption Keys (CMEK) and Private Services Access (PSA) within a dedicated VPC. To ensure all infrastructure dependencies and security access controls are satisfied before instance initialization, in what correct sequential order should these provisioning steps be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: 1) Enable the required Google Cloud APIs for Cloud SQL, Cloud KMS, and Service Networking, 2) Allocate an internal IP range and establish a Private Services Access connection with the service producer network in the VPC, 3) Grant the Cloud SQL Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter IAM role on the target encryption key, and 4) Provision the regional Cloud SQL PostgreSQL instance configured with Private IP and the customer-managed encryption key.
Provisioning managed database systems with strict security controls requires resolving infrastructure dependencies sequentially. First, service APIs must be enabled to activate Cloud KMS, Service Networking, and Cloud SQL capabilities along with their respective service agents. Second, Private Services Access must be configured by reserving an internal IP block and creating VPC peering so the database can bind to a private IP. Third, IAM access must be delegated to the Cloud SQL Service Agent on the Cloud KMS key so it can encrypt storage blocks during creation. Finally, the Cloud SQL instance can be provisioned referencing both the private network and the CMEK key.

Step-by-Step Solution

1
Enable required Google Cloud Service APIs
Cloud SQL Admin API, KMS API, and Service Networking API become active, spawning the necessary service account identities.
Infrastructure APIs must be activated before downstream networking peering or IAM role assignments can be managed.
2
Set up Private Services Access (PSA)
An IP block is allocated and VPC network peering to Google Service Networking is created.
Cloud SQL instances with Private IP require an established Private Services Access connection to route private network traffic within the VPC.
3
Configure CMEK IAM Permissions
The Cloud SQL Service Agent ([email protected]) receives the roles/cloudkms.cryptoKeyEncrypterDecrypter role.
Cloud SQL validates encryption key access at creation time; omitting this step prior to creation causes instance initialization to fail.
4
Deploy the Cloud SQL Instance
The database instance provisions successfully with private networking and customer-managed encryption.
All prerequisite infrastructure, network routing, and IAM key delegation are ready for resource allocation.

Key Concept

Sequential Dependency Resolution for Cloud SQL Private Services Access and CMEK Provisioning
Question 705Question →

A cloud security team is establishing centralized governance guardrails for a newly created Google Cloud folder named Staging. The organization's security policy demands two specific restrictions across all projects within this folder: preventing Compute Engine instances from being assigned external IP addresses, and blocking the creation of external service account keys. Which TWO Organization Policy constraints should be enforced on the Staging folder to meet these security requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Enforce the constraints/compute.vmExternalIpAccess constraint to restrict external IP assignment on virtual machine instances.; Enforce the constraints/iam.disableServiceAccountKeyCreation boolean constraint to prevent the creation of service account keys.

Answer

Enforce the constraints/compute.vmExternalIpAccess constraint to restrict external IP addresses on VM instances, and enforce the constraints/iam.disableServiceAccountKeyCreation boolean constraint to prevent service account key creation.
The correct guardrails are established using Organization Policy constraints. The constraint controlling external IP assignment on virtual machines is constraints/compute.vmExternalIpAccess, while the boolean constraint that prevents users from generating service account keys is constraints/iam.disableServiceAccountKeyCreation. Applying both at the folder level enforces these guardrails on all existing and future child projects.

Step-by-Step Solution

1
Identify the governance requirement for restricting VM networking.
Determine that constraints/compute.vmExternalIpAccess is the standard Google Cloud Organization Policy constraint designed to restrict external IP allocation on Compute Engine instances.
Organization Policies enforce resource management rules hierarchically across organization nodes, folders, and projects.
2
Identify the governance requirement for credentials management.
Determine that constraints/iam.disableServiceAccountKeyCreation is the standard boolean constraint designed to disable the creation of external service account JSON/P12 keys.
Preventing service account key creation eliminates long-lived credentials risk across all child projects under the target folder.

Key Concept

Google Cloud Organization Policy constraints for resource restriction and identity guardrails
Question 706Question →

An enterprise cloud security architect needs to ensure that newly created Google Cloud projects do not automatically grant the primitive Editor role to default service accounts, such as the default Compute Engine service account. The guardrail must be centrally managed and automatically enforced across all current and future projects in the resource hierarchy without relying on post-provisioning scripts or manual developer compliance. Which approach meets these governance requirements?

Show answer & explanation

Answer: Enforce the `iam.automaticIamGrantsForDefaultServiceAccounts` boolean Organization Policy constraint at the Organization root level.

Answer

Enforce the `iam.automaticIamGrantsForDefaultServiceAccounts` boolean Organization Policy constraint at the Organization root level.
Enforcing the boolean Organization Policy constraint `iam.automaticIamGrantsForDefaultServiceAccounts` at the Organization root level ensures that when service APIs (such as Compute Engine) are enabled in any project, Google Cloud does not automatically grant the primitive Editor role to default service accounts. Because Organization Policies inherit down the resource hierarchy, setting this at the root guarantees proactive compliance for all current and future projects.

Step-by-Step Solution

1
Identify the compliance requirement
Prevent automatic assignment of the primitive Editor role to default service accounts across all projects.
Default service accounts created when APIs (like Compute Engine) are enabled receive broad Editor permissions by default, violating least privilege principles.
2
Evaluate Google Cloud preventative guardrail mechanisms
Organization Policy constraints provide proactive, centralized policy enforcement across the resource hierarchy.
Organization Policies enforce constraints at creation time, ensuring policy compliance without operational overhead or delay.
3
Select the specific constraint for default service account IAM grants
Apply `iam.automaticIamGrantsForDefaultServiceAccounts` at the Organization node.
This specific boolean constraint stops GCP from binding primitive roles to default service accounts, inheriting down to all folders and projects.

Key Concept

Organization Policy Boolean Constraints for Service Account Security
Estimated Time:1m 30s
Question 707Question →

A global pharmaceutical enterprise headquartered in Switzerland collects sensitive clinical trial data across multiple research facilities. The compliance department mandates two strict architectural requirements: first, all newly created data resources (such as Cloud Storage buckets and BigQuery datasets) must be physically restricted to the europe-west6 (Zurich) region to satisfy national data sovereignty laws; second, any administrative access by Google support personnel to underlying customer data must require explicit, real-time cryptographic approval from the enterprise compliance team. Which solution meets these compliance and data governance requirements?

Show answer & explanation

Answer: Enforce an Organization Policy using the Resource Locations constraint (constraints/gcp.resourceLocations) set to europe-west6, and enable Access Approval across the resource hierarchy to require explicit authorization before Google support can access data.

Answer

Enforce an Organization Policy using the Resource Locations constraint (constraints/gcp.resourceLocations) set to europe-west6, and enable Access Approval across the resource hierarchy to require explicit authorization before Google support can access data.
The correct answer combines the Resource Locations organization policy constraint (constraints/gcp.resourceLocations) to declaratively restrict storage and compute resource creation to europe-west6 with Google Cloud Access Approval to ensure Google support staff cannot access data without explicit, real-time approval from customer administrators.

Step-by-Step Solution

1
Evaluate data sovereignty location enforcement requirements.
The Resource Locations organization policy constraint (constraints/gcp.resourceLocations) prevents users from creating resources in any region other than the specified allowed locations (europe-west6).
Organization policies enforce centralized guardrails on resource provisioning location across projects or folders.
2
Evaluate provider access governance requirements.
Access Approval allows customers to explicitly approve or deny requests by Google personnel to access customer data during support operations.
This guarantees that no cloud operator access occurs without just-in-time approval from compliance officers.

Key Concept

Data Sovereignty and Provider Access Control using Resource Locations Organization Policies and Access Approval
Question 708Question →

An enterprise financial institution processes sensitive transactional data on Google Cloud using BigQuery and Google Kubernetes Engine (GKE). The security architecture requires that external web traffic be protected against application-layer DDoS attacks and SQL injection, while internal analyst workloads must be strictly prevented from exfiltrating data to external Google Cloud Storage buckets or unauthorized GCP organizations, even if an analyst possesses legitimate IAM read permissions. Additionally, on-premises systems access GCP resources via Dedicated Interconnect. Which TWO architectural security controls must you implement to satisfy these compliance and perimeter security requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure Cloud Armor security policies with WAF rules and rate limiting, attaching them to the Backend Services of the Global External HTTP(S) Load Balancers.; Establish a VPC Service Controls service perimeter enclosing the BigQuery and Storage resources, defining access levels and explicit ingress/egress policies for authorized access.

Answer

To meet both perimeter security and data exfiltration prevention requirements, you must deploy Cloud Armor security policies attached to HTTP(S) load balancer backend services for Layer 7 protection, and configure a VPC Service Controls perimeter around sensitive APIs like BigQuery and Cloud Storage.
Cloud Armor security policies protect public-facing applications at the GCP edge against Layer 7 DDoS and exploit attempts, while VPC Service Controls isolate Google API services (BigQuery, Cloud Storage) within a logical perimeter to prevent authorized credentials from exfiltrating data out of the organization.

Step-by-Step Solution

1
Identify the ingress edge security requirements against Layer 7 attacks and DDoS.
Determine that Cloud Armor security policies integrated with Global External HTTP(S) Load Balancing provide edge filtering, rate limiting, and WAF protection.
Cloud Armor is Google Cloud's dedicated defense mechanism against web application attacks and volumetric/L7 DDoS.
2
Identify the perimeter exfiltration defense requirements for sensitive data APIs.
Determine that VPC Service Controls must be configured to wrap Google Cloud Storage and BigQuery APIs inside a service perimeter.
IAM permissions authenticate users but cannot prevent a compromised or malicious identity from copying data from authorized buckets to external, non-controlled GCP buckets.
3
Evaluate network transitivity and routing misconceptions.
Reject VPC Network Peering as a transitive connectivity hub for on-premises Interconnect traffic.
GCP VPC Peering strictly prohibits transitive routing between non-directly peered networks.

Key Concept

Perimeter Defense using Cloud Armor for Layer 7 Edge Protection and VPC Service Controls for Data Exfiltration Prevention
Question 709Question →

An enterprise security architect is defining key management and data encryption standards across Google Cloud infrastructure to satisfy distinct regulatory guidelines. Match each compliance and operational key control requirement to its corresponding Google Cloud encryption mechanism.

Click a left item, then click its matching right item

Items

Data must be encrypted at rest using keys hosted on an on-premises Hardware Security Module (HSM), ensuring Google Cloud never stores or directly accesses unencrypted root key material, with cryptographic requests routed externally over private network connections.
Data must be protected using customer-controlled cryptographic keys hosted in Google Cloud, supporting automated key rotation schedules, fine-grained IAM access control, and FIPS 140-2 Level 3 HSM hardware protection.
Transient compute workloads require per-request encryption key material supplied directly in API calls for disk operations, where key material resides only in ephemeral memory and is never retained in GCP persistent storage.
Data resting in cloud storage services must be protected by default using symmetric AES-256 encryption without requiring custom key creation, IAM role assignments, or operational key management overhead.

Matches

Show answer & explanation

Answer

Cloud EKM matches external on-premises HSM key hosting; CMEK via Cloud KMS/HSM matches in-cloud customer-controlled key lifecycle and rotation management; CSEK matches raw per-request key material held only in transient memory; Google-Default Encryption matches automated zero-overhead baseline storage encryption.
Each key control requirement maps to a specific GCP encryption model based on key ownership location and operational burden: Cloud EKM protects data with keys residing outside GCP; CMEK offers native GCP KMS lifecycle management; CSEK processes ephemeral client-provided keys per call; and Google-Default handles transparent baseline storage encryption.

Step-by-Step Solution

1
Analyze external on-premises key retention requirements.
Identify that Cloud External Key Manager (Cloud EKM) routes cryptographic requests to keys hosted outside GCP boundaries.
Cloud EKM connects GCP services to external HSM systems so root keys never leave on-premises infrastructure.
2
Evaluate requirements for customer-managed key lifecycle and rotation within Google Cloud.
Match with Customer-Managed Encryption Keys (CMEK) using Cloud KMS or Cloud HSM.
CMEK gives full control over rotation schedules, IAM policy permissions, and location while running on Google Cloud managed infrastructure.
3
Assess transient per-request key header requirements.
Match with Customer-Supplied Encryption Keys (CSEK).
CSEK accepts user-supplied key material in API request headers without storing the keys anywhere in Google Cloud persistent storage.
4
Identify default baseline platform encryption requirements.
Match with Google-Default Encryption.
Google Cloud automatically encrypts all data at rest using AES-256 standard encryption without requiring manual key management.

Key Concept

Google Cloud Data Encryption Spectrum (Google-Default, CMEK, CSEK, Cloud EKM)
Question 710Question →

An enterprise organization is establishing a standardized disaster recovery (DR) validation procedure for a critical multi-region application on Google Cloud. The architecture uses Cloud SQL cross-region read replicas and Compute Engine managed instance groups (MIGs). In what operational sequence should a cloud architect execute the disaster recovery failover drill from start to finish?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Verify and request necessary Compute Engine quota increases in the target secondary region, 2) Promote the secondary Cloud SQL read replica to a standalone primary database instance, 3) Update Cloud DNS routing policies to direct user traffic to the secondary region endpoint, and 4) Execute automated synthetic workload tests to validate application integrity, RPO, and RTO metrics.
A sound business continuity validation procedure begins with pre-drill verification of target region compute quotas to guarantee capacity. Once capacity is assured, the secondary database is promoted to primary status so that it can receive writes. Next, network endpoints (Cloud DNS) are switched to route incoming traffic to the secondary region. Finally, synthetic transaction tests run to validate data loss (RPO) and operational restore time (RTO).

Step-by-Step Solution

1
Pre-drill Quota Audit
Ensures the secondary GCP region has sufficient resource capacity to scale up workload instances.
Requesting quota increases during an active failover drill will lead to provisioning failures due to approval processing delays.
2
Database Failover Initiation
Promotes the cross-region read replica into a standalone primary instance.
Application servers in the secondary region require a writable database endpoint to serve traffic properly upon cutover.
3
Traffic Redirection
Switches network routing to point user requests to the secondary regional endpoint.
DNS routing changes should only occur once backend compute and database resources are operational.
4
Post-Failover Validation & Monitoring
Confirms data replication consistency and verifies that Recovery Time Objective (RTO) and Recovery Point Objective (RPO) constraints were met.
Final validation tests establish empirical proof of business continuity readiness.

Key Concept

Disaster Recovery Failover Validation Sequence
Question 711Question →

An enterprise logistics company runs a real-time fleet tracking service on Google Cloud. The workload uses a primary Compute Engine Managed Instance Group (MIG) in us-central1 and a secondary MIG in us-east4, with persistent state maintained via Cloud SQL cross-region read replicas. The organization is designing a quarterly Disaster Recovery (DR) validation procedure to verify a Recovery Time Objective (RTO) of 30 minutes and a Recovery Point Objective (RPO) of under 1 minute without disrupting live production traffic. Which TWO procedures must be included in the DR test execution plan to ensure accurate validation? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Pre-verify that regional compute and database resource quotas in the secondary region (us-east4) are sufficient to sustain full production load prior to executing the failover drill.; Promote a dedicated test cross-region Cloud SQL read replica in us-east4 to a standalone database instance and perform automated consistency checks in an isolated VPC network.

Answer

The DR validation plan must include pre-verifying regional resource quotas in the failover target region prior to testing, and promoting a dedicated test cross-region read replica in an isolated network to validate data consistency.
Validating disaster recovery readiness requires verifying target regional quotas in advance to prevent capacity provisioning failures during a test or real outage. Additionally, promoting a dedicated test read replica within an isolated environment validates data consistency and promotion procedures without disrupting the primary database or active replication pipeline.

Step-by-Step Solution

1
Analyze database replication options against the RPO target of under 1 minute.
Daily backup exports yield an RPO of up to 24 hours. Continuous cross-region replication must be validated using an isolated test replica promotion.
Sub-minute RPO requires testing live replication channels rather than periodic file backups.
2
Evaluate regional compute capacity and operational constraints in the failover region.
Quota increases must be pre-approved because request evaluation by Cloud Operations is not instantaneous.
Quota limits enforced during failover testing will cause VM creation failures, breaching the 30-minute RTO.

Key Concept

Developing Procedures for Business Continuity and Disaster Recovery Validation
Question 712Question →

An architecture team is establishing an automated progressive release pipeline for a mission-critical microservice deployed on Google Kubernetes Engine (GKE). The deployment process must strictly enforce container security attestations, progressive traffic shifting, and continuous automated health monitoring before achieving full production rollout. Place the operational stages of this release strategy in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution order begins with building and storing the container image in Artifact Registry, followed by Container Analysis scanning and Binary Authorization attestation signing. Next, Cloud Deploy provisions the workload to the staging environment. Once staging tests pass, Cloud Deploy routes 10% of live traffic to the canary release. Finally, Cloud Monitoring evaluates real-time SLIs before Cloud Deploy automatically promotes the release to 100% production traffic.
The sequence follows standard Google Cloud continuous delivery best practices: Code must first be compiled into an artifact in Artifact Registry. Security verification via Container Analysis and Binary Authorization attestation occurs next to ensure image compliance. The image is then deployed to staging via Google Cloud Deploy. Following successful staging validation, Cloud Deploy shifts a initial fraction (10%) of production traffic to the canary pods. Cloud Monitoring continuously tracks error rates and latency during this canary phase, permitting final promotion to 100% traffic only after stability criteria are satisfied.

Step-by-Step Solution

1
Source Compilation & Artifact Build
Container image created and pushed to Artifact Registry with a unique digest.
Source code must be packaged into an immutable container artifact before security scanning or deployment.
2
Vulnerability Scanning & Policy Attestation
Binary Authorization attestor generates a cryptographic signature confirming compliance.
GKE Binary Authorization admission controllers block deployments unless the image digest contains required attestations.
3
Staging Environment Deployment
Cloud Deploy renders Kubernetes manifests and deploys the workload to the staging target.
Initial deployment to non-production environments verifies deployment rendering and pre-release integration tests.
4
Canary Traffic Shifting
GKE ingress/service routes a controlled 10% fraction of user traffic to the canary pods.
Progressive delivery minimizes blast radius by testing new code against a small portion of live production traffic.
5
Automated SLI Validation & Production Promotion
Cloud Deploy shifts remaining 90% traffic to complete the production rollout after metrics verification.
Real-time monitoring of error rates and latency guarantees system stability before full traffic promotion.

Key Concept

Automated CI/CD Pipeline Execution Order with Progressive Canary Delivery and Binary Authorization
Question 713Question →

An organization is implementing a zero-trust credential architecture to allow workloads running on an external on-premises Kubernetes cluster to retrieve sensitive credentials stored in Google Cloud Secret Manager. To comply with strict security standards, you must eliminate all static, long-lived service account keys and enforce least privilege. Arrange the operational and architectural steps in the correct chronological order required to establish Workload Identity Federation and securely retrieve the secret payload.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the target Google Cloud Service Account with restricted Secret Manager Accessor permissions, followed by creating the Workload Identity Pool and OIDC Provider, granting the Workload Identity User role to the specific external principal subject, exchanging the external OIDC token for a short-lived GCP token via STS, and finally accessing the secret payload.
The sequence follows the compulsory architectural workflow for Workload Identity Federation: first defining the GCP service account with least privilege permissions, establishing the external trust boundary via Workload Identity Pool and Provider, binding the federated principal to the service account via Workload Identity User role, performing the runtime token exchange with STS, and using the resulting temporary token to access Secret Manager.

Step-by-Step Solution

1
Provision the Google Cloud identity and grant resource-level permissions.
A dedicated Service Account exists with `roles/secretmanager.secretAccessor` granted specifically on the required secret resource.
Before external access can be granted, the target identity and its least-privilege access permissions must exist inside GCP.
2
Define external identity trust mechanisms in GCP IAM.
A Workload Identity Pool and OIDC Provider are established, pointing to the external Kubernetes issuer URL.
GCP must be configured to validate tokens signed by the external OIDC identity provider.
3
Configure IAM impersonation policy for federated principals.
The external workload identity subject is bound to the GCP Service Account via `roles/iam.workloadIdentityUser`.
This establishes the authorization bridge enabling the specific external pod identity to impersonate the GCP Service Account.
4
Execute runtime token exchange via Security Token Service (STS).
The workload obtains a short-lived GCP access token in exchange for its native Kubernetes service account JWT.
Workload Identity Federation relies on short-lived STS credential exchange rather than stored service account keys.
5
Access secret payload using short-lived credentials.
The workload successfully authenticates to Secret Manager and retrieves the secret data.
The temporary access token provides the necessary identity authorization to perform the API call.

Key Concept

Workload Identity Federation & Service Account Key Elimination
Question 714Question →

A financial services firm utilizes a Cloud Build CI/CD pipeline to execute Terraform code that provisions microservices and database infrastructure across multiple Google Cloud projects. During release cycles, concurrent code merges from multiple engineering teams cause frequent Terraform state lock failures and pipeline build collisions. Additionally, developers have been downloading service account JSON keys to run terraform apply locally from their workstations to bypass pipeline queues. You need to redesign the CI/CD pipeline and SDLC process to eliminate state corruption, enforce execution order, and adhere to Google Cloud security best practices. Which solution should you implement?

Show answer & explanation

Answer: Configure a shared Cloud Storage backend with object versioning and state locking for Terraform, configure Cloud Build trigger concurrency limits to serialize deployment executions, and replace downloadable service account keys with Workload Identity Federation and service account impersonation.

Answer

Configure a shared Cloud Storage backend with object versioning and state locking for Terraform, configure Cloud Build trigger concurrency limits to serialize deployment executions, and replace downloadable service account keys with Workload Identity Federation and service account impersonation.
Centralizing Terraform state in Google Cloud Storage with object versioning and state locking guarantees atomic operations and prevents state corruption across concurrent runs. Configuring concurrency controls in Cloud Build serializes release execution, preventing race conditions during deployments. Utilizing Workload Identity Federation eliminates long-lived service account JSON keys by using short-lived, impersonated credentials.

Step-by-Step Solution

1
Analyze state management requirements for IaC in CI/CD
Identified that remote state locking via Cloud Storage backend with versioning prevents concurrent state modification and corruption.
Terraform requires centralized locking when multiple pipelines or developers execute changes against shared infrastructure.
2
Analyze pipeline concurrency and execution ordering
Determined that setting Cloud Build concurrency controls serializes execution runs.
Serializing build execution prevents race conditions when applying infrastructure changes from concurrent pull request merges.
3
Analyze authentication and identity security in the SDLC
Replaced static service account JSON key files with Workload Identity Federation and IAM service account impersonation.
Static keys represent high-risk security vulnerabilities; short-lived tokens via impersonation align with GCP security best practices.

Key Concept

CI/CD Pipeline Security and Infrastructure as Code (IaC) State Lock Optimization
Question 715Question →

An enterprise application deployed on Google Cloud requires a disaster recovery (DR) failover validation procedure that adheres to an RTO of 1 hour and an RPO of 5 minutes. During a recent DR validation exercise, automated failover to the secondary region failed because Compute Engine instance provisioning exceeded default regional quota limits. Which validation procedure should be established to ensure reliable DR failover execution in future drills?

Show answer & explanation

Answer: Include automated pre-drill verification of target regional resource quotas and proactively request quota limit increases prior to conducting failover testing.

Answer

Include automated pre-drill verification of target regional resource quotas and proactively request quota limit increases prior to conducting failover testing.
Pre-drill quota verification ensures that the secondary region has sufficient regional resource quotas provisioned and approved before initiating failover testing. This avoids unexpected instance creation failures while maintaining compliance with RTO and RPO objectives.

Step-by-Step Solution

1
Analyze the cause of the DR validation failure.
Identified that compute resource creation failed due to insufficient regional quota limits in the secondary failover region.
Default GCP regional quotas may be lower than the capacity required to host the full production workload upon failover.
2
Evaluate potential procedural fixes against RTO/RPO constraints.
Automated pre-drill quota validation and proactive quota requests ensure required capacity is available without altering the architectural recovery envelope.
Quota increases must be requested and approved by Google Cloud in advance and cannot be dynamically increased on-demand during a disaster event.

Key Concept

Disaster Recovery Validation and Quota Management
Question 716Question →

Match each Google Cloud network security requirement with the perimeter control mechanism best suited to fulfill it.

Click a left item, then click its matching right item

Items

Preventing internal users with valid IAM access from copying sensitive BigQuery datasets to unauthorized external Google Cloud projects.
Protecting public-facing web applications at the external HTTP(S) load balancer against SQL injection attacks and volumetric DDoS.
Enforcing organization-wide firewall rules centrally across multiple VPC networks using dynamic resource metadata tags.
Enabling internal Compute Engine Virtual Machines without public IP addresses to securely reach Google Cloud APIs.

Matches

Show answer & explanation

Answer

VPC Service Controls prevent data exfiltration to unauthorized projects; Cloud Armor Security Policies protect edge applications from DDoS and web application attacks; Hierarchical Firewall Policies with Secure Tags enforce organization-wide traffic control; Private Google Access allows private VMs to communicate with GCP APIs.
Each GCP security feature targets a distinct architectural layer: VPC Service Controls protect against data exfiltration across GCP API boundaries; Cloud Armor provides edge WAF and DDoS defenses at load balancers; Hierarchical Firewall Policies enforce centralized organizational firewall rules with secure tags; and Private Google Access provides secure API egress for private VMs.

Step-by-Step Solution

1
Analyze the threat of unauthorized data copying by privileged internal users.
Identify that IAM roles alone cannot prevent data movement across project boundaries, requiring VPC Service Controls perimeters.
VPC Service Controls restrict API communication between resources inside and outside a perimeter.
2
Evaluate protection controls for internet-facing web endpoints.
Map Web Application Firewall (WAF) features like SQLi protection and volumetric DDoS defense to Cloud Armor.
Cloud Armor operates at the Google Cloud edge attached to load balancers to block malicious traffic before reaching compute backends.
3
Review enterprise-wide firewall administration requirements.
Select Hierarchical Firewall Policies combined with Secure Tags.
Hierarchical policies apply rules across folder and organization levels that individual VPC admins cannot override.
4
Determine the network service required for private VM outreach to Google services.
Identify Private Google Access.
Private Google Access routes internal VM traffic securely to default Google API endpoints without external IPs.

Key Concept

Google Cloud Perimeter Security Mechanisms
Question 717Question →

An organization is executing a planned disaster recovery (DR) simulation for a critical web application hosted on Google Cloud. Arrange the standard operational steps in the correct chronological sequence to perform the failover and validation procedure.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with verifying regional resource quotas, followed by database synchronization and promotion, then updating Cloud DNS routing to point to the failover region, and concludes with validating application health and SLO metrics.
The correct procedure follows a logical operational dependency chain: first ensure compute quota capacity in the destination region, promote the replicated database to ensure state consistency, update Cloud DNS to switch live traffic to the target environment, and finally conduct health and SLO checks to validate success.

Step-by-Step Solution

1
Pre-failover Quota Verification
Ensures the destination region has sufficient quota allocations to launch required Compute Engine and network resources.
Requesting quota increases takes time and must be done prior to failover execution to prevent resource allocation failure.
2
Database Promotion and Data Integrity Check
Ensures data replication is up-to-date and sets the secondary storage tier to read-write mode.
The database tier must be active and consistent before application instances can process user transactions.
3
Traffic Redirection via Cloud DNS
Directs incoming user traffic from the primary environment to the secondary region endpoint.
Traffic routing should only be switched after target compute and database services are fully ready to process requests.
4
Post-failover Validation and Operational Monitoring
Confirms that latency, throughput, and error rates conform to target SLOs/SLIs.
Empirical validation verifies that business continuity requirements are fully met under disaster conditions.

Key Concept

Disaster Recovery Failover Execution and Validation Workflow
Estimated Time:1m 0s
Question 718Question →

A gaming analytics company is developing a stateless HTTP API to process unpredictable bursts of telemetry data sent via webhooks from mobile clients. The workload experiences periods of complete inactivity during off-peak hours and requires rapid scaling to handle sudden traffic spikes without manual intervention. The development team wants to containerize the application while minimizing operational management and paying only for the compute resources consumed during request execution. Which Google Cloud compute solution should you recommend?

Show answer & explanation

Answer: Deploy the containerized service to Cloud Run configured with autoscaling and scale-to-zero enabled.

Answer

Deploy the containerized service to Cloud Run configured with autoscaling and scale-to-zero enabled.
Deploying the service to Cloud Run provides a fully managed serverless environment that runs stateless containers, scales rapidly based on incoming HTTP webhook requests, scales down to zero when idle, and incurs costs only during request execution.

Step-by-Step Solution

1
Analyze the workload characteristics and operational constraints.
The workload is stateless, containerized, triggered via HTTP/webhooks, experiences unpredictable traffic spikes, and has periods of zero traffic.
Identifying statefulness, protocol, scaling patterns, and management constraints guides compute platform selection.
2
Evaluate Google Cloud compute options against operational overhead and billing requirements.
Cloud Run supports custom container images, scales automatically from zero to thousands of instances, charges only during request processing, and requires zero cluster maintenance.
Cloud Run is the recommended platform for stateless HTTP container workloads needing minimal management.
3
Eliminate suboptimal compute architectures.
GKE adds unnecessary cluster management complexity, MIGs require VM maintenance and static baseline costs, and Committed Use Discounts are inappropriate for idle-heavy variable workloads.
Avoiding compute misallocations ensures optimal cost efficiency and minimal maintenance.

Key Concept

Selecting Serverless Container Platforms for Stateless HTTP Workloads
Estimated Time:1m 30s
Question 719Question →

An organization is preparing to launch a new mission-critical application on Google Cloud. Before running the full production deployment, the cloud architecture team needs to validate the deployment procedures and infrastructure readiness. Which TWO validation practices should be included in the pre-deployment testing strategy? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Verify regional resource quota limits in advance to ensure the destination Google Cloud region can accommodate the target workload size.; Execute automated Infrastructure as Code (IaC) dry-run validations and plan checks in a staging environment to detect configuration errors early.

Answer

The correct practices are verifying regional resource quota limits in advance to ensure adequate capacity, and executing automated Infrastructure as Code (IaC) dry-run validations in staging environments before production deployment.
Verifying regional quotas ensures that resource capacity requests will not be rejected during deployment. Running IaC dry-run checks verifies syntax, dependencies, and expected changes without modifying live infrastructure prematurely.

Step-by-Step Solution

1
Assess pre-deployment technical validation requirements for cloud workloads.
Identified quota verification and IaC plan validation as essential validation controls.
Quota limits and syntax/configuration errors are common root causes of deployment failure.
2
Evaluate potential failure modes in automated deployment pipelines.
Confirmed that quota checks must be done proactively and IaC must be dry-run tested prior to production apply operations.
Google Cloud quotas require explicit requests and manual approval timelines, while IaC dry-runs catch drift and structural errors early.

Key Concept

Technical solution testing and environment readiness validation
Estimated Time:1m 0s
Question 720Question →

An enterprise organization is evaluating the security and governance of its automated CI/CD pipeline. The current pipeline uses Cloud Build to run integration tests for incoming pull requests (PRs) against a Cloud Spanner database situated inside a VPC Service Controls (VPC-SC) perimeter. An architecture audit revealed two critical issues: pull requests submitted by external contributors can execute arbitrary build scripts using the default Cloud Build service account, creating data exfiltration risks, and developers frequently execute ad-hoc infrastructure updates from local workstations, leading to state corruption and configuration drift. Which architecture and pipeline control strategy should a Principal Cloud Architect implement to address these security and operational risks?

Show answer & explanation

Answer: Configure Cloud Build to use a private worker pool peered into the VPC-SC perimeter, attach a minimal user-managed service account to the pipeline, require approval from a repository maintainer before running PR builds from external contributors, and enforce IaC deployments exclusively through CI/CD using a versioned Cloud Storage backend.

Answer

Configure Cloud Build to execute PR builds using private worker pools connected within the VPC Service Controls perimeter, utilize a least-privilege user-managed service account, require maintainer approval for pull request triggers from untrusted authors, and enforce centralized Infrastructure as Code execution with a versioned Cloud Storage backend.
The correct strategy combines network isolation, IAM least privilege, build trigger safeguards, and automated IaC governance. Private worker pools allow Cloud Build to access resources inside a VPC-SC perimeter securely. Utilizing a user-managed service account with fine-grained permissions prevents excessive build privileges. Requiring maintainer approval before building external pull requests mitigates malicious code execution risks. Finally, centralized IaC deployment using Cloud Storage remote backends with versioning and locking prevents state corruption and configuration drift.

Step-by-Step Solution

1
Analyze pipeline network security and perimeter requirements.
Default Cloud Build shared pools reside outside VPC-SC perimeters. Private worker pools must be provisioned and peered with the VPC network containing the Cloud Spanner database to allow secure access without exposing perimeter resources.
VPC Service Controls perimeters prevent data exfiltration and block unauthorized ingress/egress from public build environments.
2
Analyze IAM permission and build trigger security for pull requests.
Assign a dedicated user-managed service account with fine-grained permissions instead of the default Cloud Build service account, and require maintainer approval prior to executing build scripts submitted by external pull request authors.
Prevent arbitrary code execution in untrusted pull requests from abusing build pipeline privileges or exfiltrating data.
3
Evaluate Infrastructure as Code (IaC) governance and state management.
Mandate that all Terraform changes execute exclusively through the automated CI/CD pipeline using a Cloud Storage remote backend with object versioning and state locking enabled.
Eliminate manual local updates that cause configuration drift and prevent state file corruption during concurrent deployments.

Key Concept

Analyzing SDLC and CI/CD Pipeline Security and Governance in GCP
Estimated Time:3m 0s
PreviousPage 36 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin