15 Preguntas Clave en Entrevistas Cloud (AWS, Azure, GCP)

He estado en ambos lados de las entrevistas cloud. Hice las preguntas. Las respondí. Fallé en un par que probablemente no debería haber fallado.

Lo que me quedó claro: a nadie lo contratan por recitar qué es EC2. Los entrevistadores quieren saber si has operado infraestructura real. Si rompiste algo en producción. Si lo arreglaste bajo presión. Si tomaste decisiones que puedes defender sin ponerte nervioso.

Estas 15 preguntas aparecen constantemente en entrevistas de AWS, paneles de Azure y rondas de GCP. No son trivia — son preguntas reales que separan a los que construyen de los que solo siguen tutoriales.

Preguntas Básicas Que Siguen Pillando a la Gente

Pensarías que lo básico sería fácil. No lo es. Los entrevistadores no quieren definiciones. Quieren matices.

IaaS vs PaaS vs SaaS — claro, todo el mundo memoriza la pirámide. Lo que hace tropezar a la gente es que las fronteras hoy son difusas. Lambda está en algún punto entre IaaS y PaaS. Lo mismo App Engine. Decir eso en voz alta demuestra que has pensado más allá del libro de texto.

El Modelo de Responsabilidad Compartida es donde los candidatos junior se desmoronan. Lo describen en abstracto. No lo hagas. Prueba esto: “Si mi instancia EC2 se ve comprometida porque no la parcheé, eso es culpa mía.” Una frase. Demuestra más que un monólogo de cinco minutos.

VPCs. Subnets, bloques CIDR, security groups, NACLs — tienes que dominarlos. AWS VPC, Azure VNet, GCP VPC los implementan de manera diferente, pero el concepto es idéntico. Estás construyendo muros alrededor de tus workloads. Si no puedes explicar por qué una base de datos pertenece a una subnet privada, no estás listo para la entrevista.

Regiones y Availability Zones revelan si has diseñado pensando en fallos o solo has leído sobre ello. Multi-AZ no es un checkbox. Es una decisión con consecuencias de costo, latencia y compliance. Solo el GDPR puede dictar toda tu estrategia de regiones.

Escalado horizontal vs vertical. El vertical tiene un techo y normalmente requiere downtime. El horizontal te da tolerancia a fallos. Esa es la respuesta de manual. ¿La mejor respuesta? Algunos servicios gestionados — Aurora, Cloud Spanner — manejan esto por ti, y saber cuándo apoyarte en ellos es la habilidad real que están evaluando.

Nivel Intermedio: Demuestra Que Has Construido Algo Real

Aquí es donde las preguntas de entrevista cloud se ponen interesantes. Y donde la preparación separa a los candidatos.

“¿Cuándo elegirías NoSQL sobre relacional?” Respuesta incorrecta: listar las features de DynamoDB. Respuesta correcta: depende de tus patrones de acceso. DynamoDB es increíble para lookups key-value conocidos a escala. PostgreSQL en RDS gana cuando necesitas queries ad-hoc y joins. La mayoría de los sistemas en producción donde he trabajado usan ambos. Decir eso — honestamente — cae mejor que elegir un bando.

“Diseña una arquitectura de alta disponibilidad en AWS.” Quieren detalles. Dos AZs mínimo. ALB delante. Auto Scaling Group con health checks. RDS Multi-AZ para failover. S3 más CloudFront para assets estáticos. Luego cuantifícalo: “esto apunta a un 99.99% de uptime en la capa de aplicación.” Los números te dan credibilidad. Las promesas vagas no.

Infrastructure as Code. Cuando alguien te pregunta por qué IaC es innegociable, en realidad están probando si te has quemado con cambios manuales en la consola. (Te ha pasado, ¿verdad? A todos nos ha pasado.) Terraform, CloudFormation, Pulumi — la herramienta importa menos que el principio. Infraestructura versionada, repetible, auditable. Menciona los dolores de cabeza con el state de Terraform. Demuestra que realmente has usado la cosa.

Gestión de secretos es directa, pero la gente sigue fallando. Nunca hardcodees credenciales. Usa Secrets Manager, Key Vault, o GCP Secret Manager. Rotación automática. Prefiere IAM roles sobre keys de larga duración. He visto outages en producción causados por API keys hardcodeadas que expiraron — completamente prevenibles. Y aun así.

El Mito de Necesitar los Tres Proveedores

Esto es lo que pasa. Muchos candidatos queman semanas intentando aprender AWS, Azure y GCP al mismo nivel de profundidad. Es un error.

¿Honestamente? La mayoría de las empresas usan un solo proveedor cloud para el 90% de sus workloads. Las entrevistas evalúan profundidad, no amplitud. Si conoces bien AWS, puedes tender puentes con los otros: “En AWS usaría SQS. Azure Service Bus y GCP Pub/Sub cumplen roles similares, aunque las garantías de entrega difieren.” Ese tipo de razonamiento impresiona más que conocimiento superficial de tres plataformas.

Donde la conciencia multi-cloud sí importa: al comparar opciones serverless. Lambda tiene el ecosistema de triggers más rico. Azure Functions se integra profundamente con el stack de Microsoft y tiene Durable Functions para workflows con estado. Cloud Functions es la más simple para HTTP triggers y funciona genial con Firebase. Conoce los trade-offs de cold start y las diferencias de pricing. Con eso generalmente alcanza.

Una opinión quizás controversial — pero yo prefiero contratar a alguien que ha operado un cloud a fondo que a alguien que ha hojeado las tres guías de certificación.

Preguntas Avanzadas — Donde las Cicatrices Operacionales se Notan

Aquí no se puede fingir.

De monolito a microservicios. La respuesta es el patrón Strangler Fig. No reescribas todo de golpe. Extrae un bounded context a la vez. Dale a cada servicio su propia base de datos. Usa mensajería asíncrona — SQS, EventBridge, Pub/Sub — para reducir el acoplamiento. Pero lo que la mayoría de los candidatos olvida decir: estás cambiando complejidad de código por complejidad operacional. Reconocer ese trade-off… los entrevistadores lo notan.

Teorema CAP. Las particiones de red ocurren. Punto. Así que estás eligiendo entre consistencia y disponibilidad. DynamoDB usa eventual consistency por defecto pero ofrece strongly consistent reads. Cloud Spanner dice ofrecer ambas C y A a través de TrueTime… aunque se tuerce durante particiones reales. Relaciónalo con algo concreto: “Elegimos eventual consistency porque nuestro caso de uso toleraba lecturas obsoletas durante 200ms.” Eso es lo que hace que una respuesta se quede grabada.

Deployments sin downtime. Blue-green o rolling updates. Blue-green: haces deploy en un entorno inactivo, pruebas, cambias el load balancer, mantienes el viejo para rollback. Rolling updates en Kubernetes reemplazan pods incrementalmente con readiness probes controlando el tráfico. La parte difícil son siempre las migraciones de base de datos — patrón expand-contract. Añade las columnas nuevas primero, despliega código que escriba en ambos schemas, migra datos, luego elimina las columnas viejas.

Optimización de costos. Empieza con visibilidad — Cost Explorer, alertas de billing. Luego right-size las instancias, usa Reserved Instances o Savings Plans para workloads estables, Spot para batch jobs, S3 Glacier para datos fríos. Elimina recursos zombie: volúmenes EBS sin adjuntar, load balancers ociosos, snapshots olvidados. Los equipos que hacen revisiones mensuales de costos ahorran dinero de verdad. Los que no… bueno, se enteran eventualmente.

Cuando Te Quedas En Blanco

Pasa en toda entrevista de AWS, panel de Azure o ronda de GCP. Alguien te pregunta sobre un servicio que nunca has tocado.

Sé honesto. Y luego razona en voz alta.

“No he usado eso directamente, pero basándome en el problema, esperaría que funcione como [cosa análoga]. Así es como lo validaría.” El pensamiento de ingeniería le gana al conocimiento enciclopédico. Siempre.

Las certificaciones ayudan a pasar los filtros de CV. No reemplazan haber construido algo real. Una certificación más un proyecto personal que puedas demostrar — esa combinación sigue funcionando mejor que tres certificaciones sin experiencia práctica.

FAQ

¿Necesito certificaciones para entrevistas cloud?

Ayudan a pasar filtros de RRHH, especialmente en empresas grandes. Pero he entrevistado a bastantes candidatos certificados que no podían resolver un security group mal configurado. La certificación abre la puerta. Lo que has construido es lo que te hace pasar.

¿Qué proveedor cloud debería aprender primero?

AWS sigue teniendo la mayor cuota de mercado y la mayor demanda en entrevistas. Empieza por ahí a menos que estés apuntando a una empresa que claramente sea Azure o GCP. Los conceptos se transfieren — una vez que entiendes un proveedor a fondo, aprender otro toma semanas, no meses.

¿Qué tan técnicas se ponen realmente las entrevistas cloud?

Depende del puesto. Para un cloud engineer o SRE, espera dibujar arquitecturas en pizarra y discutir escenarios de fallo en detalle. Para un puesto de backend developer, probablemente te hagan algunas preguntas cloud pero no van a ir tan a fondo. Mira la descripción del puesto. Si menciona Terraform o Kubernetes, prepárate en consecuencia.

¿Cuál es el error más grande que comete la gente en entrevistas cloud?

Hablar en abstracto. Decir “yo usaría un load balancer” sin especificar cuál, cómo está configurado, o por qué. La especificidad señala experiencia. La vaguedad señala tutoriales.

¿Necesitas un plan completo? Las preguntas cloud son solo una pieza del puzzle. Para la visión completa — coding, system design, comportamental y timing — lee cómo preparar una entrevista técnica en 2026.

¿Listo? Unirme al acceso anticipado →