Defender Multicloud (AWS + GCP) + EASM + Vulnerability…

Three ways to expand visibility

Simple explanation

Once Defender for Cloud is humming on your Azure subscriptions, three SC-500 expansions complete the posture picture:

Multicloud connectors — bring AWS accounts and GCP projects into Defender for Cloud so they show up alongside Azure subscriptions. One pane of glass across all three clouds.
External Attack Surface Management (EASM) — Microsoft’s internet-scale crawler that discovers your internet-facing assets — domains, IPs, hosts, web pages — even the ones you didn’t know you had. Catches shadow IT, forgotten dev environments, and post-acquisition surprises.
Defender Vulnerability Management (MDVM) — the vulnerability assessment engine. Settings determine scan frequency, scope, prioritisation, and integration with workload protection plans.

Multicloud connectors

AWS connector

The AWS connector onboards an entire AWS Organization (or selected accounts) into Defender for Cloud. Defender provisions:

AWS IAM roles for Defender to read configuration, snapshot disks for agentless scanning, and (optionally) deploy Azure Arc agents to EC2 instances.
Defender plans per offering: Servers, Databases (RDS), Containers (EKS), CSPM. Each is enabled per offering inside the connector.
Arc onboarding for EC2 instances when Servers plan is enabled.

Once connected, AWS accounts appear in Defender for Cloud’s environment view alongside Azure subscriptions. Recommendations, attack paths, and compliance all span both clouds.

GCP connector

The GCP connector follows the same pattern with GCP-native primitives — GCP service accounts, Workload Identity Federation for token exchange, GCP project (or organisation) targeting.

When multicloud is the right answer

The exam pattern: any scenario mentioning AWS accounts, GCP projects, EC2/EKS/RDS/S3, or “multicloud” governance ties back to the Defender for Cloud multicloud connectors. Going via Sentinel data connectors alone misses the posture and workload-protection coverage that the Defender connector provides.

Microsoft Defender EASM

EASM is Microsoft’s internet-side crawler service that maps your organisation’s external attack surface. You seed it with:

Known domain names (example.com, example.co.nz)
Known IP addresses or CIDR ranges
Organisational identifiers (company name, registrant emails for WHOIS pivots)

EASM crawls the internet and discovers:

All domains you own (including subdomains, internationalised variants, recently-registered look-alikes)
All hosts answering on those domains
All IP addresses they resolve to
SSL certificates and their issuance / expiry / CN-SAN coverage
Web pages and the technology stack they expose (often via fingerprinting)
Observed vulnerabilities (CVEs evident from banners or fingerprints)
Mail / DNS records (SPF, DKIM, DMARC, mail server posture)

The output is the organisation’s external attack surface inventory — typically larger than the org’s internal inventory, because it includes assets that ops doesn’t formally track (forgotten dev environments, marketing microsites, post-acquisition assets, shadow IT).

When EASM is the right answer

The pattern: scenarios mentioning “shadow IT”, “unknown internet-exposed assets”, “post-acquisition discovery”, or “assets we didn’t know we had” point to EASM. EASM doesn’t deploy agents and doesn’t require any access into your environment — it’s outside-in discovery.

Defender Vulnerability Management (MDVM)

MDVM is the vulnerability assessment engine across Defender for Cloud (via Defender for Servers Plan 2 + Containers + CSPM) and Microsoft Defender for Endpoint (in M365 Defender XDR). For SC-500, the testable settings:

MDVM settings and capabilities — across Defender for Cloud + Defender for Endpoint
MDVM setting	What it does
Scan scope (Azure VMs)	Per-subscription, per-resource-group, or per-VM enablement (typically via Defender for Servers Plan 2 onboarding)
Scan frequency — MDE agent-based	Continuous when MDE is healthy; near real-time inventory and CVE matching
Scan frequency — agentless	Defender for Cloud agentless scanning schedule (typically daily snapshots) — settable on the Defender CSPM / Defender for Servers Plan 2 settings
Prioritisation signals	MDVM Exposure Score (org-level), Exploitability (Exploit Wednesday, CISA KEV), public exposure (internet-facing flag from Defender CSPM)
Integration with Defender for Endpoint	Findings surface in Defender XDR's Threat and Vulnerability Management view, alongside MDE EDR alerts
Authenticated scans of network devices	MDVM supports authenticated scans of network devices (switches, routers, firewalls) via configured device credentials — extends coverage beyond endpoints
Browser extension assessment	MDE/MDVM inventories installed browser extensions on managed endpoints and flags risky ones
Software inventory + licence visibility	MDVM reports installed software, versions, licence implications across the managed fleet

The ‘patch the worst first’ workflow

Combining MDVM with Defender CSPM attack-path analysis gives the exam-archetype prioritisation:

MDVM identifies the universe of vulnerabilities.
Defender CSPM attack-path analysis identifies which vulnerable assets sit on real attack paths to sensitive data.
Governance rules assign remediation owners and SLAs to those vulnerabilities.
The ‘patch the worst first’ queue is the prioritised cross-section: critical CVE × on an attack path × on an asset holding sensitive data × with a public exploit available.

This is the SC-500 answer to “we have 14,000 open CVEs — which ones matter?”

Scenario: Asha brings Aurora’s AWS + GCP estate + shadow IT into the fold

Aurora Health Service has Azure as the primary cloud, AWS for one legacy clinical workload, and GCP for a research-data project that started without IT involvement.

AWS connector onboards the AWS Organisation. Defender for Servers Plan 2 + Defender for SQL (for RDS) + Defender CSPM enabled. 38 EC2 instances Arc-onboarded automatically.
GCP connector onboards the research-data project. Defender CSPM + Defender for Servers Plan 2. 12 GCE VMs Arc-onboarded.
EASM seeded with Aurora’s primary domain + 4 known subsidiary domains + the registered company name. EASM discovers:
- 73 subdomains (Aurora team knew of 52 — 21 new ones).
- 9 IP ranges historically allocated to Aurora (3 still in use, 6 stale but advertising — Asha follows up with the network team).
- 12 forgotten dev environments on an old SaaS hosting platform (4 still serving content, all unpatched — flagged to the platform team for retirement).
- 1 marketing microsite created by an agency in 2023 with a critical CVE on the published Drupal version — Asha gets it taken offline that day.
MDVM settings: agentless scanning daily across Azure + AWS + GCP; MDE agent-based continuous on supported OSes; authenticated scans configured for the hospital network switches.
Prioritisation queue (Defender CSPM + MDVM): critical CVE × on attack path × on internet-facing × with public exploit — surfaces the top 8 to remediate this sprint.

Aurora’s external attack surface shrinks by ~17% in 60 days — and the team finally knows what they have.