Cargando...
Cargando...
Automatically rotate, manage, and retrieve secrets — so your apps never hardcode credentials again.
AWS Secrets Manager is a fully managed service that enables you to store, retrieve, rotate, and audit secrets such as database credentials, API keys, and OAuth tokens. Unlike Parameter Store, it provides native automatic rotation via Lambda functions, deep RDS/Redshift/DocumentDB integration, and cross-account secret sharing. It is the AWS-recommended solution whenever credentials must rotate automatically without application downtime.
Centralized, auditable, automatically-rotating secret storage for production workloads — eliminating hardcoded credentials and manual rotation toil.
Use When
Avoid When
Automatic Secret Rotation
Native rotation for RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Aurora, Redshift, DocumentDB. Custom Lambda rotation functions for any other secret type. Rotation uses a 'single user' or 'alternating users' strategy.
AWS KMS Encryption (at rest)
Every secret is encrypted using a KMS key. By default, the AWS-managed key (aws/secretsmanager) is used. You can specify a customer-managed KMS key (CMK) for fine-grained key policy control and cross-account scenarios.
VPC Endpoint (PrivateLink) Support
Use com.amazonaws.<region>.secretsmanager interface VPC endpoint to access Secrets Manager from private subnets without traversing the public internet. Required for compliance-driven private architectures.
Cross-Account Secret Sharing
Attach a resource-based policy to the secret AND update the KMS key policy to allow the target account. Both policies must grant access — a common exam scenario.
Multi-Region Replication
Replicate secrets to multiple AWS Regions for disaster recovery and low-latency access. Replica secrets stay in sync with the primary automatically.
Secrets Versioning and Staging Labels
AWSCURRENT (active), AWSPREVIOUS (last rotated), AWSPENDING (rotation in progress). Applications should always retrieve AWSCURRENT. During rotation, AWSPENDING exists transiently.
CloudTrail Audit Logging
Every API call (GetSecretValue, RotateSecret, PutSecretValue, DeleteSecret, etc.) is logged in CloudTrail. Use CloudTrail + EventBridge + SNS for alerting on unauthorized secret access.
AWS Config Integration
AWS Config managed rule secrets-manager-rotation-enabled-check verifies that rotation is enabled. Use for compliance posture reporting.
Secrets Manager Caching Client
Available for Java, Python (.NET, Go). Caches secret values in memory with a configurable TTL (default 1 hour) to reduce API call frequency and cost.
ECS and EKS Native Integration
ECS tasks can reference Secrets Manager ARNs directly in task definitions (valueFrom field) — secrets are injected as environment variables or mounted files at container startup without any SDK calls in application code.
Lambda Environment Variable Integration
Lambda functions can retrieve secrets at runtime via SDK. For sensitive values, avoid storing in Lambda environment variables (encrypted only with KMS, not rotated). Prefer SDK retrieval + caching client.
Secrets Manager Agent (AWS Systems Manager integration)
The Secrets Manager Agent is a local HTTP service that caches secrets for EC2 instances and on-premises servers, reducing direct API calls.
Deletion Protection (Recovery Window)
Secrets are not immediately deleted — a recovery window of 7–30 days applies by default. You can force-delete with --force-delete-without-recovery (no recovery window). Scheduled deletion can be cancelled within the recovery window.
Tag-Based Access Control
IAM policies can use aws:ResourceTag conditions on secrets for attribute-based access control (ABAC). Tag secrets with environment, team, or application for fine-grained control.
CloudFormation Dynamic References
Use {{resolve:secretsmanager:MySecret:SecretString:password}} syntax in CloudFormation templates to inject secret values at stack deployment time without hardcoding.
Envelope Encryption for Secrets at Rest
high freqEvery secret stored in Secrets Manager is encrypted using a KMS key via envelope encryption. The default key is the AWS-managed key (aws/secretsmanager). For cross-account access or fine-grained key policy control, specify a CMK. The KMS key policy must grant the accessing principal kms:Decrypt and kms:GenerateDataKey permissions — without this, even a valid Secrets Manager resource policy will fail. This dual-policy requirement is a top exam scenario.
Custom Rotation Function
high freqFor secrets not natively supported (e.g., third-party APIs, custom databases), a Lambda function implements the four-step rotation lifecycle: createSecret, setSecret, testSecret, finishSecret. The Lambda must be in the same VPC as the database (or have network access), and the Secrets Manager service endpoint must be reachable (VPC endpoint or NAT). Lambda execution role needs secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, secretsmanager:DescribeSecret, secretsmanager:UpdateSecretVersionStage permissions.
Automatic Database Credential Rotation
high freqSecrets Manager has native rotation support for RDS MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, and Aurora. Enable rotation with a single API call or console click — AWS provisions the rotation Lambda automatically. Supports 'single user' rotation (updates the same user's password) and 'alternating users' rotation (switches between two users for zero-downtime rotation). Applications should always retrieve the secret at runtime — never cache the raw password in application memory for longer than the rotation interval.
Least-Privilege Secret Access via IAM Policies
high freqUse IAM identity-based policies with secretsmanager:GetSecretValue on specific secret ARNs or name patterns. Combine with resource-based policies on the secret for cross-account scenarios. Use IAM condition keys like secretsmanager:SecretId, secretsmanager:ResourceTag, and aws:RequestedRegion for fine-grained control. Never use wildcard (*) on GetSecretValue in production.
Secret Access Auditing and Anomaly Detection
high freqAll Secrets Manager API calls are logged in CloudTrail (management events). Use CloudTrail Insights to detect unusual GetSecretValue call spikes. Route CloudTrail events to EventBridge rules that trigger SNS alerts or Lambda remediation when unauthorized principals access secrets. This pattern satisfies PCI-DSS, HIPAA, and SOC2 audit requirements.
Hybrid Secret Strategy — Rotation vs. Configuration
high freqUse Secrets Manager for credentials requiring automatic rotation (database passwords, API keys). Use Parameter Store (Standard, free) for non-sensitive configuration values or static secrets that never rotate. Use Parameter Store Advanced with SecureString for sensitive non-rotating config to save cost vs. Secrets Manager. This tiered approach optimizes cost while meeting security requirements. The exam frequently tests which service to choose based on rotation requirements.
Secure S3 Access Pattern
medium freqStore S3 pre-signed URL generation credentials or S3 encryption keys in Secrets Manager. For applications that need to access S3 with specific IAM credentials (e.g., cross-account), store the access key/secret key pair in Secrets Manager and rotate them automatically. Alternatively, store S3 SSE-C encryption keys in Secrets Manager for client-side encryption workflows.
Container Secret Injection at Task Launch
medium freqReference Secrets Manager ARNs in ECS task definitions using the 'secrets' field with 'valueFrom' pointing to the secret ARN. ECS retrieves the secret at task launch and injects it as an environment variable or into a file. The ECS task execution role must have secretsmanager:GetSecretValue and kms:Decrypt permissions. This eliminates the need for application code to call the Secrets Manager SDK.
AUTOMATIC ROTATION = SECRETS MANAGER, ALWAYS. If an exam question mentions 'automatic rotation of database credentials' or 'rotate secrets without application downtime,' the answer is Secrets Manager — not Parameter Store, not any other service. Parameter Store does NOT support automatic rotation natively.
CROSS-ACCOUNT SECRET ACCESS REQUIRES TWO POLICIES: (1) The Secrets Manager resource-based policy must grant the external account/principal access, AND (2) The KMS key policy must grant the external principal kms:Decrypt. Missing either one causes access denial. This is the #1 cross-account secret access failure mode on exams.
SECRETS MANAGER HAS NO FREE TIER. Parameter Store Standard is free. If a question asks for the most cost-effective solution for storing non-rotating configuration values, Parameter Store Standard wins. If rotation is required, cost is secondary — use Secrets Manager.
ROTATION STAGING LABELS: AWSCURRENT (active secret), AWSPREVIOUS (last version before rotation), AWSPENDING (new version being validated during rotation). Your application should always retrieve AWSCURRENT. During a rotation failure, AWSPENDING may exist without becoming AWSCURRENT — this is a failure state to monitor.
VPC ROTATION LAMBDA CONNECTIVITY: When rotating RDS credentials inside a VPC, the rotation Lambda must be deployed in the same VPC (or have network access to the DB) AND must be able to reach the Secrets Manager API endpoint. Use a Secrets Manager VPC Interface Endpoint (PrivateLink) or NAT Gateway — otherwise rotation Lambda will timeout trying to call the Secrets Manager API from inside a private subnet.
ANY scenario requiring AUTOMATIC ROTATION of credentials = Secrets Manager. Parameter Store cannot rotate automatically. This single rule answers ~30% of Secrets Manager exam questions.
Cross-account secret access ALWAYS requires BOTH a Secrets Manager resource-based policy AND a KMS CMK key policy update. The default AWS-managed key (aws/secretsmanager) cannot be used for cross-account scenarios — you must use a CMK.
Secrets Manager has NO free tier — it charges per secret per month + per API call. Parameter Store Standard is free. For cost-optimization questions about non-rotating config, choose Parameter Store. For rotation requirements, cost is not a disqualifier — choose Secrets Manager.
REPLICA SECRETS ARE READ-ONLY. In a multi-Region Secrets Manager setup, rotation only runs in the primary Region and replicates to replicas. You cannot initiate rotation from a replica Region. Billing applies per replica — each replica counts as a full secret.
USE THE CACHING CLIENT FOR HIGH-FREQUENCY ACCESS. Every direct GetSecretValue call costs money and consumes API quota. The Secrets Manager caching client (Java, Python, .NET, Go) caches secrets in memory with a configurable TTL (default 1 hour). For Lambda functions, initialize the caching client OUTSIDE the handler function to persist across warm invocations.
CLOUDFORMATION DYNAMIC REFERENCES: Use {{resolve:secretsmanager:MySecret:SecretString:username}} in CloudFormation templates to inject secret values at deploy time. The secret value is NOT stored in the CloudFormation template or state — it is resolved at deployment. This is the secure pattern for CloudFormation + Secrets Manager.
DELETION RECOVERY WINDOW: Deleted secrets have a 7–30 day recovery window (default 30 days). You CANNOT create a new secret with the same name until the old one is fully deleted. Use --force-delete-without-recovery to bypass the window (irreversible). This matters in CI/CD pipelines that recreate secrets.
IAM TEMPORARY CREDENTIALS ≠ DATABASE CREDENTIALS. IAM roles provide temporary AWS API credentials (access key, secret key, session token) for AWS service calls. They do NOT replace database usernames/passwords. Secrets Manager stores the actual DB credentials. Use IAM authentication for RDS only when the database engine supports it (MySQL, PostgreSQL on RDS/Aurora) — and even then, Secrets Manager can store the IAM auth token generation logic.
ECS TASK DEFINITION SECRET INJECTION: Reference secrets using the 'secrets' array in task definition with 'valueFrom' set to the full Secrets Manager ARN (optionally with ::key: suffix to extract a specific JSON key). The ECS task execution role (not the task role) needs the secretsmanager:GetSecretValue permission. This is a common exam trap — wrong role = secret retrieval failure.
Common Mistake
Systems Manager Parameter Store can automatically rotate secrets, so I can use it instead of Secrets Manager for database credential rotation.
Correct
Parameter Store does NOT support automatic rotation. It stores values statically — you must manually update them or build custom rotation automation (EventBridge + Lambda). Secrets Manager is the ONLY AWS service with native automatic rotation, including managed rotation for RDS, Aurora, Redshift, and DocumentDB.
This is the #1 exam trap. Any question mentioning 'automatic rotation,' 'rotate credentials without downtime,' or 'scheduled rotation' is pointing to Secrets Manager. If you see Parameter Store in the answer choices alongside Secrets Manager for a rotation scenario, Secrets Manager is always correct. Remember: Parameter Store = static config; Secrets Manager = rotating secrets.
Common Mistake
IAM temporary credentials (from STS AssumeRole) can replace database passwords stored in Secrets Manager for RDS access.
Correct
IAM temporary credentials are AWS API credentials for calling AWS services (S3, DynamoDB, etc.) — they are not database passwords. RDS does support IAM database authentication (for MySQL and PostgreSQL), which generates a temporary auth token via the RDS API, but this is a separate feature from standard password-based auth. Secrets Manager stores the actual database username/password. The two mechanisms are complementary, not interchangeable.
Exam questions often present IAM credentials as a substitute for Secrets Manager in database scenarios. The key distinction: IAM credentials authenticate you to AWS APIs; database credentials authenticate you to the database engine. Even with RDS IAM auth, the token generation still requires an IAM call — Secrets Manager can store the IAM user credentials used for that token generation.
Common Mistake
Storing database credentials as encrypted environment variables in Lambda or ECS is equivalent to using Secrets Manager.
Correct
Environment variables encrypted with KMS are static — they do not rotate automatically, they are visible to anyone with Lambda:GetFunctionConfiguration permission, and they require redeployment to update. Secrets Manager provides rotation, fine-grained IAM access control per secret, full CloudTrail audit logging of every retrieval, and dynamic retrieval at runtime without redeployment. For any compliance requirement (PCI-DSS, HIPAA), Secrets Manager is the required pattern.
This misconception leads candidates to choose environment variables as the 'simpler' option. On exams, any scenario involving compliance, rotation, or audit trails eliminates environment variables as a valid answer. The correct pattern is: retrieve the secret from Secrets Manager at runtime using the SDK or ECS native injection.
Common Mistake
Secrets Manager and Parameter Store SecureString are the same thing — just use whichever is cheaper.
Correct
They are fundamentally different services. Secrets Manager: automatic rotation, native RDS/Redshift/DocumentDB integration, resource-based policies for cross-account, 64 KB secret size, per-secret monthly charge + per-API charge, no free tier. Parameter Store SecureString: no automatic rotation, KMS encryption, 8 KB limit (Standard) or 8 KB (Advanced), free (Standard) or per-parameter charge (Advanced), no resource-based policies. Choose based on rotation requirements first, then cost.
Exam questions test whether candidates know the functional differences, not just the price difference. A question asking 'which service provides automatic rotation of database credentials with the least operational overhead' has only one answer: Secrets Manager. Cost optimization questions about non-rotating config point to Parameter Store.
Common Mistake
For cross-account secret access, I only need to update the Secrets Manager resource-based policy to allow the other account.
Correct
Cross-account secret access requires TWO policy updates: (1) The Secrets Manager resource-based policy must grant the external principal secretsmanager:GetSecretValue, AND (2) The KMS key policy (for the key encrypting the secret) must grant the external principal kms:Decrypt and kms:GenerateDataKey. If the secret uses the default AWS-managed key (aws/secretsmanager), cross-account access is NOT possible because you cannot modify AWS-managed key policies. You MUST use a customer-managed KMS key (CMK) for cross-account scenarios.
This is a multi-part trap. Candidates who know about resource-based policies but forget the KMS key policy requirement will get cross-account questions wrong. The additional trap: using the default AWS-managed key makes cross-account impossible. Always use a CMK for cross-account secrets.
Common Mistake
Using general-purpose storage like S3 or DynamoDB with server-side encryption is a valid alternative to Secrets Manager for storing database credentials.
Correct
While S3 and DynamoDB support encryption at rest, they provide no secret-specific features: no automatic rotation, no versioning with staging labels, no native database integration, no resource-based policies designed for secret access patterns, and no CloudTrail integration specifically for credential access auditing. Secrets Manager is purpose-built for credential management. Using S3 or DynamoDB introduces significant operational overhead and security gaps.
Exam questions may present S3 or DynamoDB as 'secure storage' options. The correct answer for credential management is always Secrets Manager (with rotation) or Parameter Store SecureString (without rotation) — never general-purpose storage services.
ROTATE = Secrets Manager. STORE STATIC CONFIG = Parameter Store. If the question has the word 'rotate' anywhere, stop reading and pick Secrets Manager.
Cross-Account Secret Access = TWO KEYS to open the vault: (1) Secrets Manager resource policy + (2) KMS key policy. One key alone won't open it.
Staging Labels: CURRENT → PREVIOUS → PENDING. Think of a relay race: PENDING is the runner warming up, CURRENT is running the race, PREVIOUS just finished.
Secrets Manager pricing: 'Pay to Play, Pay to Ask' — monthly fee per secret (Pay to Play) + fee per API call (Pay to Ask). Parameter Store Standard = Free to store, free to ask (within limits).
VPC Rotation Lambda: 'Database IN, API OUT' — Lambda must reach the database (IN the VPC) AND reach the Secrets Manager API (OUT via VPC endpoint or NAT). Both directions must work or rotation fails.
CertAI Tutor · DVA-C02, SAA-C03, SAP-C02, DEA-C01, DOP-C02, AIF-C01, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns