Microsoft Developing in Agentic AI Systems (GH-600)

Rationale for Selections:

The technical requirements for agent2 state that it must be able to "analyze the code base and the code requirements" but "must NOT be able to edit files or run local commands." To fulfill these requirements, the agent needs specific tools with read-only capabilities.

1. First Box: 'search'
   The search tool is required for the agent to effectively find relevant files and code snippets within the repository. This capability is essential for the analysis phase of its task.
2. Second Box: 'read'
   The read tool allows the agent to access and understand the content of files it locates via search or direct reference. This is fundamental to analyzing the existing code and requirements to formulate an implementation plan.

The tools edit and execute are explicitly forbidden by the requirements, making them incorrect choices.

Reference: https://docs.github.com/en/copilot/github-copilot-workspace/using-github-copilot-workspace/configuring-github-copilot-workspace-agents

To verify each individual upgrade step and whether all tests have passed, the tasks.md file should be used. In agentic workflows, especially for complex operations like application upgrades, the tasks.md file provides a detailed breakdown of the work performed, individual steps taken, their status, and associated verification results, including test outcomes. This file allows for granular tracking and auditing of the agent's progress.

Solution Walkthrough

This solution configures GitHub Actions permissions according to the principle of least privilege, meeting all specified requirements.

✅ **Step 1: `permissions: read-all`** matches with -> **Workflow-level `permissions` block**

Reasoning: The primary requirement is to set the default permissions for the workflow's `GITHUB_TOKEN` to be read-only. Placing `permissions: read-all` at the top level of the workflow establishes a secure baseline. All jobs, including the `analyze` job, will inherit these read-only permissions, preventing any unintended write operations.

✅ **Step 2: `contents: write`** matches with -> **`permissions` block in the `update_artifacts` job**

Reasoning: The `update_artifacts` job needs to perform write operations. Specifically, the "Update generated artifacts" step implies modifying and pushing files to the repository. This action requires overriding the workflow's read-only default by explicitly granting `contents: write` permission at the job level.

✅ **Step 3: `pull-requests: write`** matches with -> **Empty box in the `Create pull request` step**

Reasoning: In addition to updating files, the `update_artifacts` job must create a pull request. This requires the `pull-requests: write` permission. Although the box's placement within the step is syntactically incorrect in standard YAML, it logically represents the permission needed for that specific action. Permissions are scoped to the job, so this permission is granted to the `update_artifacts` job's `GITHUB_TOKEN`.

Reference: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

✅ Step 1: 'Use the upload-artifact action and configure artifact retention in the CI workflow.' matches with -> 'Create durable run outputs that are downloadable after completion:' Reasoning: The actions/upload-artifact is the standard GitHub Actions mechanism to persist files generated during a workflow. These artifacts are stored for a configured duration and can be downloaded from the workflow summary, directly fulfilling the need for durable, downloadable outputs.

✅ Step 2: 'Watch for pull request body updates and pull request timeline events.' matches with -> 'Provide ongoing, human-reviewable task progress signals inside the pull request:' Reasoning: An agent can use the GitHub API to update the pull request's description or post comments. This creates an auditable trail of its actions and progress directly within the UI that reviewers use, providing ongoing, human-reviewable signals.

✅ Step 3: 'Select View session to stream live agent logs.' matches with -> 'Provide a real-time view of agent actions for audit and troubleshooting:' Reasoning: Streaming live logs is the definition of a real-time view. This capability allows developers to monitor the agent's operations as they happen, which is essential for immediate debugging, troubleshooting, and auditing its behavior during execution.

Reference: https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts

This question requires matching GitHub Copilot for Pull Requests signals to their corresponding execution contexts.

✅ Step 1: "The agent acknowledges the assignment and will create the draft pull request." matches with -> "The eyes emoji (👀) reaction appears on the issue:" Reasoning: When GitHub Copilot is assigned an issue (e.g., via /copilot fix), it adds an eyes emoji (👀) reaction. This is the standard, documented signal that the agent has acknowledged the task and is about to begin its work.

✅ Step 2: "The agent session is actively running and generating live logs." matches with -> "The pull request timeline shows Copilot started work:" Reasoning: Once Copilot creates the draft pull request, the PR timeline will show an event indicating that it has started work. This signifies the active phase where the agent is analyzing the issue, generating code, and pushing commits. This is the main working state of the agent.

✅ Step 3: "A human must manually approve and run the workflows." matches with -> "A draft pull request exists, but GitHub Actions checks are not running:" Reasoning: A common security configuration in GitHub requires that workflows triggered by first-time contributors or bots like Copilot be manually approved by a maintainer before running. This prevents potentially malicious code from accessing repository secrets. A created PR with pending checks is the classic indicator of this state.

