Microsoft AZ-204: Azure Functions y Computación sin servidor — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — 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

Azure Functions es un servicio de computación sin servidor (serverless) optimizado para cargas de trabajo efímeras e impulsadas por eventos. Abstrae la infraestructura para que puedas centrarte en el código que responde a eventos de puntos de conexión HTTP, colas, blobs, fuentes de cambios de datos y servicios de streaming. Seleccionas un plan de hospedaje que rige el escalado, los precios y el comportamiento de arranque en frío (cold start); vinculas tu código a desencadenadores (triggers) y orígenes de datos con enlaces declarativos; y, opcionalmente, compones flujos de trabajo fiables y de larga duración utilizando Durable Functions. Una configuración robusta, un despliegue repetible y una observabilidad profunda con Application Insights completan la plataforma para sistemas de nivel de producción.

Planes de hospedaje, escalado y arranques en frío

La selección de un plan de hospedaje determina las características de ejecución y el costo.

• Plan de consumo:

  • Escalado y precios: Paga por ejecución y por consumo de recursos. La plataforma escala horizontalmente de forma automática en función de los eventos. El número de instancias se reduce a cero cuando está inactivo.
  • Límites de ejecución: El tiempo de espera (timeout) de la función es configurable hasta 10 minutos para funciones no HTTP; las funciones HTTP tienen tiempos de espera prácticos más cortos debido a la conectividad del cliente.
  • Arranque en frío (Cold start): Los arranques en frío ocurren después de períodos de inactividad o durante un escalado horizontal (scale-out) cuando se inicializan nuevas instancias. El tiempo de arranque depende del lenguaje, las dependencias y el tamaño de la aplicación.
  • Redes/características: Admite redes públicas por defecto. Conjunto de características limitado en comparación con el plan Premium (por ejemplo, sin integración con VNET). Las ranuras de despliegue (deployment slots) no están disponibles.

• Plan Premium:

  • Escalado y precios: Escala en función de los eventos, pero mantiene instancias «precalentadas» (pre-warmed) para eliminar los arranques en frío. Se factura por segundos de núcleo y memoria asignada para las instancias activas y precalentadas.
  • Límites de ejecución: Duración de ejecución prácticamente ilimitada (sujeta a las restricciones del cliente HTTP). Recomendado para cargas de trabajo pesadas o sensibles a la latencia.
  • Mitigación del arranque en frío: Las instancias precalentadas mantienen el entorno de ejecución activo (hot). Controlas el número de instancias precalentadas por plan, lo que proporciona una latencia predecible bajo ráfagas de carga (burst).
  • Redes/características: Admite integración con VNET, puntos de conexión privados, tamaños de instancia mayores y ranuras de despliegue (deployment slots).

• Plan dedicado (App Service):

  • Escalado y precios: Se ejecuta en instancias de App Service aprovisionadas con reglas de escalado manual o automático. Pagas por el plan de App Service subyacente, independientemente de su uso.
  • Límites de ejecución: Sin tiempo de espera (timeout) impuesto por la plataforma para la ejecución en segundo plano. Ideal si ya tienes capacidad de App Service de sobra o necesitas un rendimiento constante.
  • Mitigación del arranque en frío: Habilita la opción «Always On» para mantener la aplicación cargada. No escala a cero; las instancias permanecen activas (warm).

Elige el plan de consumo para cargas de trabajo esporádicas y optimizadas en costos, el Premium para necesidades de baja latencia y VNET, y el dedicado para consolidar con la capacidad existente de App Service o cuando se requiere un control total. Para una latencia ultrabaja, el plan Premium con instancias precalentadas o el dedicado con «Always On» reducen los arranques en frío. Minimiza aún más el impacto del arranque en frío reduciendo las dependencias, usando la ejecución desde un paquete (run-from-package) e inicializando los clientes de forma diferida (lazily).

Desencadenadores y enlaces

Las funciones se activan mediante desencadenadores e interactúan con los datos a través de enlaces. Los desencadenadores definen cómo y cuándo se ejecuta una función. Los enlaces se conectan declarativamente con servicios externos para entrada/salida sin código imperativo de SDK.

Desencadenadores comunes:

