An open-data portal Service listens on port 80 for clients but containers listen on port 8080. How should the Service map those ports?
Select an answer to reveal the explanation.
Short Explanation
Clients dial extension 80; the app's desk is 8080 — port is the directory number, targetPort is the real desk.
Full Explanation
An open-data portal Service that listens on port 80 for clients while containers listen on port 8080 should set service port to 80 and targetPort to 8080 so clients use the stable Service port while traffic hits the container port. port is the directory number callers dial; targetPort is the desk where the process listens—mapping them correctly keeps citizen URLs on 80 without forcing the container to bind privileged ports.
Setting both port and targetPort to 80 and renaming the container port field to servicePort does not fix a container listening on 8080. Using nodePort 8080 with targetPort 80 does not correctly remap in-cluster ClusterIP traffic for this requirement. Putting 8080 only in the Service name metadata does not make kube-proxy infer targetPort from the name.
Exam caveat: targetPort may be a number or a named container port—named ports reduce drift. Operational check: set port 80 and targetPort 8080, curl the Service on 80 from a client Pod, and confirm the open-data container receives traffic on 8080. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.