Module 1 Review: Azure Basic Security Capabilities

The first module of Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course is called Azure: Basic security capabilities. Its syllabus moves from virtual machines and virtual networks to DDoS protection, Azure Firewall, Web Application Firewall, just-in-time access, and encryption. That is a broad range for an introductory module, so the most useful review is not a list of portal steps. It is a model of which risk each control addresses and which risk remains.

These are independent study notes, not a transcript or answer key. The exercises below restate safe learning objectives without reproducing Coursera assessments, and they do not claim that any particular lab was completed. Product names and service states are checked against Microsoft documentation as of August 10, 2026.

1. Scope of the module

Module 1 can be reduced to four security questions:

1. How does an internet-facing workload remain available during abusive traffic?
2. Which network flows should be allowed between a source and destination?
3. How can administrators reach a VM without leaving management ports permanently exposed?
4. How are data and cryptographic keys protected throughout their lifecycle?

The course approaches those questions through three lab-shaped sequences: create a Windows VM, configure Azure Firewall, and secure management ports with just-in-time access. The VM is not the final security objective. It is a concrete workload around which networking, access, filtering, logging, and encryption decisions can be observed.

2. A layered mental model

No product in this module is a universal “secure” switch. Each one works at a different layer:

Internet availability       Azure DDoS Protection (network layers 3 and 4)
Web request inspection      Web Application Firewall (application layer 7)
Central network filtering   Azure Firewall
Subnet or NIC filtering     Network security group (NSG)
Temporary admin exposure    Defender for Cloud just-in-time VM access
Data confidentiality        Encryption + governed key management

This model prevents two common mistakes. First, DDoS mitigation does not replace a WAF: absorbing a volumetric SYN flood and detecting SQL injection are different jobs. Second, a firewall does not decide who may administer Azure resources. Network rules constrain packets; Microsoft Entra authentication and Azure role-based access control (RBAC) govern identities and control-plane actions.

The practical design principle is defense in depth with explicit ownership. Each layer needs an owner, a configuration baseline, telemetry, and a response procedure. Stacking products without those operating decisions creates cost and complexity, not reliable protection.

Connect the layers with one threat scenario

Consider a public online store. An attacker can flood its public IP with layer 3/4 traffic; DDoS Protection addresses that availability path. The attacker can instead send normal-looking HTTPS connections containing injection payloads; a WAF is closer to that application-layer risk. If the web tier is compromised and attempts to reach a database subnet, NSGs and central east-west firewall policy can limit the blast radius. If the attacker scans the internet for RDP, removing the VM public IP, using a private administration path, or applying JIT reduces the management surface. If a disk or credential is stolen, encryption and separately governed key access become relevant.

One product does not erase this full path. Defense in depth means that controls address independent failure modes, not merely that several security products appear on a diagram.

3. DDoS protection is an availability decision

A distributed denial-of-service attack attempts to exhaust network, protocol, or application capacity so legitimate clients cannot use a service. Azure provides infrastructure-level protection for its platform, but enhanced customer-configurable coverage is offered through Azure DDoS Protection.

The current enhanced tiers are:

Tier	Best-fit decision	Important distinction
DDoS IP Protection	Protect a smaller number of supported public IPs	Per-protected-IP model
DDoS Network Protection	Protect supported public IP resources across covered virtual networks	Includes value-added benefits such as DDoS Rapid Response and cost protection, subject to current terms

Both enhanced tiers provide always-on monitoring, adaptive tuning, automatic layer 3/4 mitigation, metrics, alerts, and attack reports for supported resources. Coverage must still be verified. A resource being “in Azure” does not prove that its public IP and deployment model are included in the chosen plan.

The architecture decision begins before buying a tier:

• Remove public endpoints that are unnecessary; use private endpoints where appropriate.
• Design the service to scale and fail safely across failure domains.
• Protect every supported public IP in scope rather than only the most visible VM.
• Place a WAF in front of HTTP workloads that need layer 7 protection.
• Route DDoS metrics and diagnostic data to an owned monitoring destination.
• Document who declares an attack, who contacts Microsoft, and how customers are informed.

