A telehealth startup deploys Terraform and CloudFormation from GitHub Actions to three environments. Security forbids plaintext database passwords in code, requires rotation every 30 days, and audit of each retrieval. How should secrets be managed in pipeline code?

The correct approach works because Secrets Manager stores the password encrypted outside code and pipeline logic references it dynamically at deploy time for Terraform and CloudFormation, native rotation enforces the 30-day requirement without manual handling, and every GetSecretValue call is logged for audit with separate secrets and IAM policies per environment. The SSM Parameter Store SecureString method fails on rotation because despite KMS encryption and CloudTrail logging it has no built-in automatic rotation engine, leaving the 30-day mandate to fragile custom jobs rather than managed versioning. The GitHub Actions encrypted secrets method fails on audit because while encryption avoids plaintext and manual updates can approximate rotation, workflow-level secret access does not produce centralized per-retrieval audit trails tied to identity and timestamp. The shared secret across dev, staging and production fails on isolation because one automatically rotated value couples environments, widening blast radius and preventing independent access control and lifecycle management. Exam caveat is to not confuse encrypted storage with managed rotation, since many questions test Secrets Manager versus Parameter Store precisely on automatic rotation and dynamic referencing. Practical check is to verify each environment secret shows rotation enabled at 30 days with recent success, templates contain only ARNs or dynamic references, and CloudTrail records retrievals by the GitHub Actions role.