Challenge 3: Spot the Credential Leak — Possible Solution
====================================================================

WHY THE API KEY IS STILL COMPROMISED: per Chapter 2's layer mechanics,
each Dockerfile instruction creates its OWN layer, and every layer is
recorded as a diff that becomes a permanent part of the image's
history — it is never truly removed just because a LATER layer undoes
its visible effect.

ENV API_KEY=abc123 creates a layer where that environment variable
(and its literal value, abc123) is set — that layer, containing the
real secret value, is now baked into the image permanently.

RUN unset API_KEY only affects the environment WITHIN that one RUN
instruction's own layer and, practically speaking, doesn't even remove
the ENV instruction's effect for the rest of the image (ENV values set
via the ENV instruction persist for the running container regardless
of a later unset in a different layer) — but even setting aside that
detail, the deeper problem is structural: the EARLIER layer where
ENV API_KEY=abc123 was set still exists in the image's history,
completely unaffected by whatever a later layer does.

Anyone with access to the image can run docker history on it, or
simply extract and inspect the image's layers directly (a docker save
followed by unpacking the resulting tarball, for instance), and find
the literal string abc123 sitting in that earlier layer's metadata or
filesystem diff — with no need to run the image at all, let alone
encounter whatever the later "unset" layer tried to do. The secret was
compromised the instant the ENV instruction was built into a layer;
nothing that happens afterward in a later layer can undo that.