CCNA Design security solutions for infrastructure Questions

Azure ExpressRoute with redundant circuits is correct because ExpressRoute provides a private, dedicated connection through a connectivity provider that does not traverse the public internet, and deploying two or more circuits in different peering locations enables automatic failover if the primary circuit fails. Azure Virtual WAN is a networking hub service that can aggregate connectivity but does not by itself guarantee private backbone-only transport or automatic failover. Azure Front Door is a global HTTP/HTTPS load balancer and CDN for web applications, not a hybrid connectivity service.

Azure VPN Gateway sends traffic over the public internet via IPsec tunnels, so it fails the requirement that traffic never use the public internet.

The correct option is C: enabling the Microsoft Defender for Identity data connector in Microsoft Sentinel. MDI integrates with Sentinel through a built-in data connector that streams MDI alerts and related identity events into the Sentinel workspace, allowing centralized detection and response without extra infrastructure. Option A is unnecessary because the MDI sensor is deployed on domain controllers or AD FS servers, not Azure VMs, and the sensor does not send data directly to Sentinel.

Option B is incorrect because Entra ID Protection covers cloud identity risk, not on-premises AD signals from MDI. Option D is incorrect because MDI does not natively forward to Syslog for Sentinel ingestion; the supported path is the MDI data connector.

User Defined Routes (UDRs) are the correct choice because they let you override Azure's default system routes and force traffic to be sent to a specific next hop, such as the private IP of a network virtual appliance, so packets are inspected before reaching the VMs. In this scenario, the security team requires traffic to pass through the NVA, which is exactly what a UDR with the NVA as the next hop accomplishes. Azure Firewall (A) is itself a managed firewall service, not the routing mechanism used to redirect traffic to a third-party NVA.

Azure Load Balancer (B) distributes traffic across endpoints but does not control routing paths, and Network Security Groups (C) only filter traffic with allow/deny rules rather than steering it through an appliance.

The correct answer is D: the policy denies creation of Windows VMs without automatic updates enabled. In Azure Policy, a Deny effect blocks the deployment request when the resource does not satisfy the condition, so a Windows VM whose automatic updates setting is not enabled would fail the policy evaluation and be rejected. This matches the scenario of enforcing automatic updates on Windows VMs at creation time.

Option A is incorrect because it reverses the condition, denying VMs that already have automatic updates enabled. Option B is incorrect because it describes an Audit effect, not Deny, and audits VMs with updates disabled rather than blocking noncompliant deployments. Option C is incorrect because it targets Linux VMs and uses Audit, neither of which matches the policy's Windows VM Deny behavior.

The correct option is C: the policy denies virtual machines with managed disks when the OS disk type is not Standard_LRS or Premium_LRS. This matches a typical Azure Policy definition that evaluates the managed disk's storage account type (for example, the field Microsoft.Compute/disks sku.name) and uses a deny effect to block any value outside the allowed set of Standard_LRS and Premium_LRS. Option A is wrong because encryption at host is controlled by a different setting (encryptionAtHost) and is not what this disk-type policy enforces.

Option B is wrong because the policy targets managed disks, not unmanaged disks, and it does not allow unmanaged disks. Option D is wrong because the policy does not deny all VMs without managed disks; it only denies managed-disk VMs whose OS disk SKU is not Standard_LRS or Premium_LRS.

Option C is correct because Azure Backup with an immutable vault prevents backup data from being altered or deleted during the retention period, which is essential for recovering VMs after a ransomware attack encrypts or destroys production data. Option E is correct because Microsoft Defender for Servers provides threat detection, vulnerability assessment, and file integrity monitoring, and it can raise alerts on suspicious ransomware-like behavior on the VM. Option A is not correct because blocking all inbound traffic with Azure Firewall would not stop ransomware delivered through outbound connections, compromised credentials, or already-running workloads, and it is not a ransomware-specific protection.

Option B is not correct because Azure Site Recovery provides replication and disaster recovery failover, but it does not by itself protect backups from tampering or detect ransomware. Option D is not correct because encryption at rest protects data confidentiality if disks are stolen, but it does not prevent ransomware from encrypting files on a running VM.

The correct answer is B: Transparent Data Encryption (TDE) and enforce TLS connections. TDE provides encryption of data at rest by encrypting the database, backups, and transaction logs at the page level, while enforcing TLS (Transport Layer Security) ensures data in transit is encrypted between the client and Azure SQL Database. Firewall rules, Azure AD authentication, Always Encrypted, Azure Defender, and vulnerability assessment address access control, client-side encryption, or threat detection, but they do not by themselves guarantee encryption of data at rest and in transit.

Therefore, options A, C, and D do not satisfy the stated requirement.

Microsoft Defender for Cloud (option D) is the correct choice because it provides cloud workload protection, including Microsoft Defender for Servers, which delivers antimalware/endpoint protection and security recommendations for Azure VMs. It continuously assesses VM configurations and surfaces hardening recommendations, satisfying both the malware protection and security-recommendation requirements. Azure Sentinel (A) is a SIEM/SOAR platform for collecting and analyzing security events, not for directly protecting VMs from malware.

