Microsoft AZ-204: Azure App Service y Aplicaciones web — 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 App Service es una plataforma de alojamiento basada en HTTP totalmente administrada para aplicaciones web, API REST y servicios de backend, que admite cargas de trabajo de código y contenedores en Windows y Linux. Proporciona características de primera clase para escalado, flujos de trabajo de implementación, autenticación, aislamiento de red, procesamiento en segundo plano y configuración segura. Su dominio implica comprender los planes y el escalado de App Service, las ranuras de implementación y la gestión del tráfico, las rutas de integración de CI/CD, Easy Auth, los dominios personalizados y TLS, los WebJobs, App Service Environment (ASE) y los patrones de configuración segura con Key Vault.

Planes, escalado y ranuras de implementación

Un plan de App Service define los recursos de computación que alojan sus aplicaciones. Todas las aplicaciones en un plan comparten el mismo grupo de máquinas virtuales y la misma configuración de escalado.

• Niveles de precios:

  • Free (F1)/Shared (D1): Solo para desarrollo y pruebas. Sin SLA. Sin TLS personalizado. Sin ranuras de implementación.
  • Basic (B1–B3): VM dedicadas, escalado horizontal manual. Sin autoescalado. Características limitadas.
  • Standard (S1–S3): Añade autoescalado y ranuras de implementación. Línea base para producción.
  • Premium v2/v3 (P1v2/P1v3+): Computación más nueva, almacenamiento más rápido, características de red mejoradas, redundancia de zona (en SKU compatibles) y mayor escalado. Ideal para producción empresarial y alto rendimiento.
  • Isolated (I1v2+) en ASE: Dedicado a la red virtual de un cliente con aislamiento de red y escalado masivo.

• Escalado vertical vs. escalado horizontal:

  • El escalado vertical mueve el plan a un SKU superior para obtener más CPU, memoria, discos más rápidos o capacidades avanzadas (por ejemplo, Premium v3 para un mejor rendimiento y características).
  • El escalado horizontal aumenta el número de instancias para distribuir la carga horizontalmente. Standard y superiores admiten el autoescalado con reglas basadas en métricas como CPU, memoria (Linux), longitud de la cola HTTP, solicitudes, métricas personalizadas o programaciones. Basic solo admite el escalado horizontal manual. El escalado se aplica a todas las aplicaciones dentro de un plan.

• Ranuras de implementación e intercambios de ranuras:

  • Los niveles Standard y superiores admiten múltiples ranuras (por ejemplo, preproducción y producción). Las ranuras se ejecutan en el mismo plan, cada una con su propio nombre de host y configuración.
  • El intercambio mueve el contenido y el estado de tiempo de ejecución de una ranura de origen a una de destino con un tiempo de inactividad casi nulo al “calentar” el destino antes de la transición del tráfico. Use applicationInitialization (Windows) o comprobaciones de estado para asegurar que esté listo antes del intercambio. El intercambio con vista previa permite la validación antes de finalizar.
  • Marque las entradas de configuración como configuraciones de ranura para mantenerlas adheridas a la ranura durante los intercambios (por ejemplo, cadenas de conexión de base de datos, secretos y puntos de conexión de diagnóstico). Las configuraciones no marcadas se mueven con el código durante el intercambio.

• Enrutamiento de tráfico con ranuras:

  • Enrute un porcentaje del tráfico en vivo a una ranura que no sea de producción para pruebas canary (probar en producción). Las cookies fijan a los usuarios a una ranura después de la asignación para preservar la consistencia de la sesión.

Implementación y CI/CD: GitHub, Azure DevOps y registros de contenedores

El Centro de implementaciones integra los flujos de CI/CD más comunes:

• GitHub Actions:
  • App Service puede generar un flujo de trabajo utilizando la compilación de Oryx o la implementación de contenedores. Al hacer un push a una rama, Actions compila e implementa en la ranura seleccionada. Soporte para compilaciones matriciales, entornos y secretos. Para contenedores de Linux, el flujo de trabajo puede compilar y enviar a ACR o Docker Hub, y luego desencadenar una implementación de la aplicación web.
• Azure DevOps:
  • Los Pipelines (YAML o clásicos) ofrecen etapas de compilación y lanzamiento, aprobaciones, comprobaciones de entorno y puertas de enlace multietapa. Use tareas como: Azure Web App, Azure Web App for Container o AzureCLI para implementaciones habilitadas con ARM/Bicep. Los grupos de variables y los secretos respaldados por Key Vault centralizan la configuración.
• Registros de contenedores:
  • App Service for Containers extrae imágenes de ACR, Docker Hub o registros privados. Configure la implementación continua a través de webhooks de ACR a la aplicación; un nuevo push de imagen desencadena una extracción y un reinicio. Fije por etiqueta o digest. Para la seguridad en producción, use digests de imagen y ranuras canary antes de promover.
• Mecánicas de implementación adicionales:
  • Kudu admite el push basado en Git, Zip Deploy y Run From Package para compilaciones reproducibles. El archivo .deployment y los scripts personalizados pueden coordinar los pasos de compilación antes de que el sitio sirva tráfico. Para una higiene de lanzamientos de nivel empresarial, combine las ranuras con CI/CD para validar las comprobaciones de estado y el calentamiento antes del intercambio.

Seguridad, identidad, dominios y TLS

La autenticación/autorización de App Service (Easy Auth) delega la identidad a la plataforma sin requerir middleware en su código.

• Proveedores:
  • Microsoft Entra ID (plataforma de identidad de Microsoft), Google, Facebook, GitHub y Twitter, además de cualquier proveedor compatible con OpenID Connect, incluido Entra ID B2C. Configure los ID de cliente/secretos, el emisor y las audiencias/ámbitos de token permitidos. Elija la acción de inicio de sesión (permitir anónimos vs. requerir autenticación).
• Almacén de tokens y encabezados:
  • Habilite el almacén de tokens para almacenar en caché los tokens de acceso/actualización obtenidos durante el flujo de inicio de sesión, recuperables a través de /.auth/me y actualizables a través de /.auth/refresh. App Service inyecta las notificaciones del usuario en los encabezados de la solicitud (por ejemplo, X-MS-CLIENT-PRINCIPAL en Base64) para que la aplicación pueda derivar la identidad sin dependencias de SDK. Use el punto de conexión de cierre de sesión de la plataforma para limpiar las sesiones.
• Dominios personalizados:
  • Asigne registros CNAME (recomendado) o A/ALIAS al nombre de host predeterminado de la aplicación. Verifique la propiedad del dominio con registros TXT si es necesario. Vincule el nombre de host personalizado en App Service.
• Certificados SSL/TLS:
  • Fuerce solo HTTPS y establezca la versión mínima de TLS. Vincule certificados mediante SNI (múltiples certificados por IP) o SSL basado en IP (IP dedicada). Cargue certificados privados (PFX) para un control de certificados de nivel de producción. El Certificado administrado de App Service proporciona un certificado gratuito, de renovación automática y con validación de dominio para nombres de host sin comodín; no se puede exportar y requiere un nivel compatible. Use la integración con Key Vault para gestionar y rotar automáticamente los certificados privados a escala.
• Certificados de cliente (mTLS):
  • Opcionalmente, requiera certificados de cliente entrantes y páselos a la aplicación para su validación. Combine con Web Application Firewall y proxies inversos (por ejemplo, Application Gateway) para un TLS de extremo a extremo.

Procesamiento en segundo plano y entornos aislados

Los WebJobs y ASE abordan escenarios de procesamiento en segundo plano y aislamiento de red.

• WebJobs:
  • Los WebJobs continuos se ejecutan perpetuamente en cada instancia de la aplicación web, adecuados para el procesamiento de colas o bucles de eventos. Requieren Always On (Standard y superior) para mantenerlos en ejecución. El escalado sigue el número de instancias del plan de la aplicación; aplique un comportamiento de singleton en el código si solo se desea un trabajador activo.
  • Los WebJobs desencadenados se ejecutan bajo demanda o según una programación (CRON a través de settings.job). Ideales para trabajos por lotes, ETL o mantenimiento periódico.
  • El SDK de WebJobs proporciona desencadenadores y enlaces para Azure Storage Queues, colas/temas de Service Bus, Blobs y Timers con métodos de función declarativos y checkpointing automático. Un WebJob desencadenado por una cola reacciona inmediatamente a nuevos mensajes, escala con las instancias de la aplicación y utiliza el manejo de colas de mensajes dudosos (poison queue) para el aislamiento de fallos. Los registros y paneles son accesibles en Kudu.
• App Service Environment (ASE):
  • ASEv3 aloja planes de App Service dentro de su VNet con SKU Isolated v2, proporcionando cómputo dedicado, aislamiento del plano de datos e IP privadas. Elija un ASE externo para la entrada pública o un ASE con Internal Load Balancer (ILB) para mantener todo el tráfico de entrada privado dentro de la VNet. Intégrelo con DNS privado, firewalls y NVA/WAF según sea necesario.
  • ASE permite un control de salida granular, inspección de red y alineación con el cumplimiento normativo. Soporta alojamiento a gran escala con límites de red predecibles y se factura por separado de las instancias del plan.

Configuración, cadenas de conexión y referencias a Key Vault

La configuración de la aplicación se inyecta en tiempo de ejecución y puede ser específica de la ranura (slot).

• Configuración de la aplicación:
  • Pares clave-valor disponibles para la aplicación como variables de entorno. Márquelos como configuración de ranura para mantener valores distintos por ranura. Utilice la ruta de comprobación de estado (Health check) para eliminar instancias no saludables de la rotación durante los despliegues (rollouts). Los cambios provocan reinicios de la aplicación a menos que se configuren con patrones de recarga dinámica en su framework.
• Cadenas de conexión:
  • Se gestionan por separado y se exponen como variables de entorno; las aplicaciones .NET también reciben una configuración específica del proveedor. Los tipos incluyen SQLAzure, SQLServer, MySQL, PostgreSQL y Custom. Márquelas como configuración de ranura cuando sea apropiado para evitar el intercambio de secretos.
• Referencias a Key Vault:
  • Haga referencia a secretos directamente en la Configuración de la aplicación y en las Cadenas de conexión usando la sintaxis especial @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) o URIs sin versión para recoger las rotaciones automáticamente. Asigne una identidad administrada asignada por el sistema o por el usuario a la aplicación, y luego otórguele permisos “Get secret” (RBAC o política de acceso) en el vault. La plataforma resuelve y actualiza los valores sin exponer los secretos en la configuración de App Service. Para usar certificados TLS desde Key Vault, impórtelos como certificados o use referencias de certificado soportadas por la plataforma.

Análisis detallado de las ranuras de implementación y excelencia operativa

Use una ranura de ensayo como destino de CI/CD. Después de la implementación:

• Ejecute pings de calentamiento y comprobaciones de estado para preparar el JIT, las cachés y las conexiones de la base de datos.
• Valide las diferencias de configuración utilizando las configuraciones de ranura para aislar los secretos y los puntos de conexión de producción.
• Realice un intercambio con vista previa para probar la ranura de ensayo en el nombre de host de producción antes de finalizar. Si surgen errores, cancele el intercambio para revertir instantáneamente.
• Para la entrega progresiva, utilice el enrutamiento de tráfico para dirigir un pequeño porcentaje a la ranura canary y supervise las métricas y los registros de Application Insights. Aumente gradualmente y luego complete el intercambio cuando los SLO se mantengan.

Escenario de un problema práctico

Starbucks está lanzando una nueva plataforma de pedidos web que debe manejar picos de demanda durante las promociones, integrarse con inicios de sesión sociales, proteger las API internas y procesar flujos de trabajo de pedidos en segundo plano de manera fiable.

1. Elija un plan de App Service Premium v3 con dos ranuras de implementación (ensayo, producción)

• Por qué: Premium v3 proporciona CPU y SSD más rápidos para cargas de página de baja latencia y mayor rendimiento, además de ranuras y escalado automático. Las ranuras permiten intercambios sin tiempo de inactividad y una reversión rápida ante picos de tráfico promocionales.

2. Implemente CI/CD con GitHub Actions para desplegar en la ranura de ensayo

• Por qué: GitHub Actions ofrece automatización nativa del repositorio. Desplegar en la ranura de ensayo permite el calentamiento y la validación antes de que el tráfico de los clientes se vea afectado. El flujo de trabajo utiliza Oryx para compilar y desplegar en cada push a main, garantizando compilaciones consistentes.

3. Habilite Easy Auth con proveedores de Microsoft Entra ID y Google; habilite el Almacén de tokens

• Por qué: Easy Auth descarga los flujos de OAuth/OIDC, reduciendo la superficie de código de seguridad personalizado. Múltiples proveedores admiten las preferencias de inicio de sesión de los consumidores. El Almacén de tokens simplifica las llamadas a API posteriores (por ejemplo, al microservicio de perfiles de fidelidad) utilizando tokens almacenados en caché y expuestos a través de los puntos de conexión /.auth.

4. Configure dominios personalizados y TLS

• Por qué: Vincule order.starbucks.com mediante CNAME, fuerce “Solo HTTPS” y establezca un mínimo de TLS 1.2 por cumplimiento normativo. Use un Certificado administrado de App Service para la ranura de ensayo para reducir la sobrecarga de gestión, y cargue un PFX de la CA corporativa para producción para satisfacer la política de marca y de certificados.

5. Use el SDK de WebJobs con un desencadenador de Azure Storage Queue para el procesamiento de pedidos

• Por qué: Un WebJob continuo procesa los mensajes a medida que llegan, desacoplando el pago del procesamiento y suavizando los picos. Con “Always On” y el escalado horizontal basado en el plan, el rendimiento aumenta automáticamente con instancias adicionales. El manejo de la cola de mensajes dudosos (poison queue) aísla los mensajes incorrectos sin interrumpir el proceso.

6. Asegure los secretos de salida con referencias de Key Vault y una identidad administrada asignada por el sistema

• Por qué: Los secretos nunca residen en la configuración de App Service. La identidad tiene acceso con privilegios mínimos a Key Vault, y los URI de secretos sin versión permiten una rotación sin interrupciones.

7. Proteja las API internas con redes

• Por qué: Coloque los microservicios internos detrás de un punto de conexión privado; la aplicación web pública los llama a través de la Integración con VNet (Premium v3) hacia un backend protegido. Si se necesita un aislamiento más estricto en el futuro, migre la capa web a un ILB ASE para que todo el tráfico de entrada sea privado, manteniendo al mismo tiempo las capacidades de App Service.

8. Estrategia de lanzamiento con canarying e intercambio

• Por qué: Dirija el 5% del tráfico a la ranura de ensayo para la validación en vivo durante una promoción. Supervise la latencia, los presupuestos de error y la conversión en el proceso de pago a través de Application Insights. Si el estado es saludable, realice un intercambio con vista previa; si no, cancele e investigue, preservando la experiencia del cliente.

Todos los dominios · Azure Functions y Computación sin servidor →

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

Explorar Microsoft →