Google PDE: Gouvernance des données, sécurité, fiabilité et gestion opérationnelle des coûts — Guide d'étude

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

Fait partie du Google Professional Data Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Cette section résume les modèles de conception et les pratiques opérationnelles pour la gouvernance des données, la sécurité, la fiabilité et les opérations de coûts sur Google Cloud. Elle se concentre sur BigQuery, Cloud Storage, Dataflow, Dataplex et les services associés. L’accent est mis sur le moindre privilège, la gestion des clés de chiffrement, les métadonnées et la classification, l’accès basé sur des politiques, les preuves de conformité, l’observabilité avec des SLO exploitables et le contrôle des coûts. Les compromis, les modes de défaillance et les configurations pratiques sont inclus pour permettre des plateformes de données sûres, auditables et efficaces.

Identité, Accès et Gouvernance

IAM, comptes de service, usurpation d’identité, identité de charge de travail, moindre privilège
- Périmètres d’identité
  - Utilisateurs et groupes via Cloud Identity ou Google Workspace
  - Comptes de service pour les charges de travail ; attribuer des rôles à portée restreinte à la ressource la plus basse possible (par ex., l’ensemble de données au lieu du projet)
- Moindre privilège
  - Préférer les rôles prédéfinis aux rôles primitifs ; pour BigQuery, utiliser des rôles comme bigquery.dataViewer sur les ensembles de données plutôt que le rôle de lecteur au niveau du projet
  - Accorder les autorisations aux groupes ; gérer l’appartenance dans un IdP, et non par utilisateur dans IAM
  - Séparation des tâches : rôles distincts pour la gestion des clés, l’accès aux données et l’administration
- Usurpation d’identité et Fédération d’identité de charge de travail
  - Utiliser l’usurpation d’identité de compte de service (rôles/iam.serviceAccountTokenCreator) pour que le CI/CD ou l’automatisation ne stocke jamais de clés à longue durée de vie
  - Utiliser la Fédération d’identité de charge de travail avec OIDC/SAML pour permettre aux identités externes d’obtenir des jetons à courte durée de vie sans fichiers de clés de compte de service
- Modes de défaillance et mesures d’atténuation
  - Des rôles excessifs au niveau du projet conduisent à des mouvements latéraux ; auditer avec Cloud Asset Inventory
  - Clés privées de compte de service perdues : interdire la création de clés ; utiliser les contraintes de politique d’organisation pour bloquer le téléchargement de clés ; effectuer une rotation si elles sont trouvées
Gouvernance Dataplex, Data Catalog, métadonnées métier, lignage des données
- Dataplex fournit des lacs, des zones et des assets pour unifier la gouvernance sur BigQuery et Cloud Storage avec des politiques centralisées
- Data Catalog contient un glossaire métier, des modèles de tags et des métadonnées techniques ; attacher des métadonnées métier (propriétaire, classe de PII, RTO/RPO) via des tags
- Le lignage des données capture les relations en amont/en aval ; utiliser les intégrations de lignage de Dataplex avec Dataflow, Dataproc et BigQuery pour tracer l’impact et le périmètre de conformité
- Compromis
  - La gouvernance centralisée ajoute une surcharge initiale mais réduit les risques à long terme et accélère les audits
Tags de politique, classification, accès au niveau des lignes, masquage de colonnes
- Classification
  - Définir une taxonomie (par ex., public, interne, confidentiel, restreint) dans les tags de politique de Data Catalog
  - Attacher des tags de politique aux colonnes BigQuery ; lier IAM aux tags pour que l’accès suive la classification à travers les tables
- Masquage de colonnes
  - Utiliser les politiques de masquage de données de BigQuery pour hacher ou annuler les colonnes sensibles pour les lecteurs non privilégiés
  - Exemple :

undefined

Accès au niveau des lignes
- Utiliser les politiques d’accès aux lignes pour filtrer les enregistrements par des attributs tels que tenant_id ou region
- Exemple :

undefined

Modes de défaillance
- L’autorisation IAM sur les tags de politique non accordée aux comptes de service utilisés par les pipelines provoque des échecs de requêtes ; inclure le rôle de lecteur/d’accesseur de tags de politique pour les agents de service si nécessaire
- Les politiques de lignes peuvent dégrader les performances si les prédicats par utilisateur sont nombreux et très sélectifs ; préférer une approche plus grossière avec un ensemble de données par locataire lorsque l’isolation est stricte
Découverte et désidentification de données sensibles
- Utiliser Sensitive Data Protection pour analyser en continu Cloud Storage et BigQuery ; créer des configurations de découverte par lac/zone avec des modèles
- Utiliser des transformations de désidentification : tokenisation, chiffrement déterministe pour la joignabilité, ou masquage
- Stocker les clés de transformation dans Cloud KMS ; conserver les clés de ré-identification séparément avec un double contrôle
- Compromis
  - Le chiffrement déterministe permet les jointures mais peut laisser fuiter des informations sur la fréquence ; ajouter un chiffrement préservant le format ou une discrétisation (bucketing) si nécessaire
  - L’échantillonnage réduit le coût des analyses de découverte mais peut manquer des PII à faible prévalence

Opérations de sécurité et de conformité

Chiffrement, Cloud KMS, CMEK et gestion des secrets
- Le chiffrement au repos et en transit est activé par défaut ; activez CMEK lorsque le contrôle réglementaire des clés est requis (BigQuery, GCS, Pub/Sub, Dataflow)
- Gestion des clés
  - Placez les clés dans la même région que les données ; accordez à l’agent de service (par ex., BigQuery Service Agent) le rôle roles/cloudkms.cryptoKeyEncrypterDecrypter
  - Effectuez une rotation régulière des clés ; surveillez les clés désactivées ou dont la destruction est planifiée
- Modes de défaillance
  - La désactivation d’une clé CMEK ou la révocation de l’agent de service interrompt les chargements, les requêtes et les exportations ; alertez sur les changements d’état des clés
  - L’utilisation de clés inter-régions n’est pas autorisée ; alignez les emplacements pour éviter les erreurs de création de tâches
- Secrets
  - Utilisez Secret Manager pour les identifiants de base de données, les jetons d’API ; accordez l’accès via IAM et auditez avec les journaux de Secret Manager
  - N’intégrez jamais de secrets dans le code, les conteneurs ou les notebooks ; montez les secrets via un accès d’exécution ; préférez l’authentification de base de données IAM lorsqu’elle est prise en charge
Journaux d’audit, revue des accès, preuves de conformité, rétention
- Activez les journaux d’accès aux données (Data Access logs) à l’échelle de l’organisation pour BigQuery, GCS, Pub/Sub ; exportez-les vers un projet de journalisation dédié en écriture seule avec CMEK
- Créez des récepteurs de journaux agrégés (log sinks) vers BigQuery (analytique) et Cloud Storage (archive immuable à long terme avec verrou de conservation de bucket)
- Utilisez Cloud Asset Inventory et Policy Analyzer pour la revue périodique des accès et la détection de dérive
- Rétention
  - Définissez la rétention des journaux selon les besoins de conformité ; utilisez le versionnement des objets et les politiques de rétention sur GCS
  - Dans BigQuery, définissez une expiration de table par défaut et utilisez les instantanés de table (snapshots) / le voyage dans le temps (time travel) pour une restauration à court terme ; archivez les jeux de données critiques dans des projets distincts
- Preuves
  - Maintenez une cartographie des contrôles avec les tags Dataplex (par ex., « SOX-C2 : Preuve dans le projet X, récepteur Y »), automatisez les exportations et exécutez des requêtes planifiées pour produire des attestations

Fiabilité, observabilité, qualité et gestion des coûts

Dimensions de la qualité des données, cadres de validation et réponse aux incidents
- Dimensions : exactitude, complétude, cohérence, ponctualité, validité, unicité, intégrité
- Mettre en œuvre des validations lors de l’ingestion et de la transformation
  - Ensembles de règles Dataplex Data Quality sur les tables BigQuery et les ressources GCS
  - Great Expectations ou Deequ dans Dataflow/Dataproc pour les vérifications de schéma et de contenu
- Acheminer les échecs vers des tables ou des buckets de lettres mortes (dead-letter) avec un contexte d’erreur riche ; éviter la perte de données en mettant en quarantaine les enregistrements incorrects
- Réponse aux incidents
  - Déclarer les niveaux de sévérité, les propriétaires, les canaux de communication, les plans de restauration (rollback) et les matrices RACI
  - Automatiser les runbooks pour rattraper (backfill) les fenêtres de données et retraiter les lettres mortes ; créer des snapshots des tables affectées avant la remédiation
