Select Two (Multi-Select) Questions

Client-side encryption of data before upload.

Why it fails: Client-side encryption of data before upload: This is a separate feature provided by the Azure Storage client SDK, where data is encrypted on the client (for example, using Azure Key Vault or a locally managed key) before transmission and decrypted after download. In contrast, SSE operates entirely on the server side, transparently encrypting data only after it reaches Azure Storage. Therefore, client-side encryption is not a built-in capability of SSE and requires additional application code to implement.

Control access to the storage account using RBAC.

Why it fails: Control access to the storage account using RBAC: Azure RBAC is an authorization mechanism that governs which identities can perform management and data operations, such as listing or reading blobs. While RBAC is essential for securing access to a storage account, it does not perform encryption or participate in the SSE encryption pipeline. Encryption and access control are independent security layers, so RBAC control should not be conflated with data-at-rest encryption.

App registration

Why it fails: App registration is not an authentication method; it is a configuration object in Microsoft Entra ID that defines an application's identity and the permissions it needs, enabling OAuth 2.0 and OpenID Connect flows. Registering an app only creates a service principal or application principal that acts as a non-user identity for programmatic access, and it is how apps authenticate to Entra ID, not how users authenticate. Users still rely on user-level authentication methods such as passwords, FIDO2 keys, or Temporary Access Passes to sign in to the tenant.

Managed identity

Why it fails: Managed identity is not a user authentication method; it is an Microsoft Entra ID identity automatically assigned to Azure resources, such as VMs, functions, or app services, to authenticate to Azure services and key vaults without embedded credentials. It exists for workload or resource authentication to other Azure resources, representing the application's or service's identity rather than a human user's identity. Users cannot sign in using a managed identity, and it is not presented as an authentication option in the Entra ID sign-in experience.

Microsoft Entra Connect

Why it fails: Microsoft Entra Connect is a hybrid identity synchronization tool, not an authentication method. It is used to sync on-premises Active Directory objects to Microsoft Entra ID, enabling features like Password Hash Sync, Pass-through Authentication, and federation with AD FS. While it can configure the tenant's authentication settings for hybrid users, the tool itself does not serve as a credential or protocol that users provide at sign-in, so it is fundamentally a provisioning and sync service rather than an authentication mechanism.

Configure password expiration policies to force frequent changes

Why it fails: Password expiration policies are a legacy credential-lifecycle control, not a zero-trust control. Zero trust centers on continuously verifying identity, device health, and context for every request; forcing frequent password changes fails to do that and actually encourages predictable, weak password patterns. Microsoft's security guidance aligns with NIST recommendations that periodic forced expirations be abandoned in favor of modern, risk-based authentication such as MFA and Conditional Access. The only time a password change matters in zero trust is when compromise is detected, which is a reactive, not proactive, control.

Enable password hash synchronization to Microsoft Entra ID

Why it fails: Password hash synchronization (PHS) simply synchronizes on-premises Active Directory password hashes to Microsoft Entra ID so that sign-ins can be authenticated against the same credential in the cloud. PHS is an identity-connectivity feature that enables hybrid users to access cloud resources, but it does not itself enforce zero-trust principles like verify explicitly or use least privilege. Zero trust requires authentication to be challenged based on real-time signals—user, device, location, and risk—whereas PHS merely makes the same static credential available for authentication without any policy enforcement.

Assign permanent Global Administrator roles to IT staff

Why it fails: Assigning permanent Global Administrator roles to IT staff violates the zero-trust principle of least privilege and 'assume breach.' Permanent roles grant standing, unrestricted access to all Microsoft Entra ID and tenant-wide resources; if a Global Administrator account is compromised, the attacker inherits that persistent, high-privilege access without any additional verification. Zero trust demands that access be explicitly verified and time-bound, not statically assigned. Instead, administrators should use PIM to activate elevated roles only when needed, with approval and just-in-time limits.

Configure Azure DNS zones.

Why it fails: Azure DNS zones are a name resolution service, either public or private, that hosts DNS records such as A, CNAME, or MX for domains. They translate human-readable names to IP addresses but do not inspect or filter network packets, block unauthorized connections, or enforce security policies. Configuring DNS zones neither strengthens the VNet's perimeter nor protects resources from network-level threats, so it is not a valid action for securing a virtual network.

Deploy Azure Bastion for VM access.

Why it fails: Azure Bastion is a managed PaaS service that provides secure, browser-based RDP/SSH access to VMs through TLS, eliminating the need for public IP addresses on those VMs. While it protects the management plane from direct internet exposure, it does not filter traffic between subnets, control inbound/outbound connectivity for applications, or enforce network-level security policies. Bastion addresses only the access path to VMs, not the overall security of the VNet itself.

Set up Azure Monitor alerts.

Why it fails: Azure Monitor alerts are a monitoring capability that sends notifications when conditions such as metric thresholds, log queries, or activity events are met. Alerts help detect potential security issues and trigger responses, but they take no direct action to block, filter, or isolate network traffic. Merely setting up alerts does not secure the VNet; security requires enforcement mechanisms like NSGs and Azure Firewall, not just visibility or notification.

Force password change on next sign-in

Why it fails: This is not a valid Conditional Access configuration because force password change at next sign-in is a per-user property, not an assignment condition or access control. It can be set through PowerShell or the Microsoft Entra admin center, but it does not appear anywhere in a policy's users, conditions, or grant blocks.

Block access for users without MFA registered

Why it fails: This is not a valid condition because MFA registration status is not one of the signals Conditional Access can evaluate. Requiring MFA is a grant control, and the policy cannot use registered-or-not as an if-then condition like sign-in risk or location. Even the default MFA experience can prompt a user to register during authentication, so blocking purely on existing registration requires a separate entitlement check.

Assign licenses to users based on location

Why it fails: Assigning licenses is an administrative operation, not a sign-in policy decision. Conditional Access policies control access by evaluating signals and granting or blocking sign-ins; they never assign or revoke licenses. Group-based licensing can be based on group membership or attributes, but location is not a valid license-assignment criterion.

Configure Azure Site Recovery for the VMs

Why it fails: Azure Site Recovery (ASR) provides continuous replication of virtual machines to a secondary Azure region so workloads can be failed over during a disaster, but it is not a backup service. It does not create scheduled, point-in-time recovery points that are retained for weeks or months and can be used to restore from accidental deletion, file corruption, or ransomware attacks. Azure Backup is the service that captures VM snapshots and stores them in a Recovery Services vault for granular restore at a chosen point in time.

Enable Azure Disk Encryption on the VMs

Why it fails: Azure Disk Encryption (ADE) uses BitLocker on Windows and DM-Crypt on Linux to encrypt the OS and data disks of the VM itself, thereby protecting the source data at rest in the managed disks. However, it does not encrypt the backup snapshots or recovery points that Azure Backup writes to the Recovery Services vault; those are encrypted separately by the backup service at the vault level. A complete backup security posture requires both ADE for protecting the production disks and vault-level encryption for protecting the backup data.

Use geo-redundant storage (GRS) for the Recovery Services vault

Why it fails: Geo-redundant storage (GRS) for the Recovery Services vault replicates backup data to a geographically paired Azure region, providing high durability and protection against loss of the primary vault. But GRS alone does not allow the VM to be restored from that secondary copy—the restore operation still reads from the primary region unless you separately enable the Cross-Region Restore (CRR) feature. Thus, selecting GRS is a storage redundancy decision and is not a substitute for enabling CRR to actually make restores possible in the paired region.

Azure Firewall Manager integration.

Why it fails: Azure Firewall Manager is a centralized network security management service for deploying and managing Azure Firewall and Web Application Firewall policies across hub-and-spoke architectures. It is not a manifest control of Microsoft Defender for Cloud's foundational CSPM; rather, it is an optional, separately configured service that customers deploy for network segmentation. Foundational CSPM focuses on resource posture assessment, not on orchestrating firewall policies, so this integration is not automatically provided.

Just-in-time (JIT) VM access.

Why it fails: Just-in-time (JIT) VM access is an enhanced Microsoft Defender for Cloud capability that locks down inbound traffic to VMs and gates RDP/SSH access via role-based approvals. This feature is only available after you enable the paid Defender for Servers plan; it is not part of the free foundational CSPM tier. Foundational CSPM delivers continuous assessment and recommendations, not active network hardening like JIT, so it cannot be considered an automatically provided control.

