PCA Exam Questions and Answers

Preemptible VMs

Preemptible VMs suit this fault-tolerant nightly batch job because they cost up to 80% less than standard instances, and the workload already tolerates restarts. The 24-hour maximum lifetime exceeds the 4-hour runtime, so forced preemption risk is acceptable, satisfying the cost-reduction constraint without disrupting analytics.

Database Migration Service (DMS)

Database Migration Service performs continuous replication from the on-premises PostgreSQL source to Cloud SQL, keeping downtime to a minimum during cutover. Its built-in schema conversion handles incompatible objects automatically, satisfying the automated conversion requirement for the 5 TB migration.

Cloud CDN

Cloud CDN caches static assets at Google edge points of presence, so repeated requests terminate near users rather than traversing to the Compute Engine backends. Enabling it on the existing Global HTTPS Load Balancer requires no application code changes, directly addressing the slow static asset loads.

Use Transfer Appliance

At 100 Mbps, transferring 200 TB over the network would take roughly 200 days, far exceeding the 30-day deadline. Transfer Appliance ships data physically via a rackable appliance, sidestepping the bandwidth constraint and completing the migration within the required window.

Database Migration Service (DMS)

Database Migration Service (DMS) supports online migration from Oracle to Cloud SQL for PostgreSQL with minimal downtime.

Use a managed instance group with autoscaling and preemptible VMs

A managed instance group automatically recreates preempted VMs, directly addressing the reliability constraint while retaining preemptible pricing. Autoscaling maintains capacity by adding instances when demand rises, so the batch job recovers without manual intervention. This satisfies the requirement to improve resilience without significantly increasing cost, since preemptible rates still apply.

Implement a retry mechanism in the job to re-run failed tasks

Preemption terminates tasks mid-execution, so a retry mechanism re-runs failed tasks once replacement VMs appear. This directly addresses the intermittent failure mode without changing the compute tier, preserving the cost constraint while improving job completion reliability.

Dedicated Interconnect

Dedicated Interconnect provides a direct physical link between the on-premises network and Google's edge at a colocation facility, delivering the 99.99% availability and up to 100 Gbps capacity the stem requires. Partner Interconnect and Cloud VPN cannot meet those combined bandwidth and SLA constraints.

GKE Autopilot

GKE Autopilot provisions and manages the node infrastructure itself, including scaling, patching and node pool configuration, while enforcing workload resource requests and SLA-backed reliability. This removes node-level operational overhead, satisfying the requirement for fully Google-managed nodes with guaranteed workload SLAs.

Configure a Cloud SQL HA instance with a failover replica in a different zone

A Cloud SQL HA instance maintains a standby in a different zone with synchronous replication, so failover is automatic and data loss is minimal. This satisfies the stem's requirement for cross-zone automatic failover within the same region.

Distribution metric

Distribution metrics record a histogram of values across a time window, letting Cloud Monitoring compute percentiles such as p99 directly. This satisfies the requirement to track 99th percentile latency over seven days, which a gauge or counter cannot represent.

Create a Cloud Monitoring alerting policy with a metric threshold condition on CPU utilization and add both email and Pub/Sub notification channels

A Cloud Monitoring alerting policy with a metric threshold condition evaluates CPU utilisation against 80% for the five-minute duration. Attaching both email and Pub/Sub notification channels delivers the alert to each destination, satisfying the dual-delivery requirement without custom code.

Object lifecycle management with a rule to delete versions after 90 days

Object lifecycle management applies age-based rules to noncurrent object versions, automatically deleting them once they pass 90 days. This satisfies the stem's requirement to retain versions for 90 days and then remove them, which a retention policy alone cannot do.

Run gcloud deployment-manager deployments update --config <previous_manifest>

Redeploying the previous manifest restores the last known-good configuration, satisfying the rollback requirement after a failed update. Deployment Manager is declarative, so reapplying the prior manifest reconciles resources back to that state rather than attempting an in-place undo.

Shared VPC

Shared VPC lets a host project export subnets to service projects, so the central team retains control of the VPC configuration while each service project deploys its own resources into those shared subnets. This directly satisfies the requirement for one common VPC defined centrally and reused across multiple GCP projects.

Deploy a VPC connector and attach it to the Cloud Run service

A Serverless VPC Access connector gives Cloud Run a private network path, letting it reach the Cloud SQL instance over its internal IP. Attaching the connector to the service satisfies the no-public-IP constraint, since traffic never traverses the internet.

Cluster Autoscaler

