Module 4 Review: Designing and Proving a Layered Azure VM Defense

Module 4 closes Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course with a recap, a scenario-based “Securing virtual machines” project, an assessment, and a learning reflection. The best way to review it is not to memorize one ideal portal configuration. It is to build a reusable method for deciding which threat a control addresses, how to validate that control, and what evidence proves it remains effective.

This article does not reproduce assignment instructions, graded questions, or answers. It also does not claim that a learner deployed the described controls in a real tenant or completed the course. The virtual-machine design below is an independent, hypothetical review framework. Use an authorized lab, follow the current Microsoft documentation, and obtain change approval before applying any control to a production workload.

1. Reconstruct the whole course as one security system

The four public course modules form a useful progression:

Module	Main scope	Operational question
1. Azure basic security capabilities	DDoS protection, virtual networks, Azure Firewall, WAF, JIT access, key management, encryption	How do I reduce the exposed attack surface?
2. Security management in Azure	Cloud security, Defender for Cloud, Bastion, Azure Policy, SIEM, Sentinel, SOAR	How do I apply guardrails and operate detections consistently?
3. Defender threat protection	Defender portal, XDR incidents, endpoint, identity, information protection, Sentinel connector	How do I connect signals into an attack story?
4. Assessment and wrap-up	VM security scenario, course review, reflection, next steps	Can I turn knowledge into a testable design and explain the tradeoffs?

A short memory model ties them together:

Prevent -> Limit -> Detect -> Respond -> Recover -> Prove

• Prevent: remove unnecessary public exposure, patch vulnerabilities, enforce safe defaults, and protect credentials.
• Limit: segment networks, minimize privileges, restrict management paths, and reduce the blast radius.
• Detect: collect control-plane, network, identity, endpoint, workload, and data signals.
• Respond: assign incidents, contain affected entities, remediate root causes, and communicate impact.
• Recover: restore trusted service and validate that the attacker no longer has access.
• Prove: retain configuration, logs, tests, approvals, and incident records that demonstrate the controls work.

Many weak designs stop at Prevent. Some mature detection designs stop at Respond. A production-ready design also includes recovery and evidence.

2. Begin with workload context, not a catalog of Azure services

Suppose the review target is a hypothetical business application running on two Azure VMs behind a web entry point. Administrators occasionally need RDP or SSH. The application stores customer data on managed disks, sends logs to a central workspace, and must remain available during a regional or network event.

Before selecting controls, write down the context:

1. Business impact: What happens if the application is unavailable, modified, or its data is disclosed?
2. Data: What classifications, retention duties, and encryption requirements apply?
3. Users and identities: Who administers the VM, which managed identities or service principals does it use, and which emergency accounts exist?
4. Connectivity: Which inbound and outbound flows are truly required? Is a public IP necessary?
5. Platform boundary: Which subscription, resource group, network, policy hierarchy, and Defender plans cover it?
6. Operations: Who patches, monitors, responds, restores, and pays for the controls?
7. Recovery: What are the recovery-time and recovery-point objectives, and when was restore last tested?

Without this information, “enable every security feature” can be both expensive and unsafe. A firewall with no application-flow inventory can interrupt service. A high-severity policy with no remediation owner creates permanent noncompliance. Encryption with no tested key-recovery process can turn a security control into an availability failure.

3. Build a threat-control-evidence matrix

The matrix below is not a universal answer to a course project. It is a reusable design worksheet for the hypothetical workload. Each row connects a realistic threat to preventive or detective controls, a validation activity, and evidence an operator can retain.

