Google Professional Cloud Architect (PCA) — Questions 151–225

Cloud Spanner is Google Cloud's globally distributed, strongly consistent relational database that supports horizontal scaling for high write throughput and provides automatic failover with zero data loss (RPO=0) via synchronous replication. It is the only option that meets all requirements across three regions.

The most likely cause is that there is no firewall rule allowing ingress traffic on ports 80 and 443. By default, Google Cloud Platform (GCP) firewall rules block all incoming traffic from the internet. Even though the instance is created successfully, HTTP/HTTPS traffic cannot reach it unless a firewall rule explicitly permits ingress on TCP ports 80 and 443, typically via a target tag like 'http-server' or 'https-server'.

Migrate for Compute Engine (formerly Velostrata) performs agentless, incremental replication of VM disks to Compute Engine, enabling minimal downtime migrations.

The image must be in a registry before the Deployment can reference it. The Service provides external access.

Cloud Run is a fully managed container platform that scales automatically in response to request volume and exposes an HTTPS endpoint by default. Because it abstracts away clusters and VMs, it fits a team without Kubernetes skills that wants to minimize infrastructure management while still running a containerized web application.

The roles/viewer role grants read-only access to all resources within the organization, including all projects, making it the correct choice for a new employee who needs read-only access across all projects. Assigning it at the organization level ensures the permission is inherited by all projects, folders, and resources beneath. This follows the principle of least privilege for read-only access.

Cloud Monitoring (formerly Stackdriver Monitoring) provides comprehensive observability for Cloud Run services, including built-in dashboards for request latency, error rates, and resource utilization. It collects metrics like request count, request latencies, and container instance counts, and allows you to set alerting policies based on these metrics. While Cloud Trace can help with latency analysis and Cloud Logging captures logs, Cloud Monitoring is the primary product for monitoring both errors and latency in a unified view.

Committed use discounts (CUDs) provide significant discounts (up to 57% for most services) in exchange for committing to a specific amount of resources for a 1- or 3-year term. For a predictable, 24/7 workload running for one year, CUDs are the most cost-effective option because they offer a lower price than on-demand and do not carry the risk of interruption like Spot or Preemptible VMs. Spot VMs are cheaper but can be preempted, making them unsuitable for a steady, always-on application.

Spot VMs provide the largest discount available on Compute Engine and are appropriate when a workload can tolerate preemption and resume from checkpoints. Because the job reads its source data from Cloud Storage and only uses local SSD as scratch, losing the instance mid-run does not corrupt results, so the cost reduction comes with acceptable risk.

HPA for CPU utilization calculates utilization as a percentage of the pod's CPU request, not of the node or a raw usage value. If pods have no resource requests defined, the HPA cannot compute a utilization percentage and will not scale, even when CPU usage is high. Defining CPU requests on the pods resolves this.

Reservations with committed slots turn variable on-demand query charges into a fixed, forecastable monthly figure, and assigning capacity per project makes each department's usage attributable. This satisfies the finance requirement directly, whereas quotas merely cap usage and alternative engines add complexity without solving the predictability and attribution goals.

Shared VPC in Google Cloud lets an organization designate a host project whose VPC network is shared with multiple service projects. This centralizes network administration (subnets, firewall rules, routes managed in the host project) while allowing teams in service projects to deploy resources into the shared network. It is the canonical answer for cross-project network sharing with centralized control.

Cloud Functions is designed for event-driven, serverless compute. It can be triggered directly by Cloud Storage events (object finalize/create). Cloud Run requires HTTP invocation, App Engine is for web apps, and Compute Engine VMs require management.

Cloud CDN attached to a global external Application Load Balancer with a backend bucket serves Cloud Storage content from Google's globally distributed edge caches. Readers in Tokyo and São Paulo are answered by a nearby point of presence, improving first-byte latency, while the europe-west1 bucket remains the sole origin and canonical copy. Because requests still use the same object paths through the load balancer, no application rewrite is required.

VPC Service Controls use Access Context Manager (ACM) access levels to define granular, identity-based access conditions. By including the project in a perimeter and applying an access level that specifies authorized users (e.g., based on IP ranges, device state, or identity), you can allow those users to query BigQuery from outside the perimeter while blocking all other external traffic, preventing data exfiltration.

The monotonically increasing primary key causes all writes to be directed to the last tablet (splitting point), creating a hotspot on one node. This hotspot leads to high latency for point reads because that node becomes a bottleneck. Adding a hash prefix or a leading random value distributes writes and reads evenly across all nodes, resolving the hotspotting issue.

Option B is correct because Cloud KMS customer-managed encryption keys (CMEK) can be configured as the default encryption key for a Cloud Storage bucket, and Cloud KMS supports automatic rotation schedules (e.g., every 90 days). This satisfies both requirements: customer-managed key and automatic 90-day rotation, with no manual intervention.

