Examkin

All practice questions

1598 questions

All types1,598Multiple choice815Multiple select537Numeric8Matching64Ordering174
Question 1361Question →

A global retail company is establishing hybrid connectivity between its primary on-premises data center and Google Cloud. The workload requires a continuous 20 Gbps low-latency connection backed by an enterprise SLA. Within Google Cloud, the architecture requires central governance for core services while allowing two isolated workload VPCs (Logistics and Inventory) to communicate with on-premises resources, while strictly preventing inter-VPC traffic between the two workload VPCs. Which network architecture should the cloud architect recommend?

Show answer & explanation

Answer: Provision a Dedicated Interconnect with multiple 10 Gbps circuits using Cloud Router for dynamic BGP routing, and implement a Shared VPC topology attaching the workload projects as Service Projects.

Answer

Provision a Dedicated Interconnect with multiple 10 Gbps circuits using Cloud Router for dynamic BGP routing, and implement a Shared VPC topology attaching the workload projects as Service Projects.
Dedicated Interconnect is the correct hybrid connection choice for high-throughput (20 Gbps) continuous enterprise traffic requiring an enterprise SLA. Coupled with a Shared VPC architecture, the Host Project manages the Cloud Routers and Interconnect attachments while Service Projects (Logistics and Inventory) securely utilize the network paths to on-premises without relying on non-transitive VPC Peering.

Step-by-Step Solution

1
Analyze bandwidth and SLA requirements for hybrid connectivity.
The requirement specifies continuous 20 Gbps throughput with an enterprise SLA, which exceeds HA VPN limits (3 Gbps per tunnel) and demands Dedicated Interconnect.
Dedicated Interconnect is required for workloads needing high bandwidth (10 Gbps or 100 Gbps links) and direct private connection to GCP.
2
Evaluate GCP VPC network topology requirements for multi-tenant service access and isolation.
Shared VPC allows central management of subnets and hybrid Interconnect resources in a Host Project while isolating workload resources in Service Projects without transitive peering limitations.
VPC Network Peering is non-transitive and would not allow spoke VPCs to reach on-premises through a peered hub VPC.

Key Concept

Hybrid Connectivity Selection and Shared VPC Topology Design
Question 1362Question →

A video broadcasting enterprise is migrating its core processing infrastructure to Google Cloud. The architecture requires a sustained hybrid connection throughput of 12 Gbps12\text{ Gbps} between their primary on-premises render farm and a primary Google Cloud Virtual Private Cloud (“vpc-render”). The hybrid connection must meet Google Cloud's 99.99%99.99\% availability SLA guidelines. Additionally, on-premises systems must be able to reach an administrative database hosted in a separate VPC (“vpc-admin”). The team initially planned to use VPC Network Peering between “vpc-render” and “vpc-admin” so that on-premises traffic arriving at “vpc-render” could flow through to “vpc-admin”. Which architectural design should a Cloud Architect recommend to satisfy the SLA, throughput, and connectivity requirements?

Show answer & explanation

Answer: Provision Dedicated Interconnect with 10 Gbps circuits across two distinct metropolitan locations terminating on Cloud Routers in a Shared VPC host network, and attach both render and admin workloads as service projects under the host VPC.

Answer

Provision Dedicated Interconnect with 10 Gbps circuits across two distinct metropolitan locations terminating on Cloud Routers in a Shared VPC host network, and attach both render and admin workloads as service projects under the host VPC.
To support 12 Gbps12\text{ Gbps} of sustained throughput with a 99.99%99.99\% SLA, Google Cloud requires Dedicated Interconnect deployed with dual circuits across two distinct metropolitan locations (facilities) terminating on Cloud Routers. Because VPC Network Peering is non-transitive and cannot route traffic from an on-premises Interconnect attachment to a peered VPC, combining the resources into a Shared VPC architecture ensures both workloads reside in service projects attached to the host VPC, providing direct reachability over the Dedicated Interconnect.

Step-by-Step Solution

1
Evaluate throughput and SLA requirements for hybrid connectivity
The requirement of sustained 12 Gbps12\text{ Gbps} throughput exceeds HA VPN limits (3 Gbps3\text{ Gbps} per tunnel) and single 10 Gbps links. Meeting the 99.99%99.99\% SLA requires Dedicated Interconnect deployed across 2 edge availability domains (metropolitan areas) with 4 VLAN attachments total.
Dedicated Interconnect is required for high-throughput (>10 Gbps>10\text{ Gbps}) enterprise links and SLA-backed redundant architecture.
2
Evaluate VPC topology for multi-VPC reachability from on-premises
VPC Network Peering does not support transitive routing; on-premises routers connected via Interconnect to one VPC cannot reach resources in a peered VPC.
Transitive routing restrictions in Google Cloud VPC Peering prevent on-premises traffic from hopping through a peered VPC network.
3
Select the correct unified network design
Consolidating networks under a Shared VPC host project allows both render and admin service projects to utilize the hybrid Dedicated Interconnect directly within the same underlying network fabric.
Shared VPC eliminates the need for transitive routing across peered VPC boundaries while satisfying centralized hybrid connectivity.

Key Concept

Designing High-Availability Hybrid Interconnect and Transitive VPC Topology
Estimated Time:2m 0s
Question 1363Question →

A global smart logistics enterprise tracks 500,000 delivery vehicles worldwide. Telemetry data is ingested via an HTTP endpoint that experiences severe traffic bursts during peak morning fleet dispatches but remains virtually idle overnight. The company needs to optimize its Google Cloud architecture to minimize Total Cost of Ownership (TCO) by eliminating idle compute infrastructure costs. Additionally, they must retain raw telemetry logs (over 1 TB per day) for 5 years to meet regulatory compliance requirements at the lowest possible storage cost. Which TWO architectural recommendations should you make to satisfy both business and cost optimization objectives?