Threat or failure	Layered control choices	How to validate safely	Evidence to retain
Volumetric attack against a public endpoint	Resilient architecture, Azure DDoS Protection where justified, autoscale, health probes, incident plan	Review protected-IP coverage; configure metrics and alerts; use only approved simulation/testing services	Protection-plan assignment, protected IP inventory, alert rule, DDoS metrics and attack report
Web exploit such as SQL injection	Secure code and patching, WAF policy, restricted backend access	Test in a nonproduction environment with approved benign requests; inspect WAF mode and logs	WAF policy version, rule tuning decision, request log, remediation ticket
Unnecessary RDP/SSH exposure	No public VM IP, Azure Bastion or private access path, NSG deny-by-default, JIT where appropriate	Query effective NSG rules; request time-bound JIT access; verify expiry and denial from an unauthorized source	Effective-rule export, Bastion configuration, JIT request/audit record, source IP and expiry
Uncontrolled ingress or egress	NSGs, application security groups, Azure Firewall policy, route control, DNS strategy	Compare required-flow matrix to effective routes/rules; generate an authorized test flow	Firewall policy in source control, rule collection, flow/application logs, change approval
Stolen administrator credentials	Phishing-resistant MFA where supported, Conditional Access, PIM, least-privilege RBAC, privileged workstation	Review role eligibility and activation; test with dedicated accounts; validate emergency access separately	Role assignment/activation logs, sign-in and CA results, access-review decision
Malware or exploit on a VM	Patch management, endpoint protection and EDR, Defender for Servers, application control, attack-surface reduction	Confirm agent health and update compliance; use vendor-provided safe test artifacts only	Patch report, endpoint onboarding status, alert/incident ID, isolation or remediation record
Boot or kernel tampering	Trusted Launch, Secure Boot, vTPM, guest attestation where supported	Inspect VM security type and attestation health; review Defender for Cloud recommendations	ARM resource properties, attestation result, Secure Boot/vTPM compliance record
Disk theft, snapshot exposure, or key misuse	Managed-disk server-side encryption, encryption at host or confidential options when required, customer-managed keys only with an operational case, restricted disk export	Inspect encryption and disk network-access settings; test key rotation and recovery in a lab	Disk encryption settings, Key Vault access/rotation logs, policy compliance, recovery test
Configuration drift	Azure Policy initiatives, Defender for Cloud recommendations, infrastructure as code, reviewed exemptions	Deploy to a test scope; verify Audit/Deny/Modify behavior and remediation; simulate an expiring exemption	Assignment ID, compliance state, deployment record, exemption owner and expiry
Missed or fragmented incident	Defender for Cloud/XDR detections, Microsoft Sentinel, diagnostic settings, tested notification and ownership	Generate an authorized signal; trace source alert to incident, owner, action, closure, and retention	Alert and incident IDs, entity timeline, connector health, analyst comments, closure classification
Destructive change or ransomware	Least privilege, resource locks where appropriate, protected backups, immutability/soft delete options, isolated recovery credentials	Perform a scheduled restore test and verify application integrity, not only backup-job success	Backup policy, protected-item inventory, restore result, measured RTO/RPO, recovery approval

The matrix reveals gaps that a product checklist hides. A control with no validation method is an assumption. A validation with no retained result cannot support audit or post-incident learning. Evidence without an owner eventually becomes stale.

4. Design the network from the outside inward

DDoS protection and WAF are different layers

Azure DDoS Protection addresses network-layer availability attacks against supported public IP resources. DDoS Network Protection and DDoS IP Protection use different commercial models and value-added capabilities. A selection should be based on the number of protected IPs, criticality, support requirements, architecture, and cost—not on a belief that every VM automatically needs its own plan.

DDoS protection does not inspect application meaning. A layer 7 web attack requires application-layer protections such as secure development, timely patching, rate controls, and an Azure Web Application Firewall offering where appropriate. WAF also requires tuning. Leaving it indefinitely in detection mode provides visibility but not blocking; switching directly to prevention without reviewing false positives can break legitimate traffic.

Validation evidence should include protected resource coverage, alert and metric configuration, WAF policy mode, exclusions with owner and expiry, and a runbook for escalation. Never generate an unapproved load or DDoS test against a public service.

NSG and Azure Firewall have different jobs

Network security groups provide distributed layer 3/4 filtering at subnet or network-interface scope. Azure Firewall provides a managed, stateful, centralized policy and logging point for network and application traffic. One does not automatically eliminate the need for the other.

Use an explicit flow matrix before writing rules:

Source	Destination	Protocol/port	Business purpose	Owner	Log requirement
Web entry tier	Application VM subnet	Application port only	Serve approved backend requests	App team	Allow and deny visibility
Admin path	VM management interface	RDP/SSH, time-bound	Approved maintenance	Platform team	Identity and session evidence
Application VM	Required platform/dependency	Explicit service	Updates, telemetry, business dependency	App owner	Egress review

Then evaluate effective routes and effective security rules, not just the intended template. A technically correct firewall rule is still wrong if the route bypasses the firewall. Broad service tags and wildcards need a documented reason. Every temporary rule needs an owner and expiry.

Bastion and JIT address related but distinct risks

Azure Bastion provides a managed RDP/SSH access path to VMs over private IPs, reducing the need for public IP addresses on the VMs. Just-in-time machine access in Defender for Servers Plan 2 restricts selected management ports and opens them for an approved source and duration when requested.

