Before writing manifests that reference an extended kind, a developer wants to see which custom APIs are installed. Which command best discovers them?
Select an answer to reveal the explanation.
Short Explanation
CRDs are the menu of extra dishes the cluster knows how to cook. kubectl get crd reads that menu before you order. Do not hunt for them in node annotations.
Full Explanation
Before referencing an extended kind in manifests, discover what custom APIs the cluster actually serves. kubectl get crd lists CustomResourceDefinitions; pairing that with kubectl api-resources shows group/version/kind and whether the resource is namespaced. That inventory prevents apply-time “resource not found” errors and clarifies which Operator-backed APIs a municipal developer may legally use. Checking CRDs first is the CKAD-friendly discovery habit for platform extensions.
kubectl get nodes -o wide fails as a CRD inventory because node listings do not embed the catalog of custom APIs in annotations for this purpose. kubectl auth can-i create pods --all-namespaces fails because it answers an authorization question about Pods, not which CRDs exist. kubectl api-resources | grep deploy fails as Operator discovery because filtering to deploy-like names misses most custom kinds and is not a CRD inventory strategy.
Exam caveat: CRDs can exist while the Operator controller is down—discovery shows the API, but reconciliation may stall; also watch API versions (v1alpha1 vs v1). Operational check: kubectl get crd, kubectl api-resources | grep <keyword>, then kubectl explain <Kind> before writing civic manifests that reference the extended kind.