Practice Test #3

Correct answer: D (virtual networks). Azure DDoS Protection Standard is enabled at the Virtual Network (VNet) level. When a VNet is protected, DDoS Standard provides enhanced mitigation for eligible resources within that VNet that have public IP exposure (for example, public IPs associated with Azure Load Balancer, Application Gateway, or internet-facing VMs). This is the key scope concept the exam expects: DDoS Standard is a network protection service applied to VNets, not to identity objects or management containers. Why the other options are wrong: A (Azure AD applications) is incorrect because Azure AD apps are identity/application registrations; DDoS Standard doesn’t attach to or protect Azure AD app objects. B (Azure AD users) is incorrect because DDoS is not an identity attack type; Azure AD user protection is handled by services like Microsoft Entra ID Protection and Conditional Access. C (resource groups) is incorrect because a resource group is a logical management container for resources; DDoS Standard is not enabled at the resource group scope. You enable it on a VNet, and then resources in that VNet benefit from the protection.

Yes. “Control” is a key Microsoft privacy principle. In Microsoft privacy guidance, control refers to giving customers and individuals meaningful choices and the ability to manage how their data is collected, used, and shared. In a cloud context, this shows up as capabilities such as configuring privacy settings, managing data retention, choosing where data is stored (where applicable), and using tools to access, export, or delete data. Why not No: Microsoft explicitly positions customer control as foundational to privacy—customers should be able to determine how their data is handled and to configure services accordingly. This is distinct from security controls (like MFA) because the emphasis is on privacy choices and data handling, not only protection from threats.

Yes. “Transparency” is a key Microsoft privacy principle. Transparency means Microsoft communicates clearly about privacy practices—what data is collected, why it is collected, how it is used, how long it is retained, and with whom it may be shared. This is commonly reflected through privacy statements, product documentation, audit/compliance documentation, and service-specific disclosures. Why not No: Transparency is repeatedly emphasized in Microsoft’s privacy posture because it enables informed decision-making and supports compliance obligations (for example, notice requirements under GDPR). In exam terms, transparency is a privacy principle, whereas items like threat protection or identity governance are security/identity capabilities rather than privacy principles.

No. “Shared responsibility” is not a Microsoft privacy principle; it is a cloud service model concept (shared responsibility model) describing how responsibilities for security and compliance are divided between Microsoft (cloud provider) and the customer. For example, Microsoft is responsible for the security of the cloud (physical datacenters, core infrastructure), while customers are responsible for security in the cloud (identity configuration, data classification, access management, endpoint security, etc.), depending on IaaS/PaaS/SaaS. Why not Yes: Although shared responsibility strongly influences privacy outcomes (customers must configure services appropriately to meet privacy obligations), Microsoft does not list “shared responsibility” as a privacy principle. It is taught under cloud security/compliance fundamentals, not as a privacy commitment like control or transparency.

Correct answer: C. Microsoft Defender for Identity. Microsoft Defender for Identity is a cloud-based security solution designed specifically to use signals from on-premises Active Directory (AD) to identify, detect, and help investigate advanced threats, compromised identities, and malicious insider actions. It typically collects telemetry from domain controllers (via Defender for Identity sensors) and analyzes AD-related activities to surface suspicious behaviors and attack patterns. Why the others are wrong: - A. Microsoft Defender for Cloud Apps focuses on SaaS application discovery, shadow IT, app governance, and controlling/monitoring cloud app usage (CASB capabilities). It is not primarily about on-prem AD signals. - B. Microsoft Defender for Endpoint focuses on endpoint devices (Windows, macOS, Linux, mobile) for EDR, vulnerability management, and attack surface reduction—not AD domain controller telemetry. - D. Microsoft Defender for Office 365 protects email and collaboration (Exchange, SharePoint, OneDrive, Teams) against phishing, malware, and business email compromise, not on-prem AD signal-based identity threat detection.

