SC-900 Cheat Sheet

In every cloud model, including SaaS, three duties never transfer to Microsoft: your information and data, your devices (the phones, laptops, and PCs that reach your services), and your accounts and identities. Because identity stays yours, so does access management: multifactor authentication, role assignments, and conditional access. These are the most tested 'who is responsible' answers precisely because they never shift to the provider.

Trap Assuming a managed or SaaS service makes Microsoft responsible for your user identities or data; those stay with you no matter how managed the service is.

On-premises you own the whole stack. With IaaS, Microsoft owns the physical hosts, network, and datacenter while you own the operating system, applications, and network controls. PaaS moves the operating system to Microsoft's side, leaving you the application and its data. SaaS hands almost everything to Microsoft. The more managed the service, the smaller your share.

Trap Putting operating-system patching on the customer for PaaS or SaaS; the OS is Microsoft's responsibility there, and only the customer's on IaaS.

Once a workload runs in the cloud, the three physical layers, physical hosts, physical network, and physical datacenter, are Microsoft's responsibility in every service model. The customer never secures the datacenter building, the racks, or the cabling.

Trap Assigning physical datacenter or host security to the customer for IaaS; physical layers are always Microsoft's once you are in the cloud.

Defense in depth uses overlapping controls from the outside in: physical, identity and access, perimeter, network, compute, application, and data at the core. Each layer is independent, so if an attacker gets past one, the next still stands between them and the data. It is the opposite of trusting a single perimeter wall.

Every security control ultimately serves one of three goals. Confidentiality keeps data readable only to authorized parties. Integrity keeps data accurate and unaltered except by authorized changes. Availability keeps systems reachable for legitimate users. Attacks map to these too: theft targets confidentiality, tampering targets integrity, and a denial-of-service targets availability.

Trap Confusing integrity with confidentiality; integrity is about unauthorized modification or tampering, while confidentiality is about unauthorized reading.

Comparing a downloaded file's hash to the value the publisher lists confirms the file was not altered, which is an integrity control. It reveals nothing about who can read the file, so it gives no confidentiality. Hashing detects change; encryption hides content.

Trap Treating a hash or checksum as a way to keep data secret; it detects tampering but does not conceal the data.

Zero Trust drops the assumption that anything inside the corporate network is safe and verifies every request as if it came from an open network. It replaces the old perimeter model because modern attacks use stolen identities and phishing that do not depend on network location. Trust is earned per request, not granted by the network.

Trap Assuming traffic from inside the corporate network is automatically trusted; under Zero Trust, network location is never by itself proof of trust.

The verify-explicitly principle authenticates and authorizes from all available signals: user identity, sign-in location, the device and its compliance state, the app and data involved, and anomalies such as an unusual sign-in time. The more signals evaluated, the more confidence the right person is reaching the right resource. A single factor like a password is not enough.

Trap Treating a correct password alone as sufficient; verify explicitly weighs multiple signals, so a valid password from an unmanaged device or odd location can still be challenged.

The least-privilege principle gives users and systems only the access a task needs, for only as long as it is needed. It is implemented with just-in-time (JIT) access, which grants then revokes, and just-enough-access (JEA), which scopes to the exact permissions required. Risk-based adaptive policies tighten access automatically when activity looks risky.

The assume-breach principle designs security as though an attacker is already inside. You segment access so a compromised account cannot roam freely, encrypt data end to end so intercepted data is unreadable, and monitor with analytics so a breach is detected and contained quickly. Effort shifts from only keeping attackers out to limiting what they can do once in.

Microsoft enforces Zero Trust across six pillars that are the resources and signal sources to defend: identities, devices, applications, data, infrastructure, and networks. A seventh pillar, visibility, automation, and orchestration, aggregates the signals from the other six and coordinates the response, typically through SIEM and SOAR tooling. Identity is described as the primary control plane because most attacks eventually abuse one.

Encryption scrambles data so a holder of the correct key can read it back, so it protects data you must recover later. Hashing runs input through a one-way algorithm to a fixed-length digest, uses no key, and cannot be reversed, so it verifies data without storing the original. The choice turns on one question: do you need to read the value back?