• Desencadenador HTTP: Expone puntos de conexión para API de estilo REST o webhooks. Los niveles de autorización incluyen Anónimo, Función y Administrador, aplicados mediante claves o autenticación de la plataforma. Considere la idempotencia y los tiempos de espera para tareas de larga duración; descargue a una cola o a Durable Functions cuando sea necesario.
• Desencadenador de temporizador: Las programaciones basadas en CRON se ejecutan en una única instancia por aplicación (por temporizador). Use expresiones NCRONTAB con configuración de zona horaria. Ideal para trabajos de mantenimiento, sondeo y limpieza.
• Desencadenador de Azure Storage Queue: Responde a los mensajes de una cola. Admite el manejo de mensajes dudosos (poison messages) con una cola -poison después de alcanzar un umbral en el recuento de retiradas. Configure el tamaño del lote, el tiempo de espera de visibilidad y la concurrencia a través de host.json.
• Desencadenador de Azure Blob Storage: Reacciona a eventos de creación/actualización de blobs utilizando una combinación de sondeo y notificaciones de Event Grid. Use patrones de ruta para limitar el alcance a contenedores y prefijos. Comprenda la consistencia eventual y el comportamiento de reintento para cargas de blobs grandes.
• Desencadenador de Azure Event Hubs: Consume flujos de eventos de alto rendimiento con puntos de control (checkpointing). Configure la concurrencia de particiones, el tamaño del lote y la captura previa (prefetch) para el rendimiento. Adecuado para telemetría y procesamiento de flujos con el orden preservado por partición.
• Desencadenador de Azure Service Bus: Admite la suscripción a colas o temas. Configure los comportamientos de maxConcurrentCalls, prefetch y autocompletado. Las colas de mensajes fallidos (dead-letter queues) capturan los mensajes que superan los intentos de entrega para su inspección posterior.
• Desencadenador de Azure Cosmos DB: Escucha el canal de cambios (change feed) para inserciones y actualizaciones. Escala con el número de particiones físicas; asegure un aprovisionamiento suficiente de RU. Use la colección de concesiones (leases) para coordinar el escalado horizontal entre instancias.

Enlaces:

• Enlaces de entrada: Suministran datos a la función, p. ej., contenido de un blob, una entidad de tabla, documentos de Cosmos DB o metadatos de un mensaje de cola. En .NET, los atributos (p. ej.,

undefined

) o function.json definen el enlace; en otros lenguajes, la configuración es declarativa.

• Enlaces de salida: Escriben datos sin SDK, p. ej., encolar un mensaje, crear un blob, enviar a Event Hub/Service Bus o escribir en Cosmos DB. Las funciones pueden tener múltiples enlaces de salida o devolver una única salida desde la firma de la función.
• Expresiones de enlace: Parametrice los detalles de conexión y las rutas utilizando marcadores de posición, p. ej., {queueTrigger}, {rand-guid}, y configuraciones de aplicación basadas en el entorno. Las propiedades de conexión hacen referencia a los nombres de la configuración de la aplicación, permitiendo la rotación y la gestión de secretos. Prefiera las conexiones basadas en identidad con identidad administrada donde sea compatible para evitar incrustar secretos.
• Concurrencia y lotes: Controle la concurrencia y los tamaños de los lotes en host.json por extensión (queues, serviceBus, eventHub) para ajustar el rendimiento y el uso de memoria. Valide el manejo de mensajes dudosos/fallidos para asegurar que los fallos se hagan visibles.

Diseñe los desencadenadores y enlaces para la idempotencia, la contrapresión y el aislamiento de fallos. Para fuentes de entrega de tipo «al menos una vez» (at-least-once) (colas, Event Hubs, Service Bus), escriba funciones que sean idempotentes y resilientes a los reintentos.

Durable Functions: Patrones de orquestación fiables

Durable Functions extiende Azure Functions con orquestación fiable y con estado para flujos de trabajo de larga duración utilizando un marco de tareas duraderas.

Tipos de función:

• Funciones de orquestador: Describen la lógica del flujo de trabajo en código utilizando construcciones deterministas. Los orquestadores reproducen el estado al recibir eventos y deben evitar las API no deterministas (DateTime.Now, números aleatorios, llamadas de red) sin los ayudantes apropiados. Use las API del cliente de orquestación duradera para iniciar, consultar y gestionar instancias.
• Funciones de actividad: Ejecutan unidades de trabajo discretas como llamar a API externas, realizar operaciones ligadas a la CPU o tareas de E/S. Las actividades son reintentables y escalables de forma independiente.
• Funciones de entidad: Proporcionan entidades duraderas y direccionables con un estado pequeño y consistente y operaciones (p. ej., contadores, estado de un dispositivo). Las entidades procesan operaciones serializadas con consistencia de un solo hilo.

Patrones:

• Encadenamiento de funciones: Secuencia actividades en un orden definido (A → B → C), pasando los resultados a la siguiente. Útil para canalizaciones con dependencias.
• Fan-out/fan-in: Inicia múltiples actividades en paralelo y agrega los resultados. Los orquestadores coordinan con una semántica similar a Task.WhenAll. Use esto para el procesamiento en paralelo de tareas independientes.
• Interacción humana (eventos externos): Espera una entrada externa (p. ej., una aprobación) utilizando WaitForExternalEvent con tiempos de espera y escalado. Combine con temporizadores duraderos para implementar SLA y lógica de compensación.
• API HTTP asíncronas: Inicia orquestaciones y devuelve un 202 Accepted con URL de estado/consulta. Los clientes sondean los puntos de conexión de estado expuestos por el enlace del cliente duradero para obtener el resultado o estado final.
• Monitor: Puntos de control recurrentes que se ejecutan según una programación, p. ej., sondeando un punto de conexión hasta que se cumple una condición, utilizando temporizadores duraderos para evitar retener recursos de cómputo.
• Agregador/Entidad: Almacene un estado pequeño junto a la lógica utilizando funciones de entidad para una coordinación detallada sin un flujo de trabajo completo.

