Microsoft AZ-104: Azure App Service y Cómputo de PaaS — Guía de estudio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

El portafolio de cómputo PaaS de Azure combina alojamiento de aplicaciones y web totalmente administrado, funciones serverless, automatización de flujos de trabajo, contenedores bajo demanda y contenedores orquestados. Como administrador, el éxito depende de comprender los límites de cada servicio, cómo se conectan a la red y se autentican, y cómo desplegar y escalar de forma fiable. Esta sección cubre App Service (planes, ranuras de implementación, redes y autenticación integrada), Azure Functions y Logic Apps (planes, desencadenadores, conectores), Azure Container Instances y AKS (programación, escalado, herramientas operativas) y el App Service Environment aislado.

Fundamentos de Cómputo de App Service y Functions

Los App Service Plans determinan el grupo de recursos de cómputo para Web Apps, API Apps y Function Apps que se ejecutan en el plan dedicado. Los niveles tienen capacidades y modelos de escalado distintos:

Free (F1) y Shared (D1) se ejecutan en infraestructura compartida con cuotas y sin SLA. Solo son adecuados para experimentos. Características como las ranuras de implementación, la integración con VNet y el autoescalado no están disponibles.
Basic (B) asigna VM dedicadas a pequeña escala con escalado horizontal manual. Carece de autoescalado y ranuras de implementación.
Standard (S) introduce el autoescalado, múltiples instancias, copias de seguridad diarias y ranuras de implementación. Es el punto de entrada para cargas de trabajo de producción que necesitan un entorno de preproducción (staging).
Premium (Pv2/Pv3) aumenta la CPU/memoria, el rendimiento de E/S y los límites de las características (más instancias, más ranuras), y añade redes avanzadas como la integración con Private Endpoint y la redundancia de zona.
Isolated/Isolated v2 se ejecutan dentro de un App Service Environment con cómputo dedicado de inquilino único dentro de su red virtual para un aislamiento estricto y cumplimiento normativo.

El escalado se divide en escalado vertical (scale-up, cambiar el nivel de precios/tamaño de la VM) y escalado horizontal (scale-out, cambiar el número de instancias). El autoescalado requiere el nivel Standard o superior y se basa en reglas de Azure Monitor (CPU, memoria a través de App Service Metrics o métricas personalizadas). Las operaciones de escalado son por App Service Plan y afectan a todas las aplicaciones dentro del plan.

Las ranuras de implementación (deployment slots) proporcionan instancias de la aplicación en vivo en el mismo plan para preparar los cambios en un entorno de preproducción. Las ranuras existen en el nivel Standard y superiores, donde Standard admite menos ranuras y Premium/Isolated admiten más. El intercambio (swap) orquesta una promoción sin tiempo de inactividad intercambiando el contenido y la configuración de la ranura, respetando al mismo tiempo las configuraciones de la ranura (configuraciones de aplicación y cadenas de conexión persistentes que permanecen en la ranura). El intercambio con vista previa (swap with preview) precalienta la ranura de destino y evalúa su estado de salud antes de completarse. Las pruebas en producción (testing in production) enrutan un porcentaje del tráfico de producción a una o más ranuras; el enrutamiento es persistente por cliente para mantener la afinidad de sesión durante una rampa de prueba.

Las redes de App Service ofrecen conectividad de entrada y salida controlada:

La Integración regional con VNet (Regional VNet Integration) enruta el tráfico de salida a una subred delegada en una red virtual en la misma región. Permite la salida hacia private endpoints, a entornos locales (on-premises) a través de VPN/ExpressRoute y a service endpoints. No cambia el comportamiento de la entrada pública.
Private Endpoint publica la aplicación de forma privada dentro de su VNet asignando el frontend de la aplicación a una IP privada; combínelo con restricciones de acceso para forzar la entrada exclusivamente privada fuera de un ASE.
Hybrid Connections proporcionan conectividad TCP de salida desde la aplicación a puntos de conexión específicos de host:puerto en entornos locales (on-premises) o en otras redes a través de Azure Relay, sin requerir cambios en el firewall de entrada. No es un túnel de VNet de propósito general y no es compatible con UDP.
Las Restricciones de acceso (Access Restrictions) evalúan reglas ordenadas de permitir/denegar para IP de clientes, etiquetas de servicio y tráfico de red virtual (a través de Private Endpoints o reglas de VNet multiinquilino). Restrinja el acceso a rangos específicos, VNets o front-ends para cumplir con la normativa.

La Autenticación/Autorización integrada (“Easy Auth”) antepone a su aplicación un manejador de autenticación alojado, descargando la validación de tokens sin necesidad de cambios en el código. Los proveedores compatibles incluyen Microsoft Entra ID (Azure AD), Microsoft Account, Google, Facebook, Twitter y OpenID Connect genérico. Puede exigir el inicio de sesión para todas las solicitudes o permitir el paso a la aplicación, establecer audiencias permitidas y restringir a inquilinos específicos. El almacén de tokens opcional guarda en caché los tokens del proveedor y expone las notificaciones (claims) a través del punto de conexión /.auth/me y los encabezados de la solicitud. Combínelo con una identidad administrada asignada por el sistema para llamar de forma segura a los servicios de Azure posteriores.

Azure Functions ofrece cómputo controlado por eventos a través de tres modelos de alojamiento:

El Plan de consumo (Consumption plan) es serverless con facturación por ejecución y por GB-segundo, y escalado horizontal y a cero automáticos. Tiene arranques en frío (cold starts) y, históricamente, no tenía integración con VNet para algunos desencadenadores; las capacidades más nuevas son más amplias, pero las cargas de trabajo sensibles a la red deben verificar la compatibilidad.
El Plan Premium (Premium plan) elimina el arranque en frío con instancias precalentadas, admite la integración con VNet y Private Endpoints, y escala en función de los eventos con controles de instancias mínimas y máximas.
El Plan dedicado (Dedicated plan, o App Service Plan) ejecuta Functions en la capacidad de su App Service Plan; el costo es por las instancias reservadas independientemente de su uso, con autoescalado opcional a nivel de plan. Los desencadenadores de Functions incluyen HTTP, Temporizador, Almacenamiento (Cola/Blob/Tabla), Service Bus, Event Hubs, Event Grid, Cosmos DB y más, con enlaces de entrada/salida (input/output bindings) para conectar servicios de forma declarativa. Durable Functions añade orquestación con estado (stateful) en un modelo code-first utilizando funciones de orquestador y de actividad, lo que permite patrones como distribución ramificada/concentración (fan-out/fan-in), HTTP asíncrono, interacción humana y sagas. El estado se persiste en un proveedor de almacenamiento (Azure Storage es común), garantizando flujos de trabajo resilientes y reproducibles.

El comportamiento de los costos y el escalado difieren sustancialmente entre los modelos App Service Plan y de Consumo. El App Service Plan cobra por el tamaño y el número de instancias siempre activas y escala según las reglas del plan. El modelo de Consumo de Functions cobra solo por el tiempo de ejecución y la memoria, con escalado automático basado en la concurrencia y escalado a cero. El plan Premium se sitúa entre ambos, combinando capacidad precalentada reservada con escalado en ráfaga (burst scaling).

Contenedores y Kubernetes

Azure Container Instances (ACI) proporciona contenedores bajo demanda, facturados por segundo, sin necesidad de gestionar VMs u orquestadores. La unidad de despliegue es un grupo de contenedores: uno o más contenedores programados en el mismo host, que comparten una IP, puertos, volúmenes y ciclo de vida. Defina CPU/memoria por contenedor, exponga puertos y monte volúmenes como Azure Files, secretos y emptyDir. Las variables de entorno pueden ser de texto plano o seguras (excluidas de los registros/superficies de metadatos). Las políticas de reinicio controlan el ciclo de vida: Always (predeterminado para servicios de larga duración), OnFailure (para trabajos que deben reintentarse ante una salida distinta de cero) y Never (para tareas que se ejecutan hasta completarse y cuyo estado de salida se desea inspeccionar sin reinicios). La red admite IPs públicas, IPs privadas con inyección de VNet en una subred delegada y etiquetas de nombre DNS para los puntos de conexión públicos.

Azure Kubernetes Service (AKS) es un plano de control de Kubernetes gestionado con grupos de nodos aprovisionados como Virtual Machine Scale Sets. Los grupos de nodos diferencian las cargas de trabajo del sistema (componentes de kube-system) de las cargas de trabajo del usuario, admiten múltiples tamaños de VM y pueden ejecutar Linux y Windows (Windows requiere al menos un grupo de nodos de sistema Linux). Los grupos pueden ser marcados con “taint” para controlar la programación de pods. Las actualizaciones se orquestan por grupo, y maxPods, las zonas de disponibilidad y los discos de SO efímeros se configuran en la creación del grupo. El autoescalador del clúster (cluster autoscaler) se integra con la programación de Kubernetes para modificar el número de nodos dentro de los límites mín/máx cuando hay pods pendientes que no pueden ser programados o cuando los nodos están infrautilizados; respeta los Pod Disruption Budgets y solo reduce la escala cuando es seguro hacerlo. El Horizontal Pod Autoscaler complementa esto escalando las réplicas dentro de un Deployment basándose en métricas.

Conceptos básicos de kubectl para la administración del clúster:

Conéctese con

undefined

para fusionar el kubeconfig y seleccionar el contexto.

Inspeccione recursos:

undefined

;

undefined

para detalles y eventos.

Diagnostique e interactúe:

undefined

para stdout/stderr,

undefined

para solución de problemas interactiva.

Aplique el estado deseado:

undefined

; use namespaces para delimitar el alcance de los recursos;

undefined

para cambiar de namespace.

Los plugins de red (Azure CNI o kubenet), la identidad (identidad administrada frente a entidad de servicio o service principal) y la integración con RBAC/Entra ID determinan la asignación de IP a los pods, la autenticación y la autorización del clúster. Asegúrese de que la identidad del clúster tenga permisos para los balanceadores de carga, los discos administrados y los grupos de recursos de los nodos.

Integración, Redes y Seguridad

Logic Apps proporciona un motor de flujos de trabajo gestionado con conectores a cientos de servicios de SaaS y Azure. Un flujo de trabajo se compone de un desencadenador que inicia la ejecución y acciones que realizan los pasos. Los desencadenadores incluyen solicitudes HTTP, periodicidad (Recurrence), mensajes de Service Bus, eventos de Event Grid, eventos de Storage y muchos eventos de SaaS (p. ej., cuando se crea un registro en Dynamics 365). Las acciones incluyen construcciones de control (condiciones, bucles, switch), operaciones de datos (componer, analizar JSON, variables) y operaciones de conector (enviar correo, encolar mensaje, llamar a una API). La integración con los servicios de Azure es profunda:

Service Bus y Event Grid proporcionan mensajería y gestión de eventos fiables para arquitecturas desacopladas.
Se pueden invocar Functions para pasos de código personalizado (HTTP síncrono o asíncrono a través de colas).
La identidad administrada protege el acceso a Key Vault, Storage, SQL y otros recursos de Azure sin necesidad de secretos. Logic Apps Consumption (multitenant) factura por ejecución de acción y uso de conector; Logic Apps Standard (de un solo inquilino) se ejecuta en el runtime de Functions en un App Service Plan o un plan Premium, admite desarrollo local, integración con VNet, puntos de conexión privados y un mayor rendimiento. El Integration Service Environment (ISE) en el plan Consumption proporciona aislamiento de VNet para los conectores gestionados cuando es necesario.

App Service Environment (ASE) implementa el nivel Aislado (Isolated) para App Service. Desplegado en su red virtual, ASE proporciona “stamps” (entornos) dedicados de computación y almacenamiento de un solo inquilino con control de red. Un ASE externo expone puntos de conexión de entrada públicos; un ASE con balanceador de carga interno (ILB) publica solo una VIP privada para un acceso estrictamente privado. Las aplicaciones en un ASE utilizan los niveles de precios Isolated/Isolated v2. Se paga tanto una tarifa por el entorno (“stamp fee”) como los costos por trabajador de instancia. Se elige ASE cuando los requisitos de cumplimiento, aislamiento de red o escala superan las capacidades del App Service multitenant. Con ASE v3, el despliegue y la red se simplifican, pero la propuesta principal se mantiene: un App Service dedicado, direccionable de forma privada, con su VNet como perímetro.

La gobernanza del acceso en estos servicios se basa en Azure RBAC para las acciones sobre recursos, identidades administradas para la autenticación de servicio a servicio y Acceso Condicional (Conditional Access) en el plano de identidad. Para el control de entrada en App Service, combine Private Endpoints o un ILB ASE con restricciones de acceso y front-ends con WAF habilitado (p. ej., Application Gateway o Azure Front Door) según sea necesario. Para el control de salida, utilice la integración con VNet con NSGs, tablas de rutas y puntos de conexión privados para los servicios de datos.

Operaciones de Despliegue y Escalado

Los lanzamientos fiables a App Service utilizan ranuras de despliegue (deployment slots) para validar la salud y calentar las cachés antes de intercambiarlas. Marca la configuración que difiere por entorno como “configuración de ranura” (slot settings) para que no se mueva durante el intercambio (p. ej., cadenas de conexión, indicadores de características). Usa el intercambio con vista previa (swap with preview) para ejecutar sondeos de salud (health probes) o puntos de conexión de calentamiento específicos de la aplicación; si no es saludable, aborta el intercambio. Durante un despliegue canary, habilita el enrutamiento de tráfico para dirigir un pequeño porcentaje persistente (sticky) a una ranura de ensayo (staging) y auméntalo de forma incremental. La configuración de aplicación específica de la ranura puede activar y desactivar características beta de forma segura.

El autoescalado para los App Service Plans se configura en el recurso del plan utilizando perfiles (mín/máx/predeterminado basados en el tiempo) y reglas (umbrales de métricas con paso de escalado y período de enfriamiento). Combina la CPU con métricas personalizadas (p. ej., longitud de la cola) para un escalado más preciso. Para Functions, el plan de Consumo escala automáticamente; supervisa la concurrencia y configura host.json para comportamientos por disparador (p. ej., tamaños de lote y prefetch para Service Bus). El plan Premium escala instancias precalentadas e instancias de ráfaga; alinea el recuento mínimo de instancias con los objetivos de latencia.

En contenedores, las políticas de reinicio de ACI deben reflejar la intención: los trabajos por lotes (batch jobs) usan Never o OnFailure para evitar bucles infinitos; los servicios usan Always. Usa variables de entorno para la configuración y Azure Key Vault para los secretos, inyectándolos mediante Managed Identity y código de inicio o montando los secretos como volúmenes cuando sea apropiado. En AKS, habilita el autoescalador del clúster (cluster autoscaler) con límites mín/máx razonables por grupo de nodos y configura HPAs para los Deployments críticos. Presupuesta un margen de capacidad (headroom) y establece Pod Disruption Budgets para proteger la disponibilidad durante las actualizaciones y el escalado hacia adentro (scale-in). Valida las actualizaciones en un grupo de nodos canary antes de desplegar ampliamente las actualizaciones del clúster o del grupo.

Escenario de Problema Práctico

Fabrikam, Inc. ejecuta un portal de clientes y servicios de procesamiento en segundo plano. Deben modernizarse a PaaS, forzar el acceso de red privado a los almacenes de datos, soportar despliegues azul-verde y ejecutar un ETL nocturno en contenedores sin gestionar VMs.

Alojar el portal en App Service Premium con ranuras de despliegue

Crear un App Service Plan en Premium v3 para un mayor rendimiento y más ranuras, y desplegar la Web App con una ranura de ensayo (staging).
Configurar los ajustes de ranura (slot settings) para valores específicos del entorno y habilitar el intercambio con vista previa (swap with preview) y las comprobaciones de estado.
Razón: El plan Premium ofrece autoescalado, más ranuras, soporte para Private Endpoint y un SLA adecuado para el tráfico de producción. Las ranuras proporcionan lanzamientos azul-verde seguros y enrutamiento canary.

Forzar la entrada privada y la salida controlada

Habilitar un Private Endpoint para la Web App y establecer restricciones de acceso para denegar la red pública.
Configurar la Integración con VNet Regional (Regional VNet Integration) a una subred delegada para el acceso de salida a almacenes de datos privados y locales a través de ExpressRoute.
Razón: Private Endpoint más las restricciones garantizan un acceso exclusivamente privado; la Integración con VNet enruta la salida a través del perímetro de la VNet para una política de firewall consistente.

Implementar el procesamiento en segundo plano con Azure Functions Premium

Desplegar una Function App en un plan Premium con una identidad administrada asignada por el sistema, utilizando disparadores de Service Bus y Storage para cargas de trabajo impulsadas por colas.
Establecer un mínimo de instancias precalentadas para eliminar los arranques en frío e integrarla con la misma VNet.
Razón: Functions Premium cumple con los requisitos de baja latencia y VNet, al tiempo que preserva el escalado sin servidor (serverless) para cargas de trabajo en ráfagas.

Orquestar flujos de trabajo entre servicios con Logic Apps Standard

Construir flujos de trabajo para coordinar el alta de clientes: disparar con un mensaje de Service Bus, llamar a la Function App, escribir en Storage y notificar a través del conector de Microsoft 365.
Usar identidad administrada para el acceso a Key Vault y Storage y desplegar en el mismo App Service Plan para aprovechar la integración con VNet y los private endpoints.
Razón: Logic Apps proporciona una orquestación visual y resiliente y conectores nativos; el plan Standard ofrece integración con VNet y rendimiento de inquilino único (single-tenant).

Ejecutar el ETL nocturno en Azure Container Instances

Definir un grupo de contenedores con el contenedor del ETL, montar un recurso compartido de Azure Files para datos intermedios, establecer variables de entorno seguras y usar restartPolicy: Never.
Asociar el grupo a la subred delegada de la VNet para el acceso privado a las bases de datos.
Razón: ACI ofrece cómputo por segundo orientado a trabajos sin la sobrecarga de un clúster y se integra con la VNet para la localidad de los datos y la seguridad.

Prepararse para microservicios en contenedores con AKS

Crear un clúster de AKS con un grupo de nodos de sistema Linux pequeño y un grupo de nodos de usuario dimensionado para la carga esperada, habilitar el autoescalador del clúster (límites mín/máx) e integrarlo con Entra ID y Azure CNI para IPs a nivel de pod.
Usar kubectl para desplegar un microservicio canary y establecer un HPA basado en CPU y métricas personalizadas.
Razón: AKS proporciona orquestación de nivel empresarial cuando los servicios se multiplican; el autoescalador y el HPA alinean la capacidad con la demanda y kubectl ofrece un control operativo estándar.

← Almacenamiento de Azure · Todos los dominios · Bases de datos de Azure y Servicios de datos →

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