While preparing for the AWS SAP-C02, many candidates confuse AWS Secrets Manager with Systems Manager Parameter Store for credential management. In the real world, this is fundamentally a decision about operational overhead vs. native automation capabilities. Let’s drill into a simulated scenario.
The Scenario #
A fintech startup, VelocityBanking, is modernizing its loan processing application. Their security team discovered that the legacy system retrieves MySQL database credentials from encrypted files stored in S3 buckets—a practice flagged during their SOC 2 audit.
For the upcoming v2.0 release, the Chief Security Officer has mandated:
- Database passwords must be cryptographically random and managed by AWS-native services
- All infrastructure must deploy via CloudFormation (Infrastructure as Code requirement)
- Credentials must auto-rotate every 90 days without manual intervention
- The solution must minimize operational burden on the 3-person DevOps team
The Solutions Architect needs to design a CloudFormation template that satisfies these requirements.
Key Requirements #
Design an IaC-driven, fully automated credential rotation system that meets enterprise security standards while minimizing operational overhead.
The Options #
A) Use AWS Secrets Manager to generate the database password as a secret resource; create an AWS Lambda function resource for password rotation; specify a Secrets Manager RotationSchedule resource to rotate credentials every 90 days.
B) Use AWS Systems Manager Parameter Store to generate the database password as a SecureString parameter; create an AWS Lambda function resource for password rotation; specify a Parameter Store RotationSchedule resource to rotate credentials every 90 days.
C) Use AWS Secrets Manager to generate the database password as a secret resource; create an AWS Lambda function resource for password rotation; create an Amazon EventBridge scheduled rule resource to trigger the Lambda function every 90 days.
D) Use AWS Systems Manager Parameter Store to generate the database password as a SecureString parameter; specify an AWS AppSync DataSource resource to automatically rotate the database password every 90 days.
Correct Answer #
Option A — Secrets Manager with native RotationSchedule.
Step-by-Step Winning Logic #
This solution achieves the optimal trade-off between automation maturity and operational simplicity:
-
Native Rotation Engine: Secrets Manager includes built-in rotation templates for RDS MySQL. The
RotationScheduleresource triggers AWS-managed Lambda functions that handle:- Password generation using cryptographic randomness (FIPS 140-2 compliant)
- RDS master password updates via
ModifyDBInstanceAPI - Secret version staging (current vs. pending)
- Automatic rollback on rotation failure
-
CloudFormation-Native Integration: The
AWS::SecretsManager::RotationScheduleresource is a first-class CloudFormation type, enabling declarative rotation configuration:RotationSchedule: Type: AWS::SecretsManager::RotationSchedule Properties: SecretId: !Ref MyDBSecret RotationLambdaARN: !GetAtt RotationLambda.Arn RotationRules: AutomaticallyAfterDays: 90 -
Minimal Custom Code: While the architect still creates a Lambda function resource, AWS provides rotation function templates (available via SAM/Serverless Application Repository) that require zero code modification for standard RDS scenarios.
đź’Ž The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option B? (Parameter Store with custom rotation)
- Fatal Flaw: Parameter Store does not have a
RotationScheduleresource—this is a fabricated CloudFormation type. - You would need to manually orchestrate rotation using EventBridge + Lambda + custom logic to update both the parameter and the RDS password.
- Parameter Store is designed for configuration data, not secrets with rotation requirements (per AWS Well-Architected Security Pillar).
Why not Option C? (Secrets Manager + EventBridge)
- Technically viable but violates the minimum operational overhead requirement.
- Creates an unnecessary abstraction layer: EventBridge → Lambda → Secrets Manager API.
- Introduces additional failure points (EventBridge rule misconfiguration, Lambda execution errors) that the native
RotationSchedulehandles automatically. - Requires custom CloudWatch alarms and retry logic that
RotationScheduleprovides out-of-the-box.
Why not Option D? (Parameter Store + AppSync)
- Conceptually nonsensical: AWS AppSync is a GraphQL API service with no credential rotation capabilities.
- The
DataSourceresource connects AppSync to data sources (DynamoDB, Lambda, RDS) but doesn’t manage credential lifecycle. - This is a classic “technology misapplication” distractor—testing if you understand service boundaries.
The Architect Blueprint #
graph TD
CFN[CloudFormation Stack] -->|Creates| SM[Secrets Manager Secret]
CFN -->|Creates| RS[RotationSchedule Resource]
CFN -->|Deploys| LF[Rotation Lambda Function]
RS -->|Triggers every 90 days| LF
LF -->|1. Generate new password| SM
LF -->|2. Update master password| RDS[(RDS MySQL)]
LF -->|3. Test connection| RDS
LF -->|4. Finalize version| SM
APP[Application] -->|Retrieves current version| SM
SM -->|Returns credentials| APP
APP -->|Connects using rotated creds| RDS
style SM fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style RS fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style LF fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style RDS fill:#527FFF,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: The RotationSchedule resource acts as the orchestrator, triggering the Lambda function which executes a four-phase rotation process (create → update → test → finalize) against both Secrets Manager and RDS.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A: Secrets Manager + Native Rotation | Low (5-10 lines of CFN) | $0.45 ($0.40 secret + $0.05 API calls) | âś… Native rotation templates âś… Automatic version staging âś… Built-in retry/rollback âś… CloudFormation-native |
❌ $0.40/secret/month cost ❌ Requires VPC endpoint for private RDS ($7.20/mo) |
| B: Parameter Store + Custom | High (150+ lines code) | $0.05 (API calls only) | âś… Free for standard parameters âś… Familiar to Ops teams |
❌ No native rotation ❌ Fictional RotationSchedule resource❌ 15-20 hrs dev time |
| C: Secrets Manager + EventBridge | Medium (50 lines code) | $0.45 (same as A) | âś… Uses Secrets Manager âś… Flexible scheduling |
❌ Redundant orchestration layer ❌ Custom error handling required ❌ No version staging |
| D: Parameter Store + AppSync | N/A (Impossible) | N/A | None | ❌ AppSync doesn’t rotate credentials ❌ Architectural mismatch |
FinOps Note: The $4.80/year cost difference between Options A and B is negligible compared to the engineering cost of building/maintaining custom rotation logic. At scale (100+ secrets), the cost advantage of Parameter Store becomes meaningful, but VelocityBanking’s 3-person team should prioritize time-to-market and cognitive load reduction.
Real-World Practitioner Insight #
Exam Rule #
“For SAP-C02, when you see ‘automatic rotation’ + ‘minimum operational overhead’ + ‘CloudFormation’, select Secrets Manager with RotationSchedule—it’s the only AWS service with native, declarative rotation support.”
Real World #
In production at scale, we often use a hybrid approach:
- Secrets Manager for databases, API keys, and credentials requiring rotation (RDS, DocumentDB, Redshift)
- Parameter Store for application config (feature flags, endpoint URLs) and static secrets (third-party API keys without rotation)
- AWS Config rules to enforce that all RDS instances use Secrets Manager credentials (compliance automation)
For VelocityBanking’s scale (single application), I’d actually recommend:
- Use Secrets Manager’s RDS integration (attaching secrets directly to RDS instances via
SecretTargetAttachment) - Enable CloudTrail logging for all Secrets Manager API calls (audit requirement)
- Implement VPC endpoints for Secrets Manager to avoid data transfer costs ($0.01/GB) when pulling secrets from Lambda
- Set rotation to 60 days instead of 90 (defense-in-depth, minimal cost difference)