Design security solutions for infrastructure practice questions

Syslog via AMA

Why wrong: Syslog via AMA is not suitable for this use case because Syslog is a standard for logging on Linux systems and network devices, not for Windows operating system security events. While Windows can be configured to forward logs via Syslog through third-party agents, the Azure Monitor Agent (AMA) does not natively collect Windows Security log entries through the Syslog protocol. To detect lateral movement on Windows hybrid identities, you need authentication-related event IDs such as 4624 and 4625, which are found in the Windows Security log, not in Syslog streams.

Office 365 Logs

Why wrong: Office 365 Logs are cloud-only audit logs that capture activities from Microsoft 365 services like Exchange Online, SharePoint, and Teams. They do not include on-premises or virtual machine authentication events, such as user logons to domain controllers or Windows servers. Therefore, they cannot provide the security event data needed to detect lateral movement across on-premises or hybrid-joined Windows machines. This option fundamentally misses the OS-level sign-in telemetry required for the scenario.

Azure Activity Log

Why wrong: Azure Activity Log provides subscription-level resource management events, such as creating or deleting Azure resources and starting or stopping VMs. It does not capture guest OS-level security events, including authentication attempts or processes running inside a virtual machine. Consequently, it cannot reveal lateral movement within your on-premises or hybrid-joined Windows environment. To monitor Windows sign-ins and other OS-level activities, you must rely on Windows Security Events collected by Azure Monitor Agent (AMA).

Enable all Defender plans for subscription

Why wrong: Enabling all Defender plans across the subscription is a post-onboarding configuration that dictates which advanced security features, such as threat detection for servers or databases, are active on resources that have already been discovered. It does not create any connection to AWS or GCP workloads, so if no cloud connector exists, the plans have nothing to operate on. Additionally, 'all plans' may be unnecessary or costly—you selectively enable only the plans that match your workload types after the multi-cloud assets are connected.

Create custom compliance policies

Why wrong: Custom compliance policies, built with Azure Policy or regulatory standards, are used to apply your organization's specific security and compliance requirements to resources once they are present in Defender for Cloud. Before any cloud connector exists, there are no AWS or GCP resources to evaluate, making policy creation premature. The initial action for multi-cloud security is to create the connector; custom policies are an optional refinement that comes after inventory and recommendations are flowing.

Deploy Azure Arc agents on all cloud VMs

Why wrong: Azure Arc agents are designed for extending Azure Control Plane management to on-premises, edge, and other cloud servers, enabling Azure Policy and resource governance on those individual machines. However, for Defender for Cloud multi-cloud visibility, installing Arc agents on every AWS EC2 or GCP compute instance is neither the correct pattern nor a prerequisite—the cloud connector natively pulls security metadata without requiring per-install agents. Also, Arc agents address server-level management, not the environment-level account synchronization that the connector provides.

CodeQL code scanning

Why wrong: CodeQL code scanning is a static analysis tool that models and queries data flow and control flow to identify vulnerabilities like SQL injection, cross-site scripting, and insecure deserialization. It does not search for raw secret strings or credential patterns in the repository; instead, it analyzes source code semantics. Therefore, CodeQL is the wrong tool for detecting a leaked API key or password, which is a content-matching problem rather than a code-quality problem.

Dependabot alerts

Why wrong: Dependabot alerts rely on a database of known Common Vulnerabilities and Exposures (CVEs) and compare the manifest and lock files (e.g., package.json, Pipfile.lock) in a repository against that database. Its sole purpose is to identify vulnerable and outdated dependencies, not to inspect the files or commit history for embedded secrets. A leaked secret will never appear in a dependency graph; thus, Dependabot cannot satisfy the secret-detection requirement.

Defender for Cloud DevOps security posture management

Why wrong: Defender for Cloud's DevOps security posture management (or CSPM features for DevOps) provides continuous assessment of your DevOps environment by evaluating configuration posture, identity/permissions, and compliance of CI/CD pipelines and infrastructure-as-code. It can surface misconfigurations and missing security controls, but it does not natively scan repository contents for secret patterns with the same fidelity as GitHub secret scanning. Hence, while it may recommend enabling secret scanning, it is not a replacement for the detection capability itself.

