CertifyDeck
Empieza gratis
Todos los resúmenes
AZ-401 · CHEAT SHEET

Microsoft Certified: Agentic DevOps Engineer Expert

Conceptos clave agrupados según el peso oficial del examen.

Descargar en PDF (gratis, sin registro)

1. Design and implement processes and communications

15–20%

Design traceability and flow of work

  • Diseña el flujo de trabajo enlazando fases: planifica en Azure Boards o GitHub Projects (columnas, columnas divididas, límites WIP y definición de terminado), compila con vinculación automática de elementos a compilaciones, despliega con entornos que registran historial y elementos desplegados, y opera creando elementos de trabajo desde Application Insights con su contexto.
  • Los ciclos de comentarios en Azure DevOps se basan en suscripciones: personales, de equipo, de proyecto o globales, entregadas por correo o mediante enlaces de servicio a servicios externos como Teams, Service Bus o Datadog. La entrega por rol limita los avisos a los implicados y Skip initiator evita avisar a quien hizo el cambio. En GitHub Actions, las notificaciones de flujos programados siguen a su creador o a quien los rehabilita.
  • Elige el proceso según el equipo: Basic (épicas, incidencias, tareas), Agile (historias de usuario), Scrum (elementos del backlog con estados Approved y Committed) o CMMI (control de cambios, riesgos y revisiones). Organiza el trabajo con rutas de área por equipo o componente, que también restringen el acceso, y rutas de iteración por sprint, y usa planes de entrega para ver varios equipos y sus dependencias en un calendario.
  • La trazabilidad une elementos de trabajo con ramas, commits, solicitudes de incorporación de cambios, compilaciones, versiones y pruebas. En Azure Repos, la directiva Check for linked work items exige vínculos; con GitHub, AB# en commits o descripciones vincula y, con fixes, cambia el estado al combinar en la rama predeterminada. Los conjuntos de pruebas basados en requisitos y los informes de trazabilidad miden la calidad de cada requisito.

Design and implement success metrics for DevOps

  • Convierte cada KPI en una métrica medible: tiempo de entrega (de la creación a Completed) para compromisos con clientes, tiempo de ciclo y diagrama de flujo acumulado para eficiencia y cuellos de botella, informes de tasa de éxito, duración y fallos de pruebas para la calidad de la entrega, y la información general de seguridad de GitHub (Coverage, Remediation) para la seguridad, con el registro de auditoría para datos de cumplimiento.
  • Con Azure DevOps MCP Server en modo agente, un asistente traduce preguntas en lenguaje natural a consultas WIQL y llamadas a herramientas sobre elementos, compilaciones y pruebas. Analytics expone OData (LeadTimeDays y CycleTimeDays solo para elementos completados) para Power BI. Azure Copilot genera KQL de ejemplo para registros de Azure Monitor, y las métricas de uso de Copilot miden la adopción de la IA.

