Files
kodekloud-engineer/terraform/task-24.md

3.7 KiB

Assignment

The Nautilus DevOps team needs to store sensitive data securely using AWS Secrets Manager. They need to create a secret with the following specifications:

  1. The secret name should be xfusion-secret.

  2. The secret value should contain a key-value pair with username: admin and password: Namin123.

  3. Use Terraform to create the secret in AWS Secrets Manager.

The Terraform working directory is /home/bob/terraform. Create the main.tf file (do not create a different .tf file) to accomplish this task.

Note: Right-click under the EXPLORER section in VS Code and select Open in Integrated Terminal to launch the terminal.

Solution

Secrets Manager — xfusion-secret

Terraform solution to create an AWS Secrets Manager secret holding a username/password key-value pair.

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_secretsmanager_secret" "xfusion" {
  name = "xfusion-secret"
}

resource "aws_secretsmanager_secret_version" "xfusion" {
  secret_id = aws_secretsmanager_secret.xfusion.id

  secret_string = jsonencode({
    username = "admin"
    password = "Namin123"
  })
}

How to run

cd /home/bob/terraform
terraform init
terraform apply -auto-approve

How it works

Secrets Manager splits a secret into two parts, and Terraform mirrors that with two resources:

aws_secretsmanager_secret

The container / metadata — the named secret itself. It holds the name, optional description, KMS key, rotation config, and resource policy, but not the secret value.

  • name = "xfusion-secret" — the secret name, exactly as required.
  • No KMS key is specified, so Secrets Manager encrypts the value with the AWS-managed aws/secretsmanager key by default — sufficient for the task.

aws_secretsmanager_secret_version

The actual value. Secrets are versioned; every value you store is a version, and one is marked AWSCURRENT. This resource writes that current version.

  • secret_id = aws_secretsmanager_secret.xfusion.id — links the version to its parent secret. Referencing the attribute (not hardcoding) creates the implicit dependency so the container is created before the version is written into it.
  • secret_string — the payload. The task wants a key-value pair, which in Secrets Manager means a JSON object string. jsonencode({ username = "admin", password = "Namin123" }) produces {"username":"admin","password":"Namin123"}. Using jsonencode (rather than hand-writing the JSON string) guarantees valid escaping and is the idiomatic way to store structured secrets — it's also the format the Secrets Manager console renders as separate key/value rows.

Why JSON and not two plain values

Secrets Manager stores a single SecretString per version. To hold multiple fields (username and password), you encode them as one JSON object. That's the standard pattern and what lets the console and SDKs pull individual keys (e.g. via --query SecretString then JSON parse). Storing raw admin / Namin123 as two separate things isn't possible — it's one string field, so JSON is the correct container.

Sandbox note

Secrets Manager basic operations (create secret, store value) are permitted. Advanced features — automatic rotation and cross-region replication — are blocked in these sandboxes, but this task uses neither, so it proceeds without issue.

Verify

aws secretsmanager get-secret-value --secret-id xfusion-secret \
  --query 'SecretString' --output text

Expected — {"username":"admin","password":"Namin123"}.