This chapter covers AWS Secrets Manager, a fully managed service for securely storing, rotating, and retrieving secrets such as database credentials, API keys, and OAuth tokens. For the DVA-C02 exam, Secrets Manager is a core security topic under Domain 2.4 (Managing Secrets). Expect 3-5 questions that test your understanding of its features, integration with other services, and best practices. Mastering Secrets Manager is essential for building secure, production-ready applications on AWS.
Jump to a section
Imagine a hotel where guests store valuables in safety deposit boxes at the front desk. Each box has a unique ID and can only be opened with a specific key (the secret value). The front desk clerk (Secrets Manager) does not hold the keys; instead, when a guest checks in, they provide their ID card (IAM role) and request access to their box. The clerk verifies the ID against a list of authorized guests (IAM policy) and then retrieves the box from a secure vault. The guest can take the key, use it, and return it. The clerk automatically rotates the lock (secret rotation) every 90 days, generating a new key and invalidating the old one. If a guest loses their key, the clerk can issue a new one (regenerate secret) but only if authorized. The clerk also keeps an audit log of every box access (AWS CloudTrail). Crucially, the clerk never writes down the key or shares it with unauthorized guests. This mirrors Secrets Manager: it stores secrets encrypted under KMS keys, enforces fine-grained access via IAM, supports automatic rotation with Lambda, and integrates with CloudTrail for auditing. Just as the safety deposit box protects valuables from theft, Secrets Manager protects sensitive credentials from exposure in code or configuration files.
What is AWS Secrets Manager?
AWS Secrets Manager is a fully managed service that helps you protect access to your applications, services, and IT resources. It enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. Secrets Manager encrypts secrets at rest using AWS KMS (Key Management Service) and in transit using TLS. It integrates natively with Amazon RDS, Amazon Redshift, Amazon DocumentDB, and other AWS services to automatically rotate credentials.
Why Secrets Manager Exists
Before Secrets Manager, developers often hardcoded secrets in application code, configuration files, or environment variables. This led to security risks: secrets were exposed in source control, logs, or debugging output. Managing rotation was manual and error-prone. Secrets Manager solves these problems by providing a centralized, auditable, and automated way to store and rotate secrets.
How Secrets Manager Works Internally
When you create a secret, Secrets Manager encrypts it using a KMS key (either the default aws/secretsmanager key or a customer managed key). The encrypted secret is stored in a regional, highly durable backend. When you retrieve the secret, Secrets Manager decrypts it in memory and returns the plaintext over a TLS-encrypted channel. It never writes plaintext to disk or logs. Access is controlled via IAM policies that can be scoped to specific secrets.
Key Components
Secret: A logical container for one or more key-value pairs or a plaintext string. Each secret has a name, description, and tags. Secrets can be up to 64 KB in size.
Rotation: Secrets Manager can automatically rotate secrets on a schedule (e.g., every 30 days). It uses a Lambda function to update the secret in both Secrets Manager and the target service (e.g., RDS). The rotation process has four stages: create a new version, set it as pending, test it, and then mark the old version as deprecated.
Version IDs: Secrets Manager supports versioning. Each version has a unique identifier (a UUID). You can reference a specific version using the VersionId parameter. The staging label AWSCURRENT always points to the latest valid version. AWSPREVIOUS points to the previous version.
Resource-based policies: You can attach a resource policy to a secret to grant cross-account access. This is useful when you need to share a secret with another AWS account.
Tags: Secrets can be tagged for cost allocation, access control, and organization.
Defaults and Timers
Rotation interval: Default 30 days. You can set any value between 1 and 365 days.
Automatic rotation: Requires a Lambda function. Secrets Manager provides built-in Lambda blueprints for RDS (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) and Amazon Redshift.
Secret retention: After deletion, a secret is scheduled for deletion with a recovery window of 7 to 30 days (default 30). During this window, you can restore the secret. After the window expires, the secret is permanently deleted.
Maximum secret size: 64 KB (65536 bytes). For larger secrets, consider using AWS Systems Manager Parameter Store (which supports up to 8 KB parameters, or 512 KB with advanced parameters).
Configuration and Verification Commands
Using the AWS CLI, you can manage secrets:
# Create a secret
aws secretsmanager create-secret --name MySecret --secret-string '{"username":"admin","password":"mypassword"}'
# Retrieve a secret (returns JSON)
aws secretsmanager get-secret-value --secret-id MySecret
# Rotate a secret immediately
aws secretsmanager rotate-secret --secret-id MySecret
# List secrets
aws secretsmanager list-secrets
# Delete a secret (with recovery window)
aws secretsmanager delete-secret --secret-id MySecret --recovery-window-in-days 7
# Restore a deleted secret
aws secretsmanager restore-secret --secret-id MySecretIntegration with Other Services
Amazon RDS: Secrets Manager can automatically rotate credentials for RDS instances (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle). The rotation Lambda function updates both the RDS user password and the secret in Secrets Manager.
AWS Lambda: You can retrieve secrets from Lambda functions using the AWS SDK. Best practice: retrieve the secret once during initialization and cache it for the lifetime of the function to reduce costs and latency.
Amazon ECS/EKS: Secrets can be injected into containers as environment variables or mounted as volumes using the secrets option in the task definition.
AWS CloudFormation: You can create and reference secrets in CloudFormation templates using the AWS::SecretsManager::Secret resource. Use dynamic references to pass secrets to other resources without exposing them in the template.
AWS CloudTrail: All API calls to Secrets Manager are logged in CloudTrail, providing an audit trail of secret access and management.
Security Best Practices
Use IAM roles, not users: Applications should assume an IAM role to access secrets. Avoid hardcoding credentials.
Cache secrets: Retrieve secrets at application startup and cache them in memory. This reduces API calls and costs. Be aware of rotation: you need a mechanism to refresh the cached secret when it rotates (e.g., catch exceptions and re-fetch).
Use customer managed KMS keys: For fine-grained control over encryption and auditing, use your own KMS key instead of the default.
Enable automatic rotation: For database credentials, always enable automatic rotation. Test rotation in a staging environment first.
Monitor with CloudWatch: Use CloudWatch metrics (e.g., SecretVersionId, RotationSucceeded) and alarms to detect rotation failures.
Common Pitfalls
Secret size limit: 64 KB is the maximum. If your secret is larger, consider splitting it or using Parameter Store.
Cross-account access: To share a secret across accounts, you must attach a resource-based policy to the secret AND grant the consuming account's IAM role permission to access the secret. Both policies are evaluated.
Rotation failures: If the Lambda function fails during rotation (e.g., network timeout, wrong permissions), the secret may be left in an inconsistent state. Monitor rotation events and set up notifications.
Cost: Secrets Manager charges per secret per month and per API call. For high-volume secrets access, caching is essential to control costs.
Create a secret
You define the secret's name, description, and tags. You can store either a plaintext string or a JSON structure of key-value pairs. Secrets Manager encrypts the secret using the specified KMS key (default or customer managed). The encrypted ciphertext is stored in the service's backend. You can also choose to generate a random password automatically by specifying the password length, character types, and exclusions. The secret is immediately available for retrieval.
Attach IAM permissions
To retrieve the secret, an IAM principal (user, role, or group) must have permissions. The minimum required action is `secretsmanager:GetSecretValue`. You can scope the policy to a specific secret using its ARN. For example: `{"Effect":"Allow","Action":"secretsmanager:GetSecretValue","Resource":"arn:aws:secretsmanager:us-east-1:123456789012:secret:MySecret-*"}`. The wildcard `-*` is required because Secrets Manager appends a random suffix to the secret name. Without this, the policy will not match the actual secret ARN.
Retrieve the secret in code
Using the AWS SDK (e.g., boto3 for Python), you call `get_secret_value()` with the secret ID (name or ARN). The SDK makes an HTTPS request to the Secrets Manager API. The service decrypts the secret using the KMS key and returns the plaintext over TLS. Your application then parses the JSON or uses the string directly. Best practice: call this once during initialization and cache the result. For example, in Python: `response = client.get_secret_value(SecretId='MySecret')` and then `secret = json.loads(response['SecretString'])`.
Enable automatic rotation
You configure a rotation schedule (e.g., every 30 days). Secrets Manager invokes a Lambda function that you provide. For RDS, you can use the built-in Lambda blueprint. The rotation process: (1) create a new version of the secret with a new password, (2) set the new version as pending, (3) update the RDS user's password using the new secret, (4) test the new credentials, (5) mark the new version as AWSCURRENT and the old version as AWSPREVIOUS. If any step fails, rotation is aborted and the secret remains unchanged.
Handle secret rotation in application
When a secret rotates, your application must be able to use the new credentials. If you cache the secret, you need a strategy to refresh it. Common approaches: (1) catch authentication failures and re-fetch the secret, (2) use a background thread that periodically re-fetches the secret before it expires, (3) use the AWS Secrets Manager Agent (a sidecar process) that caches and refreshes secrets automatically. The exam expects you to know that you should not hardcode rotation logic; instead, use caching with refresh on failure.
Enterprise Scenario 1: Database Credential Management
A financial services company runs hundreds of microservices, each connecting to an RDS PostgreSQL database. Previously, each service had its own database user with hardcoded credentials in environment variables. When a security audit required quarterly password rotation, the ops team manually updated each service, often causing downtime due to mismatched credentials. They migrated to Secrets Manager: each microservice assumes an IAM role that grants GetSecretValue on its specific database secret. Automatic rotation is enabled with a 30-day interval using the built-in RDS rotation Lambda. The Lambda generates a new password, updates the RDS user, and stores the new secret. The application retrieves the secret at startup and caches it. On authentication failure (e.g., after rotation), it re-fetches the secret. This eliminated manual rotation and reduced credential-related incidents by 90%. Key considerations: they use a customer managed KMS key for encryption, and they monitor rotation failures with CloudWatch alarms. They also set the recovery window to 7 days to quickly restore accidentally deleted secrets.
Enterprise Scenario 2: Third-Party API Key Management
A SaaS company integrates with multiple third-party APIs (e.g., Stripe, Twilio). Each API key is stored as a secret in Secrets Manager. The application retrieves the keys at startup and caches them. For security, keys are rotated manually every 90 days by updating the secret value. The application has a configuration toggle to force a re-fetch of secrets without restarting (e.g., by hitting an internal endpoint). This approach ensures that if a key is compromised, it can be rotated immediately without deploying new code. The company also uses resource-based policies to share some secrets with a partner account for integration testing. They learned the hard way that cross-account access requires both a resource policy on the secret and an IAM policy in the partner account. Initially, they only added the resource policy and wondered why access was denied.
What Goes Wrong When Misconfigured
Common issues: (1) IAM policy missing the wildcard suffix (-*) in the resource ARN, causing GetSecretValue to fail with AccessDenied. (2) Rotation Lambda lacking permissions to update the RDS user (e.g., missing rds:ModifyDBInstance), causing rotation to fail silently. (3) Application not caching secrets, leading to high API costs (Secrets Manager charges per 10,000 API calls) and throttling. (4) Setting the recovery window too short (e.g., 7 days) and accidentally deleting a secret that is still in use, causing application failures. The exam loves to test these misconfigurations.
What DVA-C02 Tests on Secrets Manager
Domain 2.4: Managing Secrets. The exam focuses on: (1) when to use Secrets Manager vs. Parameter Store, (2) how to retrieve secrets securely in code, (3) automatic rotation mechanics, (4) IAM permissions for secrets, (5) encryption with KMS, and (6) integration with RDS and Lambda.
Common Wrong Answers and Why Candidates Choose Them
"Store secrets in environment variables" – Candidates think environment variables are secure because they are not in code. But they can be exposed in logs, debugging output, or container image layers. Secrets Manager encrypts secrets and provides audit trails.
"Use Secrets Manager for configuration data like endpoint URLs" – Secrets Manager is for sensitive data. For non-sensitive configuration, use Parameter Store (free, supports tiered pricing). The exam tests cost optimization.
"Retrieve the secret on every request" – This is inefficient and costly. Best practice is to cache the secret and refresh on rotation or failure.
"Rotation happens instantly" – Rotation takes time (seconds to minutes). The Lambda function must complete all stages. The exam expects you to know that during rotation, there are two valid versions (AWSCURRENT and AWSPREVIOUS).
Specific Numbers and Terms
Maximum secret size: 64 KB
Default rotation interval: 30 days (can be 1-365)
Deletion recovery window: 7-30 days (default 30)
Version staging labels: AWSCURRENT, AWSPREVIOUS, AWSPENDING
KMS key: default aws/secretsmanager or customer managed
API calls: CreateSecret, GetSecretValue, PutSecretValue, RotateSecret, DeleteSecret, RestoreSecret
Edge Cases and Exceptions
If you delete a secret and then restore it, the restoration is only possible within the recovery window. After that, the secret is permanently deleted and cannot be recovered.
Cross-account access requires both a resource-based policy on the secret AND an IAM policy in the consuming account. The resource policy must grant secretsmanager:GetSecretValue to the external account's root or a specific role.
When using automatic rotation with RDS, the Lambda function must be in the same VPC as the RDS instance (or have network access). The Lambda needs a VPC configuration with security group rules that allow outbound traffic to the RDS instance.
Secrets Manager supports versioning. If you manually update a secret (e.g., via PutSecretValue), you create a new version. The AWSCURRENT label moves to the new version. You can reference a specific version by its VersionId.
How to Eliminate Wrong Answers
If a question asks about storing database credentials, eliminate any option that suggests hardcoding, environment variables, or storing in a file. Look for options that mention Secrets Manager, IAM roles, and caching. For rotation questions, eliminate answers that claim rotation is instantaneous or that you must manually update the secret. Remember that rotation uses a Lambda function and that during rotation, both old and new credentials are valid for a short time.
Secrets Manager encrypts secrets at rest using KMS and in transit using TLS.
Automatic rotation for RDS uses a Lambda function; the rotation interval defaults to 30 days.
IAM policies for secrets must include the wildcard suffix '-*' in the resource ARN (e.g., `arn:aws:secretsmanager:region:account:secret:MySecret-*`).
Cache secrets in memory to reduce API calls and costs; refresh on authentication failure or periodically.
Deletion has a recovery window of 7-30 days; after that, the secret is permanently unrecoverable.
Use resource-based policies for cross-account secret sharing; both the resource policy and the consuming account's IAM policy must allow access.
The maximum secret size is 64 KB; for larger data, use Parameter Store advanced parameters.
Version staging labels: AWSCURRENT (current valid secret), AWSPREVIOUS (previous valid secret), AWSPENDING (during rotation).
These come up on the exam all the time. Here's how to tell them apart.
AWS Secrets Manager
Designed for sensitive data (passwords, API keys).
Automatic rotation for RDS, Redshift, DocumentDB.
Encrypted at rest by default with KMS.
Charges per secret per month ($0.40) and per 10,000 API calls ($0.05).
Maximum secret size: 64 KB.
AWS Systems Manager Parameter Store
Designed for configuration data (endpoints, feature flags).
No built-in rotation; you must implement custom automation.
Standard parameters are not encrypted by default; advanced parameters can be encrypted with KMS.
Standard parameters are free; advanced parameters cost $0.05 per parameter per month.
Maximum parameter size: 8 KB (standard) or 512 KB (advanced).
Mistake
Secrets Manager stores secrets in plaintext and encrypts them only during transmission.
Correct
Secrets are encrypted at rest using KMS. The service never stores plaintext. When you retrieve a secret, it is decrypted in memory and sent over TLS. The encrypted ciphertext is stored persistently.
Mistake
You can use Secrets Manager to store configuration data like API endpoints or feature flags.
Correct
While technically possible, it is not cost-effective. Secrets Manager charges per secret and per API call. For non-sensitive configuration, use AWS Systems Manager Parameter Store (free for standard parameters, $0.05 per advanced parameter per month).
Mistake
Automatic rotation updates the secret in Secrets Manager without changing the actual database password.
Correct
Rotation uses a Lambda function that generates a new password and updates both the secret in Secrets Manager and the actual database user's password. The old password is invalidated after the rotation completes.
Mistake
If you delete a secret, it is immediately and permanently removed.
Correct
Deletion schedules the secret for deletion with a configurable recovery window (7-30 days). During this window, you can restore the secret. After the window expires, the secret is permanently deleted.
Mistake
You can retrieve a secret using only the secret name without any IAM permissions.
Correct
Access to secrets is governed by IAM policies. You must have `secretsmanager:GetSecretValue` permission on the secret's ARN. Without proper permissions, the API call fails with AccessDenied.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use the AWS SDK to call `get_secret_value()` with the secret ID (name or ARN). Best practice: retrieve the secret once outside the handler function and cache it in a global variable. This avoids making an API call on every invocation. If the secret rotates, you need to handle stale cache: catch authentication errors and re-fetch, or use a background refresh. Example in Python: `import boto3; client = boto3.client('secretsmanager'); secret = client.get_secret_value(SecretId='my-secret')['SecretString']`.
Secrets Manager is designed for sensitive data like passwords and API keys, with built-in automatic rotation and encryption by default. Parameter Store is for configuration data like endpoint URLs and feature flags, with no automatic rotation and optional encryption. Secrets Manager costs per secret and per API call; Parameter Store has a free tier for standard parameters. For the exam, use Secrets Manager for secrets and Parameter Store for configuration.
You attach a Lambda function to the secret. The rotation process has four stages: (1) create a new version of the secret (AWSPENDING) with a new password, (2) set the new password on the target service (e.g., RDS), (3) test the new credentials, (4) mark the new version as AWSCURRENT and the old as AWSPREVIOUS. If any stage fails, rotation is rolled back. The Lambda must have network access to the target service (e.g., be in the same VPC).
The minimum required action is `secretsmanager:GetSecretValue`. You must also allow `kms:Decrypt` on the KMS key used to encrypt the secret. The resource ARN in the policy must include the wildcard suffix `-*` because Secrets Manager appends a random 6-character string to the secret name. Example: `"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:MySecret-*"`.
Yes. Attach a resource-based policy to the secret that grants `secretsmanager:GetSecretValue` to the external account's root user or a specific IAM role. Then, in the external account, the IAM role must have a policy that allows `secretsmanager:GetSecretValue` on the secret's ARN. Both policies are evaluated; if either denies, access is denied.
Secrets Manager does not immediately delete the secret. It schedules deletion with a recovery window of 7-30 days (default 30). During this window, you can call `RestoreSecret` to recover it. After the window expires, the secret is permanently deleted and cannot be recovered. You can also force immediate deletion by setting the recovery window to 0, but this is not recommended.
Cache the secret at startup and use it for all connections. If a database authentication fails (e.g., after rotation), catch the exception and re-fetch the secret from Secrets Manager. Update the cache with the new secret and retry the connection. Alternatively, use the AWS Secrets Manager Agent, a sidecar process that caches and refreshes secrets automatically. The exam expects you to know that caching with refresh on failure is the recommended pattern.
You've just covered Secrets Manager for Applications — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?