Several running services authenticate to a partner API with a key that Terraform provisions. The key must be rotated without any service losing access during the change. Which sequence achieves this?
Select an answer to reveal the explanation.
Short Explanation
Rotating a live credential is like changing a tyre on a moving car: you bolt on the new one before you take the old one off. Run both keys side by side, move every service over, check they're happy, and only then revoke the old one. create_before_destroy sounds right, but it deletes the old key before your services have switched.
Full Explanation
Zero-downtime rotation relies on an overlap period in which two valid credentials exist. In Terraform this usually means adding a second key resource, or a second for_each entry, applying it, updating every consumer through its own deployment, confirming traffic uses the new key, and removing the old key in a separate change. Because consumers move at their own pace, the revoke step must be decoupled from creation. create_before_destroy orders replacement so the new object exists before the old one is destroyed, but both happen in the same apply; services still configured with the old key fail as soon as it is deleted. Revoking first guarantees an outage, however short, which breaks the requirement. Forcing replacement with -replace destroys and recreates the key in one operation and has no knowledge of services outside the configuration, so it does not update them. Exam caveat: some providers cap the number of keys per identity, so check limits before planning an overlap, and record which key each service uses. Operational check: after switching consumers, confirm through the partner's usage logs that the old key has no recent requests before applying the change that removes it.