Microsoft AZ-400: Contenerización y Kubernetes — 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.

Información general

La contenerización y Kubernetes son la base del DevOps moderno en Azure al combinar compilaciones reproducibles, distribución segura y orquestación declarativa y autorreparable en tiempo de ejecución. Dominarlos requiere comprender cómo se ensamblan y optimizan las imágenes, cómo los registros replican y certifican el contenido, cómo se diseña y actualiza AKS sin interrupciones, cómo se implementa la entrega progresiva y cómo proteger las cargas de trabajo de extremo a extremo. Más allá de Kubernetes puro, aprovechará Helm para el empaquetado, GitOps para la reconciliación y, en el espacio sin servidor (serverless), Azure Container Apps con Dapr y KEDA para simplificar los patrones de microservicios y el escalado basado en eventos. Las siguientes secciones resumen las decisiones de plataforma y las prácticas operativas que necesita para implementar canalizaciones robustas y conformes, y clústeres de producción resilientes.

Fundamentos de compilación y registro: Docker y ACR

Una imagen de contenedor de alto rendimiento comienza con un Dockerfile determinista y un contexto de compilación (build context) disciplinado. Las compilaciones multi-etapa (multi-stage builds) le permiten separar las fases de compilación con muchas herramientas de las imágenes de tiempo de ejecución pequeñas. Por ejemplo, compile un binario de .NET o Go en una etapa de compilador (builder stage) y luego copie solo el artefacto compilado en una imagen base mínima o distroless (p. ej., mcr.microsoft.com/dotnet/runtime-deps o gcr.io/distroless/base), lo que resulta en superficies de ataque más pequeñas y tiempos de extracción (pull) más rápidos. Cada RUN, COPY y ADD crea una capa; reestructure los Dockerfiles para maximizar los aciertos de la caché de capas (layer cache) colocando los pasos que cambian con poca frecuencia al final y agrupando comandos con una agrupación lógica mientras se preserva la legibilidad. Incluya siempre un .dockerignore para excluir bin/obj, node_modules, pruebas, documentos y secretos; un contexto de compilación demasiado grande ralentiza las subidas y reduce la eficacia de la caché remota. Utilice instalaciones de paquetes deterministas (fijación de versiones, archivos de bloqueo) y argumentos de compilación (build arguments) con cuidado; los archivos específicos del entorno deben fluir a través de la configuración en tiempo de ejecución, no de imágenes inmutables.

Azure Container Registry (ACR) es la columna vertebral para el almacenamiento y la distribución de imágenes. Aproveche ACR Tasks para descargar las compilaciones a Azure: tareas rápidas para compilaciones bajo demanda (az acr run), tareas automatizadas activadas por commits de Git, actualizaciones de imágenes base o programaciones, y YAML de tareas multi-paso para imágenes multi-arquitectura usando Buildx. La geo-replicación (SKU Premium) replica artefactos entre regiones, minimizando la latencia de extracción y los costos de egreso para implementaciones de AKS/ACA multi-región; combínelo con puntos de conexión privados (private endpoints) y RBAC con alcance de repositorio para aplicar el mínimo privilegio. Habilite la confianza de contenido (content trust) para firmar imágenes y verificar su procedencia: Docker Content Trust/Notary y los ecosistemas de firmas OCI en evolución (p. ej., cosign) se pueden hacer cumplir en la admisión a través de restricciones de OPA Gatekeeper que exigen firmas para los espacios de nombres protegidos. Integre el escaneo de vulnerabilidades: Microsoft Defender for Cloud escanea imágenes al subirlas (push) y en reposo (at rest), expone CVEs con guías de solución y puede bloquear implementaciones a través de Azure Policy y comprobaciones de CI; incluya la automatización de la actualización de la imagen base para reducir las capas con vulnerabilidades conocidas.

Plataforma y entrega de cargas de trabajo en AKS

Cree clústeres de AKS con configuraciones seguras por defecto: identidad administrada, integración con Azure AD para RBAC, Azure CNI para integración con VNET, política de red (Azure o Calico), proveedor de Azure Key Vault (Secrets Store CSI) para el consumo de secretos y clústeres privados con rangos de IP autorizados. Elija pools de nodos apropiados para la carga de trabajo: pools de sistema para componentes críticos del control plane; pools de usuario para aplicaciones; pools de GPU para ML; pools spot para trabajos sin estado que ahorran costos; pools de nodos de Windows para contenedores de Windows. Utilice taints/tolerations y restricciones de distribución de topología (topology spread constraints) para controlar la programación y la resiliencia. Autoescale con el cluster autoscaler y el Horizontal Pod Autoscaler por despliegue; considere discos de SO efímeros y zonas de disponibilidad para el rendimiento y la resiliencia.

