GCP Professional Cloud Security Engineer Practice Question

A financial-services company runs workloads in GKE clusters located in two separate production projects. All clusters must read the same third-party API key. Compliance mandates that:

the key is encrypted with a hardware-backed customer-managed key,
a new key is issued automatically every 30 days,
previous key material is retained for rollback but must not exist longer than 15 days,
workloads receive only read-only access to the secret. Which design satisfies all of these requirements?

Store the API key as a Kubernetes Secret in each cluster, enable application-layer secrets encryption with a software-protected Cloud KMS key, and run a cluster CronJob that rewrites the secret every 30 days and deletes prior versions after 15 days.
Upload the API key to a Cloud Storage bucket encrypted with a customer-supplied encryption key (CSEK), enable uniform bucket-level access, configure an object lifecycle rule to delete objects older than 15 days, and distribute new signed URLs to the clusters every 30 days.
Create a Secret Manager secret in a dedicated security project, encrypt it with a Cloud HSM-backed CMEK key, grant the Secret Manager Secret Accessor role to the GKE service accounts, and configure a 30-day rotation schedule that triggers a Cloud Function to add a new secret version and destroy versions older than 15 days.
Use Cloud Runtime Configurator to store the API key, protect it with a Cloud HSM key, and rely on the service's automatic variable refresh feature to rotate the value every 30 days while retaining prior versions for 15 days.

Report Issue

Answer Description

Secret Manager is designed for centralized, versioned storage of sensitive data and integrates with Cloud KMS for CMEK protection. By selecting a Cloud HSM-backed key ring, the secret is encrypted with hardware-backed keys that meet the compliance requirement. Secret Manager supports rotation schedules that publish to Pub/Sub; a Cloud Function (or Cloud Run job) subscribed to that topic can create a new secret version every 30 days and then destroy versions older than 15 days, keeping roll-back capability for up to 15 days. Granting only the Secret Manager Secret Accessor role to the service accounts used by the GKE workloads enforces least-privilege, read-only access.

The other options fail one or more requirements:

Kubernetes Secrets (option B) are only base-64 encoded unless application-layer encryption is configured; even then they are protected by a software key and are project-local, so they do not provide hardware-backed encryption or centralized access across projects.
Storing the key in Cloud Storage with CSEK and signed URLs (option C) does not enforce read-only IAM-based access or automatic rotation, and CSEK is not hardware-backed.
Cloud Runtime Configurator (option D) has no native CMEK or rotation feature and is not recommended for new workloads, so it cannot meet the encryption or rotation requirements.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.