Secure and Optimize Automation
This domain (≈15% of GH-200, roughly 8–12 scored items on a 55–65 item exam) tests two intertwined skills: hardening GitHub Actions workflows against supply-chain compromise, credential theft and script injection; and tuning them for runtime, minutes consumption and storage cost. Expect scenario questions that hand you a YAML snippet and ask "what is the vulnerability?" or "what is the minimum change that satisfies the requirement?" The blueprint rewards knowing exact keys (permissions, id-token, attestations, concurrency), exact defaults (90-day artifact retention, 10 GB cache, 6-hour job limit) and the precise boundary between features that look interchangeable (environment approvals vs. branch protection; GITHUB_TOKEN vs. PAT vs. OIDC; cache vs. artifact).
Environment protections and approval gates
An environment is a named deployment target (environment: production) declared at the job level. Protection rules only apply to jobs that reference the environment — a job without the environment: key bypasses every gate, which is the single most common exam distractor.
Available protection rules:
| Rule | Configuration | Limits / behavior |
|---|---|---|
| Required reviewers | Up to 6 users or teams | Any one required reviewer's approval releases the job; optional Prevent self-review; job stays queued and fails after 30 days without approval |
| Wait timer | 0–43,200 minutes (30 days) | Delays the job after it is triggered; no human action needed |
| Deployment branch and tag rules | All branches / Protected branches only / Selected branches and tags (name patterns) | Prevents deployments from arbitrary refs; patterns support * |
| Custom deployment protection rules | GitHub App–based (e.g. ServiceNow, Datadog, Honeycomb) | Third-party gate calls back to approve/reject |
| Environment secrets / variables | Scoped to the environment | Not readable until all gates pass — the job cannot even start |
Key mechanics: a job pending review shows as Waiting; approval is recorded as a deployment review and is auditable. Environments plus environment secrets and deployment branch rules are available in public repositories on all plans, but in private/internal repositories require GitHub Pro, Team, or Enterprise. Secret precedence when names collide: environment > repository > organization.
Environment protections gate a job; branch protections/rulesets gate a ref. Both may be required: branch rules stop bad code from merging; environment rules stop any run — even from main — from reaching production without a human.
Diagram: how a deployment job passes through environment gates before secrets are exposed.
Common traps
- Assuming environment secrets are available in a job that lacks
environment:— they are not. - Confusing required reviewers (environment, gates a run) with required pull request reviewers (branch ruleset, gates a merge).
- Believing all 6 reviewers must approve — only one is needed.
- Thinking a wait timer can be "approved early" — it cannot; it must elapse.
- Forgetting that a pending-approval job blocks dependent jobs and consumes no minutes while waiting.
- Choosing "protect the branch" when the requirement says "no deployment to production without sign-off from the SRE team" — that is an environment with required reviewers.
Worked scenario. Requirement: releases may only deploy from tags matching v*, must be approved by two-person rule, and the cloud credentials must be unreachable before approval. Correct design: an environment production with deployment tag rule v*, required reviewers (add a team; enable prevent self-review to guarantee a second human), and store the credentials as environment secrets (or better, use OIDC with a subject constrained to environment:production). Branch protection alone fails the "credentials unreachable" clause.
Identifying trustworthy actions from the Marketplace
Every action you reference executes arbitrary code in your runner with access to your GITHUB_TOKEN, the workspace, and any secret you pass it. Trust evaluation is therefore a required skill.
| Trust signal | What it actually guarantees |
|---|---|
GitHub-authored (actions/*, github/*) | Maintained by GitHub; highest default trust |
| Verified creator badge (blue check) | GitHub verified the publisher's domain/identity — not a code audit |
| Star count / usage | Popularity, not security |
| Pinned to a commit SHA | Immutability of the code you run |
| Published as an immutable action (released as a package with provenance attestation) | Tag cannot be moved; artifact provenance verifiable |
Source repo review: release cadence, open CVEs, action.yml inputs, transitive deps | Actual code risk |
| Action type | Docker container actions may pull images from external registries; JavaScript actions ship bundled dist/; composite actions call other actions |
Practical review checklist the exam echoes: read action.yml and the bundled dist/, check whether the action curls a script at runtime, check whether it needs write permissions or secrets, prefer forking and vendoring internally for critical/unverified actions, and enable Dependabot version updates for the github-actions ecosystem so pins are refreshed with review.
Common traps
- Treating "verified creator" as "security reviewed" — it is identity verification only.
- Assuming Marketplace listings are scanned/sandboxed by GitHub — they are not.
- Believing a high star count or "used by 50k repos" is a compliance control.
- Forgetting that an action pinned to a SHA can still fetch untrusted content at runtime (SHA pinning fixes the action code, not its network behavior).
Unlock with a paid plan
11 more sections (about 3,501 words) continue below. Every paid plan unlocks all GH-200 study guides, the full question bank and mock exams, from $4.97/month.