Application Observability and Maintenance →hardMultiple Select

CKAD Application Observability and Maintenance Practice Question

Which THREE commands can be used to get detailed information about a pod named 'my-pod'? (Choose three.)

⚠ Common exam trap

CNCF often tests the distinction between commands that retrieve object metadata/status (get/describe) versus commands that interact with the pod's runtime (logs/exec), leading candidates to mistakenly select runtime commands for 'detailed information' about the pod itself.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

kubectl get pod my-pod -o json

`kubectl get pod my-pod -o json` retrieves the full object representation of the pod in JSON format, which includes all fields such as metadata, spec, status, and annotations. This provides detailed, machine-readable information about the pod's current state and configuration.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
kubectl logs my-pod
Why it's wrong here
The `kubectl logs my-pod` command retrieves the standard output and standard error streams from one or more containers in the pod, not the pod's configuration or state. This is application-level telemetry, which is useful for observing runtime behavior but carries no data about the pod's spec, labels, conditions, container statuses, or events. It therefore cannot serve as a way to get detailed information about the pod object itself.
✓
kubectl get pod my-pod -o json
Why this is correct
Running `kubectl get pod my-pod -o json` requests the full Pod resource from the Kubernetes API and formats it as a JSON document. This output contains the complete object, including metadata (labels, annotations, ownerReferences), the desired spec, and the live status (pod IP, phase, container states, conditions). It is the canonical machine-readable representation, which can be piped to tools like `jq` for automation.
✓
kubectl describe pod my-pod
Why this is correct
The `kubectl describe pod my-pod` command fetches the pod object and formats a human-centric report that aggregates its metadata, configuration, and runtime state. In addition to the spec and status, it includes a detailed list of recent events—such as scheduling attempts, image pulls, and health-check failures—that are not shown by plain `get`. This makes it one of the most effective commands for diagnosing why a pod is not ready or running.
✗
kubectl exec my-pod -- env
Why it's wrong here
`kubectl exec my-pod -- env` runs the `env` binary inside the pod's primary container, printing only the container's environment variables. This is a container introspection command, not a pod inspection command, and it bypasses the Kubernetes API object entirely. You would see no pod-level details like restart counts, QoS class, node assignment, or events, so it fails to provide detailed pod information.
✓
kubectl get pod my-pod -o yaml
Why this is correct
`kubectl get pod my-pod -o yaml` retrieves the identical Pod API object as the JSON variant, but serializes it to YAML instead. YAML is often easier to visually scan and diff, and it is frequently used when saving or templating Kubernetes resources. Like JSON, this output includes the full spec, status, metadata, and managedFields, making it a valid method for obtaining comprehensive pod details.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question