Secret references & job scope

Reference secrets without embedding them

Lesson 11 of 20 · 12 min · Module 4: A pipeline and its release boundary

A workflow should name a secret without storing its value in version control.

Free. No installation: you write and run the code in your browser, and it is checked automatically.

By the end, you’ll be able to…

Store the reference in source
Keep the publishing privilege local

The idea

A workflow combines an event boundary, job dependencies, and ordered steps. Conditions and prerequisite outcomes determine which jobs can run.

password: "${{ secrets.EXAMPLE_TOKEN }}"
# This is a managed-secret reference, not a credential value.

01Store the reference in source

The expression names a secret managed by the real platform. It should not contain a literal token or ask a teammate to paste one into the repository.

02Keep the publishing privilege local

Only a job that publishes needs the corresponding write capability. Read-only test jobs should retain the default boundary.

03Treat logs as another exposure surface

A secret reference does not make arbitrary echo commands safe. Avoid printing values and use short-lived credentials where the real deployment platform supports them.

Your turn

Create publish on ubuntu-latest. Give only that job contents: read and packages: write. Use docker/login-action@v3 with registry registry.example, username learner, and password "${{ secrets.REGISTRY_TOKEN }}".

What the checks look for

Uses a secret reference rather than a value
Keeps write access on publish only

Try it in the editor →

Take this with you

Keep credential values outside source and scope access to the job that needs it.

Go a little further

Explain how short-lived federated credentials can reduce stored-secret risk.