3.1.3. AWS Secrets Manager for Application Secrets

First Principle: AWS Secrets Manager securely stores, rotates, and retrieves sensitive application secrets, preventing hardcoding of credentials and enhancing the security posture of your applications.

Sensitive information such as API keys, database credentials, and OAuth tokens should never be hardcoded directly into your application code or stored in plain text configuration files. AWS Secrets Manager helps you protect access to your applications, services, and IT resources.

• Secure Storage: Encrypts secrets at rest using AWS KMS.
• Automated Rotation: Automatically rotates secrets for supported databases (Amazon RDS, Amazon Redshift), Amazon DocumentDB, and other services via AWS Lambda functions. This significantly reduces the attack surface from long-lived credentials.
• Centralized Management: Manage all your secrets from a single place.
• Integration: Easily retrieve secrets programmatically using AWS SDKs or AWS CLI from your application code, Lambda functions, or CodeBuild projects.
• Least Privilege: Control access to secrets using IAM policies.

AWS KMS Encryption for Developers

AWS Key Management Service (KMS) underpins encryption across nearly every AWS service. Developers need to understand three key distinctions:

AWS managed keys vs. customer managed keys (CMKs): AWS managed keys are created and rotated automatically by AWS services (e.g., the aws/s3 key). Customer managed keys give you control over key policies, rotation schedules, and cross-account access — use them when you need fine-grained access control or compliance requirements.

Server-side encryption (SSE) vs. client-side encryption: With SSE, AWS encrypts your data after receiving it (e.g., SSE-S3, SSE-KMS, SSE-C for S3). With client-side encryption, you encrypt data before sending it to AWS — only you hold the decryption keys. The exam tests when each is appropriate: SSE-KMS when you need audit trails via CloudTrail, SSE-C when the customer must control keys, and client-side when data must never exist unencrypted on AWS.

Envelope encryption is how KMS handles data larger than 4 KB. The KMS Encrypt API only accepts 4 KB of plaintext. For larger data, you call GenerateDataKey — KMS returns a plaintext data key AND an encrypted copy. You encrypt your data locally with the plaintext key, discard it, and store the encrypted data key alongside the ciphertext. To decrypt, KMS decrypts the data key, and you use it locally. The AWS Encryption SDK handles this pattern automatically.

Key rotation: Automatic rotation (yearly for customer managed keys) generates new key material but keeps the same key ID — your applications don't need code changes. Old data encrypted with previous key material can still be decrypted because AWS retains all previous versions. Manual rotation creates a new key ID entirely, requiring alias updates.

⚠️ Exam Trap: 'Encrypt a 5 GB file with KMS' → you CANNOT send it to the KMS Encrypt API (4 KB limit). The answer is envelope encryption using GenerateDataKey.

Scenario: You're developing an application that connects to an Amazon RDS database. The database credentials are highly sensitive and should not be stored directly in your application's configuration files. You also need these credentials to be rotated frequently for security best practices.

⚠️ Exam Trap: Secrets Manager automatically rotates secrets. Systems Manager Parameter Store does NOT (you must implement rotation yourself). If a question requires automatic rotation, Secrets Manager is the answer — even though Parameter Store is cheaper.