tedAt":"2026-07-04T08:14:30.399+00:00","questionType":"multiple_choice"},{"id":"1cec33d3-f9f3-41a2-919c-52d3d30425ad","slug":"which-command-outputs-the-pod-s-full-yaml-specification-incl-yps3m","certificationSlug":"cncf-ckad","examCode":"CKAD","examName":"Certified Kubernetes Application Developer CKAD","questionText":"Which command outputs the pod's full YAML specification including status?","difficulty":"medium","domain":"Application Observability and Maintenance","domainSlug":"ckad-observability","topic":"","questionNumber":0,"totalQuestions":0,"options":[{"key":"A","isCorrect":false,"text":"kubectl describe pod ","explanation":"kubectl describe pod renders a human-readable summary organized into sections (Name, Namespace, Priority, Node, Status, etc.) and appends Events, but it does not emit the pod's complete manifest. It omits many spec details (e.g., exact container command, volume projection details) and injects derived information such as QoS class and tolerations, so it cannot serve as the pod's full YAML specification.","masteryContext":""},{"key":"B","isCorrect":false,"text":"kubectl get pod --export","explanation":"kubectl get pod --export is deprecated and, even when it existed, intentionally removed cluster-specific and runtime fields like clusterIP, nodeName, and status to produce a \"clean\" manifest for re-creation. Because the question asks for the full specification, this flag truncates exactly the status and other runtime state that -o yaml preserves.","masteryContext":""},{"key":"C","isCorrect":false,"text":"kubectl get pod -o json","explanation":"kubectl get pod -o json outputs the full pod object, including spec and status, but in JSON syntax. JSON is a valid data interchange format, but the question explicitly requests YAML; YAML and JSON are different serializations, and while YAML supports JSON, the output is not YAML. To get YAML you must set the output format to yaml.","masteryContext":""},{"key":"D","isCorrect":true,"text":"kubectl get pod -o yaml","explanation":"kubectl get pod -o yaml returns the live pod object from the API server serialized as YAML, including metadata (annotations/labels), spec, and status. This is the canonical way to dump the complete pod specification as stored by Kubernetes, though it includes defaulted fields and status that aren't part of the original input manifest.","masteryContext":""}],"correctOptionKey":"D","correctOptions":["D"],"correctAnswerText":"","isMultiSelect":false,"mainExplanation":"`kubectl get pod -o yaml` outputs the full YAML specification of the pod, including its status (e.g., conditions, container statuses, phase). The `-o yaml` flag retrieves the complete Kubernetes resource object from the API server, which includes both the desired spec and the current status, as stored in etcd.","examTrap":"The trap here is that candidates often confuse `kubectl describe` (which shows status in a readable format) with `kubectl get -o yaml` (which outputs the full YAML specification including status), or mistakenly think `--export` preserves status when it actually strips it.","examTip":null,"technicalDeepDive":"The -o yaml flag is not just a formatting flag; it instructs kubectl to fetch and serialize the entire current object from the cluster, including the status section which is continually updated by controllers and kubelet. This means the output is not identical to the YAML file you used with kubectl apply — it includes defaulted fields (like imagePullPolicy: Always) and system-managed fields (like metadata.creationTimestamp and status.podIP). When preparing a clean manifest, developers often use `kubectl get pod -o yaml --export` (now deprecated) or strip status with tools like yq, but those lose live state. Conversely, `kubectl describe` is designed for humans and adds non-persisted information like events. Understanding these distinctions prevents common mistakes when debugging or when using output to recreate resources, especially since -o yam