BigQuery is the correct choice because it is a fully managed, petabyte-scale analytics database that supports standard SQL and integrates with Pub/Sub for real-time data ingestion. It minimizes administration and offers cost-effective pricing, making it ideal for moving an on-premises data warehouse to Google Cloud.

The `--enable-private-ip-google-access` flag allows VM instances in a subnet to reach Google APIs and services (such as Cloud Storage, BigQuery, and Cloud Pub/Sub) using only their internal (private) IP addresses, without needing an external IP address. This works by routing traffic through Google's internal network to the Google Front End (GFE), bypassing the public internet.

Binary Authorization is a deploy-time security control that ensures only trusted container images are deployed to GKE or Cloud Run. It works by requiring attestations (cryptographically signed proofs) that images have been built by a trusted builder and passed required checks such as vulnerability scanning. If an image lacks the required attestation, the admission controller rejects the deployment.

Preemptible VMs are up to 80% cheaper than standard VMs and are ideal for fault-tolerant, interruptible batch jobs. Custom machine types allow tailoring CPU and memory to the workload, avoiding over-provisioning and further reducing cost.

Attaching a service account to a Compute Engine VM instance is the recommended approach because it provides the VM with automatically rotated, short-lived credentials via the metadata server. Applications on the VM can call the metadata server to obtain access tokens without any key files. This eliminates the risk of key leakage and manual rotation.

Preemptible VMs offer the lowest cost (up to 80% discount) and are ideal for fault-tolerant, short-lived batch workloads that can handle interruptions. Sustained use discounts apply automatically but require running a VM for at least 25% of a month. Committed use discounts require a 1- or 3-year commitment and are not as flexible for a short nightly job.

Cloud Deployment Manager is Google Cloud's native infrastructure as code service that uses declarative YAML or Python/Jinja templates. It supports Python and Jinja templates for reusable modules, making it the correct choice for automating infrastructure deployment with those requirements.

Cloud Armor is the correct service because it provides a web application firewall with preconfigured rules for SQL injection and cross-site scripting, and it integrates directly with external HTTP(S) load balancers. Attaching a security policy to the backend service enforces these protections at the edge before traffic reaches the application.

Flagger with Istio automates canary deployments by incrementally shifting traffic, analyzing Prometheus metrics, and rolling back automatically if KPIs degrade. This provides safe, gradual rollout with minimal manual intervention. Other options either lack automation, do not support gradual traffic shifting, or require manual monitoring.

The requirement is to cut idle capacity cost while absorbing unpredictable spikes without maintaining per-group autoscaling policies. Cloud Run provides request-driven autoscaling that can scale to zero and back out rapidly, and a serverless network endpoint group lets the existing external Application Load Balancer keep fronting the service. This removes idle VM cost and centralizes elasticity in the platform rather than in hand-tuned policies.

A headless service (clusterIP: None) allows direct pod-to-pod communication without load balancing, which is essential for stateful applications like databases that require stable network identities. Each pod in a StatefulSet gets a unique DNS name (e.g., pod-0.service.namespace.svc.cluster.local), enabling reliable discovery and ordering for replication, leader election, and failover. This ensures that clients always reach the correct pod instance, improving overall reliability.

It introduces an external, highly available, in-memory session store (Cloud Memorystore for Redis) that decouples session state from individual Compute Engine instances. This eliminates session loss during autoscaling events and reduces database load by serving session data from fast Redis memory, all while requiring minimal application changes via Tomcat's built-in session persistence or Spring Session integration.

The Cloud Build service account (typically the Compute Engine default service account or a custom service account) needs the Cloud Deploy Developer IAM role (roles/clouddeploy.developer) to create releases in Cloud Deploy. This role grants the necessary permissions, such as clouddeploy.releases.create, which are required for the Cloud Build trigger to successfully create a release after building and pushing the Docker image. Without this role, the pipeline fails with a permission error, making option A the correct resolution.

Workload Identity is the correct choice because it allows pods in GKE to authenticate to Google Cloud APIs using a specific Google service account, rather than the default Compute Engine service account. This ensures that pods cannot access any Google Cloud APIs unless explicitly granted permission via IAM roles bound to that service account, meeting the requirement for least-privilege access.

The error message 'Resource 'my-firewall' already exists' directly indicates that a firewall rule with the exact name 'my-firewall' is already present in the project. Cloud Deployment Manager creates resources by name, and if a resource with the same name exists (even if it was created outside the deployment), the deployment will fail unless the deployment is configured to adopt or manage that existing resource. The error is not about permissions, network references, or missing delete policies—it is a name collision.

Adding Cloud SQL read replicas and routing read traffic to them offloads the primary instance, which is the standard, low-disruption way to scale read-heavy workloads. With 95% reads, this directly addresses the bottleneck without architectural changes. Cloud SQL Proxy, Spanner migration, and storage/machine-type increases do not solve read contention as directly or with as little disruption.