Correct answer: C (on-premises Active Directory Domain Services (AD DS)). Microsoft Defender for Identity identifies advanced threats by collecting and analyzing signals directly from on-prem AD DS environments. It does this using Defender for Identity sensors installed on domain controllers (or a standalone sensor) to monitor authentication and directory-related activity. These on-prem signals enable detections for identity-focused attacks such as suspicious logons, abnormal Kerberos/NTLM usage, reconnaissance, lateral movement, and other behaviors that are visible at the domain controller level. Why the others are wrong: A (Azure Active Directory/Azure AD, now Microsoft Entra ID) is primarily the signal source for cloud identity protections like Entra ID Protection, Conditional Access, and sign-in risk/user risk detections. While MDI integrates with cloud portals, its core telemetry is from on-prem AD DS. B (Azure AD Connect) is a synchronization component used to sync identities between AD DS and Entra ID. It is not designed to provide the behavioral/security signals that MDI uses for advanced threat detection.

Yes. Azure Policy supports automatic (or semi-automatic) remediation through policy effects such as DeployIfNotExists and Modify. When these policies are assigned, you can create a remediation task that uses a managed identity to deploy missing configurations or modify existing resources to bring them into compliance (for example, automatically adding required tags, enabling diagnostic settings, or deploying a specific configuration if it’s missing). It’s important to note the nuance: not every policy can remediate. Policies with Deny prevent non-compliant changes but don’t “fix” existing resources. Policies with Audit only report. Remediation is specifically associated with DeployIfNotExists/Modify and requires appropriate permissions and, often, a managed identity. Because Azure Policy does provide a remediation mechanism, the statement that it supports automatic remediation is true.

Yes. A primary use case for Azure Policy is ensuring that new resources adhere to corporate standards. You can assign policies that enforce standards at deployment time (for example, Deny creation of resources outside approved regions, require specific SKUs, enforce naming/tagging conventions, or require encryption settings). When a Deny policy is in place, non-compliant resource creation or updates are blocked, which is a direct way to ensure new resources meet organizational requirements. This is a foundational governance pattern in Azure: define standards as policy definitions, assign them at the appropriate scope (often management group for enterprise-wide standards), and use initiatives (policy sets) to group related requirements. Therefore, Azure Policy can be used to ensure new resources adhere to corporate standards.

No. Compliance evaluation in Azure Policy does not occur only when a target resource is created or modified. Azure Policy performs periodic compliance scans to evaluate existing resources against assigned policies, which helps detect configuration drift and newly discovered non-compliance even if no recent change was made to the resource. Additionally, compliance evaluation can be triggered on demand (for example, via the Azure portal or APIs) and is also influenced by policy assignment changes (if you assign a new policy, existing resources are evaluated against it). While creation/modification events are important moments where policy can deny or audit changes, ongoing evaluation is a key feature for continuous compliance reporting. Because evaluation is continuous/periodic and not limited strictly to create/modify events, the statement is false.

Yes. You can add a resource lock at the subscription scope. Azure resource locks support multiple scopes: management group, subscription, resource group, and individual resource. When you apply a lock at the subscription level, it is inherited by all resource groups and resources within that subscription, which is useful for broad protection (for example, preventing deletion of all resources in a production subscription). This is a governance feature of Azure Resource Manager, not tied to a specific service. The lock can be CanNotDelete or ReadOnly. The main caveat is that applying a subscription-level lock can have wide operational impact, so it should be used carefully and typically combined with RBAC and policy. Therefore, the statement is true.

No. You can add more than one resource lock to an Azure resource. Azure supports multiple locks at the same scope (for example, a CanNotDelete lock and a ReadOnly lock), and locks can also be inherited from parent scopes (resource group, subscription, management group). The effective restriction is the most restrictive combination of all applicable locks. For example, if a resource has no direct lock but the resource group has a CanNotDelete lock, the resource cannot be deleted. If you then add a ReadOnly lock directly on the resource, it becomes read-only as well. Because multiple locks can exist and stack/inherit, the statement “only one resource lock” is incorrect.

No. You cannot delete a resource group if it contains resources that have resource locks that prevent deletion. Deleting a resource group is effectively a bulk delete operation for all contained resources. If any contained resource has a CanNotDelete lock (or a ReadOnly lock, which also blocks deletion), the delete operation will fail until the lock is removed. This is a common exam trap: even if you have Owner permissions, the lock still blocks deletion unless you first remove the lock (and you must have permissions to remove locks). In practice, administrators remove or adjust locks as part of a controlled change process before deleting a resource group. Therefore, the statement is false.