A validating admission webhook requires every new Pod in the tax namespace to carry an app.city.gov/owner label. A developer submits a Pod without that label. What happens at create time?
Select an answer to reveal the explanation.
Short Explanation
Picture a bouncer checking wristbands before anyone enters the club. Admission is that door check — no owner label, no entry, so nothing lands in etcd. This is not a scheduler or kubelet after-the-fact complaint.
Full Explanation
A validating admission webhook that requires every new Pod in the tax namespace to carry an app.city.gov/owner label rejects creates that omit it. At create time, admission control denies the request so the Pod never becomes a persisted etcd object and kubectl receives an error. Municipal labeling standards are enforced before storage, which prevents unlabeled workloads from entering the cluster and later escaping ownership audits.
Claiming the API server stores the Pod and a CronJob later patches the missing label fails the validating-admission model; rejection means there is no stored Pod for a CronJob to patch. Asserting the scheduler refuses the Pod after it is stored, leaving it Pending forever, fails the order of operations—scheduling occurs only after successful admission and persistence. Claiming kubelet drops the Pod at runtime and marks ImagePullBackOff fails because pull backoff is an image lifecycle state, and a rejected create never reaches the kubelet as an admitted Pod.
Exam caveat: webhook failPolicy Fail can also block creates when the webhook is down, which feels similar to policy rejection but is an availability failure mode. Operational check: submit a Pod without the owner label and confirm admission rejection, add the label, re-apply, and verify the Pod object exists in the tax namespace.