Admission webhooks: mutate first, then validate
Beyond the built-in controllers, you can register your own admission logic as an HTTPS webhook. The API server calls every matching mutating webhook first, and each may return a patch to the object: for example a service mesh injects a sidecar container, or a platform adds default labels. Only after all mutations does it call the validating webhooks, which can only allow or deny.
The order is deliberate. If validation ran first, a rule such as every Pod must have an owner label could reject an object that a mutating webhook would have fixed a moment later. Mutate-then-validate means validators always judge the final object that will actually be stored and run.
failurePolicy is the field that bites in production. With Fail, an unreachable webhook (its Pods are down, a network policy blocks it) causes the API server to reject matching requests, safe for security policy but capable of blocking even emergency changes. With Ignore, the request goes through unvalidated, which keeps the cluster available but means policy has a silent failure mode. Choose per hook: critical security policy usually warrants Fail with a highly available webhook; nice-to-have defaulting should be Ignore.
Gotcha: a webhook that selects its own namespace can deadlock, because the Pod that serves the webhook cannot be created while the webhook is down. Exclude the webhook's own namespace and kube-system with a namespaceSelector.