Select all that apply

Show answer & explanation

Answer: Deploy the stateless HTTP telemetry ingestion endpoint on Cloud Run to enable automatic scaling down to zero instances during idle off-peak hours.; Configure an Object Lifecycle Management rule on the Cloud Storage bucket to transition raw telemetry objects to Archive Storage after 30 days.

Answer

Deploying the HTTP telemetry endpoint on Cloud Run and setting an Object Lifecycle Management policy to transition raw data to Cloud Storage Archive class.
The combination of Cloud Run for stateless HTTP ingestion and Cloud Storage Archive class for long-term log retention directly addresses both business requirements. Cloud Run automatically scales to zero instances when traffic drops overnight, ensuring the enterprise pays strictly per request execution time and incurs zero compute cost during idle periods. Transitioning raw telemetry logs to Cloud Storage Archive tier via Lifecycle Management provides the lowest cost storage option for high-volume, multi-year compliance archiving with low retrieval frequency.

Step-by-Step Solution

1
Analyze compute workload requirements for variable traffic patterns.
Identified that HTTP ingestion is stateless with extreme peak/off-peak variations, making scale-to-zero compute (Cloud Run) optimal over fixed baseline clusters (GKE).
Eliminating infrastructure spend during idle hours drastically lowers operational compute expenditure.
2
Analyze storage requirements for high-volume historical audit data.
Identified that 1 TB daily log data requires long-term retention for compliance with rare retrieval needs, pointing directly to Cloud Storage Archive tier.
Archive Storage provides the lowest cost per GB-month for multi-year compliance retention compared to transactional databases.

Key Concept

Serverless scale-to-zero compute paired with automated object storage tiering for TCO optimization.
Question 1364Question →

A global logistics provider needs to migrate 800 TB of historical telemetry archive files from an on-premises data center to Cloud Storage to support a new machine learning analytics initiative. The migration must complete within a strict 14-day business window. The facility's internet uplink is capped at 100 Mbps, and provisioning additional network bandwidth is cost-prohibitive. Which architectural strategy meets the business timeline while minimizing total migration cost?

Show answer & explanation

Answer: Order a Google Cloud Transfer Appliance, copy the data locally in the data center, ship the appliance to Google Cloud, and ingest the files into Cloud Storage.

Answer

Order a Google Cloud Transfer Appliance, copy the data locally in the data center, ship the appliance to Google Cloud, and ingest the files into Cloud Storage.
Transfer Appliance is a high-capacity storage server that allows organizations to transfer large volumes of data (hundreds of terabytes to petabytes) to Google Cloud off-network. Given the 100 Mbps uplink restriction, an online transfer of 800 TB is mathematically unfeasible within 14 days. Transfer Appliance satisfies both the tight deadline and the requirement to minimize cost without incurring heavy network infrastructure setup fees.

Step-by-Step Solution

1
Calculate the theoretical minimum network transfer time required for the dataset
At a maximum speed of 100 Mbps (12.5 MB/s12.5\text{ MB/s}), transferring 800 TB800\text{ TB} requires 800×1012 bytes12.5×106 bytes/s≈64,000,000 seconds≈740 days\frac{800 \times 10^{12}\text{ bytes}}{12.5 \times 10^6\text{ bytes/s}} \approx 64,000,000\text{ seconds} \approx 740\text{ days}.
Evaluating network transfer throughput proves that online migration strategies cannot meet the 14-day target.
2
Evaluate offline migration alternatives against business constraints
Google Cloud Transfer Appliance allows high-speed local data ingestion onto encrypted hardware, physical transport, and direct upload in Google Cloud data centers within a standard turnaround time of a few days.
Offline physical transfer bypassed network bandwidth limitations completely while remaining significantly cheaper than provisioning short-term high-speed dedicated circuits.
3
Select the optimal architectural decision based on cost and time feasibility
Transfer Appliance fulfills the 14-day SLA at the lowest overall operational cost.
It avoids over-provisioning infrastructure or failing the timeline requirements.

Key Concept

Selecting Data Transfer Strategies based on Dataset Size, Available Bandwidth, and Cost Constraints
Question 1365Question →

A cloud administrator is preparing to provision compute resources for a stateless web application using Compute Engine Managed Instance Groups (MIGs) via an automated deployment pipeline. Which TWO steps should the administrator take to ensure correct IAM privilege bounds and avoid provisioning failure during initial deployment? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Request a regional Compute Engine CPU quota increase in advance if forecasted autoscaling peak capacity exceeds default project quotas.; Grant the deployment service account the Service Account User role on the instance runtime service account.

Answer

The correct steps are requesting a regional CPU quota increase in advance if expected peak capacity exceeds limits, and granting the deployment service account the Service Account User role on the runtime service account.
Requesting quota increases in advance ensures compute instances can scale out to required capacity without failing due to regional limits. Additionally, granting the Service Account User role (`roles/iam.serviceAccountUser`) allows the deployment service account to attach the designated runtime service account to VM instances securely without requiring over-privileged administrative access.

Step-by-Step Solution

1
Assess resource quota requirements and identity permission bounds for compute provisioning.
Identified that autoscaling workloads require sufficient regional CPU quota and deployment identities require specific service account impersonation permissions.
Ensures deployment pipelines complete successfully without hitting quota caps or encountering access permissions errors.
2
Evaluate IAM configuration against the principle of least privilege.
Selected the Service Account User role grant over broad primitive role assignments.
Provides the precise permission required to attach the service account to compute resources securely.

Key Concept

Provisioning Compute Engine resources requires proactive regional quota management and fine-grained IAM configuration using minimal necessary role grants.
Question 1366Question →

An enterprise lead architect is evaluating GCP hybrid networking topologies for four distinct enterprise business units. Match each architectural scenario on the left with the single most appropriate GCP network connectivity solution on the right that meets all throughput, security, SLA, and connectivity requirements.

Click a left item, then click its matching right item

Items

Scenario 1: A financial analytics platform requires a dedicated, unencrypted, high-throughput physical pipe (10 Gbps+) extending on-premises data centers directly to GCP with a 99.99% availability SLA across two colocation domains without traversing the public internet.
Scenario 2: A remote branch site requires encrypted IPsec tunnel connectivity to GCP over existing commodity public internet circuits, utilizing Cloud Router with dynamic BGP route propagation and providing a 99.99% availability SLA.
Scenario 3: An enterprise requires sub-10 Gbps private hybrid connectivity from an on-premises facility where direct colocation with a Google edge Point of Presence (PoP) is physically unavailable, requiring SLA guarantees managed by a third-party carrier.
Scenario 4: Two independent GCP VPC networks across separate projects require low-latency, private RFC 1918 internal IP communication without using intermediate VPN gateways or paying for external transit.

Matches

Show answer & explanation

Answer

The correct mapping pairs Scenario 1 with Dedicated Interconnect (high-throughput direct physical connection meeting 99.99% SLA); Scenario 2 with HA Cloud VPN (encrypted IPsec over public internet with dynamic BGP routing); Scenario 3 with Partner Interconnect (service provider connection where Google colocation edge is unavailable); and Scenario 4 with VPC Network Peering (direct private inter-VPC connectivity).
The solution accurately pairs each architectural constraint to its definitive GCP networking component: Dedicated Interconnect for direct physical 10 Gbps+ connections; HA Cloud VPN for encrypted internet-based IPsec tunnels; Partner Interconnect for non-colocated locations using carrier services; and VPC Network Peering for internal inter-VPC traffic.

Step-by-Step Solution

1
Analyze Scenario 1 requirements
Identified direct physical link requirement (>10 Gbps, 99.99% SLA, no public internet).
Dedicated Interconnect is the only GCP product providing direct physical circuit extension with 99.99% SLA.
2
Analyze Scenario 2 requirements
Identified encrypted IPsec tunnel over public internet with 99.99% SLA and dynamic BGP.
HA Cloud VPN mandates dual active-active tunnels with Cloud Router BGP to achieve 99.99% availability over internet circuits.
3
Analyze Scenario 3 requirements
Identified third-party service provider requirement due to lack of direct Google colocation presence.
Partner Interconnect is specifically designed for hybrid connections where customers connect through service providers.
4
Analyze Scenario 4 requirements
Identified inter-VPC private IP communication across projects without intermediate gateways.
VPC Network Peering enables direct, non-transitive, high-speed private RFC 1918 interconnectivity between VPCs.

Key Concept

Designing Enterprise GCP Network Topologies and Hybrid Connectivity Options
Question 1367Question →

An autonomous vehicle simulation enterprise is designing its cloud architecture on Google Cloud for two distinct workload components:

1. Workload A: A stateless HTTP REST API endpoint that receives vehicle telemetry webhooks with highly unpredictable, bursty traffic patterns. The requirement specifies automatic scaling down to zero instances during idle periods and zero operational overhead for cluster plane or OS management.
2. Workload B: A specialized simulation engine that requires custom kernel parameter tuning (`sysctl`), raw non-HTTP TCP socket listening, and direct access to local NVMe SSD storage.

Which TWO platform architectural decisions should the Cloud Architect recommend? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy Workload A on Cloud Run to achieve stateless HTTP container execution with scale-to-zero capabilities and minimal operational management.; Deploy Workload B on Compute Engine virtual machine instances configured with attached local SSDs to support custom OS kernel modifications and raw TCP socket networking.

Answer

The optimal solution requires deploying Workload A on Cloud Run for stateless serverless HTTP execution with scale-to-zero capabilities, and deploying Workload B on Compute Engine instances with local NVMe SSDs to accommodate custom kernel configuration and raw TCP networking requirements.
Cloud Run is the ideal fully managed serverless platform for stateless HTTP webhooks because it automatically scales down to zero when idle and eliminates OS and cluster maintenance overhead. Compute Engine is required for workloads that demand OS-level access, such as custom kernel parameter tuning (`sysctl`), non-HTTP TCP sockets, and direct local NVMe SSD attachment.

Step-by-Step Solution

1
Analyze the requirements for Workload A
Identified stateless HTTP webhooks, bursty traffic, scale-to-zero requirement, and zero operational infrastructure management.
Cloud Run is purpose-built for fully managed stateless container workloads serving HTTP/HTTPS requests with native scale-to-zero capabilities.
2
Analyze the requirements for Workload B
Identified requirement for custom Linux kernel parameters (`sysctl`), non-HTTP raw TCP socket networking, and local NVMe SSD attachment.
Compute Engine provides full administrative access to the virtual machine operating system, kernel parameters, custom protocol networking, and hardware attachment.
3
Evaluate and eliminate unsuitable platform choices
GKE introduces unnecessary cluster overhead for simple webhooks (Workload A), App Engine Standard prevents OS kernel tuning (Workload B), and Compute Engine MIGs incur idle costs for bursty workloads.
Aligning compute platforms to specific operational boundaries optimizes both cost and administrative efficiency.

Key Concept

Selecting GCP Compute Platforms based on operational overhead, container statefulness, OS/kernel customization needs, and autoscaling profiles.
Question 1368Question →

An enterprise online gaming company is connecting its primary on-premises data center to a Google Cloud Virtual Private Cloud (VPC) to stream real-time multiplayer state telemetry. The solution must guarantee a 99.99% service level agreement (SLA) for physical connectivity, provide dynamic BGP route exchange, and enforce end-to-end IPsec encryption over private IP space for high-throughput traffic exceeding 5 Gbps. Which TWO configurations must you implement to achieve this architecture according to Google Cloud best practices?

