A city’s Ingress manifest still declares a removed beta apiVersion and fails on a current cluster. What should the application developer do?
Select an answer to reveal the explanation.
Short Explanation
Old beta apiVersions are like expired parking permits—the gate will not open. Move the Ingress to the current stable group/version on the form and try again.
Full Explanation
When a city’s Ingress manifest still declares a removed beta apiVersion and fails on a current cluster, the application developer should update the manifest to the supported stable apiVersion for Ingress and re-apply. API version migration is routine application maintenance as clusters advance; pinning civic manifests to removed betas breaks production applies.
Why the other options fail by concept: Keeping the removed beta and lowering the cluster version permanently rejects platform security upgrades. Converting Ingress into a ConfigMap abandons Ingress behavior. Deleting the kube-apiserver Pod does not re-enable retired beta APIs.
Exam caveat: Field names can change between beta and stable (for example backend structure)—run kubectl explain ingress --api-version=<stable> and convert carefully. kubectl convert may help but verify output. IngressClass and controller-specific annotations still matter after apiVersion fixes.
Operational check: kubectl api-resources | grep ingress, rewrite apiVersion to networking.k8s.io/v1 (or the cluster’s preferred), kubectl apply --dry-run=server -f ingress.yaml, then apply for real and kubectl get ingress to confirm the city routing object exists.