Demo Configure secrets at Org Repo and Environment Levels

This guide shows how GitHub Actions secrets at the organization, repository, and environment scopes interact, and which value a workflow receives when the same secret name exists in multiple places. GitHub Actions environments (for example production, staging, or development) provide deployment targets and can enforce protection rules such as required reviewers and wait timers. Environments can also hold secrets that are available only to jobs explicitly associated with that environment. Secrets can be defined at three scopes:

Organization
Repository
Environment

When a job is associated with an environment, that environment’s protection rules are applied before the job runs, and environment-level secrets (if present) take precedence over repository and organization secrets with the same name. Steps to create the demo environment and secrets

Create an environment (here named DemoEnvironment) and configure protection rules such as required reviewers and a wait timer. You can also allow admins to bypass these protections if desired.

A screenshot of the GitHub repository settings page for "Environments / Configure DemoEnvironment," showing deployment protection rules. It displays options like required reviewers, a 15-minute wait timer, and a green "Save protection rules" button.

Add secrets at each scope using the same secret name so you can observe precedence:
- Environment secret: Name DEMO_OVERRIDE_SECRET, Value EnvironmentValue
- Organization secret: Name DEMO_OVERRIDE_SECRET, Value OrganizationValue (can be scoped to all or selected repos)
- Repository secret: Name DEMO_OVERRIDE_SECRET, Value RepositoryValue

You can view these secrets in the repository settings; GitHub surfaces messages such as “This secret is overridden by a repository secret” and “This secret overrides an organization secret” to indicate precedence relationships.

A dark-mode screenshot of a GitHub repository "Secrets and variables" settings page showing Environment, Repository, and Organization secrets — each listing a DEMO_OVERRIDE_SECRET with controls to manage or create secrets. The left sidebar displays repository settings (Branches, Actions, Webhooks, etc.).

Secret precedence summary:

Environment secret (when the job is associated with that environment) overrides Repository and Organization secrets.
Repository secret overrides Organization secret.
If a job is not associated with an environment, the environment secret is not considered; repository and organization secrets follow their precedence order.

Quick precedence table

Scope present for the job	Highest precedence	Middle precedence	Lowest precedence
Job associated with environment	Environment (`DEMO_OVERRIDE_SECRET` = `EnvironmentValue`)	Repository (`RepositoryValue`)	Organization (`OrganizationValue`)
Job not associated with environment	Repository (`RepositoryValue`)	Organization (`OrganizationValue`)	(no environment)

Demo workflow: verify secret precedence Create the workflow file .github/workflows/secrets-priority.yml. The workflow contains two jobs:

env-vs-repo-vs-org: associated with DemoEnvironment — demonstrates Environment vs Repository vs Organization precedence.
repo-vs-org: not associated with any environment — demonstrates Repository vs Organization precedence.

name: Secrets Priority Demo

on:
  push:
  workflow_dispatch:

jobs:
  # --- TEST 1: ENVIRONMENT VS REPO VS ORG ---
  env-vs-repo-vs-org:
    runs-on: ubuntu-latest
    # Associates the job with the environment (applies protection rules and gives access to environment secrets)
    environment: DemoEnvironment

    steps:
      - name: Override Priority - Test 1 (Env vs Repo vs Org)
        env:
          TEST_SECRET: ${{ secrets.DEMO_OVERRIDE_SECRET }}
        run: |
          echo "======================================="
          echo "🔎 TEST 1: Environment vs Repository vs Organization"
          echo "======================================="
          if [ "$TEST_SECRET" = "EnvironmentValue" ]; then
            echo "✅ Result: Environment level won! (Highest priority)"
          elif [ "$TEST_SECRET" = "RepositoryValue" ]; then
            echo "🟢 Result: Repository level won!"
          elif [ "$TEST_SECRET" = "OrganizationValue" ]; then
            echo "⚠️ Result: Organization level won!"
          else
            echo "❌ Result: Secret not found or value did not match expectations."
          fi

  # --- TEST 2: REPO VS ORG (NO ENVIRONMENT) ---
  repo-vs-org:
    runs-on: ubuntu-latest
    # Notice: NO environment block here. Environment secrets and protections are not applied.
    steps:
      - name: Override Priority - Test 2 (Repo vs Org - No Environment)
        env:
          TEST_SECRET: ${{ secrets.DEMO_OVERRIDE_SECRET }}
        run: |
          echo "============================================"
          echo "🟣 TEST 2: Repository vs Organization (No Environment)"
          echo "============================================"
          if [ "$TEST_SECRET" = "RepositoryValue" ]; then
            echo "👉 Result: Repository level won! (Medium priority)"
          elif [ "$TEST_SECRET" = "OrganizationValue" ]; then
            echo "ℹ️ Result: Organization level won! (Lowest priority)"
          else
            echo "❌ Result: Secret not found or value did not match expectations."
          fi
          echo "============================================"

Run the workflow by pushing or triggering it via workflow_dispatch. On the Actions page you will see two jobs:

The job without an environment (repo-vs-org) runs immediately and should pick up the repository secret (RepositoryValue) if present.
The job associated with DemoEnvironment (env-vs-repo-vs-org) may be paused for required approvals and wait timers until protections are satisfied.

When a job is awaiting environment approvals, GitHub presents a deployment approval modal where reviewers can add comments and approve or reject the deployment.

A GitHub Actions workflow run page with a "Review pending deployments" approval modal open. The dialog lists "DemoEnvironment", includes a comment box, and buttons to Reject or "Approve and deploy" while the workflow details are visible in the background.

Example console output

Job that ran without an environment (expected when repository secret is RepositoryValue):

==============================================
🔵 TEST 2: Repository vs Organization (No Environment)
==============================================
👉 Result: Repository level won! (Medium priority)
==============================================

After approving the environment-associated job (expected when environment secret is EnvironmentValue):

=======================================
🔎 TEST 1: Environment vs Repository vs Organization
=======================================
✅ Result: Environment level won! (Highest priority)

Summary and best practices

Environment-level secrets take the highest priority for jobs explicitly associated with that environment. Environment protections (approvals, wait timers) can pause runs until satisfied.
Repository-level secrets override organization-level secrets when the environment does not define the secret or when a job is not using an environment.
Organization-level secrets are lowest priority in this hierarchy but are useful for centrally managed values and can be scoped to selected repositories.
For predictable behavior: keep secret names unique where possible, and document which secret scope is intended to be authoritative for each workflow.

Course Introduction

Foundation Setup

Identity and Access Management

Governance and Roles

Security and Compliance

GitHub Actions and Runners

Administration and Support

Monitoring and Optimization

Demo Configure secrets at Org Repo and Environment Levels

Watch Video