Vulnerability assessment for VMs.

Why it fails: Vulnerability assessment for VMs—whether using the Qualys-based scanner or Microsoft Defender Vulnerability Management—does not run automatically under the free foundational CSPM tier. It is an add-on capability that requires the Microsoft Defender for Servers plan to be enabled, and even then, it must be explicitly configured and deployed to your VMs. Therefore, it is an enhanced, paid security feature rather than an automatically provided foundational control.

Azure Cost Management budget alerts

Why it fails: Azure Cost Management budget alerts are a financial governance tool that monitors subscription-level or resource-group-level spend against defined thresholds and sends notifications when spending approaches or exceeds a budget. They are delivered through the Cost Management + Billing portal and are in no way a component of Microsoft Defender for Servers Plan 2. Even though Defender for Servers Plan 2 also carries data-transfer allowances for each server, budget alerts do not provide any security or workload-protection capability, so this option does not answer the question.

Microsoft 365 message trace

Why it fails: Microsoft 365 message trace is a mail-flow diagnostic tool within Exchange Online that lets administrators track messages as they traverse the transport pipeline and verify how spam filters or mail-flow rules handled them. It belongs to Microsoft 365 email protection, not OS-level server hardening, and Defender for Servers Plan 2 does not consume or expose message trace data. Choosing this option would be incorrect because it confuses email routing with server workload protection.

Enable shared access key authentication.

Why it fails: Enabling shared key authentication exposes a pair of account-wide keys that grant full administrative access to the storage account; if leaked, an attacker can read or copy all blobs without any identity-based restrictions. Shared keys do not restrict the network source, so they do not prevent exfiltration and instead broaden the attack surface. This is an authentication mechanism, not a network-level control.

Enable soft delete for blobs.

Why it fails: Soft delete for blobs is a data recovery feature that retains deleted blobs for a configurable period, allowing you to restore them after accidental deletion or overwrite. It does not authenticate callers, inspect network traffic, or block an authorized user from copying data to an external destination; exfiltration would be undetected and unblocked. Thus, soft delete helps availability and recovery but is not a security control against data exfiltration.

Configure CORS rules to allow all origins.

Why it fails: CORS rules are a browser-enforced mechanism that tells the browser whether a web application running on one origin may read responses from your storage account; they do not control non-browser clients such as PowerShell, Azure CLI, or direct REST calls. Setting CORS to allow all origins actually makes browser-based access more permissive, increasing the risk of cross-origin attacks rather than preventing data theft. It is therefore ineffective and potentially harmful for exfiltration prevention.

Enable container soft delete with a retention period of 30 days

Why it fails: Container soft delete only protects the container resource itself, not the blobs inside it. If a blob is deleted while the container remains intact—the most likely scenario for accidental deletion of a single financial file—container soft delete does nothing because it only triggers when the entire container is removed. Moreover, it does not handle overwritten blobs or storage account deletion, so relying on it alone leaves the sensitive records exposed to both data corruption and account loss.

Enable blob versioning

Why it fails: Blob versioning keeps a history of each blob's contents as it is overwritten, enabling rollback to a previous version after an unintended modification. However, versioning does not capture deletions: a deleted blob is not turned into a version unless blob soft delete is also enabled, so the destroyed file would be unrecoverable. It also offers no protection against the storage account being deleted, because versions live inside the account and vanish with it.

Expired Microsoft Entra PIM role assignments

Why it fails: Expired Microsoft Entra PIM role assignments are an identity lifecycle and access governance issue, not a storage-specific security event. Defender for Storage monitors the data plane of storage accounts—blob, file, queue, and table operations—and does not ingest PIM activity or role expiration telemetry. While this may be a compliance risk, it is not a threat that Defender for Storage can detect, so it fails the stated requirement.

Public IP address creation on virtual machines

Why it fails: Public IP address creation on virtual machines is an Azure Resource Manager control-plane operation tracked by Azure Activity Log, not a storage data plane event. Defender for Storage analyzes telemetry from storage services, such as authentication attempts, blob uploads, and queries, and does not monitor VM networking actions; moreover, creating a public IP is not inherently malicious and would at most trigger a Defender for Cloud recommendation, not a storage threat alert.