Reference: https://docs.github.com/en/copilot/github-copilot-enterprise/copilot-in-github/using-github-copilot-with-github-issues#giving-feedback-on-github-copilot-in-issues

✅ Option C (Correct)

Reasoning: The errorOccurred hook is specifically designed to trigger whenever an error or failure happens during the agent's execution. This directly matches the requirement to run a command automatically when an agent execution fails.

❌ Why the other choices are incorrect:

• Option A is incorrect: postToolUse triggers after a tool completes its execution, not necessarily when the overall agent execution fails.
• Option B is incorrect: sessionEnd fires at the conclusion of an agent session, whether it succeeded, failed, or was terminated, making it too broad.
• Option D is incorrect: agentStop is also a general termination event, not exclusively tied to failures, similar to sessionEnd.

To review and agree on the approach before Copilot makes changes, you should first switch to plan mode. Copilot CLI's plan mode is specifically designed for iterating on a task's approach, allowing you to discuss and refine the strategy with Copilot before any commands are executed or code is modified. This ensures alignment and understanding of the planned refactoring. The other options either bypass this review or serve different purposes.

✅ Option C (Correct)Reasoning: A vague one-line description like "Fix the login bug" lacks the necessary context for an AI agent to accurately determine the problem's scope and required changes. Providing a clear, detailed problem description is crucial for GitHub Copilot to understand the issue thoroughly and generate an accurate, complete pull request.
❌ Why the other choices are incorrect:

• Option A is incorrect: Copilot memory assists in retaining context across interactions, but it doesn't compensate for an initially vague or incomplete task description. The fundamental problem is the input quality.
• Option B is incorrect: Model Context Protocol (MCP) server rate limits concern the frequency of requests, not the quality or accuracy of the code generated based on the input description.
• Option D is incorrect: Allocating resources to a setup file (copilot-setup-steps.yml) is unrelated to the agent's ability to interpret an issue description and generate correct, scoped code changes.

✅ Option D (Add the mcp-servers property to the agent configuration) is correct.The planned changes explicitly state: "Configure MCP1 as a tool for agent1 by modifying the product-api repository MCP configuration." The mcp-servers property is the dedicated configuration section for defining Model Context Protocol (MCP) servers as tools for the Copilot agent. Adding this property with the details of MCP1 directly fulfills this requirement. While the agent also needs to access "all the tools in the environment," configuring the custom MCP1 server is a specific and necessary step for a unique internal API tool, and mcp-servers is the correct mechanism for this.

❌ Why the other choices are incorrect:

• Option A is incorrect: Deleting line 05 (tools:) would remove the explicit list of allowed tools. This might enable default tools, but it would not configure the custom MCP1 server as a tool, which requires the mcp-servers property.
• Option B is incorrect: Adding instructions to the general .github/copilot-instructions.md file would affect Copilot Chat and Copilot code review, violating the requirement to provide specific instructions without affecting these features. More importantly, it's an instruction, not a configuration mechanism for tools.
• Option C is incorrect: Adding instructions to the agent's configuration is an instruction, not a declarative configuration for tool access. The agent requires explicit configuration for tool enablement, especially for custom MCP servers.
• Option E is incorrect: Replacing line 05 with tools: [] would explicitly configure the agent to have no tools, directly contradicting the requirement to ensure it can access all tools in the environment, and specifically MCP1.

✅ Option B (Correct)

Reasoning: Storing the API key as a secret in the Copilot environment, using a specific prefix like COPILOT_MCP_, and referencing it in the mcp.json configuration is the secure and intended method for Copilot agents to access tool credentials. This aligns with secure practices for GitHub and ensures the agent can securely authenticate to MCP1.

❌ Why the other choices are incorrect:

• Option A is incorrect: GitHub Codespaces user secrets are designed for individual user environments, not for automated agents or shared repository configurations, making them unsuitable for agent1.
• Option C is incorrect: Adding the API key directly in plaintext to a file (.mcp/server.json) is a critical security vulnerability and violates the requirement that API keys must be stored and accessed securely.
• Option D is incorrect: While GitHub Actions encrypted secrets are secure, the method of referencing them via ${{ secrets.KEY }} is specific to GitHub Actions workflow YAML files. For a Copilot coding agent configuring an MCP tool via mcp.json, the approach described in option B is typically the more integrated and direct mechanism for the agent's environment to consume such secrets.