Detecting user-facing unhealthiness requires probing the service as users reach it and monitoring the error and latency signals that reflect their experience. An uptime check from multiple locations validates the public endpoint and response content, while alerting on load balancer 5xx rates and backend latency ties detection to SLO thresholds. Together they catch both total outages and degraded performance.

Cloud Monitoring alerting policies are designed to evaluate metrics like request latency against thresholds and to notify through channels such as email. They also track incidents over time, satisfying the need for both immediate notification and a reviewable record. Log-based alerts, Cloud Trace reports, and traffic splitting serve different purposes and do not provide threshold-based latency alerting with email notification.

The default node pool in GKE uses pd-standard (standard persistent disk) which provides lower IOPS compared to pd-ssd. For applications requiring high disk I/O performance, pd-standard disks become a bottleneck, causing high latency. Upgrading to pd-ssd or using local SSDs would resolve this issue.

HorizontalPodAutoscaler is the Kubernetes resource designed to scale the number of pods based on metrics like CPU utilization. By setting a target CPU utilization and replica bounds, it can automatically add pods during spikes and remove them when demand drops, ensuring availability and cost efficiency. The other options either adjust resources vertically, scale nodes, or manage disruptions, none of which directly scale pods based on CPU.

A managed instance group supports autoscaling policies directly, including CPU utilization targets, and honors minimum and maximum instance counts so capacity tracks demand automatically. This is a built-in, fully managed capability that requires no custom scheduler or external automation, making it the simplest way to scale a stateless front end in response to unpredictable traffic.

Cloud Armor security policies bind to the backend service of an external Application Load Balancer and inspect requests at Google's edge. Geographic rules deny traffic by source region, and rate-based ban rules throttle or temporarily ban clients exceeding thresholds, delivering sanctions blocking and abuse mitigation without modifying the application.

Cloud Run is a fully managed serverless platform that automatically scales based on traffic, scales to zero, and charges only for resources used during request processing. It requires no infrastructure management, making it ideal for minimizing operational overhead while meeting autoscaling and pay-per-use requirements.

Cloud Bigtable is a fully managed, high-throughput, low-latency NoSQL wide-column store designed for massive-scale workloads with simple key-value access patterns. It scales linearly to handle millions of operations per second and provides strong consistency for single-row reads/writes within a region, matching the gaming session use case. Its row-key design supports the 10 writes/sec per player at 1M concurrent players without the relational overhead of Cloud SQL.

It combines a global HTTP(S) load balancer (which can route traffic to healthy backends across regions), regional MIGs that span multiple zones within each region (providing zone-level redundancy), and a multi-region Cloud Spanner instance (which provides synchronous replication across regions for strong consistency and automatic failover). This architecture ensures that if an entire zone or region fails, traffic is automatically redirected to healthy backends in other zones/regions, and Spanner continues to serve reads and writes without manual intervention.

VPC Service Controls allows you to define a security perimeter around Cloud Storage, restricting access to only requests originating from specific VPC networks. By configuring an access level that requires HTTPS, you enforce encryption in transit, meeting both the network restriction and data-in-transit encryption requirements.

Kubernetes Network Policies provide pod-level network segmentation and are enforced by the container network interface (CNI) plugin. GKE supports network policy logging, which records allowed and denied connections. This approach does not require application code changes and operates at the network layer.

Customer-Managed Encryption Keys (CMEK) with Cloud KMS allow organizations to control the encryption keys used for data at rest in Cloud Storage. You can set an automatic rotation period, such as 90 days, and disabling the key immediately revokes access to the data. This satisfies the requirements for control, automatic rotation, and immediate revocation.

In Google Cloud Deploy, approval gates are defined within the delivery pipeline configuration, specifically under the target definition. The target represents a deployment environment (e.g., production cluster) and can include a 'requireApproval' field to enforce manual approval before any release is promoted to that target. This ensures that promotions to sensitive environments are gated by human intervention.

The correct choices are to place both tiers in the same VPC with firewall rules restricting traffic, and to enable Private Service Access for Cloud SQL. This ensures internal communication without public internet exposure. Using a single VPC simplifies security, and Private Service Access provides private connectivity to Cloud SQL, meeting the requirement to minimize public exposure.

Enabling Cloud SQL High Availability (HA) configuration provisions a standby instance in a different zone within the same region, using synchronous replication to ensure zero data loss. In the event of a zone outage, Cloud SQL automatically fails over to the standby instance, typically within 60 seconds, providing high availability without manual intervention.

Cloud Deployment Manager is Google Cloud's native infrastructure-as-code service that uses YAML declarative configuration files and explicitly supports Python and Jinja2 templating for parameterization and reuse. It integrates directly with GCP IAM and APIs, making it the correct choice when the requirement calls out Python and Jinja support. Terraform uses HCL, not Python/Jinja, so it fails the stated requirement.