Require approval on activation.

Why it fails: Requiring approval on activation introduces a separate approval workflow in which a designated approver must review and approve the request before the role becomes active. While this is a valid PIM configuration, the scenario explicitly requires only justification and MFA, so adding an approval step is neither necessary nor sufficient to meet those stated security requirements.

Extend activation duration.

Why it fails: Extending activation duration changes how long a role remains active after successful activation, typically by configuring a maximum duration in hours for the eligible assignment. This setting does not address authentication or justification; it only widens the time window that privileges are available, so it cannot meet the specified requirements for MFA and justification.

Implement Always Encrypted for the PII columns.

Why it fails: Always Encrypted is a client-side encryption feature where the database engine operates on ciphertext but never has the keys; it requires client driver support and can break legacy applications that don't support the feature. It cannot satisfy a server-level encrypt-in-transit requirement because it doesn't control the TLS handshake or connection security. Moreover, it limits queryability (e.g., equality checks only) and is not a substitute for forcing all connections to use TLS 1.2.

Apply Azure Information Protection labels to the database.

Why it fails: Azure Information Protection (AIP) is an information-protection solution that applies classification labels and optional usage restrictions to documents/emails, not to an Azure SQL Database at rest or in transit. It does not change the database's connection security settings, nor does it mask or encrypt T-SQL result-set values. Enabling AIP labels on a database is not a supported mechanism to enforce TLS or protect PII within SQL tables; it merely adds metadata.

Disable the SigninLogs connector for the tenant

Why it fails: Disabling the SigninLogs connector would stop ingestion of Microsoft Entra ID sign-in events entirely, meaning Sentinel would have no data on which to run the impossible-travel query, let alone distinguish legitimate VPN egress from risky anonymous IPs. This is a destructive platform-level change rather than a scoped detection-tuning action, and it would suppress all sign-in detections, not just false positives. It fails the stated requirement because threat hunting and other SigninLogs-based analytics would also be lost.

Raise the query frequency from 1 hour to 24 hours

Why it fails: Raising the query frequency from 1 hour to 24 hours changes the alerting cadence, not the detection logic, so impossible-travel alerts from approved VPN egress IPs would still be generated—just less often. It also introduces up to 24 hours of delay in alert generation, which can undermine incident response for a real impossible-travel event. This does not distinguish trusted from untrusted IPs and therefore does not address the false positive's root cause.

Dynamic Data Masking

Why it fails: Dynamic Data Masking obscures column values in query results at runtime; it neither encrypts stored data nor changes the on-disk representation, so it cannot satisfy an encryption-at-rest requirement. It is tempting because it protects sensitive data from unauthorised viewers, which is its actual purpose — limiting data exposure in application output, not securing the database files themselves.

Row-Level Security

Why it fails: Row-Level Security filters which rows a user can query via predicates; it enforces access control, not encryption, and leaves data stored in plaintext on disk. It is tempting because it restricts data visibility per user, which is its real purpose — controlling row access in multi-tenant or role-based scenarios, not protecting data at rest.

Azure Disk Encryption (ADE)

Why it fails: Azure Disk Encryption encrypts virtual machine OS and data disks, not the SQL Database service's own storage, so it cannot protect database files at rest. It is tempting because ADE is a common Azure encryption control, and it would be correct for encrypting disks attached to an IaaS virtual machine hosting SQL Server.

A client secret stored in the function app settings

Why it fails: A client secret stored in the function app settings does not use a managed identity; it is a manually managed credential that must be rotated and protected in configuration. This approach still requires handling a secret, whereas the stated requirement is to authenticate via an Microsoft Entra ID managed identity, so it fails the core requirement and introduces a security risk.

A public IP address on the function app

Why it fails: A public IP address on the function app is a network-level attribution, not an identity; it cannot authenticate to Azure Key Vault or prove that the request comes from that specific function's managed identity. Even if you restrict the Key Vault firewall by IP address, the function still lacks a credential or token for authentication, so this fails the requirement entirely.

Assign the 'Kubernetes cluster should be accessible only through private endpoint' Azure Policy.