Select all that apply

Show answer & explanation

Answer: Provision four Dedicated Interconnect connections across two distinct metropolitan areas (two connections in separate Edge Availability Domains per metro) paired with Cloud Routers in two GCP regions to establish the 99.99% availability baseline.; Deploy HA VPN gateways configured with private IP addresses (HA VPN over Cloud Interconnect) over the Interconnect VLAN attachments to encrypt traffic in transit.

Answer

To meet the requirements, you must provision four Dedicated Interconnect connections deployed across two metros and two Edge Availability Domains per metro with Cloud Routers to meet the 99.99% SLA topology requirement, and deploy HA VPN gateways using private IP addressing (HA VPN over Cloud Interconnect) over the VLAN attachments to provide end-to-end IPsec encryption.
Achieving a 99.99% SLA for Dedicated Interconnect requires four total interconnect connections split evenly across two distinct metros and two Edge Availability Domains per metro, terminating on Cloud Routers in separate regions. Additionally, enforcing IPsec encryption over this private connection requires deploying HA VPN over Cloud Interconnect using private IP addressing for the VPN gateways.

Step-by-Step Solution

1
Analyze the physical transport availability requirement for 99.99% SLA.
Google Cloud's 99.99% SLA architecture for Cloud Interconnect mandates 4 connections total: 2 connections in Metro 1 (across EAD 1 and EAD 2) and 2 connections in Metro 2 (across EAD 1 and EAD 2), attached to redundant Cloud Routers in two regions.
Designing fewer than 4 connections across 2 metros only yields a 99.9% SLA or less.
2
Analyze the security requirement for IPsec encryption over private dedicated infrastructure.
Standard Dedicated Interconnect does not encrypt packets by default. To encrypt traffic on private Interconnect circuits without passing over the public internet, deploy HA VPN over Cloud Interconnect using private IP addresses.
Private IP HA VPN attaches directly to Interconnect VLAN attachments, allowing high-throughput IPsec encrypted tunnels within the private physical link.

Key Concept

Configuring 99.99% SLA Dedicated Interconnect topology combined with HA VPN over Cloud Interconnect using private IPs for encrypted hybrid connectivity.
Question 1369Question →

A global online retailer uses Google Cloud with a multi-level resource hierarchy: Organization Root → Production Folder → E-Commerce Folder → Payment-Service Project. An Organization Policy applied at the Production Folder sets the `gcp.resourceLocations` constraint to `allowedValues: ["in:us-locations"]` with `inheritFromParent: false`. The security team now needs to permit a specialized payment module inside the Payment-Service Project to deploy resources in `europe-west3`, while ensuring three strict governance rules:
1. All sibling projects under the E-Commerce Folder must remain restricted to `us-locations`.
2. Any new location constraints added at the Organization Root or Production Folder in the future must automatically merge and apply to the Payment-Service Project.
3. The security team must test a new constraint restricting public IP addresses (`compute.vmExternalIpAccess`) across the Production Folder to measure compliance impact without blocking active developer deployments.

Which combination of Organization Policy configurations correctly fulfills all security and operational requirements?

Show answer & explanation

Answer: At the Payment-Service Project level, configure `gcp.resourceLocations` with `allowedValues: ["europe-west3"]` and set `inheritFromParent: true`. At the Production Folder level, apply `compute.vmExternalIpAccess` in dry-run mode.

Answer

Configure the `gcp.resourceLocations` policy at the Payment-Service Project level to explicitly allow `europe-west3` while setting `inheritFromParent: true`, and apply the `compute.vmExternalIpAccess` constraint in dry-run mode at the Production Folder level.
The correct approach configures `gcp.resourceLocations` on the target project with `allowedValues: ["europe-west3"]` and `inheritFromParent: true`. This inherits `in:us-locations` from the parent Production Folder while permitting `europe-west3` specifically for this project, and guarantees that any future parent-level restrictions are inherited. Additionally, applying `compute.vmExternalIpAccess` in dry-run mode at the Production Folder allows the security team to audit non-compliant public IP configurations in Cloud Logging without interrupting current deployments.

Step-by-Step Solution

1
Analyze the location constraint hierarchy requirement
The Production Folder restricts deployments to `us-locations`. To add `europe-west3` at the Payment-Service Project without overriding parent policies or affecting sibling projects, the project policy must append `europe-west3` to `allowedValues` and set `inheritFromParent: true`.
Setting `inheritFromParent: true` ensures that the local allowed values are evaluated in addition to inherited parent values (`us-locations`), and allows future parent policy additions to propagate automatically.
2
Evaluate the requirement for testing public IP restrictions without breaking operations
Configure the `compute.vmExternalIpAccess` constraint at the Production Folder level using `dry-run` enforcement.
Dry-run enforcement logs policy violations to Cloud Logging and Security Command Center, enabling security teams to audit compliance impact without blocking existing CI/CD pipelines or developer workflows.

Key Concept

Google Cloud Organization Policy inheritance, list constraint merging via inheritFromParent, and dry-run policy enforcement.
Estimated Time:3m 0s
Question 1370Question →

An engineering team is building a secure CI/CD pipeline on Google Cloud Platform to deploy a microservice to Cloud Run. Arrange the following SDLC pipeline stages in the correct chronological order from developer commit to full production deployment.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the GCP CI/CD deployment pipeline is: 1) Developer commits source code to Cloud Source Repositories, 2) Cloud Build executes unit tests and builds the container image, 3) Artifact Analysis scans the image for vulnerabilities before storing in Artifact Registry, 4) Cloud Build deploys the new revision to Cloud Run with a 10% canary traffic split, and 5) Cloud Build routes 100% of traffic to the new revision after health checks pass.
The correct sequence follows Google Cloud CI/CD best practices: Source Commit -> Build & Test -> Security Vulnerability Scan -> Canary Traffic Deployment -> 100% Traffic Promotion.