Planifique las actualizaciones para minimizar la interrupción. AKS actualiza primero el control plane y luego los pools de nodos. Use max-surge en las actualizaciones de pools de nodos para agregar capacidad adicional (surge), drenar nodos de forma controlada y respetar los PodDisruptionBudgets. Adopte canales de actualización automática (rápido/estable/solo parches) para una cadencia predecible; separe las actualizaciones de los pools de sistema y de usuario para limitar el radio de impacto (blast radius). Realice actualizaciones de la imagen de nodo regularmente para incorporar correcciones del kernel/runtime incluso sin un cambio de versión de Kubernetes, y fije versiones compatibles de CNI/CSI. Utilice pools de nodos blue-green para cambios de plataforma sin tiempo de inactividad: acordone/drene el pool green hacia el blue y realice el cambio a través de nodeSelector/affinity.

Los Deployments en Kubernetes soportan nativamente actualizaciones continuas (rolling updates) con maxUnavailable y maxSurge para mantener la capacidad durante el despliegue; combínelos con sondas de readiness/liveness y sondas de startup para evitar el tráfico prematuro. La entrega blue-green en Kubernetes se implementa ejecutando Deployments paralelos (blue y green) y cambiando un selector de un Service estable o un objeto Endpoint a la revisión de destino; esto produce una reversión casi instantánea al cambiar las etiquetas. La entrega canary se realiza mejor en el borde a través del ingress: NGINX Ingress soporta canary ponderado mediante anotaciones; Application Gateway Ingress Controller (AGIC) puede dividir el tráfico entre backends; los service meshes proporcionan desvío de tráfico (traffic shifting) con políticas granulares y telemetría. Para pipelines robustos, valide con pruebas de humo (smoke tests) y comprobaciones de disponibilidad de App Insights antes de promover los pesos.

Helm empaqueta manifiestos de Kubernetes en charts que comprenden Chart.yaml, plantillas y un values.yaml por defecto. Los archivos de Values se superponen de forma determinista; use superposiciones de values.<env>.yaml y un bloque “global” para configuraciones entre subcharts. Prefiera Helm 3 con almacenamiento de charts basado en OCI en ACR (

undefined

), habilitando paridad de RBAC y georreplicación con las imágenes. En Azure Pipelines, instale Helm en una versión fijada (HelmInstaller) y despliegue (HelmDeploy) a través de una conexión de servicio de Kubernetes/Azure Resource Manager; el linting de plantillas junto con dry-run y diff (plugin helm diff) deben controlar las releases. Evite confirmar secretos en los archivos de values; integre external-secrets o CSI Key Vault para materializar los secretos en tiempo de ejecución. Versione los charts semánticamente y fije appVersion al digest de la imagen para la trazabilidad.

Operaciones, seguridad y control de tráfico

GitOps con Flux o Argo CD asegura que los clústeres converjan continuamente a un estado declarado. Flux v2 se integra nativamente con AKS a través de la CLI/extensión de Azure, reconciliando Sources (Git/OCI/Bucket) y Kustomizations a intervalos, e incluye automatización de imágenes para actualizar Helm/Kustomize a nuevas etiquetas según políticas. Argo CD rastrea Applications y su estado, soporta SSO con Azure AD y puede operar en modelos pull-based y app-of-apps para la separación multi-tenant. Ambos detectan desviaciones (drift) y pueden autocorregirse, emitir eventos/alertas y soportar entrega progresiva; combínelos con Flagger para automatizar canaries y pruebas A/B usando NGINX, Istio o Linkerd, promoviendo en base a métricas y revirtiendo ante incumplimientos de SLO.

