Google PCA Ensure solution and operations reliability Practice Question

Exhibit

Refer to the exhibit.

```
$ gcloud container clusters describe my-cluster --region us-central1
...
nodePools:
- config:
    diskSizeGb: 100
    diskType: pd-standard
    imageType: COS_CONTAINERD
    machineType: n1-standard-2
    oauthScopes:
    - https://www.googleapis.com/auth/devstorage.read_only
  initialNodeCount: 3
  management:
    autoRepair: true
    autoUpgrade: true
  name: default-pool
...
```

You are running a Kubernetes cluster in GKE with the default node pool configuration shown in the exhibit. Your application requires high disk I/O performance. You notice that the application is experiencing high latency for disk operations. What is the most likely cause?

⚠ Common exam trap

Google Cloud often tests the distinction between storage performance (disk type) and other operational features (auto-repair, scopes, machine type), leading candidates to confuse node health mechanisms or permission settings with actual I/O performance bottlenecks.

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 default node pool uses pd-standard disks, which have low IOPS.

The default node pool in GKE uses pd-standard (standard persistent disk) which provides lower IOPS compared to pd-ssd. For applications requiring high disk I/O performance, pd-standard disks become a bottleneck, causing high latency. Upgrading to pd-ssd or using local SSDs would resolve this issue.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Node auto-repair is causing disk contention.
Why it's wrong here
Auto-repair recreates unhealthy nodes; it does not continuously consume disk bandwidth on healthy ones. Auto-repair would be the answer for nodes repeatedly cycling or being replaced, so this option mistakes a node-health remediation feature for a source of sustained I/O contention.
✓
The default node pool uses pd-standard disks, which have low IOPS.
Why this is correct
GKE's default node pool provisions pd-standard persistent disks, which cap IOPS far below pd-ssd or pd-balanced. Since the stem specifies high disk I/O demand and observed latency, the storage class backing the nodes is the bottleneck. Upgrading the node pool to pd-ssd resolves the constraint.
✗
The OAuth scopes restrict disk access, causing high latency.
Why it's wrong here
OAuth scopes govern which Google Cloud APIs the node can call; they do not throttle disk throughput once access is granted. Scope misconfiguration would be correct where the node cannot reach a service at all, not where reads and writes succeed but stall.
✗
The machine type n1-standard-2 does not have enough CPU.
Why it's wrong here
Disk latency stems from the node pool's default persistent disk type, typically standard PD with lower IOPS, not CPU capacity. n1-standard-2 CPU is tempting because insufficient vCPUs can bottleneck workloads, but disk I/O performance is governed by the attached disk type and size.

Visual reference

Go deeper

Google PCA Ensure solution and operations reliability Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question