Desired State Configuration (DSC)
Start course
1h 21m

Microsoft Azure is a robust, feature-rich cloud platform used by a growing number of technology companies. With its vast array of services, a key challenge to administering an Azure environment is security. How can we ensure that our Azure infrastructure meets strict security standards? This course offers the answer.

In three concise units, the student will learn all about compliance and cloud security. The course delves into several key Azure components, including Azure DevOps, Azure Security Center, Desired State Configuration, and Azure Pipelines. After completing the lessons and watching the video demonstrations, the student will be equipped with the knowledge to automate critical security tasks to ensure a thoroughly hardened cloud architecture.

This skill set will serve infrastructure developers working with live environments or seeking to pass certification exams. Most importantly, it will help students understand cloud security in a comprehensive and thorough way.

For feedback, queries, or suggestions relating to this course, please contact us at

Learning Objectives

  • Scan infrastructure using Azure tools to prevent drift leading to compliance violations
  • Automate configuration using Azure Automation and Desired State Configuration
  • Create secure and compliant software pipelines in Azure

Intended Audience

This course is intended for:

  • Those looking to learn more about the security and compliance features in Azure
  • People studying for Microsoft's AZ-400 exam


To get the most from this course, you should already have a basic understanding of Microsoft Azure as well as some knowledge of programming and cloud infrastructure. 


If you are an infrastructure engineer responsible for managing an Azure environment, Azure Desired State Configuration is your friend. Desired State Configuration, or DSC for short, is a declarative PowerShell platform that lets you turn infrastructure into code.

Infrastructure as code is not really a new concept, but it is a powerful one. Cloud infrastructure has to be managed and accounted for somewhere. When it isn't in code, it usually ends up in a dozen other places, scripts, developer laptop BASH history, Chef server logs, and data bags, and YAML files on a forgotten server. The table in an SQL database, a product manager's email, a post-it note on someone's monitor, etc, etc. Managing infrastructure configuration is very hard when it isn't transparently all in one place. This is the problem the whole infrastructure as code thing is meant to solve. Ideally, our infrastructure is defined in a shared audited version-controlled repository in GitHub or somewhere like it.

DSC lets us do exactly that using Powershell. If you've ever worked with tools like Chef or Puppet or Terraform, then you can start to get a mental picture. In DSC there are three basic concepts: resources, configurations, and the local confirmation manager, or LCM. Resources are the things: Azure VMs, individual files, processes, and other Azure assets. Think of them as our nouns, the object of our configurations. Configurations then, as you may have guessed, are like verbs. They describe the desired state of our resources. Configurations can incorporate a wide variety of parameters. We will dive into an example in a moment. But let's go to lastly, the LCM, the local configuration manager. This is the brain of the operation, responsible for ensuring our resources are in sync with our configuration. The LCM continuously pulls the state of our infrastructure to ensure everything is running as defined.

Now here's a very simple example. Take a look at this. This includes a single named configuration referencing a single node called TEST-PC1. Node resources are our Azure VMs. These are Windows host and the configuration type here is a Windows feature. Each gets its own block and we're defining a parameter for that feature. Here specifically a flag, ensuring a named feature is present.

So how do we actually use this configuration code? There are two prerequisites both of which, thankfully, can be done right from the web browser. First of all, the VMs needs to be connected to DSC. This just requires going into your automation account, clicking on DSC, and then selecting add to connect the node to DSC. Secondly, you need to upload and compile the configuration code. So you have your .ps1 config text file locally on your laptop and what you can do from the dashboard is upload it or copy paste it using the configuration editor. You can also do this using CLI tools. Once the config is uploaded you need to compile it. 

Now, this just makes sure that there are no syntax errors or problems before the config is applied. Once these two steps are done, connecting the VM to DSC and then compiling the config after uploading it, you can just apply the config to the desired node right in the web portal with a simple point and click. Now, this should give you a sense of how configurations and resources look in actual code.

But we can't forget about the third element, the LCM. The local configuration manager actually has its own configuration. We can adjust how frequently the LCM executes configurations and we can toggle the LCM back and forth between the push and pull model. The push model is the default, where the LCM server will just regularly push configurations out to all designated resources. The latter pull model allows for more flexibility as this requires you to define some form of pull service. This lets you specify for individual resources exactly which pull service endpoint to use for config or resources.

And then finally we should mention that DSC has support for partial configurations. That is pulling configuration from multiple sources and then combining them into one complete config. This might sound strange but there is a reason for this use case. It can be done in both a push model and a pull model. Now this more complex use case, what it does actually is it adds a really interesting flexibility to your configuration management paradigm.

So here's an example scenario where this might be helpful. Imagine you're in a larger team with different groups of developers and these different groups of developers have specific responsibilities. So for example one team is responsible for the database config and another team is responsible for app config. Using partial configurations, each team can define their own part of the system and then use DSC to assemble it all come deployment time.

Okay, so now we have some basic understanding of Azure DSC. This is crucial before we move on into the next level of automation. DSC is really just a subset of our Azure Automation Account. Before we can see how it relates to security compliance we'll need to explain how we can effectively administrate DSC infrastructure, how we can manage it. The next lesson will cover that and include a demo showing how to actually utilize DSC scripts. See you there.


Useful Links


Course Introduction - Compliance & Security Scanning - Security Center Demo - Preventing Drift - ARM, Activity Log & Track Changes Demo - Azure Desired State Configuration Demo - Azure Automation State Configuration - VM Agents & Extensions - VM Agents & Extensions Demo - Security & Compliance Pipelines - Azure Pipelines & Gates Demo - Course Summary

About the Author

Jonathan Bethune is a senior technical consultant working with several companies including TopTal, BCG, and Instaclustr. He is an experienced devops specialist, data engineer, and software developer. Jonathan has spent years mastering the art of system automation with a variety of different cloud providers and tools. Before he became an engineer, Jonathan was a musician and teacher in New York City. Jonathan is based in Tokyo where he continues to work in technology and write for various publications in his free time.