Step-by-Step Solution

1
Identify the pipeline trigger stage.
Developer commit to source control initiates the continuous integration workflow.
Automated pipelines are triggered by code changes pushed to repository branches.
2
Identify the build and integration testing stage.
Cloud Build compiles the container image and runs unit tests.
Code must pass automated tests and build successfully prior to artifact storage.
3
Identify the security governance stage.
Artifact Analysis scans the container image for vulnerabilities before pushing to Artifact Registry.
Vulnerability scanning ensures compromised dependencies are identified before deployment.
4
Identify the initial deployment strategy.
Cloud Build creates a Cloud Run revision with a 10% canary traffic split.
Canary releases minimize blast radius by validating the update against real production traffic.
5
Identify the final production promotion stage.
Shift 100% of production traffic to the new Cloud Run revision.
Full promotion occurs only after metric monitoring verifies the canary release is stable.

Key Concept

Sequencing CI/CD pipeline stages from source code trigger to vulnerability scanning and canary deployment on GCP.
Question 1371Question →

An enterprise organization has established a hub-and-spoke network topology in Google Cloud using VPC Network Peering to connect a central Operations VPC (Hub) with two isolated workload environments: Production VPC (Spoke 1) and Staging VPC (Spoke 2). Virtual machines in both workload VPCs can successfully communicate with shared management utilities inside the Operations VPC. However, virtual machines in the Production VPC are unable to reach virtual machines in the Staging VPC. The architecture team mandates establishing direct, private internal IP connectivity between the Production VPC and Staging VPC while preserving sub-millisecond latency and avoiding public exposure or transit costs. Which architectural change should the Cloud Architect implement to satisfy this requirement?

Show answer & explanation

Answer: Establish a direct VPC Network Peering connection between the Production VPC and the Staging VPC.

Answer

Establish a direct VPC Network Peering connection between the Production VPC and the Staging VPC.
Google Cloud VPC Network Peering is inherently non-transitive. If VPC A is peered to VPC B, and VPC B is peered to VPC C, VPC A cannot reach VPC C through VPC B. To enable direct private communication between two spoke VPCs, a direct VPC Network Peering connection must be created explicitly between those two spoke networks.

Step-by-Step Solution

1
Analyze the existing connectivity model and restriction.
The current topology relies on VPC Network Peering between a central Hub network and two spoke networks (Spoke 1 and Spoke 2). Spoke 1 can communicate with Hub, and Spoke 2 can communicate with Hub.
VPC Network Peering in Google Cloud is strictly non-transitive by design.
2
Evaluate why transit routing through the Hub fails.
Traffic from Spoke 1 directed to Spoke 2 cannot cross the Hub VPC because peered routes from Spoke 2 are not re-advertised or forwarded to Spoke 1 through the Hub.
Google Cloud network architecture enforces non-transitivity to prevent unintentional route propagation across peered VPC boundaries.
3
Determine the optimal solution meeting private connectivity, low latency, and non-public IP requirements.
Establishing a direct VPC Network Peering link between Production VPC and Staging VPC establishes direct internal IP routing between them without intermediate gateway overhead.
Direct peering connects the two networks at the Virtual Network stack level, providing low-latency, full-bandwidth private internal communication.

Key Concept

Non-transitivity of Google Cloud VPC Network Peering
Estimated Time:2m 0s
Question 1372Question →

An organization is establishing an automated, secure continuous integration and continuous delivery (CI/CD) pipeline on Google Cloud to deploy containerized applications to Google Kubernetes Engine (GKE). Arrange the following pipeline execution stages in the correct sequence from developer code commit to final production verification.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for the CI/CD pipeline is: 1) Trigger Cloud Build via repository webhook on code commit, 2) Perform vulnerability scanning with Artifact Analysis before pushing to Artifact Registry, 3) Validate and execute Terraform IaC manifests against GKE, 4) Deploy to staging environment via Cloud Deploy for integration testing, and 5) Promote the release to production via Cloud Deploy with Cloud Monitoring verification.
The sequence follows Google Cloud SDLC best practices: Source trigger -> Build & Security scanning -> Infrastructure/Manifest update -> Staging deployment & testing -> Production promotion & health monitoring.

Step-by-Step Solution

1
Identify the entry point of the continuous integration process.
Code commit triggers the Cloud Build pipeline via webhooks to run unit tests.
CI/CD execution begins at the source control stage.
2
Determine the secure build and artifact generation step.
Images are scanned by Artifact Analysis for vulnerability checks prior to repository storage.
Security shift-left requires scanning artifacts before storing or using them.
3
Locate the infrastructure and environment configuration phase.
Terraform state is checked and GKE manifest changes are applied.
Infrastructure and deployment manifests must be updated with new image tags prior to application deployment.
4
Identify non-production deployment and testing.
Cloud Deploy deploys the application to the staging GKE cluster.
Applications must undergo integration tests in staging before reaching production.
5
Determine the final release promotion step.
Cloud Deploy promotes the build to production while monitoring health indicators.
Production promotion is the final phase of continuous delivery.

Key Concept

Continuous Integration and Continuous Delivery (CI/CD) Pipeline Sequencing and Security
Question 1373Question →

A healthcare software provider is deploying a multi-tenant clinical application on Google Kubernetes Engine (GKE) across multiple Google Cloud projects. The compliance framework requires a security architecture that detects container-level runtime anomalies (such as unexpected binary executions or reverse shells) without injecting third-party agent containers into application pods, while strictly preventing unsigned or vulnerable container images from deploying to the GKE clusters. How should the cloud security architect design this solution using native Google Cloud services?

