After a cluster upgrade, a parks-and-recreation Deployment YAML still references a deprecated API. What maintenance approach updates the manifests correctly?
Select an answer to reveal the explanation.
Short Explanation
Think of deprecated APIs like an expired building permit form—the clerk won’t stamp the old blank. kubectl convert or a careful manual rewrite moves your YAML onto a supported apiVersion. Then you apply the updated manifests as ordinary maintenance.
Full Explanation
After a cluster upgrade, a parks-and-recreation Deployment YAML that still references a deprecated or removed API should be updated with kubectl convert or a careful manual rewrite to a supported apiVersion, then applied. Manifest maintenance is part of application ownership for municipal workloads: cluster upgrades move the API surface, so YAML must follow.
Why the other options fail by concept: Deleting the Deployment and recreating from memory without reviewing API fields invites drift and outages. Disabling the API server’s version negotiation is not a viable or available app-developer fix. Changing only the image tag while leaving a removed apiVersion unchanged will not make invalid manifests apply.
Exam caveat: convert output is a starting point—review fields, especially for Ingress, CronJob, and CRD-backed types. Test converted YAML with server-side dry-run on the upgraded cluster before touching production parks services. Update Git sources so GitOps does not reapply the old apiVersion after you fix the live object.
Operational check: Identify the preferred apiVersion with kubectl api-resources / explain, convert or rewrite the parks Deployment, dry-run server apply, apply, and kubectl get deploy,rs,pods to confirm the recreation/rollout landed on the new version without lingering deprecation errors.