Exercise 3: The Benefit of TLS Termination at the Ingress — Possible Solution
====================================================================

Per the chapter, TLS termination at the Ingress provides "one place to
manage certificates... for many backend services, rather than
configuring TLS separately in every individual service." Unpacking
what this actually saves:

WITHOUT centralized termination (configuring TLS per backend service):
every individual backend service would need its own certificate
configuration, its own certificate renewal process, and its own TLS
setup maintained independently. For an application with many backend
services (matching this chapter's own five-microservice scenario),
that means FIVE separate places where certificates could expire,
FIVE separate configurations to keep consistent and updated, and FIVE
separate opportunities for a misconfiguration or an expired
certificate to cause an outage.

WITH centralized termination at the Ingress: TLS/HTTPS is handled in
exactly ONE place -- the Ingress itself decrypts incoming HTTPS traffic
and then forwards plain HTTP traffic internally to whichever backend
service the routing rules point to. This means:

1. ONLY ONE CERTIFICATE (or certificate set) needs to be managed,
   renewed, and monitored, rather than one per backend service --
   directly reducing the real operational complexity the chapter
   names.

2. Backend services themselves don't need to implement TLS handling
   at all -- they can be simpler, focusing purely on their own
   application logic, since the Ingress has already handled
   encryption/decryption before traffic ever reaches them.

3. Adding a NEW backend service later doesn't require setting up TLS
   for it specifically -- it simply becomes another routing target
   behind the Ingress's already-existing, already-configured
   certificate.

This connects directly to `https1`'s own TLS material and `crypto1`'s
certificate-chain material -- the same principle of centralizing a
security-critical, easy-to-misconfigure concern in one well-maintained
place, rather than duplicating it (and duplicating the risk of getting
it wrong) across every individual service.

WHY THIS WORKS AS AN ANSWER
------------------------------
This expands the chapter's brief "reduces real operational complexity"
claim into the SPECIFIC operational burdens (certificate count,
renewal tracking, per-service configuration) that centralizing TLS
actually eliminates, rather than simply restating that centralization
is "simpler" without explaining what specifically gets simpler.