El despliegue es el comienzo de las operaciones
En el momento en que se aprovisiona la primera infraestructura en Google Cloud, el verdadero desafío comienza. Levantar una base de datos, conectar redes y recibir tráfico externo no son tareas aisladas — forman un flujo estrechamente interconectado. A medida que los datos se acumulan es necesario ajustar las clases de almacenamiento. Cuando el tráfico crece hay que afinar los balanceadores de carga y las reglas de firewall. Si la conectividad híbrida se vuelve un requisito, hay que elegir entre Cloud Interconnect y Cloud VPN. Cuando el mismo entorno debe aprovisionarse repetidamente para múltiples equipos, se necesita un pipeline de Terraform.
El dominio de "Despliegue e implementación" del examen ACE no pregunta cómo crear recursos. Pregunta qué servicio elegir bajo qué restricciones. Este artículo comprime seis subdominios — despliegue de soluciones de datos, despliegue de recursos de red, balanceadores de carga, Marketplace, IaC y cambios de configuración en producción — en marcos de decisión orientados a escenarios.
---
Despliegue de recursos de datos: Cloud SQL, BigQuery y Cloud Storage
Cloud SQL ofrece MySQL, PostgreSQL y SQL Server como motores completamente administrados. Al configurar alta disponibilidad, se aprovisiona automáticamente una instancia en espera en una zona diferente dentro de la misma región, y el failover automático se activa ante una falla de la instancia. Las réplicas de lectura distribuyen la carga de lectura, pero también replican la corrupción de datos — por lo tanto, para protección de datos hay que confiar en los respaldos automatizados y en Point-in-time Recovery (PITR), no en las réplicas.
| Función de Cloud SQL | Propósito | Advertencia | |---|---|---| | Réplica de lectura | Distribuir carga de lectura | También replica la corrupción — no es un mecanismo de protección | | HA (Alta Disponibilidad) | Recuperación automática ante falla de instancia | Protege contra fallas zonales | | Respaldo automatizado + PITR | Restaurar a un punto específico en el tiempo | Hasta 7 días de reversión |
BigQuery es un motor OLAP sin servidor. Para estimar el costo de una consulta antes de ejecutarla bajo el modelo de precios bajo demanda, se utiliza el flag . Un dry run devuelve únicamente la cantidad de bytes que procesaría la consulta — no la ejecuta y no genera cargos. No hay que confundir EXPLAIN con dry run: EXPLAIN sirve para analizar planes de ejecución, no para estimar costos. Para analizar datos de BigQuery sin SQL, se conecta mediante Connected Sheets o Looker Studio. Para consultar directamente archivos almacenados en Cloud Storage, se crea una External Table.
Las clases de almacenamiento de Cloud Storage y las políticas de Object Lifecycle aparecen repetidamente en el examen.
| Clase de almacenamiento | Duración mínima | Frecuencia de acceso | Caso de uso típico | |---|---|---|---| | Standard | Ninguna | Frecuente | Datos activos, servicio web | | Nearline | 30 días | Menos de una vez al mes | Respaldos mensuales | | Coldline | 90 días | Menos de una vez por trimestre | Archivos de cumplimiento |
| Archive | 365 días | Menos de una vez al año | Retención de logs a largo plazo |
Las reglas de Object Lifecycle hacen la transición automática de objetos a clases más económicas o los eliminan tras una antigüedad configurada. Retention Policy es una función de bloqueo contra eliminación — es distinta de Object Lifecycle, que gestiona transiciones y eliminaciones. Para compartir objetos externamente con límite de tiempo, se usan Signed URLs.
---
Despliegue de recursos de red: VPC, Cloud NAT, Cloud VPN y Cloud Interconnect
GCP VPC es un recurso global. Una sola VPC puede abarcar subredes en múltiples regiones. Los rangos de IP primarios de las subredes pueden expandirse pero no reducirse. Para permitir que las VMs sin IP externa accedan a las APIs de Google, se habilita Private Google Access en la subred.
Las reglas de firewall controlan el tráfico de entrada y salida basándose en etiquetas de red o cuentas de servicio. Los valores de prioridad numérica más bajos se evalúan primero. Dentro de una sola VPC, aislar servicios mediante segmentación de subredes más reglas de firewall basadas en etiquetas es el enfoque correcto — aplica aislamiento sin alterar la topología existente. Para comunicación interna entre VPCs en diferentes proyectos, se usa VPC Network Peering, pero hay que recordar que el peering es no transitivo: si A hace peering con B y B con C, A y C no pueden comunicarse sin un peering explícito entre ellas.
| Conectividad híbrida | Ruta | Ancho de banda máximo | Característica clave | |---|---|---|---| | Cloud VPN (HA) | Internet público (IPsec) | 3 Gbps por túnel | Enrutamiento dinámico BGP | | Dedicated Interconnect | Circuito físico privado | 200 Gbps | SLA 99.9%+, sin tránsito por internet | | Partner Interconnect | A través de proveedor asociado | 50 Mbps – 10 Gbps | Efecto de línea dedicada sin colocation |
Cloud NAT expone una IP NAT estable hacia internet independientemente de los cambios en las IPs de las VMs subyacentes. Los escenarios que requieren simultáneamente transferencias de alto rendimiento y una IP de egreso fija para la gestión de listas de permitidos se resuelven mejor combinando Dedicated Interconnect con Cloud NAT. Para proteger las zonas públicas de Cloud DNS contra la falsificación de respuestas DNS, se habilita DNSSEC.
---
Configuración de balanceadores de carga y servicios de backend
La elección del balanceador de carga correcto en GCP depende de la capa OSI (L4 vs. L7) y el alcance (global vs. regional).
| Tipo de balanceador de carga | Capa | Alcance | Características clave | |---|---|---|---| | HTTP(S) LB externo | L7 | Global | IP Anycast, integración con CDN y Armor, failover multirregional | | Network LB externo | L4 | Regional | Passthrough UDP/TCP, menor latencia | | HTTP(S) LB interno | L7 | Regional | Distribución HTTP entre microservicios dentro de una VPC | | TCP/UDP LB interno | L4 | Regional | TCP/UDP dentro de una VPC |
El balanceador de carga HTTP(S) externo global se integra con certificados SSL administrados por Google para automatizar completamente la renovación de certificados. Los Backend Services definen los grupos de instancias o Network Endpoint Groups (NEGs) que reciben tráfico, y los health checks eliminan automáticamente de la rotación a las instancias no saludables. Reservar una IP externa estática para el frontend del balanceador de carga fija la dirección IP para que los backends puedan reemplazarse sin actualizar registros DNS.
Trampa del examen: cuando un escenario requiere Anycast global, integración con CDN o failover multirregional, un balanceador de carga de red regional es la respuesta incorrecta. Hay que seleccionar el balanceador de carga HTTP(S) externo global.
---
Comenzar rápidamente con Marketplace
Google Cloud Marketplace es un catálogo de soluciones preconfiguradas que pueden desplegarse en pocos clics. Stacks de código abierto como Cassandra, WordPress y Jenkins vienen empaquetados con licencias, configuración de VM y configuración de red.
| Tipo de despliegue en Marketplace | Descripción | |---|---| | Solución de imagen de VM | VM de Compute Engine con software preinstalado; el licenciamiento de software puede facturarse por separado | | Aplicación de Kubernetes | Chart de Helm desplegado en un clúster GKE | | Módulo de Terraform | Basado en IaC, código reutilizable | | Suscripción SaaS | Servicio administrado externamente por el proveedor |
Al seleccionar una solución de Marketplace e ingresar solo el proyecto, la región y el tipo de máquina, la VPC, las reglas de firewall y la VM se crean automáticamente. En el examen, cuando aparecen las palabras clave "minimizar la sobrecarga operativa" combinadas con "desplegar rápidamente una solución probada," Marketplace es la respuesta. Para personalización detallada o despliegues repetibles gestionados por código, Terraform es la mejor opción.
---
Infrastructure as Code: Deployment Manager, Config Connector y Terraform
IaC es la práctica de declarar la infraestructura como código versionado.
| Herramienta | Lenguaje | Cobertura | Caso de uso principal | |---|---|---|---| | Deployment Manager | YAML / Jinja2 / Python | Solo GCP | Entornos GCP heredados | | Config Connector | YAML (K8s CRD) | GCP (basado en GKE) | Integración GitOps con GKE | | Terraform | HCL | Multi-cloud | Estándar para proyectos nuevos |
Deployment Manager admite el flag para mostrar los cambios antes de aplicarlos. Es nativo de GCP pero no tiene soporte multi-cloud y su ecosistema de comunidad es más pequeño.
Terraform es la herramienta IaC que aparece con mayor frecuencia en los escenarios del examen ACE. Se usa para previsualizar cambios y para aplicarlos. Terraform es idempotente — ejecutar el mismo código varias veces siempre produce el mismo resultado — lo que hace que los despliegues repetidos sean seguros. Almacenar el código de Terraform en Cloud Source Repositories y conectarlo a triggers de Cloud Build permite ejecutar automáticamente plan y apply en cada merge de pull request. Cloud Foundation Toolkit (CFT) es una colección curada de módulos de Terraform validados para aplicar rápidamente políticas de organización, configuraciones de VPC y bases de IAM.
Para escenarios que requieren aprovisionar repetidamente un entorno estándar — VPC, Cloud SQL, políticas IAM, buckets de Cloud Storage — para múltiples equipos, Terraform combinado con un pipeline de Cloud Build es la respuesta correcta.
---
Cambios en producción: políticas de ciclo de vida, permisos y reglas de firewall
Esta sección cubre los escenarios de cambio operativo más frecuentes tras el despliegue inicial.
Las políticas de Object Lifecycle de Cloud Storage pueden agregarse o modificarse en buckets existentes en cualquier momento y se aplican retroactivamente a los objetos existentes. P