Advanced threat protection for Azure Cosmos DB

Why wrong: Advanced threat protection for Azure Cosmos DB is a Defender for Cloud plan specifically designed for NoSQL databases, using threat intelligence and anomaly detection to flag malicious access patterns like data exfiltration or SQL injection. It does nothing for AKS clusters, which require Kubernetes-specific protection. Therefore, while useful for Cosmos DB, it does not help secure an AKS workload.

DDoS Protection Standard

Why wrong: DDoS Protection Standard is a separate Azure networking service that mitigates volumetric network-layer attacks against public IP addresses and virtual networks. It is not a feature contained within Microsoft Defender for Cloud, though Defender for Cloud can surface related alerts if the service is misconfigured. Since this question asks specifically about Defender for Cloud features for AKS, DDoS Protection Standard is an incorrect choice.

Assign Azure Policy to enforce resource compliance

Why wrong: Assigning Azure Policy enforces resource compliance but does not directly improve security posture; it establishes guardrails for governance and auditing. While policies can prevent non-compliant deployments, they lack the threat detection, vulnerability management, and prioritized remediation that Defender plans or Secure Score actions provide. Policy enforcement is a reactive control, not a proactive security improvement.

Create custom security policies

Why wrong: Creating custom security policies only extends governance to unique organizational requirements; it does not inherently enhance threat protection or posture. Built-in policies already align with industry best practices and provide a baseline of recommendations, so custom policies add administrative overhead without adding detection or remediation capabilities. They are not a primary action for improving security posture.

Deploy vulnerability assessment solution to all VMs

Why wrong: Deploying a vulnerability assessment solution to all VMs is a specific, limited action that identifies misconfigurations and CVEs but does not address other critical areas like identity, network, or workload protection. It is already a component of Secure Score recommendations and Defender plans, so performing it independently lacks the comprehensive coverage of a full posture improvement initiative. It's a tactical fix, not a strategic improvement.

Requires that all network security rules have destination port range between 22 and 3389

Why wrong: This option misstates the policy's condition: the definition does not require each security rule's destinationPortRange property to be a numeric interval between 22 and 3389. Azure Policy's deny effect triggers only when the rule's destination port value is not exactly '22' or '3389', so a rule using a range like '100-200' would violate the policy just as much as one using port 443. It neither validates that a range falls within 22-3389 nor permits ranges that contain those ports; it demands the destination port be one of the two listed values.

Denies all inbound traffic except SSH and RDP

Why wrong: Azure Policy with the deny effect operates at the Azure Resource Manager control plane, not the data plane, so it cannot 'deny all inbound traffic' in the network path. What actually gets denied is the creation or update of a network security rule resource whose destination port is outside the allowed list; no packet inspection, NSG flow evaluation, or traffic blocking is performed by the policy. Inbound traffic to 22/3389 will only be allowed if an existing NSG rule explicitly permits it—the policy neither enforces such a rule nor blocks traffic on its own.

Allows only SSH and RDP inbound traffic

Why wrong: This option incorrectly frames the policy as a positive allow mechanism. Azure Policy never creates or enables NSG rules; it only evaluates resource definitions against conditions and can deny noncompliant resources. Here, the policy blocks any security rule that would allow ports other than 22 and 3389, but it does not add any allow rules for SSH or RDP, nor does it affect the existing NSG rules' priority or action. Allowing traffic remains the job of NSG rules; the policy merely prevents certain future rules from being written.

Enable the service endpoint for Microsoft.Storage on the VNet subnet

Why wrong: Enabling the service endpoint for Microsoft.Storage on the subnet prepares the network path by making traffic to Azure Storage originate from the subnet's private IP addresses and traverse the Azure backbone. However, this action alone does not grant access; the storage account's firewall still evaluates every request and, without a matching virtual network rule, will reject traffic from that subnet. You must pair the service endpoint with an explicit VNet rule to actually authorize the traffic.

Enable firewall and add an IP rule for the VNet's public IP

