AWS Secrets Manager: SAA-C03 credential scenarios

Secrets Manager offers built-in, managed rotation for supported databases including RDS: it provisions the rotation Lambda for you, generates the new password, updates it on the database, and updates the secret — all on a schedule, with no downtime. Why not the others: hand-rolling a Lambda and EventBridge schedule recreates exactly what managed rotation gives you for free in effort, the operational overhead the requirement rules out. A Parameter Store SecureString has no built-in scheduled rotation, so a 'calendar reminder' is a manual step. Leaving the password in config and rotating by hand is the anti-pattern the question is steering you away from. Automatic, no-downtime database rotation is managed rotation in Secrets Manager.

Split by requirement: non-secret configuration that never rotates belongs in Parameter Store, whose standard tier is free, and the one value that must rotate belongs in Secrets Manager, which charges per secret but provides the managed rotation the password needs. That pays for rotation only where rotation is required. Why not the others: putting plain configuration in Secrets Manager pays a per-secret charge for values that gain nothing from rotation. Keeping everything in Parameter Store leaves the password without built-in rotation, failing the schedule requirement. Hard-coding into environment variables at build time bakes a credential into artifacts and defeats central management entirely. Match rotation to Secrets Manager and free config to Parameter Store.

An IAM role attached to the task supplies short-lived, automatically rotated credentials to the SDK, which then calls GetSecretValue — no static key is ever stored anywhere. This is the intended pattern and satisfies 'no long-lived access key'. Why not the others: storing an IAM user's access key in environment variables is precisely the long-lived static credential the review forbids. Baking the secret into the image freezes a credential into an artifact that ships to every registry and cannot be rotated. Passing the password as a plaintext environment variable exposes it in task definitions and logs. Runtime retrieval under an IAM role, never a stored key, is the secure answer.

Secrets Manager encrypts every secret at rest with KMS, and you can point a secret at a customer managed key at creation time so the organization owns the key that protects it. That is the whole configuration. Why not the others: moving the secret to an S3 bucket abandons Secrets Manager's rotation and retrieval features to solve a problem the service already handles natively. Base64 is an encoding, not encryption — it protects nothing. And the claim that only the AWS managed key is available is simply false. When a scenario asks for an organization-owned key under a secret, that is a customer managed KMS key selected on the secret itself.

Cross-account access needs both sides: a resource-based policy on the secret naming the Account B principal, and — because the default AWS managed key cannot be shared across accounts — a customer managed KMS key whose policy lets Account B decrypt. Then the caller needs GetSecretValue and kms:Decrypt. Why not the others: copying the value into another account's Parameter Store creates a stale, unrotated duplicate that drifts the moment the source rotates. Making a secret public is a severe exposure and never least privilege. Emailing a credential into environment variables abandons managed storage, rotation, and auditing altogether. Cross-account is a resource policy plus a shareable customer managed key.

When a value must be encrypted but has no rotation requirement, a Parameter Store SecureString gives you KMS encryption at rest with no per-secret cost — the frugal fit. Reserve Secrets Manager for the case where its managed rotation earns its price. Why not the others: enabling Secrets Manager rotation on a token that never expires pays for a capability the value cannot use. A standard plaintext parameter leaves the token unencrypted, failing the at-rest requirement. Hard-coding a token into source and committing it is a credential-leak waiting to happen. Encrypted-but-static is a SecureString; encrypted-and-rotating is where Secrets Manager becomes worth the cost.

The fix is to stop calling the API per request: cache the secret value in memory and only re-fetch when it rotates, which the Secrets Manager caching library handles for you. That removes the latency, the throttling, and most of the cost in one change. Why not the others: copying the secret into a plaintext environment variable trades a performance problem for a security one and loses rotation. Raising the quota treats the symptom while leaving every request making a needless network call. Disabling rotation weakens the security posture to work around an application design issue. Cache and refresh on rotation is the recommended, low-overhead pattern.