Manage Secrets with AWS Secrets Manager

Store and manage app secrets securely using the AWS CLI.

Introduction

30 Second Summary

Every application needs credentials to connect to databases, APIs, and external services. Storing those passwords and keys directly in your code is one of the most common security mistakes in software development.

In this project, you will use the AWS CLI to store, retrieve, update, and delete secrets in AWS Secrets Manager. You'll build a complete secrets management workflow that replaces hardcoded credentials with secure, versioned, and organized secret storage.

What You'll Build

A secrets management workflow using the AWS CLI that securely stores and organizes application credentials across development environments.

By the end of this project, you'll have:

  • Multiple secrets stored in AWS Secrets Manager, organized by environment using path-style naming conventions.
  • Hands-on experience creating, retrieving, updating, versioning, and tagging secrets through the AWS CLI.
  • A cleanup workflow demonstrating secret deletion with recovery windows and immediate force-deletion.
  • Secret Mission: Set up automatic rotation for one of your secrets using a Lambda function.

Are there any prerequisites?

You'll need an AWS account with administrative access. If you don't have one yet, you can create a free account at aws.amazon.com. New AWS accounts created after July 15, 2025 receive up to $200 in Free Tier credits applicable to Secrets Manager.

Set Up the AWS CLI

Before you can manage secrets in AWS, you need a way to talk to AWS from your computer. The AWS CLI (Command Line Interface) lets you run commands that interact with AWS services directly from your terminal.

In this step, you'll install the AWS CLI, connect it to your AWS account, and confirm the connection works.

In this step, get ready to:
  • Install the AWS CLI v2 on your machine.
  • Configure the CLI with your AWS credentials.
  • Verify your connection to AWS.
Install the AWS CLI v2

The AWS CLI v2 is the tool you'll use to create, retrieve, and manage secrets throughout this project. Let's check if it's already installed on your machine.

  • Open a command prompt by pressing the Windows key, typing cmd, and pressing Enter.
  • Check if the AWS CLI is installed by running:
aws --version

✔️ I see aws-cli/2.x.x

Your output shows a version starting with aws-cli/2. followed by additional details like your Python version and operating system.

As long as the version starts with 2., you're good to go. Skip ahead to the next substep.

ⓧ I see aws-cli/1.x.x

You have an older version (v1) installed. Version 2 includes features this project needs that are not available in version 1.

  • Download the AWS CLI v2 installer for Windows from this link:
  • https://awscli.amazonaws.com/AWSCLIV2.msi
  • Run the downloaded AWSCLIV2.msi file and follow the installer prompts (accept the defaults).
  • Close your current command prompt and open a new one.
  • Run aws --version again to confirm you now see a version starting with 2..

What about version 1?

The v2 installer replaces version 1 automatically. Both versions use the same aws command name, so the new installer overwrites the old one.

ⓧ Command not found

The AWS CLI is not installed yet. Let's install it now.

  • Download the AWS CLI v2 installer for Windows from this link:
  • https://awscli.amazonaws.com/AWSCLIV2.msi
  • Run the downloaded AWSCLIV2.msi file and follow the installer prompts (accept the defaults).
  • Close your current command prompt and open a new one.
  • Verify the installation by running:
aws --version

You should see output starting with aws-cli/2. followed by version details.

Still seeing an error after installing?

Make sure you closed the old command prompt and opened a fresh one. The PATH update from the installer only takes effect in new terminal sessions.

If you still see an error, try restarting your computer and running aws --version again.

help me troubleshoot my AWS CLI installation

Configure the AWS CLI with your credentials

Now that the CLI is installed, you need to tell it who you are. The aws configure command sets up your credentials so every command you run is authenticated against your AWS account.

  • Start the configuration wizard by running:
aws configure

What does aws configure ask for?