An alert is useful only if it reaches someone who can act. For a lab, observing metrics and the configuration boundary is sufficient. Never generate uncontrolled attack traffic. Microsoft permits simulation only through approved testing partners and within the documented process.

4. Choose the right traffic control

The module introduces several controls whose names all contain “firewall,” but their enforcement points differ.

Control	Primary scope	Use it to answer
NSG	Subnet or network interface	May this source, destination, port, and protocol flow?
Azure Firewall	Central managed network path	Which east-west or north-south traffic is centrally allowed and logged?
WAF	HTTP/S application edge	Does this web request match an application attack pattern or policy?

Azure Firewall is a managed, stateful firewall service. A sound deployment requires more than creating the resource. Routes must actually send intended traffic through it; DNS behavior must support application rules; rules need clear ownership and expiration; and logs must be retained and reviewed.

As of this review, Azure Firewall has three SKUs:

• Basic targets smaller environments with lower throughput requirements.
• Standard adds enterprise capabilities such as threat-intelligence filtering, DNS proxy, and web categories.
• Premium adds controls for sensitive workloads, including intrusion detection and prevention, TLS inspection, and more granular URL filtering.

SKU selection should come from requirements, not the assumption that the most expensive tier automatically makes an architecture safe. TLS inspection, for example, introduces certificate, privacy, application-compatibility, and operational responsibilities. Premium features must be tested with the real traffic they will govern.

A practical rule design process is:

1. Write the intended flow in plain language, including owner and business purpose.
2. Confirm the route and enforcement point.
3. Prefer the narrowest source, destination, protocol, and port that meet the need.
4. Separate network, application, and destination NAT rules correctly.
5. Enable logs before declaring the path production-ready.
6. Test both allowed and denied flows.
7. Attach an expiry or review date to temporary exceptions.

“The firewall exists” is weak evidence. A route table, effective rule set, denied-flow test, and searchable log record are much stronger evidence.

Common firewall misconceptions

“An NSG is a cheaper Azure Firewall.” They overlap in packet filtering, but an NSG is a distributed subnet/NIC control while Azure Firewall is a managed central policy and inspection point. Select the enforcement model the architecture needs rather than treating one as a small version of the other.

“Premium is always safer.” Premium capabilities can reduce specific risks, but TLS inspection and IDPS require certificate governance, privacy review, tuning, performance testing, and exception handling. An advanced control that nobody operates can produce blind spots or outages.

“Allow rules are the only tests that matter.” A path is not proven until an intended flow succeeds and a nearby unintended flow is denied. Negative tests catch broad routes, shadowing rules, and enforcement points that traffic bypasses.

5. JIT reduces exposure; it does not replace secure administration

RDP on TCP 3389 and SSH on TCP 22 are continuously scanned on the public internet. The safest default is generally to avoid assigning a VM a public IP and use a governed private management path. When a design still requires controlled inbound management access, just-in-time VM access can reduce the time that selected ports are reachable.

In the current service, JIT is a capability of Microsoft Defender for Servers Plan 2 in Microsoft Defender for Cloud. It establishes deny rules for selected ports through supported NSG or Azure Firewall configurations. An authorized request can temporarily allow a defined source IP or range, port, and duration; the restrictive state returns after the window expires.

The security value is smaller attack surface, not a stronger password. A JIT design still needs:

• Azure RBAC that restricts who can request access;
• Microsoft Entra sign-in protection and multifactor authentication;
• a narrow source address and short access duration;
• hardened host authentication, preferably without shared credentials;
• OS patching, endpoint protection, and activity logging;
• a tested recovery path if the JIT workflow or network control is unavailable.

JIT also has documented network limitations. It should not be assumed to support every Azure Firewall Manager or Firewall Policy topology. Confirm the current prerequisites before treating it as a control commitment.

JIT and Azure Bastion should not be reduced to competing buttons. JIT mainly governs when, from where, and for how long an inbound management port is exposed. Bastion provides a managed connection path so the target VM can use a private IP without its own public management endpoint. VPN or ExpressRoute can provide another private path. The threat model, administrator population, feature needs, failure behavior, licensing, and cost determine whether one or a combination is appropriate.