Durable Functions garantiza la ejecución «al menos una vez» de las actividades y la progresión «exactamente una vez» del estado del orquestador. Persisten el estado en el almacenamiento (el predeterminado es Azure Storage); asegúrese de que la cuenta de almacenamiento cumpla con las necesidades de rendimiento y fiabilidad. Use políticas de reintento personalizadas para fallos transitorios y genere eventos para la interacción externa. Para procesos muy largos, las orquestaciones duraderas pueden ejecutarse durante días o meses con durabilidad incorporada.

Configuración, Despliegue y Observabilidad

La configuración de una Function App se organiza en capas y es consciente del entorno.

• host.json: Controla el comportamiento del tiempo de ejecución (runtime) y de las extensiones. Configura el registro (muestreo, niveles de log), functionTimeout, ajustes de extensiones (tamaños de lote, concurrencia, prefetch) y la versión del esquema JSON. Mantén host.json en el control de versiones.
• local.settings.json: Ajustes de desarrollo local, incluyendo cadenas de conexión y configuración de la aplicación. No se despliega en Azure. Trata los secretos de forma adecuada; exclúyelo de repositorios públicos y usa user-secrets o inyección de entorno para el desarrollo local.
• Application settings: Se almacenan en la configuración de la Function App (App Service). Los ajustes críticos incluyen AzureWebJobsStorage (para la cuenta de almacenamiento usada por los disparadores, logs y puntos de control), cadenas de conexión específicas de extensiones y cualquier configuración personalizada. Marca los secretos como ajustes de ranura (slot settings) para evitar que se intercambien. Usa referencias de Key Vault con identidad administrada para evitar almacenar secretos en texto plano.

Opciones de despliegue:

• Zip Deploy: Sube un archivo ZIP con los artefactos de tu compilación a la aplicación. Rápido y simple para CI/CD. Usa

undefined

o la API zipdeploy. Escribe los archivos en el directorio de contenido.

• Run-From-Package: Establece WEBSITE_RUN_FROM_PACKAGE a la URL de un paquete (o 1 para el más reciente). El runtime monta el paquete en modo de solo lectura, mejorando el arranque en frío y eliminando problemas de bloqueo de archivos durante el despliegue. Almacena el paquete en Blob Storage con una URL SAS para reversiones (rollbacks) reproducibles.
• Ranuras de despliegue (Deployment slots): Las ranuras de ensayo (staging) y producción permiten intercambios (swaps) sin tiempo de inactividad con calentamiento (warmup). Las ranuras son compatibles con los planes Premium y Dedicated. Configura ajustes específicos de la ranura (marcador de slot setting) para secretos y puntos de conexión (endpoints) para prevenir fugas entre entornos. Usa el calentamiento pre-intercambio (preSwap warmup) para validar extensiones y enlaces (bindings) antes de que el tráfico se mueva.

Monitorización con Application Insights:

• Registros de invocación: Cada invocación de una función emite telemetría estructurada que incluye Solicitudes (Requests), Trazas (Traces), Excepciones (Exceptions) y Dependencias (Dependencies). Usa ILogger (o equivalente) para registros estructurados. Los IDs de operación y correlación conectan la actividad y las dependencias a través de los servicios.
• Métricas en vivo (Live Metrics): Vista en tiempo real del rendimiento (throughput), fallos y latencia sin muestreo. Útil para observar despliegues, escalado y rutas críticas (hot paths). Filtra por nombre de función para aislar problemas.
• Fallos y fiabilidad: Inspecciona las Excepciones, las Solicitudes fallidas y los fallos de dependencias. Configura alertas sobre la tasa de fallos, anomalías en FunctionExecutionCount o el crecimiento de la cola DLQ/cola de mensajes dudosos (poison queue). Para disparadores de Storage Queue, monitoriza la cola -poison; para Service Bus/Event Hubs, monitoriza la cola de mensajes fallidos (dead-letter) y la salud de los puntos de control (checkpoint). Ajusta las políticas de reintento y el retroceso exponencial (backoff) en host.json para reducir el impacto de errores transitorios.
• Trazado distribuido: Habilita las cabeceras de trazado W3C para propagar la correlación a través de HTTP y mensajería. Para Durable Functions, el framework enlaza la telemetría de la orquestación y la actividad, ayudando en el diagnóstico de extremo a extremo. Ajusta el muestreo para equilibrar el costo y la fidelidad.

