After creating a custom database resource, an Operator creates a Secret and Service that the application mounts and calls. What does this illustrate for CKAD-level understanding?
Select an answer to reveal the explanation.
Short Explanation
Think of the Operator as an autopilot: you set the desired CR, and it keeps Secrets and Services lined up for your app. You consume those objects—you do not rewrite the autopilot for every bump. That is reconciliation in practice.
Full Explanation
After you create a custom database resource, an Operator that creates a Secret and Service for the application illustrates reconciliation: the Operator continuously maps desired CR state into concrete Kubernetes objects the app mounts and calls—without the application coding that automation. CKAD-level understanding is that developers consume the CR and the generated Secret/Service contracts, while the Operator owns child lifecycle. Municipal database platforms rely on that split so app teams do not hand-maintain StatefulSet glue for every civic datastore.
Requiring developers to fork and rebuild the Operator on every Secret rotation fails the Operator model; rotation should be expressed via CR/spec or Operator behavior, not app-team forks. Claiming Operator Secrets are ignored unless hostPath is used fails—normal Secret volume mounts and env refs work for in-cluster apps. Claiming Operator Services only work with NodePort fails because ClusterIP Services are the common pattern for in-cluster database access from application Pods.
Exam caveat: manually editing Operator-owned children often gets reverted on the next reconcile—change the CR instead of fighting owned Pods and Services. Operational check: create the DB CR, watch kubectl get secret,svc for instance labels, mount or connect from the municipal app using the generated credentials endpoint, and avoid patching child objects the Operator owns unless documentation marks a field as user-managed.