Microsoft AZ-400: Pipelines de CI/CD con Azure Pipelines — Guía de estudio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Azure Pipelines ofrece CI/CD de extremo a extremo como código, con canalizaciones YAML de varias fases que unifican la compilación, las pruebas y el lanzamiento, al tiempo que se conservan los controles empresariales. El dominio de la creación de YAML, los desencadenadores, los agentes, las variables, las plantillas, los trabajos de implementación, los artefactos, el almacenamiento en caché y las conexiones de servicio es esencial para construir sistemas de entrega escalables, seguros y repetibles.

Creación con YAML y plantillas

Una canalización YAML se compone de fases (stages), trabajos (jobs) y pasos (steps). Las fases modelan los límites del ciclo de vida, como Compilación (Build), Pruebas (Test) y Lanzamiento (Release); los trabajos se ejecutan en agentes y pueden ejecutarse en paralelo; los pasos son tareas o scripts que se ejecutan dentro de un trabajo. Las dependencias son explícitas a través de dependsOn, lo que permite una orquestación detallada y una ejecución condicional. El YAML de varias fases consolida CI y CD, admite patrones de fan-in/fan-out y vincula las aprobaciones a los entornos en lugar de a una construcción de lanzamiento independiente.

Las plantillas permiten la composición y la reutilización en diferentes granularidades:

Plantillas de pasos (Step templates): encapsulan una secuencia de tareas (p. ej., configuración de herramientas, restauración, compilación, pruebas) para su reutilización entre repositorios.
Plantillas de trabajos (Job templates): agrupan pasos con una especificación y estrategia de agente concretas (p. ej., un trabajo de matriz de pruebas).
Plantillas de fases (Stage templates): empaquetan fases completas, incluyendo aprobaciones, condiciones y la selección de entornos, para flujos de promoción consistentes.
Plantillas de extensión (Extends templates): imponen la herencia de canalizaciones. Una extensión (extends) de nivel superior hace referencia a una plantilla central que prescribe las fases/trabajos/pasos y la gobernanza requeridos. Esto es muy potente para las políticas de toda la organización, ya que garantiza que cada equipo herede los análisis de seguridad, las comprobaciones de cumplimiento y las convenciones de nomenclatura.

La evaluación de las plantillas se produce en tiempo de compilación, antes de la ejecución en tiempo de ejecución. Utilice ${{ }} para las expresiones de plantilla para ramificar la estructura de la canalización en tiempo de compilación (por ejemplo, para incluir ciertos trabajos solo para main). La sintaxis de macro $(var) y las expresiones en tiempo de ejecución $[ ] se resuelven en tiempo de ejecución, lo que afecta a cuándo están disponibles los secretos y los grupos de variables. Almacene las plantillas compartidas en un repositorio central e impórtelas a través de resources repositories; fije una rama o etiqueta para compilaciones deterministas.

Desencadenadores, agentes, variables y expresiones

Los desencadenadores (triggers) gobiernan los puntos de entrada de la automatización:

Desencadenadores de CI (CI triggers): inician ejecuciones de la canalización cuando se inserta código en las ramas rastreadas. Los filtros de ruta de inclusión y exclusión (include y exclude) reducen la actividad innecesaria. El modo por lotes (Batch) permite fusionar múltiples pushes.
Desencadenadores de PR (PR triggers): validan las pull requests. Configure las ramas de destino y los filtros de ruta, y habilite la cancelación automática de ejecuciones reemplazadas.
Desencadenadores programados (Scheduled triggers): se ejecutan según expresiones cron para soportar compilaciones nocturnas o validaciones periódicas con control de zona horaria.
Desencadenadores de canalización (Pipeline triggers): se activan cuando una canalización ascendente (upstream) publica una nueva ejecución o artefacto. Declare recursos de canalización (pipeline resources) y adjunte trigger: true con filtros de rama para encadenar canalizaciones entre repositorios o proyectos.

Los agentes y los grupos de agentes (agent pools) determinan dónde se ejecutan los trabajos:

Agentes alojados por Microsoft (Microsoft-hosted agents): aprovisionan máquinas virtuales efímeras en imágenes ubuntu-latest, windows-latest o macOS con conjuntos de herramientas preinstalados. Son ideales para la elasticidad y un mantenimiento mínimo. Planifique la concurrencia comprando trabajos paralelos y considere los límites de calentamiento de la caché.
Agentes autohospedados (Self-hosted agents): se ejecutan en su propia infraestructura para cadenas de herramientas personalizadas, acceso a redes privadas y un rendimiento predecible. Refuerce la seguridad del host (harden), restrinja el tráfico de salida (egress) según sea necesario y rote el PAT del agente utilizado para registrarlo. Utilice conjuntos de escalado o agentes en contenedores para obtener elasticidad.
Grupos de agentes (Agent pools): agrupan lógicamente los agentes y se utilizan para delegar permisos. Otorgue derechos de “Uso” a nivel de proyecto a los grupos y aísle las cargas de trabajo sensibles mediante grupos dedicados. Los trabajos especifican el grupo (pool) y, opcionalmente, las demandas (demands) para seleccionar agentes con las capacidades requeridas.