Trap Calling hashing a form of encryption or claiming a hash can be decrypted; hashing has no key and is not reversible.

Symmetric encryption uses the same secret key to encrypt and decrypt, which is fast for bulk data but creates the key distribution problem of sharing that key securely. Asymmetric encryption uses a mathematically linked public and private key pair, so the public key can be shared freely and only the matching private key decrypts. Asymmetric is what solves key distribution and underpins HTTPS.

Trap Thinking data encrypted with the public key can be decrypted with that same public key; only the matching private key can decrypt it.

In asymmetric encryption the two directions do different jobs. Encrypting with the recipient's public key means only their private key can decrypt it, giving confidentiality. Signing with the sender's private key lets anyone with the public key verify it, giving a digital signature that proves authenticity and integrity. The private key is the one you never share.

Trap Swapping the directions, such as expecting the public key to decrypt or to create a signature; only the private key decrypts and only the private key signs.

Data at rest is stored on a disk, database, or storage account, and is encrypted so stolen media stays unreadable. Data in transit is moving across a network and is protected by TLS (as in HTTPS) or a VPN. Data in use is being processed in memory, and is protected by confidential computing that creates a protected execution environment. All three states need their own protection.

Systems store the hash of a password rather than the password, so a stolen database yields only hashes. Because hashing is deterministic, attackers can precompute hashes of common passwords into rainbow tables. Adding a unique random salt to each password before hashing makes two identical passwords produce different stored hashes, so precomputed tables no longer match.

Trap Relying on plain hashing for passwords with no salt; deterministic hashes let attackers match them against precomputed rainbow tables.

Governance is the system of policies and processes that directs how an organization classifies, handles, and grants access to data. Risk management identifies, scores, and treats threats so the organization can make informed decisions. Compliance is adhering to the external laws, regulations, and standards that apply. Governance creates the structure that risk and compliance operate on.

Compliance is the minimum a law or regulation demands, while security is the broader set of practices that actually protect data and systems. Because compliance defines a floor, an organization can pass every required audit and still carry serious vulnerabilities. Meeting a regulation and being secure are not the same claim.

Trap Treating a passed compliance audit as proof the environment is secure; compliance is a minimum standard, not evidence of strong security.

Risk management scores each risk by impact and likelihood, then chooses one of four responses: accept a low risk, mitigate it with controls, transfer it (for example through insurance), or avoid it by changing the process. The goal is not to eliminate all risk but to understand it well enough to decide, then monitor as the environment changes.

Trap Believing risk management aims to remove all risk; the goal is to understand and treat it, and accepting a low risk is a valid response.

Data residency governs where data may be physically stored and how it may cross borders, and the rules vary by jurisdiction. Data sovereignty is the principle that data is subject to the laws of the country or region where it is collected, held, or processed. Because these differ, one dataset can satisfy a residency rule while still falling under another country's laws as it moves.

Trap Using data residency and data sovereignty interchangeably; residency is the physical storage location, sovereignty is which laws govern the data.

Privacy covers personal data, meaning any information that identifies a person directly or indirectly, such as a name, an email address, or location history. Privacy rules require transparency about what is collected, appropriate consent, and honoring individual rights to access, correct, or delete their data. Organizations are subject to these laws wherever they operate and wherever their customers are located.

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service; it authenticates users, apps, and devices over internet protocols such as SAML, OAuth 2.0, and OpenID Connect. It is not on-premises AD DS relocated to the cloud, so it has no domain controllers, organizational units, or Group Policy. When a workload in Azure needs Kerberos, LDAP, NTLM, or Group Policy, that job belongs to Microsoft Entra Domain Services, a separate managed-domain product.

Trap Answering Microsoft Entra ID when a scenario requires LDAP, Kerberos, or Group Policy in Azure; those legacy directory features come from Microsoft Entra Domain Services, not from Entra ID.

Microsoft Entra is the umbrella name for a set of identity and network access products, and Entra ID is the foundational directory and access service at its center. Specialized siblings sit on top of it: Entra ID Protection for risk detection, Entra ID Governance for access reviews and lifecycle, Entra External ID for customer and partner identity, and Entra Workload ID for application identities. On the exam a described capability usually maps to one specific product rather than to Entra ID in general.