Show answer & explanation

Answer: Enable Security Command Center Premium to leverage built-in Container Threat Detection for agentless hypervisor-level runtime monitoring, configure continuous scanning in Artifact Registry via Container Analysis, and enforce a Binary Authorization policy requiring Cloud KMS-backed attestations prior to deployment.

Answer

Enable Security Command Center Premium for agentless Container Threat Detection, use Container Analysis for vulnerability scanning in Artifact Registry, and enforce deployment gates with Binary Authorization and Cloud KMS attestations.
The solution combining Security Command Center Premium (Container Threat Detection), Container Analysis, and Binary Authorization natively satisfies all three enterprise security requirements. Container Threat Detection performs agentless monitoring of container runtime behavior at the hypervisor/kernel level; Container Analysis scans images in Artifact Registry for vulnerabilities; and Binary Authorization enforces deployment gates using Cloud KMS attestations.

Step-by-Step Solution

1
Address agentless container runtime monitoring requirements.
Security Command Center (SCC) Premium Container Threat Detection inspects node kernel logs and container behaviors natively without injecting sidecars or third-party agents into application workloads.
Meets the constraint for zero-agent runtime anomaly detection.
2
Implement vulnerability scanning for stored container images.
Container Analysis performs automated vulnerability scanning on images stored in Artifact Registry.
Ensures software dependencies and OS packages are continuously evaluated for known CVEs.
3
Enforce container deployment compliance controls.
Binary Authorization integrates with CI/CD and GKE to block deployment of images that lack a valid cryptographic attestation signed via Cloud KMS.
Guarantees that only trusted, verified images reaching compliance criteria can run on the cluster.

Key Concept

Multi-Layered Native GCP Container Security Architecture (Binary Authorization, Container Analysis, and SCC Container Threat Detection)
Question 1374Question →

A global pharmaceutical enterprise operates a mission-critical clinical trial telemetry ingestion platform on Google Cloud. The primary architecture runs in us-east4 with a secondary disaster recovery (DR) environment in us-west1. The system has a strict Recovery Point Objective (RPO) of 1 minute and a Recovery Time Objective (RTO) of 15 minutes. During a scheduled DR validation exercise, engineers simulated a primary region outage by updating Cloud DNS routing policies to direct incoming traffic to us-west1. Although cross-region data replication was up to date, the failover validation failed because auto-scaling Compute Engine Managed Instance Groups in us-west1 hit regional vCPU quota limits, preventing required instances from launching within the target RTO. Which procedure should the Cloud Architect incorporate into the disaster recovery validation framework to ensure RTO compliance during future failover drills?

Show answer & explanation

Answer: Implement automated pre-drill validation checks to verify regional quota availability and maintain Reserved Instance Capacity (capacity reservations) in the target DR region.

Answer

Implement automated pre-drill validation checks to verify regional quota availability and maintain Reserved Instance Capacity (capacity reservations) in the target DR region.
The correct strategy involves combining pre-drill automated quota validation checks with Compute Engine Capacity Reservations in the DR region. This ensures that the secondary region has both sufficient quota quota allocation and guaranteed compute capacity to spin up resources immediately, satisfying strict RTO requirements.

Step-by-Step Solution

1
Analyze the root cause of the DR validation failure.
The failover failed RTO constraints because Compute Engine instances could not scale up in the secondary region due to regional quota exhaustion.
Quota limits are enforced per region, and high-demand compute resources cannot be provisioned on demand if the project's regional quota is insufficient.
2
Evaluate GCP mechanism to ensure resource availability for strict RTO requirements.
Compute Engine Capacity Reservations allow reserving compute capacity in a specific zone/region so instances can launch immediately when needed.
Reservations guarantee capacity and protect against both quota limits (when combined with adequate quota limits) and stockouts during disaster recovery events.
3
Integrate capacity verification into the DR validation framework.
Establishing continuous pre-drill automated checks ensures quota sufficiency and reservation validity before an actual or simulated disaster drill takes place.
Proactive validation eliminates surprises during live DR failovers.

Key Concept

Disaster Recovery Capacity Planning and Quota Validation
Question 1375Question →

An enterprise organization maintains a centralized network architecture in Google Cloud. A primary network project contains a Virtual Private Cloud network named hub-vpc, which connects to an on-premises datacenter via Dedicated Interconnect using Cloud Router dynamic routing. Application workloads are deployed in a separate project within a Virtual Private Cloud network named spoke-vpc. You need to provide private layer-3 reachability so compute instances in spoke-vpc can communicate with on-premises servers over the existing Dedicated Interconnect connection. Which network topology configuration should you implement?

Show answer & explanation

Answer: Establish VPC Network Peering between hub-vpc and spoke-vpc, and configure the peering connection to export custom routes from hub-vpc and import custom routes into spoke-vpc.

Answer

Establish VPC Network Peering between hub-vpc and spoke-vpc, configuring the peering connection to export custom routes from hub-vpc and import custom routes into spoke-vpc.
Establishing VPC Network Peering directly between hub-vpc and spoke-vpc while enabling custom route export on hub-vpc and custom route import on spoke-vpc allows dynamic routes learned via Dedicated Interconnect in hub-vpc to be propagated directly into spoke-vpc's routing table.

Step-by-Step Solution

