A customer needs an alternative to storing their plain text secrets in their source-code management (SCM) system. How should the customer achieve this using Google Cloud Platform?

Storing plain text secrets in source code is a major security risk. The best practice is to store secrets externally and retrieve them at runtime. Encrypting the secrets with a Customer-Managed Encryption Key (CMEK) via Cloud KMS and storing the resulting ciphertext in a controlled-access location like Cloud Storage is a secure pattern. The application's service account would be granted IAM permissions to decrypt the secret using the key, but the secret itself is never stored in plaintext in the code repository. This separates the secret from the code and enforces access control.

A. Storing secrets in Cloud SQL without encryption is just moving the plain text secret to a different location; it doesn't solve the core problem.
C. Cloud Data Loss Prevention (DLP) is used for discovering and classifying sensitive data, not for securely storing and managing application secrets.
D. The choice of VM type (preemptible) and storage (local SSD) is irrelevant to the secure management of application secrets within a code repository.

1. Google Cloud Documentation

"Secret management"

Section: "Best practices". This guide recommends storing secrets in a dedicated system like Secret Manager or

for a manual approach

using Cloud KMS for encryption and Cloud Storage for the encrypted blob.

2. Google Cloud Documentation

"Customer-managed encryption keys (CMEK)"

Section: "When to use CMEK". This document explains how CMEK gives customers control over the keys used to encrypt data at rest in services like Cloud Storage.

3. Google Cloud Documentation

"Using Cloud KMS with other services". This page details the integration pattern of using Cloud KMS to encrypt data before storing it in another service like Cloud Storage.