After a Pod create, the stored object includes an extra envoy sidecar container that was not in the developer’s manifest. A separate webhook later rejects Pods missing a required annotation. What admission behaviors do these describe?
Select an answer to reveal the explanation.
Short Explanation
Mutation rewrites the form before it is filed; validation stamps approve or deny on the final form. Sidecar injection is a rewrite. Missing-annotation rejection is a yes/no stamp.
Full Explanation
After a Pod create, the stored object including an extra envoy sidecar that was not in the developer's manifest indicates a mutating admission webhook—often a service-mesh injector—altered the Pod. A separate webhook that rejects Pods missing a required annotation demonstrates validating admission. Together these describe mutation for injection and validation for policy enforcement, a common pairing on municipal mesh-enabled clusters.
Calling both behaviors validating admission only fails because sidecar injection changes the Pod spec and is mutation; kubectl does not locally merge envoy sidecars by default. Calling both mutating admission fails because rejection without accepting the object is validation, not mutation. Claiming scheduler plugins inject sidecars while asserting validating admission cannot reject creates misstates both the scheduler's placement role and admission capabilities.
Exam caveat: webhook failure policies determine whether webhook outages block deploys; Fail is stricter for cluster availability during injector downtime. Operational check: review mutating and validating webhook configurations, set the required annotation, deploy a sample Pod, confirm the sidecar appears in live YAML, and avoid manually deleting injected containers if the injector will restore them on update.