Scenario practice questions

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.

Microsoft Authenticator app

Why it fails: The Microsoft Authenticator app provides strong authentication by generating a time-based code or supporting push notifications and passwordless phone sign-in. However, it is not a built-in, zero-footprint solution: the user must install the app on a mobile device, register it with their Entra ID account, and maintain an internet connection. Therefore it fails when the requirement is to avoid deploying additional software or hardware.

FIDO2 security keys

Why it fails: FIDO2 security keys are a phishing-resistant passwordless method that uses a physical key (USB, NFC, or Bluetooth) to sign in. This approach requires purchasing and distributing hardware keys to each user, configuring dynamic lockouts, and ensuring device compatibility, which is significantly more complex than a built-in software option. It is wrong when the objective is to avoid hardware deployment and minimize extra prerequisites.

Certificate-based authentication

Why it fails: Certificate-based authentication (CBA) requires an enterprise public key infrastructure to issue, enroll, renew, and revoke client certificates on managed devices. The authentication relies on the certificate being provisioned to the user's device, which demands MDM or GPO deployment and ongoing certificate lifecycle management. This makes it unsuitable if you want to avoid certificate infrastructure and device management overhead.

Security policy

Why it fails: Security policy in Microsoft Defender for Cloud is grounded in Azure Policy, which enforces configuration and compliance requirements across resources, such as requiring encryption or specific security settings. These policies are evaluated continuously to produce recommendations and compliance scores, but they are not triggered by individual security alert events. They lack any logic to react to an alert's metadata or severity, so they cannot initiate an isolation workflow. A security policy might define the desired end-state, but it does not provide a runtime response to an active threat.

Alert suppression

Why it fails: Alert suppression rules in Microsoft Defender for Cloud are designed to reduce alert fatigue by hiding alerts that match specified conditions, such as a particular alert name or entity, based on a suppression rule like a category or security issue. However, they operate solely as a filtering mechanism on the alert stream; they do not initiate any response or action. Suppressed alerts never appear in the dashboard or feed into automation, so a compromised VM would remain unaffected and unisolated. This is fundamentally different from workflow automation, which actively invokes a Logic App to perform remediation.

Continuous export

Why it fails: Continuous export is a feature that forwards security alerts, recommendations, and other data from Microsoft Defender for Cloud to a Log Analytics workspace or an Event Hub for further processing and storage. It is a unidirectional data streaming mechanism, not a control channel for remediation actions. While you could build a custom downstream solution, such as an Azure Function that listens to the Event Hub and isolates a VM, the continuous export feature itself never triggers a Logic App or performs an action. Therefore, it does not automate the isolation directly, only makes the data available for potential external automation.

Row-Level Security

Why it fails: Row-Level Security (RLS) is a database authorization feature that restricts data access by filtering rows at query time based on the user's security context or predicate function. It does not perform any encryption of the underlying database files, backups, or transaction logs. Therefore, although RLS is valuable for fine-grained access control, it cannot satisfy a requirement for encrypting data at rest on-premises before migration.

Dynamic Data Masking

Why it fails: Dynamic Data Masking (DDM) obscures sensitive data in query results for non-privileged users by applying masking rules, such as showing only the last four digits of a credit card. However, DDM does not encrypt the underlying data; the full plaintext value remains physically stored in the database pages and is still visible to users with explicit SELECT permissions on the underlying tables. As a result, DDM does not provide encryption at rest and fails the stated security requirement.

Always Encrypted with secure enclaves

Why it fails: Always Encrypted with secure enclaves protects sensitive data by encrypting it in the client application and storing only ciphertext in the database, while also enabling rich computations on encrypted data inside a trusted enclave. Nevertheless, this feature is designed to protect specific columns from unauthorized access and does not encrypt the entire database at rest; it also does not use Azure Key Vault for Transparent Data Encryption key management. Therefore, it does not meet the requirement for TDE with customer-managed keys.

Azure Application Gateway

Why it fails: Azure Application Gateway is a layer-7 load balancer and Web Application Firewall designed to route inbound HTTP/HTTPS traffic to backend pools based on URL paths, host headers, or other L7 attributes. For a single VM needing basic per-VM connectivity rules, it introduces significant operational overhead—you must configure listeners, routing rules, and health probes—and it does not manage outbound internet access from the VM. Therefore, while it could technically proxy incoming web traffic, it is not the minimal, direct security control required here.

Azure Firewall

Why it fails: Azure Firewall is not the appropriate choice here because it is designed for centralised network security across multiple workloads or virtual networks, not for securing a single VM directly with minimal configuration. Implementing it for a lone VM would introduce unnecessary routing complexity and cost. However, it is tempting as a managed firewall service, and would be the correct option for enterprise-grade scenarios requiring advanced, centralised traffic filtering, threat intelligence, and policy enforcement for an entire network.

Azure Bastion

Why it fails: Azure Bastion is a fully managed platform-as-a-service offering that provides secure, browser-based RDP and SSH connectivity to virtual machines over the Azure portal. It does not filter general application traffic such as HTTP/HTTPS, nor does it govern outbound internet access from the workload—it only mediates interactive administrative sessions. Deploying Bastion for this requirement would be both functionally irrelevant and an unnecessary cost, as it is not a network security control for application data plane traffic.

Set 'Require Azure Multi-Factor Authentication' to 'On'

Why it fails: Setting 'Require Azure Multi-Factor Authentication' to 'On' only strengthens the identity verification of the user making the activation request; it validates that the caller is who they claim to be. It does not introduce a second party who reviews and consents to the elevation. Since no other individual or group must sign off, the role can still be activated automatically after authentication, leaving no approval control at all.

Set 'Require justification on activation' to 'On' and also enable 'Require ticket information'

Why it fails: Requiring justification and ticket information on activation forces the user to supply business context, which is valuable for auditing, but these are merely mandatory text fields during the request. Once the user enters a reason and ticket number, PIM does not route the request to any other person for authorization—it proceeds with activation according to the role's settings. Thus these options collect data but create no approver workflow.

Create a separate PIM request workflow using Azure Logic Apps

Why it fails: While you could architect a custom approval pipeline with Azure Logic Apps that reacts to PIM audit events and triggers external sign-offs, this is not a native PIM configuration and would introduce significant custom code and identity handling complexity. PIM has a built-in approval feature that is the intended, supported path, and using Logic Apps instead ignores the actual product capability. Custom workflows also risk inconsistencies with PIM's role activation state, whereas the native approval integrates directly with the role lifecycle.

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.

Analytics rule

Why it fails: Analytics rules are query-based detection mechanisms that generate alerts or incidents when suspicious activity is identified. However, they lack native capability to run automated responses such as playbooks; they only signal detection. To tie a detection to an automated workflow, you must configure an automation rule that listens for the incident or alert creation and then triggers the playbook as an action.

Playbook

Why it fails: A playbook is an Azure Logic Apps–based workflow that defines a sequence of actions for incident response, such as isolating a compromised VM or notifying an analyst. However, a playbook is passive until invoked; it does not monitor for incidents or evaluate conditions on its own. It must be called by an automation rule (or directly by an analyst) to start, so selecting "playbook" as the response mechanism is incomplete without the rule that links it to an incident trigger.

Hunt

Why it fails: Sentinel's hunting is an interactive threat-hunting capability where analysts use KQL queries to find suspicious activity across data sources. It is designed for proactive discovery, not for automated incident response. Hunts do not trigger playbooks or any other automatic action; they require human analysis, and any follow-up response would need separate configuration through an automation rule.

Configure the activation maximum duration only

Why it fails: Setting only the activation maximum duration in Microsoft Entra PIM role settings limits how long an eligible role remains active, but this control is independent of the justification and ticket-information requirements. Without also enabling the 'Require justification' and 'Require ticket information' toggles, an administrator can activate the role without providing a business reason or an incident ticket, so the activation does not meet the full audit and compliance requirements. In PIM, these settings are configured separately for each role and must all be enabled to satisfy the scenario.

Configure the requirement for justification only

Why it fails: While enabling 'Require justification' forces the user to enter a free-text reason during activation, PIM does not automatically require a ticket number, nor does it shorten the activation period. The default maximum activation duration could still be as long as the tenant administrator has configured (for example, 8 hours), so without also setting the duration to 4 hours and enabling ticket information, the activation does not satisfy the stated policy. All three settings must be toggled on in the role's settings page to enforce the full requirement.

Configure the requirement for ticket information only

Why it fails: Enabling 'Require ticket information' makes a ticketing field mandatory, but the activation could still proceed with no free-text justification and with the default maximum duration still in effect. In PIM, the ticket-information requirement is a separate dropdown that does not automatically turn on justification or change the activation duration. To meet the scenario, you must also require justification and explicitly set the activation maximum duration to four hours in the same role settings.

Require multifactor authentication

Why it fails: Multifactor authentication verifies the user's identity via an additional factor (e.g., phone or authenticator app) but does not evaluate the device's compliance state. A non-compliant device can still pass MFA if the user's credentials and second factor are valid, so this grant control fails to block devices that lack required patching, encryption, or other Intune policies.

Block access

Why it fails: Block access is a blanket denial that prevents all users and devices—including compliant ones—from accessing the resource. It does not selectively evaluate device compliance; rather, it would stop every authentication attempt, making it ineffective for a scenario where only non-compliant devices should be denied.

Require hybrid Microsoft Entra ID joined device

Why it fails: Requiring a hybrid Microsoft Entra ID joined device checks the device's join state (domain membership plus Microsoft Entra ID registration), not its compliance with Intune policies. A device can be hybrid Microsoft Entra ID joined yet still be non-compliant—for example, missing security updates or lacking BitLocker encryption—so this control does not ensure the device meets compliance requirements.

Create a Logic Apps playbook that runs on a schedule.

Why it fails: A scheduled Logic Apps playbook executes on a timer, independent of Defender for Cloud's compliance state, so it cannot promptly react when a resource becomes non-compliant. While you could build a polling loop to scan for failing recommendations, that introduces latency and doesn't leverage the native event-driven automation triggers built into Defender for Cloud for immediate remediation. Consequently, this approach lacks the automatic, compliance-state-driven remediation the question requires.

Configure Microsoft Sentinel to automatically remediate based on alerts.

Why it fails: Microsoft Sentinel is a cloud-native SIEM and SOAR platform focused on detecting, investigating, and responding to security incidents and alerts, not on enforcing resource configuration. To remediate a Defender for Cloud recommendation via Sentinel, you would need to build a custom playbook that calls the Azure REST API, which is an indirect, over-engineered workaround. Since Defender for Cloud recommendations aren't automatically surfaced as Sentinel alert logic, this option fails to provide reliable, automatic remediation for compliance findings.

Use Azure Automation runbooks to manually run remediation.

Why it fails: Azure Automation runbooks are just scripts — they execute only when explicitly launched, scheduled with custom logic, or triggered by an external hook, so they do not remediate automatically by themselves. The user would have to manually start the runbook to apply changes, making this a manual remediation process rather than an automatic one tied to Defender for Cloud's compliance state. While runbooks can be powerful for complex orchestration, they lack the native, out-of-the-box integration that DeployIfNotExists or Quick Fix! provides for recommendation remediation.

0 (no additional rules needed because the default rules block all inbound traffic)

Why it fails: The default rules in an NSG include AllowVNetInBound (priority 65000), AllowAzureLoadBalancerInBound (65001), and DenyAllInBound (65500). Because DenyAllInBound blocks all traffic from the internet that doesn't match an earlier allow rule, no HTTPS traffic from the specific IP range would ever reach the web server. You must create an explicit inbound allow rule for TCP 443 with a source IP range and a priority lower than 65500 (e.g., 100).

2 (one allow rule for HTTPS and one deny rule for all other traffic)

Why it fails: Adding an explicit deny-all-inbound rule is redundant because the built-in DenyAllInBound rule already matches and blocks every packet that no higher-priority allow rule accepts. If you put that explicit deny at a lower numeric priority (e.g., 200), it is evaluated early and simply repeats the action of the default rule; if you put it above your HTTPS allow, it would incorrectly block the very traffic you want to permit. The only truly necessary addition is the HTTPS allow rule.

3 (one allow HTTPS, one allow for Azure Load Balancer health probes, and one deny all)

Why it fails: The default AllowAzureLoadBalancerInBound rule (priority 65001) already permits Azure Load Balancer health probe traffic to reach VMs in the subnet, so an extra allow rule for health probes is unnecessary. Adding it, plus an explicit deny-all rule, compounds the error: health-probe allow is redundant, and the explicit deny duplicates DenyAllInBound. The effective result would be identical to option 1 (just the HTTPS allow rule), but with three rules instead of one, adding management complexity and clutter.

Fusion rule

Why it fails: Fusion rules are built-in, Microsoft-managed analytics rules that leverage machine learning to correlate alerts from multiple security products into a multi-stage attack story. They do not accept custom KQL queries or allow users to specify cross-table join logic, so they cannot be adapted for a custom detection based on specific correlation requirements.

Anomaly rule

Why it fails: Anomaly rules use built-in machine learning models to detect outliers against a learned baseline for individual data sources, such as user sign-ins or behavior from a specific product. They do not support custom KQL joins across different tables, so they cannot correlate events from multiple sources to uncover a custom multi-event attack pattern.

NRT rule (Near Real-Time)

Why it fails: Near Real-Time (NRT) rules are a specific category of scheduled query rules designed for 1-minute latency, but they restrict query syntax and data set size to maintain speed. While they can join some tables, the limited query complexity and lack of support for certain operators make them less suitable for complex cross-source correlation, making the broader 'Scheduled query rule' category the correct answer.