Microsoft Intune (B) is for mobile device and endpoint management, primarily for user devices, not Azure VM workload protection. Azure Monitor (C) collects metrics and logs for observability but does not provide malware protection or security recommendations.

The correct option is D: configuring a session policy in Microsoft Defender for Cloud Apps to block clipboard and screenshot actions. Defender for Cloud Apps Conditional Access App Control uses a session policy to proxy the session and apply controls such as blocking copy/paste to the clipboard and preventing screenshots, which directly addresses the requirement while still permitting legitimate query operations. Option A is incorrect because Azure Information Protection labels classify and protect data at rest or in documents, not interactive query result sessions.

Option B is incorrect because Dynamic Data Masking only obscures column values in query output and does not prevent copying or screenshotting. Option C is incorrect because Auditing and threat detection only log and alert on suspicious activity; they do not block clipboard or screenshot actions.

Azure Backup with a backup policy that specifies daily, weekly, and monthly retention (option D) is correct because Azure Backup for virtual machines natively supports long-term retention through policy rules that define daily, weekly, monthly, and yearly retention durations, exactly matching the required 30-day daily, 12-week weekly, and 3-year monthly schedule. Azure Backup also provides application-consistent snapshots and recovery points for mission-critical VMs without custom scripting. Option A is wrong because Azure Files backup targets file shares, not VM disks, and requires custom scripting that Azure Backup handles natively.

Option B is wrong because Azure Disk Backup only supports snapshot-based retention up to a limited period and does not provide the multi-tier daily/weekly/monthly retention policy required. Option C is wrong because Azure Site Recovery is a disaster-recovery replication service, not a backup solution with retention policies.

Sensitivity labels and policies (C) are correct because they apply persistent protection to content by classifying data and enforcing encryption, content marking, and usage restrictions that travel with the file or email across Microsoft 365 workloads. Data Loss Prevention (DLP) policies (E) are correct because they detect sensitive information types and take protective actions such as blocking, warning, or encrypting data when it is shared inappropriately in Exchange Online, SharePoint, OneDrive, and Teams. Audit (A) is not a protection solution; it records and searches user and admin activity for investigation and compliance reporting.

Insider Risk Management (B) focuses on detecting and remediating risky user behavior rather than directly protecting sensitive data. eDiscovery (D) is used to identify, preserve, collect, and review content for legal or investigative purposes, not to enforce data protection.

Microsoft Entra ID Protection is the correct choice (Option C) because it uses machine learning to detect risky sign-ins and user risk events, and it lets you enable risk-based Conditional Access policies that automatically remediate those risks (for example, requiring MFA or blocking access). It is purpose-built for identity risk detection and automated remediation, matching the scenario's requirement exactly. Option A, Entra Connect, only synchronizes on-premises identities to Entra ID and does not perform risk detection.

Option B, Conditional Access with session controls, enforces access and session restrictions but does not itself provide the machine-learning risk detection engine. Option D, PIM, manages just-in-time privileged role activation and approvals, not risky sign-in detection or remediation.

A compliance policy (option D) is the correct choice because Intune compliance policies are specifically designed to evaluate device health and posture, including defining a minimum OS version for iOS/iPadOS and detecting jailbroken devices via the device compliance check. When a device fails these conditions, it is marked noncompliant, which can then drive Conditional Access or other remediation actions. Device configuration policies (A) and device restrictions profiles (B) push settings to devices but do not evaluate jailbreak status or enforce a minimum OS version as a compliance condition.

Enrollment restrictions (C) only control which devices or platforms are allowed to enroll, not the ongoing OS version or jailbreak state of already-enrolled devices.

Option A is correct because onboarding on-premises and Azure servers to Azure Arc makes them manageable as connected machine resources in Azure, allowing Defender for Cloud policies and plans (such as Defender for Servers) to be applied consistently across the hybrid estate. Azure Arc is the supported mechanism for extending Azure management and Defender for Cloud coverage to non-Azure servers. Option B is wrong because Azure Automation State Configuration (DSC) enforces configuration state, not Defender for Cloud security policies.

Option C is wrong because Microsoft Sentinel is a SIEM/SOAR solution for analytics and detection, not policy assignment. Option D is wrong because Azure Policy guest configuration audits/configures in-guest settings but does not itself onboard servers to Defender for Cloud or apply its security plans.

Option C is correct because Microsoft Sentinel automation rules can automatically trigger a Logic Apps playbook in response to an incident, and that playbook can orchestrate the full response chain: isolating the compromised VM (e.g., via network security group changes or Microsoft Defender for Endpoint isolation), initiating a backup/snapshot of affected files, and resetting the user's password through Microsoft Graph or Azure AD—all with minimal manual intervention. Option A is incomplete because it only creates a snapshot and emails the team, providing no isolation or password reset. Option B only isolates the VM and does not address backup or password reset, and an alert rule alone is not the full SOAR orchestration.

Option D is manual and therefore does not minimize intervention.

Microsoft Entra application proxy (option A) is correct because it is the service designed to publish on-premises web applications for secure remote access through Microsoft Entra ID, and it natively supports Entra ID authentication, multifactor authentication (MFA), and conditional access policies. It works via a lightweight connector on the on-premises network, so users authenticate to Entra ID before reaching the internal web app, satisfying the MFA and conditional access requirements. Windows Server DirectAccess (B) provides seamless intranet connectivity for domain-joined Windows clients but does not integrate with Entra ID conditional access for publishing web apps.

