Exercise 3: The Real Risk of Laptop-Stored CLI Credentials, and How to Reduce It — Possible Solution
====================================================================

The real security risk:

Per the chapter, CLI credentials (access keys/service principals/
service accounts) typically live in a config file on the support
engineer's own machine -- directly echoing `cloud1-6`'s and
`pipelines1-5`'s warnings about hardcoded credentials, just relocated
from application code to a person's own laptop. If that laptop is ever
compromised (malware, theft, or the credentials file being
accidentally synced to a cloud backup or personal repository it
shouldn't be in), an attacker gains the SAME level of access those
credentials grant -- potentially broad, if the support engineer's
account has wide permissions across many customer environments. Unlike
a server-side credential managed centrally, a credential sitting on a
personal laptop is exposed to a much wider range of everyday risks
(lost devices, personal malware, casual file-sharing mistakes) that
have nothing to do with the cloud provider's own security at all.

Practices that reduce this risk:

1. SCOPED-DOWN, TASK-SPECIFIC CREDENTIALS rather than broad admin
   access -- directly applying `cloud1-6`'s least-privilege principle
   to the support engineer's own account, so a compromised credential
   only exposes what's actually needed for support tasks, not
   everything the organization has access to.

2. MFA on the account the CLI credentials belong to -- per
   `cloud1-6`'s MFA material, an additional layer that a stolen
   credential file alone doesn't automatically bypass, depending on
   how the credential type enforces it.

3. REGULAR CREDENTIAL ROTATION -- limiting how long a credential
   remains valid if it's ever exposed without anyone immediately
   noticing, directly echoing `crypto1-11`'s key-rotation material
   (limiting the blast radius of an undetected compromise).

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the specific new risk vector the chapter names (a personal
laptop's broader, everyday exposure compared to a centrally-managed
server credential) and then applies three separate principles already
established elsewhere in this course/site (`cloud1-6`'s least
privilege and MFA, `crypto1-11`'s rotation) directly to this new
context, rather than treating "reduce risk" as requiring an entirely
new set of practices.