Question 473 of 509
Manage implementation of cloud architectureeasyMultiple ChoiceObjective-mapped

Quick Answer

The answer is that the pod resource requests exceed the allocatable resources on the existing nodes after accounting for system reservations. This is the most likely cause of a GKE pod scheduling failure because each e2-standard-4 node provides roughly 13–14 GB of allocatable memory after the kubelet, OS, and daemonsets consume their share, yet ten pods each requesting 2 GB total 20 GB—more than the three nodes can accommodate at once. On the Google Professional Cloud Architect exam, this scenario tests your understanding of how resource requests interact with node allocatable capacity and cluster autoscaler behavior; a common trap is assuming the autoscaler will instantly add nodes, but it only triggers when pending pods cannot fit on existing nodes, and here the requests simply exceed what’s available before scaling. Remember the memory tip: “Requests rule the scheduler—if they don’t fit, pods won’t sit.”

Google PCA Manage implementation of cloud architecture Practice Question

This PCA practice question tests your understanding of manage implementation of cloud architecture. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

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?

Clue words in this question

Noticing these words before you look at the options changes how you read each choice.

  • Clue: "most likely"

    Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.

  • Clue: "least"

    Why it matters: You want the option with minimum overhead, fewest steps, or lowest impact — not the most feature-rich or comprehensive answer.

  • Clue: "minimum / minimize"

    Why it matters: Asks for the least resource use — fewest addresses, smallest subnet, lowest overhead. Eliminate over-provisioned options even if they would technically work.

Question 1easymultiple choice
Full 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
```

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.

Option D is correct because 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.

Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

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.

    Clue confirmation

    The clue words "most likely", "least", "minimum / minimize" in the question point toward this answer.

    Related concept

    Read the scenario before looking for a memorised answer.

Common exam traps

Common exam trap: answer the scenario, not the keyword

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.

Detailed technical explanation

How to think about this question

The Cluster Autoscaler works by monitoring pods that are in a 'Pending' state due to insufficient resources and then adding nodes to the node pool. However, it only scales up if the pod resource requests (not limits) exceed the allocatable resources on existing nodes, and it respects the node pool's maximum size. In this scenario, with 10 pods each requesting 2 GB, the total request is 20 GB, but the allocatable memory per e2-standard-4 node is about 13.5 GB (after reserving ~2.5 GB for system components), so 3 nodes provide ~40.5 GB, which is enough. The real issue might be that the pods have other resource constraints (e.g., CPU) or the autoscaler is delayed, but the question's context points to memory requests exceeding allocatable resources on the existing nodes, causing a scheduling failure.

KKey Concepts to Remember

  • Read the scenario before looking for a memorised answer.
  • Find the constraint that changes the correct option.
  • Eliminate answers that are true in general but not in this case.

TExam Day Tips

  • Watch for words such as best, first, most likely and least administrative effort.
  • Review why wrong options are wrong, not only why the correct option is correct.

Key takeaway

Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Real-world example

How this comes up in practice

An e-commerce site experiences heavy traffic on Black Friday and near-zero traffic during off-peak weeks. Rather than provisioning permanent large VMs, the team uses auto-scaling groups that add capacity automatically under load and reduce it overnight. Questions like this test whether you understand elasticity, availability zones, and cloud compute scaling patterns.

What to study next

Got this wrong? Here's your next step.

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Related practice questions

Related PCA practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Practice this exam

Start a free PCA practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

FAQ

Questions learners often ask

What does this PCA question test?

Manage implementation of cloud architecture — This question tests Manage implementation of cloud architecture — Read the scenario before looking for a memorised answer..

What is the correct answer to this question?

The correct answer is: The pod resource requests exceed the allocatable resources on the existing nodes after accounting for system reservations. — Option D is correct because 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.

What should I do if I get this PCA question wrong?

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

Are there clue words in this question I should notice?

Yes — watch for: "most likely", "least", "minimum / minimize". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.

What is the key concept behind this question?

Read the scenario before looking for a memorised answer.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Last reviewed: Jun 30, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

Sign in to join the discussion.

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.