Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 761Question →

A financial analytics enterprise hosts a critical transaction processing workload on Google Cloud across a primary region (us-central1) and a disaster recovery target region (us-east4). The application uses Compute Engine Managed Instance Groups (MIGs) and Cloud SQL, with a business mandate requiring a Recovery Time Objective (RTO) of 45 minutes and a Recovery Point Objective (RPO) of 15 minutes. During an unannounced DR validation drill, the automated failover process failed: scaling up the secondary MIG in us-east4 was rejected due to hitting default regional CPU quota limits, and application traffic was diverted to us-east4 before database replica promotion completed, causing widespread write transaction errors. Which disaster recovery validation procedure should you establish to prevent these failures in future drills?

Show answer & explanation

Answer: Automate pre-drill validation tasks to audit and reserve regional resource quotas in us-east4, and enforce step-by-step dependency gating that verifies database replica promotion and health checks before updating DNS and load balancer traffic routing.

Answer

Automate pre-drill validation tasks to audit and reserve regional resource quotas in us-east4, and enforce step-by-step dependency gating that verifies database replica promotion and health checks before updating DNS and load balancer traffic routing.
The optimal DR validation procedure combines proactive quota verification in the secondary region with orchestrated failover sequencing. Pre-verifying quota limits ensures that Compute Engine MIGs can scale to meet workload demands without unexpected capacity rejections. Sequential dependency gating guarantees that data tiers are fully promoted to primary read/write status and pass health checks before traffic ingress points (DNS and load balancers) are updated, preventing write errors during switchover.

Step-by-Step Solution

1
Analyze the DR drill failure causes
Identified two failure points: regional CPU quota exhaustion in us-east4 and premature traffic routing before database promotion completed.
DR procedures must address capacity readiness and execution order.
2
Evaluate capacity validation procedures
Proactive quota checks and capacity reservations in target regions ensure compute scaling will not be rejected during a drill or real emergency.
Quota approval involves manual/automated evaluation delays and cannot be relied on during runtime failover.
3
Establish orchestration and dependency validation steps
Enforce strict sequential ordering: promote database replica -> confirm database health -> switch network routing.
Routing live application traffic before database promotion leads to broken writes and transaction loss.

Key Concept

Developing Procedures for Business Continuity and Disaster Recovery Validation
Estimated Time:2m 0s
Question 762Question →

An enterprise organization needs to establish hybrid network connectivity between its on-premises environment and a Google Cloud Virtual Private Cloud (VPC). The business mandates a strict 99.99% service level availability (SLA) for the VPN connection to support mission-critical workloads. Which architecture should the cloud architect deploy to meet Google Cloud's requirements for a 99.99% availability SLA?

Show answer & explanation

Answer: Deploy an HA Cloud VPN gateway with two interfaces, configure two active VPN tunnels connected to two separate on-premises peer VPN gateway devices, and establish two BGP sessions on a Cloud Router using dynamic routing.

Answer

Deploying an HA Cloud VPN gateway with two interfaces, configuring two active tunnels pointing to separate on-premises peer devices, and running dynamic BGP sessions via Cloud Router satisfies the GCP 99.99% SLA requirement.
Google Cloud guarantees a 99.99% availability SLA for HA Cloud VPN when configured with complete redundancy. This requires an HA Cloud VPN gateway with two interfaces, two tunnels established to two separate on-premises peer gateways (or one peer gateway with two distinct public IPs), and dynamic BGP routing managed by Cloud Router across both tunnels.

Step-by-Step Solution

1
Identify the availability SLA requirement
The scenario requires a 99.99% availability SLA for hybrid VPN connectivity.
Google Cloud defines specific architectural topologies necessary to qualify for SLA tiers.
2
Evaluate HA Cloud VPN topology specifications for 99.99% SLA
GCP requires an HA Cloud VPN gateway (which has two interfaces, 0 and 1), two active tunnels connected to either two distinct on-premises peer devices or a single peer device with two separate public IP interfaces, and BGP dynamic routing.
Dynamic routing ensures instant path failover upon tunnel failure.
3
Select the option that configures Cloud Router and dual tunnels correctly
The option specifying an HA Cloud VPN gateway with two interfaces, two tunnels to separate on-premises peer devices, and BGP sessions on a Cloud Router is correct.
This full end-to-end redundancy provides complete redundancy at both the GCP and on-premises boundary.

Key Concept

HA Cloud VPN 99.99% Topology Requirements
Question 763Question →