Trap Picking Entra ID Governance to detect risky sign-ins; risk detection is Entra ID Protection, while Governance handles access reviews and identity lifecycle.

Everything Entra ID authenticates is an identity, grouped as human identities (users) and machine identities (workload identities and devices). Users are members or guests; workload identities are applications, service principals, and managed identities; devices get an identity through registration or join. Knowing which bucket a thing falls into is the core of the identity-types objective.

Trap Listing groups as an Entra ID identity type; groups are collections used to assign access, not one of the identity types (users, workload identities, devices).

A member is a user from your own organization; a guest is an external person invited through Entra External ID B2B collaboration who signs in with their own home credentials, so you never issue or manage a password for them. Member versus guest is the user distinction SC-900 tests.

Trap Creating a full internal member account for an outside partner instead of inviting them as a B2B guest; the guest keeps their own home identity and you avoid managing their credentials.

Workload identities let applications, services, scripts, and containers authenticate to Entra ID. In Entra ID they take three forms: an application, a service principal, and a managed identity. Reach for one wherever code, rather than a human, needs to sign in and access a protected resource.

An application object is the single global definition of an app, living in the tenant where it was registered, and it acts as a template. A service principal is the local instance of that app inside a specific tenant, and it is the security principal that actually receives permissions and role assignments. One application object maps to many service principals, one in every tenant that uses the app.

Trap Assigning permissions to the application object; access is granted to the service principal, which is the app's local instance in the tenant.

A managed identity is a special type of service principal that an Azure resource uses to obtain Entra ID tokens with no credential to store or rotate, and it is available at no extra cost. It works only with resources and services that support Entra ID authentication.

A system-assigned managed identity is created on a single Azure resource and shares that resource's lifecycle, so it is deleted with the resource and cannot be shared, a strict one-to-one binding. A user-assigned managed identity is a standalone Azure resource with its own lifecycle that you can attach to many resources, making it the reusable choice when several workloads need the same access or when the identity must outlive any one resource.

Trap Choosing a system-assigned managed identity when several resources must share one identity; system-assigned is bound to a single resource, so shared access needs a user-assigned identity.

Giving a device an identity in Entra ID lets policy engines weigh the device in an access decision, which is what enables device-based Conditional Access and Microsoft Intune management. Without a device identity, Entra ID cannot require, for example, a compliant or managed device.

A device gets an Entra ID identity in one of three ways. Entra registered covers personal, bring-your-own devices, including phones and tablets. Entra joined is for organization-owned devices that live only in the cloud. Entra hybrid joined is for organization-owned devices joined to both on-premises AD and Entra ID, typically a transition step for companies that still run an on-premises domain.

Trap Requiring Entra join for a personal phone; a personal, bring-your-own device only needs Entra registration, while join is for organization-owned devices.

Hybrid identity provides a single user identity for authentication and authorization across both on-premises Active Directory and the cloud, so people use the same account everywhere. It is built through directory synchronization plus a chosen sign-in method, and it applies only to organizations that already run an on-premises directory.

Microsoft Entra Connect, and the lighter-weight Entra Cloud Sync, is the tool that synchronizes users and groups from on-premises Active Directory into Entra ID. How a hybrid sign-in is actually verified is a separate choice among three authentication methods, and any sync configuration can sit under any of them.

Trap Naming Microsoft Entra Connect as an authentication method; Entra Connect only synchronizes directory objects, while sign-in is verified by password hash sync, pass-through authentication, or federation.

With password hash synchronization (PHS), a hash of the on-premises password hash is synchronized to Entra ID, which then verifies sign-ins itself, in the cloud. It needs nothing on-premises beyond the sync server, so it is the simplest option, and Microsoft recommends enabling it even alongside another method so cloud sign-in survives an on-premises outage.

Trap Assuming password hash synchronization validates the password on-premises; PHS verifies sign-in in the cloud, unlike pass-through authentication, where an on-premises agent performs the check.

Pass-through authentication (PTA) installs a lightweight agent on an on-premises server that validates the user's password directly against Active Directory, so the password check never happens in the cloud. It suits organizations that must enforce on-premises account state, such as disabled, locked out, expired, or sign-in hours, at every sign-in.

