Designing for security and compliance · Topic 2 of 5
Encryption Keys, Secrets and Data Protection
Default encryption, CMEK with Cloud KMS, Cloud HSM, Cloud EKM, CSEK, Secret Manager and Sensitive Data Protection for discovery, masking and de-identification.
- 4 min
- Default encryption always; CMEK for control; Cloud HSM for hardware; Cloud EKM for keys outside Google.
- CSEK works only for Cloud Storage and Compute Engine.
- Secret Manager for secrets; better still, keyless and passwordless identity.
What it is
Google Cloud encrypts all data at rest by default. Architects decide who controls the keys, where secrets live, and how sensitive values such as card numbers or patient identifiers are found, masked or tokenized. Contracts and regulations often dictate these choices.
How it works
Key management options
| Option | Who holds the key | Fits |
|---|---|---|
| Google default encryption | Most data, no extra effort | |
| CMEK with Cloud KMS (software keys) | You manage keys in Cloud KMS | Control over rotation, disabling and access to keys |
| Cloud HSM | Keys in Google-operated FIPS 140-2 Level 3 hardware | Regulations that require hardware-protected keys |
| Cloud EKM | Keys in an external key manager outside Google | Contracts that require keys outside Google's infrastructure; withholding the key cuts off access |
| CSEK (customer-supplied keys) | You send the key with each request | Only Cloud Storage and Compute Engine disks |
Disabling or destroying a CMEK key makes the data it protects unreadable, which is how a customer "pulls the plug". Key Access Justifications with Cloud EKM show the reason for each key access request and let you deny it.
"Keys must live outside Google" means Cloud EKM. "Hardware security module" means Cloud HSM. CSEK does not cover BigQuery.
Key design practices
- Keep keys in a separate project managed by a security team (separation of duties).
- Use key rings in the same location as the data; regional data needs regional keys.
- Rotate keys on a schedule; Cloud KMS supports automatic rotation for symmetric keys.
- Grant the service agent of each service permission to use the key, nothing more.
Secret management
| Approach | Verdict |
|---|---|
| Passwords in code, images or Git | Never |
| Kubernetes Secrets in Git | Avoid; encrypting them does not remove them from Git |
| Secret Manager with IAM and versioning | Standard choice for secrets |
| No secret at all: IAM database authentication, Workload Identity Federation | Best when the service supports it |
GKE workloads can mount Secret Manager secrets through the Secret Manager add-on, authenticated with Workload Identity Federation for GKE. Cloud SQL supports IAM database authentication, removing database passwords altogether.
Sensitive Data Protection
Sensitive Data Protection (formerly Cloud DLP) finds and protects sensitive data:
| Capability | Use |
|---|---|
| Discovery | Automatically profile BigQuery, Cloud Storage and other data across an organization to show where sensitive data sits |
| Inspection | Scan specific content for infoTypes such as card numbers or names |
| De-identification | Mask, redact, replace or tokenize values |
| Deterministic encryption | Consistent reversible tokens, so data can still be joined and re-identified by key holders |
Column and row protection in BigQuery
| Need | Control |
|---|---|
| Hide or mask specific columns | Policy tags with Fine-Grained Reader, or data masking rules with Masked Reader |
| Show each group only its rows | Row-level access policies |
| Share results without raw rows | Authorized views, or data clean rooms with analysis rules |
How the exam asks about this
- "Hospitals require keys in a key manager outside Google." Cloud EKM as CMEK on each service.
- "Analysts must follow a vehicle across months but never read the VIN; a recall team can re-identify." Deterministic encryption with Sensitive Data Protection.
- "Masked columns for most analysts, real values for one team, dozens of tables, no copies." Policy tags with a masking rule.
What to remember for the exam
- Default encryption always; CMEK for control; Cloud HSM for hardware; Cloud EKM for keys outside Google.
- CSEK works only for Cloud Storage and Compute Engine.
- Secret Manager for secrets; better still, keyless and passwordless identity.
- Sensitive Data Protection discovers, inspects and de-identifies sensitive data.
- BigQuery: policy tags for columns, row-level policies for rows.
Encrypting secrets inside a Git repository still leaves credentials in Git. Audit findings that forbid secrets in Git need a secret store or passwordless authentication.
Common mistakes
Choosing CSEK for BigQuery. It is not supported.
Masked copies of tables when a policy-tag masking rule would serve masked values in place.
Infotype replacement when the data must still be joined or reversed.
Check yourself
Which option keeps encryption keys in an external key manager outside Google's infrastructure?
Cloud EKM.
How do GKE Pods read Secret Manager secrets without Kubernetes Secrets?
Mount them with the GKE Secret Manager add-on, authenticated with Workload Identity Federation for GKE.
Which Sensitive Data Protection method keeps tokens joinable and reversible?
Deterministic encryption.
Topic 2 of 5 in Designing for security and compliance
Test yourself on Designing for security and compliance
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.