To produce security recommendations for Azure Kubernetes Service (AKS) and update the secure score, Microsoft Defender for Cloud must first be enabled for this specific workload and configured to monitor the resources.

Enabling the "Defender for Containers" plan (part of the Defender plans) is the initial step that unlocks the advanced security features, threat detection, and specific security recommendations for AKS clusters. Without this plan, Defender for Cloud will not perform the in-depth assessments required.

After the plan is enabled, Defender for Cloud needs to deploy a monitoring agent to the AKS clusters to collect security-related data. Configuring auto-provisioning ensures that the Defender agent is automatically deployed to all existing and future AKS clusters within the scope, which is essential for generating accurate recommendations.

B. Assign regulatory compliance policies: This action maps existing recommendations to compliance standards. It does not enable the initial data collection or generate new recommendations for unmonitored resources.

C. Review the inventory: This is a diagnostic step to view the status of resources. While useful for identifying unmonitored resources, it is not a corrective action to enable monitoring.

D. Add a workflow automation: This is used to automate responses to security alerts and recommendations after they have been generated, not to enable their creation.

1. Microsoft Learn

Official Documentation

"Enable Microsoft Defender for Cloud plans": This document explicitly states that to get the full range of protections for resources in a subscription

you must enable the Defender plans for the resource types. For containers

this means enabling the Defender for Containers plan.

Reference: In the section "Enable Defender for Cloud plans on your subscriptions

" it details the process of turning on plans like Defender for Containers.

2. Microsoft Learn

Official Documentation

"Introduction to Microsoft Defender for Containers": This document clarifies that Defender for Containers provides security recommendations as part of its environment hardening capabilities. Enabling the plan is the prerequisite for these features.

Reference: The "Overview" section lists "Environment hardening" which includes "continuously assessing your clusters to provide visibility into misconfigurations" and "security recommendations."

3. Microsoft Learn

Official Documentation

"Enable Defender for Containers components": This document describes the components needed for Defender for Containers to function. It highlights the need for the Defender agent and how to enable it.

Reference: In the section "Enable the plan

" it states that enabling the plan is the first step. It then discusses deploying the Defender agent

which can be managed via the auto-provisioning settings in Defender for Cloud's "Environment settings" page. This confirms that both enabling the plan and ensuring agent deployment (via auto-provisioning) are key steps.

Azure Virtual Network Manager (AVNM) security admin rules are designed to enforce security policies at scale across multiple virtual networks. These rules are evaluated before Network Security Group (NSG) rules and have a higher priority. By creating a security admin rule that denies inbound RDP (port 3389) traffic from any source other than the AzureBastionSubnet, you can centrally override any permissive RDP rules in individual NSGs. This ensures that all RDP connections must be initiated through the Bastion host, directly addressing the requirement to prevent NSG rules from creating a bypass.

A. Azure Virtual Network Manager connectivity configurations: These configurations are used to define network topology, such as hub-and-spoke or mesh, not for enforcing traffic filtering rules.

C. Azure Firewall application rules: These rules filter outbound traffic based on Fully Qualified Domain Names (FQDNs) for protocols like HTTP/S. They are not used for controlling inbound RDP traffic.

D. Azure Firewall network rules: While Azure Firewall can block RDP, the question's core problem is overriding conflicting NSG rules at scale. AVNM security admin rules are specifically designed for this purpose and take precedence over NSGs.

1. Microsoft Documentation | Azure Virtual Network Manager | Security admin rules: "Security admin rules are high priority rules that are evaluated before NSG rules... With security admin rules

you can enforce

and override NSG rules at scale." This document explicitly states the precedence and purpose of security admin rules

confirming they can override NSGs to enforce a security baseline.

Source: Microsoft Learn

"Security admin rules in Azure Virtual Network Manager

" Introduction section.

2. Microsoft Documentation | Azure Virtual Network Manager | How it works: "A security configuration contains a set of security admin rules that you can apply to one or more network groups... When you apply a security configuration to a virtual network

all the network interfaces (NICs) in the virtual network will have the security admin rules applied. The rules are evaluated before network security groups."

Source: Microsoft Learn

"How security admin rules work with Azure Virtual Network Manager

" How it works section.

3. Microsoft Documentation | Azure Virtual Network Manager | Overview: This document distinguishes between the two main capabilities of AVNM: "Connectivity configuration" and "Security configuration

" clarifying that option A (connectivity) is for topology and option B (security) is for traffic control.

Source: Microsoft Learn

"What is Azure Virtual Network Manager?

" Key benefits section.

