An operator inspects a Deployment and sees that its spec sets replicas to 5, while its status reports readyReplicas as 2. The cluster is under memory pressure and some pods are still being scheduled. What is the correct interpretation of these two fields?
- ASpec records the desired state the author requested (5 replicas), while status records the current observed state (2 ready), so the controller is still working to converge them Correct
- BThe object is inconsistent and should be deleted and recreated, because spec and status must always hold the same value
- CStatus records what the author requested (5) and spec records what is running (2), so the operator should raise spec to close the gap
- DThe operator should edit the status field to set readyReplicas to 5, which will bring the additional pods online
Why A is correct: This correctly maps spec to author-declared desired state and status to controller-reported observed state; a gap between them simply means reconciliation is in progress.
Why B is wrong: It is tempting to read the mismatch as corruption, but spec and status are meant to differ during reconciliation; deleting the object is unnecessary and would discard a working desired state.
Why C is wrong: This inverts the roles: it sounds plausible if you assume status is the target, but spec holds desired state and status holds observed state, so editing spec would only change the goal, not the current count.
Why D is wrong: Writing to status seems like a direct fix, but status is populated by the controller from observed reality and is not the lever a user pulls; the pods appear when scheduling succeeds, not when the number is typed in.