Why wrong: Adding an IP rule for the VNet's public IP is ineffective because traffic originating from resources inside a VNet, such as VMs, uses private IP addresses from the subnet's address space, not the VNet's public IP (if one even exists). Azure Storage firewall IP rules match the public source IP of connections, and since VNet-to-storage traffic appears with a private source IP, the rule will never match. Thus, this approach would not allow any traffic from the VNet.

Enable public network access and add a firewall rule

Why wrong: Enabling public network access and adding a firewall rule would defeat the current security configuration because the storage account already has public network access disabled, meaning all external traffic is blocked. Re-enabling it exposes the storage account to the internet and expands the attack surface unnecessarily, while still not addressing the specific requirement to allow only a designated VNet. The correct path is to keep public network access disabled and use a VNet rule instead.

The rule only allows traffic on port 443 from a specific IP range

Why wrong: This is incorrect because the NSG rule's sourceAddressPrefix is set to 'Internet', which is a service tag that represents all public IP addresses, not a specific IP range. The rule does not restrict the source to any particular CIDR block or individual IP; it permits any host on the Internet to initiate connection to TCP port 443. The port 443 is the destination port, not the source address, so the claim about a specific IP range is false.

The rule allows outbound traffic from the subnet to the Internet

Why wrong: This is incorrect because the rule's direction is explicitly 'Inbound', meaning it governs traffic arriving at the subnet from the Internet, not traffic leaving the subnet. An outbound rule would require the direction to be 'Outbound' and would apply to the source being the subnet and the destination being external. This rule has no effect on outbound connectivity; it only evaluates incoming packets whose source is the Internet and destination is the subnet.

The rule blocks all inbound traffic from the Internet

Why wrong: This is incorrect because the rule's access is set to 'Allow', not 'Deny', so it explicitly permits inbound traffic on port 443 from the Internet rather than blocking it. The rule does not block all inbound traffic; it actually allows a specific subset (HTTPS) and leaves other inbound traffic to be handled by default rules. If the intention were to block all inbound Internet traffic, you would need a 'Deny' rule with a broader scope, such as any source on all ports.

Windows Defender Firewall

Why wrong: Windows Defender Firewall is a host-based network filter that inspects inbound and outbound traffic and applies rule-based allow or block decisions at the network layer. It does not intercept process creation or evaluate executable files before they run, so it cannot prevent an unauthorized application from launching. Firewall rules govern connectivity, not application execution, making it unsuitable for application control.

BitLocker

Why wrong: BitLocker Drive Encryption protects data at rest by encrypting the entire volume with AES, preventing offline access to files if the disk is removed or the device is lost. It has no interaction with the OS execution pipeline and does not examine or restrict which programs can be started. BitLocker addresses confidentiality, whereas application control addresses operational security.

Windows Information Protection

Why wrong: Windows Information Protection (WIP) is an enterprise data protection feature that labels corporate data and applies policies to prevent copy-paste, drag-drop, or unauthorized sharing into personal apps. WIP does not block an application from executing; it only governs how protected corporate data is accessed and moved. Its purpose is data leakage prevention, not executable-wise enforcement of allowed software.

Microsoft Purview

Why wrong: Microsoft Purview is a unified data governance and compliance solution that focuses on discovering, classifying, and governing sensitive data across on-premises, multi-cloud, and SaaS environments. It does not provide any host-based security controls for Azure VMs, such as antimalware, vulnerability scanning, or just-in-time access protection. While Purview can help identify where sensitive data resides, it cannot remediate or defend against malware infections on virtual machines.

Microsoft Sentinel

Why wrong: Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automated Response) solution that aggregates logs and alerts from various sources, including Defender for Cloud, for security analytics and incident response. It does not actively protect VMs from malware or perform vulnerability assessment; instead, it relies on other security tools to generate the telemetry it analyzes. Using Sentinel alone would leave the VM unprotected, as it lacks native antimalware or host-based security controls.

Microsoft Intune

Why wrong: Microsoft Intune is a cloud-based unified endpoint management (UEM) and mobile device management (MDM) service that manages user-facing devices like Windows PCs, Macs, iOS, and Android devices, focusing on compliance and application deployment. It is not designed to secure infrastructure-as-a-service (IaaS) workloads such as Azure VMs, nor does it provide antimalware, vulnerability scanning, or security hardening for virtual machines. Intune's scope is device and application management, not workload protection within Azure.