The most direct and appropriate method to restrict access to an Azure Storage account from specific internet-based IP addresses is by using the storage account's built-in firewall. This feature allows you to define a set of rules that explicitly grant access from specified public IP addresses or CIDR ranges. By adding the 20 public IP addresses of the application servers to the firewall's allow list and denying access by default, you ensure that only those designated servers can reach the storage account's public endpoint. This is a native security feature designed precisely for this use case.

A. service tags in network security groups (NSGs): Service tags represent groups of IP prefixes for Azure services, not specific external application servers. NSGs apply to resources within a virtual network.

B. managed rule sets in Azure Web Application Firewall (WAF) policies: WAF is designed to protect web applications from common exploits (Layer 7), not for network-level IP-based access control to a storage account.

C. inbound rules in network security groups (NSGs): NSGs filter traffic for resources within an Azure Virtual Network (VNet), not for the public endpoint of a PaaS service like a storage account.

E. inbound rules in Azure Firewall: Azure Firewall is a VNet-level security service used to filter traffic for resources within that VNet, not the primary tool for securing a storage account's public endpoint.

1. Microsoft Learn

Azure Storage Documentation. "Configure Azure Storage firewalls and virtual networks." Under the section "Grant access from an internet IP range

" it states

"You can grant access to storage accounts from specific public internet IP address ranges by creating IP network rules. Each storage account supports up to 200 rules." This directly supports using the storage account firewall for the specified scenario.

Source: learn.microsoft.com/en-us/azure/storage/common/storage-network-security?tabs=azure-portal#grant-access-from-an-internet-ip-range

2. Microsoft Learn

Azure Storage Documentation. "Security recommendations for Blob storage." In the "Network security" section

a key recommendation is to "Use the firewall in your storage account to allow traffic only from specific virtual networks or public IP address ranges."

Source: learn.microsoft.com/en-us/azure/storage/blobs/security-recommendations#network-security

3. Microsoft Learn

SC-100 Learning Path. "Design a solution for network security." This module discusses securing PaaS services

explaining that services like Azure Storage have built-in firewall capabilities to restrict access to their public endpoints based on IP addresses

which is distinct from VNet-centric controls like NSGs or Azure Firewall.

Source: learn.microsoft.com/en-us/training/modules/design-solutions-for-securing-azure-infrastructure/4-design-solutions-for-network-security (Section: Secure PaaS services)

Azure SQL Database is a fully managed Platform as a Service (PaaS) offering. This model abstracts the underlying infrastructure, meaning Microsoft handles all patching and updates automatically, which directly fulfills the requirement to minimize operational requirements. It natively supports security features like Dynamic Data Masking to protect sensitive data. For migrating individual or groups of databases without complex instance-level dependencies, Azure SQL Database is generally the most cost-effective solution compared to other PaaS options like Azure SQL Managed Instance, thus meeting all the specified criteria.

A. Azure SQL Managed Instance: While it is a PaaS service that automates patching and supports dynamic data masking, it is typically more expensive than Azure SQL Database and is designed for migrations requiring instance-level features.

B. Azure Synapse Analytics dedicated SQL pools: This service is optimized for large-scale data warehousing and analytics, not for general-purpose transactional databases. It is an unnecessarily complex and costly option for this scenario.

D. SQL Server on Azure Virtual Machines: This is an Infrastructure as a Service (IaaS) solution. It requires the customer to manage and perform all patching for both the operating system and SQL Server, directly contradicting the requirement to minimize operational effort.

1. Microsoft Learn

"Choose an Azure SQL option": This document compares the Azure SQL offerings. It states that Azure SQL Database is a "fully managed SQL database" where "Microsoft is responsible for all patching and updating of the SQL code base". It also positions SQL Database as having the "Lowest cost in PaaS". For SQL Server on Azure VMs

it explicitly lists "OS and SQL Server patching" as a customer responsibility.

Reference Section: "Compare the options" table.

2. Microsoft Learn

"What is Azure SQL Database?": This document describes the service

stating it is a "fully managed platform as a service (PaaS) database engine that handles most of the database management functions such as upgrading

patching

backups

and monitoring without user involvement."

Reference Section: "Overview".

3. Microsoft Learn

"Dynamic Data Masking": This documentation confirms that Dynamic Data Masking is a supported feature in Azure SQL Database

Azure SQL Managed Instance

and Azure Synapse Analytics.

Reference Section: "Applies to" and "Permissions".

The solution must satisfy two distinct encryption key management requirements.

