Some of the common issues faced during the authoring and deployment of Infrastructure-as-Code aka IaC artifacts can be called out as follows:

First, the IaC provider might not support all the attributes of a resource as that of the resource provider or vice versa if the IaC is declaring attributes as independent of resource providers. They have different development cycles and there might be lag between the catch ups that they do. This might be more conspicuous when the resources are “preview-only” features instead of the mainstream “general-acceptance” offerings.

Second, the syntax and semantics might not have parity even when there are one-to-one mappings between the IaC providers’ attributes and the resource providers’ attributes. For example, the key vault secret id might refer to the resource id, the identifier without the version or the base id of the corresponding guarded secret. In these cases, it would have been helpful if the same name was used for attributes in both places, otherwise some head-scratching is inevitable.

Third, the friendly names are often references to actual resources that may have long been dereferenced, orphaned, changed, expired, or even deleted. The friendly names, also called keys, are just references and hold value to the author in a particular context but the same author might not guarantee that the moniker is in fact consistently used unless there are some validations and review involved.

Fourth, there are always three stages between design and deploy of Infrastructure-as-code which are “init”, “plan” and “apply” and they are distinct. Success in one stage does not guarantee success in the other stage especially holding true between plan and apply stages.  Another limitation is that the plan can be easily validated on the development machine but the apply stage can be performed only as part of pipeline jobs in commercial deployments. The workaround is to scope it down or target a different environment for applying.

Fifth, the ordering and sequence can only be partially manifested with corresponding attributes to explain dependencies between resources. Even if resources are self-descriptive, combination of resources must be carefully put-together by the system for a deterministic outcome.

Sixth, there is a state drift that occurs when the resources are changed without updating the IaC. The IaC provider might enforce an overwrite of resources with what’s defined in IaC but the iterative capture of IaC requires consolidation of all changes to the development cycle and this suffers from similar limitations that are rampant with those based on communications without acknowledgments.

Seventh, both the state update and its reconciliation are necessary aspects for the deployment process and consequently occur frequently. Behavior for these stages can only be articulated with a limited set of primitives such as create before delete, prevent from delete, ignore changes and others. The simpler the deployment model by virtue of overwrite, the more complex the process to ensure that everything flows into the IaC.

Eighth, access control declarations such as role assignments and permissions can often number quite large and are fraught with errors. Including them in the IaC without discretion to apply as few and as granular as necessary, can only increase maintenance.

These are only some of the articulations for the carefulness required for developing and deploying IaC.