Azure Front Door

Why wrong: Azure Front Door operates at Layer 7 (HTTP/S) and is designed for global load balancing, SSL termination, and application acceleration. It does not create an encrypted tunnel between on-premises networks and Azure, nor does it provide routing of IP packets at the network layer. Therefore, it cannot serve as a site-to-site or point-to-site VPN solution for hybrid connectivity.

Azure ExpressRoute

Why wrong: Azure ExpressRoute provides a private, dedicated connection to Azure that bypasses the public internet, but it does not natively encrypt the data in transit. To achieve confidentiality, you must layer an encryption protocol (such as IPsec) over the ExpressRoute circuit, which adds complexity and does not meet the requirement for inherently encrypted hybrid connectivity. Without that extra layer, ExpressRoute alone is susceptible to inspection by the carrier and does not provide end-to-end encryption.

Azure Bastion

Why wrong: Azure Bastion provides managed, secure RDP and SSH access to virtual machines directly through the Azure portal, using TLS for the session. It is designed for remote administration of individual VMs, not for connecting two networks together. Bastion does not establish a site-to-site VPN tunnel or route traffic between on-premises infrastructure and Azure VNet, so it is irrelevant to hybrid network connectivity.

Firewall rules and Azure Active Directory authentication

Why wrong: These control access, not encryption.

Always Encrypted and firewall rules

Why wrong: Always Encrypted is for column-level encryption, not at rest for entire database.

Azure Defender for SQL and vulnerability assessment

Why wrong: These are security monitoring features, not encryption.

Analytics rules with incident creation

Why wrong: Analytics rules in Microsoft Sentinel contain scheduled or near-real-time detection queries that create alerts and incidents when suspicious activity is detected. They are designed purely for detection and alerting; in their default configuration they do not perform any response or remediation steps. To attach an automated response, an automation rule must be created to invoke a playbook upon the analytics rule’s incident creation.

Hunting queries

Why wrong: Hunting queries are KQL-based searches that security analysts run interactively in the Microsoft Sentinel hunting area to proactively look for threats or intrusion artifacts. These queries are a manual, exploratory activity; they do not automatically generate incidents or trigger any response. While analysts can create bookmarks and livestream from hunting queries, the queries themselves have no capability to invoke playbooks or execute remediation actions.

Workbooks

Why wrong: Workbooks in Microsoft Sentinel are interactive dashboards built on Azure Workbooks that provide visualizations, metrics, and trend analysis from log data for security operations reporting. They are read-only reporting tools and do not contain logic to detect threats or launch any automated response. Their purpose is to present information to analysts and stakeholders, not to directly affect the lifecycle of an incident.

Sysmon Event ID 1 (Process creation)

Why wrong: Sysmon Event ID 1 monitors process creation, which may reveal a malicious binary executing but provides no visibility into how authentication was performed. Pass-the-hash attacks abuse NTLM credentials during a network logon, so the key evidence is the authentication event itself, not the resulting process. While process creation can be a useful supplementary signal for post-compromise activity, it cannot directly confirm that a credential hash was replayed.

DNS Query Logs

Why wrong: DNS query logs map hostnames to IP addresses and reveal network resolution activity, but they contain no authentication context such as logon type, security identifiers, or credential hashes. Pass-the-hash is an authentication protocol attack that occurs at the Windows security subsystem, not at the DNS layer. At best, DNS logs might indicate suspicious lateral movement patterns, yet they cannot distinguish a Pass-the-Hash logon from any other benign network connection.

Azure Activity Logs

Why wrong: Azure Activity Logs capture subscription-level operations in the Azure Resource Manager control plane, such as creating a virtual machine or modifying policies. They do not record interactive or network logons to Windows systems, nor do they include NTLM or Kerberos authentication attributes essential for Pass-the-Hash detection. For hybrid environments, these logs are useful for auditing resource changes, but they are blind to the credential replay itself.

Azure Firewall