Trap Standing up AD FS when pass-through authentication would do; PTA validates against on-premises AD with a lightweight agent and needs no federation server farm or TLS certificate.

Federated authentication delegates sign-in to a separate trusted system, typically on-premises Active Directory Federation Services (AD FS), which verifies the password on-premises. It fits requirements Entra ID cannot meet natively, such as certain third-party MFA or smartcard scenarios, but it needs its own server farm and a TLS certificate, which makes it the most complex option.

Microsoft Entra Cloud Sync synchronizes on-premises Active Directory identities using a lightweight provisioning agent installed on-premises, with all synchronization configuration managed in the cloud. It supports scenarios that Connect Sync handles poorly, such as synchronizing from multiple disconnected AD forests during mergers and acquisitions.

Trap Assuming Cloud Sync and Connect Sync are interchangeable; Cloud Sync's agent is lightweight and cloud-configured, whereas Connect Sync installs a heavier server configured on-premises.

Azure DDoS Protection mitigates network- and transport-layer floods (volumetric and protocol attacks at layers 3 and 4) but does not read HTTP content, so application-layer attacks such as HTTP floods, SQL injection, and cross-site scripting fall to a Web Application Firewall. Microsoft positions the two as complementary, so DDoS Protection plus a WAF is the defense-in-depth answer covering both the network and the application.

Trap Reaching for Azure DDoS Protection to stop an HTTP flood or SQL injection; those are layer 7 attacks a WAF handles, not DDoS Protection.

The three shapes are volumetric attacks that saturate bandwidth, protocol attacks that exhaust server resources by abusing layer 3 and 4 weaknesses, and resource (application) layer attacks aimed at the web application itself. Azure DDoS Protection covers the first two at layers 3 and 4; the application-layer form is left to a WAF.

The two paid DDoS tiers share the same core mitigation engine but differ in scope and billing: DDoS Network Protection protects an entire virtual network, while DDoS IP Protection is a pay-per-protected-public-IP model. IP Protection omits the value-added extras Network Protection includes, namely DDoS rapid-response support, cost protection, and WAF discounts.

Trap Assuming DDoS IP Protection includes rapid-response support and cost protection; those value-added services come only with DDoS Network Protection.

Azure gives all resources a default infrastructure-level DDoS protection at no cost, but its thresholds are tuned high and it provides no telemetry, alerting, or per-application tuning. A flood the platform treats as harmless can still overwhelm one application, which is why the paid tiers add monitoring, alerts, and adaptive tuning.

Trap Treating the free default infrastructure-level DDoS protection as equivalent to DDoS Network Protection; it lacks telemetry, alerting, and application-tuned thresholds.

Azure Firewall is a cloud-native, fully stateful firewall-as-a-service you typically place on a central hub VNet so every other VNet and on-premises network routes through one policy, giving centralized control across subscriptions. Being stateful, it tracks active connections and judges traffic in context, and it provides built-in high availability across availability zones.

Beyond IP, port, and protocol network rules, Azure Firewall filters application traffic by fully qualified domain name (FQDN) over HTTP/S, and its threat-intelligence filtering alerts on or denies traffic to and from IP addresses and domains Microsoft's feed flags as malicious. It also performs source and destination network address translation (SNAT and DNAT).

Both control traffic to virtual-network resources, but by scope. A network security group does distributed filtering within a VNet, at a subnet or network interface, on the five-tuple. Azure Firewall is a centralized, stateful service that protects across VNets and subscriptions and adds FQDN and threat-intelligence filtering an NSG cannot do. They are complementary layers, not an either-or choice.

Trap Using a network security group where you need FQDN or threat-intelligence filtering; an NSG only allows or denies on the five-tuple, so that job belongs to Azure Firewall.

A network security group evaluates rules by priority (lower numbers first, and evaluation stops at the first match) using five values: source, source port, destination, destination port, and protocol. Each rule either allows or denies, and you can override the undeletable default rules by adding a higher-priority, lower-numbered rule.

You can associate at most one network security group with a given subnet and one with a given network interface (NIC), but the same NSG can be attached to many subnets and NICs at once. This lets a single rule set cover many resources that share the same security needs.

Every NSG ships with default rules (three inbound, three outbound) you cannot delete. Their net effect allows traffic within the virtual network and from the Azure load balancer, allows outbound to the VNet and the internet, and denies all other inbound traffic from the internet. You change this only by adding higher-priority rules.

Trap Assuming a new NSG blocks everything by default; its default rules already allow traffic within the VNet and outbound to the internet, denying only other inbound traffic.

An Azure virtual network is the isolation boundary of your private network in Azure: by default no traffic crosses between VNets or arrives inbound from outside, so any communication must be explicitly provisioned. This default-deny posture is what makes segmentation the practical basis of the Zero Trust assume breach principle.

Trap Assuming resources in two different VNets can talk by default; cross-VNet traffic is denied until you explicitly provision it, for example with peering.

Within a VNet, subnets divide the network into smaller segments with their own controls, for example separating web servers from database servers. Segmenting this way limits lateral movement, so a compromise in one subnet is harder to spread, which serves the Zero Trust assume breach principle directly.

Peering links two virtual networks so their resources communicate as if on one network, and the traffic travels over the private Azure backbone rather than the public internet. Global VNet peering extends this connection across Azure regions.

Azure Bastion is a managed PaaS service provisioned inside a VNet that brokers Remote Desktop Protocol (RDP) and Secure Shell (SSH) sessions to your VMs from the Azure portal over TLS on port 443. The VM keeps only a private IP and never exposes an RDP or SSH port to the internet, which removes the open management port attackers scan for.

Trap Assuming the target VM still needs a public IP with Azure Bastion; the point is that the VM keeps only a private IP while Bastion brokers the session over TLS.

Azure Bastion brokers a single portal-based RDP or SSH session; it does not extend an on-premises network into Azure the way a VPN does, and it is not a jump-box VM you deploy and patch yourself. Azure keeps the Bastion service hardened and current, including against zero-day exploits.

Trap Treating Azure Bastion as a VPN or a self-managed jump-box VM; it is a fully managed session broker that Azure patches and hardens for you.

You provision one Azure Bastion per virtual network, and it also serves peered VNets, rather than one per VM or per subscription. Once it is deployed, every VM in that network and its peers becomes reachable through it.

Azure Key Vault centralizes three kinds of protected material: secrets (passwords, connection strings, API keys), cryptographic keys used to encrypt data, and public and private TLS/SSL certificates it can provision and renew. Applications fetch these at runtime so credentials never sit in application code.

Key Vault stores an application's secrets, keys, and certificates, not user accounts or sign-in credentials. Those identities live in Microsoft Entra ID, which Key Vault itself relies on to authenticate its callers before authorizing them with Azure RBAC or a Key Vault access policy.

Trap Storing user sign-in credentials in Key Vault; user identities belong in Microsoft Entra ID, while Key Vault holds application secrets, keys, and certificates.

Key Vault's Standard tier protects keys with software, while the Premium tier stores them in a hardware security module (HSM), tamper-resistant hardware the keys never leave. Choose Premium when compliance requires HSM-backed key protection; both tiers offer the same secrets, keys, and certificate management otherwise.

Trap Assuming HSM-backed keys come with the Standard tier; hardware security module protection requires the Premium tier of Key Vault.

Access to Key Vault is a two-step gate: authentication, which proves the caller's identity, is always handled by Microsoft Entra ID, and authorization, which decides what the caller may do, is handled by Azure role-based access control (RBAC) or a Key Vault access policy. Every access is logged so you can monitor use.

A Web Application Firewall gives centralized layer-7 protection using the OWASP core rule set against exploits like SQL injection and cross-site scripting, and Azure delivers it through Application Gateway (regional), Azure Front Door (global), or Azure CDN. Patching a vulnerability once at the WAF then covers every application behind it.

Trap Expecting Azure Firewall to block SQL injection or cross-site scripting; those layer-7 web exploits are a WAF's job, delivered through Application Gateway, Front Door, or CDN.

A network security group allows or denies both inbound and outbound traffic at no extra cost and with no dedicated appliance. Because it is stateful, when it permits a connection the return traffic for that connection is allowed automatically, so you never add a matching reverse rule. When it is associated with a subnet, its rules apply to every resource connected to that subnet.

