Sensitive Data Protection (Cloud DLP) Study Notes

Sensitive Data Protection, formerly Cloud Data Loss Prevention (Cloud DLP), discovers, classifies, and protects sensitive data such as names, emails, and payment identifiers. It inspects content in Cloud Storage, BigQuery, Datastore, files, and streams, and can redact or de-identify what it finds.

Key facts

• Built-in infoTypes are detectors for common sensitive patterns, including email addresses, phone numbers, credit card numbers, and many country-specific identifiers.
• Inspection templates store reusable configuration: which infoTypes to look for, likelihood thresholds, and limits, so jobs stay consistent across projects.
• Findings report the infoType, likelihood from very unlikely to very likely, and location of the match, without needing to expose more data than necessary.
• De-identification transformations include redaction, masking with characters, hashing, shifting dates, and tokenization including format-preserving encryption.
• Data profiles automatically scan BigQuery tables, Cloud Storage buckets, and Datastore at organization, folder, or project level to map where sensitive data lives.
• Risk analysis jobs compute statistical metrics such as k-anonymity and l-diversity to judge how re-identifiable a structured dataset is.
• Custom infoTypes can be built from regular expressions, dictionaries, or stored detectors for organization-specific identifiers such as internal account numbers.
• DLP jobs can run on schedules or triggers, and results can be saved to BigQuery for reporting and alerting through other Google Cloud tools.
• Discovery and inspection are separate from enforcement in other products; DLP finds and transforms data, while access itself is still governed by IAM.

What the exam expects you to know

• Choose Sensitive Data Protection when a scenario asks to find or classify personally identifiable information across BigQuery or Cloud Storage.
• Use redaction or masking to remove sensitive values before data is shared with analysts, support teams, or lower environments.
• Apply format-preserving encryption or tokenization when downstream systems still need values in the same shape, such as card-like numbers.
• Set likelihood thresholds and quote limits thoughtfully to balance detection coverage against false positives in noisy datasets.
• Prefer inspection and de-identification templates for repeatable pipelines instead of one-off job configurations.
• Use data profiles to answer governance questions about which tables contain high-sensitivity columns before granting wider access.

Sensitive Data Protection (Cloud DLP) vs Cloud KMS: when to use which

Use Sensitive Data Protection when you need to discover what sensitive data you hold and transform the values themselves through redaction, masking, or tokenization. Use Cloud KMS when you need to manage encryption keys that protect data at rest or encrypt payloads, without inspecting content for meaning. DLP works at the data-content layer and understands patterns like passport numbers; KMS works at the cryptographic layer and treats input as bytes. A scenario saying 'find and mask credit card numbers in this table' is DLP; 'encrypt this table with a customer-managed key' is KMS. See also the Cloud KMS notes.

Useful gcloud commands

gcloud dlp inspect-templates list --project=PROJECT_ID
gcloud dlp jobs list --project=PROJECT_ID
gcloud dlp text inspect --project=PROJECT_ID --info-types=EMAIL_ADDRESS,PHONE_NUMBER --content="Contact alice@example.com"

Common exam traps

• DLP findings are probabilistic and based on likelihood; a possible match is not proof, and thresholds must be tuned to the use case.
• Inspecting data does not automatically delete or move it; protection happens only when a de-identification job or pipeline acts on findings.
• Hashing a low-variety value such as a small set of codes may still be reversible by guessing, so hashing alone is not always strong de-identification.
• Data Loss Prevention is the historical name; exam and console wording may use Sensitive Data Protection for the same underlying service.

Frequently asked questions

What is an infoType in Sensitive Data Protection?

An infoType is a detector definition for one kind of sensitive data, such as a US passport number or an email address. Inspection jobs combine selected infoTypes with likelihood thresholds to scan content. Google provides many built-in infoTypes, and you can add custom ones using patterns or word lists for internal identifiers.

What is the difference between redaction and masking?

Redaction removes the sensitive value entirely or replaces the whole match with a fixed marker, so nothing of the original remains. Masking hides only part of the value, typically replacing characters with symbols while leaving some characters visible for recognition. Masking suits support screens; redaction suits exports and logs.

Can DLP scan data automatically across a whole organization?

Yes, data profiling and discovery scans can be configured at organization or folder level to profile BigQuery, Cloud Storage, and Datastore resources continuously. Results classify tables and files by sensitivity and risk, helping teams prioritize remediation. This is the fastest way to answer where sensitive data exists at scale.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.