# Securing Azure IaaS and Containerized Workloads

> Chapter 12 of the Courseiva SC-100 curriculum — https://courseiva.com/learn/sc-100/azure-iaas-and-container-security

**Official objective:** 4.3 — Design solutions for securing Azure infrastructure and containers

## Introduction

How do you protect a house you do not fully own, and how do you lock down a container whose whole life lasts only a few minutes? Those are the twin problems this chapter solves for anyone studying for the SC-100 exam. You will learn why shifting from trusting the physical hardware to trusting nothing at all is the single most important mindset change for a Microsoft Cybersecurity Architect.

## The High-Security Apartment Building Analogy

Because you first have to secure the building's shell and structure before you can safely rent out individual flats, this leads to a clear separation of responsibilities between the landlord and each tenant. In a high-security apartment building, the landlord (the cloud provider in IaaS and your organisation in container security) controls the physical structure: the walls, the foundation, the main electrics and the building's perimeter locks and security cameras. Each tenant (you, the IT professional) is responsible for everything inside their own flat: the deadbolt on the front door, the internal Wi-Fi password, whether they leave windows open or have a faulty toaster that could start a fire.

Now, imagine a different scenario inside that same building: a 'Containerised Workload' is like a rent-controlled micro-flat that is built and torn down in seconds. It shares the building's plumbing and electricity, but the tenant has no control over the walls – they are pre-fabricated. The landlord's job is to ensure that the shared plumbing between flats never leaks toxic water (a privilege escalation vulnerability) into the micro-flats. The tenant's job is to make sure they don't bring in a dangerous space heater (a compromised software dependency) that could melt the shared pipes and flood the entire floor. In both cases, you must trust the landlord for the base structure, but you absolutely cannot trust that another tenant hasn't left a gas leak in their flat, which is why you must have your own fire alarm and a plan to evacuate.

## Core explanation

Let's start with the basics. IT infrastructure is just the collection of hardware and software that runs all the applications you use, from your email to your banking app. For decades, companies bought and managed this hardware – servers, network cables, hard drives – inside their own buildings. That was expensive and slow.

Then came the cloud. Cloud computing lets you rent that hardware from a provider like Microsoft, Amazon or Google. They own the physical data centres; you use the power over the internet. Azure is Microsoft's cloud platform. Within Azure, you have different service models. The two this chapter focuses on are IaaS (Infrastructure as a Service) and containers.

IaaS is like renting a raw, empty apartment. Azure gives you a Virtual Machine (VM) – a simulated computer that runs inside Microsoft's data centre. You get to choose the operating system (Windows or Linux), the amount of memory and the number of CPUs. You are responsible for everything inside that VM: installing updates, configuring the firewall, managing user accounts. Azure is responsible for keeping the physical server powered on and connected to the internet.

A container is far more lightweight. Instead of running an entire operating system, a container runs just the application and its essential libraries. It shares the host operating system of the server it lives on. Think of it as a shipping container: it is standardised, it packs tightly with other containers, and you can load it onto any ship (any host operating system) that supports containers. Containers start in seconds. They are perfect for modern, scalable applications.

Azure Kubernetes Service (AKS) is the main service for managing lots of containers together. 'Kubernetes' sounds complicated, but it is essentially a traffic management system for containers. It decides which container goes on which server, restarts containers that crash, and scales them up when more users arrive. It is a container orchestra: you tell it what music you want to play, and it directs the musicians (containers) to play perfectly.

Now, why does this matter for security? Because your security model must change completely.

In the old world, you could trust your physical network. The cables were in your building. No one could tap them. In IaaS, you share a physical server with another customer's VM. You cannot trust the network cable. You must encrypt everything inside your VM, assume the network is hostile, and use Azure's tools to micro-segment traffic.

In the container world, the problem is even harder. Containers are ephemeral – they live for minutes, not years. You cannot patch a container like you patch a server. Instead, you must build security into the container image from the start. An image is a snapshot of the container's file system: the application code, the libraries, the configuration files. If you build an image with an old, vulnerable library (like an out-of-date web server), every container created from that image is vulnerable from the moment it starts.

The core principle for both IaaS and containers is 'defence in depth'. You do not rely on one single security control. You layer them. For IaaS, that means:

