Google Cloud Digital Leader
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen CDL. Lee de arriba a abajo o salta a una sección.
Cambiar el gasto de TI de grandes compras iniciales de hardware a un modelo de pago por uso.
Utilizar servicios en la nube para convertir el gasto de capital (CapEx) en gasto operativo (OpEx).
Por qué: La nube proporciona flexibilidad financiera, reduce las barreras de entrada y alinea los costos directamente con el uso, evitando el exceso de aprovisionamiento.
Aclarar la titularidad de la seguridad entre el proveedor de la nube y el cliente.
Google protege la infraestructura de la nube (hardware, red). El cliente protege lo que pone en la nube (datos, IAM, código de aplicación).
Por qué: El cliente es siempre responsable de sus datos y controles de acceso, independientemente del modelo de servicio (IaaS, PaaS, SaaS).
Adoptar la nube manteniendo la flexibilidad para usar otras plataformas o tecnologías.
Priorizar los servicios construidos sobre tecnologías de código abierto como Kubernetes (GKE), TensorFlow y Apache Beam (Dataflow).
Por qué: Los estándares de código abierto aumentan la portabilidad de las cargas de trabajo, evitando el bloqueo a APIs propietarias y permitiendo estrategias híbridas/multinube.
Reducir la huella de carbono de las operaciones de TI para cumplir los objetivos de sostenibilidad corporativa.
Alojar cargas de trabajo en Google Cloud, aprovechando su coincidencia del 100% con energía renovable. Utilizar la herramienta de Huella de Carbono para monitorear y seleccionar regiones de baja emisión de carbono.
Por qué: Google Cloud opera una de las nubes más limpias, permitiendo a las empresas heredar sus beneficios de sostenibilidad.
Integrar la infraestructura local con los servicios en la nube debido a regulaciones o soberanía de datos.
Usar Anthos para una plataforma consistente basada en Kubernetes en entornos locales y Google Cloud.
Por qué: Anthos proporciona un plano de gestión y control unificado para las aplicaciones, independientemente de dónde se ejecuten, simplificando las operaciones híbridas.
Analizar petabytes de datos estructurados con consultas SQL complejas sin gestionar infraestructura.
Usar BigQuery.
Por qué: BigQuery es un almacén de datos completamente gestionado y sin servidor, optimizado para consultas analíticas a gran escala.
Necesitar una base de datos relacional distribuida globalmente con fuerte consistencia y escalabilidad horizontal.
Usar Cloud Spanner.
Por qué: Spanner combina la semántica relacional (ACID, SQL) con la escala no relacional, ideal para aplicaciones globales de misión crítica como las financieras.
Almacenar y recuperar grandes volúmenes de datos simples de clave-valor (por ejemplo, IoT, perfiles de usuario) con latencia de un solo dígito de milisegundo.
Usar Cloud Bigtable.
Por qué: Bigtable es una base de datos NoSQL de columna ancha optimizada para cargas de trabajo operativas y analíticas de alto rendimiento y baja latencia.
Crear una aplicación móvil o web que requiera sincronización de datos en tiempo real y funcionalidad sin conexión.
Usar Firestore.
Por qué: Firestore es una base de datos de documentos NoSQL con sincronización en tiempo real y persistencia sin conexión integradas, diseñada para el desarrollo de aplicaciones modernas.
Migrar una base de datos tradicional MySQL, PostgreSQL o SQL Server local a un servicio de nube gestionado con cambios mínimos.
Usar Cloud SQL.
Por qué: Cloud SQL es un servicio de base de datos relacional completamente gestionado que ofrece compatibilidad con motores de base de datos estándar, automatizando copias de seguridad, parches y replicación.
Ingestar y procesar un flujo de datos de alto volumen y en tiempo real (por ejemplo, IoT, clickstreams) para análisis inmediatos.
Usar Pub/Sub para la ingesta, Dataflow para el procesamiento de flujos y BigQuery para el análisis.
Por qué: Este es el patrón sin servidor canónico para análisis escalables y en tiempo real en Google Cloud.
Almacenar datos con patrones de acceso variables (frecuentes, infrecuentes, archivo) de forma rentable.
Usar Cloud Storage con políticas de ciclo de vida para transicionar automáticamente los datos entre las clases Standard, Nearline, Coldline y Archive.
Por qué: Las políticas de ciclo de vida automatizan la clasificación de datos, haciendo coincidir el costo de almacenamiento con la frecuencia de acceso sin intervención manual.
Almacenar grandes cantidades de datos brutos, no estructurados y semiestructurados para su futuro procesamiento y análisis.
Usar Cloud Storage como repositorio central (data lake).
Por qué: Cloud Storage ofrece almacenamiento de objetos duradero y de bajo costo que se integra con todos los servicios de procesamiento de datos de GCP (BigQuery, Dataproc, Dataflow).
Ejecutar trabajos de procesamiento de datos a gran escala utilizando frameworks de código abierto como Apache Spark y Hadoop.
Usar Dataproc.
Por qué: Dataproc proporciona clústeres de Spark y Hadoop completamente gestionados, automatizando la creación y gestión de clústeres, lo que permite a los equipos centrarse en sus tareas.
Añadir capacidades de IA como reconocimiento de imágenes, análisis de sentimiento o transcripción de voz a una aplicación sin experiencia en ML.
Usar APIs preentrenadas: Vision AI, Natural Language AI, Speech-to-Text API, Translation API.
Por qué: Estas APIs proporcionan los modelos de vanguardia de Google para casos de uso comunes, requiriendo solo una simple llamada a la API REST.
Entrenar un modelo de ML personalizado utilizando sus propios datos etiquetados (por ejemplo, imágenes de productos, texto de clientes) pero sin experiencia en codificación de ML.
Usar AutoML dentro de Vertex AI.
Por qué: AutoML automatiza el proceso de construcción de modelos, permitiendo a los equipos crear modelos personalizados de alta calidad a través de una interfaz gráfica sencilla.
Un equipo de ciencia de datos necesita una plataforma unificada para construir, entrenar, desplegar y gestionar modelos de ML personalizados a lo largo de su ciclo de vida (MLOps).
Usar Vertex AI.
Por qué: Vertex AI es una plataforma MLOps integral que proporciona herramientas para cada paso del flujo de trabajo de aprendizaje automático en un único entorno.
Extraer automáticamente información estructurada (por ejemplo, números de factura, partidas) de documentos escaneados o PDFs.
Usar Document AI.
Por qué: Document AI está específicamente entrenado para entender el diseño de documentos y extraer datos estructurados, reduciendo la entrada manual de datos.
Construir un chatbot o agente virtual basado en voz para gestionar consultas de servicio al cliente.
Usar Dialogflow.
Por qué: Dialogflow es una plataforma de comprensión del lenguaje natural diseñada para construir interfaces conversacionales, gestionando intenciones, entidades y el flujo de la conversación.
Construir y ejecutar modelos predictivos directamente sobre datos almacenados en un almacén de datos utilizando solo SQL.
Usar BigQuery ML.
Por qué: BigQuery ML democratiza el aprendizaje automático al permitir a los analistas de datos crear modelos utilizando la sintaxis SQL familiar, evitando el movimiento de datos.
Crear aplicaciones que puedan generar contenido nuevo, como resúmenes de texto, código o imágenes.
Usar la plataforma Vertex AI para IA Generativa, accediendo a modelos fundacionales como Gemini.
Por qué: Vertex AI proporciona acceso gestionado a potentes modelos fundacionales a través de APIs, permitiendo el desarrollo rápido de funcionalidades de IA generativa.
Migrar una aplicación heredada que se ejecuta en una VM a la nube con cambios mínimos, requiriendo control total del sistema operativo.
Usar Compute Engine.
Por qué: Compute Engine (IaaS) proporciona máquinas virtuales, ofreciendo máximo control y una ruta de migración directa para servidores locales.
Desplegar una aplicación web sin estado y contenerizada que debe escalar automáticamente según el tráfico, incluyendo escalar a cero.
Usar Cloud Run.
Por qué: Cloud Run es una plataforma sin servidor completamente gestionada para contenedores que abstrae toda la infraestructura y factura solo por el tiempo de procesamiento de solicitudes activas.
Ejecutar una arquitectura compleja de microservicios utilizando contenedores, requiriendo orquestación y control precisos.
Usar Google Kubernetes Engine (GKE).
Por qué: GKE proporciona un entorno Kubernetes gestionado y listo para producción, ofreciendo capacidades completas de orquestación mientras automatiza la gestión del clúster.
Ejecutar una pequeña porción de código en respuesta a un evento, como una carga de archivo a Cloud Storage o un mensaje de Pub/Sub.
Usar Cloud Functions.
Por qué: Cloud Functions (FaaS) es un servicio de cómputo sin servidor y basado en eventos, ideal para funciones de corta duración y propósito único sin gestionar servidores.
Desplegar una aplicación web y centrarse solo en escribir código, dejando que la plataforma gestione los servidores, el escalado y los parches.
Usar App Engine.
Por qué: App Engine (PaaS) es una plataforma completamente gestionada que abstrae toda la infraestructura, ideal para desarrolladores que desean la forma más rápida de desplegar una aplicación.
Ejecutar trabajos de procesamiento por lotes o de computación de alto rendimiento grandes y tolerantes a fallos al menor costo posible.
Usar Spot VMs en Compute Engine.
Por qué: Las Spot VMs ofrecen grandes descuentos (hasta el 91%) para cargas de trabajo que pueden ser interrumpidas, haciéndolas altamente rentables para trabajos por lotes no críticos.
Establecer una conexión privada de alto ancho de banda y baja latencia entre un centro de datos local y Google Cloud.
Usar Cloud Interconnect.
Por qué: Cloud Interconnect proporciona una conexión física dedicada, ofreciendo un rendimiento más fiable y consistente que una VPN sobre la internet pública.
Entregar contenido web o de video a una base de usuarios global con baja latencia.
Usar Cloud CDN.
Por qué: Cloud CDN almacena en caché el contenido en las ubicaciones de borde distribuidas globalmente de Google, sirviendo a los usuarios desde un punto de presencia cercano a ellos.
Almacenar y gestionar imágenes de contenedores, paquetes de sistema operativo y paquetes de lenguaje de forma segura con escaneo de vulnerabilidades.
Usar Artifact Registry.
Por qué: Artifact Registry es un repositorio universal gestionado que se integra con CI/CD y GKE para proporcionar una gestión de paquetes segura y centralizada.
Migrar cargas de trabajo VMware existentes a Google Cloud sin re-arquitectar aplicaciones ni cambiar herramientas operativas.
Usar Google Cloud VMware Engine.
Por qué: Proporciona un centro de datos definido por software (SDDC) de VMware dedicado y completamente gestionado ejecutándose en Google Cloud, permitiendo un "lift and shift" sin problemas para VMware.
Gestionar el acceso de los usuarios a los recursos de la nube basándose en la función laboral, siguiendo el principio del mínimo privilegio.
Asignar roles de IAM predefinidos o personalizados a Google Groups, no a usuarios individuales.
Por qué: Gestionar permisos a través de grupos simplifica la administración y asegura que los nuevos usuarios hereden automáticamente los permisos correctos y mínimos.
Obtener una vista centralizada de vulnerabilidades de seguridad, amenazas y configuraciones erróneas en toda la organización de GCP.
Usar Security Command Center.
Por qué: Actúa como un único panel de control para la seguridad, agregando hallazgos de múltiples fuentes y proporcionando información procesable.
Proteger aplicaciones web públicas de ataques DDoS y exploits web comunes (por ejemplo, inyección SQL).
Usar Cloud Armor.
Por qué: Cloud Armor es el Web Application Firewall (WAF) y servicio de mitigación de DDoS de Google que se integra con el balanceador de carga global.
Cifrar datos en servicios en la nube manteniendo el control total sobre las claves de cifrado.
Usar Cloud Key Management Service (Cloud KMS) para crear Claves de Cifrado Gestionadas por el Cliente (CMEK).
Por qué: CMEK permite controlar el ciclo de vida de la clave (rotación, destrucción) por razones de cumplimiento o política, mientras Google gestiona la infraestructura de la clave.
Descubrir, clasificar y redactar datos sensibles (por ejemplo, números de tarjetas de crédito, PII) almacenados en Cloud Storage o BigQuery.
Usar Cloud Data Loss Prevention (DLP).
Por qué: Cloud DLP proporciona herramientas para escanear automáticamente y tomar medidas sobre datos sensibles para prevenir la exposición accidental.
Proporcionar acceso seguro a aplicaciones web internas para empleados sin usar una VPN tradicional.
Usar Identity-Aware Proxy (IAP).
Por qué: IAP aplica políticas de acceso basadas en la identidad del usuario y el contexto, creando un modelo de seguridad de confianza cero para las aplicaciones.
Prevenir la exfiltración de datos creando un perímetro de seguridad alrededor de proyectos y servicios sensibles de Google Cloud.
Usar VPC Service Controls.
Por qué: VPC Service Controls aísla servicios y datos, asegurando que los datos no puedan ser movidos fuera del perímetro definido, incluso por un usuario con permisos IAM válidos.
Almacenar y gestionar de forma segura los secretos de la aplicación como claves API, contraseñas y certificados.
Usar Secret Manager.
Por qué: Secret Manager proporciona un almacén centralizado, versionado y auditado para secretos con permisos IAM granulares, lo que es más seguro que almacenarlos en código o archivos de configuración.
Obtener una observabilidad completa sobre la salud de aplicaciones e infraestructura a través de métricas, registros y rastreos.
Usar la suite de operaciones de Google Cloud: Cloud Monitoring (métricas/alertas), Cloud Logging (registros) y Cloud Trace (rastreo).
Por qué: Esta suite integrada proporciona una imagen completa del rendimiento del sistema para un monitoreo proactivo y una resolución de problemas más rápida.
Gestionar proactivamente el gasto en la nube y recibir notificaciones antes de que los costos superen las cantidades planificadas.
Configurar alertas de presupuesto de Cloud Billing.
Por qué: Los presupuestos proporcionan notificaciones programáticas cuando el gasto alcanza ciertos umbrales, evitando excesos de costos.
Rastrear y asignar costos de la nube a equipos, proyectos o centros de costo específicos para el cobro interno.
Aplicar Labels a todos los recursos y usar los informes de Cloud Billing para filtrar y agrupar costos por etiqueta.
Por qué: Las Labels son el mecanismo principal para organizar recursos y atribuir costos para la gobernanza financiera.
Reducir costos para cargas de trabajo predecibles y de estado estable que se ejecutan continuamente (por ejemplo, un servidor de base de datos).
Adquirir Committed Use Discounts (CUDs) de 1 o 3 años para Compute Engine u otros servicios.
Por qué: Los CUDs ofrecen ahorros significativos sobre los precios bajo demanda a cambio de un compromiso con un nivel consistente de uso de recursos.
Organizar los recursos de la nube para reflejar la estructura de la empresa (por ejemplo, departamentos, entornos) y aplicar políticas jerárquicamente.
Usar la jerarquía de recursos Organización > Carpetas > Proyectos.
Por qué: Esta estructura permite el control centralizado, ya que las políticas de IAM y de Organización se heredan a lo largo de la jerarquía, simplificando la gobernanza a escala.
Definir, desplegar y gestionar la infraestructura de la nube de forma repetible, versionada y automatizada.
Usar una herramienta de Infraestructura como Código (IaC) como Terraform o Cloud Deployment Manager.
Por qué: IaC reduce errores manuales, aumenta la velocidad de despliegue y proporciona un registro auditable de los cambios de infraestructura.
Equilibrar la necesidad de fiabilidad del servicio con la necesidad de innovar y lanzar nuevas características.
Implementar principios de Site Reliability Engineering (SRE): definir Service Level Objectives (SLOs) y usar el Error Budget resultante.
Por qué: El presupuesto de errores proporciona un marco basado en datos para decidir cuándo priorizar el trabajo de fiabilidad sobre el desarrollo de características, protegiendo la experiencia del usuario.
