# 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`

```hcl
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

```bash
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

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

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