1
Identify the requirement for inter-VPC reachability to on-premises resources over Dedicated Interconnect.
Recognize that compute instances in spoke-vpc require routes to the on-premises IP ranges learned by Cloud Router in hub-vpc.
Cloud Router in hub-vpc learns on-premises routes via BGP over Dedicated Interconnect VLAN attachments.
2
Evaluate VPC Network Peering routing capabilities and limitations.
Determine that VPC Network Peering allows sharing subnets and dynamic custom routes between directly peered networks, but routing is non-transitive across multiple peering hops.
Direct peering between hub-vpc and spoke-vpc is required, along with enabling custom route flags.
3
Configure custom route export and import flags on the VPC Network Peering connection.
hub-vpc exports custom routes (on-premises BGP learned routes) and spoke-vpc imports custom routes, enabling bidirectional communication between spoke-vpc and on-premises.
By default, VPC Network Peering only exchanges subnet routes; custom route flags must be explicitly enabled to propagate dynamic BGP routes across peering boundaries.

Key Concept

VPC Network Peering Custom Route Exchange
Estimated Time:1m 30s
Question 1376Question →

An enterprise cloud security architect is standardizing the data encryption strategy across Google Cloud workloads to satisfy varying regulatory and security control mandates. Match each organizational key control requirement on the left with its corresponding Google Cloud encryption mechanism on the right.

Click a left item, then click its matching right item

Items

Requirement for full key governance where raw AES-256 keys are supplied directly in API request headers and purged from Google Cloud memory immediately after cryptographic operations.
Mandate to enforce automated encryption at rest across standard resources with zero key lifecycle management overhead, utilizing Google-managed key infrastructure.
Regulatory requirement to retain root cryptographic key material outside of Google Cloud infrastructure in a third-party key management system.
Mandate to control key rotation schedules, key access permissions, and auditing while leveraging key infrastructure hosted natively inside Google Cloud.

Matches

Show answer & explanation

Answer

Supplying raw keys in API headers pairs with Customer-Supplied Encryption Keys (CSEK); zero-overhead automated encryption pairs with Google-default encryption; retaining keys in an external third-party HSM pairs with Cloud External Key Manager (Cloud EKM); native Cloud KMS key administration pairs with Customer-Managed Encryption Keys (CMEK).
Each organizational constraint maps directly to a distinct GCP encryption tier: supplying raw keys transiently in headers matches CSEK; hands-off automatic protection matches Google-default encryption; external off-cloud key storage matches Cloud EKM; and native key control and access policy management matches CMEK via Cloud KMS.

Step-by-Step Solution

1
Analyze key ownership location and API interaction mode for raw key headers
Identified requirement matching CSEK, where raw key material is passed directly per request.
CSEK is specifically designed for scenarios where the customer holds raw keys off-cloud and sends them in ephemeral request headers.
2
Analyze standard default baseline protection without customer key intervention
Identified Google-default encryption.
Google Cloud automatically encrypts all customer data at rest by default without requiring user configuration.
3
Analyze external HSM integration requirements
Identified Cloud External Key Manager (Cloud EKM).
Cloud EKM connects Cloud KMS with an external third-party Key Management System residing outside Google Cloud.
4
Analyze native GCP key management governance
Identified CMEK via Cloud KMS.
CMEK allows management of key lifecycle policies, rotation, and IAM access using Cloud KMS/HSM hosted natively inside GCP.

Key Concept

Classification of Google Cloud Encryption Modes (Google-default, CMEK, CSEK, Cloud EKM)
Question 1377Question →

A financial technology company's platform operations and development teams manage infrastructure across Google Cloud projects using an external CI/CD pipeline and Terraform. The teams face two critical operational issues: CI/CD deployments rely on long-lived service account JSON keys stored in third-party runner secrets, creating a security compliance risk; additionally, developers frequently perform manual emergency configuration changes in the Cloud Console, causing severe state drift and deployment pipeline failures. As the Cloud Architect advising these teams on Google Cloud best practices, which TWO actions should you recommend to remediate these security and operational challenges while adhering to the principle of least privilege? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure Workload Identity Federation to allow the external CI/CD runner to exchange short-lived OpenID Connect (OIDC) tokens for GCP IAM service account credentials without using downloadable JSON keys.; Restrict manual write access to cloud resources via IAM permission boundaries, and integrate automated continuous drift detection using Cloud Asset Inventory or scheduled Terraform plan runs.

Answer

The recommended solutions are implementing Workload Identity Federation for keyless external authentication and enforcing IAM least-privilege policies alongside automated continuous drift detection.
Advising operations and development teams effectively requires enforcing security and operational reliability. Utilizing Workload Identity Federation eliminates the high risk of leaked long-lived service account keys by converting external CI/CD runner identities into short-lived GCP tokens. Concurrently, removing manual write privileges while deploying automated drift detection enforces Infrastructure as Code integrity, ensuring all environment updates proceed transparently through audited version-controlled pipelines.

Step-by-Step Solution

1
Address key management security risk
Replace exported service account JSON keys with Workload Identity Federation to allow short-lived OIDC credential exchanges from the external CI/CD system.
Google Cloud security best practices mandate avoiding long-lived, exportable service account keys wherever Workload Identity Federation can be used.
2
Address infrastructure drift and manual console edits
Revoke direct manual write permissions from developers in production and enforce changes through IaC pipelines combined with automated drift monitoring.
Preventative IAM controls stop manual console drift at the source, while detective controls identify any discrepancies between live cloud state and declared IaC manifests.

Key Concept

CI/CD Credential Management and IaC Governance
Question 1378Question →

A global fintech enterprise operates two core workloads on Google Cloud: a real-time API for evaluating transaction fraud risk and a background batch service for nightly ledger reconciliation. Business operations dictate that any un-evaluated real-time transaction causes immediate unrecoverable financial theft, whereas background ledger delays of up to four hours carry zero business or financial penalty. Currently, operations alerts on a single composite Service Level Indicator (SLI) measured as Successful RequestsTotal Requests\frac{\text{Successful Requests}}{\text{Total Requests}} aggregated across all API and batch requests. During a planned maintenance window, high-volume batch failures exhausted the quarterly error budget and triggered a critical P1 incident callout, despite the real-time fraud API maintaining 100% availability. How should the Cloud Architect realign the technical SLIs and SLOs with business impact?

