3.1.2. Access Control and Use Policies
💡 First Principle: Actions policy answers three separable questions — may this repository run Actions at all, which actions may it use, and what may the resulting token do — and each is a different setting, layered from enterprise down to repository.
The action-source policy is a ladder, and the exam wants the rungs in order:
| Policy setting | What it permits | Typical use |
|---|---|---|
| Allow all actions and reusable workflows | Anything, including arbitrary Marketplace code | Open-source orgs, low-risk repos |
| Allow enterprise/org actions only ("local only") | Only actions defined inside the enterprise or organization | Highest-lockdown regulated environments |
| Allow actions created by GitHub | The actions/* first-party set | Baseline tier, combined with others |
| Allow Marketplace actions by verified creators | Publishers GitHub has verified | Adds vetted third parties |
| Allow specified actions (allowlist) | Patterns like owner/repo@*, owner/* | The practical enterprise middle ground |
The allowlist is pattern-based, and its syntax is testable: monalisa/octocat@* permits all versions of one action, monalisa/octocat@v2 pins a version, and monalisa/* permits everything from one owner. Wildcards may not span the owner/repo boundary in a way that would grant "all of GitHub."
Layering runs outside-in. An enterprise policy sets the ceiling; an organization can be more restrictive but never more permissive; a repository can restrict further still. When a scenario reports "we allowed this action at the repository level but it's still blocked," the answer is essentially always an enterprise or organization policy above it.
Alongside source policy sit two settings that show up constantly. Workflow permissions set the default GITHUB_TOKEN scope for the org or repository — read-only by default in newer configurations — plus a checkbox controlling whether workflows may approve pull requests. And fork pull request policies govern whether workflows run at all on fork PRs, whether they require approval from a maintainer first (the default for first-time contributors), and whether they may access secrets — the enterprise-level counterpart to the pull_request_target danger from 2.1.
⚠️ Exam Trap: Policies restrict uses: resolution, not what a workflow can do generally. An allowlist does not stop a run: step from curl-ing and executing a script — that's what runner hardening, network controls, and code review are for. Answers implying the allowlist alone prevents arbitrary code execution are wrong.
Reflection Question: An organization sets "Allow specified actions" with an allowlist of forty entries and considers itself locked down. Name the execution path that policy doesn't touch, and which control from Phase 6 actually addresses it.
