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.
![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.webp)
Short Explanation
GitHub Actions filters branches in the workflow trigger, so branches: ['feature/*'] stops the workflow before the agent runs. You don't need extra agent logic to keep it off main, develop, or other branches.
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.
The configuration that sets on: push: branches: ['feature/'] in the workflow trigger and also configures the agent step to exit early if github.ref does not match the pattern is incorrect. It is not wrong because it would fail; 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. That configuration describes two layers of enforcement where one is sufficient. For exam purposes, the minimal correct configuration is the trigger alone.
The correct configuration is to use on: push: branches: ['feature/'] in the workflow trigger and rely on that alone. GitHub Actions branch filters using glob patterns (feature/ matches feature/my-new-ui, feature/bug-fix-123, and similar names) 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.
The configuration that adds a branch_filter: feature/* key directly to the agent definition file and says the Copilot runtime checks it before invoking the agent 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.
The configuration that creates a branch protection rule on main and develop to block agent invocations, while leaving the agent unrestricted on all other branches by default, is incorrect. Branch protection rules govern what can be merged into a protected branch (required reviews, status checks, and similar controls) 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.