A global logistics provider hosts a mission-critical fleet routing platform on Google Cloud. The primary architecture runs in us-east4 using Managed Instance Groups (MIGs) and a multi-region Cloud Spanner database instance. The organization requires a strict Disaster Recovery (DR) policy with a Recovery Point Objective (RPO) of near-zero and a Recovery Time Objective (RTO) of less than 15 minutes. During a scheduled regional failover validation exercise, traffic was redirected to the secondary standby region (us-west1). Although database synchronization succeeded, the MIG in us-west1 failed to scale up to handle the sudden burst of failover traffic because the project hit the regional compute CPU quota limit, resulting in extended service downtime and an RTO breach. Which procedure should the Cloud Architect mandate in the BCP/DR validation plan to prevent this issue in future failover drills?

Show answer & explanation

Answer: Implement a pre-drill validation checklist that auditing regional compute quota limits against anticipated failover demand and securing Compute Engine capacity reservations in the target DR region prior to executing failover drills.

Answer

Implement a pre-drill validation checklist that audits regional compute quota limits against anticipated failover demand and secures Compute Engine capacity reservations in the target DR region prior to executing failover drills.
The correct approach requires proactively verifying regional quotas and using Compute Engine capacity reservations in the target disaster recovery region prior to conducting failover drills. This guarantees that necessary compute capacity exists and is immediately allocable when failover traffic shifts, preventing RTO breaches caused by quota exhaustion.

Step-by-Step Solution

1
Analyze the root cause of the failure during the DR drill.
The failure occurred because the compute layer in the secondary region encountered regional quota exhaustion when attempting to scale up to accept production load.
GCP resource quotas are enforced per project per region. Even if code and configuration are valid, unmanaged quota limits block resource creation.
2
Evaluate the mandatory business objectives (RPO < 1 min, RTO < 15 min).
Any validation procedure must guarantee instant availability of compute capacity without asynchronous snapshot restoration delay or manual intervention.
Cold standby or on-demand quota escalation cannot meet strict RTO constraints during sudden regional failover.
3
Define the proper BCP and DR validation policy enhancement.
Incorporate explicit pre-validation quota verification and Compute Engine capacity reservations in the secondary region as part of standard DR drill execution procedures.
Capacity reservations guarantee project compute availability up to specified limits, eliminating quota bottlenecks during DR failover.

Key Concept

Disaster Recovery Capacity Planning and Regional Quota Validation
Estimated Time:3m 0s
Question 764Question →

A enterprise media corporation uses a Google Cloud folder structure to separate its digital publishing business unit from other corporate divisions. To satisfy strict corporate governance and compliance mandates, the lead security architect must guarantee that project administrators within this folder cannot grant IAM roles to any external personal accounts or unapproved third-party Google Workspace domains. This restriction must automatically apply to all existing projects and any future projects created within the folder. Which approach should the cloud architect recommend to meet these governance requirements?

Show answer & explanation

Answer: Set an Organization Policy using the Domain-Restricted Sharing constraint (constraints/iam.allowedPolicyMemberDomains) on the business unit folder node, specifying the approved Google Workspace customer ID.

Answer

Set an Organization Policy using the Domain-Restricted Sharing constraint (constraints/iam.allowedPolicyMemberDomains) on the business unit folder node, specifying the approved Google Workspace customer ID.
Applying an Organization Policy with the `constraints/iam.allowedPolicyMemberDomains` constraint at the targeted folder node enforces a security guardrail across all current and future child projects. It restricts IAM policy modifications so that only identities belonging to the specified Google Workspace customer ID or directory domain can be granted roles.

Step-by-Step Solution

1
Identify the governance objective
The goal is to restrict IAM policy membership strictly to authorized identity domains across a specific sub-hierarchy (folder) automatically.
Security guardrails preventing external account access across multiple projects require centralized constraints.
2
Evaluate Google Cloud governance mechanisms
Organization Policies enforce resource constraints hierarchically across projects, folders, and organizations. The specific constraint for restricting IAM member domains is constraints/iam.allowedPolicyMemberDomains.
IAM roles define what permissions an identity has, while Organization Policies restrict resource configurations and allowed configurations across the hierarchy.
3
Determine the resource hierarchy insertion point
Apply the policy constraint directly on the targeted Folder node.
Hierarchical inheritance ensures all present and future projects under that folder inherit the constraint automatically.

Key Concept

Domain-Restricted Sharing via Organization Policies
Question 765Question →

A fintech firm is reviewing its release engineering workflow for managing Google Cloud infrastructure using automated Cloud Build pipelines. During a software development lifecycle (SDLC) audit, the enterprise architect identifies two major vulnerabilities in the CI/CD architecture: concurrent build executions fail due to local state lock conflicts on ephemeral worker nodes, and the Cloud Build service account has been granted the administrative `roles/iam.serviceAccountAdmin` role to attach runtime service accounts to Compute Engine instance groups. Which combination of architectural modifications should the cloud architect implement to resolve these operational and security issues?

Show answer & explanation

