Challenge 1: Fix a Hardcoded API Key — Possible Solution
====================================================================

// First, add a secret via Settings -> Secrets and variables -> Actions,
// named e.g. API_KEY, with the value sk_live_abc123.

steps:
  - run: curl -H "Authorization: Bearer $API_KEY" https://api.example.com
    env:
      API_KEY: ${{ secrets.API_KEY }}

WHY THIS WORKS
--------------
- The literal value sk_live_abc123 is removed from the workflow file
  entirely — it never appears in the repository's own text, meaning it
  can never be exposed to anyone with read access to the repo, and it
  will never be committed into git history at all, unlike the original
  hardcoded version.
- The env: block maps the GitHub Secret (secrets.API_KEY) to a regular
  shell environment variable ($API_KEY) that the run: step's command
  can read — this is exactly this chapter's own pattern for handing a
  secret to a script without ever writing its actual value anywhere in
  the workflow's source.
- Using $API_KEY inside the curl command (rather than trying to
  reference ${{ secrets.API_KEY }} directly inside the shell command
  string) is the correct way to consume it — the secret is exposed to
  the step as a normal environment variable, and the shell command
  reads it the same way it would read any other env var.
- If this value ever ends up printed in a log for some reason, GitHub's
  automatic redaction (since it's tracked as a real secrets.* value)
  would replace it with *** — a protection the original hardcoded
  version never had at all, since GitHub has no way to know a literal
  string sitting directly in the YAML is meant to be sensitive.