1. Insurance Claim Files: The requirement is for encryption keys to be "hosted on-premises." Azure Blob storage with customer-provided keys (CPK) meets this. With CPK, the client application provides the encryption key with each read/write request. Azure Storage uses the key for the operation but never stores it. This allows the key to be securely stored and managed in an on-premises Hardware Security Module (HSM).

2. Cardholder Data: The requirement is for "encryption keys managed by the company." Storing cardholder data in an Azure SQL Database encrypted with Transparent Data Encryption (TDE) using keys from an Azure Key Vault Managed HSM fulfills this. A Managed HSM provides a single-tenant, FIPS 140-2 Level 3 validated HSM where the company retains full and exclusive control over the key lifecycle, satisfying the "company-managed" requirement.

C. Azure Key Vault Managed HSM is a cloud service hosted in Azure, not on-premises. This configuration violates the requirement for insurance claim file keys to be hosted on-premises.

D. Microsoft-managed keys are created, stored, and managed by Microsoft, not the company. This configuration violates the requirement for cardholder data keys to be company-managed.

1. Customer-Provided Keys (for Answer A): Microsoft Learn. (2023). Provide an encryption key on a request to Blob storage. "When a client application presents an encryption key on the request

Azure Storage performs encryption and decryption transparently... The encryption key is not persisted in Azure Storage." This supports using keys managed entirely outside of Azure

such as on-premises.

2. TDE with Managed HSM (for Answer B): Microsoft Learn. (2024). Customer-managed transparent data encryption (TDE) - Azure SQL Database & Azure Synapse. "Customer-managed TDE... provides control over key lifecycle management... Azure Key Vault Managed HSM is a highly available and scalable single-tenant solution for managing cryptographic keys." This confirms it as a company-managed key solution.

3. Managed HSM Location (for why C is incorrect): Microsoft Learn. (2023). What is Azure Key Vault Managed HSM?. "Azure Key Vault Managed HSM is a fully managed

highly available

single-tenant

standards-compliant cloud service..." This clarifies that the service is not hosted on-premises.

4. Microsoft-Managed Keys (for why D is incorrect): Microsoft Learn. (2023). Azure Storage encryption for data at rest. "By default

all data in a storage account is encrypted using Microsoft-managed keys. With Microsoft-managed keys

Microsoft creates and manages the keys that are used to encrypt your data..." This shows the company does not manage these keys.

The security alert explicitly identifies the threat as a "Storage account with publicly accessible containers detected." This indicates that anonymous public access is enabled for blobs within the storage account. The most direct and effective way to prevent this specific misconfiguration from reoccurring is to use an Azure Policy that enforces the desired state. The policy definition "Storage account public access should be disallowed" is designed specifically for this purpose. By assigning this policy, you can audit or deny the creation or modification of storage accounts that permit public blob access, thereby systematically preventing this vulnerability across your environment.

B. Azure Key Vault Managed HSM should have purge protection enabled: This policy applies to Azure Key Vault, not Azure Storage accounts, and is irrelevant to the alert about public container access. C. Storage accounts should prevent shared key access: This policy disables authentication using account access keys, which is a separate security control from anonymous public access settings. D. Storage account keys should not be expired: This is not a standard Azure Policy definition and is related to key rotation practices, not the prevention of public access.

1. Microsoft Learn, Azure Policy built-in definitions for Azure Storage: The documentation lists the "Storage account public access should be disallowed" policy. Its description states, "Anonymous public access is a convenient way to share data, but it can also be a security risk. To prevent data breaches, it's recommended to disallow public access to a storage account." This directly aligns with the alert's details.

Source: Microsoft Learn, Azure Policy built-in definitions for Azure Storage, "Storage" section.

2. Microsoft Learn, Remediate recommendations in Microsoft Defender for Cloud: This document explains how security recommendations in Defender for Cloud often have a corresponding Azure Policy that can be used for enforcement. The recommendation "Storage accounts should prevent public access" is directly enforced by the policy in option A.

Source: Microsoft Learn, Security recommendations - a reference guide, "Remediate security recommendations" section.

3. Microsoft Learn, Prevent anonymous public read access to containers and blobs: This documentation details the security risk of public access and recommends disabling it at the account level. It states, "To enforce that anonymous access is disallowed for all storage accounts in a subscription or resource group, assign the Azure Policy 'Storage account public access should be disallowed'."

Source: Microsoft Learn, Blob storage > Data protection > Prevent anonymous public read access to containers and blobs, "Disallow public access for a subscription or resource group" section.