A VPN gateway with RADIUS authentication (C) provides network-level access and can use MFA via RADIUS, but it does not natively enforce Entra ID conditional access for individual web applications. Microsoft Entra ID (D) is the identity provider itself, not the remote-access publishing service, so it alone cannot expose on-premises web applications.

Azure Policy with the Guest Configuration extension is the correct choice because it is designed to audit and remediate OS-level settings inside Azure VMs, including registry keys, password policies, and service configurations, using built-in or custom guest configuration packages. It continuously evaluates compliance and supports remediation tasks (DeployIfNotExists) to automatically bring non-compliant VMs back into the baseline. Azure Automation State Configuration (option A) can apply DSC, but it is a legacy approach and does not provide the same policy-driven continuous compliance and automatic remediation integration as Azure Policy Guest Configuration.

Azure Update Manager (option C) only handles OS and software patching, not security baseline settings, and Microsoft Defender for Cloud (option D) provides recommendations and alerts but does not automatically remediate these specific configuration items by itself.

The correct option is A: integrating Microsoft Defender for Containers with the CI/CD pipeline to scan images in Azure Container Registry. Defender for Containers provides image vulnerability scanning for ACR, and integrating it into the GitHub Actions pipeline lets you detect vulnerabilities before deployment to AKS, matching the requirement to scan images pre-deployment. Option B, GitHub Advanced Security, focuses on code and secret scanning rather than container image vulnerability assessment.

Option C, Azure Policy, can audit or deny deployments based on vulnerability findings but does not itself perform image scanning in the pipeline. Option D, ACR Tasks, builds images but does not provide vulnerability scanning.

Option B is correct because enabling Microsoft Defender (Azure Defender) plans for all supported resource types activates the advanced threat protection and workload protection capabilities in Microsoft Defender for Cloud, such as Defender for Servers, Defender for Storage, and Defender for SQL, which provide detection and alerting beyond the free Secure Score recommendations. Option C is correct because acting on the top security recommendations surfaced by Secure Score directly remediates the highest-impact misconfigurations and control gaps, which is the intended workflow for measurably improving the subscription's security posture. Option A is not the best choice because Azure Policy enforces compliance with organizational standards but does not itself provide the threat protection and prioritized remediation that Defender for Cloud is designed to deliver.

Option D is not correct because custom security policies are a governance customization rather than a Defender for Cloud posture-improvement action. Option E is not correct because deploying a vulnerability assessment solution is only one specific recommendation within Defender for Servers and is narrower than enabling the full Defender plans and acting on top recommendations.

The correct option is B, Deny, because a Deny policy effect actively blocks any deployment request that does not include the required tags, which is exactly what is needed to prevent untagged resources from being created. Deny evaluates the resource payload during deployment and returns a non-compliant error, so the resource is never provisioned. In contrast, Audit (D) only logs a non-compliance warning without stopping deployment, and DeployIfNotExists (C) remediates by deploying a related resource or applying tags after the fact rather than preventing the untagged deployment.

Disabled (A) turns the policy assignment off entirely, so it has no effect at all.

The correct actions are A and C. Installing the Azure Connected Machine agent (Azure Arc) on on-premises servers is required to project non-Azure machines into Azure so Defender for Cloud can see and manage them, and enabling the Defender for Cloud plans (e.g., Defender for Servers) on the Azure subscription activates the actual protection plans that cover those servers. Option B is insufficient because foundational CSPM only provides posture assessment and does not enable workload protection plans such as Defender for Servers.

Option D is not sufficient by itself because the Azure Monitor Agent collects monitoring data but does not onboard on-premises servers into Defender for Cloud without Azure Arc and the relevant Defender plan.

The template meets the requirement because the storage account resource explicitly sets the minimumTlsVersion property to TLS1_2, which enforces TLS 1.2 as the minimum accepted version for all connections. This is the exact ARM property Microsoft.Storage/storageAccounts exposes for controlling the minimum TLS version, and TLS1_2 satisfies the compliance team's 'TLS 1.2 or higher' rule. Option A is wrong because the SKU Standard_GRS controls replication and redundancy, not the TLS version.

Option C is wrong because supportsHttpsTrafficOnly is a separate setting that only redirects/rejects HTTP traffic; it does not by itself set the minimum TLS version, and the template already sets minimumTlsVersion. Option D is wrong because the apiVersion does support the minimumTlsVersion property, so the setting is valid.

Azure VPN Gateway (option C) is correct because it establishes encrypted IPsec/IKE site-to-site tunnels between on-premises networks and Azure, and it supports high availability through active-active configurations, multiple gateway instances, and zone-redundant SKUs. This directly satisfies the stated requirements of encrypted traffic and high availability for hybrid connectivity. Azure ExpressRoute (option B) provides private, dedicated connectivity but does not natively encrypt traffic over the circuit, so it does not meet the encryption requirement by itself.

Azure Front Door (option A) is a global HTTP/HTTPS application delivery and load-balancing service, not a hybrid network tunnel, and Azure Bastion (option D) provides secure RDP/SSH access to VMs over the Azure portal without exposing public IPs, not site-to-site hybrid connectivity.

The correct option is D: Identity Protection with Conditional Access policies, because Entra ID Identity Protection detects risky sign-ins and risk detections, and Conditional Access can automatically enforce remediation actions such as requiring MFA, blocking access, or forcing password reset without user intervention. This directly addresses the requirement for automatic remediation of risky sign-ins in a hybrid identity environment. Option A, Entra ID Governance Access Reviews, is for periodic attestation of access rights, not sign-in risk remediation.

Option B, Privileged Identity Management, manages just-in-time privileged role activation and approvals, not risky sign-in response. Option C, Microsoft Defender for Identity, detects identity threats on-premises but does not itself automatically remediate Entra ID sign-in risk through Conditional Access.

Microsoft Entra Application Proxy with pre-authentication (option D) is correct because it publishes the on-premises legacy application externally while enforcing Microsoft Entra ID authentication and MFA at the proxy before traffic reaches the app, enabling SSO without changing application code. Pre-authentication means users authenticate against Microsoft Entra ID first, so legacy protocols inside the app are shielded and MFA/Conditional Access can be applied. MSAL (A) requires modifying the application to use modern auth libraries, which the vendor has not provided.

Federating on-premises AD with Entra ID (B) only enables identity synchronization/federation and does not by itself provide SSO or MFA for a legacy on-premises app. Conditional Access policies (C) require the app to already authenticate with Entra ID and cannot protect an app that still uses legacy authentication directly.

Option B is correct because Conditional Access policies apply to either all cloud apps or specific apps, and Microsoft 365 cannot be excluded from one policy while having different conditions applied within the same policy. The scenario requires two separate policies: one targeting all cloud apps with Microsoft 365 excluded that blocks untrusted locations, and a second targeting Microsoft 365 that requires a compliant device. Option A is wrong because Defender for Cloud Apps session policies monitor or control sessions but do not block sign-ins from untrusted locations.

Option C is wrong because a single policy cannot apply a compliant-device requirement only to Microsoft 365 while including all other cloud apps with different conditions. Option D is wrong because it blocks Microsoft 365 from untrusted locations unconditionally, ignoring the compliant-device exception.

Microsoft Entra application proxy (C) is correct because it publishes on-premises web applications to the internet and enforces Microsoft Entra ID pre-authentication, which enables modern authentication, SSO, and Conditional Access for those apps without opening inbound firewall ports. Microsoft Entra ID as the identity provider (D) is correct because it is the cloud identity service that issues tokens, performs authentication, and evaluates Conditional Access policies for the published applications. Together, application proxy and Entra ID as the IdP provide the required modern authentication, SSO, and Conditional Access for on-premises apps.

Azure AD B2C (A) is for customer-facing identity scenarios with local or social accounts, not for securing internal on-premises enterprise applications. Microsoft Entra Domain Services (B) provides managed domain services such as domain join and Group Policy, but it does not by itself publish on-premises apps or deliver the required modern auth/SSO/Conditional Access. Site-to-Site VPN (E) only provides network connectivity and does not deliver identity-based authentication, SSO, or Conditional Access.

Azure Firewall Premium is the correct choice because it is the only Azure Firewall SKU that provides next-generation firewall capabilities such as TLS inspection, IDPS, and URL filtering, and it can be deployed directly as the secured hub in Azure Virtual WAN to protect all on-premises-to-Azure and inter-hub traffic. Azure Firewall Standard lacks TLS inspection and IDPS, so it cannot meet the stated requirement. A third-party NVA in a spoke virtual network would require custom routing and does not natively integrate as the Virtual WAN secured hub, adding complexity and not using Microsoft's security services as requested.

Application Gateway with WAF is a Layer 7 web traffic load balancer for HTTP/HTTPS applications, not a network firewall for securing all hybrid traffic.

Azure Policy with Guest Configuration is the correct choice because it uses the Guest Configuration extension (via the Azure Connected Machine/VM agent) to audit and enforce OS-level settings inside Azure VMs, including applying security baselines such as the Windows or Linux security baseline definitions. It continuously evaluates machines against the policy and can deploy configuration assignments to new VMs automatically, which directly matches the requirement to apply a baseline to new Azure VMs. The regulatory compliance dashboard (A) only reports compliance status against standards and does not apply baselines.

Azure Update Management (B) handles OS patch orchestration, not security baseline configuration. Azure Automation State Configuration (C) can apply DSC configurations but is a separate, more manual pull/push mechanism and is not the Defender for Cloud-integrated baseline enforcement feature.

The correct answer is B: enabling automated investigation and remediation in Microsoft Defender for Endpoint with action settings for isolate, run AV, and reset. This directly satisfies the scenario because Defender for Endpoint's AIR capabilities can automatically isolate a compromised Windows 10 device, trigger a full antivirus scan, and reset the device when remediation cannot clean the infection. Option A is manual and does not provide automatic remediation, while option C introduces a third-party tool that is unnecessary and not specified as available.

Option D only marks devices non-compliant and requires user action, so it does not isolate, scan, or reset the device automatically.

Microsoft Entra Application Proxy (A) is correct because it publishes on-premises web applications to the cloud and enforces Microsoft Entra ID authentication and Conditional Access before any request is forwarded to the internal app, which directly supports verifying identity and device compliance for on-premises access. Microsoft Entra Conditional Access (B) is correct because it is the policy engine that evaluates signals such as user identity, group membership, and device compliance state (via Intune) and then grants, blocks, or challenges access, which is the core of a zero-trust verification step. Azure VPN Gateway (C) only establishes encrypted network tunnels and does not itself verify user identity or device compliance.

Azure Firewall (D) is a network-layer traffic filtering and inspection service, not an identity or device-compliance gate. Azure Bastion (E) provides secure RDP/SSH access to Azure VMs over TLS without exposing public IPs, but it does not publish or broker access to on-premises applications based on identity and device compliance.

Microsoft Defender for Containers (option A) is correct because it is the Defender for Cloud plan specifically designed for Kubernetes and container workloads, providing image vulnerability scanning in registries and at deployment, plus runtime threat detection for AKS clusters via the Defender sensor and admission control. It also delivers Kubernetes-native hardening recommendations and attack-path analysis, matching both the pre-deployment scanning and runtime enforcement requirements. Microsoft Defender for App Service (option B) protects web apps and App Service plans, not container images or AKS runtime.

The regulatory compliance dashboard (option C) only reports against standards and does not perform vulnerability scanning or runtime protection. Microsoft Defender for Servers (option D) covers VMs and server OS workloads, not container image scanning or Kubernetes runtime security.

The Windows Security Events via AMA connector is correct because it collects Windows security event logs—including failed logon events (Event ID 4625)—from Azure VMs into Microsoft Sentinel, enabling correlation of brute-force attempts across multiple sources. The Azure Active Directory (Microsoft Entra ID) sign-in logs connector only ingests Entra ID authentication events, not local or VM-level Windows logon failures. The Syslog connector targets Linux/network device logs (e.g., via rsyslog) and does not capture Windows Security event data.

The Azure Activity log connector records Azure control-plane operations (resource changes), not sign-in or authentication events.

Option B is correct because X.509 certificates provide mutual TLS authentication and encryption for device-to-cloud traffic to IoT Hub, and Azure Device Provisioning Service (DPS) supports automatic enrollment plus certificate rotation workflows (for example, via enrollment groups and rolling certificate updates), which directly meets the requirement for regularly rotated device credentials. Azure Firewall (A) is a network security control and does not authenticate or encrypt IoT device application traffic end-to-end. SAS tokens (C) can authenticate devices but are symmetric shared secrets that are harder to rotate safely at scale and do not provide the same certificate-based identity lifecycle as DPS-managed X.509.

Managed identities (D) are for Azure resources accessing Azure services and cannot be assigned to external IoT devices.

Option B is correct because Microsoft Sentinel is built on a Log Analytics workspace, and a single workspace can ingest data from multiple Azure subscriptions via data collection rules (DCRs) and diagnostic settings, avoiding duplicated workspace and Sentinel costs. This centralized design is the most cost-effective since Sentinel pricing (ingestion and retention) applies per workspace, so consolidating into one workspace prevents paying for multiple Sentinel instances. Azure Lighthouse (A) is for delegated resource management across tenants, not for log ingestion into Sentinel.

Creating a separate workspace per subscription (C) multiplies Sentinel and Log Analytics costs and fragments detection. Azure Policy (D) can assign a workspace via DeployIfNotExists, but assigning a workspace per subscription still results in multiple workspaces rather than the single cost-effective workspace the scenario requires.

Azure Policy with application control is correct because it lets you enforce that only approved applications run on your Windows Server VMs by using the Guest Configuration extension to audit or deploy Windows Defender Application Control (WDAC) / AppLocker policies at scale. This directly addresses the requirement to restrict execution to approved applications. Azure Firewall (A) filters network traffic, not which applications execute on the VM.

Microsoft Defender for Cloud (C) provides security posture and threat protection but does not itself enforce an application allowlist. Just-in-Time VM access (D) restricts inbound management ports, not application execution.

The correct option is C: enabling Azure Defender for Containers in Microsoft Defender for Cloud and integrating it with Azure Container Registry provides native vulnerability scanning of container images and threat detection for AKS workloads. Defender for Containers specifically includes image scanning in ACR (on push and periodic rescanning) and surfaces findings in Defender for Cloud, which matches the requirement to scan images before deployment. Option A is wrong because Microsoft Defender for Cloud Apps is a CASB for SaaS discovery and governance, not container image scanning.

Option B is wrong because Azure Policy for Kubernetes enforces configuration and admission controls but does not itself perform vulnerability scanning of images. Option D is wrong because Microsoft Sentinel is a SIEM/SOAR platform for log collection and analytics, not an image vulnerability scanner.

Azure Firewall (option D) is the correct choice because it provides a centralized, cloud-native firewall service that can inspect and filter traffic across Azure, AWS, and on-premises connections through a hub-and-spoke or Virtual WAN topology, with a single management plane via Azure Firewall Manager for policy and threat intelligence-based blocking. It supports FQDN filtering, threat intelligence, and IDPS, making it suitable for multi-cloud traffic inspection and automatic malicious traffic blocking while minimizing complexity. Azure Front Door (A) is a global HTTP/HTTPS load balancer and WAF for web applications, not a general network traffic inspection hub for multi-cloud and on-premises traffic.

Network Security Groups (B) are stateful packet filters at the subnet/NIC level with no central management pane or advanced threat inspection. Azure DDoS Protection (C) only mitigates volumetric DDoS attacks against Azure resources and does not inspect or block general malicious traffic across hybrid and multi-cloud environments.

Secure Score (A) is a core Microsoft Defender for Cloud capability that continuously assesses your Azure resources and subscriptions against security recommendations and benchmarks, aggregating the results into a numeric score so you can prioritize hardening actions for your infrastructure. Just-in-time (JIT) VM access (C) is also a Defender for Cloud feature that reduces the attack surface of virtual machines by blocking inbound management ports (RDP 3389, SSH 22) by default and opening them only for approved, time-limited requests from authorized IPs. Both directly serve Defender for Cloud's mission of strengthening and monitoring infrastructure security posture.

Incident investigation (B) and User and Entity Behavior Analytics (E) are capabilities of Microsoft Sentinel (the SIEM/SOAR solution), not Defender for Cloud. Privileged Identity Management (D) is a separate Microsoft Entra ID (Azure AD) service for just-in-time privileged role activation and access reviews, not a Defender for Cloud infrastructure feature.

The correct option is D: integrate AKS with Microsoft Entra ID for authentication, because this scenario requires authenticating human users who access the Kubernetes API server, and Entra ID integration provides centralized identity-based authentication with conditional access, MFA, and group-based access. AKS supports Entra ID integration so that kubectl and other clients obtain Entra ID tokens that the API server validates, ensuring only authorized users can authenticate. Option A is not suitable because service account tokens are for workloads and automation inside the cluster, not for authenticating external users.

Option B is incorrect because managed identities are Azure resource identities for services, not per-user Kubernetes API authentication. Option C is incorrect because Azure RBAC for Kubernetes authorization controls what an already-authenticated principal can do, not how users are authenticated.

Option A is correct because integrating Azure Active Directory (Azure AD) with AKS enables cluster authentication and authorization via Azure RBAC, allowing you to control who can access the Kubernetes API server and manage workloads using identity-based controls rather than static credentials. Option E is correct because Azure Policy for AKS uses the Gatekeeper admission controller (Open Policy Agent) to enforce policies on pods and cluster resources at admission time, preventing non-compliant workloads from being deployed and thus hardening the workload configuration. Option B is not the intended answer because Network Security Groups apply at the subnet/NIC level for network traffic filtering, not specifically for securing AKS workloads at the pod or admission level, and pod-level security typically uses Kubernetes Network Policies.

Option C is not correct in this context because Azure Firewall provides network perimeter protection and egress filtering but does not directly secure AKS workloads themselves. Option D is not correct because Azure Front Door is a global HTTP/HTTPS load balancer and WAF for web applications, not a mechanism for securing AKS workloads internally.

The correct option is D: the policy denies creation of network security rules that allow traffic to ports other than 22 and 3389. Azure Policy definitions with a deny effect evaluate the properties of a resource being deployed—here, the destinationPortRange of a network security rule—and block the deployment when the condition is met, so rules permitting any port outside 22 and 3389 are rejected. Option A is wrong because the policy does not require ports to fall within a range; it blocks rules that allow ports other than the two specified.

Option B is wrong because the policy targets NSG rule definitions in Azure Resource Manager, not live inbound traffic flows. Option C is wrong because the policy does not permit or allow traffic; it only denies noncompliant rule creation.

Microsoft Entra Kerberos authentication enables users to authenticate to on-premises resources using their Entra ID credentials without requiring a VPN, and it supports passwordless methods like FIDO2 and Windows Hello for Business. Option A is incorrect because Entra Application Proxy is designed for publishing on-premises web applications, not for general authentication. Option C is incorrect because Conditional Access policies enforce access controls but do not provide authentication or passwordless capabilities.

Option D is incorrect because Entra Connect Sync with password hash synchronization only syncs password hashes and does not support real-time passwordless authentication without a VPN.

When referencing a Key Vault secret in an ARM template parameter, the user or service principal deploying the template must have 'Get' and 'List' permissions on the secret. If the deployment principal does not have those permissions, access is denied. Option A is wrong because special characters in secrets are supported, but the deployment still requires permissions.

Option B is wrong because the template uses a parameter reference to the secret, not the secret's URI directly; that is the correct approach. Option D is wrong because the Key Vault can be in a different resource group than the deployment, as long as the deployment principal has the necessary permissions.

Option C is correct because API Management natively provides rate limiting and quota policies to throttle requests and protect against abuse, the validate-json policy to validate JSON payloads against a schema, and OAuth 2.0 support to secure API access via authorization servers. These features directly satisfy the stated requirements within the APIM gateway itself. Option A addresses identity and authentication but does not provide throttling or JSON schema validation.

Option B offloads protection to Application Gateway WAF, which handles web attack patterns but not APIM-level rate limiting or JSON payload schema validation. Option D provides network-layer filtering with Azure Firewall and NSGs, which cannot inspect JSON payloads or apply API-level throttling.