Trap Assuming an inbound allow rule needs a matching outbound rule for the reply traffic.

In Detection mode an Azure WAF records matching requests in the WAF logs but lets them through, which is useful for tuning rules before enforcement. In Prevention mode it actively blocks a matching request, returns a 403 response, and logs the event.

Trap Leaving a tuned policy in Detection mode when the goal is to actively stop malicious requests.

Azure DDoS Protection surfaces rich telemetry through Azure Monitor, including near real-time metrics of packets dropped, forwarded, or tagged during mitigation. It can alert your operations team at the start and stop of an attack, provides attack analytics reports in about five-minute increments during the event, and delivers a forensic mitigation summary report after the attack ends.

Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) with two halves: cloud security posture management (CSPM), which checks whether resources are configured securely, and cloud workload protection (CWPP), which detects threats against running workloads. CSPM is preventive and works on configuration, so it prevents problems; CWPP is detective and works on runtime behavior, so it catches attacks in progress. Sorting any feature into posture or protection is the fastest way to place it on this topic.

The single most testable Defender for Cloud fact is that posture management produces recommendations while workload protection produces security alerts. Free foundational CSPM continuously assesses configuration and surfaces hardening recommendations, but on its own it never raises a runtime threat alert. A security alert appears only when the paid Defender plan for that resource type is enabled and detects an active threat.

Trap Assuming a live attack will always raise an alert; if the matching Defender plan was never enabled, nothing is watching the workload at runtime and no alert fires.

Secure score summarizes your current security posture as a single percentage, computed from how many of Defender for Cloud's recommendations your resources satisfy. Remediating recommendations raises the score, so the score together with its recommendation list is the everyday loop for improving posture. It is a relative measure of hardening, not a pass-or-fail result and not a compliance certification.

Trap Reading the secure score as proof of regulatory compliance; compliance against a named framework such as ISO or PCI is a separate regulatory compliance view, not the secure score.

When Defender for Cloud is enabled, the Microsoft cloud security benchmark (MCSB) is assigned automatically as the initial security standard, and its controls generate most recommendations across Azure, AWS, and GCP. You can add regulatory compliance standards such as ISO 27001 or PCI DSS on top of MCSB, but those added standards require enabling a paid Defender plan, whereas MCSB assessment is free.

Trap Confusing the free MCSB assessment with the paid regulatory compliance standards; MCSB is applied by default at no cost, while adding ISO or PCI requires a Defender plan.

Defender for Cloud continuously evaluates each resource against the controls in its assigned security standards. When a resource does not meet a control, the product generates a security recommendation that describes the gap and the steps to fix it. Standards define what secure looks like, and recommendations are the per-resource findings that flow from failing those controls.

The foundational CSPM tier turns on automatically for every subscription connected to Defender for Cloud and costs nothing. It provides secure score, security recommendations, MCSB assessment, and multicloud posture visibility. What it does not include is runtime threat detection, so it issues no security alerts until a paid Defender plan is enabled.

Cloud workload protection is delivered as individual Defender plans, each covering one resource family: Defender for Servers, for Storage, for Containers, for SQL and other databases, for App Service, for Key Vault, for Resource Manager, and for APIs. You enable the plans for the resource types you want to defend, and each adds runtime threat detection and security alerts for its family. Collectively these paid plans are the workload-protection tier of Defender for Cloud.

Trap Assuming one Defender plan protects the whole environment; each plan covers only its resource type, so any family whose plan is off has no workload protection.

Two capabilities share the CSPM name. Free foundational CSPM gives secure score and recommendations. The paid Defender CSPM plan is a separate upgrade that adds advanced posture tools: agentless vulnerability scanning, attack path analysis, and the cloud security graph and explorer for querying risk across the environment. Both are posture rather than workload protection, so neither raises runtime threat alerts.

Trap Enabling the paid Defender CSPM plan expecting runtime threat alerts; Defender CSPM is enhanced posture, and alerts still come only from a workload-protection Defender plan.

Defender for Cloud protects Azure resources natively, on-premises and other-cloud machines connected through Azure Arc, and AWS accounts and GCP projects connected with agentless connectors. Multicloud posture coverage, including secure score and recommendations for AWS and GCP, is part of the free tier. The result is one portal and one secure score spanning all three clouds.

