How does "admission control" fit into the Kubernetes API request lifecycle, and what is the difference between "ValidatingAdmissionWebhook" and "MutatingAdmissionWebhook"?
Correct! Well done.
Incorrect.
The correct answer is B) Admission controllers intercept requests after auth but before persistence; mutating webhooks can modify the object (e.g. injecting sidecars) and run first, while validating webhooks only accept or reject the resulting object
Correct Answer
Admission controllers intercept requests after auth but before persistence; mutating webhooks can modify the object (e.g. injecting sidecars) and run first, while validating webhooks only accept or reject the resulting object
The admission control phase sits between auth and persistence; mutating webhooks (which run first) can alter incoming objects (e.g. Istio's sidecar injector), while validating webhooks (running after mutation) enforce policy by accepting or rejecting the final object.