Answer: Migrate the state backend to a Cloud Storage bucket with object versioning and state locking enabled, and replace `roles/iam.serviceAccountAdmin` with `roles/iam.serviceAccountUser` on the target deployment service accounts.

Answer

Migrate the state backend to a Cloud Storage bucket with object versioning and state locking enabled, and replace `roles/iam.serviceAccountAdmin` with `roles/iam.serviceAccountUser` on the target deployment service accounts.
The solution addresses both pipeline concurrency and security compliance. A Cloud Storage remote backend with locking ensures safe concurrent state mutations, while switching from Service Account Admin to Service Account User grants the minimum permission necessary to attach deployment identities to Compute Engine instances.

Step-by-Step Solution

1
Analyze the state management failure in the pipeline.
Local state files on ephemeral Cloud Build runners cause concurrency conflicts and state corruption risks.
Centralizing Infrastructure as Code state in Cloud Storage with native state locking guarantees atomic updates across concurrent pipeline executions.
2
Evaluate the service account IAM permissions.
Granting `roles/iam.serviceAccountAdmin` violates least-privilege security mandates.
Resources only require `roles/iam.serviceAccountUser` to attach or run under a service account, avoiding unnecessary identity administration capabilities.

Key Concept

CI/CD Pipeline Security and Remote State Governance
Question 766Question →

A financial media company is migrating two new application components to Google Cloud. Component 1 is a stateless containerized REST API microservice that processes incoming webhooks with highly variable traffic patterns, including extended periods of zero traffic. Component 2 is a containerized nightly data reconciliation task that runs once per day on a schedule and takes approximately 90 minutes to execute. The cloud architecture team requires a design that minimizes operational infrastructure management overhead and avoids paying for idle compute resources. Which TWO compute platform options should you select? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy Component 1 to Cloud Run services with autoscaling configured to scale down to zero instances when idle.; Deploy Component 2 as a Cloud Run job triggered on a daily schedule via Cloud Scheduler.

Answer

Deploy Component 1 to Cloud Run services (scaling to zero instances) and deploy Component 2 as a Cloud Run job triggered via Cloud Scheduler.
Cloud Run services provide fully managed hosting for stateless containerized APIs with scale-to-zero capability during zero-traffic windows. Cloud Run jobs efficiently handle containerized tasks that run to completion (up to 24 hours), avoiding idle infrastructure expenses when paired with Cloud Scheduler for invocation.

Step-by-Step Solution

1
Analyze Component 1 requirements (stateless REST API with intermittent traffic).
Cloud Run services provide serverless container hosting that automatically scales down to zero when idle.
This satisfies the requirement for stateless HTTP webhooks while eliminating idle compute charges and infrastructure management.
2
Analyze Component 2 requirements (scheduled batch task running for 90 minutes).
Cloud Run jobs execute containerized batch tasks to completion for up to 24 hours per run.
Combining Cloud Scheduler with Cloud Run jobs allows serverless scheduled batch processing without running dedicated VMs or managing clusters.

Key Concept

Selecting serverless compute platforms (Cloud Run services and Cloud Run jobs) to minimize operational overhead and baseline costs for stateless HTTP workloads and containerized batch tasks.
Question 767Question →

An enterprise cloud security architect is auditing how access rights are evaluated across a Google Cloud environment. When a principal attempts an action on a specific resource, IAM permissions are evaluated along the resource hierarchy. Arrange the following evaluation steps in the correct order, starting from the highest ancestor node in the hierarchy down to the specific target resource.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for IAM policy inheritance and evaluation moves down the resource hierarchy: Organization level -> Folder level -> Project level -> Resource level.
Google Cloud IAM follows a strict top-down resource hierarchy structure (Organization -> Folder -> Project -> Resource). Policies set at any node in the hierarchy are inherited by all of its descendants. Therefore, evaluating effective permissions begins at the Organization level, proceeds through parent Folders, checks Project bindings, and concludes at the specific Resource level.

Step-by-Step Solution

1
Identify the top-most root node of the Google Cloud resource hierarchy.
Organization-level IAM policies are evaluated first as the root ancestor.
Permissions granted at the organization level inherit down to all child nodes in the organization tree.
2
Trace policy inheritance through intermediate grouping containers.
Folder-level IAM policies are evaluated next along the parent folder path.
Folders allow grouping projects and inherit policies from the organization while passing them to child projects.
3
Evaluate access at the project container level.
Project-level IAM policies are evaluated.
Projects contain individual resources and inherit all permissions assigned at organization and folder ancestors.
4
Check permissions directly attached to the target service instance.
Resource-level IAM policies are evaluated to determine final effective access.
Fine-grained permissions can be bound directly to specific resources like BigQuery datasets or Cloud Storage buckets.

Key Concept

Google Cloud IAM Policy Inheritance and Resource Hierarchy Evaluation
Estimated Time:1m 30s
Question 768Question →

