How to address IaC shortcomings?

Dependencies between instances of the same resource types go undetected in Infrastructure-as-code aka IaC but are still important to resource owners. The knowledge that two resources of the same resource type have a dependency as a caller-callee cannot remain tribal knowledge and impacts the sequence at the time of both creation and destruction.  Different IaC providers have different syntax and semantics associated with expressing dependencies, but none can do away with it. At the same time, their documentation suggests using these directives as a last resort and often for one resource type dependency on another. In such cases, some prudence is necessary.

When the dependency is an entire module, this directive affects the order in which the deployment rolls out. The IaC runtime will process all the resources and data sources associated with that module. If the resource requires information generated by another resource such as its assigned and dynamic public IP address, then those references can still be made part of the attributes of this resource without requiring the directive to declare dependencies. The runtime will know that the references imply and implicit dependency.  In such cases, it is not necessary to manually define the dependencies between on other resources. When the dependencies are hidden such as access control policies must be managed and actions must be taken that require those policies to be present, then the directive becomes necessary. This directive does not impact replacements when the dependency undergoes a change. For that reason, a different directive is specified to cascade parent resource replacements when there is a change to the referenced resource or attribute.

At the time of deployment, none of the resources are operational. So, caller-callee relationships do not justify a depends_on directive to be specified. Also, if for any reason one resource was required to be present for the other to be created, the idempotency of the IaC allows the deployment to be run again so that if that creation order is not met, it will succeed the next time over because one of the two resources would go through since there is at least one that does not have a dependency.  If a dependency must still be specified to get the order right the first time between resources of the same resource type, it is possible to sequentially specify them in the IaC source code. Finally, if the program order is not maintained correctly, it should be possible to introduce pseudo-attributes to these two resources of the same resource type that define different references to other hybrid resource types that have predetermined order established by virtue of being different resource types.  These marginal references can be made to local-only resources such as those for generating private-keys, issuing self-signed TLS certificates, and even generating random ids. These serve as the same glue to help connect “real” infrastructure objects. These local resources have the added advantage of being shallow as in being visible only to the IaC runtime and not the cloud as well as being persisted only in the state referenced by the runtime.

Finally, the dependency information can indeed be used as a last resort by storing all dependencies in a separate store that can be queried dynamically at the time that the dependency information becomes relevant