La pregunta más repetida del AZ-305: ¿dónde corre este workload? VM, App Service, AKS, Container Apps, Container Instances o Functions. Cada uno tiene señales claras que el examen usa para apuntarte a la respuesta.
Contenido
Cada pregunta refleja exactamente la lógica que usa el examen. Responde en orden — la primera señal que matches es la respuesta.
🌿Árbol de decisión — ¿Dónde corre este workload?
Responde las preguntas siguiendo el flujo del examen
Pregunta 1
¿El workload necesita control total del SO, drivers, software legacy, o es lift-and-shift sin cambios en el código?
💡 Señal: "acceso al registro de Windows", "agentes propietarios", "licencias por socket"
| Servicio | Señales a favor | Señales en contra |
|---|---|---|
| Virtual Machines | Control total, software con licencia/agentes, GPU específica, lift-and-shift literal | Tú gestionas parches, HA, escala — máxima responsabilidad operativa |
| App Service | Web/API HTTP, slots de deployment, certificados/custom domains administrados, CI/CD integrado | Solo HTTP/S (no TCP arbitrario), workloads no-web |
| AKS | Necesitan la API de Kubernetes: helm charts, operators, sidecars, portabilidad multi-cloud | Overhead operativo del cluster; si no piden K8s explícitamente, suele haber opción más simple |
| Container Apps | "Contenedores sin gestionar Kubernetes", scale-to-zero, eventos (KEDA), microservicios con Dapr | Sin acceso a la API de K8s — si piden operators/CRDs, es AKS |
| Container Instances | Contenedor efímero/puntual, virtual nodes para burst de AKS, sin orquestación | Sin autoscaling ni balanceo nativos — no es para servir apps en producción |
| Functions | Event-driven, ejecuciones cortas, "pagar solo cuando ejecuta" (Consumption), bindings a Storage/Cosmos/Service Bus | Procesos largos (límite de timeout en Consumption), estado complejo (→ Durable Functions) |
| Logic Apps | Integración entre sistemas con conectores (SAP, O365, Salesforce), workflows visuales, B2B | Lógica de cómputo intensivo — eso es código (Functions) |
| Azure Batch | HPC, renderizado, simulaciones — pools de VMs para jobs paralelos masivos | No es para servir aplicaciones |
Hosting de Functions — sub-decisión frecuente
Consumption: pago por ejecución, escala a cero, cold starts, timeout limitado. Flex Consumption: cold start mitigado + VNet. Premium: sin cold start (instancias pre-calentadas), VNet integration, sin límite práctico de duración. Dedicated (App Service plan): reutilizar plan existente. Señal "sin cold starts" o "acceso a VNet" → Premium/Flex.
Familias (reconocerlas basta)
Palancas de costo (caen mucho)
| El escenario dice... | Respuesta |
|---|---|
| App legacy que requiere acceso al registro de Windows | Virtual Machine |
| API REST con slots para blue/green y certificados gestionados | App Service |
| Microservicios con helm charts y operators existentes | AKS |
| Contenedores event-driven que escalan a cero, sin gestionar clusters | Container Apps |
| Job en contenedor que corre 2h una vez al mes | Container Instances (o CA Jobs) |
| Procesar cada mensaje que llega a una cola, pago por uso | Functions (Consumption) |
| Functions con VNet y sin cold start | Functions Premium |
| Orquestar aprobación → SAP → email sin código | Logic Apps |
| Render de video en 500 nodos paralelos | Azure Batch (+ Spot) |
| Reducir costo de VMs 24/7 estables | Reserved Instances + Hybrid Benefit |
| Batch tolerante a interrupciones al mínimo costo | Spot VMs |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo va a desplegar microservicios en contenedores. Requisitos: escalar a cero fuera de horario, escalar por longitud de cola de Service Bus, comunicación servicio-a-servicio con descubrimiento integrado, y el equipo NO quiere administrar clusters de Kubernetes. ¿Qué servicio recomiendas?
Inicia sesión para llevar tu progreso.