Las variables y los parámetros impulsan la configurabilidad:

Variables de canalización (Pipeline variables): son pares clave/valor disponibles para las tareas como variables de entorno y a través de la macro $(name). Las variables secretas se enmascaran en los registros y nunca se exponen en expresiones de plantilla en tiempo de compilación. Márquelas como secretas en la Biblioteca (Library) o en la canalización.
Grupos de variables (Variable groups): centralizan valores compartidos y secretos en la Biblioteca (Library). Vincúlelos a Azure Key Vault para obtener los secretos en tiempo de ejecución, asegurando que los valores no se almacenen en la canalización. Controle los permisos de la canalización para restringir qué canalizaciones pueden consumir un grupo.
Parámetros en tiempo de ejecución (Runtime parameters): definen entradas con tipos de datos fuertes en el momento de la puesta en cola (string, number, boolean, object) y se evalúan en tiempo de compilación a través de ${{ parameters.* }} para dar forma a la canalización (p. ej., habilitar/deshabilitar fases). Prefiera los parámetros cuando necesite alterar la estructura de la canalización; prefiera las variables cuando necesite valores en tiempo de ejecución dentro de los pasos.
Expresiones: utilice ${{ }} para la lógica de plantillas en tiempo de compilación, $(var) para la sustitución de macros y $[condition()] para condicionales en tiempo de ejecución en las propiedades. Establezca variables desde las tareas mediante comandos de registro (logging commands) y propague las salidas entre trabajos utilizando variables isOutput.

Implementaciones, Entornos, Estrategias y Puertas de enlace

Los trabajos de implementación proporcionan semántica de CD de primera clase. Un trabajo de implementación se dirige a un entorno y se ejecuta bajo una estrategia que controla los despliegues y los hooks del ciclo de vida:

Los entornos representan los destinos de la implementación (p. ej., dev, test, prod) y pueden contener recursos como clústeres de Kubernetes, máquinas virtuales o recursos genéricos “none” para implementaciones agnósticas de la plataforma. Los entornos unifican la telemetría, las aprobaciones y las comprobaciones.
Las aprobaciones y comprobaciones se asocian a los entornos y a las conexiones de servicio. Las aprobaciones requieren aprobadores designados antes de que la implementación continúe. Las comprobaciones actúan como puertas de enlace (gates) que evalúan condiciones como el horario comercial, elementos de trabajo requeridos, señales de Azure Monitor, la invocación de API REST o Azure Functions, y la protección de ramas. Estas impiden la promoción si no se satisfacen las líneas base de rendimiento o las condiciones de cumplimiento.
Las estrategias definen cómo se despliegan las actualizaciones:
- runOnce aplica los cambios en una sola oleada, con hooks preDeploy y postDeploy.
- rolling implementa en lotes a través de las instancias, con umbrales de maxParallel y de fallos para una progresión segura.
- canary desvía el tráfico gradualmente mediante incrementos, con fases routeTraffic y postRouteTraffic para validar antes del despliegue completo.
- blue-green (también llamado red/black) se implementa desplegando en un entorno o slot paralelo y cambiando el tráfico en el balanceador de carga o mediante un intercambio de slots de App Service. Aunque blue-green no es una estrategia con nombre en YAML, se materializa a través de entornos, enrutamiento y tareas de intercambio (swap), y proporciona una reversión rápida al revertir el tráfico.

Codifique la lógica de implementación como un trabajo de implementación por cada fase (stage) de entorno. Aproveche las comprobaciones de entorno para tener puertas de enlace robustas, en lugar de sondeos (polling) con scripts ad-hoc. Cuando se necesiten secretos, recupérelos desde Azure Key Vault a través de una conexión de servicio en lugar de incrustarlos en variables.

Artefactos, Almacenamiento en Caché y Conexiones de Servicio

Los artefactos y el almacenamiento en caché mejoran la reutilización y el rendimiento:

