Exercise 2: ClusterIP vs. NodePort vs. LoadBalancer, and Recommendations — Possible Solution
====================================================================

The difference, per the chapter:

CLUSTERIP (default): reachable only from WITHIN the cluster. Used for
internal service-to-service traffic.

NODEPORT: exposes the service on a static port on every node's own IP,
reachable from OUTSIDE the cluster -- described in the chapter as "a
fairly blunt, less commonly used-directly-in-production mechanism."

LOADBALANCER: provisions an actual external cloud load balancer
automatically (tying to `cloud1-5`'s own load balancer material),
reachable from outside the cluster via that provisioned load
balancer's address -- the common way to expose something to the
public internet on a managed cloud provider.

(a) A backend database only the app tier should reach:
    -> CLUSTERIP. Per the chapter, this is specifically for "internal
    service-to-service traffic," and a database that should NEVER be
    reachable from outside the cluster at all is exactly this case --
    this also directly echoes the private-subnet database pattern from
    `cloud1-5`/`cloud1-7` in the Cloud Platforms course: a database
    deliberately kept unreachable from outside is a security feature,
    not a limitation. ClusterIP provides exactly that boundary within
    Kubernetes' own networking model.

(b) A public-facing web frontend on a managed cloud provider:
    -> LOADBALANCER. Per the chapter, this is "the common way to
    expose a service to the public internet on a managed cloud
    provider" -- it automatically provisions a real, externally
    reachable load balancer, which is exactly what a public-facing
    frontend needs. NodePort would technically also expose it
    externally, but the chapter specifically calls it a "blunter"
    mechanism less suited to production use than LoadBalancer's
    cleaner, provider-managed approach.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each recommendation matches the scenario's core requirement (internal-
only vs. public-facing) directly to the chapter's own stated
reachability scope for each Service type, and the database
recommendation specifically draws the parallel to the Cloud Platforms
course's own private-subnet pattern, reinforcing that "unreachable
from outside" is a deliberate security choice in both contexts, not
an oversight.