A financial technology company is analyzing its continuous integration and continuous delivery (CI/CD) deployment pipeline for security vulnerabilities and process reliability. Currently, developers run manual deployment scripts using personal credentials, leading to configuration drift and security risks. The cloud architecture team must transition the deployment process to Google Cloud native automation while enforcing least privilege and securing infrastructure state files. Which pipeline design best addresses these requirements?

Show answer & explanation

Answer: Configure Cloud Build to authenticate via Workload Identity Federation, execute builds using a dedicated user-managed service account with least privilege permissions, and persist state in a Cloud Storage bucket with object versioning enabled.

Answer

Configure Cloud Build to authenticate via Workload Identity Federation, execute builds using a dedicated user-managed service account with least privilege permissions, and persist state in a Cloud Storage bucket with object versioning enabled.
Configuring Cloud Build to use Workload Identity Federation replaces static service account keys with short-lived tokens, eliminating credential leak risks. Executing builds using a custom user-managed service account enforces least privilege. Persisting infrastructure state in Cloud Storage with object versioning secures state files against loss, corruption, and concurrency issues.

Step-by-Step Solution

1
Analyze security authentication requirements for CI/CD pipelines.
Identify that Workload Identity Federation avoids long-lived service account keys.
Short-lived tokens reduce credential theft risks from repository integration points.
2
Evaluate execution identity and permissions model.
Assign a dedicated user-managed service account with fine-grained roles.
Avoids over-privileged access like primitive Owner roles or unnecessary admin rights.
3
Determine persistent state management best practices.
Use Cloud Storage with object versioning and locking.
Prevents state file loss, configuration drift, and concurrent execution corruption.

Key Concept

Secure CI/CD Pipeline Design and IaC State Governance
Question 769Question →

A telecommunications enterprise organizes its Google Cloud resource hierarchy using an Organization node containing a parent folder named Telematics-Platform, which holds two sub-folders: Connected-Fleet-Prod and Connected-Fleet-Staging. External operational contractors require permissions to deploy Compute Engine instances and configure instance templates inside projects under Connected-Fleet-Prod only. The instances must run using specific existing service accounts. The security policy mandates strict adherence to the principle of least privilege, preventing contractors from modifying service account identity policies or accessing staging workloads. How should the principal cloud architect grant the required permissions?

Show answer & explanation

Answer: Grant the Compute Instance Admin (v1) role to the contractors' Google group on the Connected-Fleet-Prod folder, and grant the Service Account User role to the group on the specific workload service accounts.

Answer

Grant the Compute Instance Admin (v1) role to the contractors' Google group on the Connected-Fleet-Prod folder, and grant the Service Account User role to the group on the specific workload service accounts.
The solution requiring Compute Instance Admin (v1) at the Connected-Fleet-Prod folder level and Service Account User on specific target service accounts adheres strictly to least privilege. Scoping the compute role at the specific sub-folder prevents access to Connected-Fleet-Staging, while granting Service Account User permits contractors to launch instances under the workload identity without conferring administrative management over the service accounts.

Step-by-Step Solution

1
Analyze resource hierarchy boundaries for compute administration
Scoping Compute Instance Admin (v1) to the Connected-Fleet-Prod folder ensures contractors cannot access or modify instances within Connected-Fleet-Staging or parent folder levels.
IAM permissions inherit downward. Placing the binding at the sub-folder level isolates production resources while satisfying operational scope requirements.
2
Determine minimum required role for running workloads under service account identities
The Service Account User role (roles/iam.serviceAccountUser) allows principals to bind service accounts to compute resources.
Service Account User provides execution/impersonation permissions without permitting IAM policy modification or key creation on the service account.
3
Evaluate distractor security anti-patterns
Reject primitive roles, administrative service account roles, and relying solely on VPC Service Controls for identity authorization.
Least privilege mandates avoiding administrative rights over identity management and avoiding broad inherited primitive roles.

Key Concept

Resource Hierarchy Scoping and Service Account User Authorization
Estimated Time:2m 0s
Question 770Question →

An organization is executing a planned disaster recovery (DR) validation drill for a mission-critical web application on Google Cloud. Arrange the following steps into the correct sequence from first to last to ensure a successful failover test.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for DR validation is: (1) Verify resource quota limits and capacity availability in the target disaster recovery region, (2) Verify database replication catch-up and confirm that the Recovery Point Objective (RPO) target is met, (3) Promote the secondary database replica to primary status and scale up standby compute workloads, and (4) Update Cloud DNS records and global Cloud Load Balancing routing to direct client traffic to the secondary region.
A structured DR validation procedure progresses systematically: verifying environmental capacity (quotas), confirming data state and RPO compliance, promoting infrastructure and databases, and finally updating network routing to shift user traffic.

