Preguntas de entrevista Cloud y DevOps 2026: la guía real
Si estás preparando una entrevista de Cloud o DevOps en 2026, vas a chocar sí o sí con seis temas: serverless, API Gateway, S3, Docker, microservicios y Azure Entra ID. Esa es la columna vertebral de las preguntas de entrevista de Cloud y DevOps de hoy, y casi todas se responden mejor con un ejemplo concreto que con una definición de manual.
Una entrevista de Cloud y DevOps es una evaluación técnica donde el entrevistador mide si sabés diseñar, desplegar y operar infraestructura en la nube. Cubre arquitectura serverless (AWS Lambda), contenedores (Docker), gestión de APIs, almacenamiento de objetos (S3), patrones de resiliencia para microservicios e identidad corporativa (Azure Entra ID). Hoy aparece hasta en roles que antes eran solo de backend.
En 30 segundos
- Serverless ya no es opcional: AWS Lambda, Docker y microservicios figuran en ofertas que antes eran 100% de aplicación.
- Cold starts: se reducen con provisioned concurrency y SnapStart, sin reciclar constantemente el entorno.
- API Gateway: HTTP API es más barata y rápida; REST API tiene más features; WebSocket es para tiempo real.
- Circuit Breaker: tres estados (Closed, Open, Half-Open), implementable en Node.js con Opossum.
- Azure Entra ID: Managed Identities reemplazan secrets hardcodeados, tema estándar desde principios de 2026.
¿Qué es serverless y qué problema resuelve de verdad?
Ponele que tenés una API que recibe 10 requests a las 3 de la mañana y 50.000 al mediodía. Con un servidor tradicional pagás 24 horas por la capacidad del pico. Con serverless pagás por invocación y por milisegundo de ejecución, y la nube escala sola.
Esa es la respuesta corta que buscan en las preguntas de entrevista de Cloud y DevOps. Según el recopilatorio de Dev Encyclopedia (junio 2026), el modelo de ejecución de Lambda es simple de explicar: AWS recibe el evento, levanta un entorno de ejecución, corre tu handler y lo congela para reusarlo. Vos no administrás el sistema operativo ni la actualización de parches. Eso es lo que vendés en la entrevista: menos operación, escalado automático, costo atado al uso real.
¿Cómo reducir cold starts en AWS Lambda?
Acá viene lo bueno: el cold start es la latencia extra de la primera invocación, cuando AWS tiene que crear el entorno desde cero. Si tu función arranca en frío justo cuando entra el tráfico del mediodía, el usuario lo siente.
- Provisioned concurrency: mantenés N entornos pre-inicializados y calientes. AWS lo recomienda para APIs de alto volumen y baja latencia, ideal para spikes horarios conocidos.
- SnapStart: toma un snapshot del entorno ya inicializado y lo restaura. Ataca el arranque pesado de runtimes como Java sin pagar concurrencia provisionada todo el día.
- Elección de runtime: un handler liviano en Node.js o Python arranca más rápido que uno con un framework que carga 200 dependencias.
Detalle que separa al senior del junior: la provisioned concurrency se configura sobre una versión o alias, no sobre $LATEST. Si lo decís en la entrevista, marcás que lo usaste de verdad.
¿REST API, HTTP API o WebSocket en API Gateway?
La pregunta es: ¿cuál elegís? Depende de qué necesites.
- HTTP API: más barata y de menor latencia. La opción por defecto para una API REST simple con backend Lambda.
- REST API: tiene features que HTTP API no trae, como request validation nativo, planes de uso con API keys y caching. Si necesitás eso, la pagás.
- WebSocket API: conexión bidireccional persistente. Es para chat, notificaciones push o dashboards en vivo, no para un CRUD.
Sobre autorización vas a tener que diferenciar IAM (para servicios internos AWS), Lambda Authorizer (lógica personalizada) y JWT Authorizer (tokens de un proveedor de identidad). Y sumá throttling, stages y canary deployments para liberar una versión nueva al 5% del tráfico antes de ir a fondo.
¿Qué storage classes de S3 hay y cuándo usar cada una?
S3 guarda objetos en buckets, cada uno identificado por una key. Lo que cambia entre clases es el costo y la velocidad de recuperación. Esta tabla es la que querés tener clara antes de la entrevista.
| Clase | Cuándo usarla | Recuperación |
|---|---|---|
| Standard | Datos de acceso frecuente (activos web) | Inmediata |
| Standard-IA | Acceso poco frecuente pero rápido cuando hace falta | Inmediata, costo por GET |
| Intelligent-Tiering | Patrón de acceso desconocido o cambiante | Automática, sin pensar |
| Glacier | Archivo a largo plazo (backups, compliance) | Minutos a horas |
| Deep Archive | Datos que casi nunca tocás (retención legal) | Hasta 12 horas |
Sumale tres conceptos que suelen pedir: versioning para no perder objetos sobreescritos, presigned URLs (que sirven tanto para GET como para PUT temporal sin exponer credenciales) y event notifications para disparar una Lambda cuando entra un archivo. Si gestionás muchos activos así, conviene apoyarte en infraestructura cercana a tu público; para hosting y dominios en Argentina, donweb.com es una opción local.
¿En qué se diferencian Docker y las máquinas virtuales?
La diferencia de fondo: una VM virtualiza el hardware y corre su propio kernel, mientras que los contenedores comparten el kernel del host. Por eso un contenedor arranca en segundos y una VM en minutos, con mucho menos overhead de recursos.
El ejemplo que impresiona es el multi-stage build. Construís en una imagen “gorda” con todo el toolchain, copiás solo el binario final a una imagen base mínima, y pasás de algo de 800 MB a una imagen de 80 MB. Si encima usás imágenes distroless y un usuario non-root, ya estás hablando de security best practices sin que te lo pregunten. Y ojo con la confusión clásica: Docker corre contenedores, Kubernetes los orquesta a escala. No son lo mismo.
¿Qué es el patrón Circuit Breaker y cuáles son sus tres estados?
Imaginá un microservicio que llama a otro que está caído. Sin protección, cada request espera el timeout, se acumulan, y el problema se propaga hacia atrás hasta tirar todo. El Circuit Breaker corta esa cadena.
- Closed: todo pasa normal, el breaker cuenta fallos.
- Open: superado el umbral, rechaza al toque sin llamar al servicio roto. Falla rápido en vez de colgarse.
- Half-Open: después de un tiempo deja pasar algunas requests de prueba. Si responden bien, vuelve a Closed; si no, vuelve a Open.
En Node.js lo implementás con Opossum, que envuelve tu función y maneja los estados solo. Para redondear el tema de microservicios, tené a mano el patrón Saga (coreografía vs orquestación para transacciones distribuidas), event sourcing y distributed tracing. Son las preguntas de seguimiento más comunes.
¿Qué es Azure Entra ID y en qué se diferencia del Active Directory clásico?
Azure Entra ID (antes Azure AD) es el servicio de identidad en la nube de Microsoft. El Active Directory tradicional vive en tu red con protocolos como LDAP y Kerberos; Entra ID es cloud-native y habla OAuth 2.0 y OpenID Connect. Según la documentación de Microsoft, hoy es tema estándar en cualquier rol que toque entornos empresariales.
Lo que te van a preguntar: la diferencia entre App Registration (la definición de tu app) y Service Principal (la instancia con permisos en un tenant). Los flujos OAuth que tenés que nombrar son Authorization Code, PKCE para apps públicas, Client Credentials para servicio a servicio, On-Behalf-Of y Device Code. Y el golazo: las Managed Identities eliminan los secrets hardcodeados, porque Azure rota las credenciales por vos. Cerrá con Conditional Access, RBAC y PIM para accesos elevados just-in-time.
Errores comunes en estas entrevistas
- Confundir Docker con Kubernetes: decir que “Docker orquesta contenedores” es un error que te baja puntos. Docker corre, Kubernetes orquesta.
- Prometer que provisioned concurrency “elimina” los cold starts: los reduce para el tráfico esperado, pero si llega un pico arriba de lo provisionado, vuelve el cold start.
- Tratar S3 como un file system: es almacenamiento de objetos, no hay carpetas reales, las “carpetas” son solo prefijos en la key.
- Guardar secrets en variables de entorno en Azure: existiendo Managed Identities, hardcodear credenciales es justo lo que el entrevistador quiere que evites.
Preguntas Frecuentes
¿Qué preguntas hacen en entrevistas de Cloud y DevOps en 2026?
Las seis categorías dominantes son serverless y AWS Lambda, API Gateway, S3, Docker, microservicios (Circuit Breaker, Saga) e identidad con Azure Entra ID. La tendencia de 2026 es pedir respuestas con código y comportamiento real, no definiciones memorizadas.
¿Cómo me preparo para una entrevista de AWS DevOps?
Practicá explicar en voz alta el modelo de ejecución de Lambda, cómo reducís cold starts y cuándo elegís cada storage class de S3. Tené un ejemplo concreto por tema, como reducir una imagen Docker de 800 MB a 80 MB con multi-stage build.
¿Qué debo saber sobre serverless y Lambda para una entrevista?
Tenés que dominar el modelo de ejecución basado en eventos, el problema del cold start y sus soluciones (provisioned concurrency y SnapStart), y los tipos de invocación. Sumá que la concurrencia provisionada se configura sobre alias o versión, no sobre $LATEST.
¿Qué es el patrón Circuit Breaker y cómo lo preguntan?
El Circuit Breaker evita que un servicio caído tire abajo toda la cadena de microservicios. Te van a pedir sus tres estados (Closed, Open, Half-Open) y, si trabajás con Node.js, cómo lo implementás con la librería Opossum.
¿Por qué Azure Entra ID es tan preguntado ahora?
Porque cualquier rol que toque entornos Microsoft empresariales lo usa para autenticación y autorización. El punto fuerte que esperan que menciones son las Managed Identities, que reemplazan los secrets hardcodeados rotando credenciales de forma automática.
Conclusión
Lo que cambió en 2026 es que estos temas dejaron de ser de roles especializados y se metieron en cualquier puesto de backend. La diferencia entre aprobar y quedar afuera no es saber la definición, es poder bajarla a un caso real: el alias para la provisioned concurrency, el multi-stage build que achica la imagen diez veces, las Managed Identities en lugar del secret hardcodeado.
Mi consejo: armate un ejemplo concreto por cada uno de los seis temas y practicá decirlo en voz alta. Eso es lo que separa una respuesta de manual de una que demuestra que lo usaste en producción.