Microsoft Defender for Cloud with the Defender for Containers plan (option D) is correct because it is the purpose-built Azure solution that provides image vulnerability scanning (via the integrated Qualys/registry scanner), runtime threat detection using the Defender sensor on AKS nodes, and security alerts for suspicious container activity in a single integrated service. It also supports Kubernetes-native hardening recommendations and integrates with AKS and Azure Container Registry out of the box. Option A is incomplete because Azure Security Center is the former name of Defender for Cloud and Azure Policy alone only enforces governance, not runtime detection or image scanning.

Option B does not fit because Azure Container Registry only stores images and Azure Monitor provides telemetry, not vulnerability scanning or container threat alerts. Option C is incorrect because Azure Policy and Azure Firewall address compliance and network filtering, not image scanning or runtime container security.

Azure Policy is the correct choice (A) because it can enforce admission-time constraints on an AKS cluster, such as an allowed-registries policy that denies pods whose images do not originate from the specified private Azure Container Registry. This directly satisfies the requirement that only authorized images from a private registry can run. Option B is incorrect because ACR Tasks scan images for vulnerabilities but do not restrict which registries pods may pull from.

Option C is incorrect because network policies control pod-level traffic, not image provenance, and blocking outbound traffic does not enforce registry allowlisting. Option D is incorrect because Microsoft Defender for Containers provides threat detection and posture management, not admission control that blocks unauthorized images.

Microsoft Intune provides device compliance policies and can send device posture signals to Entra ID Conditional Access. With Intune, you can enforce device health and compliance requirements before granting access. Option A is wrong because Microsoft Purview focuses on data governance and compliance, not device management.

Option C is wrong because Microsoft Defender for Cloud Apps is a cloud access security broker (CASB) and does not directly manage device compliance. Option D is wrong because Microsoft Sentinel is a security information and event management (SIEM) solution and does not provide device posture signals.

The correct option is B: implementing network micro-segmentation with Azure Firewall and NSGs to isolate the PLCs from the corporate network. Since the legacy PLCs cannot be patched, the most effective mitigation is to limit their attack surface and blast radius by placing them in a segmented network zone with strict allow-list rules, so a compromised PLC cannot pivot laterally into corporate systems. Azure Firewall provides centralized Layer 3–7 filtering and NSGs enforce subnet/NIC-level traffic control, which directly addresses the unpatched-device risk.

Option A is wrong because a VPN gateway only provides encrypted connectivity, not isolation or traffic restriction. Option C is wrong because the Defender for IoT micro-agent requires installation and support on the device, which unpatched legacy PLCs typically cannot accommodate. Option D is wrong because TLS 1.2 only protects data in transit and does not prevent compromise or lateral movement from an unpatched PLC.

Defender for Identity is designed to detect advanced threats against on-premises Active Directory by analyzing signals from domain controllers and AD FS. Option A is correct because it identifies privilege escalation attempts, such as unauthorized additions to privileged groups or abuse of AdminSDHolder, by monitoring directory changes and authentication events. Option B is correct because it detects lateral movement techniques like Pass-the-Hash by correlating NTLM authentication anomalies and suspicious logon patterns across domain controllers.

Option D is correct because it flags reconnaissance attacks that use LDAP queries to enumerate users, groups, and privileged accounts, which is a common precursor to AD attacks. Option C is not correct because file integrity monitoring on domain controllers is not a Defender for Identity capability; that is handled by other tools such as Microsoft Defender for Endpoint or File Integrity Monitoring in Defender for Cloud. Option E is not correct because Defender for Identity focuses on identity and directory signals rather than monitoring outbound network traffic to external IP addresses, which is covered by network security solutions.

The correct option is B: applying an Azure Policy that restricts container images to only those from approved registries. Azure Policy for AKS uses the Gatekeeper admission controller to evaluate requests against policy definitions at admission time, so any pod or deployment referencing a non-approved image is automatically denied and blocked from running in the cluster. This directly enforces the requirement that only authorized containers can run.

Option A does not fit because network policies only control pod-to-pod traffic, not which images are allowed to run. Option C does not fit because Azure AD integration handles authentication of users to the cluster, not image authorization. Option D does not fit because Azure RBAC controls who can perform deployment actions, but it does not validate or block unauthorized container images.

Security recommendations (B) is correct because Microsoft Defender for Cloud continuously assesses Azure resources against built-in and regulatory benchmarks (e.g., Azure Security Benchmark, CIS, PCI DSS) and surfaces specific, actionable remediation steps for each misconfiguration it detects. Secure score (E) is correct because it aggregates the results of those assessments into a measurable score and highlights the highest-impact misconfigurations and improvement actions, letting you prioritize and track remediation progress over time. Together, recommendations identify the misconfigurations and secure score quantifies and prioritizes them.

File integrity monitoring (A) is wrong because FIM detects changes to critical OS files and registry keys on VMs, not Azure resource misconfigurations. Just-in-time VM access (C) is wrong because it reduces the attack surface by opening management ports only on demand, rather than identifying configuration issues. Adaptive application controls (D) is wrong because it uses machine-learning allowlists to control which applications can run on VMs, which is workload protection, not misconfiguration assessment.

Network Security Groups (NSGs) are correct because they enforce network-layer defense-in-depth by filtering inbound and outbound traffic to and from Azure VMs using allow/deny security rules based on source/destination IP, port, and protocol, effectively segmenting and restricting access at the subnet or NIC level. Azure Backup is correct because it provides the data-recovery layer of defense-in-depth, protecting VM data against accidental deletion, corruption, or ransomware by creating recoverable recovery points stored in a Recovery Services vault. Azure Logic Apps is not a security control for VMs; it is a workflow-orchestration service for integrating apps and automating business processes.

Azure Automation is a configuration-management and process-automation service (runbooks, DSC, update management) and does not itself provide a protective security boundary for VM traffic or data. Azure Front Door is a global layer-7 web application delivery and CDN/WAF service for HTTP/HTTPS workloads, not a mechanism for protecting Azure VMs directly.

Microsoft Entra Conditional Access policies (option A) are correct because they evaluate signals such as user, device state, and location at authentication time and can enforce controls like requiring MFA or compliant devices even for unmanaged BYOD endpoints that cannot be enrolled in Intune. Conditional Access can block or restrict access to corporate resources for devices that don't meet policy, which directly addresses the scenario. Intune enrollment policies (B) only apply to devices being enrolled and cannot govern unenrolled devices.

Windows Defender Application Control (C) is an application control mechanism on Windows endpoints, not an access policy for corporate resources. Microsoft Defender for Endpoint (D) is an endpoint detection and response platform, not the feature that enforces access policy for unmanaged devices.

The correct answer is A: Add a virtual network rule for the specific VNet. In Azure Storage, network access restrictions are configured on the storage account's Networking blade, where you can add virtual network rules that allow access only from selected VNets and subnets; this directly satisfies the requirement that 'seccorpstorage' be accessible only from a specific Azure virtual network. Option B is incomplete because enabling the Microsoft.Storage service endpoint on the subnet is a prerequisite that makes the subnet eligible, but the storage account still needs the corresponding virtual network rule to actually restrict access.

Option C is wrong because an IP-based firewall rule uses public IP addresses and does not restrict access to a specific VNet's private traffic. Option D is wrong because enabling public network access opens the account to public connectivity rather than limiting it to one VNet.

Option A (a local network gateway resource in Azure) is required because it defines the on-premises VPN device's public IP address and address spaces, which Azure uses as the remote endpoint for the site-to-site tunnel. Option B (a connection resource with a shared key) is required because the connection object links the virtual network gateway to the local network gateway and carries the pre-shared key (PSK) used for IKE/IPsec authentication. Option D (a virtual network gateway in Azure) is required because it is the Azure-side VPN Gateway (VpnGw SKU) that terminates the IPsec/IKE tunnel and routes traffic into the virtual network.

Option C (an ExpressRoute circuit) does not belong because ExpressRoute is a private dedicated-circuit connectivity model, not a VPN Gateway component, and the scenario specifies VPN Gateway. Option E (an Azure Firewall) does not belong because it is a managed network security service for traffic filtering and is not a prerequisite for establishing a VPN Gateway site-to-site connection.

The correct option is B: a Windows 10/11 Update Rings policy with a deadline for quality and feature updates. Update Rings in Intune are the purpose-built mechanism for controlling Windows Update behavior on managed devices, and configuring a deadline forces installation of quality and feature updates by a set time, preventing users from deferring them indefinitely. Option A is too vague and device configuration profiles do not provide the update-ring deadline enforcement needed here.

Option C only evaluates and reports compliance; it does not install updates or block deferrals. Option D concerns Defender Antivirus security settings, not Windows Update ring scheduling or deadlines.

The correct answer is B: connect AWS and GCP accounts using the cloud connectors in Defender for Cloud. Defender for Cloud's native multi-cloud support requires onboarding non-Azure environments through the AWS and GCP connectors, which establish the necessary trust and inventory so that resources, recommendations, and alerts from those clouds become visible in the portal. Only after this connection can Defender plans, compliance policies, or agent-based extensions be applied to those resources.

Option A is premature because enabling subscription-level Defender plans only affects Azure resources, not AWS or GCP. Option C is a later configuration step that depends on data already being collected, and Option D is not the onboarding mechanism for multi-cloud visibility, since Azure Arc is used for connecting specific servers rather than enabling cloud-wide AWS/GCP visibility.

Option A is correct because the built-in Azure Policy 'Auditing on SQL Database should be enabled' enforces that auditing is set to 'On' for Azure SQL Database, ensuring database activity is logged for security and compliance monitoring. Option D is correct because the policy 'Firewall and virtual network settings for SQL Database should be configured' enforces that Azure SQL Database has network-level access controls (firewall rules or virtual network service endpoints/private endpoints) in place, restricting access to authorized networks only. Option B is incorrect because it targets TDE on SQL Server running on VMs (IaaS), not Azure SQL Database (PaaS), so it does not apply to this scenario.

Option C is incorrect because it audits the SQL Server-level audit setting rather than enforcing a secure configuration on Azure SQL Database itself. Option E is incorrect because it concerns secure transfer for storage accounts, which is unrelated to Azure SQL Database configuration.