Why it fails: Assigning the 'Kubernetes cluster should be accessible only through private endpoint' policy enforces network-level isolation of the API server, which is a compliance and security control, but it does not activate any Defender for Cloud monitoring. Defender for Containers can operate on a cluster with public or private endpoints; the plan must be enabled independently. Therefore, this action is not a prerequisite and would not satisfy the requirement to protect the AKS cluster with Defender for Containers.

Connect the AKS cluster to Azure Arc.

Why it fails: Connecting the AKS cluster to Azure Arc is intended for managing Kubernetes clusters running outside Azure by projecting them as Azure resources. An AKS cluster is already a first-class Azure resource, so Azure Arc does not apply and does not influence Defender for Cloud. Enabling Defender for Containers is a subscription-level plan activation, not a hybrid-management task, making this step irrelevant for the scenario.

Install the Log Analytics agent on each AKS node.

Why it fails: The Log Analytics agent (OMS agent) on each node is a legacy approach for collecting VM performance and syslog data; it is not the mechanism used by Defender for Containers. Defender for Containers instead uses Kubernetes audit logs and a dedicated host/control-plane data collection pipeline, including Azure Policy for Kubernetes, to detect threats. Installing the Log Analytics agent is therefore both unnecessary and insufficient for this plan.

Enable Azure DDoS Protection Standard on VNet1 to filter outbound traffic based on domain names.

Why it fails: Azure DDoS Protection Standard is designed to protect against volumetric and protocol attacks on public endpoints. It does not filter outbound traffic or support domain name-based rules. It is not relevant to restricting outbound access to specific FQDNs.

Configure a network security group (NSG) on Subnet1 with outbound rules that allow traffic to the FQDNs and deny all other outbound traffic.

Why it fails: Network security groups cannot filter by FQDN; they only support IP addresses, CIDR ranges, service tags, and application security groups. Since the requirement is to allow specific FQDNs, NSGs alone cannot fulfill it. They also do not provide application-layer logging of FQDN-based rules.

Deploy an Azure Application Gateway with WAF and configure custom rules to allow the FQDNs for outbound traffic.

Why it fails: Application Gateway with WAF is an inbound layer 7 load balancer and web application firewall. It inspects inbound HTTP/HTTPS traffic to protect web apps, not outbound traffic from virtual machines. It cannot enforce outbound FQDN restrictions, so it does not meet the scenario's requirements.

Self-service password reset

Why it fails: Self-service password reset is an Entra ID feature that allows end users to reset their own forgotten passwords without help desk involvement. It is not part of Privileged Identity Management, which focuses on managing, activating, and overseeing privileged administrative roles. While both are security-related, SSPR addresses user credential self-recovery rather than temporary elevation of role permissions.

Multi-factor authentication enforcement

Why it fails: Multi-factor authentication enforcement is a general Entra ID security policy applicable to all users, not a feature exclusive to PIM. PIM can require MFA as a condition during role activation, but that merely invokes the existing conditional access or authentication controls. It is not a distinct PIM feature; it is an integration point with broader identity security posture.

Automatic role assignment based on group membership

Why it fails: Automatic role assignment based on group membership is a misunderstanding of how PIM handles groups. While you can add a group as a role-assignable group in PIM, members become eligible for the role, but activation still requires a manual, time-boxed activation through the PIM workflow. PIM does not automatically grant active role assignment solely based on group membership.

Azure RBAC roles

Why it fails: Azure RBAC roles govern access to Azure resources such as virtual machines, storage, and subscriptions, not to Microsoft Entra ID administrative functions. Since the question targets least privilege for directory roles, assigning Azure RBAC roles would leave directory permissions untouched and fail to constrain who can manage users, groups, or apps. Thus it cannot fulfill the stated requirement.

Conditional Access policies

Why it fails: Conditional Access policies control access conditions like device compliance, location, or multi-factor authentication for sign-in events, but they do not alter the permissions granted to a role. While they can reduce risk by restricting when privileged roles are used, they cannot define which specific directory permissions a role holds. Therefore they are not a mechanism for role-based least privilege.

Microsoft Entra B2B external identities

Why it fails: Microsoft Entra B2B external identities are designed for inviting guests and external partners to access resources, not for managing internal role permissions. Using B2B would bring in outside users but would not help refine which directory administrative tasks any user can perform. As such, it is unrelated to the goal of least privilege for Microsoft Entra roles.