- Network Security Groups (NSGs): acting as a software firewall at the VM boundary, blocking traffic you do not want.
- Azure Firewall: a more powerful, centrally managed firewall for controlling traffic across your whole Azure network.
- Azure Policy: rules that enforce security settings automatically, like 'no VM can have a public IP address'.
- Just-In-Time (JIT) access: Not leaving administrative ports open 24/7. Instead, you request temporary access for a specific task, and Azure opens the port for a few minutes only.
- Disk encryption: using Azure Disk Encryption to scramble the data on the VM's hard drive so that even if someone steals the physical disk, they cannot read the data.

For containers, the layers are different:

- Image scanning: automatically checking the container image for known vulnerabilities before it is ever deployed.
- Runtime protection: monitoring the running container for suspicious behaviour, like it trying to access the host operating system's kernel.
- Secret management: never hardcoding passwords or API keys inside the container image. Use Azure Key Vault to inject them securely at runtime.
- Network policies: controlling which containers can talk to each other, even inside the same cluster.
- Immutable infrastructure: you never patch a running container. You delete it and replace it with a new, patched image.

Finally, the concept of 'zero trust' is the glue that holds all of this together. Zero trust means 'never trust, always verify'. In an IaaS context, it means not assuming that because a VM is inside your Azure virtual network, it is safe. You still require authentication and authorisation for every request between VMs. In a container context, it means the container micro-flat does not trust its neighbour, and it does not trust the host operating system completely.

## Real-world context

Imagine you work for 'Contoso Ltd', a medium-sized e-commerce company that runs a website selling artisan coffee. Your IT team has just migrated the website from an old server under someone's desk to Azure. You are tasked with securing the new setup.

First, you design the IaaS layer. You create three VMs: one for the web server, one for the application server that processes orders, and one for the database. You place them inside an Azure Virtual Network (VNet) – a logically isolated network in the cloud.

Your first real-world action: you configure Network Security Groups (NSGs). You attach an NSG to each VM's subnet. You write a rule that only allows traffic from the internet to hit the web server on port 80 (HTTP) and port 443 (HTTPS). You write another rule blocking the web server from directly talking to the database. All application server to database communication must go through a specific application programming interface (API) that you have secured. You explicitly deny all other inbound traffic.

Next, you implement Just-In-Time (JIT) access for your administrative Virtual Machine, which is the jump box you use to manage the other VMs. You configure Azure Security Center to manage this. Now, when you need to remote desktop (RDP) into the jump box, you first request access through the Azure portal. Azure opens the RDP port (3389) for your specific IP address for two hours. After that, the port closes automatically. No one can brute-force their way in 24 hours a day.

You then move to the container layer. Contoso's development team builds a new feature: a recommendation engine that suggests coffee blends to customers. They package it as a container and want to run it on Azure Kubernetes Service (AKS).

Your first real-world action at the container level: you integrate ACR (Azure Container Registry) with Microsoft Defender for Cloud. Every time a developer pushes a new container image to the registry, Defender for Cloud automatically scans it. It detects that the image uses an old version of a Python library with a known critical vulnerability. The push is blocked. The developer must rebuild the image with the updated library. This prevents a vulnerable container from ever reaching production.

You then set up network policies inside the AKS cluster. The recommendation engine container must only talk to the application server container and nothing else. You create a Kubernetes Network Policy that isolates the recommendation engine from the web server container.

You also enforce that no container runs as the 'root' user (the most powerful user inside a Linux system). If an attacker compromises a container running as root, they can easily break out of the container and control the host. You use Azure Policy for AKS to enforce that every container must run with a non-root user ID.

Finally, you set up monitoring. You use Azure Monitor and Container Insights to watch for unusual behaviour: a container that suddenly starts trying to execute system commands, or a container that tries to communicate with a suspicious external IP address. If such behaviour is detected, an alert triggers and the container is automatically restarted using a clean image.

In a real-world scenario, you would also conduct a 'Bastion' deployment. Azure Bastion is a fully managed service that gives you secure RDP and SSH access to your VMs directly through the Azure portal, without needing a public IP address on the VMs themselves. You deploy Bastion in your VNet, and all administrative connections are encrypted and audited. The audit logs are sent to Azure Log Analytics so they can be reviewed during security audits.

## Exam focus

The SC-100 exam is not a 'how-to' exam; it is a 'design and architect' exam. You will not be asked to type out a PowerShell command or configure a firewall rule in the exam interface. Instead, you will be given a business scenario and asked to choose the correct architectural design from four options. The questions are often long, with many details designed to distract you.

Here is exactly what they test about 'Securing Azure IaaS and Containerized Workloads':

