aws_iam_role_policy_attachment Lacks Compensation for Eventual Consistency

[FGS-BMarkham]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.11.7
+ provider.aws v1.21.0

Affected Resource(s)

• aws_iam_role_policy_attachment

Terraform Configuration Files

https://gist.github.com/FGS-BMarkham/1029a0a72df5e1d2dacd90aede00d1a8#file-main-tf

Debug Output

https://gist.github.com/FGS-BMarkham/1029a0a72df5e1d2dacd90aede00d1a8#file-debug-log
(Plan + Apply)

Panic Output

N/A

Expected Behavior

Plan successfully applies, resulting in created Option Group with an Option Settings entry pointing to the previously created Role.

Actual Behavior

* aws_db_option_group.main: Error modifying DB Option Group: InvalidParameterValue: IAM role ARN value is invalid or does not include the required permissions for: SQLSERVER_BACKUP_RESTORE

Steps to Reproduce

1. Author (or acquire my example of) a Terraform configuration that creates an IAM Role, IAM Policy, IAM Role+Policy Attachment, and an RDS Option Group that implicitly relies on said attachment (a SQLSERVER_BACKUP_RESTORE option pointing to the role ARN)
2. terraform plan
3. terraform apply

Important Factoids

• This appears to be an example of AWS IAM presenting eventual consistency, as demonstrated in aws_iam_user_policy: User creation / policy attachment race condition #2449.
• This unexpected behavior can be mitigated by inserting an arbitrary wait via the use of local_exec

References

• aws_iam_user_policy: User creation / policy attachment race condition #2449

[bflad]

Hi @FGS-BMarkham 👋

In these situations, we tend to implement the retry handling in the downstream resources as even when we can guarantee a few positive results with the IAM service, other downstream services might not recognize new or updated information.

Your timing here is pretty good though -- we actually just merged a fix for this with the aws_db_option_group resource for exactly this case in #5389. It will be released in version 1.30.0 of the AWS provider, likely tomorrow. 👍

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!