← Blog
Preguntas de Entrevista GCP: Guía Completa con Respuestas (2026)
seo

Preguntas de Entrevista GCP: Guía Completa con Respuestas (2026)

20 preguntas de entrevista Google Cloud Platform con frameworks de respuesta detallados, desde fundamentos hasta escenarios avanzados.

· 19 min de lectura

Preguntas de Entrevista GCP: Guía Completa con Respuestas (2026)

Casi arruino mi primera entrevista de Google Cloud. No porque no conociera GCP — llevaba dos años ejecutando workloads en la plataforma. Lo arruiné porque respondía como si estuviera leyendo documentación en vez de hablar como alguien que realmente había operado la plataforma.

La entrevistadora me preguntó sobre Cloud Spanner. Solté todas las características técnicas. Distribuido globalmente, fuertemente consistente, relacional. Todo correcto. Todo aburrido. Lo que ella realmente quería escuchar era por qué elegiría Spanner sobre Cloud SQL para un caso de uso específico, cuáles eran las implicaciones de costo, y si alguna vez me había sorprendido su modelo de precios. No estaba preparado para ese tipo de conversación.

Esa experiencia cambió cómo pienso sobre las entrevistas GCP. Las preguntas no son sobre qué servicios existen. Son sobre si has tomado decisiones reales con ellos. Aquí van 20 preguntas que he encontrado repetidamente — agrupadas por nivel — con los frameworks de respuesta que realmente funcionan.

Fundamentos: Las Preguntas Que Parecen Fáciles Hasta Que Dejan de Serlo

1. ¿Qué es Google Cloud Platform y cómo funciona su infraestructura global?

Qué decir: GCP organiza los recursos en regiones y zonas. Una región es una ubicación geográfica (como europe-west1). Cada región tiene al menos tres zonas, que son dominios de fallo aislados. Los recursos como las instancias de Compute Engine viven en una zona específica. Algunos servicios — Cloud Storage, BigQuery — son multi-regionales o globales por diseño, lo cual cambia cómo piensas sobre la disponibilidad.

Error común: Describir regiones y zonas como si fueran intercambiables con AWS. No lo son. La red de GCP está construida sobre la fibra privada de Google, y el modelo de red plana significa que las redes VPC son globales por defecto — no regionales como las VPCs de AWS. Esa distinción importa en las discusiones de arquitectura.

2. Explica la diferencia entre Compute Engine, App Engine, Cloud Run y Cloud Functions.

Qué decir: Es un espectro entre control y comodidad. Compute Engine te da VMs completas — gestionas todo. App Engine es un PaaS que maneja el scaling y el despliegue para runtimes estándar. Cloud Run ejecuta contenedores stateless sin gestionar infraestructura — traes una imagen Docker, él se encarga del resto. Cloud Functions es event-driven: escribes una función, le adjuntas un trigger, listo. La decisión depende de cuánta carga operacional tu equipo puede absorber.

Error común: Tratar Cloud Run y Cloud Functions como lo mismo. Cloud Run maneja contenedores arbitrarios con HTTP o gRPC, soporta concurrencia por instancia y puede ejecutarse hasta 60 minutos. Cloud Functions es de propósito único, activado por eventos, con un límite de ejecución más ajustado. Saber cuándo cada uno encaja es la verdadera habilidad que se está evaluando.

3. ¿Cómo funciona IAM en GCP?

Qué decir: IAM de GCP sigue una jerarquía de recursos: Organización > Carpetas > Proyectos > Recursos. Las políticas se heredan hacia abajo. Asignas roles a miembros (usuarios, grupos, cuentas de servicio). Los roles son colecciones de permisos. Existen roles básicos (Owner, Editor, Viewer), roles predefinidos (granulares por servicio) y roles personalizados. Siempre prefiere los roles predefinidos sobre los básicos — Editor otorga demasiado acceso para la mayoría de los casos de uso.

Error común: Ignorar la jerarquía. Un rol otorgado a nivel de organización se propaga a cada proyecto debajo. He visto equipos otorgar Editor a nivel org “por comodidad” y crear una pesadilla de seguridad. Siempre otorga permisos en el ámbito más estrecho posible.

4. ¿Qué es una VPC en GCP y en qué se diferencia de otros proveedores cloud?

Qué decir: Una VPC de GCP es global. Esa es la diferencia clave. Creas una VPC y agregas subnets en cualquier región — no necesitas VPC peering entre regiones dentro de la misma red. Las subnets son regionales y usan rangos CIDR. Las reglas de firewall se aplican a nivel de red usando tags o cuentas de servicio, no se adjuntan a instancias individuales como los security groups en AWS.

Error común: Diseñar la red GCP como si fuera AWS. En AWS crearías una VPC por región y las conectarías con peering. En GCP, a menudo basta con una VPC con subnets regionales. Luchar contra el modelo de GCP en vez de adoptarlo crea complejidad innecesaria.

5. ¿Qué es Cloud Storage y cómo funcionan las clases de almacenamiento?

Qué decir: Cloud Storage es el servicio de almacenamiento de objetos de GCP — equivalente a S3. Los objetos van en buckets. Las clases de almacenamiento controlan el costo y la disponibilidad: Standard para acceso frecuente, Nearline para acceso mensual, Coldline para trimestral y Archive para anual. Puedes definir políticas de ciclo de vida para transicionar automáticamente objetos entre clases.

Error común: Olvidar los costos de egress. El almacenamiento en Coldline puede ser barato, pero las tarifas de recuperación y egress se acumulan rápido si tus patrones de acceso no coinciden con la clase elegida. He visto equipos ahorrar 200 $/mes en almacenamiento y luego gastar 800 $ en recuperaciones inesperadas.

Intermedio: Demostrar Que Has Construido Algo Real

6. ¿Cómo diseñarías un pipeline CI/CD en GCP?

Qué decir: Cloud Build es el servicio CI/CD nativo de GCP. Defines los pasos en un archivo cloudbuild.yaml. Un pipeline típico: disparar con un push a un repo de GitHub, ejecutar tests, construir una imagen Docker, subirla a Artifact Registry, desplegar en Cloud Run o GKE. Para workflows más complejos, puedes encadenar triggers de Cloud Build o integrar Pub/Sub para pipelines event-driven. Secret Manager maneja las credenciales durante los builds.

Error común: Complicarlo demasiado. Algunos candidatos saltan inmediatamente a Jenkins en GKE o herramientas de terceros. Si el entrevistador pregunta sobre CI/CD nativo de GCP, empieza con Cloud Build. Luego menciona que para necesidades de orquestación complejas — promoción multi-entorno, gates de aprobación — podrías incorporar Spinnaker o Argo CD en GKE.

7. ¿Cuándo elegirías BigQuery en vez de Cloud SQL o Cloud Spanner?

Qué decir: BigQuery es un data warehouse serverless optimizado para consultas analíticas sobre datasets masivos. Cloud SQL es MySQL/PostgreSQL gestionado para cargas transaccionales. Cloud Spanner es distribuido globalmente, fuertemente consistente y relacional — es para cuando necesitas tanto escalado horizontal como transacciones ACID. El árbol de decisión: ¿OLTP con escala moderada? Cloud SQL. ¿OLTP a escala global con consistencia fuerte? Spanner. ¿Analytics y reporting sobre terabytes de datos? BigQuery.

Error común: Sugerir BigQuery para cargas transaccionales. BigQuery es columnar y optimizado para escaneos, no para lookups puntuales o escrituras pequeñas frecuentes. Usarlo como base de datos primaria de una aplicación sería un error arquitectónico costoso.

8. Explica Pub/Sub y cuándo lo usarías.

Qué decir: Pub/Sub es un servicio de mensajería gestionado para comunicación asíncrona. Los publicadores envían mensajes a topics, los suscriptores reciben desde suscripciones. Garantiza entrega al-menos-una-vez con plazos de acuse configurables. Úsalo para: desacoplar microservicios, arquitecturas event-driven, ingesta de datos en streaming (combinado con Dataflow), y buffer entre sistemas con diferentes tasas de throughput.

Error común: No mencionar el ordenamiento y la semántica de exactamente-una-vez. Pub/Sub ahora soporta claves de ordenamiento para entrega ordenada dentro de una clave, y entrega exactamente-una-vez para suscripciones pull. Si el entrevistador pregunta sobre ordenamiento de eventos, necesitas saber que estas funcionalidades existen — y que vienen con compromisos de throughput.

9. ¿Cómo gestionas infraestructura como código en GCP?

Qué decir: Terraform es la opción más común — es agnóstico del cloud y el provider de GCP es maduro. Google también ofrece Deployment Manager (nativo pero limitado) y Config Connector (nativo de Kubernetes, gestiona recursos GCP mediante CRDs). Para Terraform, almacena el estado en un backend GCS con versionado y bloqueo de estado mediante los mecanismos integrados de Cloud Storage.

Error común: Ignorar la gestión del estado. He visto equipos usar estado Terraform local en una VM compartida y corromperlo en una semana. Estado remoto en GCS con un pipeline CI/CD ejecutando terraform plan en los PRs — ese es el patrón que sobrevive a las dinámicas de equipo reales.

10. ¿Cuál es la diferencia entre GKE Standard y GKE Autopilot?

Qué decir: GKE Standard te da control total sobre los nodos — gestionas node pools, tipos de máquina, políticas de scaling, parcheo del OS. GKE Autopilot elimina la gestión de nodos: Google aprovisiona y escala los nodos según las specs de tus pods. Pagas por recurso solicitado por pod, no por nodo. Autopilot aplica mejores prácticas de seguridad por defecto (sin pods privilegiados, sin acceso a la red del host). Elige Standard para workloads GPU, tipos de máquina específicos o DaemonSets que Autopilot restringe. Elige Autopilot cuando quieras concentrarte en los workloads, no en la infraestructura.

Error común: Descartar Autopilot como “no listo para producción”. Lo está. Google ejecuta workloads significativos en él. La limitación real está en personalizaciones específicas — parámetros de kernel custom, ciertos drivers CSI, o workloads que necesitan acceso privilegiado. Conoce las restricciones, no descartes la opción.

Avanzado: Donde la Experiencia Real Se Nota

11. Diseña una aplicación distribuida globalmente en GCP.

Qué decir: Usa Cloud Spanner para la capa de base de datos — es la única base relacional que proporciona consistencia fuerte global. Despliega la aplicación en clusters GKE en múltiples regiones usando Multi Cluster Ingress o Cloud Load Balancing con un Application Load Balancer externo global. Cloud CDN para contenido estático. Cloud Armor para protección DDoS y reglas WAF. Pub/Sub para propagación de eventos entre regiones. Cloud DNS con enrutamiento por geolocalización para dirigir usuarios a la región más cercana.

Error común: Olvidar la conversación de costos. Cloud Spanner a escala global es caro — las configuraciones multi-región empiezan con un mínimo de nodos que puede costar miles de dólares al mes. Una buena respuesta reconoce esto y menciona que para algunos casos de uso, Firestore en modo multi-región o una arquitectura Cloud SQL con réplicas de lectura podría ser suficiente a una fracción del costo.

12. ¿Cómo implementarías seguridad zero-trust en GCP?

Qué decir: BeyondCorp Enterprise es el framework zero-trust de Google. Usa Identity-Aware Proxy (IAP) para controlar el acceso a aplicaciones sin VPN — cada solicitud se autentica y autoriza según la identidad del usuario y el contexto del dispositivo. VPC Service Controls crea perímetros de seguridad alrededor de APIs sensibles. Workload Identity para que los pods de GKE asuman identidades de cuentas de servicio sin archivos de claves. Binary Authorization garantiza que solo las imágenes de contenedor aprobadas se desplieguen en tus clusters.

Error común: Reducir zero-trust a “solo usa IAP”. Zero-trust es una estrategia en capas: verificación de identidad (IAP, Identity Platform), verificación de postura del dispositivo (BeyondCorp), segmentación de red (VPC Service Controls), protección de datos (API DLP, CMEK), y monitorización continua (Security Command Center). Mencionar solo una capa demuestra comprensión superficial.

13. Explica la arquitectura de Cloud Spanner y cuándo vale la pena su costo.

Qué decir: Spanner usa TrueTime — relojes atómicos sincronizados y receptores GPS en cada datacenter de Google — para alcanzar consistencia externa entre réplicas globales sin los cuellos de botella tradicionales del consenso. Los datos se fragmentan en splits, y cada split tiene un grupo Paxos. Vale la pena su costo cuando necesitas simultáneamente escala global, consistencia fuerte y semántica relacional — sistemas de transacciones financieras, gestión de inventario global, o tablas de clasificación de juegos a escala masiva.

Error común: No ser honesto sobre las desventajas. Spanner requiere un diseño de esquema cuidadoso — tablas entrelazadas, elegir buenas claves primarias para evitar hotspots. Tiene una curva de aprendizaje empinada comparada con Cloud SQL. Y el costo mínimo para una instancia multi-región en producción es significativo. Si tus datos caben en una sola región y no necesitas escrituras globales, Cloud SQL con réplicas de lectura suele ser la opción pragmática.

14. ¿Cómo optimizas costos en GCP?

Qué decir: Empieza con exports de facturación a BigQuery — eso te da datos de costos consultables. Usa descuentos por compromiso de uso (CUD) para workloads predecibles de Compute Engine y Cloud SQL. VMs preemptibles (o Spot VMs) para procesamiento batch tolerante a fallos. Dimensiona correctamente las instancias con las sugerencias de la API Recommender. Configura alertas de presupuesto. Para GKE, usa cluster autoscaler y vertical pod autoscaler para evitar el sobre-aprovisionamiento. Revisa y elimina recursos sin usar — VMs inactivas, discos persistentes huérfanos, snapshots antiguos.

Error común: Enfocarse solo en el cómputo. Los costos de almacenamiento, egress de red y logging/monitorización suelen sorprender a los equipos. El precio bajo demanda de BigQuery puede dispararse con consultas mal escritas que escanean tablas enteras — usa particionamiento, clustering y reservaciones de slots para costos de analytics predecibles.

15. Guíame en la depuración de un problema de latencia en una arquitectura de microservicios en GKE.

Qué decir: Empieza con los dashboards de Cloud Monitoring y los SLOs para identificar qué servicio está lento. Usa Cloud Trace para ver trazas distribuidas entre servicios y localizar el cuello de botella. Revisa Cloud Logging para picos de errores. Culpables comunes: retrasos en resolución DNS (verifica la configuración de ndots en los pods), requests de recursos mal configurados causando throttling de CPU, cold starts en despliegues auto-escalados, o un servicio downstream alcanzando el límite de su pool de conexiones. Usa kubectl top pods y el estado del Horizontal Pod Autoscaler para verificar la presión sobre los recursos.

Error común: Saltar directamente a depuración a nivel de código sin verificar la infraestructura primero. Nueve de cada diez veces, los problemas de latencia en GKE vienen de límites de recursos, network policies, o probes mal configurados — no de la lógica aplicativa.

Escenarios: Pensar en Problemas Reales

16. Tu servicio Cloud Run está dando timeouts durante picos de tráfico. ¿Qué haces?

Qué decir: Verifica el ajuste de concurrencia por instancia — si está en 1, cada instancia maneja una sola solicitud, creando una presión masiva de scale-up. Auméntalo para que coincida con lo que tu contenedor puede manejar (80-100 para APIs stateless es común). Verifica el límite máximo de instancias — podría estar limitando el escalado. Revisa los tiempos de cold start: usa instancias mínimas para mantener contenedores calientes. Si el servicio depende de una base de datos, verifica el connection pooling — Cloud SQL Auth Proxy con límites de conexión previene el agotamiento del pool.

Error común: Sugerir inmediatamente una migración a GKE. Cloud Run puede manejar la mayoría de los desafíos de escalado con configuración adecuada. La solución generalmente está en los ajustes de concurrencia, las instancias mínimas, o los cuellos de botella downstream — no en una migración de plataforma.

17. Necesitas migrar una aplicación legacy on-premise a GCP. ¿Cómo lo abordas?

Qué decir: Empieza con la evaluación usando Migration Center para descubrir y analizar el entorno existente. Fase uno: lift-and-shift de VMs a Compute Engine con Migrate to Virtual Machines. Esto te lleva al cloud rápidamente con cambios mínimos. Fase dos: modernizar incrementalmente — conteneurizar servicios para GKE o Cloud Run, reemplazar bases de datos auto-gestionadas por Cloud SQL o Firestore, mover almacenamiento de archivos a Cloud Storage. Transfer Appliance para grandes volúmenes de datos y Database Migration Service para datos estructurados.

Error común: Proponer una reescritura completa como primer paso. Las migraciones fallan cuando los equipos intentan modernizar todo simultáneamente. Lift-and-shift primero, estabilizar, luego modernizar los componentes que más se benefician de servicios cloud-nativos. El patrón Strangler Fig funciona aquí también.

18. Una consulta de BigQuery que antes tardaba 10 segundos ahora tarda 5 minutos. ¿Qué pasó?

Qué decir: Verifica si el volumen de datos de la tabla ha crecido significativamente. Mira el plan de ejecución buscando escaneos de tabla completa — la tabla podría necesitar particionamiento (por fecha es lo más común) o clustering (por columnas frecuentemente filtradas). Verifica si alguien eliminó una vista materializada que estaba sirviendo la consulta. Revisa la utilización de slots — en precios bajo demanda, compartes slots con otros proyectos y podrías estar en cola. Considera slots reservados para rendimiento consistente. También revisa cambios de esquema recientes que podrían haber invalidado el partition pruning.

Error común: No verificar la causa más simple primero: alguien podría haber cambiado la consulta misma o eliminado una cláusula WHERE que estaba filtrando particiones. Siempre compara la consulta lenta con la versión anterior antes de investigar la infraestructura.

19. Diseña un pipeline de datos event-driven para analytics en tiempo real.

Qué decir: Pub/Sub ingesta eventos de los productores. Dataflow (Apache Beam gestionado) procesa el flujo — transformaciones, enriquecimiento, ventaneo. Escritura de resultados a BigQuery para analytics y dashboards. Para requisitos de latencia sub-segundo, escribir también a Bigtable para serving. Cloud Monitoring para rastrear el lag del pipeline. Topics dead-letter en Pub/Sub manejan mensajes envenenados. Schema Registry (o simplemente validación de esquema en los topics de Pub/Sub) asegura la calidad de datos en el origen.

Error común: Ignorar la backpressure y el manejo de errores. Un pipeline de producción necesita colas de mensajes muertos, políticas de reintento y monitorización del lag del consumidor. Los candidatos que solo describen el camino feliz no han operado un pipeline a escala.

20. Tu equipo quiere usar múltiples proyectos GCP para diferentes entornos. ¿Cómo lo configuras?

Qué decir: Usa una jerarquía de recursos: Organización > Carpetas (por departamento o equipo) > Proyectos (dev, staging, prod por servicio). Aplica políticas de organización a nivel de carpeta — restringir regiones, imponer labels, deshabilitar la creación de IPs externas en prod. Shared VPC para centralizar la red: el proyecto host posee la VPC, los proyectos de servicio despliegan recursos en subnets compartidas. Módulos Terraform con archivos de variables por entorno para mantener la infraestructura consistente. Los pipelines CI/CD despliegan a cada proyecto con cuentas de servicio específicas por entorno.

Error común: Crear VPCs separadas por proyecto y luego luchar con la conectividad. Shared VPC es la respuesta de GCP al networking entre proyectos y evita el spaghetti de peering que viene con una VPC por proyecto.

Servicios GCP Que Debes Conocer

Más allá de los servicios cubiertos en las preguntas anteriores, asegúrate de poder hablar con confianza sobre estos:

No necesitas experiencia profunda en todos ellos. Pero debes saber qué problema resuelve cada uno y cuándo lo usarías en lugar de una alternativa.

Usar el GCP Free Tier para Practicar

Aquí va un consejo práctico que marcó la diferencia en mi propia preparación: usa el GCP free tier para construir cosas reales, no solo para leer sobre ellas.

Google ofrece un free tier generoso que incluye:

Es suficiente para construir una arquitectura event-driven completa sin gastar un centavo. Esto es lo que construiría: una Cloud Function que publica eventos a Pub/Sub, un servicio Cloud Run que los procesa, BigQuery para analytics, y Firestore para el estado de la aplicación. Te encontrarás con problemas reales — configuración IAM, networking, cold starts — que te preparan para las conversaciones de entrevista de maneras que los tutoriales nunca lograrán.

Un detalle importante: el free tier tiene límites específicos por servicio, y superarlos genera cargos. Configura alertas de presupuesto inmediatamente después de crear tu proyecto. Yo puse las mías en 5 $ con notificaciones por email. Ha detectado excesos accidentales más de una vez.

Los 300 $ de créditos gratuitos para cuentas nuevas cubren lo que el free tier permanente no cubre. Úsalos para experimentar con GKE y Cloud Spanner — son demasiado caros para explorar sin créditos.

FAQ

¿Cuántas certificaciones GCP debería tener antes de ir a una entrevista?

Una certificación relevante suele ser suficiente para pasar los filtros de CV. La Associate Cloud Engineer o la Professional Cloud Architect son las más reconocidas. Pero las certificaciones por sí solas no te hacen superar entrevistas — he conocido candidatos certificados incapaces de diseñar una VPC básica. Combina la certificación con proyectos prácticos de los que puedas hablar en detalle.

¿Son las entrevistas GCP más difíciles que las de AWS?

La dificultad es comparable, pero el estilo difiere. Las entrevistas GCP tienden a enfatizar más la ingeniería de datos y analytics, reflejando la dominancia de BigQuery en el ecosistema. Las entrevistas AWS se inclinan más hacia la amplitud operacional. Si estás entrevistando en una empresa que eligió GCP, espera preguntas sobre BigQuery, Pub/Sub y Dataflow — la stack de datos de Google es generalmente la razón por la que eligieron GCP.

¿Debo aprender Kubernetes para una entrevista GCP?

Si el puesto involucra GKE, absolutamente. GKE es el servicio de orquestación de contenedores insignia de GCP y muchas empresas GCP usan Kubernetes intensivamente. Debes entender pods, deployments, services, ingress, namespaces y autoscaling como mínimo. Para roles senior, prepárate para preguntas sobre Istio/Anthos Service Mesh, Workload Identity y gestión multi-cluster.

¿Cuál es el error más grande que cometen los candidatos en entrevistas GCP?

Tratar GCP como “AWS con nombres diferentes”. GCP tiene opiniones arquitectónicas genuinamente distintas — VPCs globales, aislamiento de recursos basado en proyectos, el modelo serverless de BigQuery, TrueTime de Cloud Spanner. Los candidatos que solo traducen conceptos de AWS sin entender los patrones nativos de GCP parecen superficiales. Aprende por qué GCP tomó decisiones de diseño diferentes, no solo cuáles son los servicios equivalentes.

¿Quieres una preparación cloud más amplia? Estas preguntas GCP son parte de un panorama más grande. Para preguntas cloud generales que cubren los tres proveedores, lee Top 15 Preguntas de Entrevista Cloud (AWS, Azure, GCP).

¿Buscas una estrategia de entrevista completa? Las preguntas técnicas son solo una pieza. Para el plan completo — coding, system design, comportamental, y timing — consulta cómo preparar una entrevista técnica en 2026.

¿Terminaste de leer? Únete al acceso anticipado —>

¿Listo/a para dominar tu próxima entrevista?

Únete al acceso anticipado y sé de los primeros en probar SkillRealm Interview.

Sin spam. Cancela cuando quieras.

preguntas entrevista GCP 2026 preparacion entrevista google cloud platform preguntas certificacion GCP entrevista guia entrevista ingeniero google cloud