Identity-Aware Proxy (IAP) provides zero-trust access control to applications without exposing them to the public internet, and it integrates with Cloud Identity. By syncing on-premises Active Directory to Cloud Identity (via GCDS or federation), users can authenticate with their corporate credentials through IAP, which enforces IAM policies before allowing access to the Compute Engine-hosted app.

Committed use discounts offer substantial savings for predictable workloads. Because the application runs continuously for at least a year, committing to the specific resources ensures the highest discount without impacting performance or availability. Other options either compromise reliability or do not provide additional savings beyond existing discounts.

Local SSDs provide the highest IOPS and lowest latency of any disk option on Compute Engine, and striping them with RAID 0 aggregates their performance. This directly addresses the need for high IOPS and low latency for database workloads, unlike persistent disks which have performance ceilings tied to disk size and instance limits.

Cloud Monitoring's SLO monitoring feature allows you to define SLOs and then create alerting policies based on error budget burn rates. This is the most effective way to alert on SLO violations because it considers both the error rate and the time window, and it can detect when the budget is being consumed too quickly. Other methods lack the direct integration with SLOs and error budgets.

Cloud Armor is the correct service because it provides Web Application Firewall (WAF) capabilities that can inspect HTTP/HTTPS traffic and filter out common web attacks such as SQL injection and cross-site scripting (XSS). It integrates directly with Cloud Load Balancing to apply pre-configured or custom rules at the edge, blocking malicious requests before they reach the backend.

Cloud Run is a fully managed serverless container platform that scales to zero when there is no traffic and bills only for CPU/memory consumed during request processing (and optionally during background work). It runs any containerized HTTP application, making it the exact match for the stated requirements. GKE and Compute Engine do not scale to zero, and App Engine Flexible keeps at least one instance running.

Cloud CDN integrates with an external HTTP(S) load balancer to cache static content at Google edge locations while forwarding dynamic API requests to the backend in a single region. The external HTTP(S) load balancer provides a global anycast IP, terminates client connections at the edge, and routes requests to the backend based on URL maps. This combination is the standard Google Cloud architecture for global content delivery with low latency for static assets and centralized dynamic processing.

GKE cost allocation is designed to break down cluster costs by namespace and label, enabling accurate chargeback without code changes. By labeling namespaces with team identifiers, you can generate reports and budget alerts per team. Other options either increase cost, do not provide attribution, or require additional tooling.

The roles/storage.objectViewer role grants read-only access to objects in a bucket, including listing and downloading objects, but does not allow modification or deletion.

To connect a Cloud Run service to a Cloud SQL instance privately without using public IP, you must deploy a Serverless VPC Access connector and attach it to the Cloud Run service. This connector allows Cloud Run to route traffic to the VPC network, where Cloud SQL's private IP resides. The connection uses the VPC's internal IP range, ensuring private communication.

Point-in-time recovery (PITR) for Cloud SQL for PostgreSQL lets you restore an instance to any specific timestamp within a configurable retention window (up to 7 days), using write-ahead log (WAL) archiving combined with automated backups. This directly satisfies the requirement to recover to a specific point in time within the last 7 days with an RPO under 1 hour, because WAL segments are continuously shipped and enable granular recovery. Automated backups alone only allow restore to the backup's snapshot time, which would not meet a sub-hour RPO.

A Cloud Function with a private IP Cloud SQL instance requires either the Cloud SQL Proxy (which uses the Cloud SQL Auth proxy to establish an encrypted connection via the public IP, but if the instance has only a private IP, the proxy must be run within the same VPC) or a VPC connector to enable private networking. Additionally, proper IAM permissions (e.g., Cloud SQL Client role) are necessary for the proxy or connector to authenticate and connect. Without both the network path and IAM permissions, the connection will fail.

A regional managed instance group with a fixed target size and autohealing automatically replaces unhealthy VMs and maintains the specified number of instances across multiple zones. This meets the requirements of automatic replacement and fixed instance count across two zones. Autohealing uses health checks to detect and recreate unhealthy instances, ensuring high availability.

The kubernetes.io/container/restart_count metric directly tracks container restarts and is the correct choice for alerting on repeated restarts. It is a cumulative counter, so you must apply a rate or delta alignment to detect increases over time. Other metrics like CPU usage or pod status do not provide restart counts, and log-based metrics require extra setup and may be less reliable.

Cache invalidation is the correct mechanism when content must be refreshed immediately without changing the URL. Cloud CDN supports explicit invalidation requests that purge cached objects from edge locations, forcing subsequent requests to fetch fresh content from the origin. This is the only option that removes already-cached content on demand rather than waiting for TTL expiry or relying on URL changes.