Why wrong: Azure Firewall is a stateful, cloud-native network security service that inspects and filters traffic at layers 3-7 using application and network rule collections. While you can use Azure Policy to govern how Azure Firewall is deployed or to enforce firewall configuration, Azure Firewall itself is not a policy management tool. The term 'policy' in Azure Firewall refers to firewall policy objects that define NAT, network, and application rules—these are distinctly different from Azure Policy's compliance and audit rules, so it cannot centrally manage security policies across subscriptions.

Microsoft Defender for Cloud

Why wrong: Microsoft Defender for Cloud is a cloud security posture management (CSPM) and workload protection platform that aggregates security findings and gives prioritized recommendations, such as enabling encryption or fixing vulnerable configurations. Under the hood, Defender for Cloud assigns and consumes Azure Policy definitions—for example, the built-in security policies it creates are actually Azure Policy assignments—but it is not the central policy management service. It uses policy results to drive its regulatory compliance dashboard and recommendations, and it does not replace Azure Policy as the engine for policy enforcement or the single source of truth for policy definitions.

Azure Blueprints

Why wrong: Azure Blueprints is an orchestration service for composing deployable environments, allowing you to package ARM templates, role assignments, policy assignments, and resource groups into a single blueprint artifact. However, it relies on Azure Policy for any compliance enforcement it includes; it does not provide the evaluation engine, effects, or compliance reporting that define a central policy management service. Its purpose is repeatable environment deployment, not ongoing policy governance across subscriptions.

Entra ID Governance (Access Reviews)

Why wrong: Entra ID Governance (Access Reviews) is an attestation capability that periodically asks owners to review and confirm group memberships, application assignments, and role eligibility. These reviews run on a scheduled cadence (e.g., monthly or quarterly) and are not real-time; they are designed to remove stale access over time, not to react to a suspicious sign-in event. Therefore, it cannot automatically remediate a risky sign-in as it lacks event-driven risk evaluation.

Privileged Identity Management (PIM)

Why wrong: Privileged Identity Management (PIM) provides just-in-time, time-bound, and approval-based activation of privileged roles in Azure AD, such as Global Administrator. While it limits standing privilege and requires approval for role activation, it does not examine user sign-in risk signals or evaluate the security of a user's session. PIM governs who can become an admin and when, not whether a current sign-in is risky or should be blocked.

Microsoft Defender for Identity

Why wrong: Microsoft Defender for Identity monitors on-premises Active Directory traffic, including domain controller and authentication events, to detect advanced attacks such as lateral movement, kerberoasting, and pass-the-hash. While it can provide alerts about suspicious on-prem behavior, those alerts require manual investigation by a security analyst and do not automatically enforce Conditional Access policies or block cloud SaaS sign-ins. It also does not natively calculate Azure AD sign-in risk from cloud-based signals like leaked credentials or unfamiliar locations.

Azure Logic Apps with Defender XDR connector

Why wrong: Azure Logic Apps with the Defender XDR connector can orchestrate automated playbooks, such as sending notifications or updating tickets, but they are not designed to serve as the primary incident ingestion pipeline. Logic Apps are triggered by events and can perform actions, yet creating incidents from every alert via Logic Apps would require building a custom workflow that calls the Sentinel API, replicating the connector's functionality without its reliability or scalability. The data connector is the designated mechanism for automatically creating incidents, while Logic Apps are best reserved for post-incident automation.

Microsoft Power Automate flow triggered by Defender XDR alerts

Why wrong: Power Automate flows are a valid way to automate responses, but they are not the out-of-the-box method for creating Sentinel incidents from Defender XDR alerts. A flow would need to be manually configured to trigger on each alert, parse the alert payload, and then call the Sentinel API to create an incident, introducing latency, potential throttling, and a single point of failure. This workaround bypasses the native incident correlation and deduplication that the Defender XDR data connector provides, making it unsuitable as the standard integration.

Microsoft Graph API subscription to Defender XDR alerts

Why wrong: Microsoft Graph API subscriptions for Defender XDR alerts require custom development to manage webhooks, validate tokens, and handle event delivery. While possible, this approach lacks the built-in incident creation logic, schema normalization, and automated correlation that the Sentinel data connector offers. You would need to write your own code to ingest alerts, deduplicate them, and create incidents, which increases complexity and maintenance overhead. It is not a practical or supported method for routine incident creation in Sentinel.

