Module 2 Review: Security Management in Azure

Module 2 of Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course is Security management in Azure. It expands beyond individual network controls into a management system: cloud security principles, Microsoft Defender, Azure Bastion, Azure Policy, standards, SIEM, Microsoft Sentinel, and SOAR.

The central lesson is that security is a continuous operating loop, not a one-time deployment. An organization must define the intended state, prevent or identify deviations, collect trustworthy signals, investigate meaningful activity, respond with controlled actions, and learn from the outcome.

These are independent review notes. They neither reproduce course quizzes nor claim that a learner completed any exercise. The lab patterns are safe objectives that can be used for personal revision. Product names and lifecycle statements have been checked against Microsoft documentation as of August 10, 2026; that matters particularly for Azure Blueprints and the Microsoft Sentinel portal experience.

1. Scope: from individual controls to a security management loop

Module 1 asked how to protect a network path, management port, or encryption key. Module 2 asks who sets the standard, how it is applied repeatedly, and how an operations team knows when protection fails.

Discover assets and owners
        ↓
Define the desired state
        ↓
Prevent or evaluate drift
        ↓
Collect security signals
        ↓
Detect and investigate
        ↓
Respond and recover
        ↓
Feed lessons back into the standard

The course services align to different points in this loop:

Capability	Primary role in the loop	It does not prove
Microsoft Defender for Cloud	Posture visibility, recommendations, workload protection	That every recommendation is fixed or every workload plan is enabled
Azure Bastion	Governed RDP/SSH connection path to VMs	That the signed-in user should be a VM administrator
Azure Policy	Desired-state evaluation and selected enforcement/remediation	That a workload is immune to runtime attacks
Microsoft Sentinel	Collect, correlate, detect, investigate, hunt, and orchestrate response	That every connected log source is complete or useful
SOAR automation	Execute repeatable response workflow	That every automated action is safe in every incident

The boundary statements are as important as the feature statements. A green dashboard is not a substitute for ownership, coverage evidence, and failure testing.

2. Begin with shared responsibility and explicit scope

Cloud security is a shared-responsibility model. Microsoft operates and protects the physical datacenters, host infrastructure, and service components according to the service model. The customer remains responsible for choices such as identity privileges, data classification, network exposure, resource configuration, endpoint hygiene, and incident handling. The exact boundary changes between IaaS, PaaS, and SaaS.

For an Azure VM, the customer still manages the guest operating system, installed software, accounts, and much of its network exposure. For a managed PaaS database, Microsoft manages more of the underlying stack, but the customer still decides who can query it, whether public network access is allowed, and what data belongs there. “Managed service” means a shifted responsibility boundary, not the absence of responsibility.

Before selecting a control, write its scope in four dimensions:

• Asset scope: which tenant, management group, subscription, resource, identity, endpoint, or data set?
• Threat scope: misconfiguration, stolen credentials, malware, network intrusion, data exfiltration, or service outage?
• Lifecycle scope: preventive, detective, responsive, or recovery control?
• Operating scope: who owns configuration, monitoring, exception approval, and evidence?

This avoids a classic mismatch: using a posture tool to claim incident-response coverage, or buying a detection tool when the actual problem is an unowned public endpoint.

3. Separate the Microsoft Defender products and portals

The word Defender describes a family, not a single control. Current terminology is easier to remember by asking what is protected.

Microsoft Defender for Cloud

Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) for cloud resources and application lifecycles. Its major capability groups are:

• Cloud Security Posture Management (CSPM): inventory, recommendations, secure score, regulatory views, attack-path and cloud-graph capabilities depending on plan.
• DevSecOps: connect code and pipeline contexts so risks can be addressed earlier in delivery.
• Cloud Workload Protection Platform (CWPP): paid Defender plans for servers, storage, databases, containers, APIs, and other supported workloads.