6. Encryption is a lifecycle, not a checkbox

Encryption decisions belong in three categories:

• In transit: protect connections with current TLS, IPsec, SSH, or another appropriate protocol.
• At rest: use the storage service’s encryption capability and decide whether platform-managed or customer-managed keys are required.
• In use and at the host boundary: apply workload-specific controls, including confidential-computing or host-encryption capabilities where the threat model requires them.

Encryption primarily protects confidentiality by making data unreadable without the required key. It is not, by itself, proof that a resource, application, file, or backup has not been changed. Authenticated protocols, hashes or signatures, access controls, immutable records, versioning, and tested recovery address different aspects of integrity. Key Vault governs supported keys, secrets, and certificates; merely creating a vault does not automatically encrypt a VM or make its data trustworthy.

Distinguish the current Azure managed-disk options

The managed-disk encryption overview separates controls that are often compressed into the phrase “disk encryption.”

Option	Enforcement point and coverage	Selection boundary
Azure Disk Storage server-side encryption (SSE)	Always enabled for managed OS and data disks when data persists on Azure Storage clusters; platform-managed keys are the default, and a Disk Encryption Set can reference a customer-managed key	Baseline encryption at rest; it does not cover temporary disks or disk caches
Encryption at host	VM option that encrypts temporary disks and disk caches at rest and keeps VM-host data encrypted as it flows to Storage; cache keys follow the selected disk key model, while temporary disks use platform-managed keys	Use when the threat model or standard requires coverage at the compute-host boundary; verify supported VM sizes, regions, and configuration restrictions
Azure Disk Encryption (ADE)	Guest-level technology using BitLocker on Windows or dm-crypt on Linux	Legacy design scheduled for retirement; do not select it for a new VM
Confidential disk encryption	Capability for supported confidential VM scenarios	Evaluate when the threat model includes stronger protection for confidential-computing workloads, not as a universal default

SSE being enabled does not mean every byte associated with the VM has identical coverage. The temporary disk and host caches are the important boundary that encryption at host extends. Conversely, encryption at host does not replace Azure Storage SSE; it enhances the end-to-end path. It also cannot be enabled on a VM that currently has or previously had ADE, and ADE cannot be enabled on disks using encryption at host. Migration and coexistence assumptions must be checked before a change.

Treat ADE retirement as an inventory and migration risk

Azure Disk Encryption is scheduled to retire on September 15, 2028. Microsoft’s current guidance is to use encryption at host for new VMs, or an appropriate confidential VM option for supported confidential-computing workloads. After the retirement date, an ADE-enabled workload might continue running, but its encrypted disks will fail to unlock after a reboot, which can cause service disruption.

Every ADE-enabled VM and relevant backup therefore needs an owner, migration plan, validation evidence, and deadline. The documented migration is not an in-place toggle: it requires new disks and VMs. A safe program inventories Windows and Linux ADE use, maps application and recovery dependencies, proves the target VM size and region support encryption at host, rehearses restore and rollback, migrates in waves, and validates reboot behavior before decommissioning the old path.

Select the control from the threat model

Use the question before the feature:

• If the concern is data persisted on Azure managed disks, confirm the existing SSE configuration and whether platform-managed keys satisfy the requirement.
• If an organization must control key custody, evaluate customer-managed keys through a Disk Encryption Set and Key Vault, including the added availability and operating obligations.
• If temporary disks, host caches, and the compute-to-Storage path are in scope, evaluate encryption at host and its compatibility requirements.
• If the workload has confidential-computing requirements, assess a supported confidential VM and disk option as its own architecture decision.
• If ADE already exists, treat it as a time-bound migration obligation rather than evidence that the VM has a more modern control.

A customer-managed key can provide control over rotation and revocation, but it transfers operational responsibility. Losing access to the key can become losing access to the data.

Azure Key Vault separates keys, secrets, and certificates from application code. A defensible key-management design covers:

• least-privilege data-plane and management-plane access;
• managed identities instead of embedded credentials;
• rotation dates and application compatibility with new key versions;
• soft delete and purge protection appropriate to recovery requirements;
• logging and alerts for sensitive operations;
• backup, regional-resilience, and break-glass procedures;
• separation between the people who administer workloads and those who govern keys.

Prove configuration and recoverability

Useful evidence combines control-plane state with an operational test:

• VM and disk inventory showing region, disk type, encryption type, encryptionAtHost state, and Disk Encryption Set where applicable;
• approved threat model and key-choice decision, including why platform-managed or customer-managed keys meet the requirement;
• Key Vault and Disk Encryption Set role assignments, key version and rotation configuration, soft delete, purge protection, and diagnostic settings;
• policy or infrastructure-as-code evidence that new resources receive the intended configuration;
• a sanitized key-rotation and recovery test, including application access after rotation;
• reboot and restore evidence for representative VMs, especially before and after an ADE migration;
• an ADE inventory with owner, target pattern, migration wave, validation date, and completion deadline.

Do not place secret values, key material, full resource identifiers, or production data in screenshots and study notes. The evidence should prove configuration and operation without becoming a new disclosure risk.

Common encryption misconceptions

“Managed disks are encrypted by default, so caches and temporary disks are covered identically.” SSE covers managed OS and data disks on the Storage clusters; encryption at host addresses the additional host boundary.

“ADE and encryption at host can be stacked.” They have explicit incompatibilities. ADE is retiring, so the design question is migration, not layering both technologies.

“Encryption guarantees integrity.” Encryption can be one component of authenticated protection, but integrity requires its own controls and evidence. Key Vault also does not repair unauthorized application changes.

“A customer-managed key is always safer.” It is useful when key custody or revocation control is required, but an untested rotation, deleted key, excessive Key Vault permission, or broken dependency can create a larger outage. Confidentiality and recoverability must be approved together.

The key lesson is that encryption reduces defined confidentiality risks while key custody and retirement dependencies can introduce availability risk. Both sides belong in the threat model.

7. Safe ways to revisit the course exercises

The following are review patterns, not records of personal completion.

Exercise pattern A: Create a Windows VM

Learning objective: identify every security-relevant default around a new VM.

Before deployment, record the selected region, image, authentication method, network, public-IP decision, NSG rules, disk-encryption setting, identity, monitoring, and expected owner. After deployment, inspect effective routes and security rules rather than relying only on the creation wizard. Do not use real personal data or production credentials.

Evidence to retain: a sanitized architecture note, resource inventory, rule export, and a list of deviations from the intended baseline.

Exercise pattern B: Configure Azure Firewall

Learning objective: prove that a workload’s traffic traverses an explicit policy point.

Build an isolated resource group and address plan, deploy the required firewall SKU, create routes, and add one narrowly defined allowed flow. Validate that the allowed flow works and a neighboring unapproved flow fails. Confirm that both outcomes appear in the chosen log destination.

Evidence to retain: route intent, rule purpose, test matrix, timestamps, and relevant sanitized log queries.

Exercise pattern C: Secure ports with JIT

Learning objective: observe the difference between a permanently open port and time-bound access.

First confirm licensing and supported network topology. Record the effective inbound state before the request, request the shortest practical window from a controlled source, verify the change, then confirm that access closes after expiry. An existing TCP session may behave differently from a new connection, so define the test precisely.

Evidence to retain: RBAC decision, requested source/port/duration, approval event, pre/post rule state, and closure verification.

For every disposable lab, tag resources, set a budget alert, and remove the resource group or paid plan after retaining only sanitized evidence. “Cleanup” is part of the security exercise because abandoned public IPs, disks, identities, and keys are real attack and cost surfaces.

8. 2026 terminology and product corrections

Course material can remain educational even when the interface changes. These translations help reconcile the syllabus with the current platform:

• Azure Active Directory is now Microsoft Entra ID. The identity concepts remain relevant, but current documentation and portals use the new name.
• Azure Security Center and Azure Defender evolved into Microsoft Defender for Cloud, now described as a cloud-native application protection platform combining posture, DevSecOps, and workload-protection capabilities.
• Azure Firewall should be evaluated across Basic, Standard, and Premium, not as a two-tier choice.
• Enhanced Azure DDoS options are DDoS IP Protection and DDoS Network Protection; distinguish them from platform infrastructure protection.
• JIT VM access is not a free-standing networking feature. Its current entitlement is tied to Defender for Servers Plan 2, and topology prerequisites matter.

For any production change, use the course to frame the question, then verify the current Microsoft Learn page for the exact SKU, region, licensing, and portal workflow.

9. Cost, licensing, and operating decisions

Security services create value only when their coverage and operation justify their recurring cost. Avoid placing fixed prices in an architecture note because rates, regions, and offers change. Record the meter and usage assumption, then confirm the pricing page and calculator immediately before approval.

Capability	Main cost or entitlement driver	Decision to record
Azure DDoS Protection	Per-IP or network-plan protection model and optional response benefits	How many supported public IPs need enhanced protection, and who needs incident assistance?
Azure Firewall	SKU runtime, processed data, public IPs, logging, and operating effort	Does central inspection reduce enough risk to justify the path and cost?
WAF	Gateway/edge SKU, capacity, managed-rule tuning, and log volume	Who owns false-positive review and time-bounded exclusions?
JIT VM access	Defender for Servers Plan 2 for protected machines plus topology dependencies	Which servers require JIT, and do the other Plan 2 capabilities support the business case?
Key Vault and CMK	Operations, premium/HSM choices, networking, logging, and key operations staff	Is customer key custody required, and can the team rotate and recover it safely?
Azure Monitor logs	Ingestion, analytics, retention, archive, and query volume	Which logs support a detection, investigation, or compliance use case, and for how long?

For a lab, set a budget and a dated cleanup reminder before enabling a continuously billed firewall, Bastion instance, enhanced DDoS tier, workspace, or Defender plan. A resource group deletion may not disable a subscription-level plan or remove every shared log destination, so validate the billable inventory afterward.

10. Operational checklist

• Public endpoints have a documented owner and necessity.
• DDoS coverage is mapped to actual supported public IP resources.
• Layer 3/4 DDoS protection and layer 7 WAF protection are not confused.
• Routes prove that intended traffic reaches Azure Firewall.
• Firewall and NSG rules have purpose, owner, test evidence, and review dates.
• Management ports are private by default or protected with a documented time-bound process.
• JIT licensing, RBAC, source restrictions, expiry, and network compatibility are verified.
• Encryption requirements distinguish in-transit, at-rest, and workload-specific needs.
• Key rotation, deletion protection, monitoring, and recovery are tested.
• Diagnostic logs reach a monitored destination with an agreed retention period.
• Disposable lab resources and paid plans have a cleanup decision.

11. Self-review questions

1. Why can DDoS Protection and a WAF both be necessary for one web application?
2. What evidence proves that a subnet’s traffic actually traverses Azure Firewall?
3. When would an NSG be sufficient, and when is central firewall policy useful?
4. Which requirements justify Basic, Standard, or Premium Azure Firewall?
5. What attack surface does JIT reduce, and what identity risks remain?
6. Why might customer-managed encryption keys increase availability risk?
7. Which resources would be left behind if a VM-only cleanup were performed?
8. Who receives and acts on DDoS, firewall, JIT, and key-management alerts?
9. Which control produces a recurring charge even when no security incident occurs?
10. What rollback or recovery path exists if a firewall route, JIT workflow, or key becomes unavailable?

If those answers can be stated in terms of scope, owner, evidence, and failure behavior, the module has become an operational security model rather than a collection of product names.

Final memory line

DDoS protects availability; WAF inspects web requests; Firewall governs paths;
NSG filters nearby flows; JIT limits exposure time; encryption governs data and key lifecycles.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: What is Azure DDoS Protection?
• Microsoft Learn: Choose the right Azure Firewall SKU
• Microsoft Learn: Azure Web Application Firewall overview
• Microsoft Learn: Just-in-time VM access
• Microsoft Learn: Azure Key Vault overview
• Microsoft Learn: Managed disk encryption options
• Microsoft Learn: Migrate from Azure Disk Encryption to encryption at host
• Microsoft Learn: Microsoft Defender for Cloud overview