Microsoft Azure Developer Associate
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen AZ-204. Lee de arriba a abajo o salta a una sección.
Se necesita un plan de App Service para una aplicación web de producción con dominios personalizados/SSL, escalado automático y ranuras de implementación.
Utilice el nivel de plan de App Service Standard (S1) o superior.
Por qué: Standard es el nivel mínimo que soporta todas las características clave de producción: dominios personalizados con SSL, escalado automático y ranuras de implementación. El nivel Basic carece de escalado automático y ranuras.
Realizar una implementación sin tiempo de inactividad para un App Service y mantener la configuración de producción (como cadenas de conexión) en la ranura de producción.
Utilice ranuras de implementación. Marque la configuración específica de producción como "configuración de ranura de implementación" (persistente/sticky). Realice una operación de intercambio para implementar.
Por qué: La operación de intercambio calienta la ranura de ensayo antes de redirigir el tráfico. La configuración persistente no se mueve con el código durante un intercambio, evitando que la configuración de ensayo pase a producción.
Un App Service necesita conectarse a un recurso local (ej., SQL Server) sin una VPN o ExpressRoute.
Utilice Conexiones Híbridas de App Service. Instale el Hybrid Connection Manager (HCM) en las instalaciones.
Por qué: Las Conexiones Híbridas proporcionan un túnel TCP seguro a los recursos locales sin requerir puertos de firewall de entrada, una VPN o integración de VNet. El HCM inicia la conexión saliente.
Una Función de Azure en el plan de Consumo experimenta arranques en frío prolongados, causando latencia.
Migre al plan Premium de Functions y configure un mínimo de una instancia precalentada.
Por qué: El plan Premium elimina los arranques en frío manteniendo un número específico de instancias siempre listas. Es más rentable que un plan Dedicado completo para este propósito.
Una Función de Azure en el plan de Consumo está experimentando un tiempo de espera excedido porque tarda más de 10 minutos en ejecutarse.
Migre la función a un plan Premium o Dedicado (App Service).
Por qué: El plan de Consumo tiene un tiempo de espera máximo de 10 minutos. Los planes Premium y Dedicados soportan tiempos de ejecución mucho más largos (hasta 60 minutos o ilimitado).
Procesar un gran número de elementos independientes en paralelo y esperar a que todos se completen antes de continuar.
Implemente el patrón Fan-out/Fan-in de Durable Functions. El orquestador llama a múltiples funciones de actividad concurrentemente y utiliza `Task.WhenAll` (o equivalente) para esperar su finalización.
Por qué: Este patrón está diseñado para la ejecución en paralelo, lo que es mucho más eficiente que el procesamiento secuencial (encadenamiento de funciones) para tareas independientes.
Un flujo de trabajo de larga duración debe esperar un evento externo, como la aprobación humana, con un tiempo de espera.
Utilice el patrón de Interacción Humana de Durable Functions. Combine `waitForExternalEvent` con un `createTimer`. Utilice `Task.WhenAny` para proceder cuando el evento llegue o el temporizador expire.
Por qué: Este patrón permite que las orquestaciones se pausen indefinidamente sin consumir cómputo, esperando un desencadenador externo, al mismo tiempo que manejan los tiempos de espera de forma elegante.
Una aplicación en contenedores necesita escalar a cero instancias cuando no hay tráfico para minimizar costos.
Utilice Azure Container Apps con una regla de escalado basada en KEDA (ej., solicitudes HTTP o longitud de cola).
Por qué: Container Apps con escaladores KEDA pueden escalar a cero réplicas cuando están inactivas y escalar bajo demanda, lo cual es ideal para cargas de trabajo impulsadas por eventos o intermitentes. El escalado de CPU/memoria no puede escalar a cero.
Un microservicio backend en Azure Container Apps solo debe ser accesible por otras aplicaciones de contenedor dentro del mismo entorno, no desde Internet público.
Habilite la entrada en la aplicación de contenedor backend y configure la visibilidad del tráfico a `internal`.
Por qué: La entrada interna restringe el acceso al entorno de Container Apps. Otras aplicaciones en el entorno pueden descubrir y llamar al servicio utilizando su FQDN interno.
Se necesita ejecutar un solo contenedor para una tarea simple, una prueba o un trabajo por lotes sin orquestación.
Utilice Azure Container Instances (ACI).
Por qué: ACI es la forma más rápida y sencilla de ejecutar un solo contenedor sin gestionar ninguna infraestructura subyacente. Utilice Container Apps o AKS para orquestar aplicaciones multi-contenedor.
Se necesita construir y enviar una imagen Docker a Azure Container Registry (ACR) desde un Dockerfile local, pero Docker no está instalado localmente.
Utilice el comando `az acr build`.
Por qué: `az acr build` descarga el proceso de construcción a ACR Tasks en la nube. Envía el contexto de construcción a Azure, construye la imagen y la almacena directamente en el registro.
Diseñar un contenedor de Cosmos DB con consultas frecuentes que filtran por una propiedad específica (ej., `region`).
Seleccione la propiedad de alta cardinalidad más consultada como clave de partición (ej., `/region`).
Por qué: Las consultas que incluyen la clave de partición en la cláusula `WHERE` se dirigen a una única partición lógica, evitando costosas consultas de abanico a través de particiones y minimizando el consumo de RU.
Una aplicación distribuida globalmente requiere que las lecturas siempre devuelvan la escritura más recientemente confirmada.
Configure el nivel de consistencia de la cuenta de Cosmos DB a Fuerte.
Por qué: La consistencia Fuerte proporciona una garantía de linealizabilidad, asegurando que las lecturas estén siempre actualizadas. Otros niveles (Sesión, Obsolescencia Limitada, Eventual) sacrifican la consistencia por una menor latencia y mayor disponibilidad.
Se necesita procesar todos los documentos nuevos o actualizados en un contenedor de Cosmos DB en tiempo real para actualizar una vista materializada.
Utilice una Función de Azure con un desencadenador de Cosmos DB, que aprovecha el procesador de cambios.
Por qué: El feed de cambios proporciona un registro persistente de los cambios. El desencadenador de Cosmos DB con el procesador de cambios automatiza la gestión de estado y el equilibrio de carga entre múltiples instancias de función.
Se necesita realizar una operación atómica en múltiples documentos dentro de la misma partición lógica (ej., crear dos y actualizar uno).
Utilice la API `TransactionalBatch` en el SDK de Cosmos DB. Todas las operaciones deben apuntar a la misma clave de partición.
Por qué: TransactionalBatch asegura que todas las operaciones en el lote se realicen con éxito o fallen como una única unidad atómica, evitando actualizaciones parciales. Es más eficiente que un procedimiento almacenado para operaciones por lotes del lado del cliente.
Una carga de trabajo de Cosmos DB es impredecible, con picos y valles significativos en el tráfico.
Configure el rendimiento aprovisionado de escalado automático en la base de datos o contenedor.
Por qué: El escalado automático ajusta automáticamente las RU/s según el uso, asegurando el rendimiento durante los picos y el ahorro de costos durante los valles. Escala entre el 10% y el 100% de las RU/s máximas configuradas.
Los datos se acceden frecuentemente al principio, luego infrecuentemente y finalmente se archivan para retención a largo plazo.
Utilice una combinación de niveles de acceso Hot, Cool y Archive. Automatice las transiciones con una política de administración del ciclo de vida.
Por qué: Alinear el nivel de acceso con el patrón de acceso optimiza el costo. Hot es para acceso frecuente, Cool para infrecuente y Archive para almacenamiento a largo plazo y de bajo costo. Las políticas de ciclo de vida automatizan esto.
Evitar que múltiples procesos modifiquen el mismo blob simultáneamente.
Implemente arrendamientos de blobs. Un proceso adquiere un bloqueo de escritura exclusivo (arrendamiento) en un blob antes de modificarlo.
Por qué: Los arrendamientos proporcionan control de concurrencia pesimista. Una vez que se adquiere un arrendamiento, ningún otro cliente puede escribir en el blob hasta que el arrendamiento se libere o expire.
Almacenar registros de auditoría en Blob Storage y asegurar que no puedan ser modificados ni eliminados durante un período de retención fijo (ej., 7 años).
Configure una política de retención basada en tiempo en el contenedor de blobs. Para retenciones indefinidas, utilice una retención legal.
Por qué: Las políticas de almacenamiento inmutable aplican el estado WORM (Write-Once, Read-Many), lo cual es esencial para el cumplimiento. Una vez bloqueada, una política basada en tiempo no puede ser acortada.
Se necesita categorizar blobs con atributos clave-valor y consultarlos en toda una cuenta de almacenamiento sin listar todos los blobs.
Utilice Etiquetas de Índice de Blob.
Por qué: Las etiquetas de índice son indexadas por el servicio de almacenamiento y pueden ser utilizadas en consultas de filtrado del lado del servidor (`Find Blobs by Tags`). Los metadatos no están indexados y solo pueden filtrarse del lado del cliente después de la lista.
Autenticar usuarios de forma segura en una Aplicación de Página Única (SPA) y adquirir tokens para una API de backend.
Utilice el flujo de Código de Autorización con PKCE (Proof Key for Code Exchange).
Por qué: Esta es la mejor práctica de seguridad actual para clientes públicos. Evita exponer tokens en la URL (a diferencia del flujo Implícito obsoleto) y no requiere un secreto de cliente.
Un servicio en segundo plano o daemon necesita llamar a una API protegida (como Microsoft Graph) sin un usuario autenticado.
Utilice el flujo de Credenciales de Cliente con permisos de Aplicación.
Por qué: Este flujo autentica la propia aplicación utilizando un secreto de cliente o un certificado. Los permisos de aplicación otorgan acceso en toda la organización, sujetos al consentimiento del administrador.
Una API web de nivel intermedio necesita llamar a una API de nivel inferior mientras preserva la identidad original del usuario autenticado.
Implemente el flujo On-Behalf-Of (OBO).
Por qué: La API de nivel intermedio intercambia el token de acceso del usuario por un nuevo token con ámbito para la API de nivel inferior. Esto delega la identidad del usuario de forma segura.
Una aplicación que utiliza MSAL necesita adquirir tokens de manera eficiente, minimizando las solicitudes al usuario.
Siempre llame a `AcquireTokenSilent()` primero. Si falla con una `MsalUiRequiredException`, recurra a un método interactivo como `AcquireTokenInteractive()`.
Por qué: `AcquireTokenSilent()` verifica la caché en busca de un token válido o utiliza un token de actualización para obtener uno nuevo sin interacción del usuario. Esto es crítico para una buena experiencia de usuario.
Un recurso de Azure (ej., App Service, Function) necesita acceder a otro recurso de Azure (ej., Key Vault, SQL Database) sin almacenar credenciales en el código o la configuración.
Habilite una identidad administrada (asignada por el sistema o asignada por el usuario) en el recurso de origen y otórguele permisos RBAC en el recurso de destino.
Por qué: La identidad administrada proporciona una identidad en Microsoft Entra ID para el recurso. Azure gestiona el ciclo de vida de las credenciales, eliminando la necesidad de que los desarrolladores manejen secretos.
Múltiples recursos de Azure necesitan compartir la misma identidad y permisos para acceder a otros servicios.
Cree una única identidad administrada asignada por el usuario y asígnela a todos los recursos requeridos.
Por qué: Una identidad asignada por el usuario tiene un ciclo de vida independiente de cualquier recurso, lo que la hace reutilizable. Una identidad asignada por el sistema está vinculada a un único recurso y se elimina cuando el recurso lo es.
Se necesita otorgar acceso a los secretos de Key Vault utilizando grupos de Azure AD con permisos granulares a nivel de secreto individual.
Utilice el modelo de permisos Azure RBAC para Key Vault. Asigne roles como `Key Vault Secrets User` a las entidades de seguridad.
Por qué: RBAC permite asignaciones de roles a nivel de vault, o de clave/secreto/certificado individual, proporcionando más granularidad que las políticas de acceso, que se aplican a todos los objetos de un tipo en el vault.
Una aplicación necesita tomar los cambios de configuración de Azure App Configuration sin reiniciar.
Utilice el proveedor/SDK de App Configuration y configúrelo para que se actualice monitoreando una clave centinela.
Por qué: El SDK puede verificar periódicamente una clave centinela en busca de cambios. Cuando se actualiza la configuración de la aplicación, también se actualiza la clave centinela, lo que activa que todos los clientes actualicen su configuración.
Se necesita habilitar una nueva característica para un grupo específico de usuarios (ej., beta testers) y un porcentaje de la audiencia general.
Utilice una característica de bandera (feature flag) de Azure App Configuration con un filtro de segmentación (Targeting filter).
Por qué: El filtro de segmentación (Targeting filter) soporta despliegues complejos, permitiendo definir audiencias basadas en usuarios y grupos con porcentajes específicos, además de un porcentaje de despliegue predeterminado para todos los demás.
Se necesita generar un token seguro y de corta duración para otorgar a un cliente acceso a un blob específico.
Cree una SAS de delegación de usuario.
Por qué: Una SAS de delegación de usuario se firma con credenciales de Microsoft Entra ID, no con la clave de la cuenta de almacenamiento. Esto es más seguro porque evita distribuir la clave de la cuenta y el acceso puede ser revocado a través de las políticas de Entra ID.
Solucionar un problema de rendimiento en una aplicación de microservicios visualizando las dependencias e identificando qué servicio downstream está causando alta latencia.
Utilice la característica de Mapa de Aplicaciones en Application Insights.
Por qué: El Mapa de Aplicaciones descubre y muestra automáticamente una vista topológica de su aplicación distribuida, mostrando métricas de salud y rendimiento para cada componente y las llamadas entre ellos.
Rastrear una única solicitud de usuario a medida que fluye a través de múltiples microservicios.
Utilice la vista de detalles de transacción de extremo a extremo en Application Insights. Toda la telemetría se correlaciona mediante un `operation_Id` compartido.
Por qué: Los SDK de Application Insights propagan automáticamente los encabezados W3C Trace Context, permitiendo que toda la telemetría de una única operación se correlacione con el mismo `operation_Id`, lo que habilita una vista unificada.
Diagnosticar un problema de producción: rendimiento lento intermitente frente a una excepción intermitente.
Para un rendimiento lento, utilice Application Insights Profiler. Para excepciones, utilice Snapshot Debugger.
Por qué: Profiler captura rastreos de tiempo a nivel de método para solicitudes lentas ("rutas calientes"). Snapshot Debugger captura la pila de llamadas y las variables locales en el momento en que se lanza una excepción.
Reducir el volumen de datos y el costo de Application Insights de una aplicación de alto tráfico manteniendo datos estadísticamente válidos.
Habilite el muestreo adaptativo en la configuración del SDK de la aplicación.
Por qué: El muestreo adaptativo ajusta automáticamente la tasa de muestreo para mantenerse dentro de un volumen de datos objetivo, muestreando más agresivamente durante el tráfico alto y menos durante el tráfico bajo, preservando telemetría importante.
Monitorear continuamente la disponibilidad de un endpoint de aplicación web desde múltiples ubicaciones geográficas.
Configure una prueba de disponibilidad estándar (prueba de ping de URL) en Application Insights.
Por qué: Las pruebas de disponibilidad envían solicitudes a su endpoint desde los centros de datos de Azure en todo el mundo, proporcionando monitoreo proactivo del tiempo de actividad y la capacidad de respuesta, y activando alertas en caso de fallo.
Crear una alerta que se active cuando una métrica de rendimiento (ej., tiempo de respuesta promedio) exceda un umbral específico durante un período definido.
Cree una regla de alerta de métrica de Azure Monitor. Dirija el recurso y la métrica, configure un umbral estático, tipo de agregación y período de evaluación. Enlace a un grupo de acciones.
Por qué: Las alertas de métricas proporcionan monitoreo de baja latencia y con estado de datos métricos casi en tiempo real, lo cual es ideal para alertas basadas en el rendimiento.
Controlar el uso de la API limitando la frecuencia de llamadas (ej., 100 llamadas/min) frente al total de llamadas durante un período más largo (ej., 10,000 llamadas/mes).
Utilice la política `rate-limit` para la frecuencia de llamadas. Utilice la política `quota` para el volumen total de llamadas.
Por qué: `rate-limit` limita ráfagas a corto plazo y devuelve HTTP 429. `quota` impone un límite de uso a largo plazo (ej., un período de facturación) y devuelve HTTP 403 cuando se excede.
Almacenar en caché las respuestas de la API en API Management para reducir la carga del backend, con la clave de caché variando según un encabezado de solicitud.
Utilice una política `<cache-lookup vary-by-header="..." />` en la sección de entrada y una política `<cache-store duration="..." />` en la sección de salida.
Por qué: Esta combinación de políticas de dos partes habilita el almacenamiento en caché de respuestas. `cache-lookup` verifica si hay un elemento en caché, y `cache-store` guarda la respuesta. Los atributos `vary-by` aseguran entradas de caché únicas para diferentes variaciones de solicitud.
Administrar cambios en una API. Se requiere un cambio que rompe la compatibilidad versus un cambio que no la rompe y necesita ser probado.
Utilice Versiones para cambios que rompen la compatibilidad (ej., /v1, /v2). Utilice Revisiones para cambios que no rompen la compatibilidad y despliegues seguros y escalonados.
Por qué: El versionado permite que múltiples versiones de la API estén activas simultáneamente. Las revisiones permiten modificar una API fuera de línea, probarla y luego convertirla en la revisión "actual" sin tiempo de inactividad.
Notificar a múltiples servicios downstream independientes cuando ocurre un evento en un servicio de Azure (ej., blob creado, grupo de recursos creado).
Utilice Azure Event Grid. Cree un tema del sistema para el recurso de Azure y suscripciones a eventos para cada manejador downstream.
Por qué: Event Grid es un servicio pub/sub basado en push, totalmente administrado, que desacopla a los publicadores de eventos de los suscriptores, habilitando arquitecturas reactivas y basadas en eventos.
Ingerir un flujo de alto volumen de telemetría o datos de eventos (millones de eventos por segundo) de muchos dispositivos.
Utilice Azure Event Hubs.
Por qué: Event Hubs es una plataforma de streaming de datos masivamente escalable diseñada para la ingesta de alto rendimiento. Utiliza un modelo de consumidor particionado para el procesamiento paralelo.
Asegurar que los eventos de la misma fuente (ej., un dispositivo IoT específico) sean procesados en orden por el mismo consumidor.
Envíe eventos a Event Hubs con una clave de partición configurada con el identificador de la fuente (ej., ID del dispositivo).
Por qué: Event Hubs enruta todos los mensajes con la misma clave de partición a la misma partición. Dentro de una partición, se mantiene el orden de los mensajes.
Procesar una secuencia de mensajes relacionados en estricto orden Primero en Entrar, Primero en Salir (FIFO).
Utilice sesiones de Azure Service Bus. Envíe todos los mensajes relacionados con el mismo `SessionId`.
Por qué: Las sesiones proporcionan un flujo concurrente y ordenado de mensajes. Un receptor consciente de la sesión bloquea la sesión, garantizando que los mensajes sean procesados secuencialmente por un único consumidor.
Un único publicador envía mensajes a un tema, pero múltiples suscriptores solo desean un subconjunto de esos mensajes basados en las propiedades del mensaje.
Utilice un tema de Service Bus con múltiples suscripciones. Aplique filtros SQL o filtros de Correlación a cada suscripción.
Por qué: Este es el patrón canónico de publicar-suscribir con enrutamiento basado en contenido. Cada suscripción recibe una copia del mensaje si coincide con su regla de filtro.
Un mensaje no puede ser procesado con éxito después de múltiples reintentos y debe ser apartado para una inspección posterior.
Deje que el mensaje falle el procesamiento hasta que se exceda su conteo máximo de entregas. Se moverá automáticamente a la Cola de Mensajes No Entregables (DLQ).
Por qué: La DLQ es una sub-cola incorporada para mensajes "veneno". Esto evita que un mensaje fallido bloquee la cola principal y permite el análisis y reprocesamiento fuera de línea.
Elija un servicio de mensajería para: comandos empresariales, eventos reactivos o telemetría de alto volumen.
Service Bus para comandos (pedidos, transacciones). Event Grid para eventos reactivos (blob creado, recurso cambiado). Event Hubs para telemetría (datos IoT, clickstreams).
Por qué: Service Bus ofrece características enriquecidas como ordenamiento, transacciones y envío a cola de mensajes no entregables. Event Grid es para enrutamiento de eventos ligero y basado en push. Event Hubs es para streaming de datos de alto rendimiento.
