Exercise 3: What Makes the "After" authorized_keys Version Better — Possible Solution
====================================================================

WHAT SPECIFICALLY CHANGED
------------------------------
The "before" version shows three raw public key lines with no
identifying information at all. The "after" version appends a clear
comment to each key: the owner's identity (e.g. j.lee@company.com), the
date it was added, and in one case a note about its status (legacy
RSA, scheduled for rotation).

WHY THIS MAKES THE FILE MORE USEFUL
------------------------------
Per this chapter, "the 'before' version is three anonymous,
uninterpretable lines - nobody could confidently answer 'who is this?'
months later. The 'after' version answers it directly, on sight, for
anyone who ever needs to." A raw public key string is not human-
readable or identifiable on its own - without a comment, there is no
way to determine whose key it is without cross-referencing some
external record, if one even exists.

A REAL SITUATION WHERE THIS DIFFERENCE MATTERS
------------------------------
Per this chapter, this file becomes genuinely useful "during
onboarding/offboarding verification, or when investigating 'how did
they get in' during a security incident." If a former employee's
access needs to be revoked, an unlabeled authorized_keys file offers no
way to identify which line is theirs without guesswork - a labeled one
lets someone find and remove the exact right entry immediately. In a
security investigation, being able to instantly see who each key
belongs to (and when it was added) is often the fastest way to
determine whether access was ever granted appropriately.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies the specific change (identifying comments added to each
key), explains why that specifically increases the file's usefulness,
and names concrete real scenarios (offboarding, incident investigation)
where the difference has real practical consequences.