Dynamic Application Security Testing (DAST) is a "black-box" security testing methodology that analyzes a web application from the outside while it is running. DAST tools simulate attacks against an application to identify vulnerabilities without needing access to the source code. This method is highly effective for detecting runtime vulnerabilities such as cross-site scripting (XSS), SQL injection, and insecure server configurations (e.g., HTTP header issues), which directly matches the requirements of the question. DAST assesses the application from an attacker's perspective, making it the ideal choice for this scenario.

A. interactive application security testing (IAST): IAST analyzes the application from within while it runs, often using agents. While effective, DAST is the more direct and standard black-box approach for testing the specified external vulnerabilities.

B. static application security testing (SAST): SAST analyzes the application's source code without executing it. It cannot detect runtime vulnerabilities or insecure server configurations, which are only present in a running application.

C. runtime application self-protection (RASP): RASP is a security technology that protects an application in real-time by detecting and blocking attacks. It is a protection mechanism, not a testing tool for identifying vulnerabilities.

1. Microsoft Cloud Adoption Framework

"Security in the DevOps (DevSecOps)": This document describes different application security testing methods. It states

"Dynamic Application Security Testing (DAST) analyzes running web applications and services for security vulnerabilities. DAST tools interact with the application like a malicious user would... Common vulnerabilities found by DAST tools include cross-site scripting

and SQL injection." This directly supports the use of DAST for the specified vulnerabilities.

Source: Microsoft Docs

Cloud Adoption Framework > Strategy > Define a security strategy > Security in the DevOps (DevSecOps).

2. Microsoft Security Development Lifecycle (SDL)

"Practice #10: Perform Dynamic Analysis Security Testing": The SDL

a foundational Microsoft security process

explicitly recommends DAST. It describes DAST as a method that "finds security vulnerabilities in a running web application by presenting it with a series of malicious inputs."

Source: Microsoft Security Development Lifecycle > SDL Practices > Verification > Practice #10: Perform Dynamic Analysis Security Testing.

3. OWASP

"DAST": The Open Web Application Security Project (OWASP)

a widely respected authority

defines DAST as a process of testing an application from the outside. It notes

"DAST is a black-box security testing methodology in which an application is tested from the outside."

Source: owasp.org

search for "DAST".

Azure Policy is the primary Azure service for implementing governance and ensuring compliance. It allows you to create, assign, and manage policies that enforce rules over your resources. The Microsoft cloud security benchmark (MCSB) is available as a built-in policy initiative within Azure Policy. By assigning this initiative to the relevant scope (e.g., the subscription or resource groups where App Services are deployed), you can continuously audit the configuration of the deployed apps against MCSB recommendations. Azure Policy can also be set to "Deny" non-compliant deployments, ensuring that any app deployed through Azure DevOps or any other method must adhere to the benchmark to be created or updated.

A. DevOps security in Microsoft Defender for Cloud: This provides security posture visibility and threat detection within the DevOps pipeline and code, not for enforcing compliance on deployed Azure resources.

B. Microsoft Defender for App Service: This is a threat detection service that identifies attacks against running applications; it does not enforce configuration compliance against a benchmark.

C. a branch policy in Azure DevOps: This enforces rules on the source code repository and pull request process, not on the configuration of the final deployed Azure resources.

1. Azure Policy and MCSB: Microsoft Learn

"Overview of the Microsoft cloud security benchmark (v1)". Under the "Monitor compliance" section

it states

"You can monitor your compliance with this benchmark by using the Microsoft cloud security benchmark initiative in Azure Policy."

2. Azure Policy for Governance: Microsoft Learn

"What is Azure Policy?". The introduction states

"Azure Policy is a service in Azure that you use to create

assign

and manage policies. These policies enforce different rules and effects over your resources

so those resources stay compliant with your corporate standards and service level agreements."

3. DevOps Security in Defender for Cloud: Microsoft Learn

"DevOps security". The overview explains

"The DevOps security workload in Defender for Cloud unifies security management... to provide full visibility into your application development lifecycle and security posture from code to cloud." This highlights its focus on the pipeline

not the deployed resource's compliance state.

4. Microsoft Defender for App Service: Microsoft Learn

"Protect your Azure App Service web apps and APIs". The documentation states

"Microsoft Defender for App Service uses the scale of the cloud to identify attacks targeting applications running over App Service." This confirms its role in threat detection

not configuration compliance.

Azure Application Gateway with its integrated Web Application Firewall (WAF) is the most appropriate solution. The WAF component can be configured with a managed bot protection rule set to identify and block malicious bots and scanners. Furthermore, the WAF supports custom rules for geo-filtering, which can restrict access to only users from Europe and the United States, directly minimizing the attack surface as required. This solution is specifically designed to protect web applications, such as Azure App Service, from common exploits, vulnerabilities, and automated threats.

A. Azure Firewall Premium: While it offers advanced threat protection, it is a network firewall, not a specialized web application firewall. A WAF is more suitable for protecting against web-specific attacks and bots.

C. network security groups (NSGs): NSGs operate at the network layer (L3/L4) and cannot inspect application traffic to identify or block malicious bots. They lack native geo-filtering capabilities.

D. Azure Traffic Manager and application security groups: Traffic Manager is a DNS-based load balancer and has no security inspection features. Application security groups are for simplifying NSG rules, which are insufficient for this task.

1. Microsoft Documentation

"What is Azure Web Application Firewall on Azure Application Gateway?": "Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection of your web applications from common exploits and vulnerabilities... This includes protection against things like malicious bot attacks."

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview

2. Microsoft Documentation

"Bot protection overview": "Azure WAF on Application Gateway provides protection from bot attacks through the OWASP managed bot protection rule set."

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/web-application-firewall/ag/bot-protection-overview

3. Microsoft Documentation

"Custom rules for Web Application Firewall v2 on Azure Application Gateway": This document details the creation of custom rules

including "Geomatch" as a match type. "You can create a custom rule to block or allow traffic from certain countries/regions... This helps you to block requests from geographic locations that are known to be malicious."

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/web-application-firewall/ag/custom-rules-overview (See section on Match types and operators).

4. Microsoft Documentation

"Network security groups": "A network security group contains security rules that allow or deny inbound network traffic to

or outbound network traffic from

several types of Azure resources... You can filter traffic by source and destination IP address

port

and protocol." This confirms NSGs operate at L3/L4 and lack application-layer intelligence for bot detection.

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview

Microsoft Defender for Cloud is a Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP) solution. It extends its capabilities beyond Azure to multicloud environments, including Amazon Web Services (AWS) and Google Cloud Platform (GCP). By connecting AWS and GCP accounts to Defender for Cloud, you can continuously assess their security posture against regulatory compliance standards. Defender for Cloud automatically provides prioritized security recommendations (improvement actions) with detailed implementation guidance. These assessments and recommendations directly contribute to the technical control status within Microsoft Purview Compliance Manager, thus automating compliance monitoring and minimizing administrative effort for the multicloud environment.

B. Microsoft Defender for Cloud Apps: This is a Cloud Access Security Broker (CASB) focused on securing SaaS applications, not the underlying IaaS/PaaS infrastructure of AWS and GCP for regulatory compliance posture.

C. Microsoft Sentinel: This is a SIEM/SOAR solution for threat detection and response. While it can ingest logs from multicloud environments, its primary function is not compliance posture management or providing improvement actions.

D. Compliance Manager connectors: While connectors are a concept, Microsoft Defender for Cloud is the specific, primary service that provides the multicloud CSPM capabilities required to connect AWS and GCP for automated compliance assessment.

1. Microsoft Documentation - Microsoft Defender for Cloud: "Connect your AWS accounts to Microsoft Defender for Cloud". This document details how Defender for Cloud integrates with AWS to provide CSPM. It states

"When you connect your AWS accounts to Defender for Cloud

you're integrating AWS Security Hub with Defender for Cloud. Defender for Cloud thus provides visibility and protection across both of these cloud environments to provide: ... Compliance with regulatory standards."

Source: Microsoft Learn

"Connect your AWS accounts to Microsoft Defender for Cloud"

Introduction section.

2. Microsoft Documentation - Microsoft Defender for Cloud: "Connect your GCP projects to Microsoft Defender for Cloud". This document explains the integration with GCP. It mentions

"When you connect your GCP projects to Microsoft Defender for Cloud

you are integrating GCP Security Command Center with Defender for Cloud... You get recommendations from Defender for Cloud that help you protect your resources in line with Microsoft cloud security benchmark."

Source: Microsoft Learn

"Connect your GCP projects to Microsoft Defender for Cloud"

Introduction section.

3. Microsoft Documentation - Microsoft Purview Compliance Manager: "Microsoft Purview Compliance Manager and Microsoft Defender for Cloud". This document explains the integration. It states

"Defender for Cloud's regulatory compliance dashboard provides insights into your compliance posture based on continuous assessments of your Azure and hybrid environments... The integration of Defender for Cloud with Compliance Manager allows you to get a single view of your overall compliance posture."

Source: Microsoft Learn

"Microsoft Purview Compliance Manager and Microsoft Defender for Cloud"

How the integration works section.