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:
-
The secret name should be xfusion-secret.
-
The secret value should contain a key-value pair with username: admin and password: Namin123.
-
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/secretsmanagerkey 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"}. Usingjsonencode(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"}.