Trap Assuming Defender for Cloud only covers Azure; AWS, GCP, and on-premises resources connect too, and their CSPM coverage is free.

Microsoft ships two products under the Defender brand. Defender for Cloud protects cloud infrastructure and workloads: subscriptions, virtual machines, storage, databases, and containers, across Azure, hybrid, and multicloud. Defender XDR protects the user side: endpoints, email, identities, and SaaS apps. They integrate but defend different things, so route a question by what is being protected.

Trap Choosing Microsoft Defender XDR to secure an Azure subscription or virtual machine; cloud resource and workload security is Defender for Cloud's job, not XDR's.

Just-in-time (JIT) VM access, an enhanced feature of Defender for Servers, keeps management ports such as RDP and SSH closed by default and opens them only for an approved, time-boxed request from a specific source. Nothing decides the moment of access on its own; the defining protection is simply that the opening is strictly time-limited, which shrinks the window an attacker has to find an exposed port. It cuts attack surface without leaving management ports permanently open.

Defender for Cloud raises security alerts on the workloads it protects and can export them to a SIEM or SOAR system. Microsoft Sentinel ingests those alerts and correlates them with signals from across the estate into incidents. In Zero Trust terms, posture management serves the infrastructure pillar, while these alerts feed the seventh pillar, visibility, automation, and orchestration, where Sentinel is the correlation engine.

Trap Expecting Defender for Cloud to correlate alerts from across the whole estate into incidents; that estate-wide correlation is Microsoft Sentinel's job, and Defender for Cloud is only one signal source feeding it.

In Microsoft Defender for Cloud, related recommendations are grouped into security controls, and each control contributes points to the secure score once its recommendations are remediated. Recommendations are prioritized by risk level and carry a severity rating so you can address the most exploitable issues first.

Trap Treating each recommendation as an isolated item rather than part of a scored security control.

The Fix option remediates a recommendation quickly, often across many affected resources at once, and remediating a misconfiguration reduces the resource's attack surface. Governance rules assign an owner and a remediation due date to drive accountability, while workflow automation triggers a Logic App response, such as a notification, when an alert or recommendation fires.

Trap Reaching for Microsoft Sentinel playbooks when the response should stay inside Defender for Cloud's own workflow automation.

Defender for Servers adds integrated vulnerability assessment and native Microsoft Defender for Endpoint integration to protect Windows and Linux machines across Azure, on-premises, and other clouds. Defender for Containers secures Kubernetes clusters, container registries, and images, scanning registry images for known vulnerabilities when they are pushed and on a recurring basis.

The Service Trust Portal (STP) is where Microsoft publishes the independent audit reports and compliance documentation for its cloud services, so you can download SOC 1, SOC 2, and SOC 3 reports, ISO/IEC certifications, FedRAMP and PCI DSS attestations, and Microsoft whitepapers. You go there to read evidence about Microsoft, not to configure anything on your tenant. If a question asks where to obtain Microsoft's SOC or ISO report, the answer is STP.

Trap Reaching for Microsoft Purview Compliance Manager to download Microsoft's SOC or ISO report; Compliance Manager measures your own tenant, it does not hand you Microsoft's audit artifacts.

The Service Trust Portal and the Microsoft Purview portal both say compliance but sit on opposite sides. STP is read-only evidence about Microsoft's cloud. The Microsoft Purview portal is where you act on your own tenant: run Compliance Manager, configure policies, and review your compliance score. Match the verb in the stem: obtain or download Microsoft's report points to STP, while assess, configure, or improve your posture points to the Purview portal.

Trap Assuming you configure your organization's compliance in the Service Trust Portal; STP is read-only Microsoft evidence, and tenant compliance work happens in the Microsoft Purview portal.

STP organizes documents into a few areas: certifications, regulations, and standards (the ISO/IEC, SOC, FedRAMP, PCI DSS, and CSA STAR artifacts), reports and whitepapers (penetration-test attestations, privacy and data protection material, business continuity and disaster recovery), industry and regional resources, and resources scoped to your own organization. Knowing the buckets helps you locate the right evidence quickly.

