Courseiva
Manage implementation of cloud architectureeasyMultiple ChoiceObjective-mapped

Google PCA Manage implementation of cloud architecture Practice Question

Exhibit

Refer to the exhibit.

```
$ gcloud container clusters describe my-cluster --zone us-central1-a --format 'table(name, nodeConfig.machineType, nodePools[].initialNodeCount, nodePools[].config.machineType)'
NAME: my-cluster
MASTER_VERSION: 1.28.5-gke.2000
NODE_CONFIG_MACHINE_TYPE: e2-standard-4
NODE_POOLS: [0].initialNodeCount: 3
NODE_POOLS: [0].config.machineType: e2-standard-4
```

A developer runs the command above and sees the output. The cluster has one node pool with 3 nodes, each of type e2-standard-4 (4 vCPU, 16 GB RAM). The application requires at least 2 GB of memory per pod and the cluster has 10 pods that need to be scheduled. The developer also notices that the node pool autoscaling is enabled with a minimum of 1 and maximum of 5 nodes. However, the cluster is unable to schedule all pods. What is the most likely cause?

⚠ Common exam trap

Google Cloud often tests the distinction between pod resource requests and limits, and the fact that the Cluster Autoscaler scales based on requests, not limits, leading candidates to overlook system reservations or assume autoscaling is misconfigured.

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 pod resource requests exceed the allocatable resources on the existing nodes after accounting for system reservations.

The cluster has 3 e2-standard-4 nodes, each with 4 vCPU and 16 GB RAM. After accounting for system reservations (e.g., kubelet, OS, daemonsets), the allocatable memory per node is typically around 13-14 GB. With 10 pods each requesting 2 GB, the total memory request is 20 GB, but the total allocatable memory across 3 nodes is only about 39-42 GB. However, the autoscaler can only scale up to 5 nodes, and even then, the total allocatable memory would be around 65-70 GB, which is sufficient. The most likely cause is that the pod resource requests exceed the allocatable resources on the existing nodes, preventing scheduling, and the autoscaler may not have triggered yet or is constrained by other factors like CPU or node limits.

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 cluster is running an older version of Kubernetes that does not support node auto-scaling.

    Why it's wrong here

    Version 1.28.5 supports node auto-scaling.

  • The node pool autoscaler is not properly configured to scale up based on pod resource requests.

    Why it's wrong here

    The autoscaler is enabled and should scale up if pods are unschedulable due to resource constraints.

  • The node auto-repair feature is disabled, causing a node to be unhealthy.

    Why it's wrong here

    Node auto-repair does not affect scheduling of new pods.

  • The pod resource requests exceed the allocatable resources on the existing nodes after accounting for system reservations.

    Why this is correct

    System reservations (kube-reserved, eviction threshold) reduce allocatable CPU and memory, and the pod requests may exceed what is available.

About these practice questions

This PCA question is part of Courseiva's 955-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.