Cloud Monitoring, journalisation, alertes, budgets d’erreurs et SLO
- Exposer les métriques : backlog de Dataflow, utilisation des slots BigQuery, latence des requêtes, latence/erreurs GCS, messages non acquittés (unacked) de Pub/Sub
- SLO
  - Exemple : « 99,9 % des événements de streaming disponibles dans BigQuery en moins de 5 minutes sur une période de 30 jours »
  - Suivre les taux de consommation du budget d’erreurs (burn rates) et alerter (page) en cas de consommation rapide ; créer un ticket en cas de consommation lente
- Métriques et alertes basées sur les journaux (logs)
  - Créer des métriques basées sur les journaux pour les échecs de jobs BigQuery, les résultats DLP, les erreurs de clés KMS
  - Utiliser des filtres de journaux avancés pour alerter sur des ajouts spécifiques à une table ou des anomalies d’accès
Allocation des coûts, budgets, contrôles des requêtes, cycle de vie du stockage, planification de la capacité
- Allocation et budgets
  - Utiliser des libellés (labels) et des tags sur tous les jobs, datasets, buckets et réservations ; exporter les données de facturation vers BigQuery et créer des budgets avec des notifications Pub/Sub
- Contrôles des coûts de BigQuery
  - Utiliser le partitionnement et le clustering pour réduire le volume de données analysées (scanned bytes)
  - Définir maximumBytesBilled sur les jobs de requête ; exemple de configuration client/job :
    - “jobConfiguration”: { “query”: { “maximumBytesBilled”: “1073741824” } }
  - Réserver des slots avec BigQuery Reservations pour les charges de travail prévisibles ; séparer les requêtes interactives des traitements par lots (batch) via des affectations
- Cycle de vie du stockage
  - GCS : règles de cycle de vie pour passer à des classes de stockage plus froides ou supprimer après N jours ; activer la gestion des versions d’objets (object versioning) là où la restauration est nécessaire
  - Exemple (condensé) : Supprimer les versions non actuelles après 30 jours ; définir une politique de conservation (retention policy) de 365 jours sur le bucket pour les zones de conformité
  - BigQuery : expiration par défaut des tables pour les datasets transitoires ; créer un snapshot avant les modifications destructrices
- Planification de la capacité
  - Dataflow : définir le nombre maximal de workers et l’autoscaling ; dimensionner correctement les types de machines ; partitionner (shard) les entrées pour éviter les clés surchargées (hot keys)
  - Pub/Sub : valider les quotas de publication/consommation et la rétention des messages
  - Réseau : tenir compte de la sortie de données (egress), des transferts inter-régions et de l’accès aux services privés (private service access) pour les bases de données
Reprise après sinistre, sauvegardes, résilience multi-régionale et runbooks
- Classifier les services par RTO/RPO ; choisir les modèles de reprise (patterns) cold/warm/hot en conséquence
- Sauvegardes
  - BigQuery : snapshots de table réguliers ; exporter vers GCS pour une rétention hors plateforme si nécessaire
  - GCS : buckets bi-régionaux (dual-region) ou multi-régionaux pour la durabilité ; activer le verrouillage de bucket (bucket lock) pour la conformité WORM
  - Bases de données : sauvegardes gérées dans Cloud SQL et Bigtable ; tester les restaurations
- Multi-région
  - Conserver le calcul (compute) et le stockage dans la même multi-région pour minimiser la sortie de données (egress) et la latence ; éviter les dépendances intercontinentales sauf si nécessaire
- Runbooks
  - Documenter le basculement (failover), la récupération des clés, les procédures d’incident KMS, la réhydratation à partir d’exports et les réaffectations de réservations BigQuery
  - Tester la reprise après sinistre (DR) via des journées de simulation (game days) ; suivre le temps de récupération (time-to-recover) et mettre à jour les SLO

Scénario de problème pratique

NovaRetail Analytics s’associe à plusieurs marques pour ingérer quotidiennement des fichiers CSV contenant des données de transaction dans une plateforme d’analyse partagée. Les fichiers arrivent dans un bucket Cloud Storage de réception (landing bucket) et contiennent parfois des lignes mal formées. La plateforme doit appliquer le principe du moindre privilège afin que chaque client ne puisse accéder qu’à ses propres données, détecter les champs sensibles et fournir des alertes immédiates lorsque des lignes sont ajoutées à une table d’audit spécifique. L’entreprise a également besoin de contrôles des coûts et d’un plan de reprise.

Approche :

Isoler les locataires (tenants) et appliquer le moindre privilège
- Créer un dataset BigQuery dédié par client (par ex., client_a_analytics). N’accorder au groupe du client que les rôles de dataset appropriés (bigquery.dataViewer, bigquery.jobUser) et restreindre l’utilisation de l’API BigQuery aux utilisateurs approuvés via IAM et VPC-SC si applicable.
- Justification : Un dataset par locataire limite le rayon d’impact (blast radius) et simplifie la complexité des politiques au niveau des lignes (row policy). Le périmètre du moindre privilège au niveau du dataset empêche par défaut l’accès entre locataires.
Gouverner le schéma, la classification et le masquage
- Définir une taxonomie de tags de politique (policy tag) dans Data Catalog (public, internal, confidential, restricted) et des modèles de tags pour le propriétaire, le data steward et les RTO/RPO. Attacher les tags de politique aux colonnes sensibles (email, card_suffix) dans chaque dataset client. Appliquer des politiques de masquage BigQuery pour restreindre les vues pour les rôles non privilégiés.
- Exemple :

undefined

Justification : Les tags centralisés offrent un contrôle uniforme sur toutes les tables ; le masquage garantit des lectures sécurisées par défaut sans dupliquer les données.

Découvrir les PII et appliquer la dé-identification si nécessaire
- Configurer la découverte de Sensitive Data Protection pour analyser le bucket de réception et les tables BigQuery organisées (curated). Utiliser un modèle d’inspection pour les PII courantes et un modèle de dé-identification pour tokeniser les e-mails de manière déterministe pour les cas d’usage de jointure.
- Justification : La découverte automatisée réduit les erreurs manuelles ; la tokenisation déterministe équilibre la confidentialité avec les exigences de jointure pour l’analyse.
Sécuriser le pipeline avec des comptes de service, l’emprunt d’identité (impersonation) et les CMEK
- Utiliser un compte de service Dataflow avec uniquement les rôles nécessaires : storage.objectViewer sur le bucket de réception, bigquery.dataEditor sur les datasets cibles, et l’accès aux tags de politique si requis. Utiliser des CMEK pour les datasets clients et accorder aux agents de service (service agents) de BigQuery et Dataflow le rôle Chiffreur/Déchiffreur de CryptoKey (CryptoKey Encrypter/Decrypter).
- Justification : Des rôles restreints combinés aux CMEK répondent aux exigences du moindre privilège et du contrôle des clés. L’accès des agents de service aux clés prévient les échecs de jobs.
Construire une ingestion résiliente avec une quarantaine d’erreurs
- Exécuter un job Dataflow par lots (batch) qui lit les CSV, valide le schéma et écrit les lignes valides dans des tables partitionnées BigQuery. Acheminer les lignes invalides vers une table de lettres mortes (dead-letter) BigQuery avec les détails de l’erreur (nom du fichier, ligne, raison).
- Justification : Les sorties secondaires (side outputs) conservent les données incorrectes pour analyse sans bloquer les données valides ; les tables partitionnées réduisent les coûts d’analyse et accélèrent les requêtes.
Créer le lignage des données et les métadonnées métier
- Enregistrer le bucket de réception et les datasets comme des ressources (assets) Dataplex dans un lac de données (lake). Activer la collecte du lignage pour le job Dataflow et taguer les tables organisées avec des métadonnées métier (propriétaire des données, sensibilité, rétention).
- Justification : La gouvernance centralisée permet l’analyse d’impact, la préparation aux audits et une gestion (stewardship) standardisée.
Surveiller, alerter et auditer
- Activer les journaux d’audit Admin et Data Access, exportés avec CMEK vers un projet de journalisation central et vers BigQuery pour l’analyse. Ajouter une alerte basée sur les journaux pour les nouvelles lignes ajoutées à la table d’audit en utilisant un filtre avancé sur les jobs d’insertion BigQuery ; exporter ce récepteur (sink) vers Pub/Sub pour que l’outil de surveillance le consomme.
- Justification : Les journaux sont des preuves infalsifiables ; les alertes ciblées ne notifient que pour la table requ