Step-by-Step Solution

1
Perform regional quota and capacity pre-checks.
Ensures that target Compute Engine and network quotas in the DR region are sufficient for failover.
Failing to check quota availability first can cause failover operations to fail mid-execution.
2
Check replication state and validate RPO compliance.
Confirms data catch-up state between primary and standby database instances.
Promoting a standby database before verifying replication status can cause data loss exceeding RPO limits.
3
Promote database and activate application instances.
Establishes a fully operational primary data layer and application pool in the secondary region.
Backend services must be online and healthy before accepting user requests.
4
Switch DNS and load balancer traffic routing.
User traffic is seamlessly redirected to the newly promoted secondary environment.
Routing traffic prior to infrastructure readiness results in failed user connections and outage errors.

Key Concept

Disaster Recovery Validation Procedure Sequence
Question 771Question →

A national smart power grid operator ingests real-time telemetry from millions of edge meters into Google Cloud across a primary region (us-central1) and a secondary disaster recovery region (us-east4). The organization must execute a scheduled business continuity validation drill to prove recovery capability without corrupting live state or exceeding target Recovery Point Objective (RPO) and Recovery Time Objective (RTO) limits. In what sequential order should the cloud architecture team execute the following procedure steps to validate regional disaster recovery failover?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with pre-drill quota and capacity reservation validation in the target region, followed by database state transition and integrity verification, then live traffic redirection via Cloud DNS and Global Load Balancing, followed by synthetic workload testing for RPO/RTO validation, and concludes with restoring cross-region database replication back to the primary region.
Disaster recovery validation requires a strict dependency order: verifying infrastructure capacity prerequisites (quota and reservations), transitioning the persistent state layer (database failover), shifting network ingress routing (DNS and load balancing), validating application health against RPO/RTO metrics using synthetic tests, and finally re-establishing reverse data replication to guarantee ongoing business continuity.

Step-by-Step Solution

1
Pre-drill infrastructure audit
Ensures us-east4 has sufficient quota and reserved compute instances ready to launch.
Failing to check quota prior to failover can lead to instance launch failures during peak load migration.
2
Database failover and data integrity check
Transitions database write leadership to us-east4 and confirms zero data loss.
Data persistence integrity must be guaranteed before live network traffic is allowed to write to the secondary location.
3
Network traffic steering transition
Switches ingress endpoints and DNS records to target us-east4 services.
Routing live client connections to an unready or non-primary database destination will cause system outages.
4
RPO/RTO validation and synthetic testing
Verifies that service performance and data integrity meet business continuity objectives.
Validation drills require explicit verification against business SLOs while operating in the secondary region.
5
Replication re-establishment and stabilization
Restores bidirectional or target-to-primary data sync for failback readiness.
A secondary region operating without an active replication target invalidates high availability post-failover.

Key Concept

Disaster Recovery Validation Procedures and Operational Execution Order
Question 772Question →

An enterprise logistics company is refactoring its automated software supply chain on Google Cloud. The architecture team requires a zero-trust CI/CD pipeline where deployment to Google Kubernetes Engine (GKE) is strictly gated by vulnerability analysis and cryptographic attestations via Binary Authorization. Arrange the pipeline stages in the correct execution order from initial source repository trigger to final cluster deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct pipeline sequence begins with Cloud Build compiling and pushing the container image to Artifact Registry, followed by Container Analysis vulnerability scanning, followed by Cloud KMS attestation generation via Binary Authorization attestor credentials, and concludes with Cloud Deploy pushing to GKE where Binary Authorization enforces signature verification.
The proper end-to-end SDLC order follows the logical security boundary of building, scanning, signing, and deploying. First, code build creates an image digest in Artifact Registry. Second, Container Analysis evaluates the stored digest. Third, an attestor signs the validation result via Cloud KMS. Fourth, Cloud Deploy and GKE Binary Authorization validate the signature at admission time.

Step-by-Step Solution

1
Identify the artifact creation phase
Cloud Build receives the repository trigger, builds the application container image, and pushes it to Artifact Registry to create an immutable image reference.
Security analysis and deployment targets require a central, immutable container digest stored in Artifact Registry before any validation can take place.
2
Analyze security compliance and vulnerability scanning
Container Analysis scans the image digest stored in Artifact Registry for CVEs and vulnerability compliance.
Attestations cannot be generated until the image is scanned and verified clean of blocking vulnerabilities.
3
Generate cryptographic attestation
Cloud Build uses an authorized attestor service account to sign an attestation payload using a Cloud KMS asymmetric key.
Attestations serve as digital signatures certifying that the build and scan pipeline stages completed successfully.
4
Enforce deployment policy gating
Cloud Deploy initiates deployment to GKE, where the GKE Binary Authorization admission controller verifies the cryptographic attestation signature before allowing pod creation.
Enforcement occurs at runtime admission; GKE blocks any container image deployment lacking valid attestations signed by the designated Cloud KMS key.

