Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen PCSE. Lee de arriba a abajo o salta a una sección.
Las cargas de trabajo de GKE necesitan acceder a las APIs de GCP sin gestionar claves de cuentas de servicio.
Habilitar y configurar Workload Identity en el clúster de GKE. Mapear las cuentas de servicio de Kubernetes (KSA) a las cuentas de servicio de Google (GSA).
Por qué: Elimina el riesgo de filtración de claves de cuentas de servicio mediante el uso de credenciales de corta duración y rotación automática derivadas de tokens de KSA.
Proporcionar acceso a aplicaciones web internas desde cualquier red basado en la identidad del usuario y la postura del dispositivo, sin una VPN.
Utilizar Identity-Aware Proxy (IAP) con Access Context Manager. Definir niveles de acceso basados en IP, estado del dispositivo (mediante Endpoint Verification) e identidad del usuario.
Por qué: Traslada el control de acceso del perímetro de la red a usuarios y dispositivos individuales, aplicando principios de confianza cero.
Una pipeline de CI/CD (por ejemplo, GitHub Actions, GitLab) necesita acceder a recursos de GCP sin credenciales de larga duración.
Utilizar Workload Identity Federation. Crear un pool de proveedores para el IdP externo (por ejemplo, GitHub OIDC) y configurar condiciones de atributos para restringir el acceso a repositorios o ramas específicos.
Por qué: Autenticación sin claves para cargas de trabajo externas. El sistema externo proporciona su propio token, que se intercambia por un token de GCP de corta duración.
Aplicar políticas de seguridad de IAM en toda la organización, como evitar la creación de claves de cuentas de servicio o restringir las concesiones de IAM a dominios específicos.
Utilizar restricciones de Organization Policy como `iam.disableServiceAccountKeyCreation` y `iam.allowedPolicyMemberDomains`.
Por qué: Las Organization Policies se heredan y no pueden ser anuladas por los propietarios de proyectos, asegurando una postura de seguridad consistente.
Un usuario necesita acceso administrativo temporal, auditable y sujeto a aprobación a un entorno de producción para un incidente.
Utilizar Privileged Access Manager (PAM) para acceso just-in-time (JIT). El usuario solicita un rol específico por un tiempo limitado, lo cual pasa por un flujo de trabajo de aprobación.
Por qué: Elimina los privilegios permanentes, un riesgo de seguridad importante. El acceso está limitado en el tiempo, justificado y completamente auditado.
Varios equipos comparten un clúster de GKE. Cada equipo debe gestionar recursos únicamente dentro de su propio namespace.
Conceder el rol de IAM `roles/container.clusterViewer` a nivel de proyecto. Utilizar `Role` y `RoleBinding` de Kubernetes RBAC dentro de cada namespace para otorgar permisos específicos (por ejemplo, editar, ver).
Por qué: Separa la autenticación a nivel de clúster (IAM) de la autorización a nivel de namespace (Kubernetes RBAC), proporcionando un control multi-inquilino de grano fino.
Las APIs deben ser llamadas usando credenciales de corta duración en lugar de claves estáticas.
Utilizar la suplantación de cuenta de servicio. Conceder a un principal el rol `roles/iam.serviceAccountTokenCreator` en una cuenta de servicio objetivo para generar tokens de acceso OAuth 2.0 de corta duración.
Por qué: Evita distribuir y gestionar claves de larga duración. Los tokens expiran automáticamente (por defecto 1 hora), reduciendo el riesgo si son comprometidos.
Un contratista necesita acceso a recursos específicos, pero el acceso debe expirar automáticamente después de 30 días.
Conceder el rol de IAM necesario con una condición de IAM basada en el tiempo, por ejemplo, `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.
Por qué: Automatiza la revocación del acceso, evitando la limpieza manual y asegurando que el acceso no se prolongue inadvertidamente.
Permitir únicamente que las imágenes de contenedores firmadas por la pipeline de CI/CD sean desplegadas en clústeres de GKE de producción.
Implementar Binary Authorization. Crear una atestación en la pipeline de CI para firmar imágenes. Configurar una política de Binary Authorization en el clúster de GKE para requerir esta atestación.
Por qué: Aplica una cadena de suministro de software segura al prevenir que imágenes no verificadas o manipuladas se ejecuten en producción.
Conceder permisos a recursos basados en sus etiquetas asignadas, no en nombres de recursos individuales.
Utilizar IAM Conditions con expresiones de etiquetas de recursos, como `resource.matchTag("123456789/env", "prod")`.
Por qué: Habilita un control de acceso basado en atributos (ABAC) escalable. Los permisos son dinámicos y se aplican automáticamente a medida que se etiquetan los recursos.
Permitir que un proyecto de servicio despliegue VMs en un proyecto host de Shared VPC sin conceder derechos de administrador de red.
En el proyecto host, conceder a la cuenta de servicio del proyecto de servicio el rol `roles/compute.networkUser` en la(s) subred(es) específica(s) que necesita usar.
Por qué: Sigue el principio de mínimo privilegio. Los proyectos de servicio pueden usar la red pero no modificarla (por ejemplo, cambiar reglas de firewall), la cual permanece gestionada centralmente.
Un usuario con `storage.admin` no puede crear un bucket. Necesita identificar la causa raíz.
Verificar si existe una política de Denegación de IAM a un nivel superior (carpeta, organización) que deniegue el permiso `storage.buckets.create`.
Por qué: Las políticas de Denegación de IAM siempre anulan cualquier política de permiso. Esta es una herramienta poderosa para aplicar límites de seguridad no negociables.
Habilitar SSO para usuarios de Active Directory en las instalaciones para acceder a la consola de Google Cloud.
Utilizar Google Cloud Directory Sync (GCDS) para sincronizar identidades con Cloud Identity. Configurar la federación (SAML) entre Cloud Identity y AD FS (u otro IdP).
Por qué: Mantiene AD como la fuente de verdad para las identidades mientras proporciona una experiencia SSO federada y sin interrupciones para los usuarios.
Cifrar datos en GCP, pero las claves de cifrado nunca deben salir del HSM local.
Utilizar Cloud External Key Manager (EKM). Esto permite que los servicios de GCP utilicen claves de un sistema de gestión de claves externo para operaciones CMEK.
Por qué: Proporciona el máximo control y cumple con estrictos requisitos de soberanía de datos al mantener el material de la clave fuera de Google Cloud.
Encontrar y clasificar automáticamente datos sensibles (PII, PHI) en todos los activos de Cloud Storage y BigQuery.
Configurar escaneos de descubrimiento de Cloud Data Loss Prevention (DLP). Los resultados pueden poblar automáticamente Data Catalog con etiquetas.
Por qué: Proporciona un inventario y clasificación de datos automatizados, que es la base para las políticas de gobernanza y protección de datos.
Un equipo de análisis necesita consultar datos que contienen PII, pero no debe ver los valores sensibles brutos. Se debe mantener la integridad referencial.
Utilizar una plantilla de desidentificación de Cloud DLP con cifrado determinista o hashing criptográfico.
Por qué: Transforma datos sensibles en seudónimos. Los métodos deterministas aseguran que la misma entrada siempre produce la misma salida, permitiendo uniones y agregaciones.
Un marco de cumplimiento (por ejemplo, para servicios financieros) requiere que las claves de cifrado estén protegidas por un HSM certificado FIPS 140-2 Nivel 3.
Utilizar Cloud KMS con un nivel de protección HSM. Esto crea claves dentro de un Módulo de Seguridad de Hardware gestionado.
Por qué: Cumple con los requisitos de cumplimiento de alto nivel al utilizar hardware dedicado y certificado para la gestión de claves sin gestionar los HSMs físicos.
Asegurarse de que los nuevos recursos (por ejemplo, buckets de GCS, conjuntos de datos de BigQuery) estén siempre cifrados con claves gestionadas por el cliente (CMEK), no con claves gestionadas por Google.
Aplicar la Organization Policy `constraints/gcp.restrictNonCmekServices`.
Por qué: Proporciona un control preventivo que obliga a los servicios especificados a usar CMEK, asegurando una postura de protección de datos consistente.
Los datos deben almacenarse en un estado inmutable (WORM - Write-Once-Read-Many) por un período de retención específico por razones legales o de cumplimiento.
Configurar un bucket de Cloud Storage con una política de retención y habilitar Bucket Lock.
Por qué: Bucket Lock hace que la política de retención sea irreversible, asegurando que los objetos no puedan ser eliminados o modificados, incluso por administradores, hasta que finalice el período de retención.
Las credenciales de la base de datos de la aplicación almacenadas como secretos deben rotarse automáticamente sin causar tiempo de inactividad de la aplicación.
Utilizar Secret Manager con rotación automática configurada. La rotación activa una Cloud Function que actualiza la contraseña en la base de datos y crea una nueva versión del secreto.
Por qué: La rotación gestionada y automatizada reduce el riesgo de compromiso de credenciales. Las aplicaciones referencian la versión `latest` para recoger sin problemas el nuevo secreto.
Una carga de trabajo procesa datos altamente sensibles, y los datos deben permanecer cifrados incluso mientras están en memoria (en uso).
Utilizar Confidential Computing desplegando la carga de trabajo en Confidential VMs.
Por qué: Proporciona cifrado de memoria basado en hardware, protegiendo los datos del hypervisor y otras VMs. Utilizar atestación para verificar la integridad del entorno.
Restringir el acceso a columnas sensibles específicas en una tabla de BigQuery sin crear vistas separadas.
Utilizar la seguridad a nivel de columna de BigQuery. Aplicar etiquetas de política de Data Catalog a columnas sensibles y conceder el rol "Fine-Grained Reader" en esas etiquetas de política a usuarios/grupos autorizados.
Por qué: Aplica un acceso de grano fino directamente en la tabla, lo cual es más escalable y manejable que mantener múltiples vistas autorizadas.
Proteger datos sensibles en un bucket de GCS incluso si los permisos de IAM están mal configurados y otorgan acceso público.
Cifrar objetos con una Customer-Managed Encryption Key (CMEK) y controlar estrictamente el acceso a esa clave en Cloud KMS.
Por qué: Crea un sistema de doble clave. Un atacante necesita permisos tanto para el objeto de GCS COMO para la clave de KMS para descifrar los datos, proporcionando defensa en profundidad.
Prevenir la eliminación accidental o maliciosa inmediata de claves críticas de Cloud KMS.
Al crear la clave, configurar la propiedad `destroy_scheduled_duration` a un valor como 30 días.
Por qué: Impone un período de espera antes de que una clave sea destruida permanentemente, proporcionando una ventana para recuperarse de una eliminación accidental.
Un requisito legal para probar que un archivo en Cloud Storage no ha sido alterado desde que fue subido.
Al descargar, recalcular el hash MD5 o CRC32C del archivo y compararlo con el hash almacenado en los metadatos del objeto de Cloud Storage.
Por qué: Proporciona prueba criptográfica de la integridad del objeto. Cloud Storage calcula y almacena automáticamente estos hashes al subir.
Prevenir que los datos sean copiados de un proyecto sensible a un bucket público, incluso por un usuario con el rol `owner`.
Colocar el proyecto sensible dentro de un perímetro de VPC Service Controls. Esto restringe el movimiento de datos a otros proyectos fuera del perímetro.
Por qué: VPC Service Controls actúan como un firewall centrado en datos que anula los permisos de IAM para la salida de datos, proporcionando una defensa potente contra la exfiltración.
Proteger una aplicación web de cara al público contra ataques DDoS volumétricos y exploits web comunes (por ejemplo, SQLi, XSS).
Colocar la aplicación detrás de un Global External HTTP(S) Load Balancer y adjuntar una política de seguridad de Cloud Armor con reglas WAF preconfiguradas.
Por qué: El balanceador de carga absorbe los ataques DDoS en el borde de Google. Cloud Armor proporciona un Firewall de Aplicaciones Web gestionado para bloquear las 10 principales amenazas de OWASP.
Se utiliza un Dedicated Interconnect para la conectividad on-prem a GCP, pero el tráfico debe ser cifrado por cumplimiento.
Configurar un túnel VPN de alta disponibilidad (HA VPN) sobre los adjuntos VLAN de Cloud Interconnect.
Por qué: Combina el alto ancho de banda y la baja latencia de una conexión dedicada con el cifrado IPsec de una VPN.
Los sistemas locales necesitan llamar a las APIs de Google (por ejemplo, BigQuery, GCS) sin atravesar la internet pública.
Configurar Private Google Access para hosts locales. Utilizar Cloud Interconnect o VPN, y configurar DNS para resolver `*.googleapis.com` al rango VIP restringido.
Por qué: Mantiene el tráfico a los servicios de Google en la red privada de Google, mejorando la seguridad y potencialmente reduciendo los costos de salida.
Aplicar TLS mutuo (mTLS) para toda la comunicación de servicio a servicio dentro de un clúster de GKE.
Desplegar Anthos Service Mesh (o Istio) y habilitar la autenticación de pares mTLS estricta para los namespaces relevantes.
Por qué: Cifra y autentica automáticamente todo el tráfico dentro de la malla, logrando un modelo de red de confianza cero sin cambios en el código de la aplicación.
Una VPC de consumidor necesita acceder de forma privada a un servicio (por ejemplo, una API interna) que se ejecuta en una VPC de productor sin usar peering o IPs públicas.
El productor publica el servicio usando Private Service Connect. El consumidor crea un endpoint en su VPC que enruta de forma privada al servicio.
Por qué: Desacopla la conectividad de red del acceso al servicio. Es la forma moderna y escalable de proporcionar acceso privado a servicios a través de VPCs y organizaciones.
Desplegar un clúster de GKE donde los nodos no tienen IPs públicas y el plano de control no está expuesto a internet.
Crear un clúster de GKE privado. Habilitar Private Google Access en la subred para el acceso de los nodos a las APIs de GCP. Configurar redes maestras autorizadas para restringir el acceso al plano de control a IPs específicas (por ejemplo, la red corporativa).
Por qué: Reduce significativamente la superficie de ataque del clúster al eliminar los puntos finales públicos tanto para los nodos como para el plano de control.
En un clúster de GKE, los pods de un servicio `frontend` solo deben poder comunicarse con los pods de un servicio `backend`, y con nada más.
Crear recursos de Kubernetes NetworkPolicy. Aplicar una política de ingreso a los pods `backend` que permita el tráfico solo desde los pods `frontend`, basada en etiquetas de pod.
Por qué: Proporciona firewall a nivel de pod dentro del clúster, habilitando un modelo de red de mínimo privilegio para microservicios.
Las VMs sin IPs externas necesitan acceder a internet. Todo el tráfico de salida debe originarse de un pequeño conjunto de direcciones IP predecibles para ser incluidas en listas de permitidos por terceros.
Configurar Cloud NAT para la subred que contiene las VMs.
Por qué: Proporciona traducción de direcciones de red gestionada para el tráfico saliente a internet desde instancias privadas, con registro centralizado y asignación de IP.
Aplicar una regla de firewall base en toda la organización, como denegar todo el SSH desde internet, que no pueda ser anulada por los equipos de proyecto.
Crear una política de firewall jerárquica a nivel de organización o carpeta con una regla de denegación para el puerto 22 desde `0.0.0.0/0` con alta prioridad.
Por qué: Las políticas jerárquicas se evalúan antes que las reglas a nivel de VPC, permitiendo a los equipos de seguridad centrales aplicar guardas de seguridad de red no negociables.
Resolver nombres de host internos dentro de una VPC sin filtrar consultas a servidores DNS públicos.
Configurar una zona gestionada privada de Cloud DNS para sus dominios internos y asociarla con su VPC.
Por qué: Proporciona DNS autoritativo para recursos internos dentro de la red VPC, mejorando la seguridad y la capacidad de gestión.
Cuando Security Command Center detecta una amenaza (por ejemplo, criptominado), aislar automáticamente la VM afectada.
Configurar SCC para publicar hallazgos en un tema de Pub/Sub. Activar una Cloud Function que reciba el hallazgo y modifique las etiquetas de red de la VM para aplicar una regla de firewall de "cuarentena" preconfigurada.
Por qué: Permite una respuesta a incidentes automatizada y casi en tiempo real, reduciendo el tiempo que un atacante tiene en el entorno.
Recopilar registros de auditoría de todos los proyectos de la organización y almacenarlos durante 7 años en un formato inmutable para cumplimiento.
Crear un sumidero de registros a nivel de organización a un bucket de Cloud Storage. Configurar el bucket de destino con una política de retención de 7 años y Bucket Lock.
Por qué: Un sumidero agregado centraliza los registros. Bucket Lock asegura que los registros son a prueba de manipulaciones y cumplen con estrictos requisitos de retención de cumplimiento.
Se sospecha que una VM está comprometida. Debe ser desconectada inmediatamente, pero la evidencia debe ser preservada para análisis forense.
Detener la instancia de VM (para detener la actividad) y crear inmediatamente una instantánea de su disco persistente. Luego, aislarla con reglas de firewall.
Por qué: Detener la instancia contiene la amenaza, mientras que la instantánea crea una copia del disco en un momento dado para análisis sin riesgo de manipulación de evidencia.
Detectar cuándo una cuenta de servicio se utiliza desde una ubicación geográfica inusual o realiza actividades anormales.
Habilitar el nivel Premium de Security Command Center, que incluye Event Threat Detection. Este servicio analiza los registros en busca de comportamiento anómalo.
Por qué: Utiliza la inteligencia de amenazas y el aprendizaje automático de Google para detectar amenazas difíciles de encontrar con alertas basadas en reglas, como credenciales comprometidas.
Un equipo de seguridad central necesita analizar y correlacionar señales de seguridad de GCP, AWS y sistemas locales en una única plataforma.
Ingresar todos los registros y telemetría relevantes en Chronicle Security Operations (SIEM).
Por qué: Chronicle es un SIEM nativo de la nube diseñado para análisis a escala de petabytes, con parsers y reglas de detección incorporadas para entornos multi-nube e híbridos.
Detectar cuándo los recursos de GCP gestionados por Terraform son modificados manualmente a través de la consola, creando una desviación de configuración.
Configurar un feed de Cloud Asset Inventory para enviar notificaciones de cambios de activos en tiempo real a un tema de Pub/Sub. Un servicio puede entonces comparar estos cambios con el estado de Terraform.
Por qué: Proporciona visibilidad en tiempo real de todos los cambios de recursos, permitiendo la detección automatizada de modificaciones fuera de banda.
Una organización tiene miles de hallazgos de SCC y necesita centrarse en aquellos que representan el riesgo más inmediato para los activos críticos.
Utilizar la Simulación de Ruta de Ataque en SCC Premium. Definir activos de alto valor y la simulación identificará y priorizará los hallazgos que forman un camino directo a esos activos.
Por qué: Pasa de la priorización basada en vulnerabilidades a la basada en riesgos. Destaca combinaciones tóxicas de hallazgos que un atacante podría explotar.
Detectar actividad maliciosa dentro de un contenedor GKE en ejecución, como una shell inesperada o una conexión de shell inversa.
Habilitar Container Threat Detection en Security Command Center.
Por qué: Proporciona visibilidad en tiempo de ejecución del comportamiento del contenedor, detectando amenazas que el escaneo de vulnerabilidades (que ocurre antes del tiempo de ejecución) no puede ver.
Una investigación forense de red requiere capturar y analizar el contenido completo de los paquetes de tráfico entre dos VMs específicas.
Configurar Packet Mirroring para clonar el tráfico de las VMs de origen y enviarlo a una VM recolectora que ejecute herramientas de inspección como Wireshark o Zeek.
Por qué: Proporciona captura completa de paquetes para un análisis profundo, a diferencia de los VPC Flow Logs que solo contienen metadatos.
Prevenir que se desplieguen configuraciones Terraform inseguras (por ejemplo, buckets de GCS públicos).
Integrar una herramienta de prueba de seguridad de análisis estático (SAST) como `tfsec` o Checkov en la pipeline de CI/CD. Fallar la construcción si se encuentran violaciones de seguridad.
Por qué: Implementa la seguridad "shift-left" al detectar configuraciones erróneas antes de que se desplieguen, reduciendo la necesidad de remediación reactiva.
Una empresa debe asegurarse de que, por razones de cumplimiento, ciertos datos y procesamiento solo puedan ocurrir en regiones de la UE.
Aplicar la restricción de Organization Policy `gcp.resourceLocations`, permitiendo solo las regiones especificadas de la UE.
Por qué: Este es un control técnico y preventivo que impone la residencia de datos a nivel de creación de recursos, lo cual es requerido para regulaciones como GDPR.
Una institución financiera requiere que los ingenieros de soporte de Google obtengan aprobación explícita y limitada en el tiempo antes de acceder a sus datos para un caso de soporte.
Habilitar Access Approval y configurar aprobadores. Todas las solicitudes de acceso de Google generarán una solicitud que debe ser aprobada.
Por qué: Proporciona control por parte del cliente sobre el acceso administrativo de Google, un requisito clave para industrias altamente reguladas.
Un auditor necesita verificar exactamente qué acciones tomó el personal de Google cuando se les concedió acceso a su entorno.
Habilitar y revisar los registros de Access Transparency. Estos registros proporcionan una alimentación casi en tiempo real de las acciones realizadas por el personal de Google.
Por qué: Proporciona una pista de auditoría inmutable de las acciones del administrador de Google, brindando visibilidad y apoyando los requisitos de cumplimiento.
Monitorizar continuamente el entorno de GCP en busca de configuraciones que violen un estándar de cumplimiento específico, como PCI DSS o HIPAA.
Utilizar Security Health Analytics en Security Command Center, con el estándar de cumplimiento relevante habilitado en el panel.
Por qué: Automatiza las verificaciones de cumplimiento contra los puntos de referencia de la industria, proporcionando visibilidad continua y generando hallazgos para cualquier configuración errónea detectada.
Un auditor solicita el informe SOC 2 Tipo II de Google y la Atestación de Cumplimiento de PCI DSS.
Utilizar el Compliance Reports Manager en la consola de Google Cloud para acceder y descargar informes de auditoría y certificaciones.
Por qué: Proporciona un portal de autoservicio para que los clientes obtengan la documentación de cumplimiento necesaria para respaldar sus propios procesos de auditoría.
Una agencia gubernamental de EE. UU. necesita desplegar una carga de trabajo que cumpla con los requisitos de cumplimiento de FedRAMP High.
Desplegar la aplicación dentro de un entorno de Assured Workloads configurado para el régimen de cumplimiento de FedRAMP High.
Por qué: Assured Workloads aplica automáticamente los controles y salvaguardas necesarios (por ejemplo, ubicación de datos, restricciones de acceso de personal) para ayudar a cumplir con estándares de cumplimiento específicos.