Bastion changes the connection path. JIT changes when and from where a management port is allowed. They can be complementary, but neither answers all privileged-access questions. MFA, Conditional Access, PIM, least-privilege RBAC, session accountability, privileged workstations, and emergency access remain relevant.

The safest design usually begins by asking whether interactive VM login is needed at all. Automation, configuration management, run-command mechanisms, and immutable images can reduce administrative sessions. Where login is required, record the user, source, reason, approval, start and end time, target, and resulting change.

5. Protect identity and the control plane

A VM can have perfect guest hardening and still be compromised through the Azure control plane. A principal with excessive permission can replace an extension, reset credentials, attach a disk, change networking, or delete evidence.

Separate these identity types:

• Human administrators: use individual accounts, strong authentication, Conditional Access, eligible rather than permanent privilege where possible, and periodic access review.
• Workload identities: prefer managed identities over embedded secrets; grant the smallest data-plane and management-plane permissions needed.
• Automation identities: scope pipeline permissions, protect federation or credentials, require reviewed changes, and log deployments.
• Emergency-access identities: keep them few, monitored, tested, and excluded only where the recovery design requires it.

Azure RBAC controls management-plane access to resources, but guest operating-system permissions and application/data-plane authorization remain separate. “Contributor on the resource group” does not necessarily describe who can read application data, and being a VM administrator does not automatically justify subscription-wide rights.

Validation should answer: Who can alter the VM, network, disks, keys, policy, monitoring, and backups? Which roles are permanent? Which identities have not been used? Can a workload identity obtain secrets it does not need? Are role changes sent to monitoring? Retain access-review decisions, PIM activations, role-assignment changes, and exceptions.

6. Harden the VM, operating system, and data

Start with a trusted build and lifecycle

Use supported images, minimize installed software, disable unnecessary services, apply a patch cadence, and define vulnerability-remediation service levels. Trusted Launch can add Secure Boot, vTPM, and boot-integrity monitoring for supported VM generations and configurations. These controls help protect the boot chain; they do not patch the application or prevent stolen credentials.

Defender for Servers and Defender for Endpoint can contribute posture, vulnerability, endpoint, and workload detections depending on the selected plans and onboarding architecture. Confirm coverage and sensor health. A paid plan with 60 percent onboarding is not full protection.

Choose encryption by threat model

Azure managed disks use server-side encryption at rest by default, but additional options address different threats. The current managed-disk encryption overview distinguishes server-side encryption, encryption at host, confidential disk encryption, and the older Azure Disk Encryption approach.

Do not select customer-managed keys merely because they sound more secure. They create key availability, rotation, permission, separation-of-duties, backup, and recovery responsibilities. Choose them when compliance or control requirements justify that operating model. Test what happens when a key is rotated, disabled, deleted, or inaccessible.

An important currency check: as of this article’s verification date, Microsoft documents Azure Disk Encryption retirement for September 15, 2028 and recommends encryption at host for new VMs or appropriate confidential-computing options. Existing designs should consult the current migration guidance rather than copy an older course screenshot.

Encryption also does not prevent an authorized process or compromised administrator from reading decrypted data. Combine it with identity controls, data classification, export restrictions, monitoring, and backup protection.

7. Turn governance into an executable, reviewable baseline

Azure Policy can audit, deny, modify, or deploy configurations at defined scopes. Defender for Cloud consumes posture information and produces security recommendations. Infrastructure as code makes the intended architecture reviewable and repeatable. These mechanisms reinforce one another but are not identical.

A safe policy rollout follows stages:

1. Define the risk and measurable property, not only a desired product setting.
2. Test the definition and parameters against representative resources.
3. Assign in Audit mode and identify false positives and unsupported cases.
4. Establish remediation owners and deadlines.
5. Use exemptions with justification, approver, scope, and expiry.
6. Move to Deny, Modify, or DeployIfNotExists only after impact testing.
7. Monitor compliance latency, remediation identity, deployment failures, and drift.

The course mentions Azure Blueprints in Module 2. That is now historical material. As of August 2026, Azure Blueprints is in phased retirement; Microsoft recommends Azure Deployment Stacks for lifecycle/deny behavior and template specs or Git for storing and versioning templates. New design work should use current services rather than recreate a Blueprint-based standard.