Opera las funciones con automatización de despliegues (GitHub Actions/Azure Pipelines), sondeos de salud (health probes) para puntos de conexión HTTP y ajustes conscientes del autoescalado. Mantén los paquetes ligeros, almacena en caché los clientes (p. ej., HttpClient, cliente de Service Bus) como singletons estáticos y valida que los ajustes de conexión de los enlaces se resuelvan al inicio para prevenir fallos en tiempo de ejecución.

Escenario de Problema Práctico

Contoso Retail lanza un servicio de promociones que aplica descuentos en tiempo real cuando los clientes añaden artículos a su carrito. El backend debe responder a un tráfico de alta variabilidad con baja latencia, llamar a una API de precios de terceros y actualizar un documento de carrito en Cosmos DB. El equipo de operaciones quiere despliegues sin tiempo de inactividad y una visibilidad profunda de los fallos.

1. Elegir el plan de alojamiento y estructurar la aplicación

• Usar un plan Premium de Azure Functions con dos instancias precalentadas e integración con VNET. El plan Premium elimina los arranques en frío para interacciones de carrito sensibles a la latencia y asegura el tráfico saliente hacia la API de terceros a través de un NAT o firewall en la VNET.
• Crear una única Function App con una función disparada por HTTP para el punto de conexión del carrito y un orquestador de Durable Functions para coordinar la obtención del descuento y la actualización del carrito.

2. Implementar orquestación con Durable Functions para fiabilidad y paralelismo

• Función orquestadora: Encadena los pasos para validar la entrada, se expande (fan out) para obtener los descuentos de cada artículo del carrito en paralelo mediante funciones de actividad, y luego converge (fan in) para agregar el mejor precio. La orquestación duradera asegura un flujo de control determinista y resiliencia ante reinicios.
• Funciones de actividad: Una actividad llama a la API de terceros con políticas de reintento; otra actualiza el carrito en Cosmos DB a través de un enlace de salida (output binding). Las actividades encapsulan la E/S externa y pueden ser reintentadas de forma independiente sin duplicar la lógica del orquestador.

3. Configurar disparadores y enlaces (bindings) para simplicidad

• Disparador HTTP con autenticación de tipo Function para aceptar solicitudes firmadas desde el frontend web. Devuelve un 202 con una URL de estado para carritos de larga duración, o un 200 para rutas rápidas.
• Enlace de salida de Cosmos DB en la actividad para realizar un “upsert” del documento del carrito. Las expresiones de enlace usan el cartId de la carga útil HTTP para apuntar a la clave de partición correcta.
• Usar identidad administrada y conexiones basadas en identidad para Cosmos DB y referencias de Key Vault, eliminando los secretos de la configuración de la aplicación.

4. Optimizar la configuración y el despliegue

• host.json establece functionTimeout en ilimitado (Premium) y configura tiempos de espera HTTP amigables con mallas de servicios (service mesh). Los niveles de registro se ajustan a Information para producción y el muestreo (Samples) se establece en un 20% para controlar el costo.
• Usar run-from-package con paquetes almacenados en un contenedor de Blob versionado. Desplegar vía CI con

undefined

e intercambiar a través de una ranura de ensayo a producción para lanzamientos sin tiempo de inactividad. Marcar las cadenas de conexión y los puntos de conexión de API como ajustes de ranura para evitar fugas entre entornos.

5. Monitorizar y operar

• Habilitar Application Insights y Live Metrics para observar el rendimiento y la latencia durante los lanzamientos. Configurar alertas para HTTP 5xx, tasa de fallos de dependencia hacia la API de precios y aumentos en las orquestaciones fallidas de Durable Functions.
• Usar el trazado distribuido para correlacionar la solicitud HTTP con la orquestación de Durable Functions y las dependencias de actividad, acelerando el análisis de causa raíz para problemas intermitentes de terceros.

Por qué estas elecciones:

• El plan Premium con instancias precalentadas asegura una latencia consistentemente baja y soporta la integración con VNET para una salida segura (egress).
• Durable Functions proporciona un encadenamiento fiable y expansión/convergencia (fan-out/fan-in) con gestión automática de estado y reintentos para llamadas a APIs externas.
• Los enlaces (bindings) reducen el código repetitivo (boilerplate) y fuerzan un acceso a datos declarativo y consistente a Cosmos DB.
• Run-from-package y las ranuras ofrecen despliegues repetibles y atómicos sin problemas de bloqueo de archivos ni tiempo de inactividad.
• Application Insights ofrece observabilidad en tiempo real, correlación y alertas alineadas con los SLAs operativos.

← Azure App Service y Aplicaciones web · Todos los dominios · Azure Storage y Blob Storage →

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

Explorar Microsoft →