Google PCA Ensure solution and operations reliability Practice Question
A financial services company is migrating a monolithic Java application to Google Kubernetes Engine (GKE) for improved scalability and reliability. The application serves real-time trading data and has strict latency requirements. Post-migration, the team observes frequent pod restarts due to OutOfMemory (OOM) errors, increased latency during peak trading hours, and occasional database connection timeouts. The current setup uses a single GKE cluster with a node pool of n1-standard-4 machines, a stateless application deployed as a Deployment with resource requests and limits set to 512 Mi memory and 1 CPU. The database is a Cloud SQL PostgreSQL instance with 2 vCPUs and 7.5 GB memory, and applications connect using a hardcoded connection string. The team wants to ensure reliable operation under load and during node maintenance events. Which course of action best addresses the reliability issues?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Adjust resource requests to 1 Gi memory and 2 CPU, set limits to 2 Gi and 4 CPU, create an HPA based on a custom metric (e.g., requests per second), enable cluster autoscaler, implement Cloud SQL connection pooling via Cloud SQL Auth Proxy with a max connection pool size, and configure PDB with maxUnavailable 1.
Best addresses all reliability issues. Adjusting resource requests to 1 Gi memory and 2 CPU ensures proper scheduling, while limits of 2 Gi and 4 CPU prevent OOM errors. The HPA based on custom metrics (e.g., requests per second) scales pods proactively during peak trading hours. Cluster autoscaler handles node capacity, and Cloud SQL connection pooling via Cloud SQL Auth Proxy with a max pool size prevents database connection timeouts. Finally, a PDB with maxUnavailable 1 ensures availability during node maintenance. Option B misses resource tuning, autoscaling, and connection pooling. Option C unnecessarily moves the database to GKE, increasing complexity and losing managed DB benefits. Option D lacks custom metric HPA, cluster autoscaler, and PDB, leaving gaps in scalability and maintenance handling.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Adjust resource requests to 1 Gi memory and 2 CPU, set limits to 2 Gi and 4 CPU, create an HPA based on a custom metric (e.g., requests per second), enable cluster autoscaler, implement Cloud SQL connection pooling via Cloud SQL Auth Proxy with a max connection pool size, and configure PDB with maxUnavailable 1.
Why this is correct
Raising memory requests and limits above the current 512 Mi stops OOM kills, while the HPA, cluster autoscaler, Cloud SQL Auth Proxy pooling and PDB together address peak-load latency, connection exhaustion and node maintenance disruption — the four reliability symptoms named in the stem.
- ✗
Enable GKE node auto-upgrade, configure Pod Disruption Budgets (PDB) with minAvailable 1, and set readiness probes to check application health.
Why it's wrong here
Node auto-upgrade, PDBs, and readiness probes improve maintenance resilience and restart handling but leave the 512Mi memory limit, absent autoscaling, and unpooled hardcoded connections untouched, so OOM kills and timeouts persist. It is tempting because these controls govern disruption during node maintenance, which the stem also mentions.
- ✗
Migrate the database to a StatefulSet in GKE with persistent volumes, increase node count to 10, and enable cluster autoscaler.
Why it's wrong here
Running PostgreSQL in a StatefulSet replaces managed Cloud SQL with self-managed storage, adding operational risk and not resolving OOM kills, latency, or connection exhaustion. It is tempting when workloads need co-located stateful storage, but the stem's database is already managed and the failures stem from resource sizing and connection handling.
- ✗
Increase memory limits to 2 Gi and CPU to 2, add Horizontal Pod Autoscaler (HPA) based on CPU utilization, and implement connection pooling using Cloud SQL Auth Proxy.
Why it's wrong here
Increases limits may reduce OOM but does not address readiness probes or node maintenance; CPU-based HPA may not respond to latency spikes.
Go deeper
Related to this question
Learn chapter
Data Migration and Transfer Services
Key term
Scalability
Scalability is the ability of a system, network, or process to handle a growing amount of work by adding resources, either by making the existing resources more powerful (vertical scaling) or by adding more resources (horizontal scaling).
Key term
Autoscaler
An Autoscaler is a cloud service that automatically increases or decreases the number of virtual machines (instances) or resources based on real-time demand, so your application always has enough capacity without wasting money on idle servers.
About these practice questions
One of 807 original PCA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCA practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCA exam.