La seguridad comienza en la cadena de suministro (supply chain) y se aplica en la admisión y en tiempo de ejecución. Escanee continuamente las imágenes con Defender for Cloud e implemente barreras (gates) en CI/CD. Adopte los Estándares de Seguridad de Pods de Kubernetes (baseline/restricted) con etiquetas de Pod Security Admission en los namespaces para bloquear por defecto pods privilegiados, hostPath y sysctls inseguros. Aplique políticas organizacionales con OPA Gatekeeper: las plantillas de restricciones (constraint templates) prohíben contenedores privilegiados, requieren registros aprobados, exigen límites de recursos y demandan imágenes firmadas o la presencia de SBOM. Aplique políticas de red para definir el tráfico permitido entre pods y de salida (egress); AKS soporta Azure Network Policies (con Azure CNI) y Calico. Complemente con control de salida (egress) mediante Azure Firewall o NVA y un WAF en la entrada (ingress) con Application Gateway. Refuerce las cargas de trabajo con usuarios no-root, sistemas de archivos raíz de solo lectura, perfiles de seccomp y AppArmor, y actualizaciones regulares de la imagen de nodo. Habilite la auditoría y la detección de amenazas a través de Defender for Kubernetes y agregue la telemetría en Azure Monitor Container Insights; estandarice los logs/traces con OpenTelemetry.

Un service mesh (Istio o Linkerd) añade gestión de tráfico, cifrado y observabilidad uniformes. Use DestinationRules/VirtualServices (Istio) o ServiceProfiles (Linkerd) para definir reintentos (retries), tiempos de espera (timeouts), circuit breaking y enrutamiento ponderado. Habilite TLS mutuo (mTLS) para el cifrado e identidad de servicio a servicio; aplique políticas como mTLS “STRICT” para cerrar brechas de seguridad. Exporte métricas a Prometheus y dashboards a Grafana; capture trazas distribuidas (Jaeger/Zipkin) y envíelas a Application Insights o Azure Monitor a través de colectores de OpenTelemetry. Los canaries basados en el mesh y la inyección de fallos (fault injection) potencian pruebas fiables y la entrega progresiva, con Flagger automatizando el análisis frente a los SLO.

Productividad del Desarrollador y Contenedores sin Servidor en Azure

Las herramientas de integración de DevOps para AKS optimizan los ciclos de desarrollo internos (inner loops). Draft detecta los frameworks de lenguaje y genera el esqueleto de Dockerfiles, charts de Helm y configuraciones de lanzamiento, acelerando la contenerización. Bridge to Kubernetes redirige las llamadas de servicio desde un clúster en vivo a tu estación de trabajo local, permitiéndote iterar y depurar un único microservicio localmente mientras el resto se ejecuta en el clúster con datos y dependencias reales. Azure Dev Spaces ha sido retirado; Bridge to Kubernetes es la experiencia de desarrollo local soportada y se integra con VS Code y Visual Studio.

Azure Container Apps (ACA) ofrece un entorno de ejecución sin servidor y totalmente gestionado para microservicios y trabajos sin necesidad de administrar Kubernetes. Cada despliegue crea una revisión; puedes distribuir el tráfico entre revisiones por porcentaje para realizar despliegues de tipo azul-verde o canary con un solo comando o un cambio en YAML. La integración nativa con Dapr habilita la invocación de servicios, pub/sub, bindings, almacenes de estado y secretos sin necesidad de código a medida; los componentes conectables (por ejemplo, Azure Service Bus, Key Vault, Cosmos DB) aceleran la implementación de capacidades consistentes entre servicios. KEDA potencia el autoescalado basado en eventos según la concurrencia HTTP y más de 60 scalers (Azure Queue/Service Bus, Kafka, Prometheus, personalizados), escalando hasta cero para una mayor eficiencia de costos. Utiliza los Entornos de ACA para el aislamiento de red y la integración con VNET, conecta ACR mediante una identidad administrada y gestiona la configuración a través del YAML de containerapps para mantener la paridad declarativa con las prácticas de GitOps.

Escenario de un Problema Práctico

Adobe necesita modernizar un servicio de análisis de clientes multirregional, reduciendo el riesgo de los lanzamientos y reforzando la seguridad de la cadena de suministro y del tiempo de ejecución. El equipo debe estandarizar las compilaciones (builds), automatizar los despliegues seguros y garantizar una entrega rápida y conforme a las normativas en EE. UU. y la UE.

1. Implementar Dockerfiles multi-etapa y .dockerignore para todos los servicios

• Por qué: Minimiza el tamaño de la imagen y la superficie de ataque, mejora los aciertos de la caché de compilación y evita la inclusión accidental de secretos o de grandes activos de prueba en la imagen.

2. Compilar y firmar imágenes con ACR Tasks, y subirlas a un ACR con replicación geográfica

