Azure — Fundamentos y Arquitectura (Perfil Senior Backend/Microservicios)

1. ¿Cómo organizas suscripciones, Management Groups y Resource Groups en una organización grande?

Categoría: Gobernanza y organización · Tipo: Conceptual

📝 Respuesta resumen

La jerarquía es: Tenant (Entra ID) → Management Groups → Suscripciones → Resource Groups → Recursos. Los Management Groups agrupan suscripciones para aplicar Azure Policy y RBAC de forma heredada; las suscripciones son el límite de facturación, cuotas y aislamiento; los Resource Groups agrupan recursos con el mismo ciclo de vida. En organizaciones grandes se sigue el patrón de Landing Zones del Cloud Adoption Framework: MGs por función (Platform, Landing Zones, Sandbox, Decommissioned) y suscripciones por producto/entorno.

📖 Respuesta detallada

La jerarquía de gobernanza en Azure tiene cuatro niveles y cada uno resuelve un problema distinto:

Management Groups (MG): se pueden anidar hasta 6 niveles (sin contar el root ni las suscripciones). Su función es la herencia: una Azure Policy o una asignación RBAC en un MG aplica a todas las suscripciones descendientes. El patrón recomendado por el Cloud Adoption Framework (Enterprise-Scale / Landing Zones) es: un MG raíz de la organización, debajo Platform (con suscripciones de Connectivity, Identity y Management), Landing Zones (dividido en Corp para cargas internas y Online para cargas expuestas a Internet), Sandbox y Decommissioned. Errores comunes: asignar políticas directamente en el Tenant Root Group sin pruebas (rompes todo el tenant), o crear MGs que replican el organigrama de la empresa en lugar de los requisitos de gobierno (las políticas se aplican por tipo de carga, no por departamento).

Suscripciones: son el límite duro de: facturación, cuotas (p. ej., vCPUs por región, ~980 cuentas de almacenamiento por región por defecto), límites de ARM (800 recursos por tipo por Resource Group, 980 Resource Groups por suscripción) y ciertos límites de red. También son un límite de seguridad práctico: un Owner de suscripción no ve otras suscripciones. La estrategia moderna es “subscription democratization”: una suscripción por producto y entorno (p. ej., pagos-prod, pagos-dev) en lugar de suscripciones gigantes compartidas, que generan conflictos de cuotas, ruido en Activity Log y radios de explosión enormes.

Resource Groups (RG): agrupan recursos que comparten ciclo de vida (se despliegan y eliminan juntos). El RG tiene una región, pero solo para los metadatos; puede contener recursos de varias regiones (aunque no es recomendable, porque si la región del RG cae, no puedes modificar los recursos aunque sigan funcionando). RBAC y locks (CanNotDelete, ReadOnly) se aplican a nivel de RG con frecuencia. Error común: usar RGs como carpetas temáticas (“todas las bases de datos aquí”) en lugar de por ciclo de vida, lo que hace imposible eliminar un entorno de forma limpia o aplicar IaC coherente.

Herramientas de gobierno asociadas: Azure Policy (deny, audit, deployIfNotExists, modify) para forzar tagging, regiones permitidas, SKUs prohibidas o diagnósticos obligatorios; iniciativas (policy sets) como las de CIS o Microsoft Cloud Security Benchmark; Azure Blueprints está deprecado en favor de Template Specs + Deployment Stacks. En costos, los tags obligatorios (cost-center, owner, env) aplicados con policy modify son la base del chargeback en Microsoft Cost Management.

En entrevista conviene cerrar con el trade-off: más suscripciones = mejor aislamiento y cuotas dedicadas, pero más overhead de redes (peering/hub-spoke), más gestión de identidades y más complejidad de facturación. El equilibrio típico: suscripción por producto+entorno, políticas en MGs, y recursos compartidos (hub de red, DNS privado, Log Analytics) en suscripciones de plataforma.

2. Diseño de redes: VNets, subnets, NSGs, Private Endpoints y peering

Categoría: Redes · Tipo: Conceptual

📝 Respuesta resumen

Una VNet es un espacio de direcciones privado regional dividido en subnets; los NSGs filtran tráfico L3/L4 por subnet o NIC con reglas por prioridad; los Private Endpoints dan una IP privada de tu VNet a servicios PaaS (SQL, Storage, Key Vault) eliminando la exposición pública; el peering conecta VNets (incluso entre regiones) sin tránsito por Internet. El patrón estándar es hub-spoke: hub con firewall/VPN/DNS, spokes por carga, y resolución DNS privada con zonas privatelink.*.

📖 Respuesta detallada

VNet y subnets. Una VNet es regional y define uno o más rangos CIDR privados. Azure reserva 5 IPs por subnet (red, gateway, 2 de DNS, broadcast), así que una /24 da 251 IPs útiles. Las subnets segmentan por función: snet-aks, snet-privatelink, snet-appgw, AzureFirewallSubnet y GatewaySubnet (estos dos últimos con nombres obligatorios). Con AKS y Azure CNI tradicional, cada pod consume una IP de la subnet: subestimar el CIDR es un error clásico que obliga a re-crear el clúster; Azure CNI Overlay lo mitiga dando a los pods un CIDR privado independiente.

NSGs. Filtran tráfico con reglas stateful evaluadas por prioridad (100–4096; menor número gana). Se asocian a subnet o a NIC; si hay ambos, el tráfico entrante evalúa primero subnet y luego NIC. Usa Service Tags (AzureCloud, Storage.WestEurope, AzureMonitor) en lugar de IPs, y Application Security Groups para agrupar VMs por rol. Para diagnosticar, VNet Flow Logs (los NSG Flow Logs están en retirada, con deshabilitación en junio 2025 y retirada en septiembre 2027) hacia Log Analytics + Traffic Analytics. Error común: olvidar que las reglas default permiten todo el tráfico intra-VNet (AllowVnetInBound), por lo que microsegmentar exige reglas deny explícitas.

Private Endpoints vs Service Endpoints. Un Service Endpoint optimiza la ruta hacia el servicio PaaS y permite restringir el firewall del recurso a la subnet, pero el servicio conserva su IP pública y no es accesible desde on-premises. Un Private Endpoint crea una NIC con IP privada en tu subnet que apunta a una instancia concreta del recurso: el tráfico nunca sale del backbone, funciona desde on-premises vía VPN/ExpressRoute, y permite bloquear por completo el acceso público (publicNetworkAccess: Disabled). El costo es ~0,01 USD/hora por endpoint más procesamiento de datos, y la complejidad principal es DNS: necesitas Private DNS Zones (privatelink.database.windows.net, privatelink.blob.core.windows.net, etc.) enlazadas a todas las VNets que resuelven, o un Azure DNS Private Resolver para on-premises. El fallo típico: el cliente resuelve la IP pública porque la zona privada no está enlazada a su VNet, y la conexión falla porque el firewall del recurso bloquea acceso público.

Peering. Conecta VNets con latencia de backbone; el global peering cruza regiones. No es transitivo: en hub-spoke, dos spokes no se ven entre sí salvo que enrutes por un NVA/Azure Firewall en el hub con UDRs (0.0.0.0/0 → IP del firewall), o uses Virtual WAN que sí ofrece transitividad gestionada. El peering cobra por GB de entrada y salida (~0,01 USD/GB intra-región, más caro entre regiones). Límite práctico: los espacios de direcciones no pueden solaparse, así que un IPAM disciplinado (p. ej., un /16 por landing zone) es crítico desde el día uno; corregir solapamientos después implica re-crear VNets.

3. Identidad: Entra ID, Service Principals, Managed Identities y RBAC

Categoría: Identidad y seguridad · Tipo: Conceptual

📝 Respuesta resumen

Entra ID es el plano de identidad: usuarios, grupos, app registrations y service principals. Para que un servicio se autentique contra Azure, la opción preferida es Managed Identity (system-assigned o user-assigned), porque elimina secretos: Azure inyecta y rota las credenciales. RBAC autoriza sobre recursos con asignaciones de rol (quién + qué rol + en qué scope), con herencia desde MG hasta recurso. Regla de oro: nunca guardar client secrets si una Managed Identity puede hacer el trabajo, y asignar roles a grupos, no a individuos.

📖 Respuesta detallada

App Registration vs Service Principal. La app registration es la definición global de una aplicación (multi-tenant posible); el service principal es su instancia en un tenant concreto, y es lo que recibe asignaciones de rol. Un SP se autentica con client secret (caduca, se filtra, aparece en pipelines) o certificado (mejor). El problema operativo de los SPs es el ciclo de vida de credenciales: expiraciones que tumban pipelines y secretos en variables de entorno. Por eso el orden de preferencia moderno es: 1) Managed Identity, 2) Workload Identity Federation (OIDC, p. ej. GitHub Actions o pods de AKS intercambian su token por uno de Entra sin secreto alguno), 3) SP con certificado, 4) SP con secret solo como último recurso.

Managed Identities. Son service principals gestionados por Azure. La system-assigned nace y muere con el recurso (1:1, buena para identidad única por servicio); la user-assigned es un recurso independiente que se comparte entre varios recursos (útil para flotas de instancias o para pre-crear asignaciones RBAC antes del despliegue, rompiendo dependencias circulares en IaC). El código las consume vía DefaultAzureCredential del SDK de Azure Identity, que en runtime pide tokens al endpoint IMDS (169.254.169.254) o al endpoint de identidad del App Service. En AKS lo actual es Workload Identity (federación OIDC entre la service account de Kubernetes y una user-assigned identity), que sustituye al deprecado pod-identity. Detalle senior: los tokens de MI se cachean (~24h en IMDS); si cambias asignaciones RBAC, la propagación puede tardar minutos y el token viejo seguir en caché, lo que confunde durante troubleshooting.

RBAC. Una asignación = principal (usuario, grupo, SP/MI) + rol + scope (MG, suscripción, RG, recurso). Se hereda hacia abajo. Roles clave: Owner, Contributor (no gestiona accesos), Reader, User Access Administrator, y roles de datos como Storage Blob Data Contributor o Key Vault Secrets User. Punto que distingue a un senior: distinguir plano de control vs plano de datos. Ser Contributor de una Storage Account no te deja leer blobs vía Entra ID; necesitas un rol de datos (o usar las access keys, que deberías deshabilitar con allowSharedKeyAccess: false). Lo mismo con Key Vault en modo RBAC. Límite: 4.000 asignaciones de rol por suscripción; asignar a grupos en lugar de a individuos evita agotarlo y simplifica auditoría.

Buenas prácticas de examen y de vida real: PIM (Privileged Identity Management) para acceso Just-In-Time a roles privilegiados con aprobación y expiración; Conditional Access para exigir MFA y bloquear legacy auth; custom roles solo cuando los built-in no bastan (mantienen coste de mantenimiento); revisar con Access Reviews. Error común en microservicios: usar una única identidad compartida “porque es más fácil” — pierdes trazabilidad, mínimo privilegio y la capacidad de revocar un servicio comprometido sin afectar al resto. Cada microservicio debe tener su propia identidad con exactamente los roles que necesita en el scope más estrecho posible.

4. Cómputo: ¿cuándo elegir AKS, Container Apps, App Service o Functions?

Categoría: Cómputo y arquitectura · Tipo: Conceptual

📝 Respuesta resumen

Functions para cargas orientadas a eventos y de corta duración; App Service para aplicaciones web/API “clásicas” sin necesidad de orquestación; Container Apps para microservicios contenedorizados con scale-to-zero, Dapr y KEDA sin operar Kubernetes; AKS cuando necesitas control total del plano de Kubernetes: operadores, service mesh, GPU, DaemonSets, multi-tenant complejo o portabilidad estricta. La decisión es un gradiente de control vs responsabilidad operativa: AKS da más control y más carga operativa; Functions, lo contrario.

📖 Respuesta detallada

Azure Functions. Modelo FaaS con triggers/bindings (HTTP, Service Bus, Event Hubs, Cosmos change feed, timers). Planes: Consumption (scale-to-zero, cold starts, timeout por defecto 5 min y máximo 10), Flex Consumption (scale-out más rápido, VNet integration y always-ready instances), Premium EP1-EP3 (sin cold start con pre-warmed instances, VNet, ejecución sin límite práctico de tiempo) y Dedicated (App Service Plan). Ideal para glue code, procesamiento de mensajes, tareas programadas y APIs de tráfico irregular. Mal encaje: procesos de larga duración con estado (salvo Durable Functions), dependencias pesadas que agravan el cold start, o throughput sostenido altísimo donde el Premium acaba costando más que contenedores.

App Service. PaaS para web apps y APIs (código o contenedor). Te da deployment slots (staging con swap sin downtime), autoscale por métricas, certificados gestionados, Easy Auth e integración VNet. Es la opción de menor fricción para una API monolítica o pocos servicios. Límites a conocer: escala hasta 30 instancias (100 en Isolated/ASE), el autoscale es por App Service Plan (todas las apps del plan escalan juntas), y no hay orquestación entre apps (sin service discovery nativo, sin jobs complejos). SKUs: usa mínimo P0v3/P1v3 para producción; Basic/Standard no tienen slots suficientes ni rendimiento adecuado.

Container Apps (ACA). Kubernetes gestionado y abstraído (sobre AKS interno), con KEDA para autoscaling por eventos (largo de cola de Service Bus, lag de Kafka…), scale-to-zero, Dapr integrado (service invocation con mTLS, pub/sub, state stores), revisiones para traffic splitting (canary/blue-green declarativo) y ACA Jobs para tareas. Facturación por vCPU-segundo y GiB-segundo en Consumption, o Dedicated workload profiles para cargas estables o con requisitos (GPU, más de 4 vCPU por réplica en consumption). Es el sweet spot para microservicios: obtienes el 80% del valor de Kubernetes sin gestionar nodos, upgrades ni CNI. Lo que NO te da: acceso a la API de Kubernetes, CRDs/operadores, DaemonSets, control del scheduler o service mesh propio.

AKS. Kubernetes completo: tú eliges CNI (Azure CNI, Overlay, Cilium), node pools (spot, GPU, ARM), operadores (Kafka, Postgres), Istio/Linkerd, Karpenter (Node Auto Provisioning), y políticas con Gatekeeper. El plano de control es gratuito en el tier Free (Standard, con SLA 99,95% con Availability Zones, cuesta ~0,10 USD/h por clúster); pagas los nodos. La contrapartida: upgrades de versión (soporte de ~12 meses por versión + LTS de 2 años), gestión de certificados internos, capacity planning, seguridad de nodos y un equipo con expertise real de Kubernetes. Elegir AKS “porque es lo estándar” cuando el equipo son 4 backend devs sin plataforma es el error de arquitectura más caro y común.

Regla de decisión para la entrevista: empieza por el requisito, no por la tecnología. ¿Event-driven, efímero? Functions. ¿API web sencilla? App Service. ¿Microservicios contenedorizados sin equipo de plataforma? Container Apps. ¿Necesitas primitivas de Kubernetes, multi-tenancy fuerte, mesh o portabilidad? AKS. Y menciona el costo total: AKS barato en cómputo puede ser caro en personas.

5. Azure SQL vs Cosmos DB: consistencia, particionado y RUs

Categoría: Datos · Tipo: Conceptual

📝 Respuesta resumen

Azure SQL es relacional, transaccional, con consultas ad-hoc ricas y escalado principalmente vertical (o Hyperscale hasta 128 TB); Cosmos DB es NoSQL multi-modelo, con latencia <10 ms garantizada por SLA, escalado horizontal por particiones y distribución global con 5 niveles de consistencia. Cosmos cobra por Request Units: cada operación cuesta RUs y el diseño de la partition key decide si escalas o sufres hot partitions y 429s. Elige SQL para modelos relacionales y reporting; Cosmos para alta escala de lecturas/escrituras por clave con esquema flexible y multi-región.

📖 Respuesta detallada

Azure SQL Database. Modelos de compra: DTU (legacy) y vCore (recomendado), con tiers General Purpose, Business Critical (réplicas locales, lecturas en secundaria, baja latencia de IO) y Hyperscale (hasta 128 TB, snapshots casi instantáneos, hasta 4 réplicas de lectura con named replicas). Serverless con auto-pause para cargas intermitentes. Alta disponibilidad: SLA hasta 99,995% con zone redundancy; DR con failover groups (auto-failover con listener endpoint, RPO típico ~5 s con replicación asíncrona). Fortalezas: transacciones ACID multi-fila, joins, integridad referencial, columnstore para analítica ligera, y el ecosistema de tooling. Debilidad: escalar escrituras más allá de una instancia exige sharding manual (elastic pools ayudan al costo, no al sharding).

Cosmos DB. Base multi-modelo (API NoSQL/documentos es la principal; también MongoDB, Cassandra, Gremlin, Table). Conceptos clave que un senior debe dominar:

• RUs (Request Units): moneda de throughput. Un point-read de 1 KB cuesta 1 RU; una escritura de 1 KB ~5 RUs; las queries cuestan según ítems evaluados e índices. Modos: provisioned (manual o autoscale, que escala entre el 10% y el 100% del máximo configurado y cuesta 1,5× la tarifa por RU) y serverless (pago por RUs consumidas, bueno para cargas pequeñas/irregulares, con límites de almacenamiento y throughput por contenedor). Si excedes el presupuesto de RUs en un segundo, recibes 429 (rate limiting) con x-ms-retry-after-ms.
• Particionado: la partition key divide los datos en particiones lógicas (máximo 20 GB cada una) alojadas en particiones físicas (máximo 10.000 RU/s y 50 GB cada una). El throughput provisionado se reparte uniformemente entre particiones físicas: con 30.000 RU/s y 3 particiones, cada una tiene 10.000; si el 80% del tráfico va a una partición (hot partition), recibes 429s aunque el total no llegue al límite. Una buena partition key tiene alta cardinalidad, distribuye escrituras y aparece en los filtros de las queries (para evitar cross-partition queries, que abanican a todas las particiones y multiplican costo y latencia). Patrones: clave sintética (tenantId_fecha), y hierarchical partition keys para superar los 20 GB por tenant.
• Consistencia (5 niveles): Strong (linealizable; en multi-región aumenta latencia de escritura porque exige quórum global), Bounded Staleness (retraso acotado en K versiones o T segundos; útil para multi-región con garantías de orden), Session (el default y el sweet spot: consistencia de lectura de tus propias escrituras dentro de una sesión/token), Consistent Prefix y Eventual. Trade-off directo: más consistencia = más latencia y hasta el doble de costo de RU en lecturas (Strong/Bounded cobran 2× en lecturas con multi-región). Multi-region writes da escritura local en todas las regiones con resolución de conflictos (last-writer-wins por defecto, o custom).

Decisión. SQL cuando: relaciones complejas, transacciones entre entidades, reporting/BI, equipo SQL-first. Cosmos cuando: acceso dominado por clave de partición, esquema variable, necesidad de latencia de un dígito de ms, escala de escritura horizontal o distribución global activa-activa. Antipatrón frecuente: usar Cosmos como base relacional (queries cross-partition con joins simulados en aplicación) → costo explosivo; o usar SQL para telemetría masiva de escritura → cuellos de botella. Muchos sistemas maduros usan ambos: Cosmos para el hot path operacional y SQL/Synapse/Fabric para lo analítico, conectados por el change feed.

6. Mensajería: Service Bus vs Event Grid vs Event Hubs

Categoría: Mensajería e integración · Tipo: Conceptual

📝 Respuesta resumen

Service Bus es mensajería empresarial: colas y topics con entrega fiable, transacciones, sesiones (orden por clave), DLQ, dedup y scheduled messages — para comandos y flujos de negocio. Event Grid es enrutamiento de eventos discretos push con filtrado y entrega a webhooks/handlers — para notificaciones reactivas (“algo pasó”). Event Hubs es ingesta de streaming masivo con particiones, consumer groups y retención con relectura — para telemetría, logs y pipelines tipo Kafka. Se combinan: no compiten entre sí, resuelven patrones distintos.

📖 Respuesta detallada

Service Bus — mensajería de mensajes (commands, integración entre servicios donde perder un mensaje cuesta dinero):

• Colas (competing consumers) y topics con suscripciones (pub/sub con filtros SQL o de correlación por suscripción).
• Garantías: at-least-once con PeekLock (lock por defecto 30 s, renovable; Complete/Abandon/DeadLetter), transacciones que agrupan operaciones, duplicate detection por MessageId en ventana configurable (hasta 7 días), scheduled messages y deferral.
• Sesiones: garantizan FIFO y procesamiento con afinidad por SessionId (un consumidor por sesión a la vez) y permiten session state — es la respuesta a “necesito orden por entidad” (p. ej., eventos de un mismo pedido).
• DLQ automática por cola/suscripción: mensajes van allí por MaxDeliveryCount excedido (default 10), TTL expirado o errores de filtro. La DLQ no se vacía sola: necesitas un proceso de reprocesamiento/alerta.
• Tiers: Standard (tamaño máximo de mensaje 256 KB, recursos compartidos, latencia variable) y Premium (1 messaging unit ≈ recursos dedicados, mensajes hasta 100 MB, VNet/Private Endpoints, latencia predecible, geo-DR de metadatos). Producción seria de microservicios = Premium.

Event Grid — enrutador de eventos discretos, push, serverless:

• Modelo: fuentes (Blob Storage, Resource Groups, Key Vault, custom topics, partner topics) → suscripciones con filtrado por tipo/subject/atributos → handlers (Functions, webhooks, Service Bus, Event Hubs, Storage Queues).
• Entrega at-least-once con reintentos con backoff durante 24 h y dead-lettering opcional a Storage. Pago por operación (~0,60 USD por millón), sin capacidad que aprovisionar. Además del modelo push clásico, hoy ofrece namespaces con pull delivery y soporte MQTT para IoT.
• Úsalo para reaccionar a cambios (“blob creado” → procesar archivo; “secreto cerca de expirar” → rotar) y para fan-out ligero de eventos de dominio hacia sistemas interesados. No lo uses como cola de trabajo con garantías de orden o buffering prolongado: no es su función.

Event Hubs — ingesta y streaming de alto volumen (el “Kafka de Azure”, con endpoint compatible Kafka):

• Modelo de log particionado: eventos se escriben en particiones (elige bien la partition key para no crear particiones calientes), los consumidores leen por consumer groups manteniendo offsets propios mediante checkpointing (típicamente en Blob Storage con el SDK EventProcessorClient).
• Retención: 1–7 días en Standard (hasta 90 con Premium/Dedicated), lo que permite releer el stream (reprocesos, nuevos consumidores). Capacidad por Throughput Units (Standard: 1 TU = 1 MB/s o 1.000 eventos/s de ingreso), Processing Units (Premium) o Capacity Units (Dedicated).
• No hay DLQ ni lock por mensaje: la unidad de fallo es el offset del consumidor. Si tu handler falla, tú decides si avanzas el checkpoint (pierdes el evento) o no (bloqueas la partición) — de ahí la importancia de manejar poison events con salida lateral.

Regla de decisión: ¿Comando dirigido a un servicio, con orden, transacciones o DLQ? Service Bus. ¿Notificación reactiva de que algo ocurrió, con fan-out barato? Event Grid. ¿Stream continuo de miles/millones de eventos por segundo con relectura? Event Hubs. Patrón combinado común: Event Hubs ingesta telemetría → Stream Analytics/Functions procesan → Service Bus para los comandos derivados → Event Grid notifica estados a sistemas externos.

7. API Management: rol en una arquitectura de microservicios

Categoría: Integración y APIs · Tipo: Conceptual

📝 Respuesta resumen

APIM es la fachada única de las APIs: aplica autenticación (validate-jwt contra Entra ID), rate limiting y quotas, transformación de requests, caching, versionado y revisiones, y expone un developer portal con suscripciones y keys. En microservicios actúa como API gateway centralizado delante de AKS/Container Apps, desacoplando el contrato público de la topología interna. Los tiers van de Consumption (serverless) a Premium (multi-región, VNet); el self-hosted gateway permite ejecutar el gateway junto a las cargas (incluso on-premises) manteniendo el plano de control en Azure.

📖 Respuesta detallada

Qué resuelve. Sin gateway, cada microservicio implementa su propia autenticación, throttling, CORS y versionado, y los clientes acoplan a la topología interna. APIM centraliza estas políticas cross-cutting mediante un pipeline de policies XML aplicables a nivel global, de producto, de API o de operación, en las fases inbound, backend, outbound y on-error.

Policies clave para backend senior:

• validate-jwt / validate-azure-ad-token: valida tokens de Entra ID (issuer, audience, claims, scopes) en el borde, de modo que los servicios internos pueden confiar en el gateway (aunque en zero-trust igualmente revalidan o usan mTLS).
• rate-limit-by-key (ráfagas, p. ej. 100 req/min por subscription key o por IP) y quota-by-key (volumen por periodo, p. ej. 1M req/mes) — la distinción ráfaga vs cuota aparece mucho en entrevistas.
• cache-lookup/cache-store con caché interna o Redis externa: quita presión de lecturas repetidas.
• Transformación: rewrite-uri, set-header, json-to-xml, mocking de respuestas para desarrollo paralelo.
• retry, forward-request con timeouts y circuit breaking básico (en backends modernos hay circuit breaker nativo por backend y load balancing entre pools de backends).

Versionado y ciclo de vida. Versions (v1, v2 — cambios breaking, visibles al consumidor por path/query/header) vs revisions (cambios no-breaking, con posibilidad de probar una revisión antes de hacerla current). Products agrupan APIs con términos de suscripción y aprobación. El developer portal da onboarding self-service con subscription keys — importante: las keys identifican al consumidor, no lo autentican fuerte; para seguridad real se combinan con OAuth2/JWT.

Tiers y límites. Consumption: serverless, pago por ejecución (~0,042 USD por 10k llamadas tras 1M gratis), sin VNet injection y con límites de caché — bueno para APIs pequeñas. Basic/Standard: producción ligera. Premium: VNet injection (el gateway dentro de tu red, necesario para backends totalmente privados), multi-región activo-activo, varias unidades de escala, self-hosted gateways; cuesta ~2.800 USD/mes por unidad, lo que sorprende si no se presupuesta. Existen además los tiers v2 (Basic v2, Standard v2, Premium v2) con despliegue más rápido y VNet integration de salida desde Standard v2. Datos de capacidad: una unidad Premium maneja del orden de miles de req/s dependiendo del peso de las policies (validate-jwt y transformaciones cuestan CPU); se monitoriza con la métrica Capacity y se escala horizontalmente.

Arquitectura típica. Front Door (WAF, edge global) → APIM (autenticación, throttling, enrutado) → AKS/Container Apps (ingress interno) — el patrón “gateway detrás de reverse proxy global”. Para microservicios muy numerosos se usa APIM como gateway externo y un ingress/gateway ligero interno (YARP, NGINX, Envoy) para tráfico este-oeste: APIM no debe mediar el tráfico interno de alta frecuencia entre servicios, tanto por latencia (~ms extra por hop y policies) como por costo. Error común: meter lógica de negocio en policies XML — difícil de testear y de versionar mentalmente; las policies deben limitarse a concerns transversales y vivir en IaC (Terraform/Bicep + APIOps).

8. Front Door vs Application Gateway vs Load Balancer vs Traffic Manager

Categoría: Redes y entrega · Tipo: Conceptual

📝 Respuesta resumen

Azure Load Balancer opera en L4 (TCP/UDP), regional, latencia mínima, sin conocimiento de HTTP. Application Gateway es un reverse proxy L7 regional con WAF, TLS termination, path-based routing y autoscaling (v2). Front Door es L7 global anycast en el edge: CDN, WAF, aceleración TLS en POPs, balanceo entre regiones y failover global. Traffic Manager balancea solo a nivel DNS (sin proxy). Regla rápida: global+HTTP → Front Door; regional+HTTP → Application Gateway; L4 → Load Balancer; DNS-only o protocolos no-HTTP globales → Traffic Manager.

📖 Respuesta detallada

Azure Load Balancer (L4). Reparte flujos TCP/UDP por hash de 5-tuplas hacia un backend pool (VMs, VMSS, nodos AKS). Standard SKU: zone-redundant, SLA 99,99%, health probes TCP/HTTP, HA Ports para NVAs, outbound rules con SNAT (el agotamiento de puertos SNAT es una causa clásica de fallos intermitentes de conexiones salientes — mejor usar NAT Gateway para la salida). No termina TLS, no ve rutas ni cookies. Es la pieza que AKS crea automáticamente para Services type: LoadBalancer. Latencia añadida prácticamente nula porque es lógica de SDN, no un proxy.

Application Gateway (L7 regional). Proxy inverso con: TLS termination y end-to-end TLS, enrutado por path (/api/* → pool A) y por host (multi-site), rewrite de headers, cookie-based session affinity, y WAF con reglas OWASP CRS/DRS más reglas custom. v2 añade autoscaling, zone redundancy y mejor rendimiento. Con AKS se integra como AGIC (Application Gateway Ingress Controller) o, más moderno, Application Gateway for Containers, que enruta directamente a IPs de pods. Costos: v2 cobra capacity units (compute + conexiones + throughput) más precio base (~180–300 USD/mes mínimo con WAF); no es barato para entornos pequeños.

Front Door (L7 global). Red anycast de cientos de POPs: el usuario entra por el POP más cercano, TLS termina en el edge, y el tráfico viaja por el backbone de Microsoft hasta el origen (split TCP: reduce drásticamente el efecto del RTT para usuarios lejanos). Incluye: caching CDN, compresión, WAF global (mismo motor de reglas gestionadas), health probes por origen, balanceo por latencia/prioridad/peso entre orígenes de distintas regiones, session affinity y Private Link a orígenes (Premium) para que el origen no exponga IP pública. SKUs: Standard (~35 USD base/mes + datos) y Premium (~330 USD base/mes, con Private Link y bot protection). Es la pieza de entrada estándar para multi-región: failover automático cuando los probes marcan una región unhealthy (detección típica en decenas de segundos según intervalo y sample size configurados).

Traffic Manager. Balanceo por DNS: responde a la resolución con el endpoint óptimo según routing method (priority, performance, weighted, geographic). No proxya tráfico → no añade latencia de datos, funciona con cualquier protocolo, pero el failover depende del TTL de DNS y de que los clientes respeten la caducidad (clientes que cachean agresivamente tardan en migrar). Hoy, para HTTP, Front Door lo ha desplazado; Traffic Manager queda para protocolos no-HTTP o esquemas DNS-only.

Combinaciones y errores comunes. Patrón completo enterprise: Front Door (edge global, WAF, caché) → Application Gateway o APIM (por región) → backend. Errores: duplicar WAF en Front Door y AppGW sin decidir dónde viven las excepciones (pesadilla de debugging); usar Front Door hacia orígenes sin restringir el acceso directo (cualquiera puede saltarse el WAF atacando el origen — se mitiga con Private Link, o verificando el header X-Azure-FDID y el service tag AzureFrontDoor.Backend en el NSG); y pedir un Application Gateway “global” — no existe: AppGW es regional siempre.

9. Key Vault: gestión de secretos, claves y certificados

Categoría: Seguridad · Tipo: Conceptual

📝 Respuesta resumen

Key Vault almacena secretos (strings versionados), claves criptográficas (RSA/EC, operaciones dentro del vault, respaldo HSM) y certificados (con renovación integrable con CAs). El acceso se controla con RBAC de plano de datos y Managed Identities; la red se cierra con Private Endpoints. Claves de diseño senior: un vault por aplicación y entorno, soft delete + purge protection activados, referencias de Key Vault desde App Service/Functions, rotación automatizada con Event Grid, y tratar el vault como fuente de configuración sensible, no como base de datos de alto QPS (tiene límites de throttling).

📖 Respuesta detallada

Objetos. Secrets: pares nombre-valor versionados (connection strings, API keys), hasta 25 KB. Keys: claves RSA/EC cuyo material nunca sale del vault — firmas, wrap/unwrap para envelope encryption, y respaldo de customer-managed keys (CMK) para Storage/SQL/Cosmos/Disk Encryption. Managed HSM es el producto separado con FIPS 140-2 Level 3 y single-tenancy para requisitos regulatorios fuertes. Certificates: ciclo de vida de certificados X.509 con políticas de emisión y renovación automática si la CA está integrada (DigiCert/GlobalSign) o autofirmados; con CAs no integradas la renovación es tuya, y ahí nacen los incidentes de expiración.

Autorización. Dos modelos: access policies (legacy, por vault, granular por tipo de objeto) y Azure RBAC (recomendado): roles como Key Vault Secrets User (leer secretos), Key Vault Secrets Officer, Key Vault Crypto User, asignables incluso con un secreto individual como scope. Punto de examen: ser Owner de la suscripción no te da acceso a los datos del vault en modo RBAC — necesitas rol de plano de datos. El patrón correcto de consumo es Managed Identity + DefaultAzureCredential; App Service/Functions soportan Key Vault references (@Microsoft.KeyVault(SecretUri=...)) en app settings, con lo que el código ni sabe que hay un vault. En AKS: Secrets Store CSI Driver con rotación por polling, o External Secrets Operator.

Protección de datos y recuperación. Soft delete (ya obligatorio, retención 7–90 días) permite recuperar secretos o el vault borrados; purge protection impide la eliminación definitiva durante la retención incluso a administradores — imprescindible si el vault respalda CMK: si alguien purga la clave que cifra tu Storage/SQL, los datos quedan irrecuperables. Backup de objetos: posible, pero los blobs de backup solo se restauran en la misma suscripción/geografía.

Límites y rendimiento. Key Vault Standard tiene throttling por vault: como referencia, ~2.000 transacciones de lectura de secretos por 10 segundos (las operaciones con claves RSA-HSM tienen límites mucho menores). Antipatrón clásico: leer el secreto del vault en cada request → 429s en picos de tráfico. Lo correcto: cachear secretos en memoria al arranque con refresco periódico (el SDK y las Key Vault references ya cachean; las references refrescan aproximadamente cada 24 h o al reiniciar). Otro antipatrón: un vault gigante compartido por 40 equipos — el throttling es compartido y el blast radius de un acceso comprometido, enorme. Regla: vault por aplicación y entorno.

Rotación y observabilidad. Key Vault emite eventos a Event Grid (SecretNearExpiry ~30 días antes, SecretExpired, equivalentes para certificados) — el patrón de rotación es: Event Grid → Function que genera la nueva credencial en el sistema origen y crea nueva versión del secreto; los consumidores que leen “latest” la recogen en su siguiente refresco. Para claves existen rotation policies nativas. Auditoría: diagnósticos AuditEvent a Log Analytics para saber quién leyó qué y detectar accesos anómalos; alertas sobre 403/429. Red: publicNetworkAccess deshabilitado + Private Endpoint + la excepción “Allow trusted Microsoft services” cuando servicios de plataforma necesiten llegar.

10. Almacenamiento: Blob Storage, tiers y ciclo de vida

Categoría: Datos y almacenamiento · Tipo: Conceptual

📝 Respuesta resumen

Blob Storage tiene cuatro tiers: Hot (acceso frecuente), Cool (≥30 días, almacenamiento más barato y operaciones más caras), Cold (≥90 días) y Archive (≥180 días, offline: rehidratar tarda horas). El costo se compone de almacenamiento por GB + operaciones + salida de datos, y cada tier invierte la proporción. Las lifecycle management policies mueven blobs automáticamente entre tiers o los eliminan según edad/último acceso. La redundancia va de LRS a RA-GZRS según RPO y presupuesto. Diseñar mal los tiers o ignorar las penalizaciones por borrado temprano cuesta dinero real.

📖 Respuesta detallada

Modelo de costos por tier (orden de magnitud, LRS): Hot ~0,018 USD/GB/mes con operaciones baratas; Cool ~0,01 con operaciones más caras y cargo por GB leído; Cold ~0,0036 con operaciones aún más caras; Archive ~0,002 con lecturas que exigen rehidratación: cambiar el blob a Hot/Cool tarda hasta 15 horas en prioridad Standard o menos de 1 hora (blobs <10 GB) en High priority, que se cobra mucho más cara. Además, cada tier frío tiene periodo mínimo de retención: 30 días (Cool), 90 (Cold), 180 (Archive); si borras o mueves antes, pagas el equivalente al tiempo restante (early deletion penalty). Error común: mandar a Archive datos que legal o soporte pide “de vez en cuando” — cada consulta se convierte en un ticket de horas y un costo de rehidratación.

Lifecycle management. Reglas JSON por cuenta con filtros por prefijo/tags: tierToCool tras N días desde modificación o último acceso (requiere habilitar last access time tracking, que tiene costo propio), tierToArchive, delete, y reglas para versiones previas y snapshots — fundamental cuando activas versioning, porque las versiones antiguas se acumulan y facturan silenciosamente. Patrón sólido para logs/backups: Hot 30 días → Cool 90 → Archive 365 → delete a los 7 años si hay requisito de retención.

Redundancia. LRS (3 copias en un datacenter, 11 nueves de durabilidad), ZRS (3 zonas de la región — mínimo recomendado en producción), GRS (LRS + réplica asíncrona a la región emparejada, RPO típico <15 min sin garantía), GZRS (ZRS + geo-réplica), y variantes RA- que permiten lectura del endpoint secundario. El failover de cuenta geo-redundante puede iniciarlo Microsoft (desastre declarado) o el cliente (aceptando pérdida hasta el RPO); tras el failover el destino queda en LRS y hay que re-proteger. Detalle senior: GRS no protege contra borrado lógico o ransomware (replica el borrado) — para eso están soft delete de blobs/contenedores, versioning, point-in-time restore e immutability policies (WORM, legal hold), obligatorias en escenarios regulados.

Rendimiento y límites. Una cuenta estándar soporta hasta ~20.000 req/s y decenas de Gbps; un blob individual ~500 req/s como guía. Para más IOPS por objeto: Premium Block Blob (SSD, latencia de milisegundos bajos; cobra más por GB pero menos por operación — irónicamente más barato si tu carga es operación-intensiva). Para data lake analítico: hierarchical namespace (ADLS Gen2) con ACLs POSIX. Acceso seguro: deshabilitar shared keys (allowSharedKeyAccess: false), Entra ID + RBAC de datos, SAS de delegación de usuario (firmadas con credenciales Entra, revocables) con caducidades cortas para acceso externo, y Private Endpoints por subservicio (blob, dfs). Los uploads grandes van por bloques (hasta ~190,7 TiB por blob); los SDK paralelizan bloques automáticamente — configurar mal tamaño de bloque/concurrencia explica muchos “Azure es lento subiendo”.

11. Multi-región y Disaster Recovery: cómo se diseña

Categoría: Resiliencia y DR · Tipo: Conceptual

📝 Respuesta resumen

Se parte de RTO y RPO por carga, no de tecnología. Patrones en orden de costo: backup/restore (RTO horas), pilot light, warm standby (activo-pasivo con réplicas), y activo-activo multi-región (RTO ~0, máxima complejidad y costo). En Azure: Front Door/Traffic Manager para enrutado global, paired regions y Availability Zones como base física, réplicas nativas por servicio (SQL failover groups, Cosmos multi-región, GZRS, Service Bus geo-DR) y, sobre todo, práctica regular de failover — un DR no ensayado no existe.

📖 Respuesta detallada

Fundamentos físicos. Availability Zones: datacenters independientes dentro de una región con latencia <2 ms entre sí; protegen contra fallo de datacenter y suben SLAs (p. ej., VMs 99,99% zonales). Paired regions (p. ej., West Europe ↔ North Europe): replicación GRS, actualizaciones de plataforma escalonadas y prioridad de recuperación; algunas regiones nuevas no tienen par y apuestan todo a AZs. La primera decisión senior: la mayoría de cargas no necesita multi-región — necesita multi-zona bien hecha; multi-región se justifica por RTO/RPO agresivos, requisitos de residencia/latencia o cargas críticas de negocio.

Capacidades por servicio (lo que hay que saber de memoria):

• Azure SQL: auto-failover groups con replicación asíncrona (RPO ~5 s típico), endpoint listener que redirige automáticamente; failover manual o automático con grace period.
• Cosmos DB: réplicas multi-región con failover gestionado; con multi-region writes, RTO≈0 y RPO≈0 para session/eventual (con resolución de conflictos); con single-region write, el failover de escritura es automático y el RPO depende de la consistencia elegida.
• Storage: GZRS/RA-GZRS, RPO típico <15 min; failover de cuenta con pérdida potencial.
• Service Bus Premium: geo-disaster recovery clásico replica metadatos (colas, topics) con alias DNS pero no los mensajes; la geo-replication más reciente de Premium sí replica datos. Hay que diseñar idempotencia y tolerancia a pérdida de in-flight.
• Key Vault, ACR, AKS: Key Vault replica a la región emparejada automáticamente; ACR tiene geo-replication nativa; AKS no tiene DR nativo — se despliega un clúster por región con GitOps (Flux/Argo) reproduciendo el estado.

Topologías. Activo-pasivo warm: región secundaria con infraestructura a escala mínima, datos replicados, Front Door con routing por prioridad; en failover se escala y se promueven réplicas — RTO de minutos a una hora. Activo-activo: ambas regiones sirven tráfico (Front Door por latencia/peso); exige datos activos-activos (Cosmos multi-write o particionado por geografía) y resolver el problema más difícil: el estado. Escrituras conflictivas, mensajes duplicados y cachés divergentes son el 80% del trabajo real. Punto medio pragmático: activo-activo en la capa stateless y activo-pasivo en los datos.

Los detalles que fallan en el failover real: dependencias no replicadas (el vault, el ACR, App Configuration, los agentes de CI); identidades y permisos que solo existen en la primaria; DNS con TTLs largos; colas con mensajes atascados en la región caída; el runbook desactualizado; y la capacidad — la región secundaria puede no tener cuota o stock de la SKU necesaria justo cuando media nube hace failover contigo (mitigable con capacity reservations o corriendo activo-activo). El criterio de madurez: failover ensayado con game days trimestrales, medido contra RTO/RPO objetivo, con decisión de activación documentada (quién decide y con qué umbral) y con el failback también ensayado, que suele ser más difícil que la ida.

Costo: multi-región duplica infraestructura (menos en serverless), añade egress inter-región y horas de ingeniería permanentes. Presentar a negocio el costo anual del DR contra el costo por hora de indisponibilidad es el ejercicio que justifica (o descarta) cada nivel.

12. Well-Architected Framework aplicado a un diseño en Azure

Categoría: Arquitectura y buenas prácticas · Tipo: Conceptual

📝 Respuesta resumen

El WAF de Azure tiene cinco pilares: Fiabilidad, Seguridad, Optimización de Costos, Excelencia Operativa y Eficiencia de Rendimiento. No es una checklist decorativa: es el vocabulario para justificar trade-offs (p. ej., “acepto RTO de 1 h para no duplicar el costo”) y se operacionaliza con el Well-Architected Review, Azure Advisor y decisiones registradas (ADRs). En entrevista, úsalo como estructura: por cada decisión de diseño, di qué pilar refuerza y qué pilar sacrifica.

📖 Respuesta detallada

Fiabilidad. Definir SLOs por flujo crítico (no un SLA global vago), presupuesto de error, y diseñar para fallo: redundancia zonal por defecto, health checks significativos (no “/ping” sino dependencias reales con degradación), reintentos con backoff exponencial y jitter, circuit breakers, timeouts explícitos en cada llamada saliente (el default infinito de muchos SDK es un bug de diseño), colas para absorber picos y bulkheads para aislar pools de recursos. La métrica compuesta importa: si tu API depende en serie de 5 servicios al 99,9%, tu techo teórico es ~99,5% — o reduces dependencias síncronas o añades redundancia. Herramientas: Azure Chaos Studio para inyección de fallos, Service Health alerts y análisis de modos de fallo (FMA) documentado.

Seguridad. Zero trust: identidad como perímetro (Managed Identities en todo, nada de connection strings con contraseña donde sea evitable), mínimo privilegio con RBAC por scope estrecho, redes cerradas (Private Endpoints, NSGs, sin IPs públicas en backends), secretos en Key Vault con rotación, cifrado en tránsito (TLS 1.2+ forzado) y en reposo (CMK si el compliance lo exige), Defender for Cloud para postura (CSPM) y protección de cargas, y Microsoft Sentinel si hay SOC. La pregunta trampa habitual: “¿dónde guardas las credenciales de la base de datos?” — respuesta senior: en ningún sitio; SQL con autenticación Entra ID y Managed Identity, no hay credencial que guardar.

Optimización de costos. Diseñar con el modelo de facturación en mente: right-sizing continuo (Advisor), autoscaling real (incluido scale-to-zero donde aplique), Reserved Instances/Savings Plans para lo estable (30–65% de ahorro), Spot para lo interrumpible, tiers de storage con lifecycle, y vigilar los costos silenciosos: egress inter-región, Log Analytics (frecuente top 3 de la factura), IPs públicas, snapshots huérfanos y entornos de no-producción encendidos 24/7 (auto-shutdown). Gobernanza: budgets con alertas, tags de imputación forzados por policy, revisión mensual con los equipos dueños del gasto (FinOps) y anomaly detection de Cost Management.

Excelencia operativa. Todo por IaC (Bicep/Terraform) con pipelines y entornos inmutables — el portal solo para leer; despliegues seguros (slots, canary, feature flags con App Configuration), observabilidad como requisito de diseño (App Insights + Log Analytics con dashboards y alertas accionables, no ruido), runbooks y postmortems sin culpa, y carga operativa (toil) medida. Un indicador útil: ¿puedes recrear el entorno completo desde el repo en horas? Si no, no hay excelencia operativa, hay artesanía.

Eficiencia de rendimiento. Elegir el servicio según el patrón de carga (no “lo que ya conocemos”), pruebas de carga continuas (Azure Load Testing) con presupuestos de latencia por percentil (p95/p99, nunca medias), caching en capas (Front Door/CDN, APIM, Redis, memoria local), datos cerca del cómputo, particionado que escale horizontalmente y detección de N+1 y chatty I/O con el distributed tracing de App Insights.

Cómo se usa de verdad. El framework se aplica por carga (workload), con el Azure Well-Architected Review (assessment guiado) que produce un backlog priorizado; Azure Advisor automatiza parte de las recomendaciones. Lo que distingue a un senior en la entrevista es hablar de trade-offs explícitos entre pilares: multi-región mejora fiabilidad y empeora costo y operación; CMK mejora la postura de cumplimiento y añade un modo de fallo nuevo (perder la clave = perder los datos); microservicios mejoran el despliegue independiente y empeoran rendimiento (latencia de red) y operación. La arquitectura correcta no maximiza pilares: los balancea contra requisitos escritos.