VM Agents & Extensions
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. 


We can see that Azure Automation State Configuration, AASC, and DSC work together as a unit to help manage state changes in our system in an automated and transparent manner. The tool set we have covered is quite solid for defining, deploying, and updating Azure resources, particularly VMs, in exactly the form we want. But what about post-deployment configuration on actual running virtual machines? DSC is great for onboarding nodes and has some support for updating config, particularly Windows nodes if we have commands to force poll the latest configuration. However, if we have more precise configuration to do on various running instances, we need something more surgical.

This is the use case that the Azure custom script extension was meant to solve. It is designed specifically for post-deployment actions.

Note that the custom script extension is not the only extension available to Azure VMs. There are lots other useful extensions such as the VM access extension and the diagnostics extension. These may be helpful for access control and monitoring respectively. The custom script extension, as the name implies, is designed purely for running any sort of arbitrary script on target instances. It gives you the flexibility to handle any sort of administrative, monitoring, software installation, or maintenance task.

So let's talk a little bit about extensions generally. How do these extensions work? Do we just copy/paste code snippets somewhere? Not exactly, Azure utilizes lightweight processes in their VM's known as agents to manage extensions. An Azure VM agent is a small background application that lets you run various extensions and interact with Azure APIs. VM agents are installed and running by default in any Windows marketplace VM in Azure. You can install VM agents on Linux servers as well very easily. There are official RPM and DEB packages available on most popular Linux flavors. See the documentation link and GitHub page for specifics.

VM agents give us a flexible way of interacting with running servers without having to worry about firewalls and ssh sessions. If a VM has an agent running, executing a custom script is as easy as a CLI command. We use the Set-AzVMExtension command and set the ExtensionType flag to CustomScriptExtension. There is another flag for the actual terminal command to run on the VM which may just be a random shell command or a call to some other script on the server

So how exactly do custom scripts fit into our overall compliance and security model? Being able to run arbitrary scripts thanks to the VM agent is nice and all, but engineers randomly running scripts is not a hallmark of a stable system. As with any tool if we are not mindful about how we use it we could end up only creating new problems.

We saw in the previous two lessons that Azure ASC security center and automation state configuration, and DSC, they allow us to centralize our configuration and track compliance automatically. However, we may not be able to prevent all types of configuration drift. There may be low-level environment settings we need to tune that are not exposed by the DSC API. In such a scenario we might want to update config on live servers without editing our DSC code. We may even want to do this while simultaneously adding or updating cronjobs. Well, custom scripts are perfect for this sort of maintenance.

We will conclude this section with a brief demo so that you can actually see how custom scripts work in the real world. Otherwise, this is probably gonna seem too abstract. Once you get through that demo about agents and extensions, you'll be ready for the final section of this course on pipelines. It's gonna be a blast, see you there.


Course Introduction - Compliance & Security Scanning - Security Center Demo - Preventing Drift - ARM, Activity Log & Track Changes Demo - Desired State Configuration (DSC) - Azure Desired State Configuration Demo - Azure Automation State Configuration - 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.