Microsoft AZ-400: Infraestructura como código y gestión de la configuración — 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.

Visión General

La Infraestructura como Código (IaC) y la Gestión de la Configuración en Azure le permiten definir, aprovisionar y aplicar la configuración de la infraestructura y las aplicaciones de forma repetida y segura. Azure soporta nativamente ARM JSON y Bicep, y se integra bien con Terraform y Ansible. El estado de la configuración se puede declarar con PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef y Puppet. El despliegue de características de aplicaciones y la gestión de claves se centralizan con Azure App Configuration y Key Vault. Las imágenes inmutables construidas con Packer reducen la deriva (drift). La gobernanza se aplica como política como código con Azure Policy y OPA/Gatekeeper para Kubernetes.

IaC Nativa de Azure: Plantillas ARM y Bicep

Las plantillas ARM son documentos JSON declarativos que Azure Resource Manager utiliza para crear y actualizar recursos. La estructura de nivel superior incluye $schema, contentVersion, parameters, variables, resources y outputs. Los parámetros permiten entradas específicas del entorno; las variables ayudan a derivar valores calculados; los recursos declaran el estado deseado; los outputs publican resultados como los ID de los recursos. Las plantillas admiten expresiones de plantilla y funciones en tiempo de ejecución (p. ej., resourceId, reference, concat, uniqueString) para que pueda componer nombres y recuperar propiedades.

Para dividir despliegues grandes en unidades mantenibles, puede usar plantillas anidadas o vinculadas. Una plantilla anidada integra el JSON en la propiedad template de un recurso Microsoft.Resources/deployments. Una plantilla vinculada hace referencia a una plantilla remota a través de templateLink.uri, normalmente almacenada en Azure Storage con una SAS de tiempo limitado para garantizar la integridad. Use plantillas anidadas cuando todo pueda residir en un único artefacto y desee un despliegue transaccional entre las partes. Use plantillas vinculadas para topologías muy grandes o cuando reutilice plantillas entre repositorios o equipos. Defina el ámbito de sus despliegues a un grupo de recursos, suscripción, grupo de administración o tenant según sea necesario, estableciendo el ámbito de despliegue en el recurso de despliegues.

ARM admite dos modos de despliegue. El modo Incremental (predeterminado) crea o actualiza los recursos presentes en la plantilla sin eliminar nada que no esté declarado. El modo Completo elimina los recursos en el ámbito de destino que no están especificados en la plantilla, lo que lo hace útil para garantizar una deriva mínima, pero también más arriesgado si la plantilla no es la fuente autoritativa para ese ámbito. Las operaciones de validación y What-If ayudan a previsualizar los cambios para reducir el riesgo antes de la ejecución.

Bicep es un lenguaje específico de dominio (DSL) que compila a ARM JSON y ofrece una ergonomía de autoría de primer nivel. Las declaraciones de recursos utilizan nombres simbólicos, imponen tipos y admiten la palabra clave existing para hacer referencia a recursos preexistentes sin necesidad de volver a desplegarlos. Los parámetros, variables, outputs y declaraciones de recursos son concisos, y las relaciones padre-hijo y los ámbitos son explícitos. Los módulos permiten la composición y la reutilización; cada módulo es un archivo Bicep al que se hace referencia con la palabra clave module y se puede publicar y consumir desde registros de especificaciones de plantilla (template spec) o de artefactos OCI. Las condiciones se expresan en línea con if en los recursos o módulos, y los bucles utilizan expresiones for para declarar múltiples instancias con un manejo claro de las dependencias. La migración desde ARM JSON es sencilla:

undefined

) convierte el JSON a Bicep; luego se refactoriza en módulos y se adoptan nombres simbólicos. Bicep no tiene pérdidas con respecto a ARM y es compatible con toda la superficie de la plataforma;

undefined

emite el ARM JSON estándar para el despliegue.

IaC Multiplataforma en Azure con Terraform

Terraform complementa la IaC nativa de Azure cuando se necesitan flujos de trabajo multicloud o agnósticos del proveedor. El proveedor azurerm gestiona los recursos de Azure Resource Manager y su versión debe estar fijada (version-pinned); incluya

undefined

aunque esté vacío para habilitar las características del proveedor. Otros proveedores comunes incluyen azuread para objetos de AAD y random para valores de utilidad. Autentíquese a través de una entidad de servicio (service principal), una Identidad Administrada (Managed Identity) en agentes alojados, o con la CLI de Azure. Adopte una estrategia clara de configuración del proveedor para cada entorno y centralice los módulos reutilizables con variables de entrada y outputs.

La gestión del estado es fundamental. Utilice el backend azurerm para almacenar el estado remoto en Azure Storage: configure

undefined

; autentíquese con una identidad administrada o una SAS; y habilite la eliminación temporal (soft delete) y el control de versiones en el contenedor de blobs. El backend utiliza concesiones de blob (blob leases) para bloquear el estado y evitar mutaciones concurrentes. El acceso a la cuenta de almacenamiento debe estar controlado por RBAC y, opcionalmente, restringido con Private Endpoints. Mantenga los archivos de estado aislados por entorno y, por diseño, nunca almacene secretos en el estado; utilice Key Vault y orígenes de datos (data sources) para recuperar secretos cuando sea necesario.

Los workspaces proporcionan un aislamiento lógico del estado dentro de la misma configuración para la ramificación de entornos como desarrollo (dev), pruebas (test) y producción (prod). Use

undefined

y asegúrese de que la clave del backend codifique el workspace para evitar colisiones (p. ej.,

undefined

). Los workspaces son excelentes para la paridad de entornos con pequeñas diferencias; cuando las topologías divergen significativamente, utilice configuraciones o módulos separados para evitar la deriva y la complejidad condicional. Intégrelo con Azure Pipelines utilizando conexiones de servicio (service connections) y las tareas de la CLI de Terraform para estandarizar init/plan/apply en todas las fases y para condicionar los apply a aprobaciones y comprobaciones de políticas.

Gestión de la configuración a escala: DSC, Azure Automation DSC, Ansible, Chef y Puppet

PowerShell Desired State Configuration (DSC) declara el estado de Windows y multiplataforma a través de recursos. Existen dos modos de entrega: el modo push envía los MOF directamente a los nodos; el modo pull hace que los nodos obtengan sus MOF desde un servicio pull según una programación. El Local Configuration Manager (LCM) aplica la política. Las configuraciones clave del LCM incluyen:

ConfigurationMode: ApplyOnly (configurar una vez, sin corrección de deriva), ApplyAndMonitor (detectar deriva, sin corrección), ApplyAndAutoCorrect (detectar y remediar la deriva).
ConfigurationModeFrequencyMins y RefreshFrequencyMins para ajustar la cadencia de aplicación y de pull.
RebootNodeIfNeeded y ActionAfterReboot para gestionar los reinicios.
Configuraciones parciales para componer el estado de un nodo a partir de múltiples MOF que apuntan de forma independiente a características (p. ej., el fortalecimiento del SO base y el rol de la aplicación).

Azure Automation State Configuration (Azure Automation DSC) es un servicio pull gestionado. Creas configuraciones en PowerShell, las importas a una Automation Account e inicias trabajos de compilación que producen configuraciones de nodo (MOF). Los nodos se registran con

undefined

usando una clave/endpoint de registro y pueden agruparse y se les pueden asignar configuraciones con valores de parámetros por nodo. Los informes de cumplimiento muestran la última configuración aplicada y el estado de deriva; los nodos en modo ApplyAndAutoCorrect se remediarán automáticamente en su próximo registro (check-in). Los trabajos de compilación son artefactos de compilación auditables, y el control de acceso basado en roles restringe la autoría de configuraciones y la asignación de nodos.

Ansible no tiene agentes (agentless) y es muy adecuado para la configuración de flotas de Linux y la orquestación ad-hoc. En Azure, utiliza la colección

undefined

, que proporciona módulos para computación, redes, Key Vault y más. El inventario dinámico con el plugin

undefined

descubre hosts de tus suscripciones o de grupos de recursos y etiquetas específicos; la adquisición de credenciales puede usar una entidad de servicio (service principal), Azure CLI o una identidad administrada (managed identity). Intégralo con Azure Pipelines instalando Ansible en un agente de Linux, iniciando sesión a través de

undefined

o una conexión de servicio de Azure Resource Manager, y ejecutando playbooks que hacen referencia al inventario dinámico, grupos de variables y archivos seguros. Ansible destaca en tareas idempotentes y legibles y puede complementar a DSC en entornos con predominio de Windows al gestionar flujos de trabajo y orquestación multiplataforma.

Chef y Puppet proporcionan modelos maduros de política como código (policy-as-code) e informes de cumplimiento. En las VM de Azure, las extensiones de VM de Chef y Puppet arrancan (bootstrap) los agentes en el momento del aprovisionamiento, garantizando una convergencia temprana. Chef Infra utiliza cookbooks y Policyfiles para fijar dependencias y asegurar ejecuciones reproducibles; Chef InSpec expresa el cumplimiento como código (compliance-as-code) y envía informes a Chef Automate sobre la deriva y la postura de los controles. Los manifiestos y módulos de Puppet codifican el estado deseado, con Code Manager y los entornos proporcionando flujos de promoción; Puppet Enterprise ofrece informes centralizados, clasificación basada en roles y remediación. Ambas herramientas se integran con Azure a través de módulos y proveedores de recursos y pueden coexistir con DSC nativo de Azure cuando la migración o los entornos mixtos lo requieran.

Configuración de Aplicaciones, Imágenes Inmutables y Política como Código

Azure App Configuration centraliza la configuración de las aplicaciones y los indicadores de características (feature flags). Los indicadores de características permiten el despliegue progresivo: defines indicadores y, si es necesario, adjuntas filtros como un despliegue basado en porcentajes o la segmentación de usuarios a través de las bibliotecas de Feature Manager. Las etiquetas (labels) te permiten separar valores por entorno o anillo (ring). Las instantáneas de configuración (configuration snapshots) capturan una vista inmutable y en un punto en el tiempo para un conjunto de claves y etiquetas, lo que permite despliegues consistentes y reproducibles en múltiples servicios sin condiciones de carrera por cambios concurrentes en las claves. Las referencias a Key Vault te permiten mantener los secretos en Key Vault mientras almacenas solo las referencias en App Configuration; la identidad administrada de la aplicación debe tener el permiso get sobre el secreto, y las bibliotecas cliente resuelven y almacenan en caché los secretos con una actualización dinámica opcional. Usa RBAC y aislamiento de red en ambos servicios para proteger el acceso.

La infraestructura inmutable elimina la deriva de configuración (configuration drift) al reconstruir a partir de una imagen conocida en lugar de mutar los hosts. El constructor azure-arm (ahora azure) de Packer crea imágenes a partir de un SO base, ejecuta aprovisionadores (provisioners) (shell, PowerShell, Ansible) y las publica en una Shared Image Gallery con regiones replicadas y versionado semántico. Un pipeline de imagen dorada (golden-image) típicamente realiza una comprobación de estilo (lint-check) de las plantillas de Packer, construye la imagen, ejecuta escaneos de vulnerabilidades y cumplimiento (p. ej., InSpec), la somete a pruebas de integración, la promueve a la galería y luego actualiza los VM Scale Sets o los grupos de hosts. Con VM Scale Sets, actualizaciones continuas (rolling) o basadas en el estado de salud, y actualizaciones automáticas de la imagen del SO, obtienes despliegues seguros y consistentes, y un rollback sencillo seleccionando una versión de imagen anterior.

La política como código (policy as code) impone barreras de protección (guardrails). Las definiciones de Azure Policy son objetos JSON con una policyRule que evalúa las propiedades de los recursos y aplica efectos como deny, audit, append, modify o deployIfNotExists para autorremediar. Parametriza las definiciones para reutilizarlas; agrúpalas con iniciativas (definiciones de conjuntos de políticas) para asignaciones consistentes y un seguimiento centralizado del cumplimiento. Asigna políticas a nivel de grupo de administración, suscripción o grupo de recursos; habilita tareas de remediación para las políticas modify y deployIfNotExists para poner en conformidad los recursos existentes. Almacena los artefactos de políticas en un control de fuentes, revísalos mediante pull requests y despliégalos a través de Bicep, ARM o Terraform para una promoción consistente entre entornos.

Para Kubernetes, OPA/Gatekeeper impone restricciones en el momento de la admisión (admission-time). Los ConstraintTemplates definen las políticas Rego y sus esquemas; los Constraints instancian esas políticas para un clúster. Los controles comunes incluyen restringir las imágenes a registros de confianza, requerir etiquetas/anotaciones o impedir pods con privilegios. Gatekeeper se integra con herramientas de GitOps (Flux/Argo CD) y pruebas de CI a través de conftest. Azure Policy for Kubernetes se basa en Gatekeeper para proporcionar vistas de asignación y cumplimiento nativas de Azure en todos los clústeres de AKS, unificando la gobernanza de la nube y del clúster bajo un único panel de estado de la postura (posture dashboard).

Escenario de Problema Práctico

Spotify debe estandarizar la infraestructura de Azure, reducir la deriva de configuración y acelerar los despliegues seguros de características en microservicios que abarcan Windows y Linux, AKS y cargas de trabajo basadas en VM.

Modela los recursos de la nube con módulos de Bicep por dominio (redes, datos, computación) y despliégalos a través de suscripciones con ámbito en grupos de administración. Esto produce declaraciones tipadas y mantenibles, un alcance claro y reutilización sin la verbosidad del JSON de ARM.
Usa un número reducido de especificaciones de plantillas ARM vinculadas (linked ARM template specs) para servicios de plataforma compartidos consumidos por múltiples equipos. Las plantillas vinculadas alojadas como especificaciones de plantilla (template specs) proporcionan artefactos inmutables y versionados, y desacoplan la cadencia de la plataforma de la de los equipos de aplicación.
Selecciona Terraform para las dependencias de CDN y de borde (edge) multicloud, con el backend azurerm almacenando el estado remoto en Azure Storage por espacio de trabajo (workspace) (dev/test/prod) y usando leases de blob para el bloqueo. Esto preserva un patrón de pipeline único mientras aísla el estado de forma segura y permite una promoción consistente.
Centraliza la configuración de aplicaciones y los indicadores de características en Azure App Configuration. Los indicadores de características con filtros de porcentaje y etiquetas permiten despliegues por anillos (ring-based rollouts); las instantáneas de configuración aseguran que cada etapa del despliegue consuma un conjunto de claves inmutable y auditado.
Almacena los secretos en Azure Key Vault y referéncialos desde Azure App Configuration. Resolver las referencias en tiempo de ejecución con una identidad administrada permite la rotación de claves sin necesidad de redesplegar y elimina los secretos de la configuración de la aplicación y de los pipelines.
Adopta imágenes inmutables para las cargas de trabajo de VM usando Packer para construir imágenes doradas (golden images) publicadas en Shared Image Gallery. Un pipeline ejecuta scripts de fortalecimiento (hardening) y escaneos de InSpec, etiqueta las imágenes y promueve solo las versiones que pasan las pruebas. Los VM Scale Sets consumen imágenes de la galería para realizar actualizaciones blue/green y continuas (rolling), eliminando la deriva.
Impón barreras de protección con iniciativas de Azure Policy que denieguen la exposición de IP públicas en subredes privadas, requieran configuraciones de diagnóstico hacia Log Analytics y desplieguen automáticamente políticas de copia de seguridad. Asigna a nivel de grupo de administración para una cobertura amplia y crea tareas de remediación para que los recursos existentes converjan rápidamente a la postura deseada.
Protege AKS con OPA/Gatekeeper aplicando restricciones que bloqueen imágenes no conformes y pods con privilegios. Las políticas se almacenan y versionan en Git, se validan con conftest en CI y se aplican a través de GitOps para garantizar que el estado del clúster coincida con la política en todo momento.
Gestiona la configuración de servidores Windows con Azure Automation DSC. Los nodos se registran con Register-AzAutomationDscNode y usan ConfigurationMode=ApplyAndAutoCorrect para detectar y remediar la deriva; los trabajos de compilación emiten archivos MOF por rol, y los paneles de cumplimiento muestran la deriva para su investigación.
Gestiona la configuración y orquestación de Linux con Ansible usando el inventario dinámico azure_rm y los módulos de azure.azcollection. Azure Pipelines se autentica con identidad administrada, ejecuta playbooks de forma idempotente y coordina las actualizaciones entre servicios, complementando a DSC en Windows.
Aprovecha los perfiles de Chef InSpec para el cumplimiento como código (compliance-as-code) multiplataforma tanto en imágenes como en hosts en ejecución, alimentando Chef Automate para la generación de informes. Esto introduce controles auditables y comprobables en el pipeline y en producción, asegurando que los requisitos regulatorios se validen continuamente.

Esta combinación proporciona IaC modular y tipado (Bicep/Terraform), hosts inmutables (Packer), configuración de aplicaciones centralizada (App Configuration/Key Vault), aplicación continua de la configuración (Azure Automation DSC, Ansible) y una gobernanza sólida (Azure Policy, Gatekeeper). Reduce la deriva, acorta los tiempos de recuperación y despliegue, y hace que el cumplimiento sea demostrable.

← Pipelines de CI · Todos los dominios · Contenerización y Kubernetes →

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