• Por qué: Las compilaciones en la nube eliminan la varianza local; los disparadores por actualización de la imagen base reducen la exposición a CVE. La replicación geográfica de ACR Premium ubica los artefactos junto a los clústeres de AKS, reduciendo la latencia y el egreso. Las firmas permiten verificar la procedencia.

3. Habilitar el escaneo de imágenes de Defender for Cloud y forzar su cumplimiento mediante puertas de CI y OPA Gatekeeper

• Por qué: Los escaneos al hacer push y en reposo detectan CVE de forma temprana. Las restricciones de Gatekeeper imponen políticas como “solo registros aprobados”, “se requieren imágenes firmadas” y límites de recursos, impidiendo la admisión de cargas de trabajo no seguras.

4. Provisionar clústeres de AKS privados por región con Azure CNI, políticas de red e identidad administrada

• Por qué: Los endpoints privados restringen la exposición del plano de control; Azure CNI se integra con las VNETs corporativas; las políticas de red restringen el movimiento lateral; la identidad administrada elimina la proliferación de secretos.

5. Crear node pools de sistema y de usuario separados, añadir spot pools para trabajos por lotes

• Por qué: Aísla los pods críticos de la plataforma, proporciona capacidad rentable para cargas de trabajo no críticas y simplifica las actualizaciones y la gestión de SLO.

6. Adoptar Helm para el empaquetado con charts almacenados en ACR (OCI), desplegar a través de Azure Pipelines

• Por qué: Lanzamientos consistentes y versionados con valores por entorno. Los Pipelines ejecutan helm lint, dry-run y diff antes de helm upgrade, usando una conexión de servicio de Kubernetes para apuntar a los clústeres.

7. Desplegar Flux v2 para la reconciliación con GitOps y la detección de desviaciones, integrar Flagger para despliegues canary

• Por qué: La sincronización declarativa basada en pull reduce las credenciales en la CI y asegura la convergencia. Flagger automatiza los despliegues canary ponderados en función de los SLO utilizando métricas de NGINX Ingress, revirtiendo en caso de errores o picos de latencia.

8. Configurar actualizaciones continuas (rolling updates) con PDBs y sondas de preparación/arranque (readiness/startup probes); usar azul-verde para componentes de riesgo

• Por qué: Las actualizaciones continuas preservan la capacidad; las sondas protegen el tráfico de los usuarios. El despliegue azul-verde con un cambio de etiqueta en el Service permite una reversión instantánea para componentes de alto riesgo como el API gateway.

9. Introducir la malla de servicios Istio con mTLS estricto, reintentos y tiempos de espera; exportar telemetría a Application Insights

• Por qué: Cifrado en toda la malla, políticas de tráfico robustas y observabilidad uniforme. Los colectores de OpenTelemetry envían trazas/métricas a un almacén central para el monitoreo de SLO y la gestión de incidentes.

10. Establecer una estrategia de actualización controlada con el canal de auto-actualización de AKS y actualizaciones de imagen de nodo

• Por qué: Las actualizaciones de plataforma regulares y predecibles reducen la exposición a vulnerabilidades de día cero. Max-surge y los PDBs aseguran una interrupción mínima; las actualizaciones separadas de los node pools de usuario limitan el radio de impacto.

11. Usar Bridge to Kubernetes para el desarrollo en ciclo interno (inner-loop); generar el esqueleto con Draft

• Por qué: Los desarrolladores depuran localmente contra dependencias dentro del clúster sin necesidad de mocks. Draft acelera la contenerización consistente y la generación de esqueletos de Helm entre los equipos.

12. Derivar servicios de cola larga a Azure Container Apps con Dapr y KEDA

• Por qué: Los microservicios basados en eventos y con escalado a cero (p. ej., ingesta y enriquecimiento) se ejecutan a bajo costo con división de tráfico integrada para despliegues canary; los componentes de Dapr estandarizan las llamadas entre servicios y el modelo pub/sub sin código a medida.

Este diseño de extremo a extremo alinea el determinismo de la compilación con la distribución segura, las operaciones declarativas y la entrega progresiva, proporcionando a Adobe lanzamientos rápidos y de bajo riesgo, y un entorno de ejecución reforzado en todas las regiones.

← Infraestructura como código y gestión de la configuración · Todos los dominios · Gestión de lanzamientos y estrategias de despliegue →

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

Explorar Microsoft →