Preguntas de entrevista para Cloud Engineer: respuestas que funcionan

Llegas a la fase técnica de una entrevista para Cloud Engineer y, entre diagramas de arquitectura y preguntas sobre costes, sientes que tu preparación se queda corta. No basta con saber configurar un S3 o levantar una instancia EC2. Los entrevistadores quieren ver cómo piensas, resuelves problemas y colaboras bajo presión. Esta guía te da las respuestas que realmente funcionan.

El problema que todos los entrevistadores buscan resolver#

Antes de memorizar definiciones, entiende esto: la empresa no busca un diccionario de servicios de AWS o Azure. Busca a alguien que pueda diseñar sistemas fiables, optimizar el gasto y solucionar incidencias sin que le tiemblen las manos. Cada pregunta es una puerta para demostrar una de esas tres cosas. Tu trabajo es cruzarla con claridad y datos concretos.

Preguntas de filtro: no las subestimes#

Estas preguntas parecen sencillas, pero filtran rápido a quienes no tienen experiencia real o no saben explicar lo que hacen.

• ¿Cuál es la diferencia entre IaaS, PaaS y SaaS? Pon un ejemplo de cada uno que hayas usado.: No quieren la teoría del libro. Quieren escuchar: "Usé EC2 como IaaS para levantar servidores donde yo gestionaba el sistema operativo. Para desplegar aplicaciones sin gestionar infraestructura, usé Elastic Beanstalk como PaaS. Y para el correo electrónico corporativo, usamos Google Workspace como SaaS".

• Explica el modelo de responsabilidad compartida en la nube.: Aquí buscan que sepas dónde termina la responsabilidad del proveedor y dónde empieza la tuya. Un error común es pensar que al estar en la nube, todo es responsabilidad del proveedor. En IaaS, tú eres responsable del sistema operativo, las aplicaciones y los datos. El proveedor gestiona el hardware y la red.

• ¿Cómo monitorizas el rendimiento y los costes de tu infraestructura?: Si solo dices "con CloudWatch", has perdido la oportunidad. La respuesta ganadora es específica: "Configuro dashboards en CloudWatch para métricas clave como latencia de API y uso de CPU. Para costes, uso Cost Explorer y establezco presupuestos con alertas en Budgets. La semana pasada, una alerta me avisó de un gasto inesperado en transferencia de datos y pude detenerlo antes de que escalara".

Preguntas técnicas: demuestra que has construido cosas#

Aquí es donde se separa a quien ha leído la documentación de quien ha roto cosas y las ha arreglado.

• Diseña una arquitectura de alta disponibilidad para una aplicación web con base de datos.: El entrevistador evalúa tu conocimiento de servicios gestionados y patrones de resiliencia. Una respuesta sólida menciona: balanceador de carga (ALB), grupo de Auto Scaling con instancias en múltiples zonas de disponibilidad, base de datos RDS Multi-AZ o Aurora, y almacenamiento de objetos S3 para assets estáticos. Explica por qué cada componente está ahí.

• ¿Cómo gestionas los secretos y credenciales en producción?: Si dices "los pongo en el código o en un archivo de configuración", es una respuesta automática de rechazo. La respuesta correcta implica AWS Secrets Manager, Azure Key Vault o HashiCorp Vault. Explica cómo rotas los secretos automáticamente y cómo las aplicaciones los obtienen sin exponerlos.

• Un servicio en producción tiene una latencia inusualmente alta. ¿Cuál es tu proceso?: Esta pregunta evalúa tu capacidad de diagnóstico. Un buen enfoque: primero, confirmar el problema con métricas en CloudWatch o Grafana. Segundo, revisar logs en CloudTrail o Cloud Logging para buscar errores. Tercero, verificar cambios recientes en el despliegue. Cuarto, revisar la infraestructura subyacente: ¿hay un problema de red, un volumen EBS saturado, un escalado pendiente? El orden importa.

Preguntas de comportamiento: tu red de seguridad#

Muchos candidatos técnicamente buenos fallan aquí. No porque no tengan buenas historias, sino porque no las estructuran.

• Cuéntame un tiempo en que un despliegue salió mal. ¿Qué hiciste?: Usan el método STAR (Situación, Tarea, Acción, Resultado), pero no lo digas en voz alta. Simplemente cuéntalo así. "En mi anterior empresa, un despliegue de Terraform borró un Security Group crítico por un error en el módulo. La aplicación dejó de recibir tráfico. Mi primera acción fue restaurar el Security Group manualmente desde la consola para recuperar el servicio en 10 minutos. Después, revisé el plan de Terraform, corregí el módulo y añadí validaciones automáticas al pipeline para que no volviera a pasar. El tiempo total de incidencia fue de 15 minutos".

• ¿Cómo manejas los desacuerdos con un compañero sobre la arquitectura de un sistema?: El entrevistador evalúa madurez profesional. Una mala respuesta: "Siempre busco el consenso". Una buena respuesta: "Escucho su propuesta y pido que explique los beneficios. Luego presento la mía con datos: costes estimados, latencia, complejidad operativa. Si seguimos en desacuerdo, propongo un spike técnico o una prueba de concepto pequeña para tener datos reales. La decisión final la toma el equipo con la evidencia sobre la mesa".

• Descríbeme un momento en que tuviste que aprender una tecnología nueva bajo presión.: Esto evalúa tu capacidad de adaptación. Sé específico: qué tecnología, por qué la necesitabas, cuánto tiempo tuviste y cuál fue el resultado. No inventes. Si no tienes un ejemplo perfecto, uno donde tardaste más de lo esperado pero completaste el proyecto también es válido.

Qué evalúa realmente el entrevistador#

Más allá de la respuesta correcta, buscan patrones.

• Capacidad de priorizar bajo presión.
• Comunicación clara de ideas técnicas complejas.
• Conciencia de costes, no solo de rendimiento.
• Mentalidad de "qué pasa si esto falla".
• Honestidad para decir "no lo sé, pero sé dónde buscarlo".

Los errores que te descalifican al instante#

• Mentir sobre experiencia con un servicio. Si dices que eres experto en Kubernetes pero no puedes explicar qué es un pod, lo van a notar.
• No hacer preguntas al final. Una entrevista es bidireccional. Pregunta por el stack, los retos del equipo, cómo gestionan incidentes.
• Hablar solo de tecnología sin mencionar personas o procesos. Los sistemas los mantienen equipos.
• Memorizar respuestas de internet sin adaptarlas a tu experiencia. Suena robótico y poco creíble.

Checklist de preparación final#

• Investiga la empresa: qué nube usa, qué servicios tiene, qué tamaño tiene el equipo de infraestructura.
• Repasa tu CV línea por línea. Cada tecnología que pones, prepárate para explicar cómo la usaste y un problema que resolviste con ella.
• Practica en voz alta tus respuestas STAR. Grábate si puedes.
• Prepara 3-5 preguntas específicas para el entrevistador.
• Ten a mano ejemplos con métricas concretas: "reduje costes un 20%", "el tiempo de despliegue pasó de 45 a 10 minutos".
• Revisa conceptos fundamentales: redes (TCP/IP, DNS, VPC), seguridad (IAM, grupos de seguridad), almacenamiento (bloque, objeto, archivo).

Para analizar si tu perfil encaja con la oferta, usa el decodificador de ofertas de empleo en decodificador de ofertas. Y si quieres verificar que tu CV pasa los filtros automáticos, prueba el verificador de CV para ATS en chequeo ATS gratis. Para encontrar más ofertas de Cloud Engineer, explora las vacantes disponibles en empleos. Y si quieres seguir preparándote, lee más artículos sobre entrevistas técnicas en blog.

Preguntas frecuentes#

¿Cuánto dura una entrevista técnica para Cloud Engineer?

Depende de la empresa. Una primera pantalla técnica suele durar entre 45 y 60 minutos. Una entrevista técnica profunda puede extenderse a 90 minutos, a veces con un ejercicio práctico en vivo o un take-home.

¿Me pueden preguntar sobre varias nubes a la vez?

Sí, especialmente si la empresa usa un enfoque multi-cloud o está evaluando migrar. Es común que pregunten diferencias entre AWS y Azure en servicios como almacenamiento o identidad. Si solo tienes experiencia en una, sé honesto pero muestra disposición para aprender.

¿Qué pasa si no sé la respuesta a una pregunta técnica?

No te quedes en silencio ni inventes. Di: "No tengo experiencia directa con ese servicio, pero basándome en lo que sé de servicios similares, mi aproximación sería...". Luego explica tu razonamiento. Eso vale más que un "no sé" seco.

¿Es importante tener certificaciones de la nube?

Ayudan, especialmente la AWS Solutions Architect o la Azure Administrator para roles junior. Pero no sustituyen la experiencia real. Un candidato sin certificación pero con proyectos concretos en su CV suele tener más peso que uno con tres certificaciones y sin experiencia práctica.

¿Qué tipo de ejercicio práctico me pueden pedir?

Lo más común es un escenario de diseño de arquitectura en una pizarra o herramienta colaborativa. También pueden darte un take-home donde debes desplegar una infraestructura básica con Terraform o CloudFormation. Algunas empresas hacen pair programming para resolver un problema de automatización en tiempo real.