GitHub Agentic AI Developer (GH-600) Exam Questions

Domain 1: Prepare agent architecture and SDLC processes (15–20%)

A payments team asks an agent to fix retry handling for temporary gateway failures. The task describes the expected retries and names services/payments/retry.ts and tests/payments/retry.test.ts as the relevant files. The fix must keep the existing API behavior and be reviewed before it reaches main. Which two requirements should the team add to define the agent’s scope and delivery process? (select two)

⬜ Limit edits to the two named files, keep the public API unchanged, and ask for approval if more changes are needed.
⬜ Deliver a pull request with the implementation and test results, reviewed before it’s merged.
⬜ Treat passing existing tests as proof of API compatibility, allowing interface changes as long as they pass.
⬜ Treat an approved implementation plan as completion, and collect test evidence in the next scheduled release.
⬜ Let the agent commit directly to main once tests pass, with the team reviewing the commit afterward.

A team asks an agent to add a dependency review check to a public repository, so pull requests that introduce known vulnerable packages can be blocked. The agent saves a plan to inspect workflow permissions, add the check, validate the workflow and open a pull request, but hasn’t changed any files yet. What still has to happen before the team can accept the change as implemented?

⬜ The agent must implement the workflow change and open a pull request with validation evidence for the team to review.
⬜ The team must approve the saved plan and treat its validation steps as proof the check works.
⬜ The agent must open a pull request containing only the plan, and leave the implementation for the next dependency update.
⬜ The team must run the existing workflow successfully and use that run to approve the planned change.

A team’s internal coding agent fixes payment failures, but recent runs changed both payment code and infrastructure and then committed straight to main before anyone reviewed the diff. The team wants to keep the agent while stopping unrelated edits and unreviewed changes from reaching main. Which combination fixes both problems?

⬜ Define the allowed files and expected behavior for each task, and require delivery through a pull request with required checks and review.
⬜ Require pull requests with checks and review, but let the agent decide whether a payment fix also needs infrastructure changes.
⬜ Define the allowed files and expected behavior, but allow direct commits to main after the agent reports passing tests.
⬜ Ask the agent to keep changes focused and request review, while keeping its ability to push to main when tests pass.

A team uses a Copilot cloud custom agent to inspect services/catalog/ and propose a refactoring plan. Its profile enables read, search and execute, but not edit; a separate coder profile does the implementation. Planning must inspect files without changing them. Which two changes establish the planning boundary? (select two)

⬜ Remove execute from the planner, because shell commands can also change files.
⬜ Require an approved plan before the workflow hands implementation to the coder.
⬜ Keep execute, because excluding edit already prevents file changes.
⬜ Give the planner edit so it can validate the plan by applying it.
⬜ Run the coder during planning and use its diff as the approval request.

Which plan outline gives a reviewer the scope, order, limits and acceptance evidence needed to assess an agent’s plan for work with dependent tasks?

⬜ Goal and affected paths; tasks in dependency order; constraints; validation criteria
⬜ Goal and affected paths; tasks in dependency order; constraints; time estimates
⬜ Goal and affected paths; an unordered task list; constraints; validation criteria
⬜ Goal and affected paths; tasks in dependency order; design preferences; validation criteria

An agent proposes simplifying an inventory API. Existing clients must keep working without code changes, but the plan removes a public parameter those clients use and updates the tests to call the replacement interface. What should the reviewer require before approving the implementation?

⬜ Revise the approach to keep the existing interface, and validate calls from unchanged clients.
⬜ Revise the approach to migrate the clients to the replacement interface before release.
⬜ Keep the endpoint URL and validate the replacement parameter with the updated tests.
⬜ Document the parameter removal and add a rollback procedure for affected clients.

In a GitHub Actions workflow, the validate_plan job fails when an agent plan is rejected. Which configuration of the implementation job makes it run only if validate_plan succeeds?

⬜ needs: validate_plan, with no job-level if condition that overrides the success requirement
⬜ needs: validate_plan, with a job-level if: always()
⬜ needs: implement, set on validate_plan instead of on the implementation job
⬜ concurrency: plan-review on the implementation job, instead of a dependency

A Copilot CLI session may use an editing tool, but team policy forbids changes to release configuration in the current task. The team adds a command hook that evaluates each proposed call and rejects violations before the tool runs. Assuming the hook runs successfully, which two elements implement this control? (select two)

⬜ Use preToolUse to inspect the requested toolName and toolArgs before the edit runs.
⬜ For a forbidden request, return permissionDecision set to deny, with a permissionDecisionReason.
⬜ Use postToolUse to inspect the completed edit and prevent the same call from running.
⬜ Return an empty JSON object for a forbidden request after logging the violation.
⬜ Require pull request approval and use it to block the local editing call.

An agent’s test workflow writes a detailed report to reports/checkout-results.json on a GitHub-hosted runner, but only prints a pass count to the log and doesn’t upload the file. Reviewers need the full report from future runs after the runner is gone. Which change provides that evidence through GitHub?

⬜ Upload the report as a workflow artifact, and link the run and the artifact in the pull request.
⬜ Cache the reports folder with the dependency cache key, and link the cache configuration in the pull request.
⬜ Link the pass-count log line in the pull request as the complete report.
⬜ Record the runner’s local report path in the pull request and leave the file there.

A public repository analyzes a proposed release automatically, then runs a deployment job that uses the production environment. The environment has a 20-minute wait timer but no required reviewers, so deployment goes ahead when the timer ends. A release owner must assess the analysis before production changes, while analysis stays automatic. What provides that checkpoint?

⬜ Add required reviewers to production, so the deployment job waits for explicit approval.
⬜ Increase the wait timer so the release owner has longer to look.
⬜ Restrict production to the release branch so successful runs from it can proceed.
⬜ Require someone to start the workflow manually before analysis, and keep the timed release.

A security advisory affects one of a team’s dependencies. The task given to an agent names package-lock.json, but the agent’s plan also updates package.json. The team wants a focused fix, and repository policy requires passing tests and code-owner approval before merge. Which two actions resolve the scope mismatch and define how the fix will be accepted? (select two)

⬜ Confirm whether both files are needed, then update the task to authorize the necessary dependency changes and exclude unrelated edits.
⬜ Require a pull request with test results and evidence that the affected dependency was remediated, followed by the required code-owner approval.
⬜ Treat both files as authorized because dependency updates commonly touch them, and document the wider scope after implementation.
⬜ Accept a successful package installation as completion, and leave the application tests for the next scheduled build.
⬜ Treat the code owner’s approval of the plan as approval of the resulting pull request once the agent reports success.

Customers see unclear error messages at checkout, so a team asks an agent to “improve checkout.” The agent edits packages/checkout/handler.ts and .github/workflows/release.yml, then reports completion without test results or a pull request. The team never defined the expected error messages, and release workflow changes weren’t authorized. How should the team turn this into a focused, verifiable checkout fix?

⬜ Agree on the expected checkout behavior and allowed files, remove the unauthorized workflow edit, then validate the remaining changes in a pull request.
⬜ Keep the current diff, derive the acceptance criteria from its behavior, and submit it for review after running the existing tests.
⬜ Remove the workflow edit and open a pull request with the checkout changes, using the agent’s completion report as the validation record.
⬜ Run tests on both changed files and submit the whole diff, treating passing results as justification for the workflow change.

A team asks a Copilot custom agent to fix a failing test and run the test suite. The agent was built to review pull requests, and its profile has this frontmatter:

description: Reviews code changes
tools: read, search

The team needs the test fix done while keeping this review profile unable to edit files or run commands. How should the implementation work be assigned? ⬜ Use a separate implementation profile with read, search, edit and execute, and submit its tested changes through a pull request.
⬜ Keep the tool list and expand the description to include fixing tests and running the suite before reporting.
⬜ Add edit and execute to the review profile, and tell the agent to use them only when a task asks for implementation.
⬜ Create a separate implementation profile with read, search and edit, and ask it to run the test suite after the fix.

A team adapts the documented Copilot implementation-planner example, which enables read, search and edit so it can create plan files. In this workflow the planner must inspect the repository and return a structured plan without changing any file in the working tree; an approved follow-up step will save the result. Which two changes meet that requirement? (select two)

⬜ Limit the planner’s tools to read and search.
⬜ Have the planner return the plan in its response for the follow-up step to save.
⬜ Keep edit enabled and describe the planner as a documentation-only agent.
⬜ Set tools to an empty list while still requiring the planner to inspect repository files.
⬜ Keep edit enabled and ask the planner to save the plan under docs/plans/.

In an agent’s structured implementation plan, task A creates a shared validator and task B updates a handler to use it. Which dependency lets the executor use the validator only after it exists?

⬜ Task A must complete before task B can start.
⬜ Task B must complete before task A can start.
⬜ Each task depends on the other, and the executor starts with whichever is available.
⬜ Both tasks share the same prerequisite, and either can run first.

An intermittent checkout error happens when a payment-status lookup times out but succeeds on the next attempt. The task requires the recovery to return the successful status to checkout. An agent plans the recovery code, but its proposed tests cover only immediate success. Which additional planned test directly verifies the requested recovery?

⬜ Simulate a timeout followed by a successful lookup, and assert that checkout receives the recovered status.
⬜ Simulate an immediate successful lookup, and assert that checkout receives the expected status.
⬜ Simulate a timeout followed by success, and assert the call count without checking what checkout receives.
⬜ Simulate timeouts on every attempt, and assert that checkout eventually gets an error.

In an agent workflow, how do a required pull request check on generated code and a successful plan-validation prerequisite on the implementation job control different stages?

⬜ The required check controls whether the change can merge; the prerequisite controls whether implementation can start.
⬜ The required check controls whether implementation can start; the prerequisite controls whether the change can merge.
⬜ Both stop implementation from starting, because each can report a failed validation.
⬜ Both control merge eligibility, because job dependencies are evaluated after code generation.

In a public repository, a GitHub Actions job runs an internal coding agent with the job’s GITHUB_TOKEN. The agent must update application code on an existing working branch, and a maintainer will open the pull request. The team wants minimum token access and independent validation before changes reach main. Which two controls should the team configure? (select two)

⬜ Grant contents: write to the agent job, leaving other GITHUB_TOKEN permissions unspecified so they get no access.
⬜ Require the validation status checks in the ruleset for main, with no bypass for the automation.
⬜ Grant checks: write instead of contents: write so the agent can update its branch and report results.
⬜ Grant permissions: write-all and let repository rulesets limit the token to what it needs.
⬜ Grant contents: read and pull-requests: write so the agent can push code without broader access.

An agent opens a pull request that updates a parser and its migration guide. The description links to the approved plan, but the Evidence section only says “checks passed” and the ownership areas are blank. Reviewers need to connect the planned changes with their verification and with who is responsible for the affected files. What should the agent add to the pull request?

⬜ Links to the relevant workflow runs and reports for the planned changes, plus the affected paths and their code owners.
⬜ A list of commits and changed files, using the complete diff as evidence that validation succeeded.
⬜ Nothing for evidence or ownership; remove those sections and rely on automatic CODEOWNERS review requests.
⬜ The planned validation commands, copied into the Evidence section as the verification record.

A public repository uses one GitHub Actions job to build an agent-generated update, validate it in staging and deploy it to production. The job references a production environment with a required reviewer, so even the build waits for approval. The team wants build and staging results ready for the reviewer, while still requiring approval before production deployment. How should the workflow change?

⬜ Move build and staging validation into a preparation job, and make a separate protected production job depend on its success.
⬜ Keep the combined protected job, and move the build and staging steps before the deployment step.
⬜ Apply the protected production environment to a separate preparation job, and deploy in a dependent job without it.
⬜ Replace the required reviewer with a wait timer, and keep build, staging and deployment in one job.

A team asks an agent to add three retries with exponential backoff, so the application recovers from temporary service failures without changing its public API. Acceptance requires passing retry-behavior and API regression tests. The agent saves a plan and opens a draft pull request with code and test changes, but the tests haven’t run yet. What do these artifacts establish while validation is pending? (select two)

⬜ The plan records the intended retry behavior, but the implementation still has to be verified against it.
⬜ The draft pull request offers proposed changes for inspection, but the required passing test results are still missing.
⬜ The plan and proposed tests show the retry requirements are met, even though they haven’t run.
⬜ Because tests are pending, the run has produced a plan but no implementation yet.
⬜ The API constraint only matters when the agent chooses its approach, so acceptance can focus on retry behavior alone.

An API error message has changed, so a team asks a documentation agent to update the checkout guide and the error reference together. The pull request has the requested edits in docs/api/checkout.md and docs/api/errors.md, but no result for the link check the task requires. What validation should the team get before accepting the update?

⬜ Run the required link check on the proposed docs, fix any failures, and attach the passing result to the pull request.
⬜ Use a successful documentation build as the evidence, and leave the link check for the next scheduled docs review.
⬜ Attach the latest passing link-check result from the default branch, and use the diff to confirm the text changed.
⬜ Ask the agent to check the links in the edited lines, and accept its completion summary instead of the link-check result.

The release workflow at .github/workflows/release.yml deploys to every production server at once. A team wants an agent to change it to a staged rollout, so a faulty release hits fewer servers. Before any edits, the platform lead needs to assess the rollout steps, health checks and rollback approach. How should the team organize the agent’s work to give the lead that chance?

⬜ Have the agent produce a scoped plan for the platform lead to approve before editing, then implement through a pull request with checks.
⬜ Let the agent edit the workflow on a branch, and use the required platform review of the finished pull request as plan approval.
⬜ Let the agent edit the workflow, and use the production environment approval to validate the rollout plan when deployment is ready.
⬜ Let the agent edit once a required check confirms a plan file exists, then have the lead review the finished pull request.

A GitHub Actions workflow generates an agent’s plan in a job named plan. A separate approval job succeeds only when a reviewer accepts the plan and fails when they reject it. The execute job writes the implementation, but it starts while approval is still pending. The dependencies are shown below, and neither job has an if condition. Which two statements explain the problem and its fix? (select two)

approval:
  needs: plan
execute:
  needs: plan

⬜ The two jobs can run in parallel once plan succeeds, because execute doesn’t depend on approval.
⬜ Changing execute to needs: approval makes a successful approval a prerequisite, keeping the default handling of failed dependencies.
⬜ Moving approval above execute in the file makes approval finish before execute can run.
⬜ Adding needs: approval and if: always() to execute stops implementation when the plan is rejected.
⬜ Keeping needs: plan on execute makes it wait for approval, because both jobs share the same prerequisite.

How should a structured agent plan describe deliverables so the executor can verify completion separately for each implementation task?

⬜ Link each task to its expected output and the validation evidence that output needs.
⬜ Link each task to its required inputs, and treat having those inputs as the completion signal.
⬜ Link each task to its permitted tools, and treat successful tool calls as the completion signal.
⬜ Link each task to the approved overall goal, and treat plan approval as the completion signal.

A team approves an agent’s plan to replace an existing API response format, because the issue says no clients need it. Before implementation starts, the product owner updates the issue to require support for both the old and the new formats. The pull request description still contains the approved replacement plan. What should the agent do before implementing?

⬜ Revise the plan and its validation approach to cover both formats, then have the updated plan checked against the current issue.
⬜ Implement the approved replacement plan, then open a separate issue to bring back the old format later.
⬜ Keep the approved plan and change its acceptance criteria to match the originally proposed behavior.
⬜ Start from the existing plan and rely on its proposed tests to reveal any mismatch with the requirements.

A Copilot cloud agent profile describes a planning role, includes the instruction “Analyze the request without modifying files,” and leaves out the tools property. What does that mean for the agent’s tools?

⬜ All available tools stay enabled; the instruction describes expected behavior but doesn’t remove the editing tools.
⬜ All tools are disabled, because the planning instruction takes effect before any tool can be enabled.
⬜ Only read and search are available, because Copilot infers that restricted list from the planning role.
⬜ Editing tools are removed and others stay available, because the no-edit instruction acts as an exclusion rule.

A Copilot pull request links its plan, its commits and a log archive downloaded after a partial workflow rerun. In the original attempt, the required unit job passed and the integration job failed. Re-running failed jobs then passed integration without re-running unit. The author treats the downloaded archive as the complete validation record. Which two statements assess and complete the evidence correctly? (select two)

