Task 1.2: Validate and operate AI tools

• ACopilot's own review comment is counted first and blocks other approvals on the same pull request

  Incorrect

  Copilot's reviews do not block human approvals; the issue is whose approval it is.

• BAn approval from whoever started the agent's task does not count toward required approvals

  Correct

  To preserve the required-approvals control, the person who started the task cannot be the approver; another reviewer must approve.

• CApprovals on draft pull requests are ignored until Copilot marks the pull request ready for review

  Incorrect

  Copilot cannot mark its own pull requests ready for review, and that is not why the approval is discounted.

• DCloud agent pull requests can only be approved by a repository administrator

  Incorrect

  Any other eligible reviewer can approve; the restriction is on the requester.

Copilot cloud agent prevents the user who asked it to create a pull request from approving that pull request, which keeps the "Required approvals" rule and branch protection meaningful. If approvals are required, someone other than the requester must approve before the pull request can be merged.

• ARe-run the latest workflow from the Actions tab so that it picks up Copilot's newest commits

  Incorrect

  Workflows on Copilot's pull request are held for approval; the safe step is reviewing what will run first.

• BMention @copilot and ask it to trigger the workflows with its own token

  Incorrect

  The agent cannot approve its own workflow runs; a person with write access does.

• CInspect the changes first, especially .github/workflows/, because workflows can reach secrets

  Correct

  Workflows can be privileged and access secrets, so the documentation asks reviewers to inspect the changes, watching .github/workflows/ closely, before approving.

• DConvert the pull request from draft so that required checks are triggered automatically

  Incorrect

  Changing the draft state does not lift the approval gate for workflow runs.

By default, GitHub Actions workflows do not run automatically when Copilot pushes changes to a pull request. Because workflows can be privileged and have access to sensitive secrets, reviewers should inspect the changes, paying special attention to files in .github/workflows/, and then click "Approve and run workflows" in the merge box.

• AOnly that exact command with that exact path, without asking again

  Incorrect

  The session approval is for the tool, not the single command line.

• BAny rm command, with any arguments, until the session ends

  Correct

  The documentation's own example: approving rm for the session lets Copilot run any rm command, such as rm -rf ./*, without asking.

• CAny rm command in this and all future sessions started from this folder

  Incorrect

  Session approval does not carry over to new or resumed sessions; trusted folders are a separate setting.

• Drm on files that Copilot created itself, but not on files that already existed

  Incorrect

  No such distinction is made; the approval covers the tool in any way Copilot sees fit.

Copilot CLI's second approval option, "Yes, and approve TOOL for the rest of the running session", allows Copilot to use the tool in any way it thinks appropriate for the current session. Approving rm ./this-file.txt this way means Copilot could run rm -rf ./* without asking. The approval is asked for again in new sessions or when the session is resumed.

• ACopilot code review is certified to find every defect that a static analyzer would find

  Incorrect

  No such certification exists; the guidance says Copilot may not find all problems.

• BCopilot code review only comments when it is certain, so its comments can be applied without checking

  Incorrect

  The guidance warns of false positives that must be considered before acting.

• CIt may miss problems and flag issues that do not exist, so it should supplement human review

  Correct

  The agents application card lists missed problems and false positives, and says to use code review to supplement human reviews, not replace them.

• DCopilot code review replaces human review only for repositories that have custom instructions

  Incorrect

  Custom instructions improve relevance, but they do not change the advice to keep human review.

The application card for Copilot's agentic features lists missed code quality problems, especially in large or complex changes, and false positives, where it flags problems that do not exist. Its best practice is to use Copilot code review to supplement human reviews, not to replace them, and to validate its feedback carefully.

• ASuggestions are applied automatically but can be undone within 30 seconds

  Incorrect

  Suggestions are not applied automatically at all.

• BEvery suggestion is reviewed by Copilot code review before it is shown

  Incorrect

  Code review reviews pull requests; it does not gate inline suggestions.

• CSuggestions look distinct and apply only when explicitly accepted

  Correct

  Inline suggestions follow human-in-the-loop principles: they are visually distinct and only applied when the user explicitly accepts them.

• DSuggestions are only shown after the file is saved

  Incorrect

  Suggestions appear as you type, not after saving.

Copilot inline suggestions follow human-in-the-loop principles. Suggestions are visually distinct from the surrounding content and are only applied when the user explicitly accepts them, so no code changes occur without deliberate user action. Users are still encouraged to review, test and validate what they accept.

• AClose the pull request and assign the issue to Copilot again

  Incorrect

  That starts over instead of continuing on the existing pull request.

• BApprove the pull request with a review comment describing the change

  Incorrect

  An approval doesn't ask Copilot to change anything.

• CAdd the change to the repository's custom instructions so that Copilot's next run picks it up

  Incorrect

  Custom instructions are standing guidance; a change on this pull request is requested by mentioning @copilot in a comment.

• DMention @copilot in a pull request comment that describes it

  Correct

  To request changes from Copilot on its pull request, mention @copilot in a comment, or push commits to the branch yourself.

Copilot pull requests deserve the same review as any contribution. To request changes from Copilot on its pull request, mention @copilot in a comment describing what you want, or push commits directly to the branch yourself. Copilot then iterates on the same pull request.

• AIt is recommended, because the CLI needs access to the home directory's configuration files

  Incorrect

  Configuration lives in ~/.copilot, but that is not a reason to trust the whole home directory.

• BAvoid it: launch only from directories you trust, and typically not from your home directory

  Correct

  Copilot may read, modify and execute the files it trusts, so the guidance is to launch it only from trusted directories and typically not from your home directory.

• CIt is harmless, because the CLI only reads files that are tracked by Git

  Incorrect

  Copilot can read, modify and execute the files it is trusted with, not only the ones tracked by Git.

• DIt is blocked, because the CLI refuses to start outside a Git repository

  Incorrect

  The CLI can start outside a repository; the guidance is about where to launch it.

When you start Copilot CLI, you confirm that you trust the files of the launch directory, because Copilot may read, modify and execute them. Launch it only from directories you trust; you should not use it in directories with executables you can't be sure of, or with sensitive data, and typically you should not launch it from your home directory.

• ANothing; such comments are never presented to the agent

  Correct

  Comments on the agent's pull request from users without write access are never presented to it.

• BCopilot asks a maintainer to approve the request before acting on it

  Incorrect

  Comments from users without write access are not presented to the agent at all.

• CCopilot acts on it, but the change waits as a draft pull request

  Incorrect

  The comment never reaches the agent, so no change is made.

• DCopilot acts on it only if the repository has custom instructions

  Incorrect

  Custom instructions do not change who can trigger the agent.

Comments from users without write access to the repository are never presented to Copilot cloud agent, so an outside user can't direct it from a pull request. The agent also pushes only to its own branch, and its pull requests need human review before merging.