Mutating vs Validating webhooks with an Operator
knowledge of the admission chain.
mutating runs first to inject defaults or sidecars, validating runs after to reject bad specs, both keyed to your CRD.
confusing the ordering or roles.
What's really being asked
The interviewer wants to see that you understand the Kubernetes admission control chain and where webhooks sit relative to your Operator's reconciler. Webhooks act on the object before it is persisted to etcd; the Operator acts after.
The full answer
The two phases run in a fixed order. Mutating admission webhooks fire first and may return a JSON patch that alters the incoming object. Validating admission webhooks fire afterward and may only allow or deny the request, never change it. Both are registered against your CustomResourceDefinition's group, version and kind. A mutating example: default an optional replicas field to three, or stamp a label, so users submit minimal manifests. A validating example: reject a CR whose backup schedule conflicts with its retention window, a cross-field rule that OpenAPI structural schema cannot express. You should mention failurePolicy, timeoutSeconds, and that webhooks must be highly available because they sit in the request path.
The mistakes people make
Saying a validating webhook can fix or patch the object, reversing the order, or rebuilding simple type and required checks that the CRD schema already enforces. Another mistake is putting business defaults inside the reconcile loop when they belong in mutation so the stored object is already complete.
What usually comes next
How do you avoid a webhook outage blocking all CR writes? Discuss failurePolicy Ignore versus Fail and namespace selectors. How is the webhook served and its TLS managed, often via cert-manager. How do you prevent infinite mutation loops with the Operator's own updates.
A concrete example
For a Database custom resource, the mutating webhook injects a default storageClass and a metrics sidecar container when monitoring is enabled. The validating webhook then rejects any Database whose requested storage is below the engine's minimum or whose version is not in the supported list, returning a clear message so the kubectl apply fails fast with a reason.
Interview question
A user submits a CR missing an optional field that your platform must populate, and you also need to reject specs violating a cross-field rule. Which webhook does each job?
- a.Validating defaults the field; mutating rejects the spec
- b.Both jobs require a single mutating webhook
- c.Mutating defaults the field; validating rejects the specCorrect
- d.Neither can default fields; only the reconciler can
Why? this is the answer
Mutating webhooks run first and can patch the object to add defaults, while validating webhooks run after and can only allow or deny. Reversing them fails because a validating webhook cannot change the object.
Just read this? Test yourself on what you have been reading.
Read the original → sdk.operatorframework.io
- #kubernetes
- #operators
- #admission-webhooks
- #crd
- #advanced
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles