Securing and governing data on Google Cloud (GCP) is the core set of practices that keep your digital information safe from theft, accidental loss, and unauthorised eyes. For the PDE exam, you must understand how to control who can see what, how to lock data so it's unreadable without a key, and how to automatically scan for and hide sensitive information like credit card numbers.
Jump to a section
A simple way to picture Securing and Governing Data on GCP
Your flat share house, 9 PM on a Saturday. Music is playing, people are coming and going. You own the place, but different rules apply to different people.
Your best mate, who has a key, can walk right in, grab a drink from the fridge, and crash in the spare room. They have 'full access'. A colleague you invited can come into the living room and use the bathroom, but your bedroom and the cupboard with the good whisky are strictly off limits – that is 'restricted access'. The pizza delivery person is allowed to stand at the front door and hand over the food; they can't even step inside – that is the 'least privilege' principle. Now, let's say you hide your valuables (credit cards, passport) in a locked safe in your wardrobe. If you only give the combination to your best mate, you are using 'encryption at rest' – the data (your valuables) is unreadable without the key.
But what if you accidentally leave the front door wide open? Anyone on the street could walk in. You'd have a 'data breach'. So, you install a smart lock that tracks who comes and goes, and you have a 'guest list' that is checked at the door. That guest list is your IAM policy. The smart lock logs are your Cloud Audit Logs. The safe is Cloud KMS. And if you decide to blur the faces of people in photos before posting them, you're using DLP to protect people's privacy before sharing (or storing) data.
Think of GCP as a giant, shared digital office block. You might own a floor (your project), but you share the building's infrastructure (the cloud network). 'Securing and Governing Data' is the set of locks, keys, permissions, and rules you put in place so that only the right people (or computer programs) can access the right information at the right time. It also involves making sure the information stays confidential (secret) and whole (not corrupted).
There are three main pillars to understand:
Identity and Access Management (IAM): This is your master guest list. It defines 'Who' (a user, a group, a computer service) can do 'What' (a specific action, like read, write, or delete) on 'Which' resource (a specific data bucket, database, or GCP service). IAM roles are collections of permissions. You can give a role to a user. For example, the 'roles/storage.objectViewer' role lets a user only see objects in a Cloud Storage bucket, but not delete them. This replaces the old IT way of creating individual user accounts on every single server, which was a security nightmare.
Cloud Key Management Service (Cloud KMS): This is your digital safe and key-copying service. When you 'encrypt' data, you scramble it with a secret number called a 'key'. Without the key, the data looks like gibberish, even if someone steals the hard drive. Cloud KMS is the central place where you create, store, and manage these encryption keys. It lets you control who can use the keys (via IAM) and also supports Automatic Key Rotation (where a new key is issued regularly, like changing your password every month). This replaces the old practice of storing keys in the same configuration files as the data itself – a very common and dangerous mistake.
Data Loss Prevention (DLP) API: This is your automatic scanner. Imagine a robot that can read every document in your office, find things like employee social security numbers, and then either redact (black out) them, mask them (show only the last four digits), or alert you that they exist. DLP scans your data (in Cloud Storage, BigQuery, etc.) for 'InfoTypes' – patterns that match sensitive data like credit card numbers, passport IDs, or medical record numbers. This is crucial because you sometimes forget where sensitive data lives. DLP helps you find it and protect it automatically, which is far more reliable than a person manually checking files.
These three work together. You use IAM to control access to Cloud KMS, and you use IAM to control who can run DLP jobs. You might use DLP to find and de-identify (mask) data before loading it into a data warehouse, ensuring that people who have read access to the warehouse don't see sensitive customer details, but can still analyse the data because the patterns (like age range) are preserved. This is a common pattern called 'data tokenization'.
Finally, 'Governance' is the bigger picture: the policies and processes you set up. This includes
Defining who is responsible for data quality
Setting rules for how long data is kept (data retention)
Creating audit trails (so you know who accessed what, when)
This governance layer is often implemented using 'Organization Policies' in GCP, which can enforce rules across all your projects, like 'no one can disable audit logs'.
Identify Sensitive Data
Before you can protect data, you must know where it is. Use the DLP API to scan your Cloud Storage buckets, BigQuery tables, and Cloud Datastore databases. It identifies InfoTypes like email addresses or passport numbers, giving you a report of what sensitive data exists and where.
Classify Data and Define Roles
Based on the DLP scan, you classify data by sensitivity (e.g., public, internal, confidential, restricted). For each classification, you define an IAM pre-defined role that permits the minimum actions necessary. For example, a 'Data Analyst' role for the 'confidential' data might be roles/bigquery.dataViewer on a specific dataset.
Encrypt Data at Rest with CMEK
For high-sensitivity data ('restricted'), you don't rely on default encryption. You create a customer-managed encryption key (CMEK) in Cloud KMS. You then configure the Cloud Storage bucket or BigQuery dataset to use that key. This ensures that if the encryption key is revoked or destroyed, the data becomes inaccessible.
De-identify Data with DLP
You use DLP in a data pipeline (e.g., Cloud Dataflow) to read the raw data, apply de-identification transformations (like masking, tokenization, or bucketing), and write a 'safe' version to a different location. This allows analysts to work with data patterns without seeing raw sensitive values.
Set Audit Logging and Monitor
You enable Data Access audit logs for your critical resources. You also create a Cloud Monitoring alert that fires if someone tries to access your CMEK key from an unexpected IP address. You periodically review logs to ensure no unauthorised access has occurred.
You are a Data Engineer at 'FinanceFast', a mid-sized fintech company handling loan applications. Your job is to store customer application data in GCP for analysis, but you must comply with strict financial regulations.
You create a Cloud Storage bucket named 'loan-applications-raw' to store incoming application PDFs. Without security, anyone could read them. You immediately turn to IAM. You create a service account (a special account for a computer program) for the application that uploads the PDFs. You assign it the 'roles/storage.objectCreator' role, meaning it can only write new files, not read or delete existing ones. This is the principle of 'Least Privilege' – giving only the minimum access needed.
The data analysts need to read the data to build models, but they should not see the applicant's full national insurance number (NIN). You use DLP. You write a Cloud Dataflow job (a data processing pipeline) that reads each PDF from the bucket, runs DLP on it, and writes a 'cleaned' version to a second bucket, 'loan-applications-cleaned'. DLP is configured to find the 'UK_DRIVING_LICENSE' InfoType and de-identify it – specifically, it replaces the number with '[REDACTED]' while keeping the rest of the document readable. The analysts get access to the 'cleaned' bucket.
You must encrypt the data at rest. You could let Google manage the encryption (Google-managed encryption keys), but regulations require you to control the keys. So, you create a key ring and a symmetric key (the same key encrypts and decrypts) in Cloud KMS. You then use IAM to allow only your Cloud Storage service account to access this key. When you tell Cloud Storage to use a 'Customer-Managed Encryption Key' (CMEK), GCP will encrypt all data in that bucket with your Cloud KMS key. If you delete the key, the data becomes permanently unreadable – a powerful control.
You set up a governance policy. You enable 'Cloud Audit Logs' to record every admin action (like creating a bucket) and every data access (who read a file). This is mandatory for compliance. You also set a 'Bucket Lock' policy that prevents anyone from deleting the data for 7 years, as required by law. You use 'Organization Policies' to block the creation of buckets with 'public access' across your whole GCP project.
A security audit happens. The auditor asks, 'Show me exactly who accessed customer data last month.' You go to Cloud Logging, filter for 'loan-applications-raw' and 'Storage Object Read', and you can produce a list of every user and service account that touched the data. Without IAM, Cloud KMS, and DLP, this would be an impossible, manual mess.
The PDE exam will expect you to know not just *what* the services do, but *how* they interact and *which one* to choose in a specific scenario. This is not a memorisation test of definitions; it is an application test. Expect scenario-based multiple choice questions.
Key patterns and traps:
IAM Primitive vs Predefined Roles: This is the biggest trap. Primitive roles (Owner, Editor, Viewer) are broad and applied at the project level. They are 'too powerful' for most users. Predefined roles are finely scoped (e.g., 'roles/bigquery.dataViewer'). The exam will often describe a scenario where a user needs to only query a specific BigQuery dataset. The 'correct' answer will never be 'give them the Project Viewer role'. It will be 'create a custom IAM role' or 'assign the roles/bigquery.dataViewer role on that specific dataset'. The trap is you choosing the simpler, but insecure, primitive role.
Cloud KMS Key Types: You must know the difference between a Symmetric key (one key for encrypt and decrypt) and an Asymmetric key (a public key for encrypt, a private key for decrypt – used for digital signatures). The exam loves to ask: 'Which key type is used to verify a digital signature?' Answer: Asymmetric public key. Also, understand key rotation – automatic rotation based on a schedule is a key feature of Cloud KMS that you can activate with a single setting.
DLP De-identification vs Re-identification: DLP can de-identify data (mask, redact, pseudonymise). Pseudonymisation uses a token to replace a sensitive value, and if you keep the mapping table secure, you can 're-identify' the user later. The exam will test your understanding that pseudonymisation is NOT anonymous data, because it can be reversed. You must know each de-identification technique (masking, redaction, bucketing, etc.) and when to use them.
Access Transparency vs Access Approval: This is a specific, tricky concept. Access Transparency gives you logs showing what Google employees do when they access your data (e.g., for support). Access Approval is a more advanced control that lets you explicitly 'approve or deny' such support access requests before they happen. The exam may ask which one to use for ultra-sensitive data (answer: Access Approval).
Principle of Least Privilege: This is a thematic foundation. Every single question about IAM will have a 'least privilege' answer as the correct one. If a question asks 'How should you give a developer access to deploy code?', the answer will involve creating a role with *only* the specific permissions needed for deployment, not granting them Editor or Owner.
Cloud Audit Logs Types: You need to know 'Admin Activity' logs (always on, free, show configuration changes) and 'Data Access' logs (off by default, chargeable, show who read data). The exam will test that you must *enable* Data Access logs to see who read specific customer data.
Organization Policies: This is a service that lets you set restrictions on all resources in your organisation. Exam trap: 'A user needs to shut off all public access to buckets.' Answer: Set an Organization Policy, not a single bucket policy.
IAM is the 'who can do what' rulebook; it controls access to resources but does NOT automatically encrypt or classify your data.
The principle of Least Privilege means giving a user or service exactly the permissions they need and nothing more – never use 'Owner' or 'Editor' roles if a specific predefined role exists.
Cloud KMS stores your encryption keys in a central, secure vault; you can control who uses those keys and automatically rotate them on a schedule.
Data Loss Prevention (DLP) automatically finds and de-identifies sensitive information like credit card numbers or national insurance numbers in your files and databases.
To see who actually read your data (not just who changed its configuration), you must enable Data Access audit logs in Cloud Logging.
Organization Policies let you enforce security rules across your entire GCP organisation, like banning public buckets or disabling the deletion of audit logs.
Access Approval gives you explicit control to approve or deny Google support staff from accessing your encrypted data.
These come up on the exam all the time. Here's how to tell them apart.
Primitive IAM Role (e.g., Viewer)
Applies to the entire GCP project.
Grants read access to all services in the project.
Suitable only for a small set of auditors with global oversight needs.
Considered a security anti-pattern for most users.
Predefined IAM Role (e.g., bigquery.dataViewer)
Scoped to a specific resource or service (e.g., a BigQuery dataset).
Grants read access only to that specific resource.
Follows the principle of least privilege.
The recommended way to grant permissions in modern GCP.
Data Encryption at Rest (CMEK)
Protects data stored on disk or in a database.
Uses symmetric encryption (same key for encrypt/decrypt).
Key management is under your control (via Cloud KMS).
Data Encryption in Transit (TLS/SSL)
Protects data moving across the network between two systems.
Uses asymmetric encryption for initial handshake, then symmetric.
Managed automatically by the network protocol (e.g., HTTPS).
DLP Redaction
Completely removes the sensitive data (e.g., replaces 'INN' with '[REDACTED]').
Data is permanently lost; cannot be reversed.
Simple and effective for removing data you cannot legally store.
DLP Pseudonymisation
Replaces sensitive data with a fake token or identifier.
Data can be re-identified if the mapping table is available.
Preserves data linking for analysis across different sources.
Access Transparency Logs
Provides logs showing who at Google accessed your data.
Is a read-only report – you cannot stop the access.
Satisfies compliance need for 'who accessed my data'.
Access Approval Requests
Requires you to explicitly approve or deny a support request before access happens.
Is a proactive control that blocks access until you say yes.
Used when you need definitive control over Google personnel access.
Mistake
IAM roles applied at the project level automatically secure all resources inside the project.
Correct
IAM roles grant access *to* the resource, but they don't enforce encryption or DLP scanning on the data itself. A user with 'Storage Object Admin' can read and write files, but the files might be unencrypted. Security is layered.
Beginners confuse authorisation (IAM) with other security controls (encryption, DLP). They think 'I locked the door, so the safe is safe' – but you also need to lock the safe.
Mistake
If I use Google-managed encryption keys, my data is not secure because Google has the key.
Correct
Google-managed encryption keys are incredibly secure. They encrypt data at rest by default. Google has rigorous controls and audits to prevent its employees from accessing your data. For most use cases, this is sufficient. Customer-managed keys (CMEK) are for compliance where you must control key creation and deletion.
Many beginners have a deep-seated mistrust of 'the cloud' and think any key held by the vendor is a vulnerability. They don't understand Google's infrastructure and security model.
Mistake
Data Loss Prevention (DLP) can completely anonymise data, making it impossible to ever identify a person from the dataset.
Correct
DLP can de-identify data using techniques like masking and pseudonymisation, but true anonymisation is very difficult to guarantee. Pseudonymised data can often be re-identified if the mapping table is compromised. 'k-anonymity' and 'l-diversity' are advanced DLP methods, but the data is still not perfectly anonymous.
The term 'anonymisation' is often used loosely. Truly anonymous data is data that cannot be linked back to an individual by any means, even with external data. DLP reduces risk but rarely achieves perfect anonymity.
Mistake
Cloud KMS is only for encrypting data in Cloud Storage buckets.
Correct
Cloud KMS manages encryption keys that can be used across many GCP services, including BigQuery, Compute Engine (for disk encryption), Cloud SQL, and Cloud Storage. It can also be used to encrypt data client-side before sending it to GCP.
Beginners learn the first example (Cloud Storage) and assume that's the only use case. They don't realise it's a centralised key management service for the entire platform.
Mistake
If I use DLP to scan a dataset, I don't need to worry about IAM anymore, because the sensitive data is removed.
Correct
DLP is a discovery and classification tool, not a replacement for IAM. You still need IAM to control who can read the cleaned dataset and who can run DLP jobs. DLP can be used alongside IAM as a defence-in-depth strategy, not a replacement.
The 'magic bullet' fallacy: beginners think one tool solves all security problems. They don't understand that security is a layered system (defence in depth).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A role is a collection of permissions (e.g., 'can read files'). A policy is the actual document that binds a role to a user, group, or service account on a specific resource. You don't give someone a role in the air; you create a policy that says 'User X has Role Y on Resource Z'.
Yes. You can use the Cloud KMS API from your local code to encrypt a file using a key stored in Cloud KMS. You then upload the already-encrypted file (client-side encryption). The key needed to decrypt it remains safely in Cloud KMS.
No. DLP is a tool you must invoke. You create a scan job (inspection job) that targets specific data sources (a BigQuery table, a Cloud Storage bucket). It does not run automatically on all data unless you set up a recurring schedule.
After a short waiting period (to prevent accidents), the key will be destroyed. The data in the bucket becomes permanently unreadable and unrecoverable. This is why you must be very careful with key deletion and often use key version rotation instead of deletion.
Primitive roles are the older, broader roles: Owner, Editor, and Viewer. They apply to the entire project. For example, 'Editor' can read and write almost everything in the project. They are considered bad practice for most users because they violate the principle of least privilege; you should use 'predefined' or 'custom' roles instead.
CSEK is an older method where you, the customer, supply the encryption key directly to GCP when writing data, and GCP uses it to encrypt the data before storing it. You manage the entire lifecycle of the key outside of GCP. CMEK (Customer-Managed Encryption Keys) is the modern replacement, where the key is stored and managed inside Cloud KMS.
You've finished Securing and Governing Data on GCP. Continue through the PDE study guide to build a complete picture of the exam.
Done with this chapter?