Los artefactos de canalización (Pipeline artifacts) son la forma nativa de publicar y consumir los resultados de una compilación. Use PublishPipelineArtifact para publicar artefactos con nombre y DownloadPipelineArtifact para obtenerlos de la ejecución actual o de una específica. Están optimizados para la fiabilidad y para ser compartidos entre fases en YAML. Al consumir desde otra canalización, declare un recurso de canalización (pipeline resource) y use el nombre de su recurso de artefactos para una recuperación precisa.
Los paquetes universales (Universal packages) proporcionan una distribución de binarios inmutables y versionados a través de Azure Artifacts para activos no específicos de un lenguaje (p. ej., herramientas CLI, archivos de datos). Publique y descargue con las tareas de Universal Packages, organice mediante vistas de fuente (feed views) (p. ej., prerelease vs release) y gestione la retención en las fuentes (feeds).
El almacenamiento en caché de la canalización (Pipeline caching) acelera la restauración de dependencias. La tarea Cache utiliza una clave (key) y una ruta (path). Las claves deben hashear los archivos de bloqueo (lockfiles) (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) además de las versiones del SO y de las herramientas para una invalidación precisa. Las claves de restauración (Restore keys) proporcionan coincidencias de respaldo para aciertos parciales de caché (partial cache hits). Evite incrustar secretos en las rutas de caché, respete los límites de tamaño de la caché y deshabilite el almacenamiento en caché para herramientas efímeras cuando los archivos de bloqueo sean inestables. Observe la variable cacheHitVar para bifurcar el comportamiento de las tareas.

Las conexiones de servicio definen la identidad que Azure Pipelines utiliza para alcanzar sistemas externos:

Los tipos incluyen Azure Resource Manager (para suscripciones y grupos de recursos de Azure), GitHub (lectura/escritura de repositorios, reporte de estado) y Docker/Container Registry (Docker Hub, ACR). Existen otros para AWS, GCP, puntos de conexión de servicio genéricos y registros de paquetes.
La federación OIDC (federación de identidades de carga de trabajo) elimina los secretos de larga duración al establecer una confianza entre Azure DevOps y los proveedores de identidad en la nube. Para ARM, configure una aplicación de Entra ID con una credencial federada vinculada al emisor (issuer) de Azure DevOps y a las notificaciones (claims) del repositorio/canalización. En tiempo de ejecución, Azure DevOps intercambia un token de corta duración por un token de acceso a la nube, eliminando los secretos de la entidad de servicio (service principal) y reduciendo el riesgo de fuga de credenciales.
El ámbito (scoping) y la gobernanza son críticos. Limite el ámbito de las conexiones ARM al mínimo privilegio (idealmente a nivel de grupo de recursos con RBAC personalizado). Deshabilite “Conceder permiso de acceso a todas las canalizaciones” y en su lugar autorice explícitamente las canalizaciones. Asocie aprobaciones y comprobaciones a las conexiones de servicio para requerir una revisión humana o la validación de una política antes de su uso.

Clásico vs. YAML y Migración

Las canalizaciones clásicas utilizan el diseñador visual con conceptos separados de Compilación (Build) y Lanzamiento (Release). Ofrecen creación basada en tareas, gestión de variables, entornos de lanzamiento y puertas (gates). Las canalizaciones YAML proporcionan canalizaciones como código (pipeline-as-code), unificación multifase, plantillas y un versionado robusto con el repositorio. La paridad de características se ha alcanzado en gran medida: las aprobaciones y comprobaciones de entorno reemplazan a las puertas de lanzamiento; los trabajos de despliegue modelan los entornos; los artefactos de canalización sustituyen a los artefactos de compilación; y las plantillas y extends implementan una gobernanza central a escala. Las diferencias restantes suelen estar en torno a las intervenciones manuales basadas en la interfaz de usuario y algunas características de nicho del diseñador de lanzamientos, que se cubren en YAML mediante tareas de Validación Manual y comprobaciones de entorno.

Una ruta de migración pragmática es:

Inventariar las definiciones clásicas de compilación y lanzamiento, tareas, variables, entornos, aprobaciones y puertas.
Convertir la compilación a YAML usando el asistente o la opción de exportar a YAML, y luego refactorizar en plantillas para su reutilización y mantenibilidad.
Modelar cada entorno de lanzamiento como una fase (stage) de YAML con un trabajo de despliegue que apunte a un entorno. Traducir las puertas de lanzamiento a aprobaciones y comprobaciones de entorno (p. ej., comprobaciones de consulta de Azure Monitor, comprobaciones de consulta de elementos de trabajo).
Externalizar las variables compartidas en grupos de variables y vincular Key Vault para los secretos. Reemplazar los secretos de los service principals por conexiones de servicio respaldadas por OIDC.
Reemplazar los desencadenadores de artefactos de lanzamiento por desencadenadores de recursos de canalización. Publicar artefactos de canalización en la CI y consumirlos en las fases de CD.
Validar la paridad ejecutando ambas canalizaciones temporalmente, luego hacer la transición definitiva y retirar las definiciones clásicas con planes de reversión adecuados.

Escenario de Problema Práctico

Starbucks está estandarizando la entrega para una plataforma de microservicios y debe migrar de los lanzamientos clásicos a YAML, al tiempo que impone puertas de rendimiento, reduce el riesgo de credenciales y acelera las compilaciones.

Crear YAML multifase con plantillas extends

Enfoque: Crear una plantilla extends central a nivel de organización que inyecte fases comunes para análisis estático, SCA y comprobaciones de seguridad, además de notificaciones estándar. Cada canalización de servicio extiende esta plantilla y define sus fases específicas de compilación y despliegue.
Justificación: El uso de extends impone la gobernanza de manera uniforme y mantiene las canalizaciones de servicio ligeras, garantizando al mismo tiempo los pasos de cumplimiento requeridos.

Implementar desencadenadores de CI, PR, programados y de canalización

Enfoque: Configurar desencadenadores de CI y PR con filtros de ruta para cada servicio; añadir una programación nocturna para pruebas de integración de larga duración; encadenar una canalización de empaquetado para que active una canalización de despliegue mediante recursos de canalización.
Justificación: Asegura una retroalimentación rápida sobre los cambios en el código, comprobaciones periódicas del estado del sistema y una promoción determinista de artefactos conocidos.

Usar una estrategia de agentes mixta con pools de agentes

Enfoque: Los trabajos de compilación se ejecutan en agentes ubuntu-latest alojados por Microsoft para mayor elasticidad; los trabajos de despliegue se ejecutan en agentes autohospedados dentro de la VNet de Starbucks con acceso a los clústeres internos. Aislar los agentes por pools según el entorno y restringir el uso de los pools.
Justificación: Los agentes alojados minimizan el mantenimiento para la CI; los agentes autohospedados proporcionan un alcance de red seguro para la CD. La segmentación por pools impone el principio de privilegio mínimo.

Gestionar variables con grupos de variables y parámetros en tiempo de ejecución

Enfoque: Colocar valores compartidos no secretos en grupos de variables, recuperar secretos de Azure Key Vault a través de grupos de variables vinculados y exponer un parámetro booleano enablePerfGate para activar o desactivar las puertas de rendimiento en ramas que no sean de producción.
Justificación: La configuración centralizada evita la duplicación; Key Vault protege los secretos; los parámetros impulsan las decisiones estructurales en tiempo de compilación.

Definir trabajos de despliegue con entornos, aprobaciones y comprobaciones

Enfoque: Modelar dev, staging y prod como entornos. Añadir aprobaciones para staging y prod. Añadir comprobaciones: horario comercial para prod, y una comprobación de consulta de Azure Monitor que bloquee la promoción si la latencia en staging excede la línea base.
Justificación: Las aprobaciones y comprobaciones a nivel de entorno implementan una promoción controlada e imponen los SLO antes del despliegue en producción.

Aplicar estrategias canary y luego blue-green

Enfoque: Usar una estrategia canary en staging para validar los incrementos. En producción, desplegar en un slot/entorno paralelo e intercambiar el tráfico (blue-green/red-black) con capacidad de reversión instantánea.
Justificación: La estrategia canary reduce el riesgo durante la validación; blue-green minimiza el tiempo de despliegue y proporciona la reversión más rápida.

Optimizar con artefactos de canalización y caché

Enfoque: Publicar los resultados de la compilación como artefactos de canalización; consumirlos en las fases de despliegue. Almacenar en caché la restauración de dependencias usando claves basadas en el hash del archivo de bloqueo (lockfile) con restoreKeys como alternativa.
Justificación: Los artefactos aseguran una promoción inmutable y trazable; el almacenamiento en caché reduce significativamente los tiempos de compilación sin sacrificar la corrección.

Asegurar las conexiones de servicio con OIDC y permisos acotados

Enfoque: Crear conexiones de servicio ARM utilizando federación de identidades de carga de trabajo (workload identity federation) acotadas a grupos de recursos. Requerir aprobaciones y comprobaciones para la conexión de servicio y deshabilitar la opción “Conceder acceso a todas las canalizaciones”.
Justificación: Elimina los secretos de larga duración e impone el principio de privilegio mínimo con aprobaciones auditables.

Este diseño de extremo a extremo alinea la gobernanza de YAML como código con aprobaciones y comprobaciones de nivel empresarial, acelera la entrega mediante el almacenamiento en caché y los artefactos, y fortalece la seguridad a través de OIDC y conexiones de servicio con permisos acotados.

← Control de código fuente y gestión de repositorios · Todos los dominios · Infraestructura como código y gestión de la configuración →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →