GH-600 Practice Test

Sample GH-600 Practice Questions

10 real questions from the free GH-600bank. Pick an answer in your head, then open “Show answer” for the explanation.

1. 1. A team wants to reduce Copilot cloud agent's exposure to secrets it does not need for a given task. Where does the documented guidance say sensitive data an agent should NOT access should be stored?

   • A. In the pull request description, so the agent can read the secrets directly
   • B. As GitHub Actions variables or secrets outside the agent-accessible scope, reserving agent secrets for data the agent actually needs
   • C. In an environment variable named after the agent, purely for convenience
   • D. In the repository README file, so the agent discovers the secrets automatically
   Show answer

   Correct answer: B

   The guidance recommends storing sensitive data the agent should not need as GitHub Actions variables or secrets, while using dedicated agents secrets and variables at the organization or repository level only for data the agent does require. Putting secrets in a PR description, a conveniently-named environment variable, or a README would expose them to the agent rather than restrict access.

2. 2. A DevOps engineer has one sprint of capacity to address exactly one anti-pattern before an audit. The agent workflow's GITHUB_TOKEN currently has write access to every repository, though tasks only ever touch one. Separately, recent incidents trace to reviewers approving diffs with no stated rationale, since the PR template has no required plan section. Given that the over-broad token has not yet been implicated in an actual incident while the missing-plan gap already caused two production regressions, which control should the engineer prioritize first, and why does the alternative not address the immediate risk?

   • A. Require a PR-template plan section and review-before-merge first, since the demonstrated incidents trace to planless execution, not to the unused broad token scope
   • B. Scope the GITHUB_TOKEN to least privilege first, since credential exposure is inherently more dangerous than any process gap
   • C. Address both simultaneously by disabling the workflow entirely until the sprint ends
   • D. Neither control matters until the audit begins, since anti-pattern mitigation is assessed during formal audits
   Show answer

   Correct answer: A

   The evidence points to planless execution as the active, demonstrated risk - two regressions traced to unreviewed rationale-free diffs - so the PR-template plan requirement and review-before-merge gate address the proven failure mode first. The broad token scope is a latent over-permissioned-agents risk worth fixing later, but scoping it first would leave the already-demonstrated planless-execution gap unaddressed; disabling the workflow ignores the one-control constraint and stops delivery entirely, and waiting for the audit ignores that regressions are already occurring now.

3. 3. A team wants agent execution to remain bounded to repository workflows even under a tight deadline, but also wants to avoid adding process overhead for a genuinely low-risk documentation-only change. They are considering letting the agent push documentation fixes directly to the default branch to save review time, while keeping the branch-and-PR requirement for code changes. Does this satisfy the documented plan/act separation model?

   • A. Yes, since documentation edits carry no meaningful execution risk and the documented model explicitly exempts them from the branch-and-PR requirement entirely
   • B. No - action stays bounded to a branch and pull request workflow, not direct default-branch changes; a lighter review process cuts overhead without dropping that boundary
   • C. Yes, as long as the agent first states its plan verbally to a teammate in a quick conversation before pushing any of the changes to the branch
   • D. No, but because default-branch pushes happen to already be technically blocked by GitHub platform rules, regardless of what type of change is involved
   Show answer

   Correct answer: B

   The documented model bounds the act phase to a branch and pull request workflow specifically to keep execution controlled and reviewable, and this boundary is not conditioned on perceived risk level - a faster, lighter review process addresses the overhead concern without removing the branch/PR boundary itself. There is no documented risk-based exemption for documentation-only changes, a verbal plan does not substitute for an inspectable PR-based plan, and the correct reasoning is about the documented model's scope, not merely a platform-level technical restriction.

4. 4. A team defines success criteria for an agent-driven dependency-remediation task as "the CVE advisory is marked resolved AND no new high-severity secret-scanning alerts are introduced." The agent's change resolves the CVE but its lockfile update also triggers one new high-severity secret-scanning alert from an unrelated transitive dependency. Given both conditions were explicitly required, and the team has a policy against merging any change with an open high-severity secret alert, what should happen to this pull request?

   • A. Merge it immediately, since the primary goal of resolving the CVE was achieved
   • B. Merge it and file the new secret-scanning alert as a separate future task
   • C. Do not merge yet; the compound criterion was not fully met, so someone must resolve the new alert first
   • D. Redefine the success criteria retroactively to drop the secret-scanning condition
   Show answer

   Correct answer: C

   The success criterion was explicitly compound - CVE resolution AND no new high-severity alerts - so partially satisfying it does not meet the bar the team itself defined, and the existing policy against merging with an open high-severity alert reinforces holding the merge. Merging immediately ignores the second explicit condition, filing the alert as unrelated future work still leaves the current change in violation of its own stated criteria, and retroactively redefining criteria to force a pass defeats the purpose of setting success criteria before execution.

5. 5. By default, can GitHub Copilot cloud agent mark its own draft pull request as "Ready for review" or merge it?

   • A. Yes, for both marking ready and merging
   • B. No - draft pull requests it creates must be reviewed and merged by a human
   • C. Yes, for marking ready but not for merging
   • D. Yes, if the repository has fewer than 10 contributors
   Show answer

   Correct answer: B

   Documentation states draft pull requests created by Copilot cloud agent must be reviewed and merged by a human, and the agent cannot mark its pull requests as "Ready for review" or approve or merge them. There is no repository-size exception to this control.