Exercise 2: Avoiding the Downloaded-Key-in-Source-Code Risk — Possible Solution
====================================================================

The real, standard alternative here is to avoid downloading and
storing a service account key file at all - instead, use an attached
service account, which automatically obtains real, short-lived
credentials for the resource it's attached to (such as a Compute
Engine instance), with nothing for the application's own code to
manage, store, or reference directly.

This avoids the specific risk in the scenario entirely because there
is no long-lived private key file for the application to embed in its
own source code in the first place. Even if that exact same source
code were accidentally committed to a public repository, there would
be no real credential material inside it to leak - the attached
service account's own credentials are generated and rotated
automatically behind the scenes, invisible to the application's own
code.

ANSWER: Using an attached service account, rather than a downloaded
key file, removes the vulnerability at its root - the application
never possesses a long-lived credential that could accidentally be
exposed, so a public repository leak of the exact same code would
expose no real usable credential at all. This mirrors the same real
lesson from AWS's own IAM role attachment (Chapter 3 of AWS
Fundamentals) and Azure's own Managed Identity (Chapter 3 of Azure
Fundamentals).

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies that the fix removes the long-lived
credential from the picture structurally, rather than merely
suggesting more careful secret handling, and explicitly ties the
lesson back to the identical real pattern already established for
both AWS and Azure earlier in this three-course arc.