Cluster Autoscaler adds or removes nodes in a GKE node pool when pods remain pending due to insufficient allocatable resources, directly satisfying the stem's requirement to scale node count from pending pods. It watches the scheduler's unschedulable queue, unlike Horizontal Pod Autoscaler, which only adjusts replica counts of workloads.

roles/artifactregistry.writer

Granting roles/artifactregistry.writer provides the write permissions Cloud Build requires to push Docker images into Artifact Registry, satisfying the PERMISSION_DENIED constraint. This role permits uploading and creating repository content without granting broader administrative capabilities, so the build service account can complete its image push securely.

Cloud Trace

Cloud Trace collects and correlates latency data across microservice calls, producing distributed traces that pinpoint slow spans in request paths. This directly satisfies the need to analyse latency in microservices applications, unlike logging or monitoring services that lack span-level tracing.

Grant the service account a role at the project or resource level

Binding a role to the service account at the project or specific resource level scopes its permissions precisely, so access is limited to the intended resources. IAM policies attached at those levels define exactly which actions the service account may perform.

Binary Authorization

Binary Authorization enforces deploy-time attestation on GKE, blocking unsigned or unverified container images before they reach the cluster. It satisfies the stem's requirement for signature verification at deployment by validating attestations from trusted authorities, unlike vulnerability scanning or registry-level controls, which cannot gate admission.

Implement VPC Service Controls with a service perimeter

VPC Service Controls builds a service perimeter around the GKE cluster's project, blocking Cloud Storage access from outside the perimeter even over public IPs. This satisfies the no-private-IP constraint by enforcing an identity- and network-independent boundary against exfiltration.

Data Access audit logs

Data Access audit logs record every read, write, and cryptographic operation against BigQuery data, including Cloud KMS key usage for CMEK decryption. Admin Activity logs only capture configuration changes, not key use. Enabling Data Access logging therefore reveals who used the key and when, satisfying the audit requirement.

roles/iam.serviceAccountAdmin

roles/iam.serviceAccountAdmin grants the full set of service account management permissions — creating, deleting, updating and viewing service accounts, plus binding IAM policies on them — matching the requirement to create and manage service accounts within the project.

VPC Service Controls

VPC Service Controls creates a service perimeter that restricts API access to authorised networks, so requests from outside the corporate network are denied unless they traverse the specified Cloud VPN tunnel. This satisfies the stem's requirement to enforce tunnel-only access to GCP service APIs.

Cloud Key Management Service (Cloud KMS)

Cloud KMS centralises creation, rotation and access control of customer-managed encryption keys, and integrates with Google Cloud services for envelope encryption at rest and in transit. This satisfies the requirement for one centralised key management service.

Use VPC firewall rules with target tags to allow traffic between specific tiers.

VPC firewall rules with target tags apply ingress rules only to VMs carrying the specified tag, so the application tier accepts traffic solely from the web tier's tag and the database tier solely from the application tier, enforcing tier isolation within one VPC network.

Cloud Storage with CMEK via Cloud KMS, Cloud Audit Logs, and Chronicle

CMEK via Cloud KMS supplies the customer-managed key with configurable 90-day rotation, satisfying the encryption constraint. Cloud Audit Logs capture every bucket access for compliance evidence, while Chronicle ingests those logs to detect anomalous access patterns through its security analytics. Together these three services meet each stated requirement.

Use Cloud Armor security policies with geographic-based denylist rules.

Cloud Armor security policies attach to the load balancer's backend service and evaluate rules at the edge, including geographic denylists keyed on source country. This blocks non-EU traffic before it reaches regional backends, satisfying the GDPR constraint.

Enable Binary Authorization to ensure only signed container images are deployed.

Binary Authorization enforces a deploy-time admission check, permitting only container images that carry a valid signature from an attested authority. Unsigned or tampered images are rejected before scheduling, preventing supply-chain compromise of the GKE cluster.

Use Workload Identity to bind Kubernetes service accounts to IAM service accounts.

Workload Identity binds a Kubernetes service account to a Google Cloud IAM service account, letting pods obtain short-lived IAM credentials instead of static JSON keys stored in Secrets. This satisfies the stem's recommended-practice requirement by removing long-lived credentials, the primary leak vector in GKE clusters.

Cloud Key Management Service (Cloud KMS)

Cloud KMS creates, stores, rotates and controls customer-managed encryption keys, and integrates with Google Cloud services so data at rest is encrypted under CMEK. It directly satisfies the compliance requirement for managing key lifecycle rather than relying on Google-managed keys.

Use Cloud Spanner with multi-region configuration

