draft module finetuning

Author: petender

learn-pr/wwl-azure/introduction-agentic-devops-microsoft-tools-azure/includes/2-define-agentic-devops-microsoft-environments.md

@@ -1,4 +1,4 @@
-Every experienced DevOps engineer has built automation that runs without human intervention. A pipeline triggers on push, a script rotates credentials on a schedule, a policy blocks a non-compliant resource at the control plane. These are deterministic: given the same input, they produce the same output, every time.
+As an experienced DevOps engineer, you've built automation that runs without human intervention. A pipeline triggers on push, a script rotates credentials on a schedule, a policy blocks a non-compliant resource at the control plane. These are deterministic: given the same input, they produce the same output, every time.
 
 Agentic capabilities are different. They don't execute a fixed script. They reason about a goal, gather context from multiple sources, decide which tools to use, and take a sequence of actions — adapting their next step based on what they observe. That reasoning loop is what distinguishes an agent from automation.
 
@@ -18,16 +18,16 @@ Traditional DevOps automation has goal orientation (pipelines have a target stat
 
 Microsoft has been building incremental agentic capabilities across its toolchain for several years. The progression is clearest in GitHub Copilot, which moved from a code completion tool to a chat assistant, then to agent mode, and now to a cloud-based coding agent that can take assigned tasks, open pull requests, and iterate on feedback without staying in your editor.
 
-You can observe a similar progression across the platform:
+A similar progression appears across the platform:
 
 | Capability family | How it behaves agentically |
 |---|---|
-| GitHub Copilot (chat and inline) | Responds to prompts; suggests code, explains errors, generates documentation. Single-turn or short multi-turn. |
+| GitHub Copilot (chat and inline) | Responds to prompts. Suggests code, explains errors, and generates documentation. Single-turn or short multi-turn. |
 | GitHub Copilot agent mode | Reads your full codebase context, executes multi-step tasks, invokes tools (terminal, file system, tests), and iterates. Multi-turn with tool use. |
-| GitHub Copilot coding agent (cloud) | Assigned issues from your backlog; operates autonomously to create a pull request; iterates on review comments. Asynchronous, repository-scoped. |
+| GitHub Copilot coding agent (cloud) | Receives assigned issues from your backlog, creates a pull request, and iterates on review comments. Asynchronous, repository-scoped. |
 | Azure Copilot agents | Specialized agents in the Azure portal for deployment, migration, observability, optimization, resiliency, and troubleshooting of Azure workloads. |
 | Azure DevOps AI capabilities | AI-assisted work item summaries, pull request descriptions, pipeline authoring suggestions, and Boards content generation — integrated into daily workflow surfaces. |
-| MCP-enabled tooling | Extensions to any of the above through the Model Context Protocol; gives agents access to additional tools (Azure CLI, ADO project context, Bicep analyzer) scoped by you. |
+| MCP-enabled tooling | Extensions to any of the above through the Model Context Protocol. Gives agents access to additional tools (Azure CLI, ADO project context, Bicep analyzer) scoped by you. |
 
 Rather than treating these as separate products to learn in isolation, think of them as different points on an autonomy spectrum. A Copilot suggestion is you driving with AI navigation. Agent mode is AI driving while you supervise. A platform-managed agent is AI driving on a closed course while you watch the dashcam.
 
@@ -47,9 +47,9 @@ This isn't a replacement for your automation. It's a different layer of the oper
 
 Agentic DevOps is the application of agent-based AI capabilities to DevOps workflows, where those capabilities handle tasks that require multi-source reasoning, produce structured outcomes that fit into existing delivery processes, and operate within human-defined boundaries.
 
-The goal isn't to remove DevOps engineers from the loop. It's to change *what* they're in the loop for. Instead of manually triaging a failing build by searching through five different log views, you describe the failure to an agent, which synthesizes the logs, cross-references similar past failures, and surfaces the probable root cause with supporting evidence. You still make the fix decision. You just spend less time on the search.
+The goal isn't to remove DevOps engineers from the loop. It's to change **what** they're in the loop for. Instead of manually triaging a failing build by searching through five different log views, you describe the failure to an agent, which synthesizes the logs, cross-references similar past failures, and surfaces the probable root cause with supporting evidence. You still make the fix decision. You just spend less time on the search.
 
 This distinction — AI doing the information-intensive groundwork, humans making the consequential decision — is the foundation of every concept in the rest of this module.
 
 > [!NOTE]
-> The capabilities described in this module represent the Microsoft platform as of early 2026. Specific feature availability may vary by plan, region, and product release cycle. Always verify capability status in official Microsoft documentation before designing production workflows.
+> The capabilities described in this module represent the Microsoft platform. Specific feature availability may vary by plan, region, and product release cycle. Always verify capability status in official Microsoft documentation before designing production workflows.

learn-pr/wwl-azure/introduction-agentic-devops-microsoft-tools-azure/includes/3-map-devops-work-agentic-opportunities.md

@@ -1,6 +1,6 @@
-You now have a working definition of agentic DevOps and understand what separates agents from automation. The next question is practical: *where in your daily work does agentic support actually matter?*
+You now have a working definition of agentic DevOps and understand what separates agents from automation. The next question is practical: **where in your daily work does agentic support actually matter?**
 
-Not every DevOps task is a good candidate. The tasks that yield the most value from agentic support share a consistent profile: they're frequent, they require pulling context from multiple sources, they produce structured outputs that feed into existing workflows, and they currently consume disproportionate time relative to the decision they enable. Mapping your work against that profile gives you a prioritized starting point.
+Not every DevOps task is a good candidate. The tasks that yield the most value share a consistent profile. They're frequent. They require pulling context from multiple sources. They produce structured outputs that feed into existing workflows. And they consume disproportionate time relative to the decision they enable. Mapping your work against that profile gives you a prioritized starting point.
 
 ## Map the DevOps lifecycle to agentic opportunities
 
@@ -10,15 +10,19 @@ The DevOps lifecycle gives you a natural frame for this mapping. Walk through ea
 
 Work item management looks simple on the surface, but it accumulates significant overhead: translating requirement documents into stories, tagging items with the right area paths, linking related work, estimating effort from description alone, and keeping descriptions current as design evolves.
 
-Azure DevOps Boards now includes AI-generated summaries for work items and sprints, helping teams quickly understand backlog state without reading every item in full. GitHub Copilot can generate work item descriptions from specification files, analyze PR history to surface related backlog items, and help triage incoming bugs by matching them against known patterns.
+Azure DevOps Boards now includes AI-generated summaries for work items and sprints, helping teams understand backlog state without reading every item in full. GitHub Copilot can generate work item descriptions from specification files, analyze PR history to surface related backlog items, and help triage incoming bugs by matching them against known patterns.
 
 For high-volume platform teams managing backlogs across multiple application teams, this phase-level support reduces the planning overhead that regularly delays sprint commitments.
 
 ### Code and review
 
 This is where GitHub Copilot's value is most widely understood — inline suggestions, code generation from natural language, and test scaffolding. But for experienced DevOps engineers, the highest-value use cases in this phase are different from those of application developers.
 
-Infrastructure-as-Code (IaC) authoring is a prime target. Generating Bicep templates from a resource architecture, converting ARM templates to Bicep, updating existing templates to reflect new naming conventions or policy requirements — these are context-rich, repetitive tasks that GitHub Copilot handles well while you review and approve the output.
+Infrastructure-as-Code (IaC) authoring is a prime target. These tasks are context-rich and repetitive. GitHub Copilot handles them well while you review and approve the output. Examples include generating Bicep templates from a resource architecture, converting ARM templates to Bicep, and updating existing templates to reflect new naming conventions or policy requirements.
+
+Dockerfile authoring follows the same pattern. Copilot generates a base image selection, layer ordering, and build-stage structure from a plain-language description of your app's runtime requirements. You review and adjust before committing.
+
+Azure DevOps or GitHub Actions YAML pipeline authoring is another strong fit. Describing a multi-stage pipeline in natural language and letting Copilot produce the initial YAML is faster than consulting reference documentation for every task and trigger syntax. It's especially useful when adapting an existing pipeline to a new environment or adding a new deployment stage. Or even migrating pipelines across DevOps platforms, becomes easier. 
 
 Code review preparation is another strong candidate. Before a PR review, GitHub Copilot can generate a structured description of the changes, highlight files that contain security-relevant modifications, and flag patterns that historically correlate with production incidents in your repository. This reduces the cognitive load of the reviewer without replacing their judgment.
 
@@ -34,15 +38,15 @@ The Azure DevOps MCP server extends this further by giving Copilot structured, r
 
 Change risk is where DevOps engineers spend significant judgment-intensive effort. Assessing whether a change is safe to deploy requires correlating the scope of code changes with the criticality of the deployment target, the current incident history, and any open policy exceptions.
 
-Azure Copilot's deployment agent assists with Azure resource deployments through natural language, cross-checking your intent against your subscription's Azure Policy baselines before execution. This doesn't replace change advisory board processes — it accelerates the groundwork those processes depend on.
+Azure Copilot's deployment agent assists with Azure resource deployments through natural language, generating Terraform configurations grounded in Azure Well-Architected Framework best practices for review before execution. <!-- [REVIEW: Official docs confirm WAF-grounded Terraform generation; a specific 'Azure Policy baseline cross-check before execution' capability is not documented for this agent as of early 2026. Verify and update if the feature ships.] --> This doesn't replace change advisory board processes — it accelerates the groundwork those processes depend on.
 
 IaC drift analysis is another high-value area. Running Bicep what-if or Terraform plan is standard practice, but interpreting those results across a large resource footprint and deciding which drift is acceptable and which represents a compliance risk is time-consuming. Agents can synthesize drift analysis results with policy documentation and surface the items that require human decision-making.
 
 ### Operate and monitor
 
 Azure Copilot's observability, resiliency, and troubleshooting agents target the operational half of the DevOps loop directly. For teams that both build and run their Azure workloads, these agents reduce the time between "alert fires" and "root cause identified."
 
-The observability agent pulls in metrics, logs, and dependency maps to provide a synthesis of what changed before an incident. The troubleshooting agent walks through diagnostic steps for common Azure resource issues. The resiliency agent assesses your deployed architecture against Well-Architected reliability patterns and surfaces actionable gaps.
+The observability agent pulls in metrics, logs, and dependency maps to provide a synthesis of what changed before an incident. The troubleshooting agent walks through diagnostic steps for common Azure resource issues. The resiliency agent assesses your deployed resources for zone redundancy gaps, missing backup policies, and recovery configuration issues, then surfaces actionable recommendations. <!-- [REVIEW: Official docs describe the resiliency agent in terms of zone resiliency, Azure Backup, Site Recovery, and outage resilience — not explicitly 'Well-Architected reliability patterns'. Revise if documentation is updated to include that framing.] -->
 
 For platform engineering teams, the optimization agent is particularly useful: it cross-references your resource utilization data with Azure Advisor recommendations and generates prioritized action lists that map to your team's cost and reliability objectives.
 

learn-pr/wwl-azure/introduction-agentic-devops-microsoft-tools-azure/includes/4-set-autonomy-boundaries-human-control.md

@@ -8,10 +8,10 @@ Not all agentic actions carry the same operational weight. A useful way to class
 
 | Autonomy level | Agent behavior | Human role | Examples |
 |---|---|---|---|
-| **Inform** | Generates findings or recommendations without taking action | Review and decide to act | Summarize PR changes; list work items matching a query; explain a build failure |
-| **Suggest** | Proposes a specific action with justification | Approve or modify before execution | Propose a Bicep change; suggest a pipeline fix; recommend alert threshold adjustments |
-| **Execute on approval** | Prepares execution plan and waits for explicit confirmation | Review plan and authorize each step | Create a work item; update a variable group; generate and apply IaC changes to a non-production environment |
-| **Execute autonomously** | Takes action through the full sequence without per-step confirmation | Define scope, monitor outcomes, receive summary | Assign and triage incoming bug reports; run read-only API queries; generate unit tests for new functions |
+| **Inform** | Generates findings or recommendations without taking action | Review and decide to act | Summarize PR changes, list work items matching a query, and explain a build failure |
+| **Suggest** | Proposes a specific action with justification | Approve or modify before execution | Propose a Bicep change, suggest a pipeline fix, and recommend alert threshold adjustments |
+| **Execute on approval** | Prepares execution plan and waits for explicit confirmation | Review plan and authorize each step | Create a work item, update a variable group, and generate and apply IaC changes to a non-production environment |
+| **Execute autonomously** | Takes action through the full sequence without per-step confirmation | Define scope, monitor outcomes, and receive summary | Assign and triage incoming bug reports, run read-only API queries, and generate unit tests for new functions |
 
 Most of your day-to-day agentic operations will sit at **Inform** and **Suggest** for the first months. That's not a limitation — it's appropriate calibration while you build confidence in agent behavior and develop the observability instrumentation to audit what agents do.
 
@@ -40,7 +40,7 @@ Human control points are the specific moments in a workflow where agent executio
 
 For DevOps engineers on Azure, several operations require hard human control points:
 
-- **Production environment deployments** — any agent-initiated resource change in a production subscription must transit an approval gate. This isn't a maturity question; it's a change management and compliance requirement in most regulated environments.
+- **Production environment deployments** — any agent-initiated resource change in a production subscription must transit an approval gate. This isn't a maturity question. It's a change management and compliance requirement in most regulated environments.
 - **Secret and credential operations** — agent actions that read from or write to Azure Key Vault should require explicit approval and create an audit log entry. Even read access to secrets should be scoped tightly.
 - **Pipeline configuration changes** — modifications to pipeline YAML, variable groups, or service connections in production branches must follow your existing branch protection and PR review policies. Agents should not bypass these controls.
 - **Security group and RBAC modifications** — role assignment changes and network security group rule additions must be human-authorized regardless of the principal making the change.
@@ -52,7 +52,7 @@ These aren't arbitrary restrictions. They map to the areas where audit regulator
 
 When agents invoke tools — Azure CLI, ADO REST APIs, Bicep deployments — they authenticate with an identity. That identity must follow least-privilege: the minimum permissions needed to complete the authorized scope of the agent's work.
 
-For GitHub Copilot agent mode and coding agents, the tool invocations execute in the context of your local or codespace session. Scope is bounded naturally by your own access. For platform-managed agents like Azure Copilot agents, review the managed identity or service principal they use and audit its RBAC role assignments regularly.
+For GitHub Copilot agent mode, tool invocations execute in the context of your local or codespace session, where scope is bounded naturally by your own access. For the cloud-based GitHub Copilot coding agent, execution happens in a GitHub Actions sandbox environment using a managed identity with federated credentials — not in your local session. Review the role assignments granted to that managed identity and treat them with the same scrutiny you apply to any service principal used in your deployment workflows. For platform-managed agents like Azure Copilot agents, review the managed identity or service principal they use and audit its RBAC role assignments regularly.
 
 For MCP-based extensions — where you explicitly give a Copilot session access to Azure CLI tools or ADO project APIs — define exactly which tools you expose and ensure the underlying service connection has read-only scope unless write access is specifically required for the task.