Configure collaboration and communication

  • Documenta el proyecto con wikis de Azure DevOps (wiki de proyecto o código publicado como wiki, sincronizado con la rama), README en .github, raíz o docs, notas de versión generadas y configuradas en .github/release.yml, un archivo LICENSE y CODEOWNERS, donde gana el último patrón coincidente. Mermaid dibuja diagramas de proceso, y Copilot redacta resúmenes de solicitudes de incorporación de cambios partiendo de una descripción vacía.
  • Define requisitos para agentes con instrucciones en .github/copilot-instructions.md, archivos .instructions.md con applyTo y AGENTS.md; habilidades en .github/skills con SKILL.md; y agentes personalizados cuyo campo tools limita herramientas. Copilot cloud agent solo inserta en su rama copilot/ y no aprueba sus solicitudes. Los flujos agénticos programados se ejecutan con permisos de lectura y escriben solo mediante safe-outputs.
  • Azure DevOps MCP Server puede ser remoto (https://mcp.dev.azure.com/{organización}, HTTP y Entra ID), filtrado con X-MCP-Toolsets, X-MCP-Tools o X-MCP-Readonly, o local (stdio, PAT o Entra ID). El servidor MCP de GitHub remoto usa OAuth o PAT. Para Copilot cloud agent, el JSON del repositorio solo admite herramientas, usa secretos COPILOT_MCP_ y el servidor de GitHub integrado lee solo el repositorio actual.
  • Los webhooks de GitHub y los enlaces de servicio de Azure DevOps envían eventos (push, revisiones, elementos de trabajo) a sistemas externos sin sondeo. Los servidores MCP dan herramientas a Copilot: en Copilot cloud agent se configuran en el repositorio y leen secretos de Agents con prefijo COPILOT_MCP_. Las skills son carpetas con SKILL.md (name y description) en .github/skills.
  • El servidor MCP de Azure DevOps da a los asistentes de IA en modo agente acceso a elementos de trabajo, solicitudes de cambios y canalizaciones. La versión remota (https://mcp.dev.azure.com/{org}) requiere Microsoft Entra; la local usa npx y stdio. Los encabezados X-MCP-Toolsets y X-MCP-Readonly limitan sus herramientas, y desde Azure Boards se puede iniciar Copilot en repositorios de GitHub.

2. Design and implement a source control strategy

10–15%

Design and implement branching strategies for Azure DevOps and GitHub

  • Microsoft recomienda ramas de características breves combinadas en main mediante solicitudes de cambios y una rama main siempre estable (enfoque basado en tronco). Las ramas de versión se crean desde main, no se combinan de vuelta y reciben correcciones con cherry-pick. GitHub flow elimina la rama tras combinarla, y git worktree permite trabajar en varias ramas a la vez sobre un mismo repositorio.
  • En Azure Repos, las directivas de rama exigen revisores mínimos, validación de compilación con caducidad configurable, vínculos a elementos de trabajo y revisores automáticos con filtros de ruta. En GitHub, las reglas de protección y los conjuntos de reglas exigen solicitudes de cambios aprobadas, revisión de propietarios de código, descarte de aprobaciones obsoletas y resolución de conversaciones.
  • Azure Repos limita los tipos de combinación (básica, squash, rebase con avance rápido, rebase con commit de combinación) y permite insertar directamente solo si no hay directivas obligatorias. GitHub ofrece historial lineal, firma de commits, cola de combinación, despliegues obligatorios y bloqueo de rama; varios conjuntos de reglas se suman y prevalece la regla más restrictiva.
  • Copilot cloud agent solo inserta en su rama copilot/ y respeta las protecciones de rama y las comprobaciones obligatorias; si un conjunto de reglas lo bloquea, se le añade como actor con omisión. No puede aprobar ni combinar sus solicitudes, quien se la pidió no puede aprobarla y los flujos de trabajo esperan a que alguien con acceso de escritura los apruebe.

Configure and manage repositories for Azure DevOps and GitHub

  • En Azure Repos, los permisos se asignan en All Repositories, en cada repositorio o en cada rama; Deny prevalece sobre Allow y Not set hereda. Bypass policies when completing pull requests y Bypass policies when pushing separan omitir directivas al completar o al insertar. En GitHub, los roles Read, Triage, Write, Maintain y Admin escalan el acceso; solo Admin gestiona reglas de rama.
  • Git admite etiquetas ligeras (solo un nombre) y anotadas (autor, fecha y mensaje, pensadas para versiones). Azure Repos crea etiquetas anotadas desde el portal, y eliminarlas exige el permiso Force push. Las etiquetas no desencadenan Azure Pipelines salvo que se configure trigger: tags, y en GitHub Actions on.push.tags filtra por nombre de etiqueta; los conjuntos de reglas también protegen etiquetas.
  • La trazabilidad une código y trabajo: en GitHub, las menciones AB# vinculan commits y solicitudes con Azure Boards, y palabras como Fixes cierran incidencias al combinar en la rama predeterminada. Azure Repos puede exigir elementos vinculados y, con una directiva sobre el estado de cobertura, cobertura mínima; GitHub Code Quality bloquea solicitudes con conjuntos de reglas de calidad.
  • Los hooks de Git son scripts ejecutables en .git/hooks (o en la ruta de core.hooksPath) que se disparan en puntos como pre-commit, commit-msg o pre-push; un estado distinto de cero cancela la operación. Los hooks del cliente no se copian al clonar y --no-verify omite pre-commit, commit-msg y pre-push, por lo que las directivas obligatorias deben aplicarse también en el servidor.
  • GitHub Enterprise Importer, mediante la extensión gh ado2gh y tokens en GH_PAT y ADO_PAT, migra desde Azure DevOps Cloud (no desde Server) el código Git, las solicitudes de incorporación de cambios y las directivas de rama, pero no los objetos LFS. Conviene hacer una migración de prueba, detener el trabajo durante la real y, después, revisar el registro, ajustar la visibilidad y reclamar los maniquíes.

3. Design and implement build and release pipelines

35–40%

Design and implement a package management strategy

  • Azure Artifacts ofrece fuentes con ámbito de proyecto u organización para NuGet, npm, Maven, Python, Cargo y Universal Packages, con orígenes ascendentes y vistas. GitHub Packages aloja paquetes npm, RubyGems, Maven, Gradle, NuGet e imágenes de contenedor junto al código, con permisos del repositorio o granulares, y en GitHub Actions se autentica con GITHUB_TOKEN para publicar en el propio repositorio.
  • Una fuente de Azure Artifacts guarda copia de los paquetes instalados desde sus orígenes ascendentes y los busca en orden: publicados, guardados y luego cada origen según su posición. Conviene usar una sola fuente por configuración de cliente. Las vistas @local, @prerelease y @release son de solo lectura: se publica en la fuente base y se promueven las versiones validadas, que quedan exentas de retención.
  • SemVer usa Major.Minor.Patch: el principal indica cambios importantes, el secundario funciones compatibles y la revisión correcciones; las etiquetas con guion marcan versiones preliminares y los metadatos van tras el signo más. CalVer codifica la fecha pero no el alcance del cambio, por lo que Microsoft recomienda SemVer con la fecha en metadatos. NuGet usa rangos de intervalo y Dependabot permite fijar versioning-strategy.
  • En Azure Pipelines, la propiedad name define el número de ejecución con tokens como $(Date:yyyyMMdd), $(SourceBranchName) y $(Rev:r), que se reinicia a 1 cuando cambia el resto del número; counter() mantiene un contador por prefijo. Los recursos de canalización eligen la versión del artefacto por número de ejecución, rama o etiquetas, y en GitHub Actions los artefactos llevan nombre y retention-days.

Design and implement a testing strategy for Azure DevOps pipelines and GitHub Actions

  • Las puertas de calidad bloquean la combinación: directivas de rama con validación de compilación y comprobaciones de estado en Azure Repos, o conjuntos de reglas con comprobaciones requeridas, análisis de código e implementaciones correctas en GitHub. Las puertas de versión controlan la implementación: aprobaciones y comprobaciones de Azure Pipelines definidas fuera del YAML, y reglas de protección de entornos de GitHub.
  • La revisión de código de Copilot puede ser automática mediante conjuntos de reglas, pero sus revisiones no cuentan como aprobaciones salvo que se habiliten las aprobaciones de Copilot. El agente en la nube y la revisión comparten la configuración MCP del repositorio, y la revisión solo usa herramientas con readOnlyHint; los secretos empiezan por COPILOT_MCP_. El servidor MCP de Azure DevOps da acceso a compilaciones y elementos de trabajo.
  • Una estrategia shift-left clasifica las pruebas por dependencias y duración (L0/L1 unitarias, L2 funcionales aisladas, L3 contra un despliegue de prueba, L4 contra producción) y ejecuta la mayoría antes de fusionar en main. Las pruebas de carga se automatizan con Azure Load Testing (tarea AzureLoadTest o acción azure/load-testing) y criterios de error en el YAML de configuración.
  • En Azure Pipelines, VSTest@3 reparte pruebas entre agentes con strategy: parallel y lotes por casos, tiempo o ensamblado, y PublishTestResults@2 documenta resultados JUnit, NUnit, TRX, xUnit o CTest en la pestaña Tests. Copilot genera pruebas con /tests, Copilot cloud agent prepara su entorno con copilot-setup-steps.yml y el servidor MCP de Azure DevOps expone el conjunto testplan.
  • PublishCodeCoverageResults@2 publica cobertura (Cobertura, JaCoCo, .coverage y otros) en la pestaña Code Coverage; en Azure Repos, azurepipelines-coverage.yml define la cobertura diferencial de las solicitudes de incorporación de cambios, y una directiva de rama la convierte en obligatoria. Copilot ayuda a cubrir ramas y casos límite, y el servidor MCP de Azure DevOps puede descargar artefactos para analizarlos.

Design and implement Azure DevOps pipelines and GitHub Actions

  • Azure Pipelines ofrece YAML y editor clásico (necesario para TFVC, Subversion o Bitbucket Server), fases en un solo YAML y entornos con historial y trazabilidad. GitHub Actions usa solo YAML en el repositorio, entornos con revisores obligatorios, temporizadores y ramas permitidas, y se conecta a Azure con la acción Azure Login, preferiblemente mediante OpenID Connect.
  • Los agentes hospedados por Microsoft y los ejecutores hospedados en GitHub dan una máquina nueva por trabajo sin mantenimiento, pero sin acceso a tu red. Managed DevOps Pools añade imágenes personalizadas, redes virtuales y uso en varias organizaciones; los ejecutores más grandes de GitHub admiten redes privadas de Azure; los autohospedados dan control total pero exigen mantenimiento y casi nunca deben usarse en repositorios públicos.
  • Un agente autohospedado de Azure Pipelines se registra con config.sh o config.cmd (con --unattended, --pool, --replace) y se ejecuta como servicio con svc.sh. En GitHub, los ejecutores se enrutan con runs-on por etiquetas o por grupo y, sin grupo, van al predeterminado. Managed DevOps Pools se une a tu red delegando una subred por grupo en Microsoft.DevOpsInfrastructure/pools.
  • Azure Pipelines accede a GitHub con la aplicación de GitHub (identidad de Azure Pipelines y GitHub Checks), OAuth o un PAT. Valida solicitudes con el desencadenador pr, admite comentarios /azp run y comprobaciones de estado en ramas protegidas, y no expone secretos a las bifurcaciones por defecto. Azure Boards enlaza commits, PR e issues de GitHub con elementos de trabajo.
  • Copilot genera YAML de GitHub Actions y Azure Pipelines; las instrucciones .instructions.md con applyTo fijan reglas solo para .github/workflows, y Copilot convierte horarios cron a UTC. Los flujos de trabajo agénticos se escriben en markdown con frontmatter (on, permissions, safe-outputs, engine) y se compilan con gh aw compile; el servidor MCP de Azure DevOps puede crear canalizaciones si no es de solo lectura.

Design and implement deployments

  • La exposición progresiva limita el radio de impacto: canary entrega primero a un grupo pequeño, blue-green mantiene dos entornos capaces de soportar toda la carga y desplaza el tráfico, y los anillos amplían la audiencia con tiempos de maduración. Las marcas de características separan implementación y exposición y permiten apagar sin volver a implementar; las variantes sirven para pruebas A/B.
  • Para ordenar implementaciones dependientes, Azure Pipelines ofrece desencadenadores de finalización de canalización con resources: pipelines y filtros de rama, etiqueta o fase; dentro de una canalización, dependsOn y stageDependencies. En GitHub Actions, needs ordena trabajos y workflow_run encadena flujos. En Bicep, Resource Manager deduce dependencias implícitas y despliega en paralelo lo independiente.
  • Las ranuras de App Service permiten validar en una ranura de ensayo, calentar todas las instancias y cambiarla por producción sin perder solicitudes; repetir el intercambio revierte. El intercambio con vista previa aplica antes la configuración de destino. Los conjuntos de escalado con actualización gradual actualizan por lotes con sondeos de estado, y el equilibrador deja de enviar conexiones a instancias no saludables.
  • En el flujo de versiones de Microsoft, una revisión urgente se corrige primero en main mediante una solicitud de incorporación de cambios y después se lleva a la rama de versión con cherry-pick, para que el error no reaparezca en la siguiente versión. Según la gravedad, puede saltarse anillos o niveles, y los protocolos de emergencia aceleran aprobaciones y reducen el tiempo de maduración.
  • Una implementación resiliente se detiene en cuanto un modelo de estado detecta un problema y se recupera revirtiendo, avanzando con una corrección o desplegando de nuevo la última configuración buena. En Azure Pipelines ayudan retryCountOnTaskFailure y los enlaces on: failure; Traffic Manager ofrece conmutación por error con supervisión de estado, y la restauración a un momento dado protege los datos.

Design and implement infrastructure as code (IaC)

  • Una estrategia de IaC usa archivos declarativos versionados, como Bicep o plantillas ARM, que son idempotentes y evitan la deriva entre entornos; Bicep no requiere archivos de estado y ofrece módulos y what-if. Para eliminar recursos se recomiendan las pilas de implementación en lugar del modo completo, y la configuración del sistema operativo se gestiona como código con Azure Machine Configuration.
  • Azure App Configuration centraliza la configuración y las marcas de características fuera del código y complementa a Key Vault. Las etiquetas crean variantes por entorno de una misma clave, que distingue mayúsculas. En Azure Pipelines, las tareas Import y Export sincronizan archivos y variables (con Dry Run y eliminación de claves ausentes), y en GitHub Actions se usa az appconfig kv import con OIDC.

Maintain Azure DevOps pipelines and GitHub Actions

  • Azure Pipelines ofrece informes de tasa de aprobación (tareas que más fallan), duración (tareas más lentas) y errores de pruebas, filtrables por fecha y rama. La administración de pruebas inestables las detecta por reejecución o mediante API y permite excluirlas del resumen para que no hagan fallar la canalización. En GitHub, las métricas de rendimiento muestran tiempos de ejecución y de cola y tasas de error.
  • Para optimizar canalizaciones: Cache@2 reutiliza dependencias entre ejecuciones con claves basadas en el archivo de bloqueo, restoreKeys y cacheHitVar; batch: true agrupa inserciones y fetchDepth reduce el historial descargado; retryCountOnTaskFailure reintenta tareas con errores transitorios. En GitHub Actions, concurrency con cancel-in-progress cancela ejecuciones obsoletas de la misma rama.
  • En Azure Pipelines la retención de ejecuciones se configura solo en el proyecto, conserva las ejecuciones recientes de la rama predeterminada, de las ramas protegidas y de la canalización, y no rige los paquetes; las concesiones de retención alargan ejecuciones concretas. Las fuentes de Azure Artifacts tienen su propia retención y las vistas eximen versiones; en GitHub, retention-days ajusta cada artefacto.

4. Design and implement a security and compliance plan

15–20%

Design and implement authentication and authorization methods

  • Para cargas hospedadas en Azure se prefiere una identidad administrada, cuyas credenciales gestiona Azure; la asignada por el sistema vive y muere con su recurso y la asignada por el usuario se comparte entre recursos. Fuera de Azure se usa una entidad de servicio con federación o certificado mejor que con secreto. En Azure DevOps la identidad se agrega explícitamente a la organización y se autoriza con niveles de acceso y grupos.
  • GITHUB_TOKEN es un token de instalación limitado al repositorio del flujo de trabajo; con la clave permissions se aplica el mínimo privilegio y lo no especificado queda en none. Para otros repositorios o integraciones duraderas se usa una GitHub App, que no depende de un usuario, con actions/create-github-app-token. Los tokens de acceso personal sirven para scripts breves, y se prefieren los fine-grained a los clásicos.
  • La autenticación sin secretos usa OIDC y federación de identidades de carga de trabajo: en GitHub Actions, el trabajo necesita id-token: write y azure/login intercambia el token por uno de Azure de corta duración, con la credencial federada en una aplicación de Entra o una identidad administrada asignada por el usuario. En Azure Pipelines, las conexiones de servicio con federación eliminan los secretos almacenados.
  • Las conexiones de servicio autentican Azure Pipelines frente a servicios externos; para Azure Resource Manager se recomienda la federación de identidades de carga de trabajo, que elimina los secretos, y cada canalización debe autorizarse por separado. Los PAT solo se usan cuando no hay autenticación de Microsoft Entra: con ámbito de organización, ámbitos mínimos, vigencia corta y guardados en un almacén de secretos.
  • En Azure DevOps, los niveles de acceso deciden qué características del portal se ven y los grupos de seguridad conceden Allow o Deny; un Deny de otro grupo en el mismo ámbito suele prevalecer y una asignación explícita en un nodo hijo sustituye la heredada. En GitHub se eligen roles de repositorio de Read a Admin, y el bloque permissions limita el GITHUB_TOKEN.

Design and implement a strategy for managing sensitive information in automation

  • En Azure Pipelines, la tarea AzureKeyVault@2 descarga secretos como variables mediante una conexión de servicio con permisos Get y List, y un grupo de variables puede vincularse a un almacén para leer los valores en tiempo de ejecución. En GitHub Actions se inicia sesión con azure/login y OIDC, se lee el secreto con la CLI y se enmascara con ::add-mask::.
  • Key Vault guarda secretos, claves y certificados; con Azure RBAC se asigna el rol mínimo, como Key Vault Secrets User para leer secretos. La eliminación temporal permite recuperar objetos y la protección de purga impide borrarlos antes de la retención. Las directivas de rotación crean nuevas versiones de clave, que los servicios toman con el URI sin versión, y los certificados de CA integradas se renuevan solos.
  • Los archivos seguros de Azure Pipelines guardan certificados, perfiles y claves cifrados; son recursos protegidos con aprobaciones y permisos de canalización, y DownloadSecureFile@1 los descarga al inicio de la fase y los borra al terminar el trabajo. En GitHub Actions, los secretos pueden ser de repositorio, de organización o de entorno, y estos últimos solo se liberan tras sus reglas de protección.
  • El enmascaramiento de secretos es un esfuerzo razonable, no una garantía: no se ocultan subcadenas ni partes de datos estructurados, así que hay que usar un secreto por valor, asignarlos a variables de entorno en vez de pasarlos por la línea de comandos y registrar con ::add-mask:: los valores derivados. Las compilaciones de bifurcaciones no deben recibir secretos ni ejecutar código no confiable con privilegios.

Automate security and compliance scanning

  • Una estrategia de análisis combina herramientas por momento y tipo de contenido: revisión de dependencias en cada solicitud para bloquear paquetes vulnerables, CodeQL para el código, la extensión Microsoft Security DevOps para plantillas IaC, contenedores y binarios, y Defender for Cloud para ver en una consola los hallazgos de Azure DevOps, GitHub y GitLab.
  • En Azure Repos, GitHub Advanced Security for Azure DevOps activa la protección de inserción y el análisis de secretos del historial; el análisis de dependencias y CodeQL son tareas de canalización, y las comprobaciones de estado AdvancedSecurity bloquean solicitudes vulnerables. En GitHub, la configuración predeterminada de CodeQL requiere Actions y la omisión delegada limita quién salta la protección de inserción.
  • Defender for Cloud conecta Azure DevOps, GitHub y GitLab desde Configuración del entorno con conectores nativos. GitHub exige instalar la aplicación de seguridad de DevOps como propietario de la organización; Azure DevOps exige Project Collection Administrator, nivel Basic y OAuth de terceros activado. Las operaciones se ejecutan con la identidad que autoriza, así que conviene una cuenta de servicio dedicada.

5. Implement an instrumentation strategy

15–20%

Configure monitoring for Azure DevOps and GitHub platforms

  • En Azure DevOps, el widget Lead Time mide desde la creación del elemento hasta su estado Completado y Cycle Time desde que entra en curso; ambos muestran media móvil y desviación estándar por equipo. El Cumulative Flow Diagram enseña el flujo de trabajo por columna y revela abultamientos. Para la recuperación se sigue el tiempo medio de restauración del servicio tras un incidente.
  • Azure DevOps puede transmitir su registro de auditoría a Azure Monitor Logs, donde se consulta la tabla AzureDevOpsAuditing y se crean alertas; también admite Splunk y Event Grid. GitHub Enterprise Cloud transmite eventos de auditoría y de Git a Azure Event Hubs o Blob Storage desde que se habilita. Application Insights recibe anotaciones de versión de Azure Pipelines y crea elementos de trabajo en GitHub o Azure DevOps.
  • GitHub ofrece información a varios niveles: Pulse y el tráfico por repositorio, métricas de uso y de rendimiento de GitHub Actions por organización, y gráficos en la información de Projects. Los gráficos actuales agrupan elementos por campo y los históricos ponen Time en el eje X; el eje Y puede sumar o promediar un campo numérico. Un rol personalizado permite ver las métricas de Actions sin ser propietario.
  • En Azure Pipelines, las alertas se configuran con suscripciones de notificaciones de equipo o proyecto, con la aplicación Azure Pipelines para Slack o Teams, que permite filtrar por compilaciones fallidas y aprobar fases, y con la comprobación Query Azure Monitor Alerts en entornos. En GitHub Actions, cada usuario recibe avisos de las ejecuciones que desencadena, y workflow_run con una condición sobre conclusion crea alertas propias.

Monitor Azure workloads by using AI agents

  • Azure Copilot Observability Agent permite chatear con registros y métricas e investigar incidentes sin aprovisionar nada. Para las operaciones autónomas, que correlacionan alertas y crean incidencias de Azure Monitor, se crea un recurso Observability Agent con identidad administrada, ámbito en Application Insights e instrucciones personalizadas. El agente nunca reinicia recursos ni cambia la configuración: deciden las personas.
  • Para crear Azure SRE Agent hace falta Propietario, o Colaborador más User Access Administrator, y el creador recibe SRE Agent Administrator. Después se conectan repositorios de código, orígenes de registros como Application Insights y, opcionalmente, grupos de recursos con nivel Reader o Privileged para su identidad administrada. Las directivas de acceso a herramientas solo permiten denegar en el ámbito global.
  • Azure SRE Agent investiga con hipótesis que valida o descarta, propone mitigaciones y, en modo Review, espera la aprobación de un SRE Agent Administrator para operaciones de infraestructura de Azure. Nunca ejecuta eliminaciones, respeta los bloqueos ReadOnly y registra cada comando az como evento AgentAzCliExecution en Application Insights. También puede crear elementos de trabajo, notificar o lanzar flujos de trabajo.

Analyze metrics from instrumentation by using AI agents

  • Las métricas de host de una máquina virtual (CPU, red y uso de disco) están disponibles sin agente; la memoria del invitado y el espacio libre en disco requieren el agente de Azure Monitor y una DCR, por ejemplo con VM insights, que escribe en InsightsMetrics. Azure SRE Agent consulta métricas y registros con su identidad administrada sin conectores y analiza series temporales; Observability Agent correlaciona mejor si se supervisan las VM.
  • Application Insights ofrece las vistas Performance, Failures y Search y la vista End-to-end transaction details; Live metrics muestra datos con un segundo de latencia sin conservarlos. Azure Copilot Observability Agent ejecuta investigaciones profundas desde una alerta que correlacionan señales de aplicación, infraestructura y plataforma; sus resultados son temporales y se conservan guardándolos como issue de Azure Monitor.
  • Application Insights agrupa la telemetría de una transacción distribuida con operation_Id (operación raíz) y enlaza cada elemento con su padre inmediato mediante operation_ParentId. Application map identifica los componentes por el cloud role name, y End-to-end transaction details muestra un diagrama de Gantt con solicitudes, dependencias y excepciones. El muestreo en la distribución evita trazas rotas; el de ingesta las hace más probables.
  • La actividad de los agentes de Copilot en GitHub se revisa en el registro de auditoría de la empresa con actor:Copilot; cada evento incluye user y agent_session_id. Para un historial largo, se transmite a un destino como Azure Event Hubs. Los datos de clientes locales se recogen con OpenTelemetry, y la clase identity atribuye la actividad sin capturar prompts ni respuestas.
  • Desde la página Logs, Observability Agent responde en lenguaje natural sobre registros y métricas, y Azure Copilot genera KQL de ejemplo. En KQL, que distingue mayúsculas y minúsculas, where filtra (== exacto, =~ sin distinguir mayúsculas), summarize con bin agrupa por intervalos de tiempo, project y extend controlan columnas y top ordena y limita; search es más lento que filtrar.
Practicar esta certificación