Lesson 174 · AWS Learning Path

AWS 174: Secrets Manager and Parameter Store

Anil Jalela · Published Dec 16, 2025 · 9 min read

Why this lesson matters

Choose secret or configuration storage based on rotation, retrieval, hierarchy, versioning, policy, size, throughput, sharing, and cost.

What you will be able to do

By the end, you can:

• explain secrets manager and parameter store in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+------------------------+
|  Application identity  |
+------------------------+
            |
            v
+-------------------------------------+
|  Secret or parameter authorization  |
+-------------------------------------+
                  |
                  v
+-----------------------+
|  Encrypted retrieval  |
+-----------------------+
           |
           v
+--------------------------------------+
|  Use in memory, rotation, and audit  |
+--------------------------------------+

Choose configuration and secret storage from the requirement

Do not put secrets in plain String parameters, Lambda environment variables, AMIs, user data, container images, Git, CloudFormation parameters without NoEcho, command history, tags or logs. NoEcho only masks selected CloudFormation surfaces; it is not encryption and cannot protect a value copied into outputs or resource metadata.

Parameter Store details an architect must know

Standard and advanced tiers differ in quota, value size, policies, sharing and price. Intelligent-Tiering chooses a tier when a request requires advanced features. A standard parameter can be upgraded, but an advanced parameter cannot be downgraded in place; delete and recreate only after dependency and rollback analysis. Tier is separate from throughput.

SecureString uses KMS. With the default AWS managed key, access patterns differ from a customer managed key, so use a customer managed key when policy, separation, audit or cross-account requirements justify it. GetParameter without decryption returns ciphertext metadata; --with-decryption requires both SSM and KMS permission. Hierarchical access such as GetParametersByPath can expose descendants, so constrain path permissions carefully and test recursive behavior.

Parameter policies on advanced parameters can signal expiration, expiration notification and no-change periods. They do not update the consuming application automatically. AppConfig is a better fit when configuration rollout, validation, deployment strategies and rollback are required.

Secrets Manager lifecycle and rotation

A secret version is immutable; staging labels move between versions. Normal retrieval asks for AWSCURRENT. During Lambda rotation, the four logical steps are:

1. createSecret creates or finds the AWSPENDING version idempotently.
2. setSecret applies the pending credential to the database or target service.
3. testSecret proves the pending credential can authenticate and has expected access.
4. finishSecret moves AWSCURRENT; Secrets Manager retains the prior version as AWSPREVIOUS.

Some service-managed secrets support managed rotation without a customer Lambda. Other secrets need a Lambda with network reachability to both Secrets Manager and the target. A rotation schedule is not evidence of success: inspect rotation status, CloudTrail, Lambda logs, target authentication and version labels. Never log secret values.

Single-user database rotation briefly changes one credential. Alternating-user rotation maintains two users for higher availability but needs elevated credentials and requires permission parity between the users. Applications should retrieve at runtime, cache for a bounded period, retry authentication once after refreshing, and avoid calling Secrets Manager for every request.

Multi-Region replication creates read replicas of a secret with independent regional ARNs and KMS protection. Plan failover retrieval and promotion, key permissions, rotation propagation and deletion order. Replication is not a substitute for rotating a compromised credential.

Permission and network path

The workload identity needs only the exact GetSecretValue or parameter read actions and, for customer-managed encryption, kms:Decrypt under appropriate service/context conditions. A secret resource policy can create public or cross-account exposure; use BlockPublicPolicy validation where applicable. Private workloads can use interface VPC endpoints for Secrets Manager and Systems Manager, but endpoint policies, DNS, security groups and KMS remain separate authorization layers.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open Secrets Manager, Secrets and Systems Manager, Parameter Store; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws secretsmanager list-secrets --query 'SecretList[].{Name:Name,Rotation:RotationEnabled,LastChanged:LastChangedDate}' --output table
aws ssm describe-parameters --query 'Parameters[].{Name:Name,Type:Type,Tier:Tier,Version:Version}' --output table

Expected interpretation

Metadata inventory must not expose values. Successful retrieval still requires safe application memory, log redaction, network path, KMS permission, and rotation handling.

Practical work

Compare a rotating RDS password, API token, non-secret feature flag, AMI ID, and hierarchical environment configuration. Select store, naming, KMS, resource policy, cache, rotation, audit, and deletion behavior.

Diagnose this topic from its own evidence

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Choose secret or configuration storage based on rotation, retrieval, hierarchy, versioning, policy, size, throughput, sharing, and cost.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Secrets Manager and Parameter Store.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Secrets Manager and Parameter Store.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid placing secrets in code, user data, task definitions, shell history, screenshots, or CloudFormation outputs.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Select Parameter Store, Secrets Manager or AppConfig from lifecycle requirements rather than treating them as interchangeable.
• Explain standard/advanced/intelligent tiers, SecureString KMS authorization and path-recursion risk.
• Trace all four rotation steps and use version labels to diagnose a failed rotation.
• Design bounded client caching, authentication refresh and least-privilege retrieval without exposing a value.
• Account for regional replicas, VPC endpoints, KMS permissions, CloudTrail evidence, cost and deletion ownership.

Official sources

• Secrets Manager
• Parameter Store
• Parameter tiers
• Secrets Manager rotation
• Lambda rotation steps
• AWS security documentation
• Security Pillar