Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
Your continuous integration and continuous deployment (CI/CD) pipelines use Google Cloud Key Management Service (Cloud KMS) to protect sensitive environment configuration files with symmetric encryption keys and sign build provenance attestations using asymmetric keys.
You need to establish an automated lifecycle and rotation policy that avoids pipeline and runtime service disruption, accommodates the behavioral differences between symmetric and asymmetric keys, and safely retires obsolete key versions.
What should you do?
Configure an automatic rotation schedule on both the symmetric and asymmetric keys, configure CI/CD tasks to reference only the root CryptoKey resource name without version numbers, and immediately destroy prior key versions once rotation occurs.
Pin all CI/CD symmetric decryption steps to explicit CryptoKeyVersion resource IDs, configure Cloud KMS to overwrite existing asymmetric private keys in place during rotation, and execute hard immediate deletes on deprecated key versions.
Configure an automatic rotation schedule for the symmetric encryption keys; create new key versions programmatically for asymmetric keys while distributing public keys to verification systems before pointing signing tasks to the new version; and disable prior key versions while monitoring audit logs before scheduling destruction.
Write a pipeline job that periodically deletes and recreates the Cloud KMS Key Ring, generates brand-new symmetric and asymmetric keys with identical names, and purges all historical key metadata to eliminate storage overhead.
Configure an automatic rotation schedule on both the symmetric and asymmetric keys, configure CI/CD tasks to reference only the root CryptoKey resource name without version numbers, and immediately destroy prior key versions once rotation occurs.
Pin all CI/CD symmetric decryption steps to explicit CryptoKeyVersion resource IDs, configure Cloud KMS to overwrite existing asymmetric private keys in place during rotation, and execute hard immediate deletes on deprecated key versions.
Configure an automatic rotation schedule for the symmetric encryption keys; create new key versions programmatically for asymmetric keys while distributing public keys to verification systems before pointing signing tasks to the new version; and disable prior key versions while monitoring audit logs before scheduling destruction.
This strategy aligns cryptographic key management with Cloud KMS design constraints by differentiating between symmetric and asymmetric key lifecycles, maintaining backward compatibility for decryption, and enforcing a phased retirement process for decommissioned keys.
This approach leverages native automated features where supported (symmetric rotation schedules) while implementing necessary orchestration for asymmetric keys and safe multi-step retirement (disable -> monitor -> schedule destruction), completely preventing pipeline outages.
Write a pipeline job that periodically deletes and recreates the Cloud KMS Key Ring, generates brand-new symmetric and asymmetric keys with identical names, and purges all historical key metadata to eliminate storage overhead.