- **Shared Responsibility Model questions**: The exam loves to test your understanding of who is responsible for what. For IaaS, the customer is responsible for everything inside the VM (OS, apps, data, network configurations). For containers, the customer is responsible for the container image, secrets, and network policies. For AKS, Microsoft manages the master control plane; you manage the worker nodes and the workloads. A common trap question describes a security incident and asks who is to blame. The correct answer always aligns with the shared responsibility model. If you chose 'Microsoft' for an incident caused by an unpatched application inside your container, you would be wrong.

- **Defence in depth for IaaS**: You will see questions that list a set of security controls and ask which one is missing. They love to test NSGs, Azure Firewall, Azure Bastion, Just-In-Time VM access, and Azure Disk Encryption. They might present a scenario where a company only uses NSGs and leaves RDP open to the internet for all VMs. The correct answer is to recommend implementing JIT VM access and Azure Bastion to remove the public RDP endpoint.

- **Container security lifecycle**: The exam covers the entire lifecycle: build, deploy, and run. At the 'build' stage, the key concept is container image scanning and using a trusted base image. At the 'deploy' stage, the key concepts are Azure Policy for AKS (to enforce non-root, read-only root filesystem), network policies, and secret management with Key Vault. At the 'run' stage, the key concepts are runtime threat detection (Defender for Containers) and limiting resource usage (to prevent container escape). The trap often presents a solution that only covers one stage, when the correct answer covers all three.

- **Network policies in AKS**: A recurring trap is confusing Azure Network Security Groups with Kubernetes Network Policies. An NSG operates at the Azure network layer; a Kubernetes Network Policy operates inside the cluster. If a question asks 'how to isolate containers from each other inside AKS', the answer is not an NSG – it is a Kubernetes Network Policy. If the question asks 'how to block traffic from the internet to the AKS API server', the answer is an NSG or API server Authorised IP ranges.

- **Secrets management**: The exam will have a question where a company has passwords hardcoded in their container images. The correct answer is always: use Azure Key Vault with a pod identity or Azure Key Vault Secrets Provider for AKS. Never store secrets in the image.

- **Azure Arc**: This is a concept for hybrid and multi-cloud environments. Azure Arc lets you manage servers and Kubernetes clusters that are running outside of Azure (in your own data centre or on other clouds) as if they were Azure resources. The exam tests whether you can design a solution that uses Azure Arc to extend the same security policies (Azure Policy, Defender for Cloud) to on-premises containers. The trap: forgetting that Azure Arc has special prerequisites and that not all Azure security features are supported via Arc.

- **Host OS vs. container OS**: A subtle but important distinction. VMs have a full operating system you must patch. Containers share the host's OS kernel. If you run a container on a host with an old, vulnerable kernel, all containers on that host are vulnerable. The exam might test whether you choose to patch the host OS or replace the container image. The correct answer: patch the host OS (the node) and then drain and restart the pods. Do not try to patch the container itself.

- **Pricing and scaling considerations**: The exam expects you to consider cost in your design. For example, using Azure Bastion is more expensive than using a basic jump VM. The question will state a budget constraint, and you must choose the most appropriate secure solution that fits that budget.

## Step by step

1. **Assess Shared Responsibility** — You identify which components of the solution are your responsibility and which are Microsoft's. For IaaS, you list everything: OS patching, application security, network firewall rules, data encryption. For containers, you list the container image security, secret management, and network policies. This step defines the boundary of your work.
2. **Design Network Segmentation with NSGs and Azure Firewall** — You create a Virtual Network (VNet) and divide it into subnets for different tiers (web, app, data). You apply a Network Security Group to each subnet with strict inbound and outbound rules. You deploy Azure Firewall to inspect and log traffic between VNets and to the internet. This step prevents an attacker from moving laterally once inside.
3. **Harden Virtual Machine Access with Bastion and JIT** — You deploy Azure Bastion in the VNet to provide secure, audited administrative access. You enable Just-In-Time VM Access via Microsoft Defender for Cloud to ensure administrative ports (RDP 3389, SSH 22) are closed by default and only open when a specific user requests access and is approved. This step removes the risk of brute-force attacks on exposed ports.
4. **Integrate Container Image Scanning and Policy Enforcement** — You connect Azure Container Registry (ACR) to Microsoft Defender for Cloud so every pushed image is automatically scanned for known vulnerabilities. You then apply Azure Policy for AKS to enforce rules, such as 'containers must run as non-root user' and 'containers must have a read-only root filesystem'. This step ensures no vulnerable or misconfigured container is ever deployed.
5. **Configure Kubernetes Network Policies and Runtime Monitoring** — You create Kubernetes Network Policy objects that isolate pods (groups of containers) from each other. For example, only allowing the front-end pod to talk to the back-end API pod. You enable Container Insights in Azure Monitor and configure alerts for suspicious runtime behaviour, such as a process spawning a shell or outbound traffic to a known malicious IP. This step contains breaches and enables rapid detection.

