A scheduled reports CronJob still uses batch/v1beta1 and fails on a newer cluster. Which migration fixes the application schedule object?
Select an answer to reveal the explanation.
Short Explanation
CronJob grew up: the beta house number is gone, and it lives at batch/v1 now. Update the apiVersion (and any field renames the stable schema needs) so the schedule object applies again.
Full Explanation
A scheduled reports CronJob that still uses batch/v1beta1 and fails on a newer cluster should be migrated by changing the CronJob apiVersion to batch/v1 and adjusting fields as required by the stable schema. That restores the municipal reporting schedule onto a supported API so applies succeed after control-plane upgrades and the city continues to receive scheduled Jobs.
Why the other options fail by concept: Renaming the kind to Deployment while keeping batch/v1beta1 neither fixes the removed API nor preserves CronJob scheduling semantics. Moving CronJob YAML into an annotation on a Service does not schedule Jobs. Replacing the schedule with a laptop kubectl logs loop abandons in-cluster scheduling and operational reliability.
Exam caveat: Field names and structure can differ between v1beta1 and v1—verify with kubectl explain cronjob --api-version=batch/v1. Concurrency policy, successful/failed history limits, and timezone-related fields should be reviewed during migration. Ensure the Job template’s Pod spec still passes Pod Security for the reports namespace.
Operational check: Confirm cronjobs via kubectl api-resources, rewrite the manifest to batch/v1, server-side dry-run, apply, then kubectl get cronjobs and wait for the next successful scheduled Job. Validate report artifacts or logs before closing the migration ticket.