Exam domain 3.3 tasks you with protecting the most sensitive data in a Google Cloud environment, which is where Secret Management and Data Loss Prevention come into play. This chapter will break down the core concepts: how to securely store and control access to credentials (like passwords and API keys) and how to automatically prevent sensitive data from being copied, shared, or leaked. For a Professional Cloud Security Engineer, mastering these tools is not optional — it is how you stop data breaches before they happen.
Jump to a section
A simple way to picture Secret Management and Data Loss Prevention
Have you ever left your credit card on the office kitchen counter and come back to find it gone? That sinking feeling is exactly what a company feels when its digital secrets are exposed. In a shared office, you keep your personal valuables locked in a drawer, not taped to the underside of the breakroom table. For a company, things like database passwords, API keys, and encryption keys are the valuables. Secret Manager is the digital equivalent of that secure, lockable drawer. It keeps secrets in a central, encrypted vault, and only gives them out to people or programs that have the right permission — a key, in a way. Meanwhile, Data Loss Prevention (DLP) is like the office manager who has a list of sensitive items that must never leave the building: printed customer lists, payroll spreadsheets, or the recipe for the office's famous coffee blend. DLP scans everything that tries to leave — emails, printouts, file uploads — and if it spots something sensitive, it blocks it, alerts the manager, or files the serial number off. Without these two systems, your company's secrets are just lying on the digital kitchen counter, and anyone could pocket them.
Let us start with the basics. Every application and service needs to talk to other services to operate. For example, your e-commerce website needs to connect to a payment processor. To do that, it uses a password or a secret key. In the past, developers would hard-code these secrets directly into their application code — a practice called 'hard-coding'. This is dangerous. If the code is ever shared, uploaded to a public code repository, or inspected by an attacker, that secret is instantly exposed.
Secret Manager is a Google Cloud service designed to solve this exact problem. It is a central, encrypted vault for storing sensitive data like database passwords, API keys, and TLS certificates. Instead of putting a password in your code, you store it in Secret Manager. Your application then requests the secret from Secret Manager when it needs it. Secret Manager encrypts the secret at rest and in transit. It also has fine-grained access control using Cloud IAM (Identity and Access Management). Cloud IAM is the system that defines who or what (which user, which application) has permission to access a given secret. You can give your web server permission to read a database password, but prevent a junior developer from even seeing that it exists. Secret Manager also supports versioning — you can have multiple versions of a secret (like a password that gets rotated every month) and your application can always point to the latest version.
Now, imagine a different problem. An employee at your company has financial data and customer credit card numbers in a spreadsheet. They are about to email it to their personal email address to work on at home. That is a data loss disaster waiting to happen. Data Loss Prevention (DLP) API is another Google Cloud service that helps you stop this. DLP is an intelligent inspection system. You give it content — a file, a piece of text, a database row — and it inspects that content using built-in detectors called 'infoTypes'. InfoTypes are pre-defined patterns that match sensitive data, such as credit card numbers, social security numbers, passport numbers, or medical record identifiers. DLP can be configured to automatically redact the sensitive data (replace it with asterisks), mask it (show only the last four digits), or fire off an alert to a security team.
Secret Manager and DLP solve different but complementary problems. Secret Manager stops secrets from leaking out of the code. DLP stops secrets from leaking out of the organisation. They are both essential to a defence-in-depth strategy — layering multiple security controls so that if one fails, another catches the problem. For the PCSE exam, you need to understand the use cases for each:
Secret Manager is used for storing and managing access to secrets that applications use.
DLP is used for inspecting and protecting data that is at rest (in a database or file) or in motion (being emailed or uploaded).
Both integrate with Cloud Logging and Cloud Monitoring for audit trails and alerting.
A common pattern is to combine them. For example, a healthcare application might use Secret Manager to store the password for its patient database, and use DLP to scan all patient records that are being exported to ensure no social security numbers are included in the export. Understanding these patterns is critical for the scenario-based questions on the exam.
Identify Secrets in Your Codebase
You must first find all hard-coded secrets (passwords, API keys, tokens) that currently exist in your application source code, configuration files, and environment variables. This is the discovery phase. Use grep, automated scanners, or manual review to compile a list.
Create a Secret in Secret Manager
Using the Google Cloud Console or the gcloud command-line tool, you create a new secret resource. You give it a name that describes its purpose (e.g., 'prod-db-password'). You then provide the secret value — the plaintext password or API key — which Secret Manager encrypts immediately using the Google Cloud default encryption or a customer-managed key from Cloud KMS.
Configure IAM Access Controls
You define which service accounts, users, or groups have permission to access the secret. Use Cloud IAM roles like 'Secret Manager Secret Accessor' for read access. Crucially, you apply the principle of least privilege — give each application only the permissions it specifically needs, nothing more.
Modify the Application to Fetch the Secret at Runtime
You update your application code to use the Secret Manager client library. Instead of reading a hard-coded value, the code makes an authenticated API call to Secret Manager to retrieve the current version of the secret. This means the secret is never stored in a file or environment variable on the server.
Set Up DLP Inspection Job for Sensitive Data
You create a DLP inspection job targeting your data sources (e.g., a Cloud Storage bucket, a BigQuery table, or a stream from Pub/Sub). You configure the relevant infoTypes — for example, CREDIT_CARD_NUMBER and US_DRIVERS_LICENSE_NUMBER. The job runs on a schedule and outputs findings to BigQuery or Cloud Logging.
Configure DLP De-identification Actions
You define what DLP should do when it finds sensitive data. Options include redaction (remove the data entirely), masking (show only a portion, like last four digits), tokenization (replace with a random token), and bucketing (group into ranges). You apply the most appropriate action based on your compliance requirements.
Monitor and Audit with Cloud Logging and Alerts
You set up Cloud Audit Logs to record every access to Secret Manager and every DLP inspection result. You create Cloud Monitoring alerts that trigger when, for example, a secret is accessed from an unusual location, or when DLP finds a high number of sensitive data matches. This step ensures you can detect and respond to incidents quickly.
Let us walk through a real scenario. You are the security engineer for a financial technology (fintech) startup that processes loan applications. Your application is built on Google Cloud. It collects sensitive customer data including bank account numbers, national identity numbers, and estimated annual income. The company's CTO has just read about a breach at a competitor — their database credentials were found in a public GitHub repository. You are tasked with ensuring this never happens to your company.
The first thing you do is identify all hard-coded secrets in your application code and move them into Secret Manager. You create a new Secret Manager secret for the production database password. You use the Cloud Console or gcloud command-line tool to create the secret entry. You then modify your application code to use the Secret Manager client library — instead of reading a password from a config file, it makes an API call to Secret Manager to get the current version of the secret. You also set up automatic rotation: every 30 days, a Cloud Function is triggered that generates a new password, updates the database with it, and then stores the new password as a new version in Secret Manager.
Next, you tackle the DLP part. Your customer support team often exports data from the database to run analytics. You need to prevent any sensitive fields from leaving. You create a DLP inspection job that runs weekly over the entire production database. The job uses built-in infoTypes like US_BANK_ROUTING_NUMBER and US_DRIVERS_LICENSE_NUMBER. You configure it to automatically redact those fields before the data is presented to the analyst. You also create a DLP job that scans outbound emails and attachments. If someone tries to email a spreadsheet containing a national identity number, DLP quarantines the email and sends an alert to your security team’s Slack channel.
Finally, you set up the IAM permissions. You create a service account for your web application and grant it the 'Secret Manager Secret Accessor' role for the database password secret. You grant a data analyst a more limited role that only allows them to view DLP job results, not to de-identify data. You use Cloud Audit Logs to monitor every access to Secret Manager and every DLP inspection result. You set up a monitoring dashboard that shows any IAM policy changes to these services. The end result is a layered security architecture: your secrets are stored in a secure vault, and your data is inspected before it can leave. This protects both your customer trust and your company’s compliance with financial regulations.
The PCSE exam tests Secret Management and DLP specifically through scenario-based multiple-choice questions. You will be given a paragraph describing a business requirement — for example, 'A company needs to store database credentials securely and ensure they are rotated automatically' — and you will have to choose the correct Google Cloud service or configuration.
Here are the exam topics and the traps they set:
- Secret Manager vs. Cloud KMS: This is the most common confusion area. Secret Manager stores arbitrary secrets (passwords, API keys). Cloud KMS creates and manages cryptographic keys used for encrypting and decrypting data. The exam will describe a scenario where you need to encrypt a file; the correct answer is Cloud KMS, not Secret Manager. Conversely, if the scenario is about storing a database password, the answer is Secret Manager. - DLP Inspection vs. De-identification: DLP offers two broad modes: inspection (just finding the sensitive data) and de-identification (actually changing the data by redacting, masking, or tokenizing it). The exam might ask: 'Which DLP action should be used to completely remove a credit card number from a log file?' The correct answer is redaction. - IAM Roles for Secret Manager: The exam loves testing the principle of least privilege. They will give you roles like 'Secret Manager Admin', 'Secret Manager Secret Accessor', and 'Secret Manager Viewer'. The trap is choosing an over-permissive role. The correct pattern is to give a service account only 'Secret Accessor' (the least privilege to read a secret). - Automatic Rotation: They will test that Secret Manager supports manual and automated rotation. The key detail is that Secret Manager does not rotate the secret itself; it only stores versions. You must use a separate tool (like a Cloud Function or a third-party solution) to actually perform the rotation. - DLP InfoTypes: Memorise the most common infoTypes: CREDIT_CARD_NUMBER, US_SOCIAL_SECURITY_NUMBER, EMAIL_ADDRESS, PHONE_NUMBER. The exam will ask which infoType you would use to detect a specific piece of data. - De-identification Techniques: The exam will distinguish between masking, redaction, tokenization, and bucketing. Masking shows part of the data (e.g., last four digits). Redaction removes it entirely. Tokenization replaces it with a random token. Bucketing groups data into ranges (e.g., age 20-30). Be ready to pick the correct technique for a given requirement. - Logging and Monitoring: The exam will ask about how to audit access to secrets or DLP actions. The correct answer is to use Cloud Audit Logs and Cloud Monitoring alerts. They love testing that Secret Manager access is logged by default.
The trap questions often combine multiple services. For example, 'Your application needs to encrypt a file before storing it in Cloud Storage, and you also need to store the encryption key securely. Which two services do you use?' The answer is Cloud KMS (to create the key) and Secret Manager (to store the key securely), or sometimes Cloud KMS alone if the key is managed within KMS. Read the scenario carefully — if it says 'store the key', it is Secret Manager; if it says 'create and manage the key', it is Cloud KMS.
Secret Manager is for storing and controlling access to small secrets like passwords, API keys, and TLS certificates — it is not a key management service.
Cloud KMS (Key Management Service) is for creating, storing, and managing cryptographic keys used for encryption — it is not a general-purpose password vault.
DLP (Data Loss Prevention) API inspects content for sensitive data using built-in infoTypes and can redact, mask, tokenize, or alert on matches.
Secret Manager supports versioning so you can rotate secrets and have applications always use the latest version without code changes.
DLP is not a firewall — it is a content inspection service that should be part of a layered security strategy, not the only defence.
When you need to audit access to secrets, look to Cloud Audit Logs — Secret Manager logs all access by default.
DLP can inspect data at rest (databases, files), in use (memory streams), and in motion (emails, API responses) depending on how you deploy it.
The principle of least privilege applies to both services: give service accounts only the exact roles they need (e.g., 'Secret Accessor' not 'Secret Manager Admin').
These come up on the exam all the time. Here's how to tell them apart.
Secret Manager
Stores arbitrary byte strings (passwords, API keys, certificates) as secrets.
Maximum secret size is 64 KB.
Does not create or rotate secrets automatically; it only stores versions.
Cloud KMS
Creates, manages, and rotates cryptographic keys used for encryption/decryption.
Handles key material; the keys themselves are not typically used as application passwords.
Supports automatic key rotation based on a schedule you define.
DLP Inspection
Scans content to find and report sensitive data matches.
Does not alter the original data; only produces findings.
Used for auditing and discovering where sensitive data resides.
DLP De-identification
Transforms the content by redacting, masking, tokenizing, or bucketing sensitive data.
Modifies the data permanently (or produces a new de-identified copy).
Used to protect data before sharing or exporting.
Secret Manager Secret Accessor Role
Grants permission only to read the payload of a secret.
Cannot create, delete, or manage versions of secrets.
Is the least privileged role for a service that needs to read a secret.
Secret Manager Admin Role
Grants full control over secrets: create, read, update, delete, and manage IAM policies.
Should be reserved for a small number of security administrators.
Is over-permissive if assigned to an application service account.
DLP Redaction
Completely removes the sensitive data and replaces it with a placeholder (e.g., '[REDACTED]').
Irreversible — the original value is lost.
Useful for logs or documents where the data must not appear at all.
DLP Masking
Shows only a portion of the data (e.g., last four digits of a credit card: 'XXXX-XXXX-XXXX-1234').
Irreversible in the sense that the full number is not recoverable, but provides some context.
Useful for customer-facing displays or reports where partial data is acceptable.
Cloud Logging for Secret Manager
Logs every access to a secret (read, list, create, update, delete) by default.
Audit logs show which principal accessed which secret and when.
Useful for detecting unauthorised access attempts to secrets.
Cloud Logging for DLP
Logs job configuration, inspection results, and actions taken (redaction, masking).
Findings can be exported to BigQuery or Cloud Monitoring for analysis.
Useful for compliance reporting and proving that sensitive data is being protected.
Mistake
Secret Manager and Cloud KMS are the same thing — they both store secrets.
Correct
Secret Manager stores arbitrary byte strings like passwords and API keys. Cloud KMS is for creating, storing, and managing cryptographic keys used to encrypt and decrypt data. They are different services for different purposes.
Both involve the concept of 'secrets' and 'encryption', so beginners conflate them. The exam deliberately tests this distinction.
Mistake
Once you store a secret in Secret Manager, Google Cloud automatically rotates it for you.
Correct
Secret Manager stores versions of secrets but does not automatically generate new versions. You must use a Cloud Function, Cloud Scheduler, or an external tool to rotate the secret and upload the new version.
Beginners expect a 'set it and forget it' service. The exam tests that you understand Secret Manager's scope: storage and access control, not generation or rotation of the secret content.
Mistake
DLP can only scan data that is stored in Google Cloud (Cloud Storage, BigQuery etc.).
Correct
DLP can scan data from multiple sources, including on-premises systems via the API, and data streams like Pub/Sub or streaming analytics. It is not limited to Google Cloud storage.
Beginners think of DLP as a Google Cloud-only tool. The exam questions often describe hybrid or multi-cloud scenarios, and DLP's API can be called from anywhere.
Mistake
Using DLP means you never have to worry about data leakage again — it is a complete solution.
Correct
DLP is a powerful inspection and de-identification tool, but it is not a firewall. It can miss data if the infoType is not configured, or if data is exfiltrated through a channel not monitored by DLP (e.g., encrypted traffic). It is one layer in a defence-in-depth strategy.
Beginners want a single magic solution. The exam emphasises a layered approach, so they test that you understand DLP's limitations.
Mistake
You can use Secret Manager to encrypt files directly — just upload the file as a secret.
Correct
Secret Manager has a maximum secret size of 64 KB. It is not designed for storing files or large data objects. For encrypting files, you use Cloud KMS to manage encryption keys and then encrypt the file client-side or with Cloud Storage server-side encryption.
This misconception arises because people think 'if it's a secret, it goes in Secret Manager'. The size limit catches beginners off guard in exam scenarios.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Secret Manager stores small secrets like passwords and API keys. Cloud KMS is for creating and managing cryptographic keys that you use to encrypt your own data. They are complementary services: you can use Cloud KMS to encrypt the contents of a secret in Secret Manager if you want customer-managed encryption keys.
No. Secret Manager stores versions of a secret but does not generate new values. You need to use Cloud Functions, Cloud Scheduler, or an external tool to create a new secret value and upload it as a new version. Secret Manager will then serve the latest version to authorised callers.
DLP cannot inspect encrypted data directly because it cannot read the plaintext. You must decrypt the data before sending it to DLP for inspection, or use DLP's built-in support for inspecting Cloud Storage objects that are encrypted with Cloud KMS (DLP can call Cloud KMS to decrypt for inspection).
An infoType is a pre-defined detector pattern that identifies a specific type of sensitive data, such as CREDIT_CARD_NUMBER, US_SOCIAL_SECURITY_NUMBER, or EMAIL_ADDRESS. You configure DLP jobs with the infoTypes relevant to your data to find matches.
Yes. Google Cloud Console offers a visual interface to create DLP jobs for inspecting content in Cloud Storage, BigQuery, and Cloud Datastore. You can also use the DLP API programmatically. For most simple use cases, the console is sufficient.
Tokenization replaces the original sensitive value with a randomly generated token (a placeholder) that has no meaningful relationship to the original data. Masking only shows a portion of the data (e.g., last four digits of a credit card). Tokenization allows you to retain referential integrity (the token can be reversed if needed), while masking is a one-way obfuscation.
Yes, the maximum secret size is 64 KB. This limit exists because Secret Manager is designed for small, sensitive data (passwords, keys, certificates), not for storing large files or entire configuration documents. For storing larger secrets, consider breaking them into parts or using a different storage solution.
You've finished Secret Management and Data Loss Prevention. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?