Key Concept

Software Supply Chain Security & CI/CD Gating with Binary Authorization
Question 773Question →

An organization wants to configure Workload Identity Federation to allow an on-premises application to access Google Cloud resources without using long-lived service account keys. In what sequence should the administrator perform the configuration steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by establishing trust via the Workload Identity Pool and Provider, followed by provisioning the target Google Cloud service account with minimal IAM permissions. Next, grant the external workload identity permission to impersonate the service account using the Workload Identity User role, and finally configure the application to execute dynamic short-lived token exchange.
The proper administrative order follows standard identity federation setup: establish trust infrastructure first (Pool/Provider), create the destination GCP service account with least privilege permissions second, attach the impersonation binding (`roles/iam.workloadIdentityUser`) third, and lastly update application code to perform short-lived token exchanges.

Step-by-Step Solution

1
Establish federation trust
Workload Identity Pool and Provider are created in Google Cloud.
Google Cloud must know how to validate tokens issued by the external identity provider before any authentication can take place.
2
Provision target identity
Dedicated Google Cloud service account created with least-privilege IAM roles.
Google Cloud resources require a native GCP identity (service account) to execute authorized API operations.
3
Grant impersonation rights
External workload identity granted roles/iam.workloadIdentityUser on the service account.
The external workload identity must explicitly receive permission to assume the identity of the GCP service account.
4
Configure application runtime token exchange
Application receives short-lived GCP access tokens dynamically.
The external application calls the Security Token Service (STS) to swap its local IDP token for a GCP credentials token.

Key Concept

Workload Identity Federation lifecycle configuration steps
Question 774Question →

An enterprise security architect is designing a centralized log aggregation framework across a multi-project Google Cloud organization. Cloud Audit Logs from all projects are exported via an organization-level log sink into a central Cloud Storage bucket. Security policy mandates that while authorized security analysts require read access to inspect audit records, they must be strictly prevented from copying or exfiltrating log data to Cloud Storage buckets residing outside the corporate GCP organization perimeter. Which architectural control should be implemented to satisfy this requirement?

Show answer & explanation

Answer: Establish a VPC Service Controls perimeter around the project hosting the central log storage bucket to restrict data egress to external Google Cloud projects and organizations.

Answer

Establish a VPC Service Controls perimeter around the project hosting the central log storage bucket to restrict data egress to external Google Cloud projects and organizations.
VPC Service Controls allow organizations to establish a security perimeter around GCP services (such as Cloud Storage containing aggregated audit logs). This prevents data exfiltration by blocking API requests that attempt to copy data from inside the perimeter to resources outside the perimeter, even when the user possesses valid IAM read permissions.

Step-by-Step Solution

1
Analyze security and compliance requirements
Identified the need to allow security analysts read access to central audit logs while preventing data exfiltration to external GCP resources.
Standard IAM permissions allow users with read access to write data to any external bucket they have access to.
2
Evaluate GCP perimeter security capabilities
Determined that VPC Service Controls provide context-aware perimeter boundaries that block unauthorized data movement (egress/ingress) across project boundaries.
VPC Service Controls protect against data exfiltration risks that IAM alone cannot mitigate.
3
Select the optimal control
Enclose the centralized logging storage bucket within a VPC SC security perimeter with strict egress rules.
This guarantees that audit log data remains inside the trusted perimeter regardless of user IAM privileges.

Key Concept

Data Exfiltration Prevention with VPC Service Controls
Question 775Question →

A global online multiplayer gaming enterprise hosts its real-time session management application on Google Cloud. The architecture uses Compute Engine Managed Instance Groups (MIGs) across a primary region and an secondary failover region, connected to a multi-region Cloud Spanner database for player profile states. The lead cloud architect is tasked with creating a standardized Disaster Recovery (DR) validation procedure to periodically test complete regional failover readiness without risking service disruption. Which validation procedure must be executed prior to initiating the compute failover drill to prevent deployment failures during DR execution?

Show answer & explanation

Answer: Audit and request required regional compute and network resource quota increases in the secondary disaster recovery region in advance of the scheduled validation drill.

Answer

Audit and request required regional compute and network resource quota increases in the secondary disaster recovery region in advance of the scheduled validation drill.
Pre-verifying and requesting necessary resource quota increases in the target DR region ensures that when failover occurs, the Managed Instance Groups can successfully scale to full operational capacity without failing due to project quota limits.

Step-by-Step Solution

1
Analyze the disaster recovery scenario and regional resource demands.
Identified that scaling up resources in a secondary failover region requires sufficient compute capacity quotas.
GCP regional quotas limit the maximum number of compute resources that can be provisioned in a given region.
2
Evaluate the pre-drill validation steps necessary to ensure seamless failover.
Confirmed that quota availability must be verified and requested ahead of time.
Quota approval can take time, and missing quotas will cause automated deployment or scaling scripts to fail during a disaster recovery scenario.

Key Concept

Disaster Recovery Validation and Resource Quota Management
Question 776Question →

An enterprise cloud architecture team is establishing a formal procedure to validate the scalability and performance of a critical Google Cloud workload prior to launch. Arrange the following steps of the technical solution testing procedure in the correct sequential order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for testing and validating the technical solution is: 1. Define target SLOs and baseline performance metrics, 2. Provision an isolated non-production testing environment, 3. Execute synthetic load tests while monitoring metrics and quota utilization, and 4. Analyze test results against defined SLOs and optimize parameters.
A complete technical solution validation procedure requires defining measurable success criteria (SLOs) first, establishing an isolated test environment second, conducting load testing while monitoring telemetry third, and evaluating results to optimize configurations fourth.

Step-by-Step Solution

1
Establish SLOs and performance baseline requirements.
Provides clear metric thresholds (e.g., p99 latency, throughput) to validate system behavior.
Validation cannot occur without knowing the success criteria upfront.
2
Deploy a mirrored non-production staging environment.
Produces a safe, isolated infrastructure that mimics production setup.
Prevents testing stress activities from interrupting live systems or altering production state.
3
Run synthetic stress and load tests while capturing telemetric data.
Reveals system bottlenecks, scaling behaviors, and regional GCP quota constraints under load.
Simulating real-world traffic reveals system constraints under stress.
4
Compare gathered telemetry against SLOs and apply remediations.
Ensures auto-scaling thresholds, resource sizing, and GCP quota limits meet readiness standards.
Closing the testing feedback loop verifies production readiness before actual deployment.

Key Concept

Structured Technical Solution Testing and Validation Procedures
Question 777Question →

An enterprise media streaming provider is executing a scheduled, non-disruptive disaster recovery (DR) validation procedure for its mission-critical workload hosted on Google Cloud. The application relies on Cloud Spanner for globally consistent state storage, Compute Engine Managed Instance Groups (MIGs) deployed across primary (`us-central1`) and failover (`us-east4`) regions, and Cloud DNS for global traffic routing. To ensure business continuity and satisfy compliance mandates without risking primary production operations, in what sequence should the cloud operations team execute the DR validation procedure steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct execution order for DR validation is: 1) Verify regional compute quotas in the failover region, 2) Validate Cloud Spanner cross-region replication against RPO targets, 3) Deploy isolated application test instances in the failover region, 4) Update Cloud DNS routing policies to measure RTO performance, and 5) Revert Cloud DNS routing to the primary region and tear down DR test resources.
A structured DR validation procedure follows a logical sequence: pre-flight resource/quota checks, data replication and RPO validation, isolated workload instantiation, traffic redirection for RTO assessment, and final failback cleanup. Requesting quotas first ensures target capacity exists. Validating RPO metrics prevents loss of data integrity. Running isolated test workloads protects production data. Updating DNS tests routing under test conditions, and restoring DNS followed by resource teardown concludes the procedure safely.

Step-by-Step Solution

1
Pre-verify quota availability in target DR region.
Ensures secondary region target resources can scale to match primary production demand.
Quota increases in GCP require time for approval; failing to check quota beforehand causes catastrophic scaling failures during actual or simulated failover.
2
Inspect storage replication lag and confirm RPO thresholds.
Guarantees data loss bounds remain within business limits prior to state transitions.
Cloud Spanner replication metrics must be healthy before cutting over service traffic.
3
Provision isolated test workloads in secondary region.
Validates infrastructure-as-code scripts, environment configurations, and startup scripts.
Isolation prevents test traffic from corrupting active production databases.
4
Update Cloud DNS and monitor RTO.
Measures real end-to-end failover time.
Routing updates evaluate global resolution propagation speeds against target business RTO metrics.
5
Revert traffic routing and clean up temporary test artifacts.
Restores primary baseline operation and avoids lingering resource costs.
Failback validation closes out the simulation loop safely.

Key Concept

Disaster Recovery Validation Procedures
Question 778Question →

An enterprise logistics company is analyzing its continuous integration and continuous delivery (CI/CD) pipelines used to manage Google Cloud infrastructure with Terraform and Cloud Build. During a pipeline security and operational analysis, the Cloud Architect identifies two significant vulnerabilities: concurrent pipeline executions corrupt local Terraform state files, and the Cloud Build service account has been granted primitive Project Editor privileges along with broad administrative rights over project service accounts. Which TWO actions should the architecture team implement to remediate these issues while adhering to Google Cloud best practices? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Migrate the Terraform state storage backend to a Cloud Storage bucket with object versioning and state locking enabled.; Replace primitive Editor roles on the Cloud Build service account with minimal predefined roles and grant 'roles/iam.serviceAccountUser' on specific deployment service accounts.

Answer

The team must migrate the Terraform state storage backend to a Cloud Storage bucket with object versioning and state locking enabled, and replace primitive Editor roles on the Cloud Build service account with minimal predefined roles while granting 'roles/iam.serviceAccountUser' on specific target service accounts.
To fix state corruption and enforce operational stability, Terraform state must be stored in a centralized Cloud Storage bucket configured with versioning and state locking. To secure the pipeline according to GCP least privilege practices, primitive Editor roles must be removed from the build service account and replaced with minimal predefined roles, combined with 'roles/iam.serviceAccountUser' granted specifically on deployment identities.

Step-by-Step Solution

1
Analyze the state management flaw in the CI/CD pipeline.
Identified that local unversioned state storage causes state corruption under concurrent pipeline executions.
Cloud Storage backends provide distributed state locking and object versioning to safeguard state integrity.
2
Analyze the Identity and Access Management (IAM) permissions flaw.
Identified excessive permissions from primitive Project Editor roles and administrative identity privileges.
Replacing primitive roles with fine-grained predefined roles and scoped Service Account User bindings enforces least privilege.

Key Concept

CI/CD Pipeline Security and Infrastructure as Code State Management
Question 779Question →

A Site Reliability Engineering (SRE) team is defining service level metrics for a critical cloud payment gateway to ensure technical metrics align with business revenue goals. Which TWO of the following practices correctly align technical Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with business impact? Select two.

Select all that apply

Show answer & explanation

Answer: Defining the Service Level Indicator (SLI) as the ratio of successful payment transactions to total attempted payment transactions.; Setting the Service Level Objective (SLO) target below 100% based on the acceptable business cost of minor downtime versus engineering effort.

Answer

The correct practices are defining the SLI as the ratio of successful payment transactions to total attempted transactions, and setting the SLO target below 100% based on acceptable business impact.
Defining an SLI based on successful transactions directly measures customer success and revenue flow. Furthermore, establishing SLO targets below 100% aligns technical goals with financial reality by balancing reliability costs against acceptable business downtime.

Step-by-Step Solution

1
Identify the metric that directly reflects user transaction success.
The proportion of successful transactions over total attempts captures the actual business goal (successful payments).
An SLI should measure service performance from the perspective of user and business impact.
2
Determine how the SLO target should be established relative to business needs.
Setting SLOs lower than 100% creates an error budget that allows feature velocity while keeping downtime within acceptable business risk.
100% uptime is rarely economically viable or necessary for business success.

Key Concept

Aligning SLIs and SLOs with Business Impact
Estimated Time:1m 0s
Question 780Question →

A financial analytics company is connecting its on-premises data center to a Google Cloud VPC to enable secure, dynamic routing for operational workloads with a required 99.99% service level agreement (SLA). The network design mandates automatic failover and dynamic route propagation without manual static route adjustments. Which TWO configuration steps must the cloud architect perform in Google Cloud to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Provision an High Availability (HA) Cloud VPN gateway with dual interfaces and configure two IPsec tunnels connected to the on-premises VPN router.; Configure a Cloud Router in the VPC network with a Google Autonomous System Number (ASN) to establish Border Gateway Protocol (BGP) sessions over the VPN tunnels.

Answer

To establish a 99.99% SLA hybrid connectivity topology with dynamic routing, the architect must deploy an HA Cloud VPN gateway with dual interfaces connecting two IPsec tunnels, and configure a Cloud Router to manage BGP sessions across those tunnels.
Achieving a 99.99% SLA for encrypted hybrid connectivity in Google Cloud strictly requires deploying an HA Cloud VPN gateway utilizing both interfaces connected to redundant on-premises VPN devices. Furthermore, HA Cloud VPN mandates the use of Cloud Router to establish dynamic BGP sessions for automated route propagation and zero-touch failover.

Step-by-Step Solution

1
Identify high-availability VPN architecture requirements.
Determine that HA Cloud VPN with dual interface tunnels is mandatory for achieving 99.99% uptime SLA.
Classic VPN only supports 99.9% availability, whereas HA Cloud VPN guarantees 99.99% availability when correctly deployed across two interfaces.
2
Establish dynamic routing capabilities.
Deploy a Cloud Router inside the target VPC network to handle BGP route exchange.
HA Cloud VPN requires Cloud Router to exchange dynamic BGP routes between on-premises routers and Google Cloud.

Key Concept

High Availability Cloud VPN and Dynamic BGP Routing via Cloud Router
PreviousPage 39 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin