Google PDE: Gobernanza de Datos, Seguridad, Confiabilidad y Operaciones de Costos — Guía de estudio

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Forma parte de la Google Professional Data Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Esta sección resume los patrones de diseño y las prácticas operativas para la gobernanza de datos, la seguridad, la fiabilidad y las operaciones de costos en Google Cloud. Se centra en BigQuery, Cloud Storage, Dataflow, Dataplex y servicios de soporte. Se pone énfasis en el privilegio mínimo, la gestión de claves de cifrado, los metadatos y la clasificación, el acceso basado en políticas, la evidencia de cumplimiento, la observabilidad con SLO procesables y el control de costos. Se incluyen compensaciones, modos de fallo y configuraciones prácticas para habilitar plataformas de datos seguras, auditables y eficientes.

Identidad, Acceso y Gobernanza

IAM, cuentas de servicio, suplantación de identidad, identidad de carga de trabajo, privilegio mínimo
- Límites de identidad
  - Usuarios y grupos a través de Cloud Identity o Google Workspace
  - Cuentas de servicio para cargas de trabajo; asignar roles con alcance limitado al recurso práctico más bajo (p. ej., dataset en lugar de proyecto)
- Privilegio mínimo
  - Preferir roles predefinidos sobre roles primitivos; para BigQuery, usar roles como bigquery.dataViewer en datasets en lugar de viewer a nivel de proyecto
  - Otorgar permisos a grupos; gestionar la membresía en un IdP, no por usuario en IAM
  - Separación de funciones: roles separados para la gestión de claves, el acceso a datos y la administración
- Suplantación de identidad y Federación de identidades para cargas de trabajo
  - Usar la suplantación de identidad de cuentas de servicio (roles/iam.serviceAccountTokenCreator) para que la CI/CD o la automatización nunca almacenen claves de larga duración
  - Usar la Federación de identidades para cargas de trabajo con OIDC/SAML para permitir que identidades externas obtengan tokens de corta duración sin archivos de claves de cuenta de servicio
- Modos de fallo y mitigaciones
  - El exceso de roles a nivel de proyecto conduce a movimientos laterales; auditar con Cloud Asset Inventory
  - Pérdida de claves privadas de cuentas de servicio: no permitir la creación de claves; usar restricciones de políticas de organización para bloquear la descarga de claves; rotar si se encuentran
Gobernanza de Dataplex, Data Catalog, metadatos de negocio, linaje
- Dataplex proporciona lagos, zonas y activos para unificar la gobernanza sobre BigQuery y Cloud Storage con políticas centralizadas
- Data Catalog contiene un glosario de negocio, plantillas de etiquetas y metadatos técnicos; adjuntar metadatos de negocio (propietario, clase de PII, RTO/RPO) a través de etiquetas
- El linaje captura las relaciones de origen y destino; usar las integraciones de linaje de Dataplex con Dataflow, Dataproc y BigQuery para rastrear el impacto y el alcance del cumplimiento
- Compensaciones
  - La gobernanza centralizada añade una sobrecarga inicial pero reduce el riesgo a largo plazo y acelera las auditorías
Etiquetas de política, clasificación, acceso a nivel de fila, enmascaramiento de columnas
- Clasificación
  - Definir una taxonomía (p. ej., público, interno, confidencial, restringido) en las etiquetas de política de Data Catalog
  - Adjuntar etiquetas de política a las columnas de BigQuery; vincular IAM a las etiquetas para que el acceso siga la clasificación a través de las tablas
- Enmascaramiento de columnas
  - Usar políticas de enmascaramiento de datos de BigQuery para aplicar hash o anular columnas sensibles para lectores sin privilegios
  - Ejemplo:

undefined

Acceso a nivel de fila
- Usar políticas de acceso a filas para filtrar registros por atributos como tenant_id o región
- Ejemplo:

undefined

Modos de fallo
- El IAM de etiquetas de política no otorgado a las cuentas de servicio utilizadas por las canalizaciones causa fallos en las consultas; incluir el rol de visualizador/acceso a etiquetas de política para los agentes de servicio según sea necesario
- Las políticas de fila pueden degradar el rendimiento si hay muchos predicados por usuario altamente selectivos; preferir un dataset por tenant de grano grueso donde el aislamiento es estricto
Descubrimiento y desidentificación de datos sensibles
- Usar Sensitive Data Protection para escanear continuamente Cloud Storage y BigQuery; crear configuraciones de descubrimiento por lago/zona con plantillas
- Usar transformaciones de desidentificación: tokenización, cifrado determinista para permitir uniones (joins) o enmascaramiento
- Almacenar las claves de transformación en Cloud KMS; mantener las claves de reidentificación separadas con control dual
- Compensaciones
  - El cifrado determinista permite las uniones (joins) pero puede filtrar información de frecuencia; añadir cifrado que preserva el formato o agrupación en buckets según sea necesario
  - El muestreo reduce el costo de los escaneos de descubrimiento pero puede omitir PII de baja prevalencia

Operaciones de seguridad y cumplimiento

Cifrado, Cloud KMS, CMEK y manejo de secretos
- El cifrado en reposo y en tránsito es el predeterminado; habilita CMEK donde se requiera control normativo de las claves (BigQuery, GCS, Pub/Sub, Dataflow)
- Gestión de claves
  - Ubica las claves en la misma región que los datos; otorga al agente de servicio (p. ej., BigQuery Service Agent) el rol roles/cloudkms.cryptoKeyEncrypterDecrypter
  - Rota las claves regularmente; monitorea las claves deshabilitadas o programadas para su destrucción
- Modos de fallo
  - Deshabilitar una clave CMEK o revocar el agente de servicio interrumpe las cargas, consultas y exportaciones; alerta sobre los cambios de estado de las claves
  - No se permite el uso de claves entre regiones; alinea las ubicaciones para evitar errores en la creación de trabajos
- Secretos
  - Usa Secret Manager para credenciales de bases de datos y tokens de API; otorga acceso a través de IAM y audita con los registros de Secret Manager
  - Nunca incrustes secretos en el código, contenedores o notebooks; monta los secretos a través del acceso en tiempo de ejecución; prefiere la autenticación de base de datos de IAM donde sea compatible
Registros de auditoría, revisión de acceso, evidencia de cumplimiento y retención
- Habilita los registros de acceso a datos (Data Access logs) a nivel de organización para BigQuery, GCS, Pub/Sub; expórtalos a un proyecto de registro dedicado, de solo escritura y con CMEK
- Crea sinks de registros agregados hacia BigQuery (analítica) y Cloud Storage (archivo inmutable a largo plazo con bloqueo de retención de bucket)
- Usa Cloud Asset Inventory y Policy Analyzer para la revisión periódica de accesos y la detección de desviaciones (drift)
- Retención
  - Establece la retención de registros según las necesidades de cumplimiento; usa el control de versiones de objetos y las políticas de retención en GCS
  - En BigQuery, establece la expiración predeterminada de las tablas y apóyate en los snapshots de tabla/time travel para reversiones a corto plazo; archiva los conjuntos de datos críticos en proyectos separados
- Evidencia
  - Mantén un mapeo de controles con etiquetas de Dataplex (p. ej., “SOX-C2: Evidencia en el proyecto X, sink Y”), automatiza las exportaciones y ejecuta consultas programadas para producir atestaciones

Fiabilidad, Observabilidad, Calidad y Gestión de Costos

Dimensiones de la calidad de los datos, marcos de validación y respuesta a incidentes
- Dimensiones: exactitud, completitud, consistencia, puntualidad, validez, unicidad, integridad
- Implementar validaciones en la ingesta y la transformación
  - Conjuntos de reglas de Dataplex Data Quality en tablas de BigQuery y activos de GCS
  - Great Expectations o Deequ en Dataflow/Dataproc para verificaciones de esquema y contenido
- Dirigir los fallos a tablas o buckets de dead-letter con un contexto de error enriquecido; evitar la pérdida de datos poniendo en cuarentena los registros erróneos
- Respuesta a incidentes
  - Declarar severidades, propietarios, canales de comunicación, planes de rollback y matriz RACI
  - Automatizar runbooks para rellenar ventanas de datos (backfill) y reprocesar los dead letters; crear snapshots de las tablas afectadas antes de la remediación
Cloud Monitoring, registro (logging), alertas, presupuestos de errores y SLOs
- Exponer métricas: backlog de Dataflow, utilización de slots de BigQuery, latencia de consultas, latencia/errores de GCS, mensajes no confirmados (unacked) de Pub/Sub
- SLOs
  - Ejemplo: “99.9% de los eventos de streaming disponibles en BigQuery en menos de 5 minutos durante un período de 30 días”
  - Monitorear las tasas de consumo del presupuesto de errores (burn rate) y notificar (page) en consumos rápidos; crear un ticket en consumos lentos
- Métricas y alertas basadas en registros (logs)
  - Crear métricas basadas en registros para fallos de trabajos de BigQuery, hallazgos de DLP, errores de claves de KMS
  - Usar filtros de registro avanzados para alertar sobre anexos a tablas específicas o anomalías de acceso
Asignación de costos, presupuestos, controles de consultas, ciclo de vida del almacenamiento y planificación de capacidad
- Asignación y presupuestos
  - Usar etiquetas (labels y tags) en todos los trabajos, datasets, buckets y reservaciones; exportar los datos de facturación a BigQuery y crear presupuestos con notificaciones de Pub/Sub
- Controles de costos de BigQuery
  - Usar particionamiento y clustering para reducir los bytes escaneados
  - Establecer maximumBytesBilled en los trabajos de consulta; ejemplo de configuración de cliente/trabajo:
    - “jobConfiguration”: { “query”: { “maximumBytesBilled”: “1073741824” } }
  - Reservar slots con BigQuery Reservations para cargas de trabajo predecibles; separar las interactivas de las de tipo batch mediante asignaciones
- Ciclo de vida del almacenamiento
  - GCS: reglas de ciclo de vida para pasar a almacenamiento más frío o eliminar después de N días; habilitar el versionado de objetos donde se necesite rollback
  - Ejemplo (condensado): Eliminar versiones no actuales después de 30 días; establecer una política de retención del bucket de 365 días para zonas de cumplimiento normativo (compliance)
  - BigQuery: expiración de tabla por defecto para datasets transitorios; crear snapshots antes de cambios destructivos
- Planificación de capacidad
  - Dataflow: establecer un máximo de workers y autoescalado; dimensionar correctamente los tipos de máquina; fragmentar (shard) las entradas para evitar hot keys
  - Pub/Sub: validar las cuotas de publicación/consumo y la retención de mensajes
  - Red: tener en cuenta el egreso, el movimiento entre regiones y el acceso a servicios privados para bases de datos
Recuperación ante desastres, copias de seguridad, resiliencia multirregional y runbooks
- Clasificar los servicios por RTO/RPO; elegir patrones cold/warm/hot en consecuencia
- Copias de seguridad
  - BigQuery: snapshots de tablas regulares; exportar a GCS para retención fuera de la plataforma si es necesario
  - GCS: buckets de doble región o multirregión para durabilidad; habilitar el bloqueo de bucket (bucket lock) para cumplimiento WORM
  - Bases de datos: copias de seguridad gestionadas en Cloud SQL y Bigtable; probar restauraciones
- Multirregión
  - Mantener el cómputo y el almacenamiento en la misma multirregión para minimizar el egreso y la latencia; evitar dependencias transcontinentales a menos que sea necesario
- Runbooks
  - Documentar el failover, la recuperación de claves, los procedimientos de incidentes de KMS, la rehidratación desde exportaciones y las reasignaciones de reservaciones de BigQuery
  - Probar la recuperación ante desastres (DR) mediante game days; medir el tiempo de recuperación (time-to-recover) y actualizar los SLOs

Escenario de Problema Práctico

NovaRetail Analytics se asocia con múltiples marcas para ingerir archivos CSV diarios que contienen datos de transacciones en una plataforma de análisis compartida. Los archivos llegan a un bucket de aterrizaje (landing) en Cloud Storage y ocasionalmente incluyen filas con formato incorrecto. La plataforma debe aplicar el mínimo privilegio para que cada cliente solo pueda acceder a sus propios datos, detectar campos sensibles y proporcionar alertas inmediatas cuando se añaden filas a una tabla de auditoría específica. La empresa también necesita controles de costos y un plan de recuperación.

Enfoque:

Aislar a los tenants y aplicar el mínimo privilegio
- Crear un dataset de BigQuery dedicado por cliente (p. ej., client_a_analytics). Otorgar solo al grupo del cliente los roles de dataset apropiados (bigquery.dataViewer, bigquery.jobUser) y restringir el uso de la API de BigQuery a usuarios aprobados mediante IAM y VPC-SC si aplica.
- Justificación: Un dataset por tenant limita el radio de impacto (blast radius) y simplifica la complejidad de las políticas a nivel de fila. El alcance de mínimo privilegio a nivel de dataset previene el acceso entre tenants por defecto.
Gobernar el esquema, la clasificación y el enmascaramiento
- Definir una taxonomía de etiquetas de política (policy tags) en Data Catalog (público, interno, confidencial, restringido) y plantillas de etiquetas para propietario, data steward y RTO/RPO. Adjuntar las etiquetas de política a columnas sensibles (email, card_suffix) en el dataset de cada cliente. Aplicar políticas de enmascaramiento de BigQuery para restringir las vistas a roles no privilegiados.
- Ejemplo:

undefined

Justificación: Las etiquetas centralizadas proporcionan un control uniforme entre tablas; el enmascaramiento garantiza lecturas seguras por defecto sin duplicar datos.

Descubrir PII y aplicar desidentificación donde sea necesario
- Configurar el descubrimiento de Sensitive Data Protection para escanear el bucket de aterrizaje y las tablas curadas de BigQuery. Usar una plantilla de inspección para PII común y una plantilla de desidentificación para tokenizar los correos electrónicos de forma determinista para casos de uso con joins.
- Justificación: El descubrimiento automatizado reduce los errores manuales; la tokenización determinista equilibra la privacidad con los requisitos de join en el análisis.
Asegurar el pipeline con cuentas de servicio, suplantación (impersonation) y CMEK
- Usar una cuenta de servicio de Dataflow solo con los roles necesarios: storage.objectViewer en el bucket de aterrizaje, bigquery.dataEditor en los datasets de destino y acceso a las etiquetas de política si es necesario. Usar CMEK para los datasets del cliente y otorgar a los agentes de servicio de BigQuery y Dataflow el rol CryptoKey Encrypter/Decrypter.
- Justificación: Roles específicos junto con CMEK cumplen con los requisitos de mínimo privilegio y control de claves. El acceso de los agentes de servicio a las claves previene fallos en los trabajos.
Construir una ingesta resiliente con cuarentena de errores
- Ejecutar un trabajo de Dataflow en modo batch que lea los CSV, valide el esquema y escriba las filas válidas en tablas particionadas de BigQuery. Dirigir las filas inválidas a una tabla de dead-letter en BigQuery con detalles del error (nombre del archivo, línea, motivo).
- Justificación: Las salidas secundarias (side outputs) preservan los datos erróneos para su análisis sin bloquear los datos correctos; las tablas particionadas reducen el costo de escaneo y aceleran las consultas.
Crear linaje y metadatos de negocio
- Registrar el bucket de aterrizaje y los datasets como activos de Dataplex en un lake. Habilitar la recolección de linaje para el trabajo de Dataflow y etiquetar las tablas curadas con metadatos de negocio (propietario de los datos, sensibilidad, retención).
- Justificación: La gobernanza centralizada permite el análisis de impacto, la preparación para auditorías y una gestión (stewardship) estandarizada.
Monitorear, alertar y auditar
- Habilitar los registros de auditoría de Admin y Data Access, exportados con CMEK a un proyecto de logging central y a BigQuery para análisis. Añadir una alerta basada en registros para nuevas filas añadidas a la tabla de auditoría usando un filtro avanzado en los trabajos de inserción de BigQuery; exportar ese sink a Pub/Sub para que la herramienta de monitoreo lo consuma.
- Justificación: Los registros son evidencia resistente a la manipulación; las alertas específicas notifican solo sobre la tabla requerida, reduciendo el ruido.
Aplicar controles de costos y barreras de protección (guardrails) para consultas
- Requerir que los trabajos de consulta establezcan maximumBytesBilled y aprovechar el clustering en columnas de alta cardinalidad (p. ej., order_id). Aplicar presupuestos y establecer etiquetas (labels) (cliente, entorno) en trabajos y datasets. Usar BigQuery Reservations para separar el análisis interactivo de las cargas programadas.
- Justificación: Las barreras de protección previenen costos descontrolados; las etiquetas permiten la refacturación (chargeback); el aislamiento de slots mantiene un rendimiento predecible.
Implementar retención y recuperación ante desastres (DR)
- En el bucket de aterrizaje, habilitar el versionado de objetos y una regla de ciclo de vida para eliminar objetos después de 30 días; establecer una política de retención para zonas de cumplimiento normativo. En BigQuery, establecer una expiración de tabla por defecto para las tablas de staging y tomar snapshots periódicos de las tablas curadas. Almacenar los procedimientos de copia de seguridad de KMS y los pasos de restauración de tablas en runbooks y probarlos trimestralmente.
- Justificación: La gestión del ciclo de vida reduce el costo de almacenamiento; los snapshots y los runbooks documentados aseguran la recuperabilidad. Las pruebas validan las suposiciones de RTO/RPO.
Revisiones periódicas de acceso y SLIs/SLOs de calidad
- Trimestralmente, exportar las políticas de IAM con Cloud Asset Inventory y compararlas con una línea base aprobada. Definir SLOs como “99% de los archivos diarios procesados en 30 minutos desde su llegada” con alertas sobre la tasa de consumo (burn rate). Monitorear los SLIs de calidad de datos (completitud, validez) usando las reglas de Dataplex Data Quality y dirigir las violaciones a la respuesta de incidentes con automatización de backfill.
- Justificación: La revisión regular previene la acumulación de privilegios (privilege creep); las operaciones basadas en SLOs alinean el esfuerzo con la experiencia del usuario; las verificaciones de calidad automatizadas detectan regresiones tempranamente.

Compromisos técnicos y modos de fallo abordados:

Una mala configuración de CMEK o la desactivación de una clave interrumpirá las cargas de Dataflow y las consultas de BigQuery; es obligatorio monitorear el estado de KMS y los permisos del agente de servicio.
El uso excesivo de políticas de fila de grano fino puede degradar el rendimiento; es preferible el aislamiento de datasets para los tenants.
Los escaneos de descubrimiento pueden ser costosos; acotar por zona y muestrear donde sea apropiado, aceptando el riesgo de omitir PII poco común.
La fatiga por alertas reduce la capacidad de respuesta; construir filtros precisos por tabla/acción y probarlos antes de su implementación.

← Machine Learning · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →