Study guide
8.2 Environments, Protection Rules & Deployment Approvals
GitHub Actions Certification GH-200
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Exam Overview
1.1 Exam Structure, Format & Scoring 1.2 GitHub Actions Architecture & Core Mental Model 1.3 Hands-On Preparation & Exam Day Strategy
2 Chapter 2: Workflow Triggers & Event Architecture
2.1 Webhook & Code Events: push, pull_request, and pull_request_target 2.2 Scheduled & Manual Triggers: schedule, workflow_dispatch, and repository_dispatch 2.3 Release, Issue, and Dynamic Lifecycle Events 2.4 Branch, Tag, and Path Filtering Patterns
3 Chapter 3: Jobs, Matrix Strategies & Execution Control
3.1 Job Anatomy, Step Execution & Job Dependencies (needs) 3.2 Contexts, Expressions & Functions 3.3 Environment Variables & Workflow Commands 3.4 Matrix Strategies & Multi-Platform Builds 3.5 YAML Anchors, Aliases & Merge Keys
4 Chapter 4: Reusable Workflows & Troubleshooting
4.1 Authoring & Calling Reusable Workflows (workflow_call) 4.2 Comparing Reusable Workflows, Composite Actions & Starter Workflows 4.3 Troubleshooting Workflow Runs & Debug Logging 4.4 Concurrency Controls & Status Check Functions
5 Chapter 5: Authoring Custom Actions
5.1 Action Architecture & action.yml Specification 5.2 Authoring Composite Actions 5.3 Building JavaScript Actions 5.4 Building Docker Container Actions
6 Chapter 6: Action Distribution, Marketplace & Advanced Action Types
6.1 Action Versioning, Semantic Releases & Tagging 6.2 Publishing Actions to GitHub Marketplace 6.3 Service Containers & Network Topology 6.4 actions/github-script & Workflow Tooling
7 Chapter 7: Runner Infrastructure & Self-Hosted Runners
7.1 GitHub-Hosted Runners & Larger Runners 7.2 Self-Hosted Runner Setup, Architecture & Communication 7.3 Self-Hosted Runner Security & Ephemeral Runners 7.4 Runner Groups, Labels & Organization Routing
8 Chapter 8: Enterprise Governance, Policies & Environments
8.1 Enterprise & Organization Action Policies 8.2 Environments, Protection Rules & Deployment Approvals 8.3 Repository Rulesets, Required Status Checks & Governance 8.4 Usage Limits, Billing Multipliers & Usage Metrics
9 Chapter 9: Secrets, Permissions & OIDC Cloud Authentication
9.1 Encrypted Secrets Architecture & Scopes 9.2 GITHUB_TOKEN & Least Privilege Configuration 9.3 OpenID Connect (OIDC) & Workload Identity Federation 9.4 Script Injection Prevention & Secure Workflow Patterns
10 Chapter 10: Supply Chain Hardening & Performance Optimization
10.1 Supply Chain Hardening: SHA Pinning, Dependabot & Artifact Attestations 10.2 Caching Dependencies with `actions/cache` 10.3 Artifacts Management & Job Handoff 10.4 Workflow Performance, Cost Optimization & Architecture Review
8.2 Environments, Protection Rules & Deployment Approvals
Key Takeaways Explain This Topic AI
Environments in GitHub Actions represent distinct logical deployment targets (e.g., production , staging ) configured with environment-scoped secrets, variables, and protection rules.
Built-in protection rules enforce operational gates before jobs start, including Required Reviewers (up to 6 individuals or teams with self-approval prevention), Wait Timers (0 to 43,200 minutes), and Deployment Branches/Tags.
Custom deployment protection rules use GitHub Apps and the deployment_protection_rule webhook to let external systems such as ServiceNow, Datadog, or Jira approve or reject a deployment before the job starts.
Workflows bind to environments using the job-level environment: keyword, enabling dynamic metadata like deployment URLs ( url: ) rendered directly on pull requests and deployment logs.
Environment secrets override repository and organization secrets of identical names, and are only decrypted and delivered to the runner after all protection rules have succeeded.
Last updated: August 2026
Environments, Protection Rules & Deployment Approvals
Continuous Deployment (CD) pipelines require rigorous separation of duties, auditable approval workflows, and strict access controls for production infrastructure. In GitHub Actions, these operational controls are centered around Environments .
Environments represent logical deployment targets—such as production , staging , qa , or preview —configured with specialized protection rules, dedicated environment secrets, and deployment tracking metadata. Understanding environment configuration and protection gates is essential for mastering enterprise CD workflows.
1. Environment Architecture & Secrets Precedence
An environment binds sensitive credentials, configuration variables, and operational constraints to a named deployment target configured under Repository Settings → Environments . Secret Resolution Precedence (Highest to Lowest):
- 1. Environment Secrets (Scoped to target environment: e.g., production)
- │ (Overrides)
- ▼
- 2. Repository Secrets (Scoped to repository)
- │ (Overrides)
- ▼
- 3. Organization Secrets (Inherited org-wide or via team access)
- The Security Isolation Guarantee
When a workflow job specifies environment: production :
The runner does not receive environment secrets or configuration variables when the job is queued.
Secrets are only decrypted and injected into the runner after every environment protection rule (required approvals, wait timers, branch filters, and custom checks) has fully satisfied its validation criteria.
If an approval is rejected or a custom protection rule fails, the runner never starts, and production secrets are never exposed.
2. Built-in Environment Protection Rules
GitHub Actions provides three core built-in protection rules that can be configured independently or in combination for any environment:
1. Required Reviewers (Manual Approval Gates)
Allows repository administrators to designate up to 6 individual users and/or teams who must review and approve deployment jobs.
When a workflow job targeting the environment triggers, the job enters a Waiting status.
Reviewers receive email notifications and a prominent banner on the workflow run page with a "Review deployments" prompt to Approve or Reject.
Prevent Self-Review: An essential compliance toggle that ensures the user who initiated or triggered the workflow run cannot approve their own deployment, satisfying SOC 2 and ISO 27001 separation-of-duties requirements.
2. Wait Timer
Delays job execution for a specified duration in minutes (from 0 up to 43,200 minutes / 30 days ) after the job is triggered or approved.
Commonly used for:
Providing a cooldown window after staging deployments.
Establishing soak periods between progressive canary rollouts.
Enforcing maintenance window delays.
3. Deployment Branches and Tags
Restricts which Git branches or tags are permitted to deploy to the environment.
Configuration options include:
All branches: Any branch in the repository can deploy.
Protected branches only: Only branches covered by classic branch protection or active Rulesets can deploy.
Selected branches/tags: Uses fnmatch glob patterns to specify exact branches (e.g., main , releases/* ) or release tags (e.g., v* ).
If a pull request on a feature branch ( feature/user-auth ) triggers a workflow job targeting an environment restricted to main , the job is blocked immediately with a configuration mismatch error.
3. Custom Deployment Protection Rules
In addition to built-in rules, GitHub Enterprise allows organizations to install Custom Deployment Protection Rules powered by GitHub Apps. [Job: Deploy Prod] ──► Triggers Environment 'production'
- │
- ▼
- [Custom Deployment Protection Rule]
- (GitHub sends webhook to External App)
- │
- ┌─────────────────────┼─────────────────────┐
- ▼ ▼ ▼
- [ServiceNow / Jira] [Datadog / Dynatrace] [Snyk / Wiz]
- Change Request Ticket Health / Error Rate Security & Policy
Status == APPROVED? Metrics Normal? Scan Clean?
- │ │ │
- └─────────────────────┼─────────────────────┘
- │
- ▼
- [App calls GitHub API: Approve / Reject]
- │
- ┌────────────────────┴────────────────────┐
- ▼ ▼
- [Approved] [Rejected]
- Job executes on runner Job fails immediately
- How Custom Rules Operate
When the job enters the environment gate, GitHub pauses execution and dispatches a deployment_protection_rule event webhook to the registered GitHub App.
The external system evaluates automated compliance criteria (e.g., verifying an approved Change Advisory Board ticket in ServiceNow, verifying zero Sev-1 alerts in Datadog, or checking regulatory compliance).
The GitHub App posts a response back to the GitHub REST API ( POST /repos/{owner}/{repo}/actions/runs/{run_id}/deployment_protection_rule ) with a state of approved or rejected along with a comment.
The job stays in a waiting state until the app responds. GitHub's published ceiling for this is the gate approval limit of 30 days : a workflow run may wait at most 30 days on an environment approval, and the whole run is cancelled at the 35-day workflow-run limit regardless. A custom rule that never answers therefore parks a run - and its concurrency slot - for a very long time, which is why production integrations should always post an explicit rejection on failure rather than staying silent.
4. Configuring Environments in Workflow YAML
Workflows reference environments using the environment keyword at the job level. GitHub Actions supports both simple string notation and expanded object notation with dynamic deployment URLs. name: Continuous Deployment Pipeline
on:
push:
branches:
- main
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run automated test suite
- run: npm ci && npm test
deploy-staging:
- needs: build-and-test
- runs-on: ubuntu-latest
environment:
- name: staging
- url: https://staging.app.example.com
steps:
- name: Deploy to Staging Cluster
- run: ./deploy.sh --target staging
deploy-production:
- needs: deploy-staging
- runs-on: ubuntu-latest
- concurrency: production-deployment
environment:
- name: production
- url: ${{ steps.deploy-step.outputs.environment_url }}
steps:
- name: Checkout Code
- uses: actions/checkout@v4
- name: Deploy to Cloud Infrastructure
- id: deploy-step
env:
- # Scoped environment secret released only after all rules pass
- PROD_API_KEY: ${{ secrets.PROD_API_KEY }}
- DATABASE_URL: ${{ secrets.DATABASE_URL }}
- run: |
- echo "Deploying application to production..."
- DEPLOY_URL=$(./scripts/cloud-deploy.sh)
- echo "environment_url=$DEPLOY_URL" >> $GITHUB_OUTPUT
- Key YAML Configuration Properties
environment.name : The exact string name of the target environment configured in repository settings.
environment.url : An output expression or static string URL. GitHub Actions renders this URL as a clickable "View deployment" button in the workflow run summary, deployment timeline, and associated pull requests.
concurrency : Often combined with environments to ensure only one deployment executes at a time, preventing race conditions.
5. Deployment Tracking, Audit Logs & Historical Records
GitHub Actions integrates natively with the GitHub Deployments API to provide complete traceability:
Deployment History Dashboard: Under the repository homepage, the Environments sidebar displays the active deployment SHA, time of deployment, deployment author, and historical timeline of past releases.
Audit Log Events: Every reviewer approval, rejection, wait timer expiration, and custom protection rule verdict is logged with timestamps and actor identities in the Organization and Enterprise audit logs, ensuring complete compliance auditability.