Examkin

Question

Difficulty: HardProvisioning Storage and Database Systems

An enterprise architecture team is automating the provisioning of managed relational database instances and object storage buckets using Infrastructure as Code (Terraform) within a multi-developer CI/CD pipeline. Corporate governance policies dictate that all storage and database assets must utilize key management controls where keys can be revoked or rotated within Google Cloud without requiring raw cryptographic keys to be handled or transmitted by developers. Additionally, the execution pipeline must prevent state file corruption during simultaneous deployments and safeguard infrastructure history against accidental deletions. Which TWO actions should the team implement in their provisioning configuration? (Select TWO.)

  1. Configure a Cloud Storage remote backend for Terraform with object versioning enabled and native state locking to ensure state integrity across automated runs.Answer
  2. Grant resource service accounts the Cloud KMS CryptoKey Encrypter/Decrypter role and pass the Customer-Managed Encryption Key (CMEK) resource IDs into the Terraform resource configurations.Answer
  3. C
    Supply raw 256-bit Customer-Supplied Encryption Keys (CSEK) as sensitive input variables in the Terraform module parameters to fulfill key governance without relying on Cloud KMS.
  4. D
    Store the Terraform state file in an unversioned local directory within the build container workspace to minimize API call latency during plan and apply steps.

Answer

The team should configure a Cloud Storage remote backend with object versioning and state locking for Terraform, and grant service accounts the Cloud KMS CryptoKey Encrypter/Decrypter role while specifying CMEK resource IDs in the resource definitions.
Configuring a Cloud Storage remote backend with state locking and object versioning ensures concurrent CI/CD pipeline runs cannot corrupt the Terraform state file, while enabling recovery of previous state versions. Using Customer-Managed Encryption Keys (CMEK) via Cloud KMS fulfills key governance requirements by enabling key lifecycle management and revocation within GCP without requiring developers to manage raw cryptographic key bytes.

Step-by-Step Solution

1
Evaluate state storage requirements for multi-developer CI/CD automated deployments.
Identify that a centralized Cloud Storage backend with versioning and object locking prevents state race conditions and enables rollback.
Unversioned local state files lead to concurrency collisions and state loss across ephemeral CI/CD containers.
2
Evaluate encryption requirements under corporate key governance policy.
Select Customer-Managed Encryption Keys (CMEK) via Cloud KMS instead of Customer-Supplied Encryption Keys (CSEK).
CMEK allows key management, rotation, and revocation within Google Cloud KMS without requiring developers to handle raw 256-bit keys.
3
Bind appropriate IAM roles to resource service accounts.
Grant roles/cloudkms.cryptoKeyEncrypterDecrypter to the database and storage service accounts for the designated CMEK key.
Services require explicit cryptographic permissions to encrypt and decrypt underlying persistent disks and storage objects upon provisioning.

Key Concept

Terraform State Management and CMEK Integration for Provisioned Infrastructure
Rate this question

Topics

Provisioning Storage and Database Systems

More questions from this topic