When running an application, you inevitably need to store sensitive information like database passwords, external service API keys, and authentication tokens somewhere. If you write this information directly into your code, it could be exposed to the entire world the moment it gets pushed to GitHub. Let us explore how to manage this securely.
DVA-C02 exam questions in this area focus on where and how to store passwords and API keys.
AWS Secrets Manager
AWS Secrets Manager is a service that securely stores your application's sensitive information and automatically rotates it. Think of it as an automated secret management vault.
Key feature: Auto Rotation Automatically changes database passwords on a schedule. Executes rotation logic through a Lambda function. Directly integrated with RDS, Redshift, and more, making DB password rotation very straightforward. Cross-account sharing: Secrets can be shared securely with other AWS accounts. Cost: $0.40 per secret per month
AWS Systems Manager Parameter Store
Parameter Store is where you store application configuration values and sensitive information. Think of it as an app settings warehouse. It can be used for free, making it popular for storing simple configurations.
Two tiers are available: Standard: Free, up to 10,000 parameters, 4KB value size limit Advanced: Paid, up to 100,000 parameters, 8KB values, parameter policies (expiration dates, etc.) supported
Path-based hierarchy lets you manage environment-specific settings cleanly. /app/dev/db-url (development environment DB address) /app/prod/db-url (production environment DB address)
Secrets Manager vs Parameter Store Comparison
| Feature | Secrets Manager | Parameter Store | |---------|----------------|-----------------| | Auto-rotation | Supported (Lambda-based) | Not supported (manual implementation required) | | Cost | $0.40/secret/month | Standard parameters free | | Cross-account sharing | Supported | Not supported | | Integration | Built-in RDS/Redshift rotation | General configuration storage |
Choose based on your needs: Need to automatically rotate DB passwords → Secrets Manager Store general configuration values, minimize cost → Parameter Store (Standard) Securely store Lambda environment variables → Parameter Store (SecureString)
!Secrets Manager versus Parameter Store
Lambda Environment Variable Security
You need to be careful when handling sensitive information in Lambda functions.
Wrong approach: Writing it directly in code
If you do this, your password becomes public the moment your code gets pushed to Git.
Two correct approaches: Use KMS to encrypt Lambda environment variables directly (can be configured easily in the Lambda console) Dynamically retrieve secrets at runtime from Secrets Manager or Parameter Store
Protecting PII and PHI
PII (Personally Identifiable Information) is any information that can identify a specific individual. This includes names, email addresses, phone numbers, social security numbers, and similar data. PHI (Protected Health Information) is health-related sensitive information such as patient medical records and diagnostic information.
Protection methods: Data masking: Show only part of the data and hide the rest. Example: 010-XXXX-5678 Data sanitization: Completely delete sensitive data that is no longer needed Amazon Macie: A service that automatically finds PII in S3 buckets — think of it as an automatic personal information detector.
Exam Key Points
"Automatic DB password rotation" -- Secrets Manager
"Free configuration storage, general purpose" -- Parameter Store (Standard)
"Encrypt Lambda environment variables" -- KMS or Parameter Store SecureString
"Prevent hardcoded passwords in code" -- Runtime retrieval from Secrets Manager or Parameter Store
"Auto-detect PII in S3" -- Amazon Macie
"Cross-account secret sharing" -- Secrets Manager
Secrets Manager = auto-rotation + paid, Parameter Store = manual management + free