Cloud Digital Leader Google Cloud Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud Storage with encryption

  Why it's wrong here

  Cloud Storage is an object storage service for holding arbitrary binary files, not a secret management system. While you can enable default encryption at rest or use customer-managed encryption keys (CMEK), this only protects the ciphertext of the stored object; it does not address the critical requirement to securely inject API keys into applications, enforce fine-grained IAM permissions on individual secrets, or maintain a versioned history of secret material with automatic rotation. Moreover, Cloud Storage objects are meant to be read as files, and any application with storage.objectViewer access gets unencrypted plaintext directly, which expands the attack surface compared to a dedicated secret store.

• ✗

  Cloud KMS

  Why it's wrong here

  Cloud KMS is a key management service that creates, stores, and uses cryptographic key material to encrypt or sign data. It does not store secrets such as API keys or database passwords—only the keys used to protect other data. Even if you encrypt a secret with a Cloud KMS key and store the resulting ciphertext elsewhere, the plaintext secret must be separately managed, and Cloud KMS has no concept of secret versions, secret rotation policies, or secret-specific audit logging that tracks who accessed the plaintext value. Its role is to manage encryption keys, not to act as a vault for application credentials.

• ✗

  Cloud HSM

  Why it's wrong here

  Cloud HSM provides a FIPS 140-2 Level 3 validated hardware security module that performs cryptographic operations using keys that never leave the HSM boundary. It is even more specialized than Cloud KMS: it focuses on the secure generation and usage of asymmetric or symmetric encryption keys in tamper-resistant hardware, and it does not offer any service-level API to store, version, or retrieve application secrets like API keys or passwords. Attempting to use Cloud HSM as a secret store would require you to manage plaintext secrets separately, inherit none of Secret Manager's rotation or access-audit features, and unnecessarily complicate your architecture with low-level PKCS#11 or KMSP operations.

• ✓

  Secret Manager

  Why this is correct

  Secret Manager is the purpose-built Google Cloud service for storing API keys, database passwords, certificates, and other sensitive configuration data. It maintains immutable secret versions, supports granular IAM roles and conditions (e.g., accessor, giver, view access to a specific secret version), and is natively integrated with Cloud Audit Logs so every access to a secret's plaintext is recorded. You can automate rotation by using Cloud Functions or Cloud Scheduler to regenerate the secret value and add a new version, and then grant applications access only to the active version. It is the only option here that directly satisfies the requirements for secure storage, rotation, and auditing of manage to manage runtime secrets.

Go deeper

Related to this question