Exercise 2: Why Pods Need Their Own ServiceAccount Identity — Possible Solution
====================================================================

What a ServiceAccount is for:

Per the chapter, a ServiceAccount is "an identity for a pod or
process, not a person." It lets a running application/pod
authenticate to and interact with the Kubernetes API SERVER itself
(Chapter 2, Course 1's own architecture) directly -- for example, a
monitoring tool (this chapter's own worked example) that needs to LIST
or GET information about Pods running in the cluster, or a controller/
operator application that needs to WATCH for changes to certain
resources and react to them.

Why this needs to be distinct from a human user's own credentials:

1. HUMANS AND APPLICATIONS HAVE FUNDAMENTALLY DIFFERENT LIFECYCLES AND
   ACCESS PATTERNS. A human user authenticates interactively (via
   `k8s1-4`'s kubeconfig, often tied to their own cloud provider IAM
   identity per `cloud1-6`), typically for occasional, manual
   operations. A pod runs continuously, unattended, and needs its
   OWN, independently-manageable credential that doesn't depend on any
   particular human being logged in or present.

2. GRANTING PODS A HUMAN'S CREDENTIALS WOULD BE A SERIOUS SECURITY
   PROBLEM. If an application needed to borrow a specific person's own
   login credentials just to function, that would mean embedding a
   human's personal access (with whatever broad permissions THAT
   person happens to have) inside application code or configuration --
   directly echoing this course's earlier warnings (`k8s1-6`/
   `pipelines1-5`-style) about hardcoded/borrowed credentials being a
   real security risk, and making it impossible to apply LEAST
   PRIVILEGE (this chapter's own material) specifically to what the
   application itself actually needs, since it would inherit
   everything the human happens to have access to instead.

3. SERVICEACCOUNTS CAN BE SCOPED NARROWLY TO EXACTLY WHAT THE
   APPLICATION NEEDS. Per this chapter's own least-privilege section,
   a ServiceAccount can be bound (via a RoleBinding) to a Role granting
   ONLY the specific permissions that particular application genuinely
   requires (e.g., read-only access to Pods for a monitoring tool) --
   independent of and unrelated to whatever access any human
   administrator happens to have.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes ServiceAccounts from human credentials along both a
PRACTICAL dimension (different lifecycles -- continuous/unattended vs.
interactive/occasional) and a SECURITY dimension (least privilege
requires the application's access to be independently and narrowly
scoped, not borrowed from a person), both directly grounded in the
chapter's own stated purpose and least-privilege material.