This is a continuation of articles on Infrastructure-as-code shortcomings to address deployment routines. One of the most frequently encountered situations is when a resource is deployed with a configuration that does not permit subsequent changes in place. This could be at any level such as from the vnet that a resource is hosted on along with its private endpoint and zone to a key in a keyvault that must be changed. Some errors encountered in such situations and their resolutions are now called out.

First, if a resource cannot be updated in place, it is widely assumed that it must be deleted and recreated. The setup and teardown are not onerous for an IaC based deployment which is by definition, idempotent and repeatable. However, it is also seldom known that delete might not always imply that another can be created with the same name.  Take for instance keys in a keyvault that is enabled for soft-delete. Even when the keys are deleted and no longer appearing in the list of keys, it still lingers.  This persists for 90 days. A new key with the same name cannot be created and a name change is required. When the name changes, all upstream usages also change which can be quite pervasive.

Second, taking backups also suffers from similar concern. A backup of a key in a keyvault can be downloaded and restored with but if the resource is enabled with soft-delete, then the restoration for a backup also fails. In this case, a new key is not created but the old key is restored and yet the problem is similar. Backups and restores are not limited to keyvaults and can span other data stores such as databases. How the resource is configured such as if soft-delete or purge protection which is similar to a lock of an item in a recycle bin, is enabled.

Third, another popular use case is when there is an interim state of deployment when resources are dual-homed. For example, moving a resource from one vnet to another, is often attempted with a private endpoint added to the destination vnet. For a certain period of time, the resource has addressability in both networks until the old one is decommissioned. It is also perfectly fine for a resource to have multiple private endpoints. However, the point that escapes attention often is that the old one cannot be deleted and lingers resulting in the interim state becoming a permanent solution.  To add to this complexity, the private endpoints do not solve all addressability concerns and often disable public IP connectivity.  Traffic flow from different virtual networks might not have the same gateway and dedicated outbound subnets can only be one per resource. In these cases, new deployments and migration of workloads offer a simpler alternative.