⬜ The downloaded archive only has logs for the re-run jobs, so it can leave out the original successful unit result.
⬜ Link the original attempt’s successful unit job log together with the rerun’s successful integration job log.
⬜ The downloaded archive combines the latest logs for every job, so it already shows both successes.
⬜ Use the agent session’s test plan to supply the unit result, and keep the rerun archive for integration.
⬜ Replace the rerun archive with the original full archive, and use that one attempt to verify both jobs.

A developer sees an active Copilot cloud agent session working from an outdated task scope. The agent is in the middle of a repository search, and the developer wants the session to use a revised scope for the rest of its work. Which intervention and timing does GitHub support?

⬜ Send a follow-up in the prompt box below the session log; Copilot applies it after the current tool call finishes.
⬜ Send a follow-up in the prompt box below the session log; Copilot cancels the current tool call immediately.
⬜ Stop the session and edit its prompt; the same GitHub Actions run resumes with the new scope.
⬜ Stop and archive the session; archiving restarts the run with an updated task description.

An agent workflow pauses for human approval before every source-file read and repository search. These operations are limited to approved project content and can’t change files or reach production. The workflow already requires an accountable release owner to review validation evidence before deployment, and the constant inspection prompts are delaying that evidence. Which policy change reduces interruptions but keeps the release decision?

⬜ Allow the bounded read and search operations automatically, and keep the separate approval for production deployment.
⬜ Use one approval of the first repository read to authorize every later operation, including deployment.
⬜ Keep approval for every read and search, and use a successful validation run in place of the release owner’s decision.
⬜ Auto-approve all tool categories for the session and ask the release owner to review the actions afterwards.

Customers contact support because they can’t tell whether checkout succeeded. A product owner wants a better confirmation screen and gives an agent a task titled “Improve checkout,” with no acceptance criteria. The repository has separate checkout and billing components, and production changes need approval. Which two additions define what the agent should change and how the improvement will be accepted? (select two)

⬜ Specify the expected confirmation-screen behavior, the checkout files the agent may change, and which billing changes are out of scope.
⬜ Define the pull request deliverable, checks for the customer-facing behavior, and the review and approval handoff before acceptance and release.
⬜ Authorize edits across checkout and billing, and let the agent set the task boundary after comparing options in both.
⬜ Use the existing unit suite as the definition of done, and let the agent decide the expected customer experience while coding.
⬜ Make passing automated checks the handoff to production, with the production reviewer inspecting the change after release.

A team asks an agent to fix the order total shown during checkout, limited to checkout code and its tests. The task explicitly excludes infra/prod.yml. The agent’s pull request has the requested fix and passing unit tests, but the diff also changes that production configuration file. How should the reviewer handle the excluded change before accepting the fix?

⬜ Ask for the production configuration change to be removed, then require checks on the corrected pull request before accepting it.
⬜ Run infrastructure validation as well as the unit tests, and accept the combined pull request if everything passes.
⬜ Ask the agent to explain how the production change supports checkout, and accept the combined pull request if the reason is convincing.
⬜ Move the production change into a separate commit in the same pull request, and accept after reviewing the checkout commit.

New contributors can’t follow outdated setup instructions, so a team asks an agent to fix docs/getting-started.md. The pull request passes the required link check and is approved by a maintainer who isn’t a code owner for that path. The repository requires code-owner approval for the changed docs, and no assigned code owner has approved. What satisfies the remaining review requirement?

⬜ Get approval from an assigned code owner for the changed docs before merging.
⬜ Accept the maintainer approval plus the passing link check as enough for a docs-only pull request.
⬜ Get a second approval from another maintainer who isn’t a code owner, so there are two independent reviews.
⬜ Fill in a pull request checklist recording the check and the maintainer approval, and use it to meet the requirement.

A team is defining planner, coder and security reviewer roles for an agent workflow on GitHub. It wants to approve the intent before implementation and assess the resulting work before acceptance. Which two responsibility and handoff rules support that separation? (select two)

⬜ The planner delivers a proposed scope and implementation plan, and the coder starts once that plan is approved.
⬜ The coder delivers proposed commits and validation evidence, so the security reviewer can assess them against the approved scope.
⬜ The planner commits the first version of the feature as supporting material while reviewers are still deciding on the plan.
⬜ The security reviewer treats approval of the plan as enough evidence that the resulting code meets security requirements.
⬜ The coder adjusts the agreed acceptance criteria to match what was built before handing over to the security reviewer.

In a plan-first agent workflow, what sequence should apply to a proposed plan that hasn’t yet been checked for permitted scope, technical feasibility or coverage of the acceptance criteria?

⬜ Check those things, fix gaps in the plan, get approval, then allow implementation.
⬜ Get approval, allow implementation, then check those things against the diff before merge.
⬜ Confirm the plan is visible, allow implementation, then get approval after the first validation run.
⬜ Approve the first plan, revise it during implementation, and check feasibility when a tool call fails.

A team authorizes an orchestrated agent workflow to update a service configuration through a pull request. The approved plan excludes changes to production records. Later the agent proposes deleting obsolete production records as an extra step, and the revised proposal passes automated checks. Team policy requires the service owner’s explicit approval for production data changes. What has to happen before the extra step can run?

⬜ The expanded plan and its production impact must go to the service owner for explicit approval of the added step.
⬜ The original approval must be linked to the added step, because both serve the same service update.
⬜ The passing checks must be recorded as approval, because they evaluated the revised proposal.
⬜ The production change must be logged for the service owner’s next review, because the configuration work is already approved.

Which planning output gives a reviewer something concrete to inspect about an agent’s intended implementation before any repository changes start?

⬜ A plan in the pull request description that lists the proposed changes and explains how they address the issue.
⬜ A comment confirming the agent understands the issue and is ready to start.
⬜ A link in the issue to a successful workflow run that validated the current default branch.
⬜ A statement that the agent has worked out the approach in its session and will explain it after implementation.

Copilot cloud agent works in a public repository where it can’t push to main or merge pull requests. The branch ruleset requires a pull request, but checks and approving reviews are optional. A trusted installed GitHub App posts acceptance-tests results. The team wants merging to require both a review of the latest changes and validation from that app. Which two ruleset changes enforce this? (select two)

⬜ Require approving reviews, including approval of the most recent reviewable push by someone other than the person who pushed it.
⬜ Require the acceptance-tests status check to pass, with the trusted GitHub App selected as the expected source.
⬜ Require signed commits, so verifying the newest commit also shows a reviewer accepted it.
⬜ Require all conversations to be resolved, so an earlier approval still counts after new pushes.
⬜ Require acceptance-tests with any source, so any matching success shows the trusted app validated the change.

An agent’s pull request has several revisions and an uploaded test report showing success. The report has no commit ID and no reference to the workflow run that produced it. Before using it to accept the submitted revision, what should the reviewer require?

⬜ The workflow run that generated it and the exact commit tested, confirming the result applies to the submitted revision.
⬜ The pull request number and branch name in the report title, treating the branch’s current contents as the tested revision.
⬜ Test totals that match the current test suite, using identical counts to show which revision was tested.
⬜ The latest successful run on main, using it to show the report also validates the proposed revision.

A push to a public repository’s release branch starts a workflow that validates agent-generated changes in staging. Production deployment uses a separate environment with a required reviewer, and its deployment credential exists only as a production environment secret. An engineer suggests using that credential for an extra staging check while production approval is pending. Which configuration keeps the credential boundary while staging stays automated?

⬜ Keep the credential in production, and run the check that needs it in the production job after approval.
⬜ Copy the credential to a repository secret for the staging job, and keep the production job’s required reviewer.
⬜ Copy the credential to the staging environment, and treat successful staging as authorization for production access.
⬜ Replace the production reviewer with a branch restriction, and let staging success authorize use of the credential.

Domain 2: Implement tool use and environment interaction (20–25%)

Which two tool aliases in a Copilot cloud agent custom profile support repository discovery - finding and reading relevant code? (select two)

⬜ Glob, to search for matching files or text in the repository
⬜ NotebookRead, to inspect the contents of a selected source file
⬜ Task, to keep the list of locations found during discovery
⬜ WebSearch, to replace repository search on GitHub.com
⬜ Bash, which limits discovery commands to operations that can’t change files

A Copilot cloud agent custom profile can inspect and update packages/cart/, but its task also requires running the existing test command. Its frontmatter has tools: ["read", "search", "edit"]. The team wants to add the missing capability, keep the other three and keep an explicit list. Which line should they use?

⬜ tools: ["read", "search", "edit", "execute"]
⬜ tools: ["read", "search", "edit", "agent"]
⬜ tools: ["read", "search", "execute"]
⬜ tools: ["read", "search", "edit", "web"]

In Copilot CLI, what happens when a startup --allow-tool rule permits an operation of a tool that was excluded from the available tool set?

⬜ The tool stays unavailable to the model, despite the matching permission rule.
⬜ The rule restores the tool and allows the operation without a prompt.
⬜ The rule restores the tool but asks for approval each time.
⬜ The tool becomes available the first time the model requests the operation.

A team has prepared an Azure DevOps MCP server entry in repository settings for Copilot cloud agent. Launch and authentication settings are ready, but the tools field is missing, and the task only needs wit_get_work_item. Which two actions enable that tool and confirm the agent can see it? (select two)

⬜ Add "tools": ["wit_get_work_item"] to the server entry.
⬜ Assign a test issue to Copilot and check the tool list in the Start MCP Servers step of the session logs.
⬜ Add "tools": ["*"] and rely on the task description to limit what’s used.
⬜ Save the entry and treat valid JSON as confirmation the tool is available.
⬜ Expose the work item as an MCP resource and use it instead of the tools field.

Copilot cloud agent must read a configuration file in a second private repository through the remote GitHub MCP server. The team wants the MCP credential limited to that repository and to read access. Which configuration meets this?

⬜ Use the read-only endpoint, select get_file_contents from the repos toolset, and supply a fine-grained token with read access to that repository.
⬜ Use the read-only endpoint, select get_file_contents, and keep the default token scoped to the agent’s current repository.
⬜ Use the read-only endpoint, select get_file_contents, and supply a fine-grained token with read and write access to every repository.
⬜ Use the read-only endpoint, select tools from the issues toolset, and supply a fine-grained token with read access to that repository.

What must a self-hosted MCP registry provide so supported Copilot clients can retrieve its server catalog?

⬜ HTTPS endpoints implementing the MCP registry v0.1 routes, with the required CORS headers
⬜ A remote MCP server endpoint exposing tools, with a tools array listing every catalog entry
⬜ A repository mcpServers configuration with command and args for each entry
⬜ An allowedMcpServers array of server matchers, published as the catalog response

A supported Copilot client receives an enterprise managed-settings.json policy. An external MCP server matches an entry in allowedMcpServers and an entry in deniedMcpServers, and it’s also listed in the company’s discovery registry. What happens?

⬜ The server is blocked, because the matching deny rule takes precedence.
⬜ The server is allowed, because the allowlist match takes precedence.
⬜ The server is allowed, because registry membership takes precedence.
⬜ The server’s tools become available after the user accepts a prompt.

A team tracks defects in acme/triage and keeps the affected code in acme/catalog. An engineer assigns a triage issue to Copilot cloud agent and selects acme/catalog as the target repository. Both repositories have custom instructions. Which two statements are correct? (select two)

⬜ Copilot works on the code in acme/catalog, because it was selected as the target.
⬜ Copilot uses the custom instructions of acme/catalog.
⬜ Copilot works on the code in acme/triage, because that’s where the issue is.
⬜ Copilot uses the acme/triage instructions instead of the target repository’s.
⬜ Any repository shown in the target dropdown can be selected if the engineer has read access.

A maintainer starts a new Copilot cloud agent task from the repository’s Agents tab. The fix must use the maintenance code in release/2.x, while main has incompatible next-version changes. How does the task start from the right code without making release/2.x the agent’s working branch?

⬜ Select release/2.x as the base branch for the task.
⬜ Select main as the base branch and mention release/2.x in the task title.
⬜ Keep main as the base branch and pick a custom agent for release work.
⬜ Make release/2.x the repository default branch and ask Copilot to push to it directly.

A GitHub Actions job has installed Copilot CLI, which found the documentation-checker custom agent. Authentication and permissions are set. The job must run a prompt with that agent and finish when the prompt completes. Which command does this?

⬜ copilot --agent=documentation-checker -p "Check the API documentation"
⬜ copilot --agent=documentation-checker -i "Check the API documentation"
⬜ copilot --name=documentation-checker -p "Check the API documentation"
⬜ copilot --agent=documentation-checker --plan -i "Check the API documentation"

A Copilot cloud agent setup workflow is on the default branch with the required job name. Its first step produces an optional environment report and exits with a nonzero status, so the later package-installation step never runs. What does this mean for the agent’s environment?

⬜ Copilot skips the remaining setup steps and starts work with the environment as it is.
⬜ Copilot holds the task until every setup step succeeds.
⬜ Copilot runs the remaining steps first and reports the failure afterward.
⬜ Copilot waits for workflow-run approval before continuing the setup.

An agent times out while reading a dependency service through a tool. It’s a temporary connection problem, and the read can’t change the service. The team allows up to two retries and is considering the same policy for tools that write data. Which two decisions are right? (select two)

⬜ Retry the failed read after a delay, within the permitted limit.
⬜ Check whether an operation can safely be repeated before applying the retry policy to a write.
⬜ Retry a write whenever its response is missing, treating that as proof it made no change.
⬜ Put retry loops in both the tool and its caller, each allowing two retries.
⬜ Treat an input-validation failure as temporary and resend the same request.

Copilot cloud agent pushes a faulty commit to its own working branch, and validation fails. The team wants to undo that commit’s changes but keep the shared branch history and the failure evidence. An engineer has a clean checkout and can push. What should they do?

⬜ Revert the faulty commit with Git, push the revert commit, and keep the failed run logs.
⬜ Stop the Copilot session and treat the branch as restored, keeping the failed run logs.
⬜ Restore the local files from the earlier commit but leave the remote branch unchanged, keeping the logs.
⬜ Rerun validation on the branch and use the new run as the rollback record, keeping the logs.

Which situation should make an agent workflow escalate to an accountable person before trying another fix?

⬜ The proposed fix would change live records, and its effects can’t be reliably reversed.
⬜ A repository read hits its first temporary connection error, within the retry budget.
⬜ A formatting check fails on an isolated branch where formatting fixes and reruns are already authorized.
⬜ A routine test run needs another diagnostic log, within the existing read-only tool boundary.

Which two tool assignments let a Copilot cloud agent reviewer inspect a localhost web preview that’s already running inside the cloud agent environment and read a known local report file? (select two)

