Las entrevistas de ingeniería de nube dejaron de ser cuestionarios de trivia hace tiempo. En 2026 casi nadie te pide recitar la diferencia entre un bucket de S3 y un volumen de EBS. Te ponen delante una VPC rota, un plan de Terraform que quiere destruir una base de datos de producción o una alerta a las 3 de la mañana, y observan cómo piensas. "Lo buscaría en Google" solo cuenta si sabes decir qué buscarías y por qué.
Esta guía recoge las preguntas que los candidatos a ingeniero de nube se encuentran ahora mismo, en AWS, Azure y GCP, con una nota breve sobre cómo abordar cada una.
Qué evalúan de verdad las entrevistas de ingeniero de nube en 2026
El título esconde muchísima variación. Un "ingeniero de nube" en una startup de 30 personas es un equipo de plataforma de una sola persona montando Terraform, CI/CD y guardias (on-call). El mismo título en un banco significa redes a fondo, controles de cumplimiento y trabajo de landing zone. Lee la descripción del puesto como si fuera parte del examen, porque el proceso se inclina hacia aquello en lo que ese equipo se está ahogando.
Las señales de fondo no cambian. Los entrevistadores miran cuatro cosas: tu modelo mental de la nube (regiones, zonas de disponibilidad, qué se cae cuando una AZ se apaga); tu soltura con infraestructura como código (Terraform sobre todo, con CloudFormation y Bicep en sitios concretos); tu criterio operativo, porque costo, seguridad y fiabilidad ya son rondas centrales y no extras; y la comunicación bajo incertidumbre, porque los problemas de nube son ambiguos y los buenos candidatos narran sus supuestos en voz alta.
El proceso de entrevista: las rondas reales
La mayoría de los procesos de nube en 2026 tienen entre cuatro y seis etapas, y la forma es predecible en cuanto pasas por unos cuantos.
- Filtro con el reclutador (20 a 30 min). Logística, banda salarial y en qué nubes has puesto cosas en producción de verdad. Sé preciso: "tres años sobre todo en AWS, algo de GCP" gana a un vago "experiencia en la nube".
- Filtro técnico por teléfono (45 a 60 min). Una charla en vivo con el responsable de contratación o un ingeniero senior: fundamentos a ritmo rápido y uno o dos escenarios.
- Ejercicio práctico o prueba para casa. Cada vez más, la ronda central. Escribir un módulo de Terraform, depurar un despliegue roto a propósito o levantar un servicio pequeño con un breve documento de arquitectura.
- Ronda de diseño de sistemas (60 min). Diseñar un sistema resiliente y consciente del costo. Mucho menos cargado de algoritmos que un puesto puro de software, mucho más centrado en compromisos y dominios de fallo.
- Ronda conductual / de incidentes (45 min). Háblame de una caída, una migración, un desacuerdo sobre una decisión de seguridad. A menudo es un análisis a fondo de un incidente real que gestionaste.
Las preguntas
Fundamentos básicos
Explícame qué pasa, de principio a fin, cuando un usuario llega a una app que está detrás de un Application Load Balancer. Cómo abordarla: resolución DNS, terminación TLS, el target group del balanceador y sus health checks, los security groups y las subredes que hay en el camino, y después el cómputo y su conexión con el almacén de datos. Di dónde puede fallar cada pieza.
Explica la diferencia entre una región y una zona de disponibilidad, y luego diseña para sobrevivir a la pérdida de una AZ. Cómo abordarla: define ambas con precisión y luego muestra la consecuencia. Multi-AZ para los servicios con estado (RDS Multi-AZ, quórum entre tres AZ), cómputo sin estado repartido detrás de un balanceador. Señala que multirregión es otra conversación, más cara, sobre RTO y RPO, y no algo por defecto.
¿Qué es el modelo de responsabilidad compartida y en qué se equivocan los ingenieros? Cómo abordarla: el proveedor asegura la nube, tú aseguras lo que pones dentro. El fallo típico es dar por hecho que servicios gestionados significa seguridad gestionada. Un bucket de S3 público o un IAM demasiado amplio es tu problema, no el del proveedor.
Infraestructura como código
Tu terraform plan quiere destruir y recrear una instancia de RDS en producción. ¿Qué haces?
Cómo abordarla: no apliques. Lee el plan para encontrar qué atributo fuerza el reemplazo (un campo inmutable, una versión de motor, un cambio de AZ). Echa mano de bloques create_before_destroy, lifecycle y de state mv o import como herramientas de recuperación. Un destroy en un plan de producción es motivo para parar todo.
¿Cómo gestionas el state de Terraform con quince ingenieros y tres entornos?
Cómo abordarla: backend remoto (S3 más bloqueo con DynamoDB, o Terraform Cloud), separación del state por entorno y control del radio de impacto para que un cambio en staging nunca pueda tocar el state de producción. Puntos extra por credenciales de CI con mínimo privilegio y por detectar drift con un plan programado que falle si hay diferencias.
Redes, seguridad e IAM
Diseña una VPC con subredes públicas y privadas en dos AZ, y explícame el enrutamiento. Cómo abordarla: dibújalo. Un bloque CIDR para la VPC, subredes públicas que enrutan a un internet gateway, subredes privadas que salen a través de un NAT gateway, tablas de rutas por capa. Espera la pregunta de seguimiento: ¿cómo llegan las instancias privadas a las APIs de la nube sin pasar por internet público (VPC endpoints)?
Una instancia EC2 en una subred privada no llega a internet. ¿Cómo lo depuras? Cómo abordarla: es una pregunta de diagnóstico estructurado, no de trivia. Ve hacia fuera por capas: la salida del security group, las network ACLs, la tabla de rutas de la subred, el estado del NAT gateway y su ruta al IGW, y después DNS. Nárralo como una lista de comprobación y nombra la herramienta que confirma cada paso (reachability analyzer, flow logs).
Una aplicación necesita acceso de lectura a un único bucket de S3. ¿Cómo se lo das?
Cómo abordarla: un rol de IAM en el cómputo (instance profile, IRSA en EKS o workload identity) con una política bien acotada a ese bucket y ese prefijo. Las respuestas trampa, claves de acceso de larga duración dentro de la app o s3:* en Resource: *, se caen al primer contacto. Di "mínimo privilegio" en voz alta.
¿Cómo guardas y rotas los secretos de una app nativa de nube? Cómo abordarla: un almacén de secretos gestionado (Secrets Manager, Parameter Store o Vault), leído en tiempo de ejecución con la identidad de la carga de trabajo, nunca subido a git ni horneado en una imagen. La regla es que la app nunca guarda una credencial estática de larga duración.
Operaciones, fiabilidad y costo
La latencia en producción se acaba de triplicar y no tienes ni idea de por qué. Cuéntame tus primeros diez minutos. Cómo abordarla: aquí se mide tu respuesta ante incidentes. Primero reconoce y comunica, luego lee las señales doradas (latencia, tráfico, errores, saturación), revisa los despliegues recientes y prioriza mitigar (rollback, escalar) por encima de cazar la causa raíz mientras los clientes sufren. La calma gana al frenesí.
La factura mensual subió un 40 por ciento sin que cambiara el tráfico. ¿Cómo encuentras la causa? Cómo abordarla: etiquetas de asignación de costos, cost explorer desglosado por servicio y por cuenta, y los sospechosos habituales (volúmenes huérfanos, balanceadores ociosos, transferencia entre AZ o de salida, un autoscaling group desbocado, entornos de desarrollo olvidados). Trata el costo como una métrica de ingeniería con dueños.
¿Cuál es tu enfoque para las copias de seguridad y la recuperación ante desastres, y cómo sabes que funcionan? Cómo abordarla: define primero RTO y RPO, y luego llévalos a una estrategia (snapshots, replicación entre regiones, infraestructura reconstruible desde código). La frase que cala: una copia de seguridad que nunca has restaurado es una esperanza, no una copia de seguridad.
Preguntas conductuales y profundidad en incidentes
Háblame del peor incidente de producción en el que participaste. ¿Cuál fue tu papel y qué cambió después? Cómo abordarla: elige uno real y estructúralo como situación, tus acciones concretas, la resolución, y el arreglo sistémico y el postmortem sin culpables que vinieron después. Buscan responsabilidad y aprendizaje, no si alguna vez has roto algo.
Cuéntame una vez en la que no estuviste de acuerdo con una decisión de seguridad o de arquitectura. Cómo abordarla: demuestra que sabes discrepar con datos y luego comprometerte. La versión madura incluye una vez en la que te llevaron la contraria y salió bien, en lugar de una historia en la que montaste un apaño por tu cuenta.
Errores habituales que hunden a los candidatos a ingeniero de nube
- Nombrar servicios sin hablar de compromisos. "Usaría Kubernetes" no es una respuesta. ¿Por qué no ECS, o Lambda, o un simple autoscaling group? El puesto va de criterio, no de vocabulario.
- Ignorar el costo. Diseñar activo-activo en cinco regiones para una herramienta interna con doce usuarios deja claro que nunca has sido responsable de una factura.
- Farolear. Fingir que dominas un servicio que no has usado se cae a la segunda pregunta de seguimiento. "No he tenido Aurora en producción, pero así es como lo razonaría" genera mucha más confianza.
- Adivinar la solución. En una pregunta de VPC rota, acertar de chiripa se lee como suerte. Un diagnóstico por capas y bien narrado se lee como competencia.
- Dejar la seguridad para el final. Dejar IAM y los secretos para el final de una ronda de diseño es una señal de alarma en 2026.
Cómo prepararte (y dónde ayuda un copiloto en vivo)
Construye, no solo leas. Abre una cuenta de capa gratuita, escribe un módulo de Terraform que levante una VPC con subredes públicas y privadas, rompe el enrutamiento a propósito y arréglalo. Ese único ejercicio cubre un tercio de las preguntas de arriba.
Practica las preguntas de escenario en voz alta, porque las entrevistas de nube premian la narración. Ensayar la respuesta de los "primeros diez minutos de un incidente" hasta que fluya vale más que memorizar límites de servicio que puedes consultar. Mapea también tu historial a las preguntas conductuales: una historia de caída, una de migración, una de desacuerdo, estructuradas y listas.
Para las rondas en vivo, donde las preguntas llegan más rápido de lo que puedes componer una respuesta completa, un copiloto en tiempo real te quita presión. GhostPilot funciona en el panel lateral de Chrome y escucha la entrevista, mostrando un prompt estructurado en cuanto aterriza la pregunta: las capas que hay que revisar en una pregunta de depuración, los compromisos que hay que nombrar en una de diseño, un empujón hacia el ángulo de costo o seguridad que se te podría olvidar bajo presión. Te da el esqueleto, no un guion para leer en voz alta, así que la experiencia vivida la sigues poniendo tú con tus propias palabras. Más en ghostpilotai.com.
FAQ
¿En qué debería centrarme para una entrevista de ingeniero de nube de nivel inicial? En los fundamentos antes que en la amplitud. Domina a fondo los primitivos de cómputo, almacenamiento y redes de una sola nube, entiende IAM y el modelo de responsabilidad compartida, y escribe una configuración básica de Terraform. Los procesos junior perdonan huecos en escala si tus fundamentos son sólidos.
¿Cuántas certificaciones de nube necesito en 2026? Una certificación de nivel associate (por ejemplo AWS Solutions Architect Associate) ayuda a pasar el filtro del currículum, sobre todo si tienes poca experiencia. Más allá de eso, los rendimientos decrecen rápido. Un pequeño portafolio de Terraform y un proyecto real que sepas explicar valen más que un muro de insignias.
¿Las entrevistas de ingeniero de nube siguen incluyendo programación estilo LeetCode? Menos que los puestos de software, pero no cero. Espera scripting ligero (Python o Bash para parsear logs o llamar a una API) antes que algoritmos duros. Los puestos de plataforma o con sesgo SRE pueden añadir un problema de estructuras de datos, pero dominan IaC y el diseño de escenarios.
¿En qué se diferencia una entrevista de ingeniero de nube de una de DevOps o SRE? Se solapan mucho. El ingeniero de nube tira hacia el aprovisionamiento, IaC y los servicios del proveedor. El SRE tira hacia las matemáticas de la fiabilidad, los SLO y el rigor en las guardias (on-call). DevOps tira hacia CI/CD y la experiencia de desarrollo. Un mismo proceso sirve a menudo para los tres, y lo que hunde a buenos candidatos en todos ellos es hablar con nombres de servicios en vez de con compromisos.
Prueba GhostPilot AI
Las entrevistas de nube van rápido y las preguntas de escenario rara vez tienen una respuesta limpia, que es justo donde un prompt en tiempo real te ayuda a mantener la estructura bajo presión. GhostPilot funciona en el panel lateral de Chrome, así que cuando compartes una sola pestaña no forma parte de lo que se captura, y la app de escritorio opcional para Windows es invisible a la captura de pantalla en Windows 10 (build 2004 o posterior) y Windows 11. Empieza gratis con sesiones en vivo de 10 minutos y respuestas de IA ilimitadas, consigue un Session Pass por $29 (tres entrevistas completas de dos horas, pago único, sin suscripción) o pásate a Pro por $59/mes o $192/año ($16/mes con facturación anual).