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 and Infographic
The GITHUB_TOKEN is like a scoped badge that only unlocks the doors you explicitly list — by default it can read things but can't write pull requests. The fix is to declare the permissions the workflow needs right in the YAML file using the 'permissions' block. This is the recommended least-privilege approach and the exam almost always prefers token-scope fixes over switching token types entirely. Option C is a necessary organization-level setting, but without the workflow permissions block, the token still can't create PRs.
Full explanation below image
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:
Option A — Using a PAT with full 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.
Option C — 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.
Option D — Installing a GitHub App and using its installation token 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.