Cloud Spanner's multi-region configuration synchronously replicates data across regions using TrueTime, delivering strong consistency with low read latency and automatic failover for disaster recovery. Its horizontally scalable architecture handles 10x growth without manual sharding, satisfying the stem's combined demands for consistent low latency, multi-region replicas and elastic scale.

Rehost the application on Compute Engine and use Cloud SQL for MySQL as the database.

Rehosting on Compute Engine with Cloud SQL for MySQL lifts and shifts the application with minimal code change, satisfying the minimise-changes constraint. Cloud SQL adds managed backups and high availability, improving reliability and scalability over the single on-premises server.

Enable Cloud Spanner interleaved tables and add secondary indexes for common query filters.

Cloud Spanner query latency under flash-sale load stems from scanning non-interleaved tables and full-table reads. Interleaving co-locates child rows with parents, and secondary indexes accelerate the catalog's common filter queries, cutting the data scanned and reducing timeouts at the database layer.

Ingest via Cloud Pub/Sub, process with Cloud Dataflow, store in Cloud Bigtable, and query from the dashboard.

Cloud Pub/Sub absorbs unpredictable spikes to millions of events per second without backpressure, while Dataflow provides streaming windowed aggregations. Bigtable's row-key design delivers the low-latency point and range reads the dashboard needs, satisfying the sub-second latency constraint that batch warehouses such as BigQuery cannot meet for continuous refreshes.

Grant the service account roles/storage.objectViewer on the bucket and remove all other bindings.

Granting `roles/storage.objectViewer` at bucket level binds the service account directly to the resource, satisfying the least-privilege constraint. Removing every other binding ensures no principal inherits access via project-level or inherited roles, so only that service account can read objects. This is the precise mechanism for restricting a sensitive bucket to a single identity.

1. Verify that the VPC networks have non-overlapping IP ranges. 2. Create a VPC peering connection from Project A to Project B. 3. Create a VPC peering connection from Project B to Project A. 4. Verify the peering status and network connectivity.

This order ensures prerequisites are met (non-overlapping IPs), then establishes both directions of peering, which is required for bidirectional communication. Finally, verification confirms success.

Create a managed instance group with instances in multiple zones.

A managed instance group spanning multiple zones maintains capacity when one zone fails, satisfying the automatic zone-failure recovery requirement. The group's regional distribution and autohealing replace unhealthy instances in surviving zones, unlike a single-zone group or manual restart, which cannot survive zone loss.

Create a logs sink in each project that exports logs to a BigQuery dataset in the central project.

A logs sink in each project routes log entries to a BigQuery dataset hosted in the central project, aggregating all projects' logs for centralised analysis. This satisfies the requirement to consolidate logs into a single project without per-project querying.

Horizontal Pod Autoscaler.

The Horizontal Pod Autoscaler adjusts the replica count of a workload based on observed CPU utilisation, satisfying the automatic scaling requirement with minimal operational overhead. It reads metrics from the metrics server and scales pods directly, unlike cluster-level node autoscaling.

Cloud Armor security policies.

Cloud Armor security policies attach directly to the global HTTP(S) load balancer's backend service, letting you define allow or deny rules matching source IP ranges. This satisfies the requirement to restrict access to specific IP ranges at the edge, before traffic reaches Compute Engine instances.

Enable Cloud SQL High Availability (HA) configuration.

Cloud SQL High Availability provisions a standby instance in a separate zone with synchronous replication, enabling automatic failover during a zone outage. This directly satisfies the stated availability constraint, whereas read replicas and backups do not provide automatic failover.

Firestore.

Firestore is a serverless NoSQL document database offering flexible schemas and automatic horizontal scaling, matching the non-relational, flexible-schema, auto-scaling requirement. It suits application data needing real-time sync and scales without manual sharding, unlike Cloud SQL's fixed relational schema.

Use Database Migration Service for PostgreSQL with continuous migration from Oracle via Homogeneous Migration.

DMS supports minimal downtime via continuous replication.

Add a random prefix to the order ID primary key.

Randomising the leading key bytes spreads sequential inserts across multiple Spanner splits, eliminating the hot spot caused by monotonically increasing order IDs during flash sales. This directly addresses the stem's constraint: write contention concentrated on the trailing split. Range scans by order ID still work, though they now require prefix-aware query design.

Apply clustering on frequently filtered columns.

Clustering physically co-locates rows sharing the clustered column values, so filters on those columns scan fewer blocks. On a frequently queried partitioned table, clustering the common filter columns prunes data within each partition, improving performance without restructuring partitions.

The node pool has reached the maximum node count limit.

When the node pool hits its maximum node count, the cluster autoscaler cannot provision further nodes regardless of pending pods. Pods remain Pending because no capacity is added, explaining the slow scaling despite autoscaling being enabled.

Increase the CPU request for the backend pods to 2 CPUs.

CPU throttling, not network bandwidth, causes the latency spikes. Raising each backend pod's CPU request to 2 CPUs gives the CPU-bound gRPC service enough quota to avoid throttling, directly removing the constraint correlated with the observed timeouts.

Identify stateless components to migrate to Cloud Run, and keep stateful components on GKE with managed services like Cloud Spanner.

Cloud Run removes cluster management for stateless components, cutting operational overhead, while GKE with managed Spanner keeps stateful workloads reliable. This split directly balances the stated modernization benefits against the concern about increased operational complexity, rather than migrating everything wholesale.

The autohealing health check is misconfigured.

Autohealing relies on a health check to detect and recreate unhealthy instances. If that health check is misconfigured — wrong path, port, or thresholds — the MIG never marks instances unhealthy, so no automatic replacement occurs despite the traffic spike.

Optimize transactions to reduce lock contention.

Reducing lock contention directly addresses the transaction aborts and latency spikes. Cloud Spanner aborts transactions when locks conflict, so shortening transactions and ordering reads and writes to minimise overlapping access lowers abort rates and improves throughput during peak load.

The application has a memory leak that eventually exceeds the limit.

Requests and limits only cap consumption; they cannot prevent a leak from growing until the container exceeds its limit and is OOMKilled. Since configuration is already correct, the remaining cause is application-level: unbounded allocation that eventually surpasses the configured memory limit.

Increase the memory allocated to the Cloud Function.

Memory limit exceeded errors mean the function's allocated memory is exhausted during peak concurrency. Raising the memory allocation gives each instance more headroom to process Pub/Sub messages and write to Firestore, restoring reliability while preserving throughput, since Cloud Functions scales instances independently of the memory setting.

Increase the evaluation window to 10 minutes.

Extending the evaluation window to 10 minutes requires latency to breach 500 ms across a longer sustained period, filtering out brief spikes that triggered false positives. This directly addresses the stem's short-burst problem while retaining detection of genuine sustained degradation.

Configure Horizontal Pod Autoscaler (HPA) based on CPU utilization or custom metrics.

Cluster Autoscaler only adds nodes when pods are pending; with CPU and memory headroom already available, no new nodes are needed. The bottleneck is pod count, so Horizontal Pod Autoscaler must scale replicas based on CPU or custom metrics to absorb the traffic spike.

The readiness probes are not passing, causing the service endpoints to be removed.

Failing readiness probes cause the pod to be removed from service endpoints, leading to connection refused.

Use Cloud CDN in front of an external HTTPS Load Balancer with backend services in multiple regions.

Cloud CDN caches static assets at edge locations, while the external HTTPS Load Balancer with multi-region backends routes dynamic API traffic to the nearest healthy region, satisfying the worldwide low-latency requirement for both content types.

App Engine Standard Environment with Cloud SQL.

App Engine Standard automatically scales instances with traffic and requires no server management, while Cloud SQL provides a managed MySQL database, together minimising operational overhead. This pairing satisfies the low-traffic start, seamless scaling, and reduced administration constraints.

Use the Organization Policy service with a custom constraint to require labels on Compute Engine instances.

Organization Policy custom constraints let you define and enforce label requirements across the project hierarchy, blocking non-compliant instance creation at the API level. This satisfies the policy's demand for automatic enforcement at creation time, rather than relying on manual labelling or post-hoc auditing.

Partition the table by a date or timestamp column.

Partitioning by date or timestamp prunes scanned data, so ad-hoc analytical queries read only relevant partitions rather than the full table. This directly reduces bytes processed, and BigQuery bills on-demand queries by data scanned, satisfying the cost-reduction requirement for frequent large-dataset analysis.

Create materialized views for common aggregation queries.

Materialised views precompute and persistently store aggregation results, so repeated ad-hoc queries scan the small view rather than the full large dataset. BigQuery bills on bytes processed, so this directly cuts query cost for the frequent common aggregations described in the stem. Automatic refresh keeps results current without manual intervention.

Use clustering on columns frequently used in filter clauses.

Clustering physically sorts data by the chosen columns, so filters on those columns skip irrelevant blocks. Queries scan fewer bytes, and BigQuery bills on-demand by bytes processed, directly reducing cost for frequently filtered ad-hoc workloads.

The boot disk is too small and has run out of space.

The boot disk holds the operating system, logs, and temporary files. At 95% of 100 GB, it lacks space for normal writes, causing the instance to hang. The data disk's free capacity is irrelevant because the OS cannot use it for boot-volume operations.