The wizard prompts you for four values, one at a time:

  • AWS Access Key ID and AWS Secret Access Key identify your IAM user. You create these in the AWS Console under your IAM user's security credentials.
  • Default region name sets which AWS region your commands target (e.g. us-east-1).
  • Default output format controls how results are displayed. Enter json for readable, structured output.
  • When prompted for AWS Access Key ID, paste your Access Key ID and press Enter.
  • When prompted for AWS Secret Access Key, paste your Secret Access Key and press Enter.
  • When prompted for Default region name, type us-east-1 and press Enter.
  • When prompted for Default output format, type json and press Enter.

Where do I find my Access Key ID and Secret Access Key?

In the AWS Console, navigate to IAM, then Users. Select your user and click the Security credentials tab.

Click Create access key. Copy both the Access Key ID and Secret Access Key immediately. The Secret Access Key is only shown once at creation time.

Made a typo during configuration?

Run aws configure again. It will show your current values in brackets. Press Enter to keep a value unchanged, or type a new value to overwrite it.

help me fix my AWS CLI configuration

Verify your CLI access works

The final check confirms your credentials are valid and your CLI can communicate with AWS.

  • Verify your identity by running:
aws sts get-caller-identity

What does this command do?

This command asks AWS "who am I?" and returns your account details. A successful response proves your credentials are correctly configured and your CLI can reach AWS.

