Google PCA Manage implementation of cloud architecture Practice Question
Your team has deployed a microservices application on Google Kubernetes Engine (GKE) with multiple services communicating via internal ClusterIP services. You notice that some requests between services are failing intermittently with 'connection refused' errors. The services are defined with readiness probes. What is the most likely cause?
⚠ Common exam trap
Google Cloud often tests the distinction between readiness and liveness probes, where candidates may incorrectly assume that a failing liveness probe (which restarts the pod) is the cause of 'connection refused', but the key is that readiness probes control endpoint membership, directly causing the error when all endpoints are removed.
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
✓
The readiness probes are not passing, causing the service endpoints to be removed.
The 'connection refused' error indicates that the client is attempting to connect to a port on which no process is listening. In GKE, when a readiness probe fails, Kubernetes removes the pod's IP from the corresponding ClusterIP service's endpoints. If all pods for a service fail their readiness probes, the service has no healthy endpoints, and any request to the ClusterIP will be refused because there is no backend to accept the connection. This matches the intermittent nature of the issue, as pods may temporarily fail the probe and then recover.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The readiness probes are not passing, causing the service endpoints to be removed.
Why this is correct
Failing readiness probes cause the pod to be removed from service endpoints, leading to connection refused.
- ✗
The services are not exposed via a VPC peering connection to the client's VPC.
Why it's wrong here
ClusterIP services are internal to the cluster and do not require VPC peering.
- ✗
The services are using NodePort instead of LoadBalancer type, causing port conflicts.
Why it's wrong here
NodePort works but is not the cause of connection refused; it's a valid type for internal access.
- ✗
The services are not associated with an Ingress resource.
Why it's wrong here
Ingress is for external HTTP(S) traffic; internal services don't need it.
Go deeper
Related to this question
Learn chapter
Introduction to Google Cloud Platform
Key term
Microservices
Microservices is an architectural style where a software application is built as a collection of small, independent services, each handling a specific business function and communicating over a network.
Key term
Service
A service is a software component or system that performs a specific function and is available to be used by other programs or users over a network.
About these practice questions
Courseiva writes every PCA question from scratch — 955 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.