## Comparisons

### IaaS (Virtual Machine) vs Containers (AKS)

**IaaS (Virtual Machine):**
- Full operating system responsibility, including patching the OS kernel.
- Long-lived resource: a VM can run for years without being rebuilt.
- Security relies heavily on network segmentation and host-based firewalls.

**Containers (AKS):**
- Shares the host OS kernel; you only patch the worker node OS, not the container itself.
- Ephemeral: containers are designed to be destroyed and recreated often.
- Security relies on image scanning, runtime policies, and Kubernetes Network Policies.

### Network Security Group (NSG) vs Azure Firewall

**Network Security Group (NSG):**
- Stateful firewall that operates at the subnet or NIC level.
- Free of charge; no additional cost beyond the Azure subscription.
- Limited to layer 3/4 filtering (source/destination IP, port, protocol).

**Azure Firewall:**
- Stateful firewall-as-a-service with centralised management across VNets.
- Paid service with costs based on data processed and hours deployed.
- Offers layer 3/4 and layer 7 inspection (application filtering based on FQDNs).

### Just-In-Time VM Access (JIT) vs Azure Bastion

**Just-In-Time VM Access (JIT):**
- Temporarily opens the RDP/SSH port for a specific user and source IP.
- Does not provide a web-based UI; requires an RDP/SSH client on the user's machine.
- Only grants access for a configurable time window (e.g., 3 hours) then closes the port.

**Azure Bastion:**
- Provides persistent, seamless RDP/SSH access through the Azure portal in a web browser.
- Eliminates the need for a public IP on the VM; traffic goes through the Azure backbone.
- Always available; no time limit but logs all sessions for audit.

### Running container as root user vs Running container as non-root user

**Running container as root user:**
- Container has full administrative privileges inside the container namespace.
- If the container is compromised, the attacker can easily escalate to host root via known escape techniques.
- Azure Policy for AKS can be used to block this, but is not enforced by default.

**Running container as non-root user:**
- Container runs with a restricted user ID (e.g., UID 1001), limiting what it can do even if compromised.
- Drastically reduces the blast radius of a container escape attempt.
- Best practice enforced via Azure Policy for AKS: required for production workloads.

### Patcing: IaaS VM vs Patching: Containers

**Patcing: IaaS VM:**
- Apply security updates directly to the running operating system using Update Management or WSUS.
- The VM remains the same instance; it is rebooted to apply patches.
- Patches are often cumulative and can be tested side by side in a staging environment.

**Patching: Containers:**
- Do not patch the running container; delete it and deploy a new container from an updated image.
- The entire container is replaced with a new immutable instance.
- Relies on a CI/CD pipeline that rebuilds the image, scans it, and rolls out the update.

### Azure Policy for IaaS vs Azure Policy for AKS (Azure Policy for Kubernetes)

**Azure Policy for IaaS:**
- Enforces rules on Azure resources like VMs: e.g., 'all VMs must have disk encryption enabled'.
- Remediation: can automatically fix non-compliant resources (e.g., enable encryption).
- Evaluated at resource creation and on periodic compliance scans.

**Azure Policy for AKS (Azure Policy for Kubernetes):**
- Enforces rules on Kubernetes objects inside the cluster: e.g., 'containers must not run as root'.
- Remediation: can reject non-compliant pod creation at admission time (e.g., via OPA Gatekeeper).
- Evaluated in real time when a pod is submitted to the Kubernetes API server via admission webhooks.

## Diagram

_This diagram illustrates the shared responsibility model for Azure IaaS (Virtual Machines) and Containerised workloads (AKS), showing which components are owned by the customer versus Microsoft, and the defence-in-depth layers that must be applied._

```mermaid
flowchart TD
    A[Azure Cloud] --> B[IaaS - Virtual Machine]
    A --> C[Containers - AKS]
    B --> D[Customer: OS, Apps, Data]
    B --> E[Microsoft: Hypervisor, Host]
    C --> F[Customer: Image, Secrets, Policies]
    C --> G[Microsoft: K8s Master, Node OS]
    D & F --> H[Shared: Network, Encryption, Monitoring]
    H --> I[Defence in Depth Layers: NSG, FW, JIT, Policy, Runtime]
```

## Common misconceptions

- **Misconception:** Because it is called a 'shared responsibility model', Microsoft is responsible for securing my container application code. **Reality:** Microsoft is responsible for the physical security of the data centre and the security of the hypervisor (the software that runs VMs) and the Kubernetes master control plane. You, the customer, are 100% responsible for the security of your application code, the container image, all your data, and the configurations of your IaaS VMs. (People interpret 'shared' as meaning a 50/50 split across everything. In reality, the split is absolute: some responsibilities are entirely Microsoft's, and others are entirely the customer's. Beginners want to assume the cloud provider handles the hard part, but the opposite is often true: they give you the tools, and you must use them.)
- **Misconception:** If I use containers in Azure Kubernetes Service (AKS), I do not need to worry about patching operating systems because containers handle that automatically. **Reality:** Containers share the host operating system's kernel of the AKS worker node (the VM that runs the containers). You are responsible for keeping the worker node's operating system updated. While AKS offers automatic node image upgrades, you still need to configure and trigger them. The containers themselves are never patched in place; they are replaced with new images. (The marketing around containers emphasises 'lightweight' and 'fast', which leads beginners to think they eliminate all OS concerns. In reality, the host OS remains a massive attack surface. People forget that the kernel is shared, and a vulnerability there – like the Dirty Pipe vulnerability – affects all containers on that host.)
- **Misconception:** Encrypting my Virtual Machine with Azure Disk Encryption makes the VM completely secure against all threats. **Reality:** Disk encryption (using Azure Disk Encryption or server-side encryption) protects only against physical theft of the disk drives. It does not protect against an attacker who gains remote access to the running VM through a weak password or unpatched software. Once the VM is running, the data is decrypted in memory, and the attacker can access it if they have the right permissions. Disk encryption is one layer in a defence-in-depth strategy, not a silver bullet. (The word 'encryption' sounds absolute and final to non-experts. They hear 'encrypted' and think 'impenetrable'. They do not understand the difference between data at rest (on disk) and data in use (in RAM).)
- **Misconception:** Azure Security Groups (NSGs) alone are enough to secure all network traffic in Azure IaaS. **Reality:** NSGs are stateless or stateful (depending on the type) and work at the subnet or network interface level. They can control traffic between VMs and from the internet. However, they cannot provide deep packet inspection, application-level filtering (like blocking SQL injection), or centralised logging across many VNets. For that, you need Azure Firewall or a third-party network virtual appliance. NSGs are a necessary component, but they are not sufficient on their own in a large or regulated environment. (Beginners learn about NSGs first because they are free and simple. They assume that if they put an NSG on every VM, their network is safe. They do not realise that NSGs have limits on the number of rules and that they do not protect against application-layer attacks.)
- **Misconception:** Running a container as the 'root' user inside the container is safe because the container is isolated from the host. **Reality:** Running as root inside a container is dangerous because if an attacker manages to break out of the container (container escape), they automatically gain root access on the host operating system. Even without a full break-out, the root user inside the container can perform privileged operations that may affect the host's kernel. The security best practice is to run containers with the least privileges possible, typically a non-root user ID, and to enforce this with Azure Policy for AKS. (Many developers are used to running their applications as root during local development. They bring that habit to production and assume container isolation is perfect. They do not understand that isolation is a software-enforced boundary, and software has bugs. History shows that container escape vulnerabilities have been discovered and exploited.)

## Key takeaways

- In the shared responsibility model for Azure IaaS, Microsoft is responsible for the physical host and network; you are responsible for everything inside your Virtual Machine, including the OS, applications, and data.
- Containers are not a security silver bullet; they share the host operating system's kernel, meaning a host vulnerability can compromise all containers running on it.
- Defence in depth for IaaS requires layering Network Security Groups, Azure Firewall, Just-In-Time VM Access, and Azure Disk Encryption – never rely on a single control.
- For Azure Kubernetes Service (AKS), you must secure the entire container lifecycle: scan images at build time, enforce policy at deploy time, and monitor behaviour at runtime.
- Never store secrets like passwords or API keys inside a container image; always use Azure Key Vault to inject them securely at runtime.
- Just-In-Time (JIT) VM Access eliminates the attack surface of permanently open administrative ports by granting temporary, audited access only when requested.
- Zero trust applies to your Azure network: assume every other VM and container is hostile until proven otherwise, and authenticate every request.
- Azure Bastion provides secure RDP and SSH access to your VMs through the Azure portal without requiring public IP addresses on the VMs themselves.
- If a container is found to be vulnerable, do not patch it – delete it and deploy a new instance built from a patched container image.
- Kubernetes Network Policies control traffic between pods inside an AKS cluster and are distinct from Azure Network Security Groups, which control traffic at the Azure network boundary.

## FAQ

**What is the difference between IaaS and containers in terms of security responsibility?**

With IaaS, you are responsible for the entire Virtual Machine, including the operating system and all applications. With containers, you are responsible for the container image, the application code, and the secrets, but the host operating system's kernel is shared and managed by you (for the worker node) or by Azure (for serverless containers). In both cases, Microsoft handles the physical data centre.

**Do I need to patch container images?**

Yes. You do not patch a running container. Instead, you rebuild the container image using updated base images and libraries, scan the new image, and then deploy new containers from that fresh image. The old containers are deleted, and the new ones take over.

**What is Azure Kubernetes Service (AKS) and why is it important for security?**

AKS is Microsoft's managed service for running Kubernetes. It automates deploying, scaling, and managing containers. For security, AKS provides built-in integrations with Azure Policy, Microsoft Defender for Cloud, and Azure Key Vault, making it easier to enforce security best practices across a large cluster without managing the complexity of Kubernetes security yourself.

**What is the difference between a Network Security Group (NSG) and Azure Firewall?**

An NSG is a simple, stateful firewall that filters traffic at the subnet or network interface level. It is free and good for basic traffic rules. Azure Firewall is a managed, cloud-native firewall-as-a-service that provides application-level filtering (FQDN-based rules), outbound traffic inspection, and centralised logging. It is paid but offers much deeper control and threat intelligence integration.

**What does Just-In-Time VM Access actually do?**

It prevents attackers from scanning and brute-forcing your RDP/SSH ports by keeping those ports closed on the VM's network security group at all times. When an authorised administrator requests access through the Azure portal, Defender for Cloud temporarily opens the specific port (e.g., 3389) only for that administrator's source IP address for a configurable time window (e.g., 3 hours). After the time expires, the rule is removed, and the port closes again.

**What is 'container escape' and how do I prevent it?**

Container escape is when an attacker who has gained access inside a container manages to break out of the container's isolation and execute commands on the host operating system. To prevent it, never run containers as the root user, restrict the container's capabilities, use a read-only root filesystem, and keep the host OS kernel patched. Also, enable runtime threat detection from Defender for Cloud to alert on potential escape attempts.

**Can I use the same NSG rules for both IaaS VMs and AKS pods?**

You can apply NSGs to the subnet that hosts your AKS worker nodes, but NSGs do not control traffic between pods inside the cluster. For that, you must use Kubernetes Network Policies, which are rules written in YAML that define which pods can communicate with each other. For traffic coming from the internet to your cluster's load balancer, NSGs can be used to restrict source IP ranges.

## Check your understanding

1. **In the shared responsibility model for Azure IaaS, who is responsible for patching the operating system of the Virtual Machine?**

   Answer: The customer is responsible. Microsoft is only responsible for the physical host and the hypervisor; the customer must patch the OS, applications, and manage the VM's security configurations.

2. **What is the key difference between patching a container and patching a traditional VM?**

   Answer: You never patch a running container. Instead, you rebuild the container image from source, scan it, and deploy a new container from that updated image. A VM can be patched in place by applying updates and rebooting.

3. **Which Azure service should you use to temporarily grant an administrator access to port 3389 on a Virtual Machine, and then automatically close the port after the approved time expires?**

   Answer: Just-In-Time (JIT) VM Access, which is part of Microsoft Defender for Cloud. It temporarily opens the port for a specific user's source IP and then removes the rule.

4. **Name two controls you would implement on an Azure Kubernetes Service (AKS) cluster to prevent a container from breaking out to the host operating system.**

   Answer: First, enforce that containers run as a non-root user using Azure Policy for AKS. Second, set the container's root filesystem to read-only, which limits the ability to write malicious files that could aid an escape.

5. **A developer pushes a container image to Azure Container Registry that contains a known critical vulnerability. What is the most efficient way to prevent this image from ever being deployed to AKS?**

   Answer: Enable vulnerability scanning on the container registry via Microsoft Defender for Cloud, and set a policy to block the deployment of any image that has high or critical severity vulnerabilities. The push itself should be rejected or quarantined.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/sc-100/azure-iaas-and-container-security