You should see JSON output containing three fields: UserId, Account (your 12-digit AWS account number), and Arn (your user's Amazon Resource Name).

Your output looks similar to this (with your own account details):

{
    "UserId": "AIDASAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/YourUserName"
}

Seeing an access denied or credentials error?

Double-check that you pasted the correct Access Key ID and Secret Access Key during aws configure. A single extra space or missing character will cause authentication to fail.

Also confirm that your IAM user has the SecretsManagerReadWrite managed policy attached (or administrative access). Without sufficient permissions, later commands in this project will fail.

help me fix my AWS CLI credentials error

Your CLI is connected and ready to go. Next up, you'll use it to create your first secret in AWS Secrets Manager.

Create Your First Secret

Your CLI is connected to AWS and ready to go. Now it's time to store your first secrets in AWS Secrets Manager.

Hardcoded credentials in source code are one of the most common security vulnerabilities. Secrets Manager gives you a central, encrypted vault where your application can retrieve credentials at runtime instead of reading them from config files checked into version control.

In this step, get ready to:
  • Create an API key secret with JSON key/value pairs.
  • Create a database credentials secret.
  • Confirm both secrets exist in your account.
Store your API key credentials

In a real application, you'd have API keys for third-party services like payment processors, email providers, or analytics tools. Instead of pasting these directly into your code, you'll store them as a secret in Secrets Manager.

  • Create your first secret by running this command:
aws secretsmanager create-secret --name myapp/dev/api-key --description "Development API key for MyApp" --secret-string "{\"api_key\":\"dev-key-abc123\",\"api_secret\":\"dev-secret-xyz789\"}"

What does this command do?

  • --name myapp/dev/api-key sets a path-style name that organizes secrets by application, environment, and purpose.
  • --description adds a human-readable note so your team knows what this secret is for.
  • --secret-string stores the actual credential as a JSON key/value pair. Secrets Manager recommends JSON format so applications can parse individual fields.

The path-style naming convention myapp/dev/api-key mirrors real-world practice. It lets you filter secrets by application or environment later.

You should see a JSON response containing an ARN, Name, and VersionId confirming the secret was created.

What is an ARN?

An ARN (Amazon Resource Name) is the unique identifier AWS assigns to every resource. It includes the service name, region, account ID, and resource path. You'll see ARNs throughout AWS whenever you need to reference a specific resource.

Seeing an AccessDeniedException?

Your IAM user needs the SecretsManagerReadWrite managed policy attached. Check with your AWS account administrator or attach the policy yourself in the IAM console under your user's permissions.

Also confirm your CLI region is set correctly. Run aws configure get region to check.

Help me fix this permissions error in AWS Secrets Manager.

Store your database credentials

Database credentials are another common secret that should never live in source code. This second secret stores a full connection string's worth of fields.

  • Create your database credentials secret by running this command:
aws secretsmanager create-secret --name myapp/dev/db-credentials --description "Development database credentials" --secret-string "{\"username\":\"devuser\",\"password\":\"DevPass123!\",\"host\":\"dev-db.example.com\",\"port\":\"5432\"}"

What's different about this secret?

This secret stores four fields: username, password, host, and port. Your application can parse the JSON and extract only the fields it needs at runtime.

Secrets Manager automatically encrypts this value at rest using the aws/secretsmanager KMS key at no extra cost.

You should see the same response structure as before: an ARN, Name, and VersionId for the new secret.

Getting a ResourceExistsException?

This means a secret with the name myapp/dev/db-credentials already exists in your account. If you ran the command twice by mistake, you can continue to the next substep.

Help me resolve this duplicate secret error.

Confirm your secrets were created
  • List all secrets in your account by running this command:
aws secretsmanager list-secrets

You should see a SecretList array containing both myapp/dev/api-key and myapp/dev/db-credentials. Each entry shows metadata like the name, description, ARN, and creation date.

Why no secret values in this output?

The list-secrets command returns metadata only. It never exposes the actual secret values. This is a security design choice. You need a separate, explicit command to retrieve the decrypted value.

Only seeing one secret?

Scroll up in your terminal to check if the first create-secret command returned an error. If so, re-run it. Both commands must succeed before continuing.

Help me figure out why my secret is missing.

You now have two secrets safely stored and encrypted in AWS. Next up, you'll learn how to retrieve and inspect these secrets using different query techniques.

Retrieve and Inspect Secrets

Your secrets are stored and encrypted in AWS Secrets Manager. Now you need to know how to retrieve them when your applications need the credentials.

In this step, you'll use three different retrieval approaches to get full secret values, extract specific fields, and inspect metadata without exposing the encrypted value.

In this step, get ready to:
  • Retrieve the full JSON response for a stored secret.
  • Extract just the secret string using query flags.
  • Inspect secret metadata without exposing the encrypted value.
Retrieve the full secret value

When an application needs credentials, it calls Secrets Manager to retrieve the decrypted secret value at runtime. This means credentials never need to live in your source code.

  • Retrieve the full secret value of your API key secret by running this command:
aws secretsmanager get-secret-value --secret-id myapp/dev/api-key

What does this command do?

This command decrypts and returns the full secret, including metadata. The response includes:

  • ARN is the unique Amazon Resource Name identifying your secret.
  • SecretString contains your actual credentials as the JSON string you stored.
  • VersionStages shows AWSCURRENT, meaning this is the active version.
  • VersionId is a unique identifier for this specific version of the secret.

You should see a JSON response containing your ARN, Name, SecretString with your API key and secret, and VersionStages showing AWSCURRENT.

Seeing ResourceNotFoundException?

Double check the --secret-id value matches exactly what you used when creating the secret: myapp/dev/api-key. Secret names are case-sensitive.

If you see an AccessDeniedException, your IAM user may not have the secretsmanager:GetSecretValue permission. Confirm your user has the SecretsManagerReadWrite managed policy attached.

Help me debug a Secrets Manager retrieval error

Extract just the secret string

The full response includes metadata you don't always need. In scripts and automation, you often want just the secret value itself.

  • Extract only the secret string (without the surrounding metadata) by running this command:
aws secretsmanager get-secret-value --secret-id myapp/dev/api-key --query SecretString --output text

What do --query and --output do?

The --query SecretString flag uses JMESPath syntax to extract only the SecretString field from the response. The --output text flag strips the JSON formatting so you get a raw string.

This combination is useful for piping secret values into scripts or environment variables without needing to parse the full JSON response yourself.

You should see just your JSON credentials printed as raw text:

{"api_key":"dev-key-abc123","api_secret":"dev-secret-xyz789"}

Seeing the full JSON response instead?

Make sure you included both --query SecretString and --output text in your command. Without --output text, the value will still be wrapped in JSON quotes.

Help me extract just the secret string from my response

Inspect the secret metadata

Sometimes you need information about a secret (when it was last changed, which versions exist, whether rotation is enabled) without exposing the actual credentials.

  • Inspect your API key secret's metadata by running this command:
aws secretsmanager describe-secret --secret-id myapp/dev/api-key

What does describe-secret show?

This command returns metadata about the secret without ever decrypting or exposing the secret value. Key fields include:

  • ARN and Name identify the secret.
  • Description shows the description you set when creating the secret.
  • LastChangedDate tells you when the secret value was last updated.
  • VersionIdsToStages maps version IDs to their staging labels (like AWSCURRENT).

This is safe to run in audit scripts or monitoring tools because the encrypted secret value is never included in the response.

You should see a JSON response showing your secret's ARN, name, description, creation date, last changed date, and a VersionIdsToStages map with one version labeled AWSCURRENT.

Not seeing VersionIdsToStages?

Secrets Manager only returns fields that have a value. If you don't see VersionIdsToStages in the output, check that your --secret-id matches myapp/dev/api-key exactly.

Help me understand my describe-secret output

You now know three ways to interact with a stored secret: full retrieval, targeted extraction, and metadata inspection. Next up, you'll update a secret and see how Secrets Manager handles versioning automatically.

Update a Secret and Explore Versioning

In the previous step, you retrieved and inspected your secrets using different query techniques.

In a real project, credentials change regularly. An API provider might issue new keys, a database password might expire, or your security team might require a rotation. AWS Secrets Manager handles this gracefully by automatically versioning every update. You never lose your previous credentials, and you can roll back if something breaks.

In this step, get ready to:
  • Update the API key secret with new credential values.
  • Retrieve both the current and previous versions of the secret.
  • List the version IDs tracked by Secrets Manager.
Update the API key secret with new values

Imagine your API provider just issued fresh credentials. You need to store the new values without losing the old ones in case you need to roll back.

  • Update the myapp/dev/api-key secret with new credentials by running this command:
aws secretsmanager put-secret-value --secret-id myapp/dev/api-key --secret-string "{\"api_key\":\"dev-key-NEW456\",\"api_secret\":\"dev-secret-NEW012\"}"

What does this command do?

The put-secret-value command creates a new version of an existing secret. It does not overwrite the old value. Instead, Secrets Manager labels the new value as AWSCURRENT and moves the previous value to AWSPREVIOUS.

This automatic versioning means you always have a safety net. If the new credentials cause issues, the previous version is still accessible.

  • You should see a JSON response containing the secret's ARN, Name, a new VersionId, and VersionStages showing AWSCURRENT.

Seeing an error?

  • If you see a ResourceNotFoundException, double check that the secret ID is exactly myapp/dev/api-key with no typos.
  • If you see a JSON parsing error, make sure all backslashes and quotes in the --secret-string value are correct. Copy the command directly from the code block above.

Help me fix my put-secret-value command

Retrieve the current and previous versions

Now that you have two versions of the same secret, you can retrieve either one by specifying its version stage.

  • Retrieve the current version of your secret by running this command:
aws secretsmanager get-secret-value --secret-id myapp/dev/api-key
  • Confirm the SecretString shows your new values: dev-key-NEW456 and dev-secret-NEW012.

Why didn't we specify a version stage?

When you omit the --version-stage flag, Secrets Manager defaults to AWSCURRENT. This is the version your applications will get when they request the secret.

  • Now retrieve the previous version by running this command:
aws secretsmanager get-secret-value --secret-id myapp/dev/api-key --version-stage AWSPREVIOUS
  • Confirm the SecretString shows your original values: dev-key-abc123 and dev-secret-xyz789.

What is happening with versioning?

Secrets Manager uses staging labels to track which version is which. AWSCURRENT always points to the latest version. AWSPREVIOUS always points to the version that was current before the last update.

This means if you update a secret and your application breaks, you can immediately retrieve the old credentials from AWSPREVIOUS without any manual backup system.

Getting a ResourceNotFoundException for AWSPREVIOUS?

The AWSPREVIOUS stage only exists after the first update. If you skipped the put-secret-value command in the previous substep, go back and run it first.

Why can't I retrieve the AWSPREVIOUS version of my secret?

List the version IDs for your secret

Each version of a secret gets a unique version ID. You can list all tracked versions to see the full history.

  • List all version IDs for the API key secret by running this command:
aws secretsmanager list-secret-version-ids --secret-id myapp/dev/api-key

What does this output show?

The response contains a Versions array. Each entry shows a VersionId (a unique identifier) and VersionStages (which labels are attached to that version).

You should see two entries. One is labeled AWSCURRENT (your new credentials) and one is labeled AWSPREVIOUS (your original credentials).

  • Confirm you see two version entries in the Versions array, each with a different VersionId and staging label.

Only seeing one version?

If you only see one version, the put-secret-value command from earlier may not have run successfully. Scroll up and check for any errors, then rerun it.

Help me understand why I only see one version of my secret

Your secrets now have a version history. Next up, you'll organize them with tags so you can filter and manage secrets across different environments and teams.

Organize Secrets with Tags

Your secrets now have versioning built in, giving you a safety net when credentials change. As your collection of secrets grows, you need a way to organize and filter them.

Tags are key-value pairs you attach to AWS resources. They help you categorize secrets by environment, team, or service. In this step, you'll tag both of your secrets and verify you can filter by those tags.

In this step, get ready to:
  • Tag your API key secret with environment and team labels.
  • Tag your database credentials with environment, team, and service labels.
  • Verify your tags by describing secrets and filtering by tag.
Tag your API key secret

In a real-world project, you might have dozens or hundreds of secrets spread across multiple environments. Tags let you label each secret with metadata like which environment it belongs to or which team owns it.

  • Add environment and team tags to your API key secret by running this command:
aws secretsmanager tag-resource --secret-id myapp/dev/api-key --tags Key=Environment,Value=Development Key=Team,Value=Backend

What does this command do?

  • tag-resource attaches key-value metadata to your secret. Tags are stored as part of the secret's metadata, not the encrypted value itself.
  • Key=Environment,Value=Development marks this as a development environment secret.
  • Key=Team,Value=Backend identifies which team owns this secret.
  • This command produces no output on success. If you see no error message, your tags were applied.

Seeing an error?

  • If you see ResourceNotFoundException, double check the secret name is exactly myapp/dev/api-key with forward slashes.
  • If you see AccessDeniedException, your IAM user may not have the secretsmanager:TagResource permission. Check that you're using the same credentials from Step 1.

Help me troubleshoot my tag-resource command

Tag your database credentials secret

Your database credentials connect to a specific service, so you'll add an extra tag identifying the database type.

  • Add environment, team, and service tags to your database credentials by running this command:
aws secretsmanager tag-resource --secret-id myapp/dev/db-credentials --tags Key=Environment,Value=Development Key=Team,Value=Backend Key=Service,Value=PostgreSQL

What does this command do?

This adds three tags to your database credentials secret. The first two tags match the API key secret for consistent organization. The extra Service=PostgreSQL tag identifies the specific service these credentials connect to.

Consistent tagging across secrets lets you filter and manage groups of related resources. For example, you could find all secrets belonging to the Backend team or all secrets tied to PostgreSQL.

  • Again, no output means success. If you see no error message, your three tags were applied.
Verify your tags

Now confirm the tags are in place. You'll use two different approaches to see them.

  • Inspect the metadata of your API key secret by running this command:
aws secretsmanager describe-secret --secret-id myapp/dev/api-key

What should I see?

The output includes a Tags section listing your two tags: Environment=Development and Team=Backend. You'll also see all the other metadata fields like Name, Description, and version information.

  • Filter your secrets list to show only secrets that have the Environment tag by running this command:
aws secretsmanager list-secrets --filter Key="tag-key",Values="Environment"

What should I see?

The output shows both myapp/dev/api-key and myapp/dev/db-credentials because both have the Environment tag. Only secrets with that tag key appear in the filtered results.

This filtering becomes essential in production when you have hundreds of secrets and need to quickly find all secrets for a specific environment or team.

Not seeing your tags in the output?

  • Make sure you ran the tag-resource commands from the earlier substeps without errors. If either command returned an error, re-run it.
  • Check the filter syntax carefully. The key must be tag-key (with a hyphen) and the value must match the tag key name exactly, including capitalization.

Help me figure out why my tags aren't showing up

Your secrets are now organized with tags for easy filtering and access control. Next up, you'll learn how to safely delete secrets and manage recovery windows.

Clean Up Your Secrets

Your secrets are now organized with meaningful tags for easy filtering and cost tracking. The final piece of managing secrets professionally is knowing how to decommission them safely when they're no longer needed.

AWS Secrets Manager offers two deletion strategies. A soft delete gives you a recovery window, while a hard delete is immediate and permanent.

In this step, get ready to:
  • Delete a secret with a 7-day recovery window.
  • Force-delete a secret permanently with no recovery possible.
  • Verify your secrets are removed from active listings.
Delete your API key secret with a recovery window
  • Delete the myapp/dev/api-key secret with a 7-day recovery window by running this command:
aws secretsmanager delete-secret --secret-id myapp/dev/api-key --recovery-window-in-days 7

What does this command do?

The --recovery-window-in-days 7 flag schedules the secret for deletion instead of destroying it immediately. You have 7 days to change your mind and restore the secret before it's permanently gone.

During this recovery window, the secret won't appear in normal listings and you won't be charged for it. If you need it back, you can restore it with aws secretsmanager restore-secret --secret-id myapp/dev/api-key.

  • You should see a JSON response containing ARN, Name, and DeletionDate fields confirming the deletion is scheduled.

Seeing an error?

  • If you see a "ResourceNotFoundException" error, double-check the secret name myapp/dev/api-key matches exactly what you created in Step 2.
  • If you see "InvalidParameterException", make sure the recovery window value is at least 7 (the minimum AWS allows).
  • help me troubleshoot my delete-secret command
Force-delete the database credentials secret
  • Delete the myapp/dev/db-credentials secret immediately with no recovery possible by running this command:
aws secretsmanager delete-secret --secret-id myapp/dev/db-credentials --force-delete-without-recovery

What does this command do?

The --force-delete-without-recovery flag skips the recovery window entirely. The secret is permanently destroyed the moment you run this command.

Use this option only when you're absolutely certain you won't need the secret again. There is no undo.

  • You should see a JSON response with ARN, Name, and DeletionDate fields confirming the secret has been deleted.

Command not working?

  • If you see "ResourceNotFoundException", check that the secret name myapp/dev/db-credentials is spelled correctly with the forward slashes.
  • If you see "AccessDeniedException", your IAM user may not have the secretsmanager:DeleteSecret permission.
  • help me fix my force-delete command
Verify both secrets are deleted
  • Confirm both secrets are gone from active listings by running this command:
aws secretsmanager list-secrets
  • You should see an empty SecretList array in the response. Neither myapp/dev/api-key nor myapp/dev/db-credentials should appear in the results.

Still seeing your secrets in the list?

  • Secrets scheduled for deletion or force-deleted should not appear in list-secrets results. If you still see them, wait a few seconds and run the command again.
  • If you see other secrets you didn't create in this project, those belong to a different workflow and can be safely ignored.
  • help me verify my secrets were deleted

Secret mission

Set Up Automatic Rotation for a Secret

In production, no human should ever see or manage long-lived passwords. Automatic rotation uses a Lambda function to generate new credentials on a schedule. In this mission, you'll configure rotation for a production secret using the AWS Console.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

This project uses AWS Secrets Manager, which charges $0.40 per secret per month. Secrets that are scheduled for deletion are not charged.

Cost warning

If you completed the Secret Mission, your myapp/prod/db-credentials secret is active and costs $0.40/month. The Lambda rotation function stays within the free tier (1M requests/month). If you do not plan to continue using these resources, choose the Delete tab below to remove them.

Resources you used:

  • myapp/dev/api-key secret in AWS Secrets Manager (already scheduled for deletion, no ongoing cost).
  • myapp/prod/db-credentials secret in AWS Secrets Manager (Secret Mission, $0.40/month while active).
  • CloudFormation stack created by Secrets Manager to provision the Lambda rotation function (Secret Mission).
  • Lambda rotation function linked to myapp/prod/db-credentials (Secret Mission, free tier).

Keep everything running

No action needed. Choose this if you plan to explore Secrets Manager further or want to experiment with the rotation configuration.

  • myapp/dev/api-key will automatically delete after the 7-day recovery window expires. No charge applies while it is scheduled for deletion.
  • myapp/prod/db-credentials remains active at $0.40/month.
  • The Lambda rotation function stays within the AWS Lambda free tier (1M requests/month).

Pause - I'll come back to this later

Secrets cannot be paused directly. You can delete them with a recovery window and restore them later if needed.

  • myapp/dev/api-key is already scheduled for deletion with a 7-day recovery window. You can restore it within 7 days by running:
  • myapp/prod/db-credentials can be deleted with a recovery window so you can restore it later.

Restore the API key secret (within the 7-day window) by running:

aws secretsmanager restore-secret --secret-id myapp/dev/api-key

Delete the production secret with a 7-day recovery window by running:

aws secretsmanager delete-secret --secret-id myapp/prod/db-credentials --recovery-window-in-days 7

When you are ready to resume, restore it by running:

aws secretsmanager restore-secret --secret-id myapp/prod/db-credentials

What about the Lambda function?

The Lambda rotation function has no ongoing cost within the free tier. You can leave it in place until you return. If the secret is deleted, rotation will simply have nothing to act on.

Delete - I don't want to use this again

Remove all project resources permanently. This cannot be undone for force-deleted secrets.

  • myapp/dev/api-key is already scheduled for deletion and will auto-delete within 7 days. No action needed.

If you completed the Secret Mission, delete the production secret by running:

aws secretsmanager delete-secret --secret-id myapp/prod/db-credentials --force-delete-without-recovery

Next, delete the CloudFormation stack that Secrets Manager created for the rotation function. Deleting this stack also removes the Lambda function it provisioned.

  • Open the CloudFormation console at https://console.aws.amazon.com/cloudformation.
  • On the Stacks page, select the stack that Secrets Manager created for your rotation function.
  • Click Delete.
  • When prompted for confirmation, click Delete again.

Why delete the CloudFormation stack instead of the Lambda directly?

The Lambda rotation function was created by CloudFormation. Deleting the stack removes both the function and its associated execution role cleanly. Deleting the Lambda directly would leave the stack in a drifted state.

Confirm all secrets are removed by running:

aws secretsmanager list-secrets

You should see an empty list or only unrelated secrets.

Nice Work!

Nice Work!

Nice work! You've just built a complete secrets management workflow using AWS Secrets Manager and the AWS CLI.

You've learned how to:

  • Created and organized multiple secrets using the AWS CLI with environment-based naming conventions, then retrieved them using both full responses and targeted --query filtering.
  • Updated secrets and explored Secrets Manager's automatic versioning with AWSCURRENT and AWSPREVIOUS staging labels.
  • Managed the full secret lifecycle including tagging for organization, deletion with recovery windows, and force-deletion.
  • Set up automatic rotation with a Lambda function to eliminate long-lived credentials.

Ready to quiz yourself?