A team wants to run a code-generation agent only when changes are made to branches that follow the naming pattern feature/*. They want the agent to be completely inactive on main, develop, and any other branches. Which configuration achieves this branch-based scope?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Workflow triggers in GitHub Actions use glob patterns to filter by branch name, and that's the right place to enforce this. Setting branches: ['feature/*'] in the trigger means GitHub won't even start the workflow — let alone the agent — for pushes to main, develop, or anything else that doesn't match. The double-exit guard in option A is redundant when the trigger itself does the filtering correctly.
Full explanation below image
![A 2048x1536 landscape infographic titled 'Branch-Based Agent Scope with GitHub Actions'. Left shows a branching tree: main (red X — no trigger), develop (red X — no trigger), feature/login (green checkmark — trigger fires), feature/payment (green checkmark — trigger fires), hotfix/bug (red X — no trigger). Center shows the YAML trigger: 'on: push: branches: [feature/]' with the glob pattern highlighted. Right shows the evaluation flow: Push Event → GitHub Evaluates Branch Filter → Does branch match feature/? → Yes: Workflow Starts → Agent Runs. No: Workflow Skipped. Bottom: 'Trigger-level filtering = no workflow overhead for excluded branches'. GitHub blue/green color scheme, branch diagram style.](/media/github/gh-600/GH-600-e2-q017-infographic.webp)
Full Explanation
Branch-based scoping for agents is primarily controlled through GitHub Actions workflow triggers. GitHub evaluates the trigger conditions before any workflow steps run, meaning a correctly configured trigger is the most efficient and reliable gating mechanism.
Option A is incorrect — not because it would fail, but because it is over-engineered and reflects a misunderstanding of how workflow triggers work. If on: push: branches: ['feature/*'] is already configured, the workflow will not start for pushes to non-matching branches. Adding an early-exit guard in the agent step is redundant. The answer describes two layers of enforcement where one is sufficient. For exam purposes, the minimal correct configuration is the trigger alone.
Option B is correct. GitHub Actions branch filters using glob patterns (feature/* matches feature/my-new-ui, feature/bug-fix-123, etc.) are evaluated server-side before the workflow is queued. Pushes to main, develop, hotfix/xyz, or any other non-matching branch do not trigger the workflow at all. Since the agent runs as a step within this workflow, it inherits the same scope restriction automatically. This is clean, declarative, and requires no agent-level logic.
Option C is incorrect. There is no branch_filter key in the Copilot agent definition file specification. Agent definition files configure tools, models, and prompts — not workflow trigger conditions. Trigger conditions belong in the GitHub Actions workflow YAML.
Option D is incorrect. Branch protection rules govern what can be merged into a protected branch (required reviews, status checks, etc.) and who can push to it. They do not block or allow agent invocations, and they do not provide a mechanism to scope agent execution by branch name.
Key exam point: branch-based scope is configured in the GitHub Actions workflow trigger (on: push: branches), not in the agent definition file or branch protection rules.