Show answer & explanation

Answer: Decouple the workloads into separate SLIs and SLOs for real-time fraud evaluation and batch reconciliation, and restrict high-severity error budget burn-rate alerts to the real-time service.

Answer

Decouple the workloads into separate SLIs and SLOs for real-time fraud evaluation and batch reconciliation, and restrict high-severity error budget burn-rate alerts to the real-time service.
The correct response addresses the core Site Reliability Engineering (SRE) principle of aligning technical metrics with business impact. Because real-time fraud checks carry direct financial penalties upon failure while batch reconciliation is delay-tolerant, the services must have independent Service Level Indicators (SLIs) and Service Level Objectives (SLOs). High-severity paging alerts should only trigger when the error budget of the critical real-time service is burning rapidly.

Step-by-Step Solution

1
Analyze business impact differences between services
Real-time fraud processing has zero tolerance for downtime (direct monetary loss), whereas nightly batch reconciliation tolerates up to 4 hours of delay.
SLOs and error budgets must directly map to business risk and user experience.
2
Evaluate the current composite SLI strategy
Aggregating batch and real-time requests into a single ratio Successful RequestsTotal Requests\frac{\text{Successful Requests}}{\text{Total Requests}} causes non-critical high-volume batch failures to exhaust the error budget of the critical path.
Combining heterogeneous workloads distorts telemetry and generates false-positive P1 operational alerts.
3
Define aligned SLIs/SLOs and alerting rules
Create independent SLIs and SLOs for each service. Configure paging burn-rate alerts strictly on the real-time fraud endpoint, while routing batch failures to low-priority ticketing queues.
This alignment prevents alert fatigue, protects critical business revenues, and allows batch workloads to consume their error budgets as intended.

Key Concept

Aligning technical SLIs/SLOs with distinct business impacts by separating critical user-facing metrics from non-critical batch processes.
Question 1379Question →

An organization is designing a CI/CD pipeline on Google Cloud to build container images securely and manage release artifacts. Which of the following practices should be incorporated into the pipeline design? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Use Cloud Build with a dedicated service account configured with least-privilege IAM roles for build execution.; Store built container images in Artifact Registry to enable granular access control and automated container vulnerability scanning.

Answer

The pipeline design should utilize Cloud Build with a dedicated service account configured with least-privilege IAM permissions, and store container images in Artifact Registry to leverage granular access management and automated vulnerability scanning.
Establishing dedicated service accounts with minimal necessary IAM permissions for Cloud Build ensures secure build execution. Storing artifacts in Artifact Registry allows organizations to enforce repository-level access policy and scan images automatically for security vulnerabilities.

Step-by-Step Solution

1
Identify secure build execution requirements for Cloud Build.
Configuring dedicated service accounts with least-privilege roles ensures automated tasks only access required GCP resources.
Avoid using primitive roles or overly broad permissions in CI/CD pipeline automation.
2
Select the appropriate artifact storage service.
Artifact Registry provides enterprise container management with granular IAM permissions and automatic vulnerability scanning.
Storing build outputs securely requires repository-level isolation and vulnerability detection.

Key Concept

Least-privilege execution and secure artifact management in CI/CD pipelines
Question 1380Question →

A renewable energy analytics firm recently completed a rapid lift-and-shift migration of its IoT data processing pipeline to Google Cloud. A post-migration architecture audit identified two critical sources of technical debt: infrastructure engineers store Terraform state files on local developer workstations, resulting in frequent state drift and race conditions during deployments; additionally, compute workloads execute using service accounts assigned the project-level Owner primitive role to simplify access to Cloud Storage and BigQuery. Which combination of architectural refactoring actions should you recommend to effectively mitigate this technical debt while adhering to Google Cloud recommended practices?

Show answer & explanation

Answer: Migrate the Terraform state files to a centralized Cloud Storage bucket configured with Object Versioning and state locking, and replace the project-level Owner roles with minimal predefined IAM roles assigned directly to workload service accounts.

Answer

The optimal mitigation strategy is to migrate Terraform state files to a Cloud Storage backend with Object Versioning and state locking, while replacing primitive Owner roles with least-privilege predefined IAM roles.
The correct recommendation addresses both identified areas of technical debt according to Google Cloud architectural best practices. Configuring Cloud Storage as a remote backend provides central state storage, object versioning for rollback capabilities, and native state locking to prevent concurrent modifications. Concurrently, replacing primitive Owner roles with targeted predefined roles (such as Cloud Storage Object Admin or BigQuery Data Editor) enforces least privilege and meets compliance standards without introducing operational complexity.

Step-by-Step Solution

1
Assess the Infrastructure as Code (IaC) technical debt.
Identified that local state files lead to concurrency conflicts, environment drift, and risk of state loss.
Google Cloud recommended practice dictates using a remote backend such as Cloud Storage with state locking enabled to ensure consistent, secure deployment pipeline execution.
2
Assess the Identity and Access Management (IAM) technical debt.
Identified that project-level Owner primitive roles violate security compliance and grant excessive permissions.
Replacing primitive roles with specific predefined or custom roles follows the principle of least privilege.
3
Combine the refactoring strategies into a minimal-overhead, standardized architecture.
Configuring a GCS backend for IaC state and scoping IAM roles to specific services directly resolves both forms of technical debt without adding excessive infrastructure management overhead.
This directly remediates operational instability and security compliance failures while remaining cost-effective.

Key Concept

Technical Debt Mitigation in IaC State Management and IAM Role Scoping
PreviousPage 69 / 80Next
All practice questions — Google Cloud Professional Cloud Architect | Examkin