5 exercises — Explain CRDs, operator reconciliation loops, custom resource documentation, status subresources, and the operator vs Helm trade-off.
0 / 12 completed
1 / 12
A backend engineer unfamiliar with Kubernetes asks what a Custom Resource Definition (CRD) does. Which explanation is most accurate?
A CRD is the schema declaration that tells the Kubernetes API server: "accept and store objects of this new kind." The custom resource instances themselves are the data; the CRD is the type definition.
Without a CRD, kubectl will reject any resource with an unknown kind. Once the CRD is installed, operators can create, update, list, and delete custom resources using the full Kubernetes API and kubectl — including label selectors, namespace scoping, and RBAC. CRDs are the foundation of the operator pattern: they give operators a declarative interface their users can interact with using familiar tooling. Examples: cert-manager installs a Certificate CRD; Prometheus Operator installs a PrometheusRule CRD.
Key vocabulary:
• CRD (CustomResourceDefinition) — extends the Kubernetes API with a new resource kind and its schema
• custom resource (CR) — an instance of a type defined by a CRD; stored and managed by Kubernetes
• OpenAPI v3 schema — the validation schema embedded in a CRD that enforces field types and constraints
2 / 12
A colleague asks you to explain how a Kubernetes operator works. Which description correctly explains the reconciliation loop?
The operator reconciliation loop is the "observe, compare, act" cycle: watch for change events → read the current state → compare with the desired state → take the smallest corrective action needed → repeat.
This is the same pattern every core Kubernetes controller uses (Deployment controller, ReplicaSet controller, etc.). Operators extend it with domain-specific logic. For a database operator, reconciliation might mean: "spec says 3 replicas at version 15.2, actual state is 3 replicas at version 15.1 → trigger a rolling upgrade." The operator encodes operational knowledge (how to safely upgrade this database) as code, removing the need for manual runbooks. Key terms: watch (listen for events), reconcile (bring actual to desired), idempotent (safe to run multiple times).
Key vocabulary:
• reconciliation loop — the operator's core cycle: observe → diff → act → repeat
• desired state — the configuration declared in the custom resource spec
• actual state — what currently exists in the cluster; may differ from desired during transitions
3 / 12
You are documenting the spec field retentionDays in a custom resource called BackupPolicy. Which documentation approach is most complete?
Custom resource fields should be documented in two places: the CRD's OpenAPI schema (for validation and kubectl explain output) and the operator README (for example manifests and human-readable context).
When a field has an OpenAPI description, running kubectl explain BackupPolicy.spec.retentionDays displays that description directly in the terminal — giving operators instant documentation without leaving their workflow. The description should include: what the field controls, valid range, default value, and what happens when it is omitted. The README example should show a complete, working BackupPolicy manifest so operators can copy-paste and adapt it rather than guessing at field combinations.
Key vocabulary:
• OpenAPI v3 schema — embedded in the CRD; provides field descriptions, types, and validation rules
• kubectl explain — CLI command that displays schema and description for any resource field
• default value — the value used when the field is omitted; must be documented explicitly in CR schemas
4 / 12
A custom resource shows status.phase: Degraded and status.conditions[0].reason: ReplicaSetUnavailable. How do you correctly interpret and communicate this to your team?
The status subresource is the operator's window into the health of what it manages — it is written by the operator, not by Kubernetes, and reflects the operator's own assessment of the controlled resource's state.
The conditions array in status follows the Kubernetes conventions for condition types: type (e.g., Available, Progressing, Degraded), status (True/False/Unknown), reason (a camelCase code), message (human-readable explanation), and observedGeneration (which version of the spec this status reflects). When interpreting a Degraded condition, look at: (1) the reason field for a machine-readable code, (2) the message field for the human-readable explanation, and (3) the operator logs for full context. Never ignore status fields — they are the operator's primary communication channel.
Key vocabulary:
• status subresource — written by the operator to reflect the current health of the managed resource
• conditions — structured health indicators in status; each has type, status, reason, message
• observedGeneration — the spec generation the operator last reconciled; helps detect stale status
5 / 12
A team is choosing between Helm and an operator to manage a stateful PostgreSQL deployment. Which explanation correctly describes when an operator is the more appropriate choice?
The key question is: does managing this application require human operational knowledge that must be enacted procedurally — if yes, that knowledge belongs in an operator; if the lifecycle is purely declarative, Helm is sufficient.
Helm upgrades by applying a new rendered manifest — excellent for stateless apps where "new version = apply new YAML." But a PostgreSQL upgrade might require: checking current replication lag, promoting a standby to primary, draining connections, running pg_upgrade, then reattaching replicas — a sequence that cannot be expressed in a single kubectl apply. Operators encode these procedures as code. This is why projects like PGO (PostgreSQL Operator), CloudNativePG, and Redis Operator exist. A common heuristic: if your runbook has conditional logic or depends on live state, it belongs in an operator.
Key vocabulary:
• stateful workload — an application with persistent identity, storage, and ordered lifecycle requirements
• operational logic — procedural knowledge about how to safely manage a system (backups, upgrades, failover)
• runbook — a documented procedure for operating a system; operators turn runbooks into executable code
6 / 12
Jane (Lead Developer) comments on a pull request:
'This CRD definition is great, but I'm not entirely clear on how the scaleSubresources field impacts scaling. Could you elaborate?'
This question tests understanding of a specific CRD field. The scaleSubresources field in a CRD allows you to define different resource requests for various node sizes, offering finer-grained control over pod scaling than just using the standard requests and limits fields. Options A and C are incorrect as they misrepresent its functionality or state it's deprecated. Option D confuses the concept with HPA.
7 / 12
Mark (DevOps Engineer) sends a Slack message to the team:
'Just deployed the new operator for our Kafka cluster. It's constantly reconciling the state – ensuring all brokers are running and configured correctly according to our desired state. The core of its operation is a continuous loop checking the actual state against what we've defined.'
This focuses on the reconciliation loop, a key concept in operator behavior. A Kubernetes operator uses a continuous loop – often referred to as 'reconciliation' – to monitor the actual state of its managed resources (like a Kafka cluster) and actively correct any differences between that state and the desired state defined in the CRD. Options A and C misrepresent the process, while option B is an oversimplification.
8 / 12
David (a junior developer) asks you about Operators:
'I've heard the term 'Operator' in relation to Kubernetes. It seems like it does more than just running deployments. Can you explain how it differs from a regular Deployment or StatefulSet?'
Operators represent a significant shift in how we manage complex stateful applications. Unlike Deployments which define the desired state and attempt to achieve it once, an Operator continuously monitors the actual state of your application and takes corrective actions to maintain that desired configuration – this includes things like database migrations or scaling based on real-time demand. Crucially, Operators actively reconcile discrepancies between the desired and actual states, a core difference from simpler deployment methods.
9 / 12
Sarah (a Senior Developer) is reviewing a pull request for a new CRD defining a 'DatabaseBackup' resource. The PR includes this YAML:
```yaml
apiVersion: backup.example.com/v1beta1
spec:
retentionDays: 30
```
Sarah comments: 'I'm not sure what the purpose of `retentionDays` is here. Can you explain how it relates to automated backups?'
The `retentionDays` field in this CRD defines how long backup data is retained before it's automatically deleted. This allows you to manage storage costs and comply with regulatory requirements by ensuring that old backups are purged after a specified period. The operator then handles the actual deletion process based on this retention policy.
10 / 12
Ben (a DevOps Engineer) sends a Slack message to the team:
'Hey everyone, just deployed the new 'OrderProcessing' operator. It's been running for an hour and I'm seeing a lot of 'Reconcile' events in the logs - it seems like it's constantly trying to bring the system back into sync. Is this normal?'
Frequent 'Reconcile' events in an Operator's logs don't necessarily indicate a problem. Operators continuously monitor and adjust the state of their managed resources to match the desired configuration. These reconciliation loops are inherent in the operator's design as it proactively corrects any deviations from the specified target state – this is a key function of their operation.
11 / 12
Emily (a Backend Developer) is writing a description for a Pull Request introducing an Operator to manage a Redis cluster:
'This operator will automatically scale the Redis cluster based on observed CPU usage and ensure that all nodes are running the latest version of Redis. It also handles failover events seamlessly.'
The key advantage of using an Operator over tools like Helm for a stateful application such as Redis is its continuous reconciliation capability. Operators actively monitor and adjust the system's configuration – in this case, scaling based on CPU usage and handling failover events – ensuring it remains in the desired state without manual intervention. Helm primarily focuses on deploying pre-configured deployments.
12 / 12
Tom (a Site Reliability Engineer) is investigating a Kubernetes cluster and sees the following status information:
`status.phase: Degraded`
`status.conditions[0].reason: ReplicaSetUnavailable`
The `status.phase: Degraded` and `status.conditions[0].reason: ReplicaSetUnavailable` message clearly indicates a problem with the application's desired state. It signifies that the number of running replicas (ReplicaSets) doesn't match the target defined by the operator, likely due to issues like pod scheduling failures or resource constraints preventing new pods from starting – requiring immediate investigation.
What will I practise in "CRD & Operator Language — Kubernetes Operations | CoderLingo"?
5 advanced exercises practising Kubernetes CRD and operator vocabulary — custom resource definitions, reconciliation loops, status subresources, and operator vs Helm decisions.
How many exercises are in this module?
This module has 12 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Kubernetes Operations exercises?
Browse the full Kubernetes Operations hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.