Network Performance Monitor.

Why it fails: Network Performance Monitor (NPM) is an Azure Monitor-based solution that measures network latency, packet loss, and topology across virtual machines, ExpressRoute, and VPN connections. It relies on agents installed on monitored endpoints to gather performance telemetry and cannot simulate a specific packet against a network security group (NSG). Therefore, while NPM helps identify degraded or failing network paths, it is not designed to validate whether a particular NSG rule permits or denies a given traffic flow, making it incorrect for this troubleshooting scenario.

Next hop.

Why it fails: The Next hop capability in Network Watcher identifies the next hop type and IP address for a packet based on the effective route table associated with a VM—for example, Internet, VirtualNetworkGateway, or a virtual appliance—but it does not inspect NSG rules. A route may correctly point to a valid next hop, yet an NSG rule can still block the traffic before it leaves the VM. Consequently, Next hop is designed for diagnosing routing issues and cannot validate the allow/deny decisions made by network security groups.

NSG diagnostics (flow logs).

Why it fails: NSG diagnostics (flow logs) continuously capture information about IP traffic flowing through an NSG, recording allow/deny outcomes, source/destination addresses, ports, and packet counts into a storage account or Log Analytics workspace for historical analysis. These logs are not interactive: they do not let you simulate an arbitrary test packet on demand and are instead analyzed after the fact using queries or network monitoring tools. Because flow logs require enabling diagnostics and waiting for data to accumulate, they are unsuitable for immediate, packet-specific NSG rule validation, unlike IP flow verify.

Azure Information Protection, Dynamic Data Masking, and column-level security

Why it fails: Azure Information Protection (AIP) is a classification and labeling service, not a native Azure SQL Database encryption feature, so it cannot protect SQL columns or query processing. Dynamic Data Masking (DDM) only obscures values in query results for unauthorized users, while the underlying data remains fully present and unencrypted in storage. Column-level security restricts which principals can SELECT specific columns but does not transform the data at all. This combination lacks true encryption for data at rest, in transit, or in use, leaving the data exposed to privileged database users.

Always Encrypted, Microsoft Entra ID authentication, and Azure Information Protection

Why it fails: Always Encrypted provides strong client-side column encryption, and Microsoft Entra ID authentication improves identity management, but the combination omits Transparent Data Encryption to protect database files and backups at rest. Azure Information Protection is not natively integrated with Azure SQL Database, so it adds no data-plane protection for the database service. Enforced TLS is also missing, leaving the network channel between the client and database potentially susceptible to interception. Therefore, this set fails to deliver comprehensive encryption coverage across all data states and includes a non-integrated control.

Transparent Data Encryption, Dynamic Data Masking, and Microsoft Entra ID authentication

Why it fails: Transparent Data Encryption adequately covers data at rest, and Microsoft Entra ID authentication strengthens access control, but Dynamic Data Masking (DDM) does not encrypt data in use or at rest—it merely redacts results for non-privileged users at query time. This option also omits enforced TLS, so data in transit between the application and database could be exposed to network eavesdropping. Without Always Encrypted, sensitive column values remain visible in plaintext to the SQL database engine and any user with elevated permissions. Thus, it leaves both the in-transit and in-use states without true encryption.

Azure Activity Logs

Why it fails: Azure Activity Log captures subscription-level control plane operations such as resource creation, deletion, and configuration changes, not user authentication events. While it shows the caller's identity, it lacks critical sign-in metadata like client IP, device, and sign-in location. Therefore, it cannot support unfamiliar sign-in detection. This is why the Activity Log is not the correct source for this use case.

Microsoft Entra ID Audit Logs

Why it fails: Microsoft Entra ID Audit Logs focus exclusively on directory management events, such as creating or updating users, assigning roles, and changing tenant settings. They do not capture individual authentication events, nor do they include sign-in IP addresses or geographic location, so they cannot indicate where a sign-in originated. Without that location metadata, Audit Logs are useless for detecting unfamiliar sign-in activity. Thus, this option is incorrect.

Microsoft 365 Defender Alerts

Why it fails: Microsoft 365 Defender Alerts are generated by detection engines and represent specific threats or suspicious activities, such as a possible attempt to access a compromised account. They do not offer a raw, comprehensive log of every sign-in with its location; instead, they abstract away the underlying telemetry. To run a custom query on sign-in location and detect unfamiliar sign-ins, you need the raw sign-in logs, not processed alerts. Therefore, Defender Alerts are not the correct answer here.

AKS managed identity

Why it fails: Using the AKS cluster's managed identity to pull from ACR grants registry access at the cluster level, meaning any workload running on any node in the cluster can potentially use that identity to obtain images. This violates the policy requiring the use of a dedicated service principal secret, because a managed identity is not a static service principal secret and lacks the per-pod scoping needed to limit access to specific workloads. Worse, a cluster-scoped identity amplifies the blast radius if the cluster or a node is compromised, as the credential is not easily revocable per workload.

ACR admin account

Why it fails: The ACR admin account is a static, shared username and password that carries full registry permissions, including push and delete, far beyond the read-only access needed to pull images. Because it is a single credential with no per-registry or per-repository scoping, any secret leak exposes the entire registry, and the lack of built-in rotation and auditing mechanisms makes it unsuitable for production. A service principal with the AcrPull role would provide a narrowly scoped, independently rotatable credential, which is why the admin account fails the least-privilege and secret-management requirements.

Microsoft Entra ID pod identity

Why it fails: Microsoft Entra ID Pod Identity assigns an Microsoft Entra ID managed identity to individual pods, enabling them to request a token and authenticate to ACR via `az acr login` or token-based pulls; however, this is fundamentally an identity-based mechanism, not a static service principal secret stored in a Kubernetes pull secret. Introducing it for image pulls would require deployed components like NMI (Node Managed Identity) and MIC (Managed Identity Controller), adding complexity and operational overhead while still violating the stated requirement to use a service principal secret. Additionally, the policy specifically forbids using any cluster or pod identity for this purpose, so this approach is not merely suboptimal—it is non-compliant by design.

NRT rule

Why it fails: An NRT (Near-Real-Time) rule is not ideal here because its primary purpose is to detect threats with minimal latency, typically within minutes. While it could technically detect the VM creation, the scenario doesn't necessitate such immediate detection, and the overhead for near-real-time processing is unnecessary. It's tempting because NRT rules are commonly used for active threat hunting, but for periodic checks against an approved list, a scheduled rule offers better resource optimisation.

Anomaly rule

Why it fails: Anomaly rules use machine learning to detect unusual patterns, not static list matching. They are not suitable for checking against a fixed approved IP list.

Fusion rule

Why it fails: Fusion rules correlate multiple alerts from different sources to detect multi-stage attacks. They are not used for single-event detection like a new VM creation.

Manually copy screenshots of rules

Why it fails: Screenshots are static images that contain no executable rule logic, query text, or schedule settings, so they cannot be programmatically applied to another workspace. Recreating rules from screenshots is a manual, error-prone process that almost certainly introduces configuration drift between environments. While screenshots may be useful for documentation, they are not a deployment mechanism and fail the consistency requirement.

Store incidents in Azure Key Vault

Why it fails: Azure Key Vault is a secrets management service for keys, certificates, and passwords, not a repository for operational incidents or Sentinel content. Storing incidents there would not push any rule, workbook, or data connector into target workspaces, and it would also interfere with Sentinel's incident lifecycle and investigation workflows. This option confuses secure storage with content deployment, making it incorrect.

The compliance dashboard only displays results if you manually run an assessment.

Why it fails: Defender for Cloud continuously performs automatic assessments of Azure resources against assigned regulatory compliance initiatives; these scans run on a recurring schedule and update the compliance dashboard without any manual intervention. A manual trigger is not required to populate results, and no 'run assessment' button is needed for standard regulatory compliance. Therefore, the 'Not started' status is not due to a lack of a manual assessment run, but rather stems from the policy evaluation not executing for specific resources—such as the regional effect unsupported issue.

The PCI DSS initiative must be assigned to each subscription individually.

Why it fails: Assigning the PCI DSS initiative at the management group scope is a fully supported deployment model; the assignment inherits to every subscription under that group, so individual per-subscription assignment is unnecessary. If per-subscription assignment were truly required, you would see subscriptions listed as 'Not covered' or 'No assessment data' rather than a uniform 'Not started' status across the board. Since the scenario already leverages management group assignment, this is not the cause of the missing assessment results.

The Defender Cloud Security Posture Management (CSPM) plan is not enabled on all subscriptions.

Why it fails: The Defender Cloud Security Posture Management (CSPM) plan, formerly the free tier of Azure Security Center, is automatically enabled on every Azure subscription and provides the foundational policy scanning that regulatory compliance assessments depend on. The question context explicitly states that the CSPM plan is enabled on all subscriptions, meaning the absence of this plan is not the issue. If CSPM were disabled, you would see no compliance dashboard at all, not a 'Not started' status for a specific initiative.