While applying application manifests, kubectl prints a warning that a resource type is deprecated. What is the correct response before the API is removed?
Select an answer to reveal the explanation.
Short Explanation
Deprecation warnings are yellow construction signs on the road you use every day. They still let you drive—for now—but they mean the route is closing. Plan the detour (new apiVersion) before the barricades go up.
Full Explanation
While applying application manifests, a kubectl warning that a resource type is deprecated is a signal to migrate the manifests to the supported API version soon—before removal breaks municipal apply pipelines. Deprecation warnings are intentional advance notice from the apiserver, not cosmetic noise. City platform teams should treat them as timed work items tied to the next cluster upgrade train.
Why the other options fail by concept: Ignoring all deprecation warnings forever eventually causes hard failures when APIs are removed mid-incident window. Replacing kubectl with a custom client that hides warnings removes the signal while preserving the risk. Scaling the Deployment to zero does not address API deprecation and harms availability for residents.
Exam caveat: Deprecated does not mean already removed—applies may still succeed today on the current production version. Track Kubernetes version skew across city environments so staging surfaces removals before production. Migrate live YAML and any Helm charts or Kustomize bases that still emit the old version.
Operational check: Capture deprecation warnings in CI logs as tickets, use kubectl api-resources and explain to choose replacements, update manifests, and verify with kubectl apply --dry-run=server against a cluster matching the next production version before promoting the civic app.