Operators represent the most powerful extensibility mechanism in Kubernetes. As organizations mature their Kubernetes usage, they increasingly rely on operators to manage databases, message brokers, and other stateful infrastructure. Interviewers use operator questions to identify candidates who understand Kubernetes at a platform level.
Foundational questions ask about CRDs: "What is a CRD and how does it differ from a ConfigMap?" and "How does the API server know how to validate a custom resource?" Candidates should explain that CRDs extend the Kubernetes API itself, creating new endpoints that behave like built-in resources with support for kubectl, RBAC, and the watch API.
The controller reconciliation loop is the heart of the operator pattern. Interviewers expect you to describe the observe-diff-act cycle: the controller watches for changes, compares desired state to actual state, and takes corrective action. Understanding that controllers are level-triggered (they respond to the current state, not individual events) is an important distinction.
Advanced questions may cover finalizer patterns for graceful cleanup, status subresources for reporting state, and the trade-offs between building a custom operator versus using Helm or simple scripting. Candidates who can discuss real operators they have used or built demonstrate the practical experience that sets them apart.
CRDs extend the Kubernetes API by letting you define custom resource types. Once a CRD is created, users can create, read, update, and delete instances of the custom resource using kubectl, just like built-in resources. CRDs are the foundation for the Operator pattern.