Practice the vocabulary of extending the Kubernetes API with a custom resource type.
0 / 5 completed
1 / 5
At standup, a dev mentions extending the Kubernetes API with a brand-new, custom resource type, like a 'Database' object, that behaves just like a built-in resource such as a Pod. What is this extension mechanism called?
A Custom Resource Definition, or CRD, extends the Kubernetes API with a brand-new, custom resource type, like a 'Database' object, that behaves just like a built-in resource such as a Pod, complete with its own API endpoint and validation. Only using built-in resource types limits what a team can express declaratively through the Kubernetes API. This extension mechanism is what lets a domain-specific concept become a first-class, declaratively managed Kubernetes object.
2 / 5
During a design review, the team wants a custom controller to watch for a new 'Database' custom resource being created and automatically provision the actual underlying database it describes. Which capability supports this?
A custom controller implementing the operator pattern watches for a new custom resource, like a 'Database' object, being created and automatically provisions the actual underlying resource it describes. Creating a custom resource with no controller watching it leaves that resource as just an inert record with no real action taken on it. This controller is what gives a CRD real, functional behavior rather than being purely declarative data with no effect.
3 / 5
In a code review, a dev notices the CRD defines a strict OpenAPI schema for its custom resource, rejecting an invalid field value at creation time rather than accepting anything and failing later. What does this represent?
Schema validation enforced at the Kubernetes API level rejects an invalid field value for a custom resource right at creation time, rather than accepting anything and letting a downstream controller fail later trying to act on invalid data. Accepting any value with no validation risks a malformed custom resource silently sitting in the cluster until something eventually breaks. This API-level validation catches a mistake immediately, before it ever reaches the controller acting on that resource.
4 / 5
An incident report shows a custom resource was created with a typo in a required field, and the controller failed silently for hours before anyone noticed the underlying resource was never actually provisioned. What practice would prevent this?
Defining a strict schema on the CRD rejects an invalid field immediately at creation time, and clear controller-status reporting surfaces a later failure instead of letting it happen silently. Accepting any value with no validation or status reporting risks exactly the kind of hours-long silent failure this incident describes. This combination of upfront validation and visible status reporting is what makes a custom resource's behavior genuinely observable.
5 / 5
During a PR review, a teammate asks why the team defines a Custom Resource Definition and a controller instead of just managing the same concept through a separate script or tool outside of Kubernetes entirely. What is the reasoning?
A CRD makes a domain-specific concept a first-class, declaratively managed Kubernetes object, complete with built-in API-level validation and integration with existing Kubernetes tooling like kubectl and RBAC. A separate external script lacks that same native integration and typically needs its own separate validation and access-control logic. The tradeoff is the added complexity of designing and maintaining a CRD's schema and a controller to actually act on it.