Exercise 3: OS Login vs. Static Keys After an IAM Revocation — Possible Solution
====================================================================

The answer genuinely depends on which SSH access mechanism is in use,
because the two work in fundamentally different ways once IAM
permissions actually change.

If OS Login is being used, SSH access is checked against IAM on
EVERY single login attempt - the moment the employee's own IAM
permissions are revoked, their very next attempt to SSH into any
instance is checked against that now-revoked permission and blocked
immediately. There's no delay and no separate cleanup step required.

If traditional metadata-based SSH keys are being used instead, the
key itself is a real, static credential that keeps working
regardless of any later IAM change - revoking the employee's own IAM
role has no direct effect on a key that's already present in an
instance's own metadata. Someone would need to separately, manually
remove that specific key from every instance where it was added,
or the former employee's access genuinely continues working
indefinitely.

ANSWER: With OS Login, SSH access is blocked immediately after the
IAM revocation, since every login attempt is checked against current
IAM permissions in real time. With traditional metadata-based SSH
keys, the revocation has no automatic effect at all - the static key
keeps granting access until someone manually removes it from each
instance, meaning the former employee's own access could genuinely
continue working well after they've left.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains the real, structural reason the two
mechanisms behave differently (continuous IAM checking vs. a static,
independent credential) rather than just asserting "OS Login is more
secure," and matches the chapter's own explicit real distinction
between the two SSH access models.