Technical Debt & Templates


Course Introduction
Course Conclusion
Start course

This course provides you with the foundational knowledge required to design an infrastructure and configuration management strategy. It starts by looking at hosting infrastructure — IaaS, PaaS, FaaS, and some modern native app options — before moving on to look at Infrastructure-as-Code. You’ll learn what Infrastructure-as-Code means and the tools and technologies that are used to deploy and manage it.

Next, you'll learn about some of the more common Infrastructure-as-Code tools and technologies: Terraform, Azure Resource Manager, Chef, Puppet, and more. You'll also learn about technical debt and how to deal with it in templates. The course then covers transient infrastructure and its role in the delivery lifecycle, before finishing off by looking at the mitigation of infrastructure state drift.

If you have any feedback relating to this course, please contact us at

Learning Objectives

  • Understand the main compute options available to host your infrastructure
  • Have a solid grasp of Infrastructure-as-Code (IaC) and its related tools and technologies 
  • Learn about technical debt and how to deal with it in templates
  • Learn about transient infrastructure and how it can speed up projects and reduce costs

Intended Audience

This course is intended for those preparing for Microsoft's AZ-400 exam, or anybody who wants to learn about designing an infrastructure and configuration management strategy in Azure.


To get the most from this course, you should have a basic understanding of Microsoft Azure and of DevOps concepts.


Hello and welcome to Technical Debt and Templates. In this lesson, we are going to look at what technical debt is and how to deal with it in templates.

Technical debt is a headache that is almost never-ending. It’s a concept in software development circles that refers to the cost of additional rework that often results from choosing to implement a quick and easy solution now, instead of implementing a more thought-out solution that would take longer to deploy. Technical debt is often incurred when developers are tasked with rushing a job to completion, rather than ensuring it is done right.

While technical debt doesn’t necessarily impact business functionality, it does make updating and troubleshooting more difficult. It undermines productivity because it makes code hard to understand, time-consuming to change, and difficult to validate. 

Technical debt typically starts out small and grows over time as rushed changes and features are implemented in existing code in an undisciplined manner.

The term “technical debt” refers to any tasks or work that a team must complete in order to deploy production code and to keep it running. Some examples of technical debt include performance issues that are encountered, bugs in code that are discovered, operational issues in production that must be addressed. Other examples of technical debt include changes that are made on the fly and situations where you need to switch to technologies that were not accounted for in the development process.

While technical debt is often a result of manual actions that are taken during the development process, it can also turn up in Azure Resource Manager templates, which are used to deploy and configure Azure resources.

When you think about it, during the process of deploying resources via templates, you’ll often find yourself retrieving information about the different resource providers and types. This is all well and good, but whenever a resource provider enables new features, a new version of the associated REST API is also usually released.  If you have components defined within your resource manager templates that rely on specific API versions, those components will usually need to be updated periodically. 

To address this issue with templates, what you should do is validate the API versions in those templates to ensure they are current. This should be completed as part of your general development work.

Although you are not likely to ever completely eliminate technical debt, you can manage it effectively if you take the necessary steps to do so.

To properly manage technical debt, you need to understand it and be able to locate it within your code. You should also weigh the costs of remediation versus non-remediation because, while fixing technical debt incurs costs, not fixing it also incurs costs – and the costs of not addressing that technical debt could very well be larger.

Taking proactive steps to enforce policies that specifically focus on preventing debt from becoming worse makes it easier to manage that debt.

Steps that you can take, for example, include planning for and completing periodic updates to your Microsoft Azure Resource Manager templates to account for new API versions. This should be done as part of your general development work.

You should also restrict manual configurations. Ensuring that no manual configurations are allowed goes a long way toward limiting ad-hoc changes that often result in more technical debt.

And since technical debt is virtually unavoidable, you should be sure that you track it over time to ensure that it’s shrinking, rather than growing. When you do identify technical debt, it should be remediated as quickly as possible – and as AUTOMATICALLY as possible.

You might even consider setting the priority of technical debt so that it’s just as important as the development of new application features. This ensures that it is addressed in an ongoing fashion.

Third-party tools like SonarQube can be used to quantify technical debt so that it can be addressed.

To learn more about SonarQube, visit the URL that you see on your screen:


About the Author
Learning Paths

Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.

In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.

In his spare time, Tom enjoys camping, fishing, and playing poker.