Kms Symmetric Asymmetric Key Lifecycle Cicd

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.

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.

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.

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.

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.

Professional Cloud DevOps Engineer

Kms Symmetric Asymmetric Key Lifecycle Cicd

Related questions