Exercise 3: A Mismatched targetPort — Possible Solution
====================================================================

The setup: Service spec has `port: 80` and `targetPort: 8080`, but the
container is actually listening on port 3000.

What goes wrong:

Per the chapter, `port` is what CLIENTS connect to on the Service
itself, while `targetPort` is what the Service forwards that traffic
to on the CONTAINER. The Service will correctly accept connections on
port 80 (that part works fine, since `port` is just the Service's own
listening port, unrelated to the container). But when it tries to
forward that traffic to `targetPort: 8080` on the container, nothing
is actually listening there -- the container is listening on port
3000, not 8080. The connection to the actual container will FAIL --
typically manifesting as a connection refused or timeout error
(echoing the failure-type distinctions from the Cloud Platforms
course's own `cloud2-2` chapter, since "something is listening but on
the wrong port" produces exactly this kind of symptom) -- even though
the Service itself appears to be configured and running correctly.

This is exactly the chapter's own named trap: "getting this backwards
-- or forgetting that the container's actual listening port must
match targetPort exactly -- is a frequent, confusing source of 'why
can't I reach my service' issues." From the outside, the Service looks
fine (it exists, has endpoints, accepts connections on port 80), which
is precisely what makes this mismatch confusing to diagnose without
knowing to check targetPort specifically against the container's ACTUAL
listening port.

How to fix it:

Change `targetPort` in the Service's spec to `3000`, matching the
port the container is genuinely listening on. The `port` field (80)
can stay whatever value client applications should use to connect --
it doesn't need to match the container's port at all, since the
Service's whole job is to translate between the two. Only `targetPort`
needs to match the container's actual listening port exactly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This applies the chapter's own port/targetPort distinction to trace
exactly WHERE the connection fails (the Service-to-container hop
specifically, not the client-to-Service hop) and identifies the single
field that needs correcting -- directly matching the chapter's own
warn-box description of this exact class of mistake.