A developer writing new workload YAML needs to know which apiVersion the cluster prefers for a resource kind. Which approach helps choose the preferred version?
Select an answer to reveal the explanation.
Short Explanation
API discovery is the cluster’s menu board: it shows which dishes (versions) are served today and which is preferred. Check that board before you order an alpha special that disappeared last season.
Full Explanation
A developer writing new workload YAML should use API discovery—for example kubectl api-resources and kubectl explain—to see which apiVersions the cluster supports and prefers for a given kind. Choosing the preferred version from the live municipal cluster is far safer than guessing alphas or copying blog posts written for a different Kubernetes major. Discovery keeps new city manifests aligned with what the apiserver will actually accept.
Why the other options fail by concept: Guessing the oldest alpha version maximizes breakage and instability, not forward compatibility. Copying apiVersions from a blog aimed at another major risks removed or divergent APIs. Omitting apiVersion entirely is invalid for standard resource manifests; the apiserver does not invent a version for your unchecked YAML file on each request.
Exam caveat: Preferred versions can differ between staging and production if clusters are skewed—discover per environment. CRDs introduce additional versions with conversion strategies you must respect. kubectl explain <kind> --api-version=<v> disambiguates fields when multiple versions coexist during migrations.
Operational check: kubectl api-resources | grep -i <kind>, kubectl explain <kind>, author manifests with the preferred apiVersion, and kubectl apply --dry-run=server -f <file> to validate before committing to the city application repository.