Google Cloud Professional Cloud Architect
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen PCA. Lee de arriba a abajo o salta a una sección.
Una aplicación global requiere baja latencia y alta disponibilidad para usuarios en todo el mundo.
Utilice un balanceador de carga HTTP(S) global con backends multirregionales (MIGs/GKE), Cloud CDN para contenido estático y Cloud Armor para protección DDoS.
Por qué: El balanceador de carga global proporciona una única IP anycast que dirige a los usuarios al backend saludable más cercano. CDN almacena contenido en el borde, reduciendo la carga de origen y la latencia.
Ingerir y procesar datos de alta capacidad y en tiempo real de dispositivos IoT para análisis inmediato.
Utilice Pub/Sub para la ingesta escalable de mensajes, un pipeline de streaming de Dataflow para el procesamiento en tiempo real y la detección de anomalías, y escriba los resultados en BigQuery para análisis.
Por qué: Este es el patrón serverless canónico para datos en tiempo real. Pub/Sub desacopla la ingesta, Dataflow maneja el procesamiento complejo con autoescalado, y BigQuery soporta inserciones de streaming para análisis en tiempo real.
Un backend de juegos necesita almacenar el estado del jugador y las tablas de clasificación con latencia de lectura inferior al milisegundo y alto rendimiento.
Utilice Cloud Bigtable para el estado del juego/tablas de clasificación y Memorystore (Redis) para el almacenamiento en caché de sesiones.
Por qué: Bigtable proporciona una latencia de milisegundos de un solo dígito para lecturas/escrituras de alto rendimiento, ideal para series temporales o grandes conjuntos de datos analíticos. Memorystore ofrece latencia de microsegundos para el estado de la sesión.
Una aplicación distribuida globalmente requiere una base de datos con fuerte consistencia transaccional y escalabilidad horizontal.
Utilice Cloud Spanner con una configuración multirregional.
Por qué: Spanner es el único servicio que proporciona transacciones globales, fuertemente consistentes con semántica SQL y escalabilidad horizontal. Cloud SQL requiere fragmentación manual para esta escala.
Migrar una base de datos Oracle o PostgreSQL local exigente que requiere alta disponibilidad, rendimiento y refactorización mínima.
Utilice AlloyDB para PostgreSQL.
Por qué: AlloyDB es una base de datos totalmente administrada y compatible con PostgreSQL, con un rendimiento superior, 99.99% de disponibilidad y características de compatibilidad con Oracle, lo que la hace ideal para migraciones empresariales.
Conectar un centro de datos local a GCP con requisitos consistentes de baja latencia (<10ms) y alto ancho de banda (10+ Gbps).
Utilice Dedicated Interconnect con conexiones redundantes.
Por qué: Dedicated Interconnect proporciona una conexión física privada de alto ancho de banda y baja latencia. Cloud VPN funciona a través de internet público y no puede garantizar SLA de latencia o ancho de banda a este nivel.
Diseñar una red para múltiples equipos/proyectos que requieren gestión de red centralizada pero propiedad de proyectos descentralizada.
Implemente un modelo de concentrador y radios utilizando una VPC compartida. El equipo de red central gestiona el proyecto host, y los equipos de aplicaciones utilizan proyectos de servicio.
Por qué: VPC compartida permite un control centralizado sobre los recursos de red (subredes, firewalls) mientras delega la gestión de recursos en los proyectos de servicio. Esto es más escalable y seguro que el emparejamiento de VPC.
Gestionar clusters de Kubernetes de forma consistente en Google Cloud, AWS, Azure y entornos locales.
Utilice Anthos para proporcionar un plano de control unificado para la gestión de clusters multinube e híbridos, la aplicación de políticas y la observabilidad.
Por qué: Anthos extiende GKE a otros entornos, permitiendo operaciones consistentes y gestión de configuración basada en GitOps (Config Management) en toda su flota.
Un equipo de ciencia de datos necesita entrenar modelos complejos de ML con aceleración de GPU sin gestionar la infraestructura.
Utilice Vertex AI Training con contenedores personalizados y Vertex AI Experiments para el seguimiento de iteraciones del modelo.
Por qué: Vertex AI proporciona un servicio de entrenamiento totalmente administrado que gestiona el aprovisionamiento de infraestructura, el escalado y la gestión de GPU. Se integra con experimentos para rastrear y comparar el rendimiento del modelo.
Servir un modelo ML grande con baja latencia y alta disponibilidad, capaz de autoescalado.
Utilice Vertex AI Prediction con un contenedor personalizado, desplegado en un endpoint gestionado con autoescalado habilitado.
Por qué: Vertex AI Prediction está optimizado para el servicio de modelos de baja latencia. Maneja el autoescalado, la división de tráfico (para pruebas A/B) y la gestión de infraestructura, abstraiendo la complejidad de los desarrolladores.
Un servicio de Cloud Function o Cloud Run necesita conectarse de forma segura a una instancia de Cloud SQL con una IP privada.
Configure un conector de acceso VPC sin servidor para conectar el entorno sin servidor con su VPC.
Por qué: El conector crea un túnel hacia su VPC, permitiendo que los servicios sin servidor accedan a los recursos internos por sus direcciones IP privadas sin exponerlos a internet.
Migrar una aplicación con estado que utiliza almacenamiento de sesión local a una plataforma sin estado y autoescalable como Cloud Run o GKE.
Externalice el estado de la sesión a un almacén en memoria gestionado como Memorystore (Redis).
Por qué: El cómputo sin estado requiere que los datos de la sesión se almacenen externamente para que cualquier instancia pueda manejar cualquier solicitud de usuario. Memorystore proporciona una solución compartida de baja latencia para esto.
Crear un pipeline de entrega continua gestionado para promover releases a través de múltiples entornos (preproducción, producción) con aprobaciones.
Utilice Cloud Deploy para definir un pipeline de entrega que orquesta los despliegues a entornos de destino (GKE, Cloud Run) con puertas de aprobación integradas.
Por qué: Cloud Deploy es un servicio totalmente gestionado para CD, que proporciona gestión de releases, auditabilidad y capacidades de reversión automatizada sin la sobrecarga operativa de herramientas autohospedadas como Spinnaker.
Desplegar una aplicación en contenedores en un cluster de Kubernetes listo para producción con una sobrecarga operativa y de gestión mínima.
Utilice un cluster GKE Autopilot.
Por qué: Autopilot gestiona el plano de control y los nodos del cluster, incluyendo el aprovisionamiento, escalado y endurecimiento de seguridad. Solo paga por los recursos de pod que solicita, simplificando tanto las operaciones como la gestión de costos.
Migrar incrementalmente una aplicación monolítica grande a una arquitectura de microservicios con riesgo y tiempo de inactividad mínimos.
Aplique el patrón Strangler Fig. Coloque un proxy delante del monolito y redirija gradualmente el tráfico para funcionalidades específicas a nuevos microservicios a medida que se construyen y validan.
Por qué: Este patrón evita una reescritura de "gran explosión" de alto riesgo al permitir una transición gradual y controlada. El monolito es lentamente "estrangulado" a medida que los nuevos servicios asumen su funcionalidad.
Migrar un gran número de VMs locales a Google Cloud con un tiempo de inactividad mínimo.
Utilice Migrate to Virtual Machines (anteriormente Migrate for Compute Engine) para realizar una replicación continua a nivel de bloque desde entornos locales a GCP, seguida de una rápida transición.
Por qué: Esta herramienta está diseñada para migraciones "lift-and-shift", minimizando el tiempo de inactividad a minutos al mantener las VMs de origen y destino sincronizadas hasta la transición final.
Un equipo está adoptando principios SRE y necesita establecer sus SLOs iniciales.
Defina primero los Indicadores de Nivel de Servicio (SLIs) centrados en el usuario (por ejemplo, disponibilidad, latencia). Analice los datos históricos de rendimiento para establecer Objetivos de Nivel de Servicio (SLOs) iniciales realistas.
Por qué: Los SLOs deben basarse en la experiencia del usuario (SLIs) y ser alcanzables. Establecerlos basándose en datos históricos asegura que el presupuesto de errores inicial sea realista y no se viole inmediatamente.
Automatizar la creación de nuevos proyectos de GCP con una configuración estandarizada (APIs, IAM, redes, seguridad).
Utilice un patrón de "Fábrica de Proyectos" con un módulo de Terraform, activado por Cloud Build. Utilice Service Catalog para proporcionar una interfaz de autoservicio.
Por qué: Esto asegura que todos los nuevos proyectos se adhieran a los estándares organizacionales y a las líneas base de seguridad, reduciendo el esfuerzo manual y la desviación de la configuración. Permite la gobernanza a escala.
Prevenir cambios manuales (desviación de configuración) en la infraestructura gestionada por Terraform.
Utilice un pipeline de CI/CD (por ejemplo, Cloud Build) para todas las aplicaciones, bloqueo de estado de Terraform (a través del backend de GCS), Políticas de la Organización para restringir acciones en la consola y detección regular de desviación.
Por qué: Se requiere un enfoque multicapa. El pipeline impone una única ruta para los cambios, el bloqueo evita aplicaciones concurrentes y las Políticas de la Organización proporcionan una barrera preventiva.
Gestionar código de infraestructura (Terraform) para múltiples entornos (desarrollo, preproducción, producción) con módulos compartidos pero diferentes configuraciones.
Utilice un único conjunto de módulos Terraform reutilizables y proporcione configuraciones específicas del entorno a través de archivos `.tfvars` separados o espacios de trabajo.
Por qué: Esto sigue el principio Don't Repeat Yourself (DRY). Los módulos garantizan la consistencia, mientras que los archivos de variables proporcionan la flexibilidad para adaptar cada entorno.
Implementar un flujo de trabajo GitOps para desplegar automáticamente manifiestos de Kubernetes desde un repositorio Git a clusters GKE.
Utilice Anthos Config Management (o Config Sync independiente) para reconciliar continuamente el estado del cluster con la configuración en un repositorio Git.
Por qué: Config Sync proporciona una solución GitOps totalmente gestionada que detecta y corrige la desviación de configuración, asegurando que el repositorio Git sea la única fuente de verdad para el estado del cluster.
Implementar una implementación azul-verde para una aplicación web con cero tiempo de inactividad y capacidad de reversión instantánea.
Utilice dos Grupos de Instancias Administradas idénticos (o Despliegues de GKE) detrás de un balanceador de carga HTTP(S). Realice la transición redirigiendo el tráfico en el servicio de backend del balanceador de carga.
Por qué: La división de tráfico a nivel del balanceador de carga es instantánea y permite una reversión fácil simplemente volviendo a cambiar el tráfico al backend original. Esto es superior a los métodos más lentos basados en DNS.
Almacenar, gestionar y auditar de forma segura el acceso a secretos como claves API y contraseñas de bases de datos para aplicaciones.
Utilice Secret Manager con IAM para el control de acceso y Workload Identity para la autenticación sin claves desde GKE/Cloud Run.
Por qué: Secret Manager es un servicio centralizado y gestionado con versionado, políticas de rotación y registro de auditoría. El uso de Workload Identity evita la gestión y distribución de claves de cuentas de servicio.
Evitar que los datos sensibles en servicios como BigQuery y Cloud Storage sean accedidos o copiados a proyectos o ubicaciones no autorizadas.
Utilice Controles de Servicio de VPC para crear un perímetro de servicio alrededor de proyectos sensibles y restringir el flujo de datos.
Por qué: Los Controles de Servicio de VPC actúan como un firewall para los servicios gestionados por Google, evitando la exfiltración de datos a nivel de API. Esta es una capa crítica de defensa en profundidad más allá de IAM y los firewalls de red.
Cifrar datos en reposo en los servicios de Google Cloud manteniendo un control total sobre las claves de cifrado.
Utilice Claves de Cifrado Gestionadas por el Cliente (CMEK), con claves almacenadas y gestionadas en Cloud KMS.
Por qué: CMEK le permite utilizar sus propias claves a través de Cloud KMS para proteger los datos en otros servicios de GCP. Usted controla la rotación de claves y puede revocar el acceso deshabilitando la clave, proporcionando un borrado criptográfico.
Diseñar una arquitectura para manejar Información de Salud Protegida (PHI) en cumplimiento con HIPAA.
Utilice CMEK para el control de cifrado, Controles de Servicio de VPC para prevenir la exfiltración, Cargas de Trabajo Aseguradas para límites de cumplimiento, Cloud Audit Logs y Transparencia de Acceso para auditoría.
Por qué: HIPAA requiere una combinación de controles técnicos. CMEK proporciona control de claves, VPC-SC previene fugas de datos y un registro extenso (Audit Logs, Access Transparency) proporciona la auditabilidad necesaria.
Un pod de GKE necesita conectarse a una base de datos de Cloud SQL de forma segura sin usar contraseñas ni gestionar claves de cuentas de servicio.
Utilice Workload Identity para vincular una Cuenta de Servicio de Kubernetes a una Cuenta de Servicio de Google. Conéctese utilizando el sidecar Cloud SQL Auth Proxy y la autenticación de base de datos de IAM.
Por qué: Este patrón "sin contraseña" es el más seguro. Workload Identity proporciona autenticación sin claves, el Auth Proxy cifra el tráfico, e IAM DB auth utiliza IAM para el acceso a la base de datos en lugar de credenciales estáticas.
Aplicar una política que exija que todos los recursos de la nube se creen solo en regiones geográficas específicas (por ejemplo, la UE).
Configure una restricción de Política de la Organización (`gcp.resourceLocations`) a nivel de organización o carpeta, especificando las regiones permitidas.
Por qué: Este es un control preventivo que bloquea la creación de recursos no conformes a nivel de API. Es la forma autoritativa de aplicar políticas de residencia de datos en toda la organización.
Asegurar que solo las imágenes de contenedores confiables, escaneadas y autorizadas se desplieguen en clusters GKE de producción.
Utilice Artifact Registry para el escaneo de vulnerabilidades y Binary Authorization para aplicar políticas de despliegue que requieran atestaciones (firmas) válidas.
Por qué: Esto crea una cadena de suministro de software segura. Artifact Registry escanea en busca de vulnerabilidades, y Binary Authorization actúa como un punto de aplicación de políticas, verificando criptográficamente que una imagen ha pasado todas las comprobaciones requeridas.
Proporcionar acceso seguro y consciente del contexto a aplicaciones web internas para empleados remotos sin usar una VPN tradicional.
Utilice BeyondCorp Enterprise con Identity-Aware Proxy (IAP), Access Context Manager para políticas y Endpoint Verification para la postura del dispositivo.
Por qué: Esto implementa un modelo de confianza cero donde el acceso se otorga basándose en la identidad del usuario y la confianza del dispositivo, no en la ubicación de la red. IAP actúa como un proxy de autenticación para cada solicitud.
Una carga de trabajo regulada requiere que las claves de cifrado se almacenen y procesen dentro de un Módulo de Seguridad de Hardware (HSM) certificado FIPS 140-2 Nivel 3.
Utilice Cloud KMS con el nivel de protección `HSM` para las claves.
Por qué: Cloud HSM es un servicio totalmente gestionado que proporciona HSMs certificados FIPS 140-2 Nivel 3. Las claves generadas con este nivel de protección nunca salen del límite del HSM en texto plano.
Descubrir y desidentificar automáticamente datos sensibles (como PII) en Cloud Storage o BigQuery.
Utilice Cloud Data Loss Prevention (DLP) para escanear datos sensibles y aplicar técnicas de desidentificación como el enmascaramiento, la tokenización o la redacción.
Por qué: DLP proporciona detectores preconstruidos y personalizados para una amplia gama de tipos de datos sensibles, lo que permite una protección de datos automatizada y escalable sin necesidad de scripts personalizados.
Permitir que los empleados de múltiples proveedores de identidad (por ejemplo, Okta, Azure AD) accedan a los recursos de Google Cloud sin crear cuentas de Google.
Utilice Workforce Identity Federation para conectar proveedores de identidad externos a Google Cloud IAM.
Por qué: Esto le permite aprovechar sus sistemas de identidad existentes como fuente de verdad, evitando la necesidad de sincronizar usuarios o gestionar identidades de Google separadas para su personal.
Procesar datos altamente sensibles donde los datos deben permanecer cifrados incluso durante su uso (en memoria).
Utilice VMs Confidenciales.
Por qué: La computación confidencial cifra los datos durante el procesamiento utilizando características de hardware dedicadas (AMD SEV). Esto protege contra ataques de extracción de memoria y proporciona una capa extra de seguridad para cargas de trabajo sensibles.
Optimizar el costo y el rendimiento de BigQuery para un gran almacén de datos.
Implementar particionamiento por fecha y clustering en columnas frecuentemente filtradas. Utilice BI Engine para dashboards y vistas materializadas para agregaciones comunes y costosas.
Por qué: El particionamiento y el clustering son fundamentales para reducir la cantidad de datos escaneados por consulta, lo que reduce directamente los costos y mejora la velocidad. BI Engine y las MV reducen las computaciones redundantes.
Ejecutar trabajos de procesamiento por lotes a gran escala y tolerantes a fallos con el costo de cómputo más bajo posible.
Utilice VMs Spot en un Grupo de Instancias Administradas. Asegúrese de que la aplicación sea tolerante a fallos y pueda manejar interrupciones.
Por qué: Las VMs Spot ofrecen hasta un 91% de ahorro sobre las instancias bajo demanda. Son ideales para cargas de trabajo sin estado y tolerantes a fallos que pueden detenerse y reiniciarse, como muchas tareas de procesamiento por lotes.
Implementar prácticas FinOps para proporcionar visibilidad y responsabilidad de costos a diferentes equipos o departamentos.
Utilice una jerarquía de recursos (carpetas por equipo), aplique etiquetas para la asignación de costos y exporte datos de facturación detallados a BigQuery para su análisis y visualización en Looker Studio.
Por qué: Esta combinación proporciona una forma estructurada de organizar los recursos, rastrear costos de forma granular a través de etiquetas y construir dashboards personalizados y específicos para cada equipo para showback/chargeback.
Optimizar el costo y el rendimiento del cluster GKE para aplicaciones con carga variable.
Utilice Horizontal Pod Autoscaler (HPA) para escalar pods basándose en métricas, y Cluster Autoscaler para añadir/eliminar nodos según sea necesario.
Por qué: Este enfoque de autoescalado de dos niveles asegura que tanto la aplicación (pods) como la infraestructura (nodos) escalen en conjunto con la demanda, previniendo el sobreaprovisionamiento y garantizando el rendimiento.
Un trabajo de entrenamiento de ML muestra una baja utilización de GPU (<30%), lo que indica un cuello de botella.
Diagnosticar y optimizar el pipeline de entrada de datos. Utilice `tf.data` con precarga y lecturas paralelas, o Cloud Storage FUSE para mejorar el rendimiento de E/S.
Por qué: La baja utilización de GPU es casi siempre un cuello de botella de E/S de datos. La GPU está inactiva mientras espera el siguiente lote de datos. Optimizar la carga de datos es el primer paso para mejorar la eficiencia del entrenamiento.
Reducir los altos costos de salida de red al servir datos a internet o entre regiones.
Utilice Cloud CDN para almacenar en caché contenido estático. Para el tráfico entre regiones, utilice el Nivel de Servicio de Red Estándar para cargas de trabajo no sensibles a la latencia.
Por qué: CDN sirve datos desde el borde, lo cual es más barato que la salida desde el origen. El Nivel Estándar enruta el tráfico a través de internet público en lugar de la red premium de Google, ofreciendo un costo menor para la transferencia masiva de datos.
Reducir costos para VMs de desarrollo y prueba que solo se necesitan durante horas de oficina.
Utilice Cloud Scheduler para activar Cloud Functions que inician y detienen automáticamente instancias en un horario predefinido.
Por qué: Este patrón de "programación de instancias" automatiza el proceso de apagar recursos cuando no están en uso, reduciendo significativamente los costos para entornos no productivos.
Una aplicación crítica requiere una base de datos relacional con conmutación por error automática en caso de fallo zonal.
Configure la instancia de Cloud SQL con la opción de Alta Disponibilidad (HA).
Por qué: La configuración de HA crea una instancia en espera en una zona diferente con replicación síncrona. En caso de fallo de la instancia principal o de la zona, la conmutación por error es automática y suele tardar menos de 60 segundos.
Detectar y recuperarse automáticamente de instancias de Compute Engine que no responden o han fallado.
Despliegue instancias dentro de un Grupo de Instancias Administradas (MIG) y configure la autorreparación con una comprobación de estado basada en la aplicación.
Por qué: La autorreparación de MIG sondea activamente la aplicación en cada instancia. Si la aplicación falla su comprobación de estado, el MIG recrea automáticamente la instancia, asegurando la fiabilidad del servicio.
Diseñar un plan de recuperación ante desastres con un RTO de < 1 hora y un RPO de < 15 minutos.
Implemente un "warm standby" en una región secundaria. Utilice réplicas de Cloud SQL entre regiones, Cloud Storage multirregional y plantillas de instancias preconfiguradas para cómputo.
Por qué: Este enfoque equilibra el costo y el tiempo de recuperación. Los datos se replican casi de forma síncrona para cumplir con el RPO, y una infraestructura mínima está en funcionamiento (caliente) para permitir un escalado rápido que cumpla con el RTO.
Implementar una observabilidad integral para una aplicación de microservicios para permitir una rápida resolución de problemas.
Utilice el registro estructurado con IDs de correlación, Cloud Trace para el rastreo distribuido, Cloud Monitoring para métricas y Cloud Error Reporting para la agrupación automatizada de errores.
Por qué: Una combinación de logs, traces y métricas (los "tres pilares de la observabilidad") es esencial. Los IDs de correlación y el rastreo distribuido son críticos para seguir una sola solicitud a través de múltiples servicios.
Evitar que un fallo en un microservicio provoque un fallo en cascada en toda la aplicación.
Implemente patrones de resiliencia como disyuntores, reintentos con retroceso exponencial y tiempos de espera agresivos en cada punto de comunicación entre servicios.
Por qué: Estos patrones aíslan los fallos. Un disyuntor detiene las llamadas a un servicio fallido, evitando que el servicio que llama agote sus recursos y falle a su vez.
Implementar las mejores prácticas de SRE para reducir el riesgo de interrupciones de producción causadas por nuevos despliegues.
Utilice despliegues canary para implementar cambios gradualmente, feature flags para desacoplar el despliegue del lanzamiento y disparadores de reversión automáticos basados en la monitorización de SLO.
Por qué: Estas prácticas limitan el "radio de impacto" de un despliegue defectuoso. Los canaries exponen la nueva versión a un pequeño subconjunto de usuarios primero, y la reversión automatizada minimiza el Tiempo Medio de Recuperación (MTTR).
Utilizar presupuestos de errores de SRE para equilibrar la velocidad de las características con la fiabilidad.
Defina una política de presupuesto de errores: cuando el presupuesto esté casi consumido, congele los nuevos despliegues de características y priorice el trabajo que mejore la fiabilidad.
Por qué: El presupuesto de errores es un mecanismo basado en datos para tomar decisiones de compromiso. Permite a los equipos asumir riesgos cuando el presupuesto es saludable y exige un enfoque en la estabilidad cuando no lo es.
Una aplicación distribuida globalmente que utiliza Cloud Spanner experimenta alta latencia de escritura en ciertas regiones.
Analice los patrones de escritura de la aplicación y configure la región líder de la instancia de Spanner para que esté geográficamente cerca de la mayoría de las operaciones de escritura.
Por qué: En Spanner, todas las escrituras se enrutan a través de la región líder para garantizar la consistencia. Colocar la región líder cerca de la fuente principal de escrituras minimiza la latencia de red para esas transacciones.
