A team reports that their CI-triggered agent successfully analyzes code and proposes fixes, but always fails at the step where it should open a pull request — the run log shows 'Resource not accessible by integration.' The agent uses the default GITHUB_TOKEN. What is the most likely fix?
Select an answer to reveal the explanation.
Short Explanation
The default GITHUB_TOKEN is like a scoped badge that only unlocks the doors you explicitly list, so it can read things but can't write pull requests unless you grant it. Declare 'pull-requests: write' and 'contents: write' in the workflow's permissions block so it can push branches and open PRs. That's the least-privilege fix, and it's what the exam wants.
Full Explanation
The error 'Resource not accessible by integration' from the GitHub API means the GITHUB_TOKEN does not have the required permission scope for the requested operation. By default, the GITHUB_TOKEN in a GitHub Actions workflow has a restrictive default scope — in many repository and organization configurations, pull-request write access is not granted automatically.
The correct fix for an agent that needs to autonomously create branches and open pull requests in a CI workflow is to explicitly declare those permissions in the workflow YAML using the top-level or job-level 'permissions' block:
permissions: contents: write # needed to push a new branch pull-requests: write # needed to open the PR
This is the idiomatic GitHub Actions approach and aligns with the least-privilege principle: you grant exactly what the workflow needs, scoped to that specific run.
Why the other options are wrong:
Replacing the default GITHUB_TOKEN with a personal access token that has full repository admin rights is an anti-pattern. It violates least privilege, is harder to rotate, and leaks a human's credentials into a machine workflow. The exam consistently steers candidates away from PATs when GITHUB_TOKEN with proper scopes is sufficient.
Enabling the 'Allow GitHub Actions to create and approve pull requests' setting in repository Settings > Actions is indeed required for PR creation by Actions, but it is a prerequisite — not the complete fix. Even with that setting enabled, if the workflow's GITHUB_TOKEN permission block does not include 'pull-requests: write', the API call will still fail. The scenario states the token is the issue, making the permissions block the primary fix.
Switching from GITHUB_TOKEN to a GitHub App installation token with the 'pull_requests' scope configured in the App's permissions is a valid advanced pattern for agents that need elevated or cross-repository access, but it is significantly more complex to set up than adding two lines to a permissions block. For a single-repository agent using GITHUB_TOKEN, the permissions block is the correct and simpler solution. GitHub App tokens become the right answer when the agent needs to span multiple repositories or organizations.