Common governance evidence includes policy definitions and assignments, version-control reviews, deployment records, compliance exports, remediation-task results, and exemption registers. A dashboard percentage alone is not enough: document which scope was measured, when it was evaluated, and which excluded resources remain at risk.

8. Design detection, response, and recovery before go-live

Enable diagnostic settings and endpoint/workload protection because a threat model requires particular signals—not simply because a baseline says “send all logs.” Define each data source, destination, retention, expected volume, cost, and operational query.

Microsoft Defender for Cloud can identify posture issues and workload threats. Defender XDR can correlate endpoint and identity evidence. Microsoft Sentinel can connect these incidents with firewall, identity, application, and third-party data and drive SIEM/SOAR workflows. The Module 3 connector lessons still apply: prevent duplicate incident paths, verify which entities and alerts are synchronized, and monitor connector health.

For each high-priority scenario, write a small runbook:

Trigger and severity criteria
  -> first triage evidence
  -> containment authority and safe actions
  -> investigation and scoping queries
  -> remediation owner
  -> recovery validation
  -> communication and closure evidence

Recovery must be tested separately from detection. A green backup job proves that a job ran; it does not prove that operators can restore an application inside its objective, locate required keys, reconnect dependencies, verify data integrity, and avoid restoring attacker persistence. Schedule restoration exercises and record measured RTO/RPO.

9. Cost, licensing, and operational cautions

Security controls consume money and attention. Exact pricing changes, so the design should record pricing assumptions and review dates rather than hard-code a stale figure.

• Defender for Cloud protection plans and Defender for Servers capabilities differ by plan.
• JIT availability has plan prerequisites; verify them before designing the access process around it.
• Azure Bastion, Azure Firewall, DDoS Protection, WAF, Log Analytics/Sentinel ingestion, retention, automation, and egress can each add cost.
• Customer-managed keys add operational work even when direct service charges are small.
• High-volume network and endpoint logs need filtering and retention decisions, but cost reduction must not remove evidence required for response or regulation.
• A control with no staffed owner creates hidden cost through alerts, exceptions, outages, and failed audits.

Compare control cost with the workload’s business impact and alternatives. For a small internal VM, eliminating the public IP and using an existing private management path may be more effective than purchasing multiple edge services. For a critical public application, multi-layer DDoS/WAF protection, resilient architecture, and rapid-response planning may be justified. The decision record should show why.

10. Common misconceptions to correct

1. “A VM has no public IP, so it is secure.” It may still be reachable through peering, VPN, a compromised host, the control plane, or an overprivileged identity.
2. “Bastion is MFA for RDP/SSH.” Bastion is a managed connection path; identity assurance and authorization still need separate design.
3. “JIT closes every management path.” It controls selected ports and supported network resources; inspect effective rules and alternative paths.
4. “DDoS Protection replaces WAF.” DDoS network-layer mitigation and application-layer request inspection address different threats.
5. “Encryption prevents data theft.” Encryption at rest does not stop a compromised authorized process from reading plaintext.
6. “Policy compliance means the workload is secure.” Policy evaluates defined resource properties; it does not prove secure application code or effective incident response.
7. “Defender enabled means every resource is monitored.” Plans, extensions, connectors, permissions, supported resources, and sensor health determine coverage.
8. “A backup succeeded, so recovery is ready.” Only an end-to-end restoration and integrity test proves recoverability.
9. “More logs always improve detection.” Unowned, unqueried, or unaffordable logs can increase noise without improving outcomes.
10. “Completing an assessment proves production readiness.” Production security requires architecture review, controlled implementation, validation, ownership, and continuous improvement.

11. Step-by-step implementation and verification plan

Phase A: discover and design

• Inventory VMs, images, extensions, public IPs, NICs, NSGs, routes, disks, identities, roles, keys, backup policies, diagnostics, and owners.
• Classify workload criticality and data; document required inbound, outbound, and administrative flows.
• Model threats and fill the threat-control-evidence matrix.
• Estimate licensing, platform, logging, staffing, and recovery costs.
• Agree on RACI, exception process, maintenance windows, and rollback criteria.

Phase B: pilot safely

• Reproduce a representative workload in an isolated subscription or resource group.
• Apply identity and network controls in the least disruptive order.
• Introduce Policy in Audit before enforcement.
• Onboard Defender sensors and validate health before relying on alerts.
• Enable only required logs and confirm timestamps, fields, retention, and query access.
• Use vendor-supported simulations and benign checks; never test attacks without authorization.

Phase C: prove the end-to-end controls

• Demonstrate that unauthorized management traffic is denied and approved access expires.
• Trace a safe detection from the source alert through correlation, assignment, response, and closure.
• Verify encryption settings, key rotation/recovery, Trusted Launch state, and update compliance.
• Confirm that drift appears in Policy/Defender and that remediation is owned.
• Restore the application from backup and measure the result against RTO/RPO.
• Store evidence in a controlled location with retention and access appropriate to its sensitivity.

Phase D: release and operate

• Deploy through reviewed infrastructure-as-code changes.
• Monitor coverage, control health, incidents, exceptions, spending, and failure queues.
• Review privileges and firewall rules regularly; remove expired access.
• Run scenario exercises and restoration tests on a schedule.
• Update the threat model after architecture changes and incidents.

12. Final operational checklist

• Every VM and dependency has a business and technical owner.
• Required network flows are documented; unintended public exposure is removed.
• DDoS and WAF choices match public-endpoint risk and application architecture.
• Administrative access uses a controlled path, least privilege, strong identity, and time limits.
• Effective NSG, firewall, and route behavior is tested—not inferred from templates.
• Supported images, patching, vulnerability management, endpoint/workload protection, and sensor health are monitored.
• Disk, host, key, and export controls match the documented data threat model.
• Policy is versioned, tested, staged, and paired with expiring exemptions and remediation owners.
• Logs and connectors have an owner, retention, cost limit, health check, and tested query.
• Incident runbooks define containment authority, rollback, recovery, and closure evidence.
• Backups are protected and end-to-end restoration is measured regularly.
• The evidence package includes approvals, configurations, tests, incidents, and open risks.

13. Self-review questions

1. Can I explain why a threat model should come before choosing Azure products?
2. Which controls prevent, limit, detect, respond, recover, and prove protection for the same VM scenario?
3. When would DDoS Network Protection, DDoS IP Protection, a WAF, or no extra paid DDoS tier be a defensible choice?
4. How do NSGs, Azure Firewall, Bastion, and JIT differ, and where can they complement one another?
5. What evidence proves that management access was denied by default and opened only for an approved session?
6. Which VM encryption option addresses the stated threat, and what new key-recovery risk does it introduce?
7. Why should an Azure Policy move through Audit and impact review before Deny?
8. How would I detect incomplete Defender onboarding or a broken Sentinel connector?
9. What makes an incident “closed” beyond changing its status to Resolved?
10. What does a restore test need to prove that a successful backup job cannot?
11. Which historical course terms—such as Azure Blueprints or Azure Disk Encryption guidance—require a current-documentation check?
12. Can I produce one evidence package that a workload owner, SOC analyst, auditor, and recovery operator all understand?

14. One-page memory summary

Memory sentence	Meaning
Start with the threat, not the SKU	A service is justified only when it reduces a defined risk
No single control secures a VM	Identity, network, host, data, monitoring, and recovery must overlap
Configuration is not evidence	Validate effective behavior and retain the result
Private is not automatically trusted	Verify every identity, route, workload, and action
Detection without ownership is noise	Every high-value signal needs a triage and response route
Backup is a promise; restore is proof	Measure recovery with an end-to-end exercise
Exceptions are temporary risk decisions	Give each one an owner, reason, compensating control, and expiry

Final reflection

The final module is valuable because it asks for synthesis. DDoS protection, Firewall, Bastion, JIT, encryption, Policy, Defender, and Sentinel are not isolated exam topics. Together they form overlapping layers around a workload. The architecture becomes credible only when the team can explain the boundary of each layer and test the full path from prevention to recovery.

The most durable output of the course is therefore not a screenshot of a secured VM. It is a repeatable reasoning process:

Describe the asset and threat.
Choose proportionate, layered controls.
Assign ownership and understand cost.
Validate effective behavior safely.
Retain evidence and test response/recovery.
Review changes, incidents, and exceptions continuously.

That process applies beyond one VM, one Azure subscription, or one course. It is the bridge between learning a security feature and operating a defensible cloud service.

Official references

• Coursera course and Module 4 outline
• Security best practices for Azure IaaS workloads
• Apply Zero Trust principles to Azure virtual machines
• Azure DDoS Protection overview
• Azure Web Application Firewall overview
• Azure Bastion overview
• Just-in-time machine access
• Trusted Launch for Azure VMs
• Managed-disk encryption options
• Azure Policy documentation
• Microsoft Defender for Cloud overview
• Microsoft Defender XDR integration with Microsoft Sentinel