An agent is failing your team's code governance policy because it is committing changes directly to the 'main' branch instead of creating a feature branch. Branch protection rules are enabled on 'main,' causing the direct pushes to be rejected with a 403 error. The agent has no branch-based scope configured. What is the correct configuration change?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Branch-based scope is how you tell an agent 'you work on feature branches, not main.' Without it, the agent picks the simplest path — pushing straight to main — which breaks your protection rules. The fix is to configure a branch scope pattern like 'agent/*' so the agent always creates a new branch, stages its changes there, and then opens a PR. This enforces the full human-review flow and keeps main clean. Never bypass protection rules for an autonomous agent — that's the opposite of the safety boundary branch protection is there to provide.
Full explanation below image
Full Explanation
Branch protection rules on 'main' (or 'master') are a foundational governance control that prevents direct pushes and requires changes to arrive via reviewed pull requests. When an agent lacks branch-based scope configuration, it defaults to whatever the most straightforward write path is — often the current default branch. This causes 403 errors when branch protection blocks the push and leaves the agent with no fallback strategy.
The correct fix is to configure a branch-based scope in the agent's settings that: 1. Defines a branch naming pattern for agent-created branches (e.g., 'agent/fix-{timestamp}' or 'agent/{task-id}'). 2. Instructs the agent to always create a new branch matching that pattern before making any file changes. 3. Opens a pull request from that branch to the target branch (main) after completing its changes.
This configuration ensures agents always participate in the normal code review workflow rather than attempting to bypass it.
Why the other options are wrong:
Option A — Disabling branch protection rules is a severe governance regression. These rules exist to ensure code quality, require reviews, and prevent accidental or malicious direct pushes. Removing them to accommodate an agent defeats the purpose of the protection and exposes the entire repository to unreviewed changes from any actor.
Option C — Granting 'bypass branch protection' to an autonomous agent is one of the most dangerous permissions in a GitHub repository. It allows the agent to push any change directly to any protected branch without review. This violates least privilege and removes the safety net that branch protection provides. On the GH-600 exam, this is an anti-pattern to recognize, not a recommended approach.
Option D — Pre-commit hooks run on the developer's local machine (or the CI runner that's pushing), not as a server-side redirect mechanism. GitHub does not support pre-receive hooks on the server side in the same way that some self-hosted Git servers do. Even if a hook could redirect a push, doing so silently without the agent's awareness creates unexpected behavior and doesn't configure the agent correctly for future runs.