Anyone can browse the Service Trust Portal, but downloading many documents requires signing in with a Microsoft Entra organization account and accepting a non-disclosure agreement for compliance materials. Restricted documents need a specific role such as Compliance Administrator or Security Reader. STP is public-facing but gated for its most sensitive audit content.

Microsoft frames its privacy commitment to commercial customers as four areas: you control your data, you know where your data is located, your data is secured at rest and in transit, and Microsoft defends your data. These are contractual commitments backed by the Product Terms and the Data Protection Addendum, not a product you configure.

Trap Picking an option that lists a fifth principle which is actually a product feature or a security control; the privacy principles are these four commitments, not a Priva feature or a portal setting.

Under the control-your-data principle, your data belongs to you: you can access, modify, or delete it, and Microsoft uses it only to provide the services you chose. Microsoft does not use your data for advertising or mine it for marketing research, and any subprocessor it engages is bound by the same commitments. This is the principle often paraphrased as no content-based advertising.

Under the defend-your-data principle, Microsoft directs government and law-enforcement requests for your data to you rather than answering them itself, gives no government direct or unfettered access, and challenges demands in court where it can lawfully do so. It is a commitment about how Microsoft responds to third-party and government access attempts.

STP and the privacy principles describe Microsoft's obligations to you; Microsoft Priva flips the direction. Priva is the product your organization operates to manage the personal data it holds, meeting your privacy obligations to your own users. When a stem is about finding or reducing risk in personal data you store, the answer is Priva, not a Microsoft-published document.

Trap Treating Priva as something Microsoft runs to protect its own cloud; Priva acts on your tenant's personal data and is your responsibility to operate.

Priva's Privacy Risk Management solution gives visibility into personal data across your Microsoft 365 services and flags privacy risk using built-in policy templates: data minimization (personal data kept but no longer needed), data overexposure (personal data open to too many people), and data transfers (personal data crossing departments or borders). On a match it raises an alert and offers remediation such as making an item private, notifying the owner, or tagging it for review.

Priva scans personal data in your organization's Microsoft 365 services (Exchange Online, SharePoint, OneDrive for Business, and Teams) plus sources you register through Microsoft Purview, using Purview's data classifications and sensitive information types to identify it. It does not reach a user's personal Microsoft account or arbitrary systems outside your tenant.

Trap Assuming Priva can scan a user's personal Microsoft account or data outside Microsoft 365; Priva is limited to your organization's Microsoft 365 environment and Purview-registered sources.

A data subject request (DSR), also called a subject rights request, is an individual's request to access, correct, export, or delete the personal data an organization holds on them, a right granted by privacy laws such as the GDPR. Handling one obliges the organization to first find that person's personal data, then decide what to produce, redact, correct, or erase.

Keep the division of labor: Priva finds and reduces privacy risk across your tenant's personal data, while locating and producing one individual's data to satisfy a data subject request is done with Microsoft Purview eDiscovery. A stem about responding to a specific DSR points to eDiscovery, not to Priva's risk policies.

Trap Choosing Priva Privacy Risk Management to fulfil a specific data subject request end to end; Priva surfaces privacy risk, but eDiscovery is what locates and exports one individual's data.

Priva and Compliance Manager both concern your own obligations but answer different questions. Priva finds and reduces privacy risk in the personal data you hold. Purview Compliance Manager scores how well your tenant meets regulatory requirements overall and lists improvement actions. A personal-data privacy stem points to Priva, while an overall compliance score points to Compliance Manager.

Trap Reaching for Compliance Manager to find and remediate personal data overexposure; that is Priva's job, while Compliance Manager tracks your overall compliance score, not personal-data risk.

Do not confuse Priva with Purview's information protection tools. Sensitivity labels, data loss prevention, and retention classify and protect data of all kinds across the tenant. Priva is narrower and privacy-specific: it surfaces privacy risk in personal data and drives remediation. A stem about labeling or blocking data broadly is information protection, while a stem about personal-data privacy risk is Priva.

Trap Reaching for sensitivity labels or DLP to run a data minimization or overexposure policy on personal data; those broad protection tools are not Priva's privacy risk policies.