Applications read a database password from AWS Secrets Manager, and a separate rotation function changes the value monthly. Terraform should create the secret and its access policy but must never hold the password or conflict with the rotation. What should the configuration manage?
Select an answer to reveal the explanation.
Short Explanation
Think of Terraform as the builder you hire to install the safe, not the person who knows the combination. Let it create the secret container and the policy, and let the rotation function own what goes inside. Anything that reads or writes the value drags the password into state.
Full Explanation
Splitting ownership avoids two problems at once. Terraform manages the aws_secretsmanager_secret resource, which is the container with its name, encryption key, rotation settings and resource policy, while the rotation function creates and updates the secret values. Because Terraform never writes or reads a secret version, the password never appears in plan or state, and Terraform never tries to revert a rotated value. Managing a secret version with a password and ignore_changes still stores the initial password in state, and that value is a real credential until the first rotation. A data source that reads the current version persists each rotated password in state on every run, which is the exposure the requirement forbids. Supplying the value from a sensitive variable means Terraform holds the password, stores it in state, and overwrites whatever the rotation function set, so the two systems fight each month. Exam caveat: when Terraform must set an initial value, newer AWS provider versions offer a write-only secret string argument fed by an ephemeral value, which keeps it out of state. Operational check: run terraform plan after a rotation and confirm no changes, then confirm the state contains the secret's metadata but no secret version resource.