Before applying a Kustomize overlay for a inspections service, the developer wants to review the fully merged YAML. Which approach renders that output for inspection?
Select an answer to reveal the explanation.
Short Explanation
Rendering first is like proofreading the assembled permit packet before you stamp APPROVED. kubectl kustomize / kustomize build shows the final YAML so surprises show up on screen, not in the cluster.
Full Explanation
Before applying a Kustomize overlay for an inspections service, the developer should run kubectl kustomize (or kustomize build) on the overlay directory and review the emitted manifests. That render-only step shows the fully merged YAML—base resources, patches, name prefixes, generators, and namespace rewrites—so municipal reviewers can catch wrong images, RBAC, or probe edits before any cluster mutation occurs.
Why the other options fail by concept: kubectl drain on a worker node disrupts scheduling and does not print merged overlay YAML. helm repo update refreshes Helm chart indexes; it does not print Kustomize builds. Opening etcdctl get --prefix and reading raw keys is not an application-developer workflow for reviewing an overlay render and is inappropriate on managed city clusters.
Exam caveat: Review rendered RBAC, images, probes, and names carefully—generators and patches can surprise even experienced teams. kubectl’s embedded Kustomize version may differ from a standalone kustomize binary; pin tooling in CI. Diff rendered output against the previous release artifact as part of municipal change control.
Operational check: kubectl kustomize overlays/inspections > /tmp/inspections.yaml, peer-review the file, then kubectl apply -k overlays/inspections only after approval. Store the rendered artifact with the change ticket so auditors can see exactly what was intended for the inspections service.