L17. Workload Protections: Servers, Containers and Databases
Visual workflow edition
Worked example, diagrams and a question with time to think. Synthetic American-English narration; examples are fictional. Reviewed October 2026.
Read the video transcript
A server, a container workload, and a database all appear in your cloud environment. Can you protect them with exactly the same checks? Their threats and available signals differ. We'll map the asset to the enabled protection capability, then choose evidence and a response that fit the workload.
Confirm what resources exist and which protection capabilities are enabled for them. Review onboarding and prerequisites for the workload and environment. Plans, integrations, and supported features differ. A dashboard's aggregate count can hide gaps, so inspect representative resources. Coverage is a configuration and verification question, not simply a product name on a diagram.
For a server, process and device context may be central. A container finding can require image, workload, and orchestration context. A database alert may need query or access evidence. These are examples, not a promise that every signal is available in every plan. Check the actual capability before designing an investigation around it.
Imagine an alert on a database used by a customer-facing application. Confirm which database and identity are involved. Review the available event details and timing, then compare them with legitimate application activity. Coordinate with the owner before a disruptive response. Blocking an account without understanding its use can interrupt the service you are trying to protect.
After the response, verify its outcome on the actual workload. Then review any related configuration weakness or coverage gap. Threat response and posture improvement are complementary tasks. Record unresolved questions and the next owner. One alert being closed should not erase the need to verify a protection capability that was missing or unhealthy.
A container alert and a database alert have the same severity. Should the analyst use identical evidence and containment steps? Pause and name one reason the workflows can differ.
No. Available telemetry, permissions, dependencies, and safe response options differ. Start with the workload's actual boundary and the evidence you have. For practice, describe one useful signal and one potential response impact for a server, container, and database. Matching controls to assets is more reliable than assuming the same label means the same workflow.
Course outlineLesson 17 of 18
Defender for Cloud workload protection plans provide runtime threat detection for servers, containers, and databases. This lesson covers Defender for Servers plans, container security, database protections, and alert investigation for the SC-200 exam.
Defender for Servers
Defender for Servers protects Windows and Linux virtual machines across Azure, AWS, GCP, and on-premises (via Azure Arc). Two plans are available:
| Feature | Plan 1 | Plan 2 |
|---|---|---|
| Defender for Endpoint integration | Yes | Yes |
| Agentless vulnerability scanning | No | Yes |
| File integrity monitoring | No | Yes |
| Just-in-time VM access | No | Yes |
| Adaptive application controls | No | Yes |
| Adaptive network hardening | No | Yes |
| OS baseline compliance | No | Yes |
Just-in-Time VM Access
JIT reduces exposure of management ports:
- JIT closes management ports (e.g., 3389, 22) on the NSG by default
- An analyst requests access for a specific port, IP, and time duration
- JIT opens the port for the requested duration and source IP only
- Access automatically revokes when the time expires
JIT requests can be approved automatically or require manual approval from a security admin.
Defender for Containers
Defender for Containers protects Kubernetes environments:
| Capability | Description |
|---|---|
| Image vulnerability scanning | Scans container images in ACR, ECR, and GCR |
| Runtime protection | Detects suspicious container behavior (crypto mining, shell access, privilege escalation) |
| Kubernetes audit log analysis | Monitors API server events for suspicious operations |
| Admission control | Blocks deployment of vulnerable or non-compliant images |
| Network policy recommendations | Suggests network segmentation for pods |
- A Defender sensor (DaemonSet) is deployed on each Kubernetes node
- An Azure Policy add-on enforces admission control policies
- Container images are scanned agentlessly in the registry
Defender for Databases
Multiple database protection plans: Defender for Azure SQL:
- Detects SQL injection attempts
- Identifies anomalous database access patterns
- Alerts on brute force login attempts
- Detects access from unusual locations
- Covers PostgreSQL, MySQL, and MariaDB
- Detects anomalous access and brute force attacks
- Detects SQL injection in Cosmos DB queries
- Identifies anomalous data access patterns
- Alerts on access from suspicious locations
Defender for Storage
Defender for Storage protects Azure Blob, File, and Data Lake:
- Malware scanning: Scans uploaded files for malware (near real-time)
- Sensitive data threat detection: Alerts when sensitive data is accessed anomalously
- Anomalous access detection: Identifies unusual access patterns
Malware scanning can be configured to block malicious uploads or alert-only mode.
Security Alerts
When workload protections detect threats, they generate security alerts with:
- Severity (High, Medium, Low, Informational)
- Kill chain stage mapping (MITRE ATT&CK)
- Affected resource details
- Remediation guidance
- Raw evidence and related entities
Alerts flow into Defender for Cloud and, if connected, into Microsoft Sentinel for correlation with other security data.
Alert Suppression Rules
Create suppression rules to hide known false positive alerts:
- Filter by alert type, resource, IP, or other properties
- Set an expiration date for temporary suppressions
- Suppressed alerts are logged but not displayed in the active queue
- ✓Defender for Servers Plan 2 includes JIT VM access, file integrity monitoring, and agentless vulnerability scanning.
- ✓JIT VM access closes management ports by default and opens them only for approved requests with time limits.
- ✓Defender for Containers uses a DaemonSet sensor for runtime protection and Azure Policy add-on for admission control.
- ✓Container image scanning works agentlessly across ACR, ECR, and GCR registries.
- ✓Defender for Azure SQL detects SQL injection, anomalous access patterns, and brute force attacks.
- ✓Alert suppression rules hide known false positives while still logging them for audit purposes.
1. An organization wants to close RDP and SSH ports on Azure VMs by default and only open them when analysts need access. Which feature should they enable?
2. Which component does Defender for Containers deploy on Kubernetes nodes for runtime threat detection?
3. Defender for Servers Plan 1 includes which core capability?
Keep learning
Use the knowledge check above to test your understanding. You can browse every lesson without signing in; opening another lesson does not mark this one complete.
Next lesson: Regulatory Compliance and Governance →