A 311 Operator ships a new CRD version and marks the old one deprecated. How should the application team that owns Custom Resources respond?
Select an answer to reveal the explanation.
Short Explanation
When the Operator authors retire a CRD version, your CRs are like forms that must match the new template. Update the Custom Resource specs to the supported version and follow their migration guidance. Clinging to the deprecated shape is how apply and reconcile start failing.
Full Explanation
When a 311 Operator ships a new CRD version and marks the old one deprecated, the application team that owns Custom Resources should update application CR specs to the Operator’s supported CRD version and follow its migration notes. Operators evolve their APIs like built-in kinds; municipal app teams must migrate CRs deliberately rather than assuming eternal dual support.
Why the other options fail by concept: Keeping the deprecated CR version forever is unsafe once storage/served versions drop it. Replacing every Custom Resource with a ConfigMap abandons the Operator’s domain logic and validation. Downgrading the Operator nightly to stay on the oldest CRD fights platform security and supportability.
Exam caveat: CRD conversion webhooks may rewrite objects automatically for some Operators, but application Git manifests should still move to the served version you intend to keep. Read storage versus served version concepts at awareness depth. Test migrations in a non-prod 311 namespace first.
Operational check: Read the Operator release notes, update CR yaml apiVersion/fields, apply to staging, confirm the Operator reconciles without errors (kubectl describe <cr>), then promote. Watch for deprecation warnings on apply as interim signals.