Azure DDoS Protection

Why wrong: Azure DDoS Protection is a network-layer mitigation service that defends against volumetric attacks (SYN floods, UDP floods, etc.) targeting public endpoints. It operates at the Azure perimeter and does not filter or control traffic flows between subnets inside a virtual network; it also doesn't provide stateful allow/deny rules based on ports or IPs for internal segmentation. Therefore, it cannot replace NSGs for isolating workloads.

Azure Firewall

Why wrong: Azure Firewall is a managed, cloud-native firewall that can filter both inbound/outbound and east-west traffic, but it requires deliberate deployment (usually in a hub VNet) and custom user-defined routes to redirect inter-subnet traffic to it. It also carries cost and operational overhead that isn't justified for straightforward subnet-to-subnet segmentation. Within a single VNet, NSGs are the default, lower-overhead mechanism that applies directly at the subnet or network interface without routing changes.

Azure Bastion

Why wrong: Azure Bastion is a fully managed PaaS service that provides secure, browser-based RDP and SSH connectivity to VMs through the Azure portal over TLS. It only facilitates a secure management path; it does not evaluate, inspect, or filter traffic between application subnets, nor does it enforce deny rules between workloads. As such, it has no role in network segmentation and is not a security control for east-west traffic.

Microsoft Defender for Cloud regulatory compliance dashboard

Why wrong: Microsoft Defender for Cloud's regulatory compliance dashboard is a reporting and visibility tool that aggregates compliance posture against standards like CIS and NIST. It continuously assesses your environment and surfaces recommendations, but it does not automatically apply or remediate security baselines on VMs. Enforcement requires separate mechanisms such as Azure Policy, making it insufficient for the stated requirement of automatically applying baselines.

Azure Update Management

Why wrong: Azure Update Management is designed specifically for managing operating system updates and patches, including patch compliance and scheduled deployments. It does not interpret or enforce security baseline configurations such as CIS benchmarks or Microsoft security guides, which are policy-based settings rather than software updates. Thus, it cannot automatically apply baselines to VMs, making it the wrong choice for this scenario.

Azure Automation State Configuration (DSC)

Why wrong: Azure Automation State Configuration (DSC) can apply PowerShell Desired State Configuration to VMs, but it requires custom DSC configurations and pull server or compilation infrastructure to enforce baselines. It lacks the native integration, built-in baseline definitions, and automatic compliance reporting that Azure Policy's Guest Configuration provides, and is considered a legacy approach. For modern, cloud-native baseline enforcement, Azure Policy is the recommended service.

Compliance policy

Why wrong: Compliance policies evaluate device health against conditions such as minimum OS version, required encryption, and a cleared threat score. A device that fails is marked non-compliant and can be blocked from company resources via Conditional Access, or it can be forcefully removed from management. These policies are purely state-based assessments; they have no enforcement mechanism to prevent a user from launching an installer or to filter untrusted sources during installation. Therefore, a compliance policy cannot satisfy the requirement to block app installation from untrusted sources.

App protection policy (MAM)

Why wrong: App Protection Policies (MAM) govern how data behaves inside specific managed apps—for example, disabling copy/paste, blocking screen capture, requiring a PIN, or preventing 'Save As' to personal space. They apply at the app layer and work even on unenrolled or BYOD devices. MAM has no concept of installation-time validation; it only wraps runtime behavior once a protected app is in use. Because it never evaluates a package's source during setup, it cannot block a user from installing an app from an untrusted location.

Configuration policy (OMA-URI)

Why wrong: OMA-URI configuration policies are a custom mechanism that lets you push any Windows Management Infrastructure (SyncML) setting to a device as raw XML. To block untrusted installs, you would have to manually craft a URI such as `./Vendor/MSFT/Policy/Config/AppRuntime/AllowAllTrustedApps` and set it to zero, then maintain it outside the standard UI. That approach is less discoverable, lacks built-in validation, and is easy to misconfigure—it is not the intended 'configuration policy' for app installation control. Intune's dedicated device restriction profile is the correct, supported interface for this enforcement.