⬜ Enable playwright/* to interact with the running preview in a browser.
⬜ Enable read to inspect the contents of the existing report file.
⬜ Enable WebFetch to navigate through the running preview.
⬜ Enable Glob to retrieve the complete contents of the known report.
⬜ Define Playwright in mcp-servers, because its browser tools aren’t available by default.

A team keeps two otherwise identical Copilot cloud agent profiles. Profile A leaves out the tools property; profile B has tools: []. The team needs a profile that reasons only from the supplied prompt, without calling any tools. Which profile provides that?

⬜ Profile B, because an explicit empty list disables all tools.
⬜ Profile A, because an omitted property enables no tools.
⬜ Either profile, because both use the default empty list.
⬜ Neither profile, because an empty list restores the built-in tool defaults.

In Copilot CLI, a session starts with --allow-tool='shell(git:*)' and --deny-tool='shell(git push)'. How is a git push handled?

⬜ It’s denied, because the matching deny rule takes precedence.
⬜ It’s allowed, because the broader Git rule includes every subcommand.
⬜ The CLI asks for approval, because the matching allow and deny rules cancel out.
⬜ The last-listed rule wins, so swapping the options would allow it.

A repository administrator is configuring the Azure MCP server for Copilot cloud agent. It should start as a local process, and its command, arguments and tools are already set. Which two values are supported for the missing type property? (select two)

{
  "mcpServers": {
    "Azure": {
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"],
      "tools": ["*"]
    }
  }
}

⬜ "type": "local"
⬜ "type": "stdio"
⬜ "type": "http"
⬜ "type": "sse"
⬜ Leave out type and let the command property select it.

An organization’s Copilot cloud custom agent has an Azure DevOps server named ado in its mcp-servers configuration, and that server exposes several tools. The agent needs local file reading plus only the server’s wit_get_work_item tool. Which top-level tools value applies that selection?

⬜ tools: ["read", "ado/wit_get_work_item"]
⬜ tools: ["read", "ado/*"]
⬜ tools: ["read"]
⬜ tools: ["ado/wit_get_work_item"]

Where does an organization owner set an MCP discovery registry URL for the organization’s Copilot users, when enterprise policy allows registry configuration at organization level?

⬜ In the organization’s Settings, under Copilot > Policies, in MCP Registry URL.
⬜ In each repository’s Settings, under Copilot > MCP servers, in the MCP configuration.
⬜ In the enterprise’s AI controls, under MCP, in the enterprise MCP Registry URL.
⬜ In an organization custom agent profile, using the mcp-servers YAML property.

A repository administrator sets up a remote GitHub MCP server for Copilot cloud agent. A valid personal access token is stored as an Agents secret named API_TOKEN, and the server JSON includes the lines below. Which change supplies the token through supported repository MCP secret substitution?

"type": "http",
"url": "https://api.githubcopilot.com/mcp/readonly",
"tools": ["get_file_contents"],
"headers": {
  "Authorization": "Bearer $API_TOKEN"
}

⬜ Rename the secret to COPILOT_MCP_API_TOKEN and reference $COPILOT_MCP_API_TOKEN in the header.
⬜ Keep the secret as API_TOKEN and change the header to ${{ secrets.API_TOKEN }}.
⬜ Keep the secret as API_TOKEN and replace the header reference with a VS Code inputs prompt.
⬜ Keep the secret as API_TOKEN and load it through an envFile entry in the server configuration.

Copilot cloud agent is enabled in a repository, and a developer with write access assigns it a self-contained issue. The team wants autonomous implementation followed by human acceptance. In the normal issue-assignment flow, which two capabilities define what Copilot can deliver? (select two)

⬜ Copilot can push implementation commits to the new copilot/ branch created for the task.
⬜ Copilot can open a pull request and request human review of the work.
⬜ Copilot can push the task commits directly to the default branch.
⬜ Copilot can approve and merge its own pull request after its validation succeeds.
⬜ Copilot can push commits to every branch the assigning developer can modify.

An organization has enabled Copilot cloud agent for its members and set Repository access to Selected repositories. A developer can delegate work in acme/docs but can’t select acme/payments, where they also have write access. An owner confirms that acme/payments isn’t in the selected list. Which change enables delegation there while keeping the current selection policy?

⬜ Add acme/payments to the cloud agent’s selected repositories.
⬜ Enable the MCP servers on GitHub.com policy for the organization.
⬜ Turn off the cloud agent’s workflow-run approval requirement in acme/payments.
⬜ Allow cloud agent automations for the organization’s repositories.

A team maintains a GitHub Agentic Workflow that summarizes new issues. It currently runs on a schedule, but now it must run when an issue is opened. Its output permissions are already correct. Which update configures and publishes the new trigger?

⬜ Set on.issues.types to [opened] in the Markdown frontmatter, recompile, and push both updated workflow files to the default branch.
⬜ Set on.issue_comment.types to [created] in the frontmatter, recompile, and push both files to the default branch.
⬜ Set on.issues.types to [labeled] in the frontmatter, recompile, and push both files to the default branch.
⬜ Describe the issue-opened behavior in the Markdown instructions, keep the schedule in the frontmatter, recompile, and push both files.

A repository has .github/workflows/copilot-setup-steps.yml on its default branch. The workflow is named “Copilot Setup Steps” and has one job with the ID prepare and valid install steps. It runs fine in normal Actions testing, but Copilot cloud agent ignores it. Which edit meets the cloud agent’s discovery requirement?

⬜ Change the job ID from prepare to copilot-setup-steps.
⬜ Change the workflow name to prepare.
⬜ Change the first step’s name to copilot-setup-steps.
⬜ Add a run-name of copilot-setup-steps to the workflow.

A team uses the Copilot TypeScript SDK. A tool call raises a recoverable execution error, and the application has confirmed that repeating the operation is safe. The team wants its error handler to recognize this category and ask for one retry. Which two implementation choices meet that requirement? (select two)

⬜ Use onErrorOccurred and check errorContext for tool_execution together with recoverable.
⬜ Return errorHandling set to retry with retryCount set to 1 from the error handler.
⬜ Use onPostToolUse to catch the error, because it receives both successful and failed tool returns.
⬜ Return null from the error handler to replace default handling with exactly one retry.
⬜ Return suppressOutput: true to request the retry while keeping the error out of the interface.

A maintainer is investigating why Copilot cloud agent removed a compatibility check in a pull request. The commit diff shows the removal, but the maintainer needs the session’s tool activity and validation attempts to understand how it happened. Which record links directly to that execution?

⬜ The session-log link in the Copilot-authored commit message.
⬜ The current CODEOWNERS entry for the file that contained the check.
⬜ The latest successful workflow run on the default branch.
⬜ The pull request’s list of requested reviewers.

An agent-generated pull request has already been merged on GitHub. How does the pull request’s Revert button prepare a controlled rollback?

⬜ It creates a new pull request that reverses the original merge commit; merging that pull request applies the reversal.
⬜ It pushes a reversal commit straight to the base branch, then opens a pull request to document it.
⬜ It creates a pull request that reverses the merge and every later commit, restoring the earlier branch snapshot.
⬜ It creates a pull request that deletes the merge commit from history while keeping later commits.

For Copilot cloud agent test maintenance, which two tool alias replacements keep the capability the stated operation needs? (select two)

⬜ Replace edit with MultiEdit to update assertions in existing test files.
⬜ Replace execute with powershell to run the repository’s test command.
⬜ Replace edit with NotebookRead to update assertions in test files.
⬜ Replace execute with Task to run the test command in the same agent.
⬜ Replace edit with Grep to apply replacements to matching assertions.

A Copilot CLI session has a file-editing tool available, but a proposed update to docs/api.md is waiting for write approval. The team wants future updates to that file to run without permission prompts, while writes to other files keep their existing permissions. There are no matching deny rules. Which startup option grants exactly that?

⬜ --allow-tool='write(docs/api.md)'
⬜ --allow-tool=write
⬜ --allow-all-tools
⬜ --available-tools='edit,view'

A developer adds the todo tool alias to a Copilot custom agent profile used in VS Code. What does it provide?

⬜ Creating and managing structured task lists.
⬜ Searching repository files for TODO comments.
⬜ Delegating tasks to another custom agent.
⬜ Running shell commands for listed tasks.

A team configures a local Sentry MCP server for Copilot cloud agent, with npx as its command and a reviewed tool list. The Start MCP Servers log reports that npx can’t be found, and the server never starts. Which two statements identify the failure and a suitable fix? (select two)

⬜ The launcher isn’t available to the server process, so startup never got as far as tool discovery.
⬜ Set up the runtime in copilot-setup-steps.yml so npx exists when the local MCP server starts.
⬜ Install the runtime in the separate pull request validation workflow so later cloud agent sessions have it.
⬜ Put the install command in the custom agent instructions so it runs before MCP startup.
⬜ Move npx into args and remove command so the configuration picks the launcher automatically.

A company’s discovery registry lists an external MCP server. On a supported Copilot client, MCP use is enabled and the enterprise managed-settings.json includes allowedMcpServers. The external server matches no allowlist entry and no denylist entry. How does the client treat it?

⬜ It blocks the server, because an allowlist is present and requires a matching entry.
⬜ It allows the server, because no denylist entry matches.
⬜ It allows the server, because being in the discovery registry counts as approval.
⬜ It allows the server once the user adds it to their local MCP configuration.

Which URL belongs in MCP Registry URL for an Azure API Center registry, so Copilot can add the registry API route correctly?

⬜ https://contoso-apic.data.eastus.azure-apicenter.ms/workspaces/default
⬜ https://contoso-apic.data.eastus.azure-apicenter.ms/workspaces/default/v0.1/servers
⬜ https://contoso-apic.data.eastus.azure-apicenter.ms/workspaces/default/v0.1/servers/example/versions/latest
⬜ https://contoso-apic.data.eastus.azure-apicenter.ms

A team adapts a remote GitHub MCP connection that signs in with browser-based OAuth in VS Code. Copilot cloud agent needs the same approved repository reads, but the team has kept the OAuth approach in its repository configuration. Which approach supports authentication for cloud agent?

⬜ Supply a suitably scoped personal access token through an Agents secret and the supported MCP credential configuration.
⬜ Copy the VS Code inputs sign-in prompt into the repository MCP JSON so the cloud task can ask for sign-in.
⬜ Keep OAuth and set X-MCP-Toolsets to repos to enable authentication for repository operations.
⬜ Keep OAuth and use a wildcard tools selection to make sign-in available.

A maintainer finds that a pull request created with a Copilot cloud custom agent profile targets main, although the fix belongs on release/2.x. They change the pull request’s base to release/2.x and review its scope again. Which two effects of changing the base should they account for? (select two)

⬜ The pull request now compares its changes against release/2.x instead of main.
⬜ Some earlier review comments may become outdated if the lines they refer to drop out of the comparison.
⬜ The commit list in the timeline stays identical, because the source branch hasn’t changed.
⬜ Earlier review comments stay current in the new diff even when their lines drop out of the comparison.
⬜ Follow-up work on the pull request switches to the latest custom agent profile from release/2.x.

A pull request workflow runs Copilot CLI with the intended custom agent and a programmatic prompt, but authentication fails. In that step, COPILOT_GITHUB_TOKEN holds an expired credential and GH_TOKEN holds a valid fine-grained token with the Copilot Requests permission. Which change makes the CLI use the valid credential?

⬜ Remove the expired COPILOT_GITHUB_TOKEN value from the step’s environment.
⬜ Keep both values and add --no-ask-user to the command.
⬜ Keep both values and select the custom agent again with --agent.
⬜ Keep both values and also provide the valid token through GITHUB_TOKEN.

A team adds a valid .github/workflows/copilot-setup-steps.yml with the required job to an unmerged setup-improvements branch. Its pull request check passes, but new Copilot cloud agent sessions still start without the setup steps. The default branch doesn’t have the file. What should the team do?

⬜ Merge the reviewed setup workflow into the default branch.
⬜ Choose setup-improvements as the base branch for new cloud agent tasks, without merging.
⬜ Run the setup workflow once with workflow_dispatch and leave it on the unmerged branch.
⬜ Add the setup file name to the custom agent instructions and leave it on the unmerged branch.

Copilot cloud agent opens a pull request with a fix and finishes its task, but the repository’s CI workflows are waiting to start. The repository keeps the default approval requirement for workflows on agent changes. A maintainer has inspected the changes and wants CI to run. What releases the waiting runs?

⬜ A user with write access clicks Approve and run workflows on the pull request.
⬜ A maintainer submits an approving code review.
⬜ A maintainer marks the draft pull request ready for review.
⬜ A maintainer posts an @copilot comment asking for another validation pass.

A Copilot TypeScript SDK application tracks retries for a required tool operation and allows at most two. Both retries have failed, and onErrorOccurred reports another error with recoverable set to true. The current user is the designated investigator. The handler must now stop automated execution and notify a person, while keeping the failure history. Which two responses meet those requirements? (select two)

⬜ Return errorHandling: "abort", because the application’s retry allowance is used up.
⬜ Provide a userNotification about the exhausted retries, and keep the recorded failures for the investigator.
⬜ Return errorHandling: "retry" with retryCount: 2 for the error reported after the two failed retries.
⬜ Return errorHandling: "skip" with a note that the required operation still needs investigating.
⬜ Return suppressOutput: true, leaving the other output fields unset.

An agent’s required validation job keeps failing because a dependency can’t be reached from its environment. The team’s allowed recovery attempts are used up, and some code changes are already on the pull request branch. A platform engineer will investigate. What should the agent include in the escalation so it’s actionable?

⬜ The failed step and its log link, the remedies already tried, the current branch changes, and the environment question the engineer needs to decide.
⬜ The full log archive, the workflow name, the branch link, and a request for a platform-level assessment.
⬜ The current diff, the formatting result, the acceptance criteria, and a request for implementation approval before another attempt.
⬜ The original prompt, the configured tools, the dependency access policy, and a request for a larger retry allowance.

A Copilot cloud agent task fails before creating any commit. A reviewer needs to reconstruct the tool operations it attempted, identify the task that started it and confirm the outcome. Which evidence supports that review?

⬜ The initiating task, the failed session log and the related workflow run, noting that no commit was produced.
⬜ The initiating task and the workflow result, skipping the session log because logs only appear after a commit.
⬜ The initiating task and the archived session entry, treating archived status as proof no tools ran.
⬜ The initiating task and the final error notification, treating that notification as the full record of earlier tool calls.

Which two Copilot cloud custom agent tool lists match the stated responsibility, using the dedicated file and delegation tools? (select two)

⬜ A planner that reads supplied source files and saves a plan file: ["read", "edit"].
⬜ A coder that changes a file and calls a separate review specialist: ["edit", "agent"].
⬜ A planner that searches the repository and saves a plan file: ["search", "read"].
⬜ A reviewer that reads a report and calls another specialist: ["read", "todo"].
⬜ A coder that finds a function and replaces its implementation: ["search", "agent"].

A documentation team has a Copilot cloud agent profile with tools: ["*"]. The task is to inspect and update two already-identified Markdown files, with no repository search, shell commands or other integrations. Which replacement keeps the file tools the task needs and removes the broader access?

⬜ tools: ["read", "edit"]
⬜ tools: ["read", "edit", "*"]
⬜ tools: ["read", "search"]
⬜ tools: []

In Copilot CLI, which startup option turns a prompt instruction to protect config/production.yml into a runtime denial of built-in file writes to that path, without changing write permissions for other paths?

⬜ --deny-tool='write(config/production.yml)'
⬜ --allow-tool='read(config/production.yml)'
⬜ --available-tools='edit,view'
⬜ --deny-tool=write

A Copilot cloud custom agent overrides one setting of a built-in MCP server. Repository Alpha sets a different value for that same setting in its repository MCP configuration. Repository Beta uses the same custom agent but has no repository MCP override. Which two statements describe the effective setting? (select two)

⬜ Alpha uses its repository value, because repository MCP settings are processed after the custom agent configuration.
⬜ Beta uses the custom agent value, because the profile is processed after the built-in MCP configuration.
⬜ Alpha uses the custom agent value, because agent-specific settings are processed after repository settings.
⬜ Beta uses the built-in value, because default MCP settings override custom agent values.
⬜ Alpha combines the conflicting values, because repository and custom agent settings have equal priority.

A supported Copilot client gets managed MCP policy from two places: a GitHub-hosted managed-settings.json and a file deployed through mobile device management (MDM). Both define valid allowlists, and neither has a deny rule. An external server matches the GitHub-hosted allowlist but not the MDM one. What’s the result?

⬜ The server is blocked, because it has to match the allowlist at every applicable layer.
⬜ The server is allowed, because matching either layer satisfies the combined allowlist.
⬜ The server is allowed, because GitHub-hosted settings replace the MDM allowlist.
⬜ The server is allowed, because neither policy has a matching deny rule.

Several teams share an MCP registry, and enterprise managed settings control server access separately. Which responsibility belongs to the shared registry?

⬜ Publishing server metadata that supported clients can query for discovery.
⬜ Evaluating allowedMcpServers and deniedMcpServers to decide which servers can run.
⬜ Selecting a custom agent’s individual tools through its top-level tools list.
⬜ Limiting a personal access token to the repositories an agent may read.

Copilot cloud agent’s remote GitHub MCP connection can read public files, but reading a file from the organization’s private repository is denied. A non-owner member’s fine-grained token selects that repository with Contents read access, but its approval is pending under the organization’s token policy. Which action enables the private read while keeping that policy?

⬜ An organization owner approves the pending token request after reviewing its repository and permission scope.
⬜ Raise the pending token’s Contents permission from read to write.
⬜ Remove /readonly from the MCP endpoint, keeping the same pending token.
⬜ Expand X-MCP-Toolsets to more tools, keeping the same pending token.

A repository has a GitHub Agentic Workflow source file, dependency-summary.md, and a generated dependency-summary.lock.yml. An engineer needs to change the agent instructions while keeping the execution configuration reproducible. Which two statements describe these files correctly? (select two)

⬜ The Markdown file holds the maintained instructions and the frontmatter configuration.
⬜ The lock file is the compiled GitHub Actions workflow that actually runs.
⬜ The lock file is the report produced after the agent finishes.
⬜ The Markdown body sets write permissions independently of the frontmatter.
⬜ The Markdown source runs directly in Actions without a compiled workflow.

A Copilot cloud agent setup step can reach https://build.example.com/catalog/, but a later request from the agent’s Bash tool is blocked by its firewall. The repository allows custom allowlist entries. The task needs that HTTPS path and everything under it, while other paths on the host stay blocked. Which change provides the access?

⬜ Add https://build.example.com/catalog/ to the cloud agent’s custom allowlist.
⬜ Add build.example.com to the cloud agent’s custom allowlist.
⬜ Turn off the cloud agent firewall for the repository.
⬜ Add https://build.example.com/catalog/ to the code review custom allowlist.

A GitHub Actions workflow runs Copilot CLI to inspect proposed release changes. It should run for pull requests that target release/2.x, whatever the source branch is called. Which event configuration matches?

⬜

on:
  pull_request:
    branches: [release/2.x]

⬜

on:
  push:
    branches: [release/2.x]

⬜

on:
  pull_request:
    branches-ignore: [release/2.x]

⬜

on:
  pull_request:
    branches: [copilot/release-fix]

An engineer has refined a documentation change in Copilot Chat on GitHub.com, and the conversation already has the required behavior and repository context. They now want cloud agent to implement it and open a pull request that uses those details. Which action starts that handoff from the current chat?

⬜ Use /task with a request to create the pull request for the discussed change.
⬜ Use the agents panel to create a new custom agent profile for the repository.
⬜ Open an existing workflow run and choose Fix with Copilot.
⬜ Mention @copilot on an existing pull request to update its branch.

A team configures Copilot CLI command hooks with camelCase event names. Its audit handler records successful tool results, but now a tool returns a failure and the team needs the failed operation and its error captured. Which two statements identify the right event and evidence? (select two)

⬜ postToolUseFailure fires after a tool completes with a failure.
⬜ The postToolUseFailure input includes toolName, toolArgs and error for the failed operation.
⬜ postToolUse gets the failed result in toolResult, because it runs after every completed tool call.
⬜ preToolUse gets the final error before execution and can record the failure then.
⬜ errorOccurred handles an errorHandling retry response from a CLI command hook to repeat the call.

In a Copilot CLI task, an agent may update tools/catalog-sync.py and its test together. The edit to the first tracked file succeeds, but the second edit fails before touching the test. Nothing was staged or committed. An engineer has saved the diff and error log and decides to discard the partial edit while keeping unrelated local work. From the repository root, which command restores the edited file to HEAD without touching other paths?

⬜ git restore --source=HEAD --worktree -- tools/catalog-sync.py
⬜ git restore --source=HEAD --staged -- tools/catalog-sync.py
⬜ git restore --source=HEAD --worktree -- .
⬜ git revert HEAD

When tracing an agent-generated change through human review, which GitHub record shows explicit acceptance of the changes, as opposed to general feedback or a review request?

⬜ A submitted pull request review with the decision Approve.
⬜ A submitted pull request review with the decision Comment.
⬜ A person listed as a requested reviewer on the pull request.
⬜ A person listed as co-author on a Copilot cloud agent commit.

Domain 3: Manage memory, state, and execution (10–15%)

In Copilot CLI with Copilot Memory turned on, which two statements correctly separate the current session’s context from information kept for later tasks? (select two)

⬜ Recent tool results in the CLI context support decisions within the current task.
⬜ Repository facts stored by Copilot Memory can support later CLI tasks in the same repository.
⬜ The /context command lists the repository facts Copilot Memory has stored.
⬜ A saved CLI session plan is shared with repository users as a Copilot Memory fact.
⬜ A GitHub issue becomes short-term memory when its contents are read into a session.

When Copilot Memory retrieves a repository fact relevant to a task, what decides whether it can be used on the current branch?

⬜ Whether the cited code on the current branch still supports the fact
⬜ Whether the pull request the fact came from was merged into the default branch
⬜ Whether the same user who caused the fact to be stored started the current task
⬜ Whether the fact was last used within the retention period

An engineer is clearing old Copilot CLI sessions from a laptop. The finished sessions have already synced to GitHub and are more than 30 days old. What happens when they run /session prune --older-than 30?

⬜ The local copies are deleted, and the synced copies stay on GitHub.
⬜ Both the local and synced copies are deleted.
⬜ The synced copies are deleted, and the local copies stay available.
⬜ The synced copies are hidden from searches, and local files are unchanged.

An agent is migrating an API in two phases: add a compatibility adapter, then update the callers. It pushed the adapter to its pull request branch and the adapter checks passed, but it must stop before updating the callers. The plan is only in session context, and the check report is only on the Actions runner. Which two records should it save so a later run can continue? (select two)

⬜ A checkpoint in the pull request with the completed adapter, its commit and the next step (updating the callers).
⬜ The check report as a workflow artifact, linked from the checkpoint with its run and the tested commit.
⬜ A note marking the whole migration complete, because the adapter checks passed.
⬜ The check report in a dependency cache, using its availability as the completion record.
⬜ The original adapter edits as the next steps, so the later run rebuilds the adapter.

A maintainer is resuming a stopped Copilot cloud agent task with two steps: a parser fix and a guide update. The saved checklist still shows both as pending, but the pull request contains the parser fix, and parser checks passed on the latest commit. Nothing has changed since, and the guide still needs updating. What should the resumed agent do next?

⬜ Reconcile the checklist with the commit and check results, mark the parser step done, and start the guide update.
⬜ Redo the parser fix from the checklist, then update the guide after another commit.
⬜ Treat the passing parser check as completing the whole checklist and hand over the pull request.
⬜ Reset the branch to before the fix and replay the original steps so the checklist matches.

During a long Copilot CLI task, the plan limits changes to services/billing/. After compaction, Copilot starts editing an authentication component. Before correcting the work, an engineer wants to know whether the compaction summary kept the billing constraint. Which inspection answers that directly?

⬜ Use /session checkpoints to inspect the saved summary and compare its scope with the plan.
⬜ Use /context to compare token percentages before and after the authentication edit.
⬜ Use /session files to compare the changed files with the number of tasks left.
⬜ Use /session info to compare the session ID and working directory with those before compaction.

A Copilot CLI investigation finds a configuration defect in a file on a feature branch. Before handing the task to Copilot cloud agent, the engineer must reference the exact file contents that produced the finding, even though both main and the feature branch may get more commits first. Which reference preserves that context?

⬜ A permalink to the file containing the inspected commit SHA, with the relevant line range
⬜ A link containing the feature branch name, with the line range
⬜ A link containing the main branch name, with the line range
⬜ A feature-branch link whose line anchor is updated after the next push

A cloud agent is asked to continue a pull request whose handoff says the latest changes passed validation. The linked Actions run originally checked out the commit that triggered it. After another commit was pushed to the branch, an engineer chose Re-run all jobs on that earlier run, and it passed. What does this show?

⬜ It validates the original commit, because a rerun keeps the original event’s SHA and ref.
⬜ It validates the newer commit, because the rerun finished after it was pushed.
⬜ It validates the newer commit, because the branch name still matches.
⬜ It validates the newer commit, if the person who reran it can write to the branch.

An individual Copilot Pro user has Copilot Memory turned on. Which two statements describe how repository facts and user preferences are shared? (select two)

⬜ Repository coding conventions are available to eligible Copilot Memory users working in that repository.
⬜ The user’s interaction preferences can be reused in that user’s later Copilot CLI tasks, across repositories.
⬜ Repository coding conventions follow the user into work on unrelated repositories.
⬜ A user’s interaction preferences become shared repository facts when they’re learned during repository work.
⬜ Copilot code review applies the user’s interaction preferences as well as repository facts.

Where should task-specific acceptance criteria be kept so that engineers and later agent runs can read and discuss them?

⬜ In the GitHub issue that tracks the task.
⬜ In the current agent session’s active context.
⬜ In the repository-wide custom instructions file.
⬜ In the initiating user’s Copilot Memory preferences.

The requirements and repository guidance for a task have changed, so the approach built up in a long Copilot CLI session is now obsolete. After saving the useful findings and the new requirements in the GitHub issue, how should the engineer restart without carrying the old assumptions forward?

⬜ Start a fresh CLI session and load the updated issue and current repository guidance.
⬜ Compact the session and use its summary of the earlier approach as the new starting point.
⬜ Resume the earlier session and continue from its plan and conversation history.
⬜ Load an earlier session checkpoint and rebuild the approach from its saved goals.

Before resuming a Copilot CLI session, an engineer wants to look at its saved history and work. They’ve found the session directory under ~/.copilot/session-state/. Which two kinds of records should be there? (select two)

⬜ An events.jsonl event log for the session.
⬜ Workspace artifacts such as plans, checkpoints and tracked files.
⬜ A settings.json file with the completed task sequence.
⬜ A permissions-config.json file with the ordered tool results.
⬜ A command-history-state/ directory with the saved implementation plan.

An agent is planning a report-export feature when a diagnostic shows the proposed bulk endpoint can’t provide a required field. Based on that result, the team picks an existing paginated endpoint and saves the diagnostic output as a workflow artifact. Implementation hasn’t started. What should the agent record in the task checkpoint so the next run can implement the chosen approach?

⬜ The rejected endpoint, the link to the diagnostic evidence, the selected endpoint and the next implementation step.
⬜ The diagnostic artifact link and the original endpoint plan, leaving the next run to choose again.
⬜ The selected endpoint and a completed implementation status, using the investigation as evidence.
⬜ The original endpoint and a pending diagnostic status, using the saved commands as the next run’s instructions.

A team has approved moving its application from the retired v1 interface to v2. An agent must update the adapter before running the integration tests, but the code still calls v1, and the team’s task-state.json file says:

{
  "adapter": "complete",
  "next": "integration-tests"
}

How should the agent reconcile this saved progress with the approved interface change? ⬜ Mark the adapter as needing a v2 update, record the new constraint, and block the dependent tests until that update is done.
⬜ Keep the adapter marked complete, rename the saved interface to v2, and go straight to the integration tests.
⬜ Keep the v1 adapter complete, change the test expectation to v1, and record a passing result.
⬜ Reset every task to pending, remove the completed-work references, and regenerate the task from the original request.

A team prepares a Copilot Space for a handoff with a linked GitHub issue and a pasted note from an earlier IDE discussion. The issue is the agreed record for acceptance criteria and now requires a 30-day report. The pasted note still says 7 days. Which change aligns the Space with the maintained requirements?

⬜ Keep the linked issue as a source and update the pasted note to match its current criteria.
⬜ Change the Space description to say 30 days and keep both sources as they are.
⬜ Replace the linked issue with a new upload of the unchanged IDE note.
⬜ Keep both sources and add an instruction that the pasted note takes precedence.

A team uses separate GitHub Actions jobs to plan and carry out an agent task. In the job with ID plan, a planning agent creates plan.json and uploads it as an artifact named approved-plan, without committing it. The execution agent must get that file on another GitHub-hosted runner in the same run, and start only after planning succeeds. How should its job be configured?

⬜ Set needs: plan and download the approved-plan artifact before reading plan.json.
⬜ Set needs: plan and read plan.json directly from the job’s workspace.
⬜ Set needs: plan and use actions/checkout to get the generated plan.json.
⬜ Download the approved-plan artifact and leave out the dependency on the planning job.

Which two properties make GitHub issues and pull requests useful as external memory for an agent workflow? (select two)

⬜ Their maintained task records can be read independently of any one agent conversation.
⬜ Their discussions and change history let collaborators inspect task context outside the agent conversation.
⬜ Their task history is visible only to the user who started the agent session.
⬜ All their linked records stay in the active context when a conversation is compacted.
⬜ Their stored decisions stay valid for later work without checking whether the repository has changed.

How does Copilot Memory scope a stored repository fact when the same user starts work in an unrelated repository?

⬜ The fact stays available only for work in the repository where it was stored.
⬜ The fact follows the user and becomes available in the new repository.
⬜ The fact becomes available in the new repository if both have the same owner.
⬜ The fact becomes a personal preference if the new repository has no equivalent fact.

A team wants to know how long Copilot Memory keeps two repository facts: one is still used during maintenance work, and the other hasn’t been used. Which statement describes the retention?

⬜ An unused entry is deleted after 28 days, and successful validation and use can reset its timer.
⬜ Every entry is deleted 28 days after creation, even if it keeps being validated and used.
⬜ Repository facts stay until an owner deletes them; the 28-day rule only applies to user preferences.
⬜ A fact’s timer resets when an owner views it, while use by Copilot doesn’t change the timer.

An agent is about to resume work on support for larger reports. Its saved checkpoint says streaming support is complete and reports can be up to 5 MB. Since then, a maintainer has fully reverted the streaming code, and the issue now requires 20 MB reports. Which two updates should the agent make to its saved state before continuing? (select two)

⬜ Set the streaming-support status from the current code, rather than treating its original commit as proof it’s done.
⬜ Replace the old size limit with the maintained 20 MB requirement and reassess the work needed.
⬜ Keep streaming marked complete, because a revert adds a commit without removing the original from history.
⬜ Change the issue back to 5 MB so the task matches the checkpoint that was recorded first.
⬜ Mark every earlier task incomplete, because the revert invalidates all progress before it.

A Copilot-assisted optimization replaced a streaming reader with an in-memory reader. Tests hit an out-of-memory failure, and an engineer reverted the change while keeping the failure report. The code now looks like the original version again. What checkpoint entry stops a later agent from treating this approach as untried?

⬜ Record the in-memory approach as tried and rejected, linking the failing test, the implementation commit and the revert.
⬜ Record the reader change as pending, linking the restored code as the starting point for the optimization.
⬜ Record the reader change as complete, linking the successful revert as evidence it finished.
⬜ Record the original streaming code as the chosen plan, using the current diff to explain the choice.

An agent ran gh pr create for agent/report-fix targeting main, but stopped before recording whether it worked. The branch was created just for this task and hasn’t been reused. Any resulting pull request would still have the same head and base, but a maintainer may have closed or merged it in the meantime. Which lookup should the agent run before trying again?

⬜ gh pr list --head agent/report-fix --base main --state all, then inspect any match and its state.
⬜ gh pr list --head agent/report-fix --base main, treating an empty result as proof creation failed.
⬜ gh pr create --head agent/report-fix --base main --fill, using the new response in place of the missing checkpoint.
⬜ gh pr list --head agent/report-fix --base main --state merged, treating an empty result as proof no pull request exists.

Before handing a client-generation task from the IDE to Copilot cloud agent, an engineer checks the handoff’s naming guidance. It says to use snake_case, based on .github/copilot-instructions.md. The cloud agent will also receive .github/instructions/client.instructions.md, which applies to these files and requires camelCase. Under GitHub’s documented instruction priority, what should the handoff say?

⬜ The applicable path-specific instruction takes priority, so the handoff should use camelCase for those files.
⬜ The repository-wide instruction takes priority, so the handoff should use snake_case.
⬜ Both files have equal priority, so the handoff can use either style.
⬜ Path-specific instructions only apply to code review, so the handoff should keep snake_case.

When handing a pull request from Copilot CLI to cloud agent, an engineer includes a passing test result from GitHub Actions. The pull_request workflow used default actions/checkout, which tests the pull request’s merge commit. The pull request branch hasn’t changed since, but new commits on the base branch have produced a different merge commit. How should cloud agent use this result to judge compatibility with the current base?

⬜ Treat it as evidence for the earlier merge result, and get validation of the current merge result.
⬜ Treat it as current evidence, because the pull request’s head commit hasn’t changed.
⬜ Treat it as current evidence, because the base branch still has the same name.
⬜ Treat it as current evidence, because the workflow file hasn’t changed.

When a tool response is larger than Copilot CLI’s configured large-output threshold, which two statements describe how it’s stored and shown to the model? (select two)

⬜ The full output is saved to a temporary file outside the active conversation.
⬜ The model gets the file path and a preview of the output.
⬜ The full output replaces earlier conversation messages in the active context.
⬜ The response is stored as a numbered compaction checkpoint.
⬜ The limit applies to built-in tools, while MCP responses stay fully inline.

When both repository-wide and path-specific instructions apply to a file and are enabled for Copilot cloud agent, which does the agent receive?

⬜ Both the matching path-specific instructions and the repository-wide instructions.
⬜ Only the matching path-specific instructions, replacing the repository-wide ones.
⬜ Only the repository-wide instructions, replacing the path-specific ones.
⬜ The path-specific instructions for every directory, plus the repository-wide ones.

An engineer needs the exact tool output from a Copilot CLI investigation for a later review. The GitHub issue has a summary of the findings, and the engineer is about to compact the conversation to free up context. How should they preserve the evidence first?

⬜ Save the exact output outside the conversation and link it from the issue summary.
⬜ Use the compaction checkpoint as the complete copy of the original output.
⬜ Keep the issue summary and recover the exact output by reversing compaction during review.
⬜ Run /context before compacting, so the review can recover the output from its usage report.

An agent has pushed the code and tests for a parser update to its pull request branch, but has to stop before it can run the tests. The task record still says implementation is in progress, so a later agent might redo work that’s already committed. Which two checkpoint updates let an authorized agent continue on the same branch from the right point? (select two)

⬜ Mark implementation complete, and record the pushed commit and the files it changed.
⬜ Mark validation as not yet run, and record the required test step and expected result.
⬜ Keep implementation in progress, and make the original file edits the first steps of the resumed run.
⬜ Mark validation complete, using the successful push as evidence the tests passed.
⬜ Mark the whole task complete, because the pull request now has both the code and tests.

An agent was asked to add CSV and PDF report exports. After the CSV work is accepted, reviewers move PDF to a separate issue so this task can focus on CSV. The agent hasn’t written any PDF code, but its saved queue still says to implement PDF and then review both formats. How should it update the queue to finish the revised task?

⬜ Keep the completed CSV step, remove PDF from this task’s pending work, and move on to reviewing the CSV output.
⬜ Keep the completed CSV step, finish the queued PDF step, and move PDF to the separate issue during final review.
⬜ Reset the CSV step to pending, remove PDF, and rebuild CSV from the original combined request.
⬜ Keep both queued steps, restore the original two-format description, and resume at PDF.

An agent resumes a task after a maintainer changes parser.ts. Its checkpoint records a finished implementation plus passing parser tests, export integration tests and documentation link checks. The integration tests use the parser; the link checks only use Markdown files and link targets that haven’t changed. How should the agent update its validation checkpoint?

⬜ Re-run the parser and export integration validation, keep the documentation result, and keep the completed implementation history.
⬜ Re-run parser validation, keep the integration and documentation results, and keep the implementation history.
⬜ Re-run the documentation check, keep the parser and integration results, and keep the implementation history.
⬜ Repeat the implementation from the first step, and discard all three validation results.

An engineer is handing a task from the IDE to cloud agent working in acme/catalog-service. The requirement is issue 42 in acme/catalog, and the implementation is PR 73 in acme/catalog-service. The handoff says “Continue #42 using #73,” but catalog-service has an unrelated issue 42. Which replacement identifies the right requirement and implementation?

⬜ acme/catalog#42 for the requirement and acme/catalog-service#73 for the implementation.
⬜ acme/catalog-service#42 for the requirement and acme/catalog-service#73 for the implementation.
⬜ acme/catalog#42 for the requirement and acme/catalog#73 for the implementation.
⬜ #42 for the requirement and GH-73 for the implementation, in the catalog-service conversation.

An agent in a new GitHub Actions run needs to continue from an approved plan saved as an artifact in an earlier run. The handoff names that run, but a newer run in the same repository has an unrelated plan under the same artifact name. How should the agent configure actions/download-artifact, using a token with Actions read access?

⬜ Set name to the artifact name, run-id to the run named in the handoff, and github-token to the token.
⬜ Set name to the artifact name, run-id to the current run, and github-token to the token.
⬜ Set name to the artifact name, run-id to the newer run, and github-token to the token.
⬜ Set name to the artifact name, path to the run ID from the handoff, and github-token to the token.

Domain 4: Perform evaluation, error analysis, and tuning (15–20%)

A team scores agent-generated retry changes by averaging functional, compatibility and runtime scores. One change passes overall even though it breaks the public API. The task requires recovering from temporary failures, API compatibility and staying within a fixed runtime budget. Which two rules should the revised scorecard enforce? (select two)

⬜ Require separate passes for API compatibility and the runtime budget before recording overall success.
⬜ Require evidence that retries recover from temporary failures, independently of the compatibility and runtime results.
⬜ Weight functional tests more heavily so strong recovery can make up for compatibility failures.
⬜ Use the number of successful tool calls as the functional score, keeping the average.
⬜ Replace the runtime limit with the average runtime of accepted changes in the batch.

When evaluating an agent-generated change, how should a measured test duration and a reviewer’s explanation of maintainability be classified?

⬜ Test duration is quantitative; the maintainability explanation is qualitative.
⬜ Test duration is qualitative; the maintainability explanation is quantitative.
⬜ Both are quantitative, because both can affect acceptance.
⬜ Both are qualitative, because the team must interpret both.

An agent changes a CSV exporter so values containing commas stay in one field. The pull request has a completed CodeQL scan with no alerts, but its tests only export values without commas. What evidence should the reviewer get to confirm the behavior works?

⬜ A test that exports a value containing a comma and checks the resulting field structure
⬜ A second CodeQL scan of the same commit with the same configuration
⬜ A dependency review showing no new vulnerable packages
⬜ A secret scanning result showing no exposed credentials

A Copilot-generated pull request updates a package manifest and lock file. The team wants an automated comparison that finds known vulnerable package versions introduced by the change, including indirect dependencies. Which GitHub check provides that?

⬜ The dependency review action, comparing the pull request’s dependency changes
⬜ CodeQL analysis of the source code
⬜ Secret scanning of the repository history
⬜ The existing unit test job

A team asks a Copilot agent to remove archived projects from a report but keep active ones, including active projects with no recent activity. The session record has that requirement, but the agent plans to remove projects based on their last activity date. Its edits succeed and implement that plan, and an unchanged acceptance test shows an active project missing. Which two findings explain the failure? (select two)

⬜ The agent replaced archive status with inactivity when interpreting the requirement.
⬜ The successful edits carried out the mistaken plan; they didn’t show the task was understood correctly.
⬜ The editing tool failed to apply the filter the agent asked for.
⬜ The agent didn’t have the requirement about active projects.
⬜ The acceptance test added a new requirement after the plan was made.

An agent correctly plans to inspect unstaged edits, but runs git diff --cached, which completes normally and shows no changes. How should this first error be classified?

⬜ Tool misuse: it compared staged changes for a task about unstaged changes.
⬜ Tool execution failure: Git couldn’t complete the comparison.
⬜ Invalid syntax: Git rejected an unsupported option.
⬜ Missing context: the agent wasn’t told which changes to inspect.

A Copilot agent submits a change to an order service and runs the required pytest integration tests. Pytest collects the tests, but the shared connection fixture raises ConnectionRefusedError when opening the test service. The fixture uses the documented endpoint, and an availability check confirms the service is offline. Which classification fits this evidence?

⬜ An unavailable environment dependency stopped the test bodies from running.
⬜ A behavioral defect in the generated order logic made assertions fail.
⬜ A malformed test command stopped pytest from starting.
⬜ A reasoning error made the agent validate the wrong requirement.

A documentation team finds that Copilot cloud agent pull requests repeatedly skip link validation. The repository instructions cover editing conventions but not the link check, and the existing link-check script works from the repository root. Which two additions to .github/copilot-instructions.md address this? (select two)

⬜ Document the link-check command and the folder it must be run from.
⬜ Tell the agent to run the check after documentation edits and report the result.
⬜ Record the maintainer’s passing run as the validation result for future changes.
⬜ Explain how to request review, leaving validation to the reviewer.
⬜ Tell the agent to judge link quality from its final summary instead of running the check.

A Copilot SDK application retrieves earlier documentation discussions from an external memory store, saving each message separately. Evaluation shows the agent keeps recalling an answer that recommends listing all internal endpoints, but misses the question that limited that advice to a private guide - so public guides get internal details. Which memory change should the team evaluate?

⬜ Store and retrieve each relevant question and its answer together as one memory unit.
⬜ Store only the assistant’s answers, so questions take up no retrieval context.
⬜ Sort individual answers by recency, keeping message-level units.
⬜ Compress each answer further before storing its embedding.

Evaluations show unnecessary bash attempts in Copilot CLI. Assuming --available-tools isn’t set, which option removes bash from the model’s choices while keeping edit and view?

⬜ --excluded-tools=bash
⬜ --deny-tool=shell
⬜ --available-tools=bash
⬜ --excluded-tools='bash,edit,view'

A team accepts an agent-generated change only after any new High-severity code security finding is resolved and the requested behavior is validated. Code scanning flags a High-severity issue in the changed code, while the functional tests pass. Which two statements interpret this evaluation correctly? (select two)

⬜ The alert is a security finding to investigate against the team’s unresolved-finding criterion.
⬜ The passing tests are functional evidence but don’t satisfy the separate security criterion.
⬜ The successful analysis run shows the detected security issue has been resolved.
⬜ The passing tests show the scanner’s finding is a false positive.
⬜ The High-severity finding shows the requested behavior failed its tests.

A completed dependency review comparison reports no known vulnerabilities in the dependencies added by an agent-generated pull request. What conclusion does that support?

⬜ No known vulnerability was reported for the added dependencies covered by that comparison.
⬜ No known vulnerability remains in any dependency already on the target branch.
⬜ The updated application keeps its expected behavior when the changed packages run.
⬜ The pull request contains no exposed credentials in its source or configuration.

An agent adds a working integration example that contains a real API token, and GitHub secret scanning reports the token as active. The agent then removes it from the latest version of the example, and the tests still pass. Acceptance requires that any credentials exposed by the change be secured. What should the evaluator record?

⬜ The criterion isn’t met until the exposed credential is revoked or rotated with its issuer.
⬜ The criterion is met, because the token no longer appears in the latest file.
⬜ The criterion is met, because passing tests show the integration still works.
⬜ The criterion isn’t met until dependency review reports no vulnerable package changes.

A team evaluates a Copilot CLI agent that writes a repository analysis report. Acceptance requires all requested findings and no more than 20 calls to the external analysis service per task. The report is correct, but the trace shows 28 successful service calls. How should this run be recorded?

⬜ The findings criterion passed, the call-budget criterion failed, and the task didn’t fully meet acceptance.
⬜ Both criteria passed, because every call succeeded and the findings are correct.
⬜ The findings criterion failed, because exceeding the budget makes the findings incorrect.
⬜ The task passed, because the call limit applies only to failed calls.

A team is investigating why validation of an agent’s Python change ended with a “missing test report” error. The GitHub Actions log shows dependency setup and file editing succeeded, then python -m py_compile services/catalog.py reported a syntax error on the line the agent edited. The test step was skipped, and the reporting step, which runs after failures, couldn’t find the test report. Which two conclusions follow? (select two)

⬜ The compile step shows the first failure, in the Python source the agent changed.
⬜ The missing report is a downstream symptom, because the test step never ran.
⬜ The reporting step caused the syntax error by failing to keep the test report.
⬜ The test step found a wrong catalog value while running an assertion.
⬜ Dependency setup failed before Python could check the edited file.

An agent gets a successful recursive GitHub Get a tree response with truncated: true, finds no deployment file in the returned entries, and concludes the repository has no deployment file. How should this failure be classified?

⬜ A reasoning error: the agent treated an explicitly incomplete result as proof that the file doesn’t exist anywhere.
⬜ An authorization failure: the truncation flag means the credential can’t read deployment files.
⬜ A transport failure: the response contains no usable data because the request didn’t finish.
⬜ An invalid-input failure: recursive tree requests can’t return a successful response.

A Copilot agent changes a pytest cart fixture to session scope, and tests that pass on their own start failing when run together. The workflow logs have been deleted, but a saved test report shows both tests expect an empty cart: the first adds an item, and the second receives the same cart with that item still in it before any application code runs. What explains the failure?

⬜ The fixture lets mutable state from one test leak into a later test that expects a fresh cart.
⬜ The application wrongly adds an item during the second test before its first operation.
⬜ The report lost the fixture results when the workflow logs were deleted.
⬜ Pytest stopped discovering the second test after the fixture scope changed.

Evaluations of Copilot cloud agent changes show it keeps missing a required catalog test. The relevant path-specific instruction file already matches the changed files, but its frontmatter has excludeAgent: "cloud-agent" and its body says only “Improve catalog quality.” The team wants both cloud agent and code review to get an actionable test requirement. Which two edits fix the gap? (select two)

⬜ Remove excludeAgent: "cloud-agent" so both Copilot features can use the file.
⬜ Replace the vague statement with the verified catalog-test command and when to run it.
⬜ Change the exclusion to excludeAgent: "code-review" so both features get the requirement.
⬜ Widen applyTo to "**" and leave the exclusion and body unchanged.
⬜ Add one evaluation run’s passing result as a permanent substitute for the test command.

A team evaluates the external memory retrieval layer of its Copilot SDK application. The relevant architecture decision is in the retrieved candidates, but loosely related notes fill the limited context sent to the agent and keep leading to wrong changes. The stored decisions are accurate, and the team wants to keep the current context size. Which retrieval change should it test first?

⬜ Rerank the retrieved candidates against the current task before choosing what to send.
⬜ Send more candidates in their current order by increasing the context size.
⬜ Delete the loosely related notes from storage, even though other tasks still need them.
⬜ Sort the same candidates by last access time before choosing what to send.

In an interactive Copilot TypeScript SDK application, evaluations show that a custom tool publishes without the required approval. The same tool also provides necessary read-only inspection. Which tool-policy change keeps inspection automatic and asks for approval before publishing?

⬜ Use onPreToolUse to inspect toolArgs, returning permissionDecision: "ask" for publishing and "allow" for inspection.
⬜ Use onPostToolUse to request review after publishing, keeping permissionDecision: "allow" in the pre-tool hook.
⬜ Use onPreToolUse to return permissionDecision: "deny" for every call to the tool, including inspection.
⬜ Use onSessionStart to add an approval reminder through additionalContext, keeping unconditional permission.

A team evaluates a Copilot agent that fixes small bugs. After an update, its logs show more tool calls per task, but reviewers accept a smaller share of its fixes. The team wants to know whether the agent is producing useful results. Which two signals should lead that assessment? (select two)

⬜ The share of attempted fixes that meet the documented acceptance criteria.
⬜ Reviewer findings about why fixes do or don’t solve the reported bugs.
⬜ The number of successful tool calls during each fix.
⬜ The number of commits the agent makes per bug.
⬜ The total number of lines the agent adds across its fixes.

Which code scanning evidence is most useful for assessing a claim that a CodeQL data-flow alert is a false positive because input is sanitized before it reaches the reported operation?

⬜ The source-to-sink paths and the relevant code, including the claimed sanitization on each reported path.
⬜ The latest analysis completion time and the name of the tool that raised the alert.
⬜ The alert’s security severity and how many open alerts are assigned to the same reviewer.
⬜ The file’s application-code category and the pull request’s total changed lines.

A team accepts an agent-generated report if its content is correct and the report-generation step finishes within two minutes, not counting setup or runner queue time. GitHub Actions shows four minutes waiting for a runner, one minute of setup and three minutes for the report-generation step. The content checks pass. Which timing result belongs in the acceptance scorecard?

⬜ Three minutes, which fails the limit for the report-generation step.
⬜ Eight minutes, which fails the limit for the whole workflow.
⬜ Four minutes, which fails the limit for setup plus report generation.
⬜ One minute, which passes, because setup is the measured execution.

An agent fixes a report that should list overdue orders. Its new test computes the expected list by calling the same filtering function the report uses, then compares the two. The test passes, but the reviewer needs evidence that the report follows the issue’s definition of “overdue.” How should the evaluation be strengthened?

⬜ Use a fixture whose expected overdue orders are worked out from the requirement, and compare the report with that list.
⬜ Run the same test many times, so a stable match proves the definition is followed.
⬜ Generate more fixtures, still using the report’s filtering function to compute every expected list.
⬜ Compare the run times of the report and the filtering function to confirm they process the same orders.

A team reviews a failed handoff between planning, implementation and test agents. The accepted plan requires a five-second request timeout, and the handoff contract defines timeout_ms in milliseconds. The implementation agent emits timeout_ms: 5. The test agent reads the field as documented, cancels the request after five milliseconds and reports that it didn’t complete. Which two conclusions identify the cause and its downstream effect? (select two)

⬜ The implementation handoff breaks the contract first, by putting a seconds value in a milliseconds field.
⬜ The test agent’s timeout is consistent with the value it received, and exposes the earlier unit mismatch.
⬜ The planning agent breaks the requirement first, by choosing a timeout shorter than five seconds.
⬜ The test agent breaks the contract first, by reading timeout_ms as milliseconds.
⬜ The request failure shows the environment couldn’t run the request at all.

How should you classify an MCP request rejected because a required argument is missing, compared with a valid shell request blocked by an explicit Copilot CLI deny rule?

⬜ The MCP request has a tool-input error; the shell request hits an authorization boundary.
⬜ The MCP request hits an authorization boundary; the shell request has a tool-input error.
⬜ Both show the tool implementation crashed during execution.
⬜ Both show the model was never given the tools.

A reviewer investigates a failing agent-generated search change. A pull request comment links an older report showing ModuleNotFoundError, but the saved report for the current failing run shows imports and test startup succeeded. In the empty-results test, the search function returns an empty list as required, and the agent-generated caller then raises IndexError at rows[0]. What explains the current failure?

⬜ The generated caller assumes a result exists and doesn’t handle the valid empty list.
⬜ The earlier missing-module problem still stops the tests from starting.
⬜ The search function breaks its contract, because a successful search must return at least one row.
⬜ The test fixture failed before the search function or caller could run.

An engineer evaluates a read-only repository audit in an interactive Copilot CLI session started with --allow-tool='shell(npm test)'. After the engineer used /allow-all, traces show the agent making unnecessary file edits. The engineer wants to withdraw that broad consent so edits need permission again, while keeping the test command pre-approved. Which two statements describe the right reset and its effect? (select two)

⬜ Use /reset-allowed-tools to withdraw the extra permissions granted during the session.
⬜ The startup allowance for shell(npm test) stays in effect after the reset.
⬜ The reset also removes the startup allowance, so the test command needs approval again.
⬜ Use /allow-all again to restore the original narrow permissions.
⬜ Add --deny-tool=shell at the next start to keep the test command while blocking edits.

A Copilot SDK application saves model-generated repository notes into long-term external memory after checking that each note has valid JSON fields. Repeated evaluations show that tentative claims from investigations get stored as facts and repeated in later tasks, even though repository evidence never supported them. Which change to the memory write process addresses this?

⬜ Check proposed facts against supporting evidence before admitting them to reusable memory.
⬜ Shorten memory retention while still admitting every schema-valid note.
⬜ Re-embed the existing notes so unsupported claims are retrieved more consistently.
⬜ Log every memory write after storage, keeping the same admission checks.

Evaluation shows that follow-up messages in a Copilot TypeScript SDK session miss changing project requirements. Which hook and output should the application use to add the current requirements before every message is processed, while keeping the submitted prompt as it is?

⬜ onUserPromptSubmitted returning additionalContext.
⬜ onSessionStart returning additionalContext.
⬜ onPostToolUse returning modifiedResult.
⬜ onSessionEnd returning sessionSummary.

A Copilot agent updates a diagnostic formatter to hide API tokens while keeping useful error details. The evaluation currently just counts exposed tokens, so an implementation that returns an empty string gets a perfect score. The task also requires non-secret diagnostic fields to stay unchanged. Which two assertions should define success for a fixture with both kinds of data? (select two)

⬜ The formatted result doesn’t contain the known token values from the fixture.
⬜ The formatted result keeps the fixture’s non-secret diagnostic fields and their values.
⬜ The formatted result has fewer characters than the original record.
⬜ The formatter performs at least one replacement while processing the fixture.
⬜ The formatter finishes without raising an exception.

How should an evaluation combine a high automated pass rate with reviewer reports that agent-generated code is hard to maintain?

⬜ Keep both signals, and check whether the automated checks cover the maintainability concerns reviewers raised.
⬜ Treat the pass rate as the quality verdict, and use reviewer reports only to measure satisfaction.
⬜ Replace the pass rate with the number of critical comments, so quality has one measure.
⬜ Run the same checks more often until their pass rate reflects maintainability.

To evaluate a Copilot change across two services, a workflow runs the same third-party scanner separately for each service. Both SARIF uploads use the same category, and GitHub rejects the duplicate analysis in that run. How should the team configure github/codeql-action/upload-sarif so both services’ findings can be reviewed?

⬜ Give each service’s upload its own category for the same commit.
⬜ Rename each SARIF file and keep the shared category.
⬜ Give each upload step a different name and keep the shared category.
⬜ Upload in separate runs and reuse the category for the same commit.

A Copilot pull request changes the checkout component. Its required checkout-test job looks successful in the merge checks, but opening it shows “This check was skipped” because its condition was false. Acceptance requires the checkout tests to actually run and pass for this change. What does the current result establish?

⬜ GitHub accepted the skipped job’s status, but the required checkout test run hasn’t been shown.
⬜ The checkout tests ran successfully, because required checks can’t succeed when their jobs are skipped.
⬜ The checkout tests took the passing result of another successful job in the workflow.
⬜ The false condition shows the checkout change is outside the acceptance criteria.

A team reviews two failed Copilot tasks. In a test-validation task, the agent rightly plans to run regression tests but runs pytest --collect-only and treats the list of collected tests as validation. In a repository-inspection task, the agent sends a correctly formed, authorized GitHub REST request that returns 403 with x-ratelimit-remaining: 0. Which two classifications fit? (select two)

⬜ The test task is tool misuse, because that pytest mode doesn’t run the planned tests.
⬜ The repository task hits an API rate limit, despite a valid request and authorization.
⬜ The test task is a missing-runtime failure, because pytest couldn’t start collecting tests.
⬜ The repository task has malformed input, because a 403 means an invalid parameter.
⬜ The repository task is a missing-permission failure, because the token can’t access the repository.

An MCP tool trace has a JSON-RPC result object with isError: true and a message saying the operation failed. What does that record show?

⬜ The tool reported an execution error in its result, even though a normal protocol response came back.
⬜ The operation succeeded, because the response has result rather than a JSON-RPC error object.
⬜ The request was rejected as an unknown tool with a protocol error before running.
⬜ The response describes a proposed operation and doesn’t contain an execution outcome.

A reporting agent passes a validation result to a review agent before the review agent assesses a pull request. Their agreed JSON contract says failed_tests must be an integer. The captured validator output has {"failed_tests": 0}, but the reporting agent serializes it as {"failed_tests": "0"}. The review agent rejects the payload during schema validation and never starts reviewing. Where does the failure originate?

⬜ In the reporting handoff, which turns the integer into a string and breaks the consumer’s input contract.
⬜ In the validator, which reports a count that can’t fit the agreed integer field.
⬜ In the review agent, which misreads a valid payload, since JSON treats "0" and 0 as the same type.
⬜ In the code review phase, which makes a reasoning error while examining the changes.

A team revises its Copilot cloud custom agent instructions after evaluations show generated clients keep skipping a required compatibility check. The new instructions name the check explicitly. Before adopting them, the team wants evidence that the change actually improves behavior on those tasks. Which two choices make the comparison useful? (select two)

⬜ Run both instruction versions on the same representative tasks, with the model and environment kept the same.
⬜ Compare actual compatibility-check runs and accepted results, using the same criteria for both versions.
⬜ Test the new version on simpler tasks and compare its success rate with the earlier failures.
⬜ Use a stronger model only for the new version, and credit the improvement to the instructions.
⬜ Treat the check’s name appearing in the new file as proof the agent now runs it.

A Copilot SDK application uses semantic search to retrieve past incident decisions from external memory. Evaluation shows good results for paraphrased descriptions, but tasks that include exact error identifiers often retrieve a similar incident and miss the decision for that identifier. The team must keep both kinds of lookup. Which retrieval change should it evaluate?

⬜ Combine keyword matching with semantic search and merge the ranked results.
⬜ Replace semantic search with keyword matching for all incident requests.
⬜ Shorten the retention period so fewer decisions are searchable.
⬜ Sort semantic results by recency, without adding identifier matching.

Copilot CLI evaluations still show unnecessary web_search calls after starting with --available-tools='bash,web_fetch,web_search' and --excluded-tools=web_search. Required test commands use bash, and supplied documentation URLs use web_fetch. Which change removes search as a choice while keeping the required tools?

⬜ Change --available-tools to 'bash,web_fetch'.
⬜ Change --excluded-tools to 'bash,web_search'.
⬜ Add --allow-tool='shell(npm test)' and keep both lists.
⬜ Change --available-tools to 'bash' and keep the exclusion.

Domain 5: Orchestrate multi-agent coordination (15–20%)

A team plans to use Copilot CLI /fleet for a dependency update and an unrelated spelling fix in a guide. A validation agent must test the finished dependency change, while the spelling fix can be made in a separate working tree. Which two scheduling choices keep useful parallelism and the validation dependency? (select two)

⬜ Start validation after the dependency agent finishes the change to be tested.
⬜ Run the independent spelling fix alongside the dependency update.
⬜ Run validation on the original checkout while the dependency update is being written.
⬜ Use autopilot mode to start all three tasks together despite the dependency.
⬜ Finish the spelling fix before starting the dependency update and validation.

Two GitHub Actions jobs run coding agents on self-hosted runners that share the same repository checkout. Their tasks change different components, but both stage files in that checkout, so one agent’s commit can include the other’s unfinished edits. Which arrangement lets them work in parallel without sharing files and the staging area?

⬜ Give each job its own Git worktree on its own task branch.
⬜ Give each job its own branch name while both keep using the shared checkout.
⬜ Give the jobs different display names while both keep staging in the shared checkout.
⬜ Lock the shared worktree and let both jobs keep editing in it.

A dependency agent will update package.json, while a refactoring agent will change application code and add a new script to package.json. They already have separate branches and worktrees. Before running them in parallel, the coordinator wants to avoid competing edits to the shared manifest while letting the refactor continue. What should it change?

⬜ Assign package.json to one agent, and send the other agent’s needed manifest change to that owner.
⬜ Keep both assignments and add the platform team as CODEOWNERS reviewers for the file.
⬜ Keep both assignments and give the branches more specific names.
⬜ Keep both assignments and run the jobs under different workflow names.

A workflow runs a compatibility agent and a documentation agent in parallel. Each produces a report that must stay separately attributable in pull request review, but both upload with actions/upload-artifact@v4 using the name agent-report. Which two changes keep both contributions and make them reviewable? (select two)

⬜ Give each artifact a distinct name that identifies its agent.
⬜ List each artifact’s URL beside its agent in the pull request’s evidence summary.
⬜ Keep the shared name and use different local report file names.
⬜ Run the uploads one after another so the second appends to the first artifact.
⬜ Keep the shared name and use different upload step names.

A multi-agent handoff record already names the sending agent, the receiving agent and the task. What information explains why the handoff was appropriate?

⬜ The task constraint that triggered the handoff, and how the receiving agent can address it
⬜ The agents’ start times and the number of tool calls before the handoff
⬜ The receiving agent’s available tools and the repositories it can access
⬜ The transferred file’s name and the workflow job that stored it

A maintainer investigates a compatibility check that was removed during work by a planning agent and an implementation agent. The planning session recommends removing it, and the removal commit links to an implementation session whose tool log records the edit. The same engineer started both sessions. Which attribution do these records support?

⬜ The planning agent proposed the removal, and the implementation agent made the edit.
⬜ The planning agent made the edit, because its recommendation came first.
⬜ The engineer made the edit, because they started both sessions.
⬜ The implementation agent originated the recommendation, because its session produced the commit.

A Copilot SDK coordinator tracks parallel test and documentation sub-agents. The test sub-agent emits subagent.failed with an error, while the documentation sub-agent has emitted subagent.started and keeps producing tool activity with no terminal event. Which two interpretations should the coordinator use? (select two)

⬜ The test invocation failed, so work that depends on it can’t treat it as finished successfully.
⬜ The documentation invocation is still running, so the test failure alone doesn’t justify replacing it.
⬜ The documentation invocation is complete, because subagent.started confirms it was accepted.
⬜ The test invocation returns to success when the runtime emits subagent.deselected.
⬜ Both invocations failed, because their events come through the same parent session.

A report-writing agent finishes and sends its result to a coordinator. A dispatch failure means the independent validation agent never receives the report, but the coordinator closes the parent task when the writer finishes. The publishing agent needs the validator to accept the report first. How should the coordinator recover?

⬜ Reopen the validation assignment with the existing report, and keep publication waiting for the validator’s result.
⬜ Reopen the writing assignment with the original prompt, and let the writer’s completion release publication again.
⬜ Reopen publication with the existing report, and make validation a follow-up after publishing.
⬜ Reopen both agents as writers of new reports, and publish when either finishes.

Two agents are preparing a coordinated API change. The contract agent waits for an example request from the client agent, while the client agent waits for the contract agent to finalize the request format. Restarting either one recreates the same wait, and neither owns the decision about which input comes first. What escalation lets the workflow recover?

⬜ Ask the workflow owner to resolve the circular dependency and assign the first input, using both agents’ waiting records.
⬜ Ask the contract agent’s operator to restart it, using its latest log as the request.
⬜ Ask the client agent’s operator to extend its waiting time, citing the missing contract.
⬜ Ask another client agent to create the example, with the same dependency on the final contract.

A specialist is added to a Copilot SDK workflow whose coordinator stays responsible for the final result. What should the integration contract specify?

⬜ The inputs it receives, the output expected from it, and how the coordinator validates and uses that output
⬜ The inputs, the expected output, and transfer of overall ownership when the specialist starts
⬜ The specialist’s prompt, its tools, and using the parent session as its shared working context
⬜ The specialist’s name and description, accepting its output whenever the SDK reports success

A team has moved a retiring Copilot cloud specialist’s future work to its replacement and kept the old pull request and decision records. It wants to keep the old profile file for reference but remove the specialist from the user picker and from automatic task selection. Which profile change does this?

⬜ Set disable-model-invocation: true and user-invocable: false.
⬜ Set disable-model-invocation: true and leave user-invocable unset.
⬜ Set user-invocable: false and leave disable-model-invocation unset.
⬜ Set tools: [] and leave both invocation settings unset.

A Copilot SDK application has a parent session that produces a combined repository assessment. Its dependency and API specialists have different prompts and tools, but both descriptions say “Reviews code” and both set infer to false. The team wants the runtime to delegate relevant parts of a request automatically while the parent combines the results. Which two changes support that? (select two)

⬜ Give each specialist a distinct description of its expertise.
⬜ Set infer to true on both specialists so the runtime can select them automatically.
⬜ Set the session’s agent property to the dependency specialist for every request.
⬜ Set each specialist’s tool list to null so both expose the same tools.
⬜ Change only displayName to descriptive labels, keeping the current descriptions and infer values.

A repository has two manually triggered workflows for agents that publish updates to release branches. Both run from main and get the target branch in inputs.release_branch. Their concurrency group includes github.workflow, so agents from different workflows can update the same target at the same time. Which shared group expression prevents that overlap but still lets different release branches run in parallel?

⬜ agent-release-${{ inputs.release_branch }}
⬜ ${{ github.workflow }}-${{ inputs.release_branch }}
⬜ agent-release-${{ github.run_id }}
⬜ agent-release-${{ github.ref }}

A team’s dispatcher sends every ready GitHub issue to both of its coding agents. Either agent can handle any issue, so they keep starting the same fix while other independent issues wait. The team wants one agent per issue and several issues progressing at once. How should dispatching change?

⬜ Assign each issue to one available agent and record that ownership before work starts.
⬜ Keep sending every issue to both agents and give each a separate branch.
⬜ Keep sending every issue to both agents and run them one after the other on each issue, without checking ownership.
⬜ Send all issues to one agent and leave the other idle until the queue is empty.

A Copilot TypeScript SDK application runs specialist agents in separate sessions and stores which role each session has. Their successful tool calls are logged only by tool name, so it’s hard to tell which agent produced a result when several use the same tool. Which two additions make each operation attributable? (select two)

⬜ Save invocation.sessionId with each tool audit entry and use the stored role mapping.
⬜ Record input.toolArgs and input.toolResult from onPostToolUse alongside input.toolName.
⬜ Group entries by input.workingDirectory and use that path as the agent’s identity.
⬜ Group entries by input.timestamp instead of keeping the session that produced each one.
⬜ Replace individual entries with each session’s total tool-call count at onSessionEnd.

When a coordinating agent hands full control of a multi-agent task to a specialist, how should the shared GitHub task record distinguish that from a request for the specialist’s advice?

⬜ Record the specialist as responsible for the rest of the task and identify the work transferred.
⬜ Keep the coordinator responsible for the rest of the task and list the specialist as a consultant.
⬜ Record the specialist’s advice as the final outcome and mark the original task complete.
⬜ List both agents as independently responsible for the same remaining work.

A finished multi-agent pull request uses request-local caching, although the planning agent first proposed a shared cache. The team wants to understand how the decision changed after a review agent assessed the proposal. Which evidence lets them reconstruct it?

⬜ The planner’s proposal, the review agent’s recorded objection, and the implementation session that applied the revised decision.
⬜ The final cache code, its passing tests, and the implementation session’s success status.
⬜ The latest agent summary, the current pull request description, and the final list of changed files.
⬜ The agents’ run durations, their tool-call counts, and the merge time.

A coordinator keeps routing compatibility checks to a specialist whose service is down. Nothing is still running on it, and a healthy standby can do the same check with the same input and output contract. Other agents are piling up waiting for the missing result. Which two changes should the coordinator make to restore progress? (select two)

⬜ Temporarily stop routing new checks to the failing specialist while its availability is reassessed.
⬜ Move the pending check and its current context to the standby, recording the standby as its owner.
⬜ Use the failing specialist’s result from an earlier task to satisfy the waiting agents.
⬜ Keep routing checks to the failed service and also give the pending check to every healthy agent.
⬜ Mark the pending check complete once the standby accepts it, and release the waiting agents.

An environment agent provisions a candidate preview service, and a routing agent then points the shared preview URL at it. Validation finds the candidate unusable, so the coordinator chooses the documented undo steps: point the URL back at the healthy previous service and remove the candidate. The URL would break if it pointed at a removed service. How should the agents recover?

⬜ The routing agent restores the previous target and verifies it, then the environment agent removes the candidate.
⬜ The environment agent removes the candidate and verifies it’s gone, then the routing agent restores the previous target.
⬜ Both agents start their undo steps together, and the URL is checked after both finish.
⬜ The environment agent removes the candidate, then the routing agent validates the unchanged URL.

After a coordinated release fails, a rollback agent proposes restoring the previous application version, while a data-repair agent proposes keeping the new version and repairing its records. Each plan relies on keeping a different data format, so combining them could leave the service inconsistent. The agents have shared their evidence but can’t agree which path preserves the required records. What should the coordinator do next?

⬜ Pause both recovery paths and have the incident owner choose one coordinated strategy from the proposals and evidence.
⬜ Run the rollback first and queue the data repair to run after it.
⬜ Run the data repair first and queue the rollback to run after it.
⬜ Send both proposals to separate workers and keep whichever finishes first.

Copilot cloud agent created a pull request before its custom agent profile was updated. Which profile version does it use for follow-up interactions on that pull request?

⬜ The profile version used for the task that created the pull request.
⬜ The newest version on the repository’s current default branch.
⬜ The newest version on the pull request’s current base branch.
⬜ The version most recently selected for any task in the repository.

A Copilot SDK workflow is adopting a shared analysis specialist whose published output groups findings by file. That contract is fixed for this release, and the downstream review agent must keep using a flat findings list without changes. The release must switch the review agent to the new specialist’s findings. Which migration keeps the handoff working without losing information?

⬜ Add a coordinator adapter that converts every finding into the flat format, validate the handoff, and switch production inputs to it.
⬜ Upgrade the review agent to accept grouped findings, validate the new contract, and release both agents together.
⬜ Reconfigure the shared specialist to produce the flat format, validate it against the review tests, and replace the old specialist.
⬜ Run the new specialist in shadow mode, compare both specialists’ findings, and keep the old output feeding the review agent.

A performance agent proposes caching every API response, while a privacy agent proposes turning caching off entirely. The task requires reusing public catalog responses and isolating customer-specific ones, so neither proposal meets the full requirement. The coordinator must reconcile them before assigning implementation. Which two actions support that arbitration? (select two)

⬜ Evaluate both proposals against the same public-response and customer-isolation criteria.
⬜ Have the integration owner ask for a revised design that satisfies both required behaviors.
⬜ Choose the proposal that arrived first, to give the implementation agent a stable direction.
⬜ Treat agreement from more performance agents as enough to choose the caching proposal.
⬜ Let both agents implement their proposals and use a clean Git merge to decide.

A Copilot SDK application runs coding sub-agents with separate prompts and restricted tools. Their shared application-defined editing tool writes to a single checkout, so concurrent calls overwrite each other’s changes. Which change creates the missing execution boundary while still allowing concurrent edits?

⬜ Make the editing handler write to a separate checkout for each agent.
⬜ Give each agent its own SDK session, keeping the handler’s checkout target unchanged.
⬜ Register a differently named editing tool for each agent, using the same handler and checkout.
⬜ Restrict each agent’s tools to the shared editing tool, leaving the handler unchanged.

Two agents each add a required export format to the same configuration list on separate branches: one adds CSV, the other PDF, and each branch passes its own format tests. When the coordinator combines them, Git reports a conflict because both replaced the same line. How should the integration owner resolve it and keep both outcomes?

⬜ Edit the conflict into a list that includes both formats, then validate the combined change before integrating.
⬜ Keep the CSV branch’s list, because its passing test shows the configuration is ready.
⬜ Keep the PDF branch’s list, because the later contribution should replace the earlier one.
⬜ Restore the original list and rerun both branch checks to show the conflict is resolved.

An implementation agent keeps reviving a shared-library change that a review agent rejected because it breaks another agent’s integration contract. The shared handoff still contains the proposed patch but not the review decision, so later agents treat the patch as ready to use. Which two additions make the handoff keep the decision and direct the remaining work? (select two)

⬜ Attach the review agent’s rejection, its integration-contract reason and the supporting evidence.
⬜ Record which agent must revise the proposal and which must check the replacement against the contract.
⬜ Mark the patch accepted, because it was created and uploaded as a workflow artifact.
⬜ Replace the rejection with the producer’s passing unit-test summary, so the handoff has one conclusion.
⬜ Give the contract revision to every downstream agent and let each interpret it their own way.

In GitHub enterprise audit log events for agents, how do the user and agent_session_id fields tell participants apart when one person starts work by several agents?

⬜ user identifies the person who started the work; agent_session_id identifies the session that generated the event.
⬜ user identifies the agent that ran; agent_session_id identifies the person who approved its result.
⬜ user identifies the final reviewer; agent_session_id identifies the repository the agents share.
⬜ user identifies the person who started the work; agent_session_id identifies the agent profile across all its sessions.

Each specialist in a multi-agent GitHub Actions workflow uploads its own attributed report for a later integration review. Earlier reports expired before that review, and a cleanup job also deletes completed workflow runs. The repository’s retention limit allows the required review period. Which change keeps all the agent evidence available until review?

⬜ Set each report’s retention-days to cover the review period, and keep its workflow run until the review ends.
⬜ Set each report’s retention-days to cover the review period, but keep deleting the run straight away.
⬜ Keep the workflow runs until review ends, but leave the shorter artifact retention unchanged.
⬜ Copy the artifact URLs into the pull request summary, and keep both the expiry and the run cleanup.

A coordinator needs a finished migration analysis and test cases for every agreed migration scenario before combining two agents’ work. The migration-analysis agent is still marked running past its agreed deadline, with no new progress or final answer. The test-design agent has stopped and returned test cases, explicitly listing agreed scenarios that still have no tests. Which two conclusions fit this evidence? (select two)

⬜ The migration assignment needs timeout or stall handling, although the record doesn’t show whether its process crashed.
⬜ The test-design result is partial, so the coordinator must record and resolve the missing coverage before treating it as complete.
⬜ The migration assignment is healthy, because its saved running state outweighs the missed deadline.
⬜ The test-design output is ready to combine, because a returned report shows its coverage is complete.
⬜ Both assignments can be classed as crashed, because neither has given a fully acceptable result.

A coordinator runs a maker-checker loop to revise an API proposal. The maker keeps switching between designs after the checker gives conflicting feedback, and the loop has hit its configured iteration limit without meeting the shared acceptance criteria. The workflow has a disagreement-resolution path for exactly this case. How should the coordinator handle the proposal?

⬜ Stop automatic revisions and send the unresolved alternatives and feedback through the disagreement-resolution path.
⬜ Raise the iteration limit and keep switching designs under the same criteria.
⬜ Start a fresh maker-checker pair with the same feedback and count it as a new task.
⬜ Pick the design that came up most often and report the checker’s job as complete.

Two Copilot analysis agents run in independent jobs of a manually triggered GitHub Actions workflow. The documentation agent finishes with an accepted report, while the compatibility agent fails because its external test service is down. The service is back, the inputs haven’t changed, and the accepted report is still available to a separate coordinator. Which GitHub CLI command recovers the missing result without repeating the accepted work?

⬜ gh run rerun --failed for the affected run.
⬜ gh run rerun --debug for the affected run.
⬜ gh run watch --compact for the affected run.
⬜ gh workflow run for the same workflow and inputs.

When replacing a Copilot SDK specialist that depends on a preloaded migration-checklist skill, which configuration keeps that startup context in the replacement?

⬜ List migration-checklist in the replacement’s skills, and keep it discoverable through the session-level skillDirectories.
⬜ Load migration-checklist into the parent agent and leave skills off the replacement so it inherits the context.
⬜ Keep migration-checklist in skillDirectories and leave skills off the replacement so discovery preloads it.
⬜ Mention migration-checklist in the replacement’s description and leave skills off so expertise matching loads it.

A scheduled GitHub Actions workflow runs a legacy Copilot CLI review agent and passes its assessment to a planning agent. The team has tested a replacement profile, release-review.agent.md, and confirmed its output meets the planning agent’s contract. Previous review evidence is kept. How should the team retire the legacy profile without leaving the scheduled workflow depending on it?

⬜ Update the default-branch command to --agent=release-review, verify the downstream handoff, then remove the legacy profile.
⬜ Change the legacy profile’s display name to release-review, keep the existing command, then remove the legacy profile.
⬜ Update the command on an unmerged migration branch, leave the default-branch workflow as is, then remove the legacy profile.
⬜ Change the workflow’s display name to release-review, keep the existing command, then remove the legacy profile.

A GitHub Actions workflow runs a documentation-review agent and an accessibility-review agent on the same unchanged UI. Each writes its own report, and report transfer is already set up. The synthesis agent must combine both successful reports, but it currently depends only on documentation_review. Which two dependency choices keep the reviews parallel and stop synthesis from starting with a report missing? (select two)

⬜ Set the synthesis job to needs: [documentation_review, accessibility_review].
⬜ Keep documentation_review and accessibility_review independent of each other.
⬜ Set accessibility_review to needs: documentation_review before synthesis.
⬜ Put all three jobs in one concurrency group instead of declaring dependencies.
⬜ Add if: always() to synthesis and keep its dependency on documentation_review only.

A workflow runs an implementation agent and an issue-reporting agent in separate jobs. The workflow grants contents: read. The implementation job explicitly grants contents: write, and the reporting job explicitly grants issues: write, but then fails to read the repository. The reporting agent needs to read the repository to write its issue comment, but mustn’t push code. Which permission change gives both roles the right access?

⬜ Add contents: read to the reporting job alongside issues: write.
⬜ Change the workflow-level contents permission from read to write.
⬜ Change the implementation job to contents: read instead of write.
⬜ Remove the reporting job’s permissions block so it uses the workflow default.

A coordinator assigned one agent to update an API schema and another to update its generated client. At integration, both agents submit schema changes on separate branches, and neither branch includes the client update. Both schema changes are usable alternatives. How should the integration owner keep valid work and finish the intended change?

⬜ Choose one schema result, record the other as duplicate work, and assign the missing client update based on the chosen schema.
⬜ Treat the second schema result as completing the client assignment, because it came from the client agent.
⬜ Combine both schema changes and use their separate successes to mark both assignments complete.
⬜ Discard both results and restart both assignments under their original labels.

A review agent combines reports from several specialist sessions into an integration assessment. The reports are already uploaded as separate GitHub Actions artifacts, but the assessment must record which session and code revision supplied each input, and whether the downloaded contents match the uploads. Which two records provide that? (select two)

⬜ A manifest mapping each input artifact to its producing agent session, workflow run and source commit.
⬜ The upload-versus-download digest comparison for each input artifact.
⬜ The review agent’s own session ID, recorded as the producer of every input.
⬜ The source commit’s Verified signature, as proof each downloaded report matches its upload.
⬜ The assessment’s successful workflow status, as proof of every input’s origin and contents.

A multi-agent workflow uses architecture decision records (ADRs) to track integration ownership. How should an accepted ownership change replace an earlier accepted decision while keeping the audit history?

⬜ Add a new accepted record for the new owner and scope, and link it to the earlier decision it supersedes.
⬜ Rewrite the earlier accepted record with the new owner and scope, keeping its original acceptance date.
⬜ Keep both records accepted as current, and let agents pick either one.
⬜ Put the new owner and scope in a private session message and leave the shared record unchanged.

A Copilot TypeScript SDK application runs several sub-agents in one parent session. Its audit export stores each event’s type, data and the parent session ID, so reviewers can’t tell sub-agent tool activity from parent activity. Which change restores the documented attribution?

⬜ Keep event.agentId when it’s present, and treat events without it as parent or session-level activity.
⬜ Read agentId from event.data, and treat a missing value there as parent activity.
⬜ Use the parent session ID as the producing agent for every event.
⬜ Keep event.agentId when present, and discard events without it as incomplete.

A schema agent produces a wrong API contract that both a client agent and a documentation agent use. The defect is caught before their outputs are published, and both outputs need regenerating. Two recovery coordinators notice the incident at the same time. Which two actions support consistent recovery? (select two)

⬜ Establish a single recovery owner for the affected work before either coordinator issues new assignments.
⬜ Hold the dependent outputs, fix and validate the contract, then regenerate both consumers from the corrected contract.
⬜ Have each coordinator immediately regenerate a different consumer from the stored contract.
⬜ Fix the contract and release the existing consumer outputs, because their runs already finished.
⬜ Regenerate both consumers first, then choose the corrected contract that best matches their new outputs.

A Copilot SDK coordinator asks a specialist both to write a migration proposal and to verify that it keeps existing clients working. The specialist emits subagent.completed, but its result says the proposal was saved and the compatibility check couldn’t be completed. A release-planning agent is waiting for the verified proposal. How should the coordinator classify this?

⬜ The invocation finished successfully, but the delegated work is partial and the release-planning dependency is still unmet.
⬜ The delegated work is complete, because subagent.completed means every acceptance condition passed.
⬜ The invocation failed at the SDK lifecycle level, because any unmet condition implies subagent.failed.
⬜ The delegated work is still running, because the unfinished check keeps the invocation active.

A coordinator crashes while agents prepare a client update. After restart, its durable records show an accepted API contract and a client implementation still owned by an active worker. The integration agent hasn’t started, because it needs that implementation. The coordinator’s in-memory assignment list is empty. How should it rebuild coordination before dispatching more work?

⬜ Restore the contract as complete, reconnect the implementation to its active owner, and keep integration waiting for it.
⬜ Restore the contract as complete, give the implementation to a new worker, and accept whichever result arrives first.
⬜ Recreate every assignment from the original request, and discard older results when the new ones finish.
⬜ Mark every assignment with an owner as complete, then start integration with the contract alone.

What is GitHub’s documented way to privately test an update to an existing organization custom agent before releasing it to all members?

⬜ Test the updated copy in .github/agents within .github-private, then merge its move to agents to release it to the organization.
⬜ Test the updated copy in agents within .github-private, then limit repository collaborators to keep it private until release.
⬜ Test the updated copy in .github/agents within .github-private, then change its display name to release it.
⬜ Test the updated copy in agents within .github-private, then move it into .github/agents to release it.

A repository’s default branch has a Copilot cloud profile, compatibility-review.agent.md, that overrides an organization profile with the same file name. The organization profile has been validated as the successor, and the team wants future tasks from that branch to use it, retiring the repository version. Which change does that while keeping earlier task records?

⬜ Remove the repository profile from the default branch, leaving the organization profile and earlier task records in place.
⬜ Change the repository profile’s display name to match the organization’s, keeping both files and the records.
⬜ Remove tools from the repository profile so it inherits the organization’s definition, keeping the records.
⬜ Keep the repository profile and add another organization profile with a different file name, keeping the records.

Domain 6: Implement guardrails and accountability (10–15%)

Which two properties support classifying an agent task that summarizes approved public documentation for an internal reader as lower risk than a task that changes a production system? (select two)

⬜ Its tools and credentials let it read the approved material without changing anything.
⬜ Its inputs are already public, and the summary stays within the approved audience and purpose.
⬜ Its output is shorter than the sources, so it needs less review.
⬜ Its activity log names the initiating user, so its effects equal a human-approved change.
⬜ Its output links to its sources, so the enabled tools don’t need reviewing.

A team wants Copilot cloud agent to investigate customer-reported failures through a new MCP integration. The tool can’t modify records, but it returns customer contact details and private support messages. An admin calls it low risk because its token only has read access. What should the team conclude?

⬜ The information exposure needs review before enabling it, because the agent can call configured tools without a separate approval prompt.
⬜ Read scope makes it low risk, because approving the final pull request also covers the earlier data retrieval.
⬜ It stays low risk, because Copilot asks for approval before each retrieval of private data.
⬜ It stays low risk if its activity is logged, because logging protects as well as limiting the data.

An agent prepares changes to a data-retention policy, and organizational policy reserves approval of those changes for the records owner. Which level of autonomy fits?

⬜ The agent can develop and validate proposals, but each change waits until the records owner authorizes it.
⬜ The agent can apply a proposal after technical validation, with the records owner reviewing afterward.
⬜ The agent can apply proposals once its general role is approved, needing new approval only after failed validation.
⬜ The agent can approve its own proposal with a second reasoning pass, sending the owner only the ones it can’t resolve.

An agent prepares a production release that passes all required automated checks. Its report shows deployment would interrupt a customer event, while postponing would leave a known service limitation in place. The service owner must decide. Which two responsibilities belong to this human decision? (select two)

⬜ Weigh the impact of the interruption on customers against the consequences of postponing.
⬜ Accept or reject the deployment based on the documented impact and alternatives.
⬜ Calculate whether the failed-test count exceeds the predefined threshold.
⬜ Generate a checksum for the release artifact.
⬜ Collect the check results into the standard release report.

A read-only analysis agent in GitHub Actions reads repository files and downloads earlier runs’ artifacts through the REST API in a private repository. It inherits contents: write and actions: write from the workflow, which a separate maintenance job needs. Which two permissions should the analysis job get for least privilege? (select two)

⬜ contents: read on the analysis job, for reading the repository
⬜ actions: read on the analysis job, for downloading artifacts
⬜ checks: read instead of any actions access
⬜ id-token: write instead of contents access
⬜ Keep contents: write and restrict merges with a ruleset

An agent-generated pull request has the required human approvals, but its security-policy check fails. An active ruleset on the target branch requires that check, and the maintainer merging it has no bypass permission. What happens?

⬜ The reviews meet the approval requirement, but the failing required check still blocks the merge.
⬜ The approvals override the failing check, because a maintainer is merging.
⬜ The check blocks merge commits, but a squash merge is allowed.
⬜ The merge is allowed once all conversations are resolved.

A public repository’s maintenance workflow has separate jobs for an irreversible database migration and a records purge, each using its own protected environment. The change owner has authorized the migration but deferred the purge, and both jobs are waiting for review. How do you approve only the migration?

⬜ In Review deployments, select only the migration’s environment and choose Approve and deploy.
⬜ In Review deployments, select both environments and explain in the comment that only the migration is authorized.
⬜ Approve the workflow’s source pull request and use that as authorization for both jobs.
⬜ Choose Start all waiting jobs, select both environments, and describe the limited authorization in the comment.

Which two considerations should decide whether a small agent-generated change to a GitHub Actions deployment workflow is riskier than a larger fix to public documentation? (select two)

⬜ The workflow change can increase the authority of credentials used by later jobs.
⬜ The workflow change can alter which production systems a later run modifies.
⬜ The deployment command is unchanged, so the workflow keeps its previously approved risk level.
⬜ The documentation fix touches more files, so it must have greater operational impact.
⬜ The workflow change passes a syntax check, so it carries the same risk as a documentation fix.

An internal agent triages public GitHub issues, but waiting for a person to approve every routine label has created a backlog. A tested controller restricts the agent to approved labels in one repository, records each change and sends ambiguous cases to a maintainer. These labels don’t trigger deployments or other automation. Which autonomy setting speeds up routine work within those limits?

⬜ Let the bounded label changes run automatically and keep ambiguous cases on the maintainer path.
⬜ Let the agent change labels and close issues automatically, using the activity record for later correction.
⬜ Let routine changes run after a maintainer approves each issue, with the controller picking the label afterwards.
⬜ Let the agent create new labels when needed, using the repository restriction as the approval boundary.

An autonomy policy requires both a release owner and a security owner to approve any agent-initiated production deployment. If both are listed as required reviewers on one GitHub Actions environment, what does that enforce?

⬜ Approval from either listed reviewer releases the job, so it doesn’t enforce the two-approval policy.
⬜ Approval from both reviewers is required, so it enforces the two-approval policy directly.
⬜ The release owner must approve first, then the security owner, in list order.
⬜ The workflow initiator’s approval counts as the release decision, leaving the security owner as the required reviewer.

A Copilot agent is preparing a cost-saving pull request for infra/, which CODEOWNERS assigns to the platform team. The team has authorized routine preparation and validation within existing requirements. Which two proposed actions need the platform owner’s judgment before the agent treats them as authorized? (select two)

⬜ Choosing a lower availability target when the savings conflict with the service’s current failover expectations.
⬜ Deciding whether the deployment identity should get broader production permissions for a new operational responsibility.
⬜ Validating resource configuration against the approved schema and reporting fields that violate it.
⬜ Applying the repository formatter to infrastructure files while confirming the parsed values don’t change.
⬜ Comparing recorded resource counts with the maximums already set in the approved deployment policy.

After a workflow cleanup, an agent’s pull request shows a successful check named dependency-audit, but merging waits for security-audit. The administrator confirms the unchanged audit job was renamed and the active ruleset still requires the old check name. Which two changes would each restore the enforced audit? (select two)

⬜ Replace security-audit in the required checks with the audit’s verified current name, dependency-audit.
⬜ Change the audit job’s check name back to security-audit and run it for the current change.
⬜ Rename the workflow file to security-audit.yml, keeping the job’s check name unchanged.
⬜ Set the workflow’s top-level name to security-audit, keeping the dependency-audit job name.
⬜ Turn off Require branches to be up to date before merging and keep the security-audit requirement.

A public repository stores a migration credential in a production environment that has no required reviewers. The agent-prepared migration job sets an ordinary variable TARGET_ENV: production but doesn’t reference a GitHub Actions environment. The team needs the job to wait for the data owner’s approval and then use that environment secret. Which configuration provides both?

⬜ Set environment: production on the migration job and add the data owner as a required reviewer for production.
⬜ Add the data owner as a required reviewer and keep TARGET_ENV as the job’s link to the environment.
⬜ Set environment: production on the job and rely on the stored secret to require the data owner’s approval.
⬜ Set environment: production on the job and restrict production to the protected release branch instead of a reviewer.

An agent-prepared documentation preview uses synthetic data and can’t affect production. Its workflow asks the same reviewer twice to approve the same preview artifact, with no change in evidence, scope or policy in between. The team requires one preview approval and a separate production release approval. Which revision removes the unnecessary interruption?

⬜ Keep one preview approval, remove the duplicate, and keep the separate production approval.
⬜ Combine preview and production approval into one decision before the preview is deployed.
⬜ Keep both preview approvals and count the second as the production approval.
⬜ Give the duplicate preview approval to another reviewer and keep both.

An agent’s validation command moves from an isolated test runner to a self-hosted runner that’s also used for production maintenance. Which two differences justify reassessing the action’s risk, even though the command is unchanged? (select two)

⬜ The new runner can reach production services the test runner couldn’t.
⬜ The new runner can expose leftover credentials or files from other work on the same machine.
⬜ The command text is identical, so its earlier classification carries over to the new runner.
⬜ The runner has a descriptive label, and the label establishes which side effects the command can have.
⬜ The workflow is in a private repository, so the host’s other capabilities no longer matter.

A team manually reviews every agent-generated documentation edit, because the same workflow could also change application code. A new controller now rejects edits outside docs/ before they’re applied, and testing confirms that boundary. A security owner must still approve changes to documented security guarantees. What change in autonomy does the new control support?

⬜ Allow routine documentation edits inside the enforced boundary, while keeping security-owner approval for changes to security guarantees.
⬜ Allow all documentation edits once they pass a link check, because the directory restriction also covers their security meaning.
⬜ Allow application edits after a successful documentation edit, because the controller builds trust in the agent’s later work.
⬜ Get security-owner approval once per documentation file, then allow later revisions without another security decision.

How should an autonomy assessment compare an MCP read that returns restricted customer records with a write that replaces disposable synthetic test data in an isolated sandbox?

⬜ The read may need stricter handling because it exposes restricted information, while the write has limited, recoverable effects.
⬜ The write needs stricter handling, because changing state is always riskier than reading, whatever the target.
⬜ The read needs lighter handling, because a read-only credential keeps customer data inside its source system.
⬜ Both need the same handling, because using the same MCP protocol gives them the same data and execution boundaries.

A repository uses a GitHub App to run an internal coding agent. An active ruleset requires a security check on main, yet the app merges a pull request while that check is failing. The app is listed as Always allow in the ruleset’s bypass list, and it must keep its ability to update working branches. Which two conclusions guide the fix? (select two)

⬜ The app’s bypass entry lets its merge skip the otherwise required security check.
⬜ Removing the app’s bypass entry makes its merges subject to the required check, while keeping its working-branch permissions.
⬜ Changing the bypass entry to For pull requests only makes the app satisfy every check when merging.
⬜ Adding another required security check to the same ruleset removes the app’s bypass.
⬜ Lowering the app’s contents permission to read keeps its branch updates and enforces the check.

Secret scanning finds a provider credential introduced by an agent’s pull request, in a repository with GitHub Secret Protection enabled. Human code review is done, but the security responder hasn’t finished the required remediation. The team wants GitHub to block merging until that response is recorded. Which two controls implement this? (select two)

⬜ Turn on a branch rule that requires secret scanning alerts to be resolved, including provider patterns, for the target branch.
⬜ Have the authorized responder review the remediation and close the blocking alert with a reason and a supporting comment.
⬜ Use the code scanning results rule for the branch instead of the secret scanning alert requirement.
⬜ Resolve the pull request’s review conversations, so the existing approval closes the secret scanning alert.
⬜ Disable the secret scanning merge rule once the tests pass, and leave the alert open for later.

A security review finds that an analysis agent’s GitHub Actions job has write-all access. In this private repository, the agent needs to read source files and publish its findings by creating check runs through the Checks API. It doesn’t change code or manage pull requests. Which permission block keeps that work with the least access?

⬜

permissions:
  contents: read
  checks: write

⬜

permissions:
  contents: write
  checks: read

⬜

permissions:
  contents: read
  statuses: write

⬜

permissions:
  contents: read
  pull-requests: write

An incident responder starts a recovery workflow that would rewrite protected production records. The public repository uses a recovery environment with required reviewers, Prevent self-review turned on and administrator bypass turned off. The responder is an administrator and a listed reviewer, but the recovery job is waiting. What authorization lets this run continue through its designated control path?

⬜ Approval of the recovery environment by another listed reviewer who didn’t start the run.
⬜ Approval by the responder, because administrator status overrides Prevent self-review.
⬜ A bypass by the responder using Start all waiting jobs for the recovery environment.
⬜ The responder’s earlier approval of the pull request that added the recovery script.

Which two proposed operations deserve a higher-risk assessment, even when assigned to a Copilot custom agent whose description calls it a read-only release reviewer? (select two)

⬜ Using a configured tool and credential to change the production service’s access policy.
⬜ Retrieving confidential release details through MCP to include in a public report.
⬜ Replacing disposable fixture files with synthetic data in an isolated checkout with no production access.
⬜ Running unit tests on synthetic data in a disposable environment with no production access.
⬜ Comparing two supplied public changelogs without changing files or contacting other systems.

An agent workflow checks dependency metadata, proposes updates through a pull request and, when a package is blocked, can ask to change the team’s dependency acceptance policy. The team wants routine preparation to run unattended, but the security owner keeps authority over policy exceptions. How should autonomy be assigned?

⬜ Authorize metadata checks and update proposals within the existing policy, and require security-owner approval before the policy changes.
⬜ Authorize the whole workflow when the task is assigned, treating a policy exception as part of finishing it.
⬜ Authorize policy changes once the proposed update passes tests, using test success as the security owner’s decision.
⬜ Require security-owner approval before metadata collection, and let that approval cover any later exception.

Which control set supports an agent that may prepare a report from an approved internal dataset, but must leave out personal identifiers and get the data owner’s approval before public release?

⬜ Limit access to the approved dataset, enforce an identifier-removal check, and gate publication on the data owner’s approval.
⬜ Limit access to the approved dataset, enforce a formatting check, and gate publication on the data owner’s approval.
⬜ Allow access to more internal datasets, enforce an identifier-removal check, and gate publication on the data owner’s approval.
⬜ Limit access to the approved dataset, enforce an identifier-removal check, and treat the original request as approval to publish.

A GitHub Actions workflow uses an agent to inspect contributor-supplied files and draft release notes. A separate publisher creates the GitHub release after approval. However, the inspection job currently has the publishing token, and its output provides a script for the publisher to run. Which two changes enforce the intended reader/publisher boundary? (select two)

⬜ Give the inspection job contents: read, and keep contents: write for the separate publishing job.
⬜ Use trusted publishing code that takes the release notes as data, instead of running scripts the agent supplies.
⬜ Keep the publishing token in the inspection job and add instructions limiting it to approved releases.
⬜ Move inspection and publishing into separate steps of one job with contents: write.
⬜ Give the inspection job checks: write instead of contents: read, keeping the script handoff.

A team lets Copilot CLI edit a service but forbids changing its release configuration during local execution. Separately, every proposed change must pass the security-policy check before merge. The CLI has an active command hook that can recognize the prohibited tool arguments. Which two controls enforce both stages of this policy? (select two)

⬜ Have preToolUse return permissionDecision: "deny" with a permissionDecisionReason when it detects a prohibited operation.
⬜ Require the security-policy check in an active ruleset on the target branch, with no bypass for the merging identity.
⬜ Use postToolUse to log a prohibited edit, and treat the log entry as preventing that edit.
⬜ Rely on the required pull request check to stop the local CLI from running a prohibited edit.
⬜ Return permissionDecision: "ask" for a prohibited operation, so an interactive approval can allow it.

A team proposes another approval gate for agent-generated releases, where a new reviewer confirms that security-policy is green, even though an active ruleset already blocks a failing result. The existing release owner reviews customer impact and authorizes production after validation. The new gate adds no other review duty. Which design keeps the required validation and human judgment with the least delay?

⬜ Keep the enforced security check and the release owner’s impact decision, without the extra check-confirmation gate.
⬜ Replace the enforced security check with the new reviewer’s confirmation, keeping the release owner’s decision.
⬜ Keep the extra gate and let its approval replace the release owner’s impact decision.
⬜ Keep the extra gate to create a second manual record of the same enforced result.

Maintainers merge an agent’s pull request that adds an irreversible production purge workflow. The workflow takes a required Boolean input named approved, and its purge job references the protected production environment. Policy requires the data owner to authorize each purge through that environment’s review. An operator starts a run with approved set to true. What has to happen before the purge is authorized?

⬜ The data owner must approve this run’s production environment review; neither the input nor the merged pull request is that decision.
⬜ The workflow can treat approved: true as the data owner’s authorization, because the input is required.
⬜ The workflow can reuse the pull request’s approving review, because it accepted the purge code.
⬜ The operator can rely on the allowed production branch as authorization, because its changes passed the merge controls.