A Deployment defines a container port named http on 8080. How can a probe reference that port clearly?
Select an answer to reveal the explanation.
Short Explanation
Named ports are sticky notes on the wiring diagram—'http' means 'whatever number we labeled http.' Point the probe’s port at that name and it follows the containerPort definition. You avoid chasing magic numbers when the listen port changes.
Full Explanation
When a Deployment defines a container port named http on 8080, a probe can reference that port clearly by setting the probe’s port field to the string name http so it resolves to the named containerPort. Named ports act as stable aliases: manifests can change the numeric listen port in one place and keep probes aligned without hunting magic numbers through liveness and readiness blocks.
Why the other options fail by concept: Hard-coding the probe port to 443 while ignoring the containerPort list misses the health endpoint because the container listens on 8080. Omitting the port and assuming kubelet always picks the first hostPort on the node is incorrect—probes do not work that way and hostPort is unrelated. Using the Service ClusterIP as the probe port number confuses Service virtual IPs with the container port the kubelet must probe locally.
Exam caveat: The name in the probe must exactly match containerPort.name on the same container. Numeric ports remain valid; names are for clarity and DRY manifests. For multi-container Pods, ensure the probe is on the container that owns that named port. The named-port pattern is the operational truth for CKAD.
Operational check: Define containerPort name http with containerPort 8080, set readinessProbe.httpGet.port to http, apply, and kubectl describe pod to confirm probes succeed. Change the numeric port once, keep the name, and verify probes still work without editing probe numbers.