This is a continuation of articles on IaC shortcomings and resolutions. As a recap of several articles, this section brings to light what has worked and what hasn’t across a diverse and complex set of deployments. 

1. Cloud is our friend in its ability to provide management free, elastic, performant and highly available resources that can be reached from around the world. Transition from on-premises while requiring migration and modernization concerns are not insurmountable and the final state as cloud native deployments is very appealing in the long run.

2. Resources transition from preview to general acceptance as various cloud services become more mainstream. Since they are developed and made generally available independent of each other, many mature and lower the users concerns in their usage. Leveraging these built-in features over customizations holds us in good stead as it is maintenance free.

3. Anything managed is good including networks, storage and compute if the resource or set of resources to be deployed give that option. Taking the example of an Azure Machine Learning Workspace over an Azure Databricks instance, storage accounts, key vaults, managed virtual network are tightly integrated with the managed option and eschews rediscovery by hands-on configuration.

4. Complex deployments have a significant number of configuration parameters that can quickly get out of hand and require a large test matrix. Capturing them in Infrastructure-as-code with source control is helpful to both repeatable deployments as well as curating best practices.

5. The final state of the resources on their deployment must meet all the criteria so instead of working through the order of various steps and getting lost in the choices, it is better to work backwards from the final state once that has gained deliberation and buy-ins from stakeholders.

6. Zonal redundancy and regional disaster recovery are aspects that must be considered as early as design and implementation. They are not an afterthought and must be judiciously chosen to conserver resources and costs without detriment to the business continuity

7. Most workspaces and resources with public ip connectivity grow feet in the form of private endpoints to gain private plane connectivity through virtual networks so that the connectivity and traffic are secured and there is less attack surface from the ubiquitous internet. Designating subnets for providing addresses to private endpoints from various resources is good practice. Only when private connectivity interferes with usage of resources via workspace notebooks or management views and requires jump hosts or Bastions, then both public and private connectivity might be required. For public connectivity alone, simple firewall rules to enumerate the source and destinations can thwart many attacks that might require otherwise have required costly setup like Defender

8. Cost is always a concern as they have a tendency to balloon with usage and keeping them nanageable requires attention to features that are used and those that aren’t and the process must be repeated at setup as well as an ongoing basis.

9. Just like built-in features, most resources come with diagnostics, troubleshooting and documentation as well as support, so leveraging them avoids lengthy investigations.

10. Naming convention is important to capture the variations possible to resources and do very weill with prefixes and suffixes that have well-known meanings.  Previous articles: https://1drv.ms/w/s!Ashlm-Nw-wnWhO8w-_97Fxz2IyBZog?e=R3wwt0