GCP ACE Practice / Study guide / Topics / Data Protection: Encryption & Secret Manager
Data Protection: Encryption & Secret Manager
What actually gets tested on the Google Cloud Associate Cloud Engineer exam,
the traps to know, and 6 free sample questions with full explanations.
Google Cloud encrypts data at rest by default, universally, at no extra cost — a fact the exam expects you to know so you don't overcomplicate a scenario that doesn't actually need customer-managed keys. When a scenario does need more control, CMEK (customer-managed encryption keys, via Cloud KMS) gives you rotation, revocation, and IAM control over the key itself while Google still stores and uses it; CSEK (customer-supplied encryption keys) goes further — Google never stores your key at all, which means maximal control but also maximal operational burden: lose the key, and the data is unrecoverable.
Secret Manager exists because secrets — API keys, database passwords, tokens — don't belong in container images, config files, or a Git repository: images and repos both leak secrets to anyone with read access, and Git history keeps old commits around even after a secret is "removed" from the latest one. Secret Manager instead provides versioned, IAM-controlled, audit-logged secret storage with native integration into Cloud Run and GKE, so a workload can bind a secret at runtime (e.g. via --set-secrets on Cloud Run) without the value ever appearing in a config file or the image itself.
Put together, this topic is really about recognizing when the default is already sufficient (most scenarios) versus when a specific requirement — regulatory, contractual, "we must control our own keys" — pushes you toward CMEK or, rarely, the heavier CSEK. The exam rewards not over-engineering a security answer just as much as it rewards catching a genuine gap.
Exam tips for this topic
- Default encryption at rest is universal and free — don't reach for CMEK or CSEK unless the scenario specifically calls for customer control over the keys.
- CMEK = you control rotation/revocation/IAM on the key, Google still stores it; CSEK = you supply and hold the key entirely, so losing it means losing the data.
- Secrets belong in Secret Manager, bound at runtime — never in a container image, a config file, or committed to a Git repository, even one that's since had the secret "removed."
Sample questions — Data Protection: Encryption & Secret Manager
These 6 questions are drawn from our full bank of 658 to show the style and
depth you'll get in the app. Each comes with the full explanation you'd see after answering
in a real practice session.
Encryption
A customer asks whether the data your app stores on Google Cloud is encrypted, given that you never configured any encryption. Data at rest in Google Cloud is encrypted:
- Always, by default, with Google-managed keys — CMEK/CSEK are optional layers for customer controlCorrect
- Only if you enable encryption when creating each resource
- Only for customers on Enhanced or Premium support tiers
- Never unless you upload encrypted files
Why: Default encryption at rest is universal and free. CMEK gives you key control/rotation/revocation; CSEK (customer-supplied) means Google never stores your key. The exam loves 'default encryption' facts.
Secret Manager
Your app on Cloud Run needs a third-party API key at runtime. Recommended handling?
- Store it in Secret Manager and mount/expose it to the service (--set-secrets), granting the service account secretAccessorCorrect
- Bake it into the container image
- Commit it to git 'privately'
- Pass it in the public URL
Why: Secret Manager provides versioned, IAM-controlled, audited secret storage with native Cloud Run/GKE integration. Images, repos, and URLs all leak secrets to anyone with read access.
Encryption
Your compliance team asks you to compare the CMEK and CSEK encryption key options for a sensitive new workload. What is the difference?
- CMEK: keys live in Cloud KMS under your control; CSEK: you supply the raw key with each request and Google doesn't store itCorrect
- Both store keys in Cloud KMS; CSEK simply adds a second layer
- CSEK is the default for buckets; CMEK must be enabled per object
- CMEK disables encryption
Why: CMEK = managed control (rotation, IAM on keys, audit); CSEK = maximal customer possession with operational burden (lose the key, lose the data). Default remains Google-managed keys.
Secret Manager
A code review reveals that your team's Cloud Run service reads its database password from a plaintext environment variable defined in the deploy script, which is committed to the repository. You must fix this following Google-recommended practices, with an audit trail of secret access. What should you do?
- Move the password to Secret Manager, expose it to the service with --set-secrets, grant the service's SA roles/secretmanager.secretAccessor, rotate the password, and purge it from the repo historyCorrect
- Base64-encode the password in the script so it isn't plaintext
- Move the password to a different, private repository
- Rename the environment variable to something less obvious
Why: Secret Manager gives IAM-controlled, versioned, audit-logged secrets with native Cloud Run binding — and because the old password is burned into git history, rotation plus history purge is mandatory. Base64 is encoding, not encryption; private repos still leak to everyone with read access; renaming variables is security theater.
Encryption
A customer security questionnaire asks whether your traffic between Google Cloud services is encrypted in transit. The accurate answer is:
- Google encrypts/authenticates traffic between its facilities automatically; you add TLS at your app edges (LB certs, client TLS) as neededCorrect
- Exists only between regions, not within a single zone
- Requires you to configure IPsec tunnels between each pair of services
- Only applies to storage
Why: Google-internal links are protected by default (ALTS etc.); your responsibility is the app layer — HTTPS at the LB, TLS to databases, etc.
Secret Manager
You are reviewing a pull request that hardcodes the database password for your Cloud Run app in its deploy config. Where should that password live instead?
- Secret Manager, accessed at runtime by the service's SA with secretmanager.secretAccessorCorrect
- An environment variable committed in the deploy YAML in git
- A comment in the code
- A public bucket with an obscure name
Why: Secret Manager provides versioning, IAM, audit logging, and rotation hooks; runtime binding (--set-secrets) avoids exposing values in configs. Git history never forgets committed secrets.
Practice this for real
The app has dozens more questions on this and every other topic, with instant scoring,
spaced repetition of what you get wrong, and progress tracking across sessions.
Start practicing →
This topic shows up in
Other topics