Foundational posture features and individual paid plans have different coverage and costs. Opening Defender for Cloud does not mean Defender for Servers, Storage, SQL, Containers, or every extension is enabled. Maintain a subscription-by-plan coverage matrix and verify that required sensors, agents, agentless features, and permissions are healthy.

Secure score is a prioritization signal derived from recommendations. It is not a breach-free certificate, and a higher score does not automatically mean the largest attack path has been removed. A low-effort recommendation with many resources can affect score more than a narrow but business-critical exposure. Combine score with asset criticality, exploitability, internet reachability, data sensitivity, and active threat intelligence.

Microsoft Defender XDR and the Microsoft Defender portal

Microsoft Defender XDR correlates protection across endpoints, identities, email, Microsoft 365 services, and SaaS applications, based on licensed services. The Microsoft Defender portal is the unified interface where Defender XDR, Microsoft Sentinel, and expanding Defender for Cloud experiences can appear.

The portal is not the license. Two users can open the same URL and see different capabilities because their roles, onboarded products, and subscriptions differ. When a course says “the Defender interface,” record the exact workload and portal instead of assuming every Defender product shares configuration, telemetry, or entitlement.

A useful memory rule

Defender for Cloud asks: “How exposed and protected are my cloud workloads?”
Defender XDR asks:       “How do related attack signals cross users, devices, email, and apps?”
Defender portal asks:    “Where does the analyst work with the enabled capabilities?”

4. Turn posture findings into decisions

A recommendation is the beginning of a decision, not an automatic change request. For each significant finding:

1. Confirm that the resource, subscription, owner, and environment are correct.
2. Read the recommendation logic and check whether the resource is genuinely applicable.
3. Add business context: criticality, exposure, data, dependencies, and planned retirement.
4. Validate the remediation in a representative nonproduction scope.
5. Record expected security gain, workload impact, cost, rollback, and evidence.
6. Apply the change through the normal deployment path where possible.
7. Re-evaluate the recommendation and independently test the intended control.

For example, “management ports should be closed” may lead to removing a public IP and using Bastion, not simply adding another deny rule. “Storage should disable public network access” may require private DNS and application routing before enforcement. Treating all findings as identical tickets creates alert fatigue and risky bulk remediation.

An operational finding record can contain:

finding ID | affected asset | owner | severity/context | decision
change ID  | test evidence  | rollback | due date         | residual risk approver

If a recommendation is not implemented, document whether it is not applicable, temporarily exempt, risk accepted, or superseded by a compensating control. Silence is not a risk decision.

5. Azure Bastion protects the management path

Azure Bastion is a managed PaaS service for RDP and SSH connectivity to VMs over TLS. In common deployments, the VM uses its private IP and does not need a public IP, agent, or inbound internet exposure for RDP/SSH. Depending on SKU, administrators can connect through the portal’s browser client or supported native clients.

The threat scenario is straightforward. A VM with a public IP and open RDP is continuously discoverable. Even with strong credentials, the endpoint creates scanning, exploit, credential-spraying, and operational-noise exposure. Bastion centralizes the connection path and removes that public endpoint from each target VM.

That does not mean Bastion grants safe administration automatically:

• Azure RBAC controls who can use relevant Azure resources, while guest-OS authorization controls who can sign in to the VM.
• Microsoft Entra Conditional Access and MFA should protect administrative identities where applicable.
• NSGs, routes, DNS, and the dedicated Bastion subnet must follow supported requirements.
• Session, platform, and guest logs need destinations, owners, and retention.
• Target VMs still require patching, endpoint protection, least privilege, and credential hygiene.
• Emergency access and regional/network failure behavior must be designed.

Compare the access patterns

Pattern	What it changes	Best-fit thought	Residual concern
Public IP + open RDP/SSH	Nothing limits internet reachability	Avoid as a default	Permanent attack surface
Public IP + JIT	Limits source and exposure duration	Legacy or constrained scenario needing temporary inbound access	Public path and Plan 2/topology dependencies remain
Azure Bastion	Removes the VM’s public management endpoint and brokers the connection	Governed Azure VM administration	Bastion cost, identity, network, logging, and resilience still matter
VPN/ExpressRoute + private access	Places the administrator on a private network path	Broader hybrid/private operations	Client/network trust, routing, and lateral movement need controls

Bastion and JIT solve different dimensions—path versus time-bound exposure—and are not always mutually exclusive. Select a pattern from the threat model, administrator population, connectivity architecture, availability objective, feature requirements, and cost.

As of this review, Bastion has Developer, Basic, Standard, and Premium SKUs with different architecture and features; Premium supports private-only deployment. Verify region and feature requirements before deployment rather than assuming a course screenshot represents the current choice.

6. Azure Policy expresses and evaluates desired resource state

Azure Policy governs Azure resources by evaluating them against definitions and applying configured effects. Its vocabulary forms a hierarchy:

Definition:  condition + effect
Initiative:  related definitions grouped toward one objective
Assignment:  definition/initiative applied at a scope with parameters
Evaluation:  applicable resources receive compliance states
Remediation: selected modify/deployIfNotExists gaps are corrected through a task
Exemption:   an applicable resource is intentionally excepted with governance metadata

A definition can live at a management group or subscription. Its location determines where it may be assigned. An assignment at a management group, subscription, resource group, or resource applies to that scope and descendants, subject to exclusions, exemptions, resource selectors, and applicability conditions.

Effects are different decisions

• audit and auditIfNotExists report gaps without blocking the request.
• deny blocks a nonconforming create or update request.
• modify can change supported request properties and can remediate existing resources with the required identity and task.
• deployIfNotExists can deploy a related configuration after evaluation and similarly needs a managed identity and remediation for existing resources.
• disabled allows a definition in an initiative to be inactive for an assignment.
• Other effects exist for specific scenarios; always check the current effect behavior and evaluation order.

“Non-compliant” does not always mean the resource stopped working, and “compliant” does not prove runtime security. Compliance means the applicable resource met the evaluated policy rule at that point in the evaluation cycle.

Do not confuse Policy with adjacent controls

Control	Governing question
Azure Policy	Is resource state allowed, required, or reported?
Azure RBAC	Which identity may perform which control-plane action at this scope?
Resource lock	Should accidental delete or modification be blocked regardless of ordinary RBAC?
Defender for Cloud recommendation	Which posture or workload risk should be investigated and prioritized?

Policy can deny a public IP configuration, but it does not authenticate a VM user. RBAC can let a contributor deploy a storage account, while Policy can constrain the allowed regions and public-access state. These controls intersect without replacing one another.

7. Roll out policy without causing an outage

A policy becomes dangerous when an organization moves from an appealing rule to broad enforcement without observing the estate.

1. Write the intent and owner. State the threat or standard, affected resource types, expected state, exception authority, and success metric.
2. Prefer a maintained built-in when it matches. Custom definitions create testing and version-maintenance obligations.
3. Inspect aliases and modes. Verify that the resource provider exposes the property being evaluated and that all or indexed mode fits the target.
4. Start with a representative pilot. Use a test subscription or narrow resource selector. For deny-capable effects, an assignment with enforcement disabled can evaluate without blocking while behavior is studied.
5. Observe existing and new resources. Policy evaluation is not always instantaneous. Capture applicability, conflicting assignments, and false positives.
6. Prepare remediation and prerequisites. modify and deployIfNotExists require appropriate managed identity permissions; existing resources generally need a remediation task.
7. Test deployment pipelines. A deny that surprises infrastructure-as-code can stop releases. Make the required state part of templates before broad enforcement.
8. Define exemptions rather than invisible workarounds. Record category, owner, justification, compensating controls, expiry, and review date.
9. Enforce in stages and monitor denials. Keep rollback authority and an incident route.

Evidence should include the versioned definition or built-in version, assignment scope and parameters, enforcement mode, excluded scopes, exemptions, compliance export, remediation result, denied-request test, pipeline test, and change approval.

Common policy misconceptions

“Policy fixes all old resources automatically.” Audit only reports. modify and deployIfNotExists have specific behavior, identity requirements, and remediation tasks for existing resources.

“An exclusion and an exemption are the same.” An excluded scope is removed from evaluation and does not appear like an applicable exempt resource. An exemption keeps governance context and compliance reporting. Use the mechanism that matches the decision.

“A regulatory initiative certifies compliance.” It maps technical evaluations to a standard. Organizational procedures, people, data handling, evidence, and controls outside Azure still matter.

8. 2026 correction: Azure Blueprints is retiring

The course includes Azure Blueprints, but this topic now requires a prominent lifecycle correction. Azure Blueprints retirement guidance states that the preview service is retiring on January 31, 2027, with phased restrictions beginning July 31, 2026. As of this article’s date, new blueprint definitions and versions can no longer be created. Further modification and assignment restrictions follow later in 2026.

Do not design a new governance platform around Blueprints. Microsoft’s recommended migration separates the jobs Blueprints once combined:

• Store and version deployment definitions in Template Specs or Git.
• Use Azure Deployment Stacks for grouped resource lifecycle and deny-assignment-style protection where appropriate.
• Continue to use Azure Policy for desired-state evaluation and enforcement.

Existing users should inventory definitions and assignments, export source and parameters, map artifacts to replacements, test lock and lifecycle semantics, and migrate before final retirement. “Blueprint” remains useful as a general architecture word, but it should not be confused with the retiring Azure Blueprints resource provider.

9. SIEM turns telemetry into an investigation

A Security Information and Event Management system collects and analyzes security data across many sources. Microsoft Sentinel is Microsoft’s cloud-native SIEM and unified security platform. It supports multicloud and multiplatform data collection, analytics, incident investigation, hunting, threat intelligence, and response automation.

A basic detection path is:

Source telemetry
  → connector / collection path
    → normalized, queryable data
      → analytics or detection rule
        → alert
          → correlated incident
            → investigation and response

Every arrow can fail. A connector can show as configured while a table receives no recent records. A query can execute while filtering on the wrong field. Alerts can fire but fail to group into useful incidents. An incident can be correct but have no assigned owner. SIEM onboarding is therefore a data-quality and operating-model project, not just a connector project.

For each source, record:

• owner, environment, and security use case;
• authentication and least-privilege collection method;
• expected tables, event types, volume, and latency;
• parser or normalization dependency;
• retention and archive requirement;
• cost estimate and daily-volume alert;
• heartbeat or “last event received” health check;
• detections and investigations that actually consume the data.

Collecting everything indefinitely is not maturity. High-volume data with no detection, hunting, investigation, or compliance use case increases cost and analyst noise. Conversely, deleting identity or control-plane records too quickly can make an incident impossible to reconstruct. Tie retention to explicit uses and legal requirements.

10. SOAR automates controlled response

Security Orchestration, Automation, and Response links tools and executes repeatable workflows. In Sentinel, automation rules can triage and manage incidents or trigger playbooks, which use Azure Logic Apps and connectors to take broader actions.

Good early automation is deterministic and reversible:

• enrich an incident with asset owner and criticality;
• add a task or tag based on a known rule;
• notify an on-call channel with a stable incident link;
• collect volatile evidence before a human decision;
• close a well-understood duplicate under tightly tested conditions.

High-impact containment needs stronger guardrails. Disabling an executive account, isolating a production server, blocking a shared IP, or revoking broad sessions can interrupt legitimate operations or help an attacker cause denial of service. Require appropriate approval, narrow permissions, idempotent actions, timeouts, retry limits, audit logs, and a tested rollback.

A playbook is production code. Version it, review connector identities, keep secrets out of the workflow, test failure branches, monitor runs, control deployment, and assign an owner. “Automated” must never mean “unaccountable.”

SIEM and SOAR in one sentence

SIEM decides what deserves investigation from security data;
SOAR coordinates repeatable actions after that decision.

11. Current Microsoft Sentinel portal direction

Older lessons commonly demonstrate Sentinel in the Azure portal. In 2026, Microsoft is moving Sentinel operations into the Microsoft Defender portal, where Sentinel can participate in a unified incident queue with Defender capabilities.

The transition must be described precisely. Microsoft states that after March 31, 2027, Sentinel will no longer be supported in the Azure portal and will be available only in the Defender portal. Until then, existing environments should plan and validate their move. Navigation and a few capabilities differ between portals, so teams should inventory workflows, roles, bookmarks, automation, and analyst training rather than assuming the URL is the only change.

For new customers, onboarding behavior has also changed since July 2025 under documented permission and tenancy conditions. Use the current Sentinel in the Defender portal guidance for exact navigation and limitations.

12. One scenario across all the controls

Consider a developer VM that must be administered by a small platform team and monitored by the SOC.

1. Azure Policy audits or denies VM public IP patterns and requires selected diagnostic settings.
2. The VM has a private address; Azure Bastion brokers the administration path.
3. Azure RBAC and guest-OS roles restrict which people can start a connection and sign in.
4. Defender for Cloud evaluates posture and the enabled workload-protection plan produces relevant alerts.
5. Logs flow through monitored connectors into Sentinel.
6. An analytics rule correlates suspicious sign-in and host activity into an incident.
7. An automation rule assigns the incident and enriches it with owner and criticality.
8. A human verifies impact before a playbook performs a high-risk containment action.
9. The post-incident review changes the Policy baseline, access design, detection, or playbook.

This shows why the services are not interchangeable. Policy defines resource state; Bastion provides the path; RBAC and host controls authorize people; Defender provides posture/workload signals; Sentinel correlates evidence; SOAR carries out governed workflow.

13. Safe exercise patterns for revision

These patterns do not assert completion and do not reproduce course assessment answers.

Exercise A: Shield a VM with Bastion

Objective: compare public and private management paths.

Use an isolated subscription or resource group. Document the target VM’s address, NSG, route, and login model. Deploy an appropriate Bastion SKU using current subnet and public/private requirements. Confirm that the target VM has no public IP, test the approved connection path, and confirm an unapproved identity or path fails. Capture diagnostic evidence without recording credentials or sensitive screen content.

Evidence: sanitized diagram, role assignments, effective network rules, successful/denied test matrix, log timestamps, cost and cleanup record.

Exercise B: Pilot an Azure Policy assignment

Objective: distinguish definition, assignment, evaluation, enforcement, and remediation.

Choose a harmless built-in such as an allowed-location or tagging audit in a lab scope. Read its rule and aliases. Assign it without broad enforcement, deploy one conforming and one nonconforming test resource, and observe compliance latency. If the effect supports remediation, inspect the identity and task rather than assuming automatic repair. Remove the assignment and resources after evidence is saved.

Evidence: definition version, parameters, scope, enforcement mode, test resources, compliance timestamps, exception decision, and cleanup.

Exercise C: Design a minimal Sentinel use case

Objective: trace one useful signal from source health to incident response.

Select a low-volume supported source and one documented detection goal. Estimate ingestion before connecting it. Verify recent data with a bounded query, document the expected fields, and create or enable only content needed for the use case. Test with an authorized benign event or vendor-provided simulation method. Do not generate real attacks or ingest production secrets into a personal lab.

Evidence: source owner, connector health, last-record timestamp, query, alert/incident relationship, assigned response task, automation run result, retention, and cost.

For all exercises, use synthetic names and data, set budgets, restrict permissions, and clean up Bastion instances, public IPs, workspaces, connectors, Logic Apps, identities, and paid Defender plans. A deleted VM does not remove every dependent paid resource.

14. Cost, licensing, and operating decisions

Capability	Main cost or entitlement driver	Decision to record
Defender for Cloud	Enabled plan per protected resource/workload plus feature dependencies	Which subscriptions and resource types require foundational CSPM or paid plans?
Azure Bastion	SKU, deployment duration, scale/features, and associated networking	Is a shared governed path preferable to per-VM exposure, and what availability is required?
Azure Policy	Service evaluation is not the main cost; remediation can deploy billable resources	Who funds resources created by deployIfNotExists, and who handles denials?
Microsoft Sentinel	Data ingestion, retention, data-lake/analytics choices, queries, automation	Which use case justifies each source and retention period?
Logic Apps/playbooks	Trigger/action executions, connectors, integration services	Which actions need approval and what is the safe retry/rollback behavior?

Do not freeze price numbers into architecture notes. Record the meter and usage assumption, then confirm the current pricing page, licensing terms, region availability, and cost calculator immediately before approval. In a lab, configure a budget and a calendar reminder for cleanup before enabling a paid plan or continuously running service.

15. Operational checklist

• Every security control has an asset scope, threat, owner, and failure response.
• Defender for Cloud foundational and paid-plan coverage is inventoried by subscription and resource type.
• Secure score is prioritized with asset context rather than treated as a certificate.
• Defender for Cloud, Defender XDR, Defender portal, and Sentinel are named precisely.
• VMs avoid public management endpoints unless a documented exception requires one.
• Bastion SKU, identity path, network rules, logs, resilience, and cost are validated.
• Policy intent, definition version, scope, parameters, enforcement mode, and exemptions are versioned.
• Deny and remediation behavior is tested against deployment pipelines before broad rollout.
• No new governance design depends on the retiring Azure Blueprints service.
• Every Sentinel source has a use case, health check, volume expectation, retention, and owner.
• Analytics create actionable incidents with severity, grouping, assignment, and response steps.
• Playbooks use least privilege, bounded retries, approvals for high-impact actions, and rollback.
• Portal-transition behavior is tested before the 2027 Sentinel Azure-portal retirement.
• Lab and production costs include logs, automation, and dependent resources—not only the visible VM.

16. Self-review questions

1. How does shared responsibility differ for an Azure VM and a managed PaaS database?
2. What is the difference between Defender for Cloud, Defender XDR, and the Defender portal?
3. Why can secure score rise while a critical attack path remains?
4. Which risks does Bastion reduce, and which identity or host risks remain?
5. How do Bastion and JIT differ in the dimensions they control?
6. What is the relationship among a Policy definition, initiative, assignment, and remediation task?
7. Why should a deny policy begin with observation and pipeline testing?
8. What is the governance difference between an exclusion and an exemption?
9. Why should a new design avoid Azure Blueprints in August 2026?
10. What proves that a Sentinel connector is useful, not merely configured?
11. Which response actions are safe to automate without approval, and which are not?
12. What must be tested before moving an analyst workflow from the Azure portal to the Defender portal?

Final memory map

Defender for Cloud sees posture and workload risk.
Bastion governs the VM management path.
Policy defines and evaluates resource state.
Sentinel turns telemetry into investigations.
SOAR turns approved decisions into repeatable action.

If each line can be explained with a threat scenario, scope, owner, evidence, cost, and failure behavior, Module 2 has become a reusable operating model rather than a tour of Azure menus.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Microsoft Defender for Cloud overview
• Microsoft Learn: Microsoft Defender XDR in the Defender portal
• Microsoft Learn: Azure Bastion overview
• Microsoft Learn: Azure Policy overview
• Microsoft Learn: Azure Policy definition structure
• Microsoft Learn: Azure Blueprints retirement
• Microsoft Learn: Migrate Azure Blueprints to Template Specs
• Microsoft Learn: Microsoft Sentinel overview
• Microsoft Learn: Microsoft Sentinel in the Microsoft Defender portal