CCNA Design security solutions for applications and data Questions

Microsoft Purview Information Protection with encryption and usage rights (option B) is correct because it applies persistent protection to the file itself via sensitivity labels, so the encryption and usage restrictions travel with the document even after it is downloaded to a personal device, and only authorized users with the granted rights can open it. Office 365 Message Encryption (A) only protects email messages in transit and does not persist on files stored locally. BitLocker (C) encrypts the whole drive at the OS level, so protection is lost once the file leaves that device.

Azure Information Protection (D) is the legacy predecessor now superseded by Purview Information Protection, making B the current, appropriate choice.

Microsoft Purview Data Map is the correct choice because it is the foundational service that performs automated scanning, data discovery, and classification of data sources such as Azure Blob Storage, populating the catalog with sensitivity labels and classifications. It uses scan rule sets and classification rules to detect sensitive data types across registered sources. Azure Policy is a governance service for enforcing resource compliance, not for scanning and classifying data content.

Microsoft Purview Information Protection applies sensitivity labels to files and emails but does not itself scan and classify data at rest in Blob Storage. Microsoft Purview Data Loss Prevention enforces policies to prevent data exfiltration, not to discover and classify stored data.

Sensitivity labels in Microsoft Purview Information Protection can be configured with encryption and content marking (watermark) settings, which are applied automatically when users apply the label. Option A is incorrect: the Azure Information Protection scanner discovers and labels existing files but does not configure label settings; the label itself must be defined. Option B is incorrect: a DLP policy can block sharing but cannot add watermarks or encrypt content on its own.

Option D is incorrect: Microsoft 365 Message Encryption provides encryption for email transport but does not apply watermarks or enforce labels.

The correct answer is B: a managed identity must be associated with the policy assignment and have permissions to modify TDE. Azure Policy's modify effect performs remediation-style changes to resources, so the assignment needs a system-assigned or user-assigned managed identity with the required RBAC permissions (such as SQL DB Contributor or a custom role granting Microsoft.Sql/servers/databases/transparentDataEncryption/write) to actually enable TDE on the database. Option A is incorrect because modify works at any assignment scope (management group, subscription, resource group) as long as the identity and permissions are configured.

Option C is incorrect because modify can act on existing resources during evaluation/remediation, not only newly created ones. Option D is incorrect because TDE enablement via modify is not limited to the General Purpose service tier.

Option A is correct because in Azure API Management, the validate-jwt policy validates OAuth 2.0/JWT bearer tokens issued by an identity provider (such as Microsoft Entra ID), ensuring only authorized partners with valid tokens can call the APIs, while the rate-limit-by-key policy throttles requests based on a key such as the subscription key or a claim (e.g., partner ID), directly preventing abuse. Together these policies satisfy both the authentication and rate-limiting requirements within the APIM policy pipeline. Option B does not fit because client certificate authentication alone does not provide token-based authorization and a global rate limit applies to all callers rather than per-partner, so one partner could exhaust the quota.

Option C is insufficient because a subscription key is a shared secret that can be leaked and IP whitelisting is brittle and does not enforce per-partner request limits. Option D is incomplete because OAuth 2.0 tokens and Key Vault key storage address credential handling but do not themselves implement rate limiting in APIM.

The correct answer is C, Conditional Access policy, because Conditional Access is the Intune/Microsoft Entra mechanism that enforces access decisions such as requiring a device to be compliant before granting access to corporate resources like Exchange Online for Outlook Mobile. In this scenario, the company needs an access control that evaluates device compliance at sign-in and blocks noncompliant devices, which is exactly what a Conditional Access policy with a 'Require device to be marked as compliant' grant control does. A compliance policy (D) only defines and evaluates compliance state but does not itself block or grant access, and a device configuration policy (B) merely configures settings on devices without enforcing access.

An app protection policy (A) protects app data with PINs and encryption but does not gate access to corporate email based on device compliance.

The correct option is A, an analytics rule with an automated response, because in Microsoft Sentinel analytics rules generate incidents from detected events, and their automated response (via automation rules or playbooks triggered on incident creation) can send an email to the security team when a high-severity incident is created. This directly satisfies the requirement of automatic notification upon incident creation. A workbook (B) is only a visualization/reporting dashboard and does not trigger notifications.

A watchlist (C) stores reference data for enrichment or correlation and cannot send emails. A hunting query (D) is a manual, proactive search for threats and does not automatically notify anyone.

Option D is correct because enabling a system-assigned managed identity on the Azure App Service creates an identity in Azure AD tied to the app's lifecycle, and that identity can be granted access to Azure SQL Database (for example, by creating a contained database user with CREATE USER [app-name] FROM EXTERNAL PROVIDER and assigning db_datareader/db_datawriter roles), letting the app authenticate without storing any credentials in code. This is the recommended passwordless approach for App Service to Azure SQL. Option A still requires managing and referencing a client certificate, which is credential material rather than eliminating secrets.

Option B uses a service principal with a client secret, which is exactly the stored credential the scenario wants to avoid. Option C only restricts network access via firewall rules and does not provide authentication or authorization to the database.

Authorization Code Flow with PKCE (C) is correct because it is the recommended OAuth 2.0 flow for web applications that call Microsoft Graph on behalf of a signed-in user, exchanging the authorization code for delegated access and refresh tokens while PKCE protects the code exchange against interception. Implicit Flow (A) is deprecated for this purpose and returns tokens directly from the authorization endpoint without an authorization code, offering weaker security. Client Credentials Flow (B) is app-only and has no signed-in user, so it cannot act on behalf of a user.

Device Code Flow (D) is intended for input-constrained devices, not a standard web application with a browser-based sign-in.

Azure AD Workload Identity is the correct choice because it federates a Kubernetes service account with an Azure AD managed identity, allowing each pod to obtain Azure AD tokens without any stored secrets or certificates in the cluster. This directly satisfies the requirement that each microservice authenticates with its own identity and that no service principal secrets or certificates be stored. Option A is wrong because it still relies on a service principal secret stored in Key Vault and mounted into the cluster.

Option B is wrong because a node-level system-assigned managed identity is shared by all pods on the node, so it does not give each microservice its own identity. Option D is wrong because storing credentials in a Kubernetes secret violates the no-secrets requirement and is not identity-based authentication.

Sensitivity labels in Microsoft Purview Information Protection (E) are the core classification mechanism that lets you tag content containing PII so protection (encryption, marking, access restrictions) travels with the data across Microsoft 365 workloads. Microsoft Purview Data Loss Prevention (DLP) policies (D) automatically detect PII using sensitive information types and then block, warn, or audit risky sharing in Exchange Online, SharePoint, OneDrive, Teams, and endpoint locations. The Microsoft Purview Information Protection scanner (C) extends that same labeling and protection to on-premises file shares and SharePoint Server repositories, which is required for a complete PII detection and protection solution.

Azure Policy (A) governs Azure resource compliance and cannot classify or protect PII in Microsoft 365 content, and Microsoft Defender for Cloud (B) is a cloud security posture and workload protection service, not a data classification or DLP tool for Microsoft 365 PII.

Option A is correct because shared access signatures (SAS) let you delegate granular, time-limited access to specific blobs or containers, specifying exact permissions (read, write, etc.) and an expiry time, which directly satisfies the requirements for granular access control and automatic access expiration. Option E is correct because Azure Storage Service Encryption with customer-managed keys stored in Azure Key Vault provides encryption at rest where the customer controls the key lifecycle, meeting the customer-managed key requirement. Option B is not correct because enabling Azure AD authentication alone does not provide granular per-blob access or automatic expiry; it is an authentication mechanism, not an access delegation or expiration feature.

Option C is not correct because IP firewall rules restrict network access but do not provide granular blob-level permissions or automatic access expiration. Option D is not correct because the Storage Blob Data Reader role grants broad read access at the scope assigned and does not inherently expire, so it fails the granularity and automatic expiration requirements.

The correct option is B: it denies creation or update of storage accounts that do not enforce HTTPS traffic. An Azure Policy definition with a deny effect targeting the Microsoft.Storage/storageAccounts resource type and the supportsHttpsTrafficOnly property blocks any create or update request where that property is false or missing, enforcing secure transfer. Option A is wrong because the policy targets storage accounts, not virtual networks, and HTTPS enforcement is not a virtual network property.

Option C is wrong because the effect is deny, not audit, so noncompliant requests are blocked rather than merely logged. Option D is wrong because the policy scope is the storage account resource itself, not the blob service child resource.

The application is a line-of-business app used by employees and external partners, which implies it may be a public client (e.g., mobile or desktop) that cannot securely store a client secret. OAuth 2.0 authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended authentication pattern for such clients because it eliminates the need for a client secret by using a dynamically generated code verifier. This ensures the client secret is never exposed.

Option B is correct. Option A (system-assigned managed identity) is only suitable for Azure-hosted services, not client applications. Option C (storing client secret in Key Vault) still requires secret retrieval at runtime, which can be insecure for public clients.

Option D (implicit grant flow) is outdated and less secure than authorization code flow with PKCE.

Option A is correct because enabling App Service Authentication (EasyAuth) on the Function App enforces identity verification via Microsoft Entra ID or other identity providers before requests reach the function, providing strong authentication for HTTP triggers. Option B is correct because configuring network restrictions (access restrictions / IP allowlists) on the Function App limits inbound HTTP traffic to trusted IP ranges, reducing exposure to unauthorized or malicious callers. Option C is wrong because setting the authorization level to anonymous removes the function key requirement and allows unauthenticated access, weakening security.

Option D is wrong because Application Insights is a monitoring and telemetry service, not a security control. Option E is wrong because function keys alone are shared secrets that can be leaked and do not provide robust authentication or network-level protection.

Option A is correct because using OAuth 2.0 with Microsoft Entra ID lets the Azure Functions validate the bearer tokens issued to the mobile app, providing strong, identity-based authentication and enabling fine-grained authorization through app roles or scopes in a defense-in-depth model. Option C is correct because configuring Azure Cosmos DB with a private endpoint (via Azure Private Link) removes the database from the public internet and restricts traffic to the virtual network, adding a network-layer control that complements the identity-layer protection. Option B is not appropriate because IP whitelisting is brittle for a mobile app whose users connect from many dynamic addresses and does not authenticate the caller.

Option D is weaker than A because function-level authorization keys are shared secrets that are hard to rotate and do not provide user identity or scoped permissions. Option E is incorrect because TLS 1.0 is deprecated and insecure; TLS 1.2 or higher should be enforced.

Option C is correct because anomaly detection policies in Microsoft Defender for Cloud Apps are specifically designed to detect unusual user behavior—such as impossible travel, atypical download volumes, or suspicious admin activity—and can be tuned to alert on or automatically remediate risky activities in your SaaS environment. Option E is correct because enabling session monitoring (via Conditional Access App Control) for critical applications lets Defender for Cloud Apps inspect and control user sessions in real time, allowing it to block risky actions like downloads, uploads, or copy/paste based on session policies. Option A is not appropriate because blocking all third-party app access is an overly broad, disruptive measure rather than a targeted risky-activity detection and blocking configuration.

Option B does not belong because defining IP address ranges for trusted locations only informs risk evaluation and conditional access decisions; by itself it neither detects nor blocks risky user activities. Option D is incorrect because app discovery policies focus on identifying shadow IT and unsanctioned cloud apps from traffic logs, not on detecting and blocking risky user activities within sanctioned SaaS apps.

Option C is correct because the Azure Key Vault provider for the Secrets Store CSI driver mounts secrets from Azure Key Vault as volumes in AKS pods and supports auto-rotation via the secret rotation feature, which periodically re-fetches updated secrets and updates the mounted files without restarting the application. This satisfies the requirement for secure storage in Key Vault plus automatic rotation with no downtime. Option A is aimed at application configuration scenarios and does not natively mount or rotate secrets into AKS pods.

Option B stores secrets in Kubernetes Secrets, which are only base64-encoded and lack the managed rotation and centralized security of Key Vault. Option D injects secrets as environment variables, which cannot be updated in a running container without a pod restart, causing downtime.

The correct answer is C: a list of user accounts and computers where the account has more than 5 failed logins in the last 24 hours. This matches a typical Sentinel brute-force KQL pattern that filters SecurityEvent for EventID 4625 (failed logon), restricts the TimeGenerated window to the last 24 hours, and then summarizes failed attempts by Account and Computer, filtering with a threshold greater than 5. Option A is wrong because the grouping is by account and computer, not by computer alone, and it ignores the 24-hour time window.

Option B is wrong because it omits the per-computer grouping, so it would not return computer context. Option D is wrong because it references successful logins rather than failed logons (EventID 4625).

Option B is correct because the scenario explicitly requires encryption at rest with customer-managed keys (CMK) stored in Azure Key Vault, which is achieved by configuring the storage account to use CMK encryption referencing a Key Vault key. Option C is correct because restricting access to specific virtual networks requires configuring the storage account firewall (network rules) and enabling a virtual network service endpoint (Microsoft.Storage) on the designated subnets so traffic reaches the storage account over the Azure backbone. Option A is correct because the requirement that all access be logged is satisfied by enabling Azure Storage logging (diagnostic logging for read and write requests) for the blob service, capturing authentication and access details.

Option D is incorrect because Azure Files encryption at rest is unrelated to Blob Storage and does not address CMK, network restriction, or logging for blobs. Option E is incorrect because soft delete for blobs is a data-protection/recovery feature that retains deleted blobs; it does not provide encryption with CMK, network access control, or access logging.

The correct answer is C: create a Data Loss Prevention (DLP) policy to detect credit card numbers and block sharing. In Microsoft Purview, DLP policies are the built-in mechanism that inspects SharePoint Online content for sensitive information types such as credit card numbers and enforces protective actions like blocking external sharing or restricting access. This directly matches the requirement to automatically detect and protect credit card numbers in SharePoint Online documents.

Option A is incorrect because Azure Information Protection is a labeling/encryption client, not a policy engine that automatically detects sensitive data in SharePoint. Option B is incomplete because a sensitivity label alone does not automatically detect credit card numbers unless combined with auto-labeling conditions, and it does not block sharing. Option D is incorrect because Defender for Cloud Apps focuses on cloud app discovery, session controls, and anomaly detection rather than enforcing DLP rules on SharePoint content.

The correct option is B, a Scheduled query rule, because this rule type lets you write a KQL query against your log data (e.g., SecurityEvent or AuditLogs) and schedule it to run at defined intervals, which is exactly what's needed to detect user account creation events filtered by time-of-day and unusual source IP conditions. Scheduled query rules support custom detection logic, entity mapping, and alert/incident generation, making them ideal for this scenario. Anomaly rules (A) are built-in templates that detect deviations from learned baselines and don't let you author arbitrary detection logic for specific conditions like account creation outside business hours.

ML Behavior Analytics rules (C) are also prebuilt Microsoft-defined detections for specific behaviors, not customizable queries. Fusion rules (D) correlate multiple signals across products to detect multi-stage attacks and are not designed for a single custom condition like this.

Option B is correct because requiring TLS for all Cosmos DB connections enforces data encryption in transit, protecting data as it moves between clients and the service. Option D is correct because enabling encryption at rest with customer-managed keys ensures stored data is encrypted and gives the organization control over the key lifecycle, satisfying the encryption-at-rest requirement. Option E is correct because enabling diagnostic logging for Cosmos DB captures data-plane and control-plane operations, providing the audit trail needed to monitor and audit all data access.

Option A is incorrect because replacing Cosmos DB with Azure SQL Database does not meet the stated application requirement to use Cosmos DB and does not by itself address all three security controls. Option C is incorrect because Azure AD authentication addresses identity and access control, not encryption at rest, encryption in transit, or auditing of data access.

The correct option is C: Delegated permissions with User.Read. Delegated permissions let the app act on behalf of the signed-in user, and User.Read is the least-privileged Microsoft Graph scope that allows reading the signed-in user's own profile, satisfying the requirement for minimal data access. Option A is unnecessary because admin consent for all scopes grants far broader access than needed.

Option B is wrong because application permissions run without a signed-in user and typically require broader tenant-wide access. Option D is excessive since User.Read.All allows reading all users' full profiles, not just the current user's minimal data.

Option D is correct because Transparent Data Encryption (TDE) with customer-managed keys (CMK) in Azure Key Vault encrypts Azure SQL Database data at rest, and TDE supports point-in-time restore (PITR) via automated backups while allowing automatic key rotation through the Key Vault key rotation policy. Configuring TDE with a CMK satisfies the requirement that the encryption key be customer-managed and rotated every 90 days. Option A is wrong because service-managed keys do not meet the customer-managed key requirement, and Azure Policy cannot itself rotate TDE protector keys.

Option B is wrong because Always Encrypted protects data in use and in transit at the client, not data at rest as required, and manual rotation does not meet the 90-day automated rotation need. Option C is wrong because Azure Storage Service Encryption applies to Azure Storage, not Azure SQL Database, and soft delete is a Key Vault data-protection feature, not a database encryption solution.

It provides encryption at rest with a customer-managed key (CMK) stored in Azure Key Vault, a private endpoint to restrict access to the company's virtual network, and Azure RBAC with the Storage Blob Data Contributor role for both the Machine Learning workspace and data scientists, ensuring Azure AD authentication. Option A is wrong because firewall rules using IP ranges are less secure than private endpoints, and granting access via storage account access keys bypasses Azure AD authentication. Option B is wrong because it uses a service-managed key, which does not meet the customer-managed key requirement.

Option D is wrong because a service endpoint is less secure than a private endpoint, and using a SAS token does not provide Azure AD-based access control.

Option D is correct because the ARM template does not define any network rules (such as a virtual network rule or IP firewall rule) for the storage account, so the storage endpoint remains reachable from the internet; however, since public blob access is not enabled, anonymous access is denied and only authenticated requests with valid credentials or SAS tokens can succeed. This means the container is not publicly accessible in the anonymous sense, but the lack of network restrictions still exposes the endpoint to authenticated access from any network. Option A is wrong because nothing in the template enables anonymous public access to the container.

Option B is wrong because versioning is a data-protection feature, not a public-access control, and it is not the security implication being asked about. Option C is wrong because encryption at rest is enabled by default for Azure Storage and is unrelated to whether the container is publicly reachable.

You can configure a DLP policy in Microsoft Purview to block sensitive data like credit card numbers in Teams messages, and use the 'Block sharing to external users except' condition to allow sharing with approved domains. This meets the requirement to prevent sharing with unauthorized external users while allowing sharing with approved vendors. Option B is wrong because blocking all external sharing is too restrictive and does not allow the approved external vendors.

Option C is wrong because Information Protection labels do not have the granular control over sharing conditions based on external domains. Option D is wrong because sensitivity labels are not designed for DLP actions such as blocking sharing in Teams chat based on external approval.

Microsoft Purview Data Loss Prevention (DLP) policy for Exchange Online is the correct choice because DLP is purpose-built to inspect email content in transit and detect sensitive information types such as credit card numbers, then automatically block or restrict the message per policy actions. It natively integrates with Exchange Online so detection and blocking happen at the mail-flow level without user intervention. Sensitivity labels with auto-classification apply classification and protection to content but do not themselves block an email from being sent externally based on credit card detection.

Safe Attachments focuses on malware detonation in attachments, not on detecting sensitive data patterns, and the AIP unified labeling client is a client-side labeling tool rather than a server-side email blocking control.

The correct answer is C, Session policy. In Microsoft Defender for Cloud Apps, session policies are used with Conditional Access App Control to monitor and control user sessions in real time, including blocking downloads of sensitive files from Microsoft 365 when accessed from unmanaged devices. This is the specific policy type designed for session-based enforcement, such as blocking downloads, uploads, or copy/paste actions during an active session.

A file policy (A) applies to files in connected cloud apps for governance and alerting but does not control live session actions like downloads from unmanaged devices. A DLP policy in Microsoft 365 (B) enforces data protection within Microsoft 365 workloads but does not provide the same session proxy-based control for unmanaged device access. An access policy (D) in Defender for Cloud Apps is used to allow or block app access based on conditions, not to block downloads within an active session.

Azure Update Manager (option C) is the correct choice because it is the native Azure service designed to assess and automatically remediate missing OS security updates across Azure, on-premises, and multicloud servers, including those onboarded to Microsoft Defender for Servers. It provides update assessment, scheduling, and automatic patching for Windows and Linux machines, which directly addresses the team's need to remediate missing updates on their hybrid servers. Adaptive Application Controls (option A) only create allowlist/denylist rules for applications to control execution and do not patch operating systems.

Azure Automation Update Management (option B) is the legacy predecessor that has been superseded by Azure Update Manager, so it is not the recommended feature. Just-in-Time VM access (option D) only restricts inbound management ports on VMs and has nothing to do with update remediation.

Option D is correct because a DLP policy must reference a sensitive information type (SIT) — in this case the built-in 'Credit Card Number' SIT — so Purview can detect the credit card patterns in Exchange Online email content. Option C is correct because detection alone does nothing; the policy rule must define an action such as 'Block' (or restrict access/encrypt) to prevent the credit card data from being shared via email. Option A is incorrect because retention labels govern data lifecycle and retention, not real-time blocking of sensitive data sharing.

Option B is incorrect because auto-labeling policies apply sensitivity labels to content and do not enforce DLP blocking actions. Option E is incorrect because trainable classifiers are used for custom content categories (e.g., resumes, contracts), not for detecting standardized numeric patterns like credit card numbers, which are handled by built-in SITs.

Microsoft Purview Information Protection allows for classification and labeling of documents based on content, while Data Loss Prevention (DLP) policies can enforce actions such as blocking external sharing or applying encryption. Together, they provide automated protection for sensitive documents like those containing PII. Option D is correct because these two services work together to classify and protect documents.

Option A is incorrect because Microsoft Defender for Cloud Apps focuses on SaaS app security and Intune is for device management; they do not directly classify documents. Option B is incorrect because Compliance Manager is for managing compliance posture, and Sentinel is a SIEM; they are not used for automatic document classification. Option C is incorrect because Azure Information Protection is a previous version, now part of Purview, and Microsoft Entra ID is an identity service; they do not provide the same integrated classification and DLP capabilities as the Purview solutions.

Azure Monitor and Microsoft Sentinel (option D) are the right combination because Azure Monitor collects and retains the logs and metrics from the application and its Azure resources, while Microsoft Sentinel ingests those logs to correlate events, detect unauthorized access attempts to cardholder data, and generate alerts via analytics rules and incident creation, satisfying PCI DSS logging and monitoring requirements. Azure Monitor provides the telemetry pipeline (Log Analytics workspace, diagnostic settings) and Sentinel adds SIEM/SOAR detection and alerting on top of it. Option A is wrong because Azure Policy enforces configuration compliance and Defender for Cloud Apps is a CASB for SaaS discovery/control, not a log-monitoring and alerting SIEM.

Option B is wrong because Azure Policy and Defender for Cloud provide posture management and threat protection but do not deliver the centralized log correlation and custom alerting on access to cardholder data that Sentinel does. Option C is wrong because Azure Key Vault only manages secrets, keys, and certificates, and Defender for Cloud alone does not provide the required log aggregation and alerting.

The correct answer is D: iOS line-of-business app deployment in Intune. Intune supports deploying custom in-house iOS apps via the iOS LOB app type, which uploads the signed .ipa file and installs it on enrolled devices without requiring the public App Store, matching the scenario of an enterprise-certificate-signed LOB app. Option A (Android Enterprise managed Google Play) is for Android apps distributed through managed Google Play, not iOS.

Option B (VPP token) is used for purchasing and distributing App Store apps in volume, not for custom in-house iOS apps. Option C (Microsoft Store for Business) distributes Windows apps and is unrelated to iOS deployment.

Auto-labeling policies (option A) are the correct choice because they can automatically apply sensitivity or retention labels to documents in Microsoft 365 services such as SharePoint, OneDrive, and Exchange when content matches specified conditions, including sensitive information types like PII. They are designed specifically for automatic classification and labeling at scale, which matches the requirement to classify PII-containing documents and apply a retention label. Trainable classifiers (option B) can identify content based on examples, but they are used to detect custom content types and still require a labeling policy to apply labels, so they are not the primary feature for this scenario.

Manual labeling (option C) requires user intervention and does not meet the need for automatic classification. DLP policies (option D) can detect and protect sensitive information, but they do not apply retention labels; they enforce actions like blocking or notifying.

Option B is correct because Microsoft Defender for Cloud's container registry scanning (Defender for Containers) integrates natively with ACR to scan images on push, and a GitHub Actions step can query the scan results via the Azure CLI/REST API and fail the pipeline when critical vulnerabilities are detected. This directly satisfies the requirement to block deployment when critical findings exist. Option A does not fit because Azure Policy enforces governance on deployed resources and cannot fail a GitHub Actions build step based on scan results.

Option C is wrong because Azure Bastion is a managed jump-host service for RDP/SSH access, not an image scanner. Option D is wrong because Azure Security Center is the legacy name for Defender for Cloud and, by itself, does not provide the pipeline-failing GitHub Actions integration described in B.

The correct option is D: use a managed identity assigned to the playbook to authenticate to Azure SQL. In Microsoft Sentinel, playbooks are Logic Apps, and when they need to access Azure SQL Database, the recommended approach is to assign a managed identity to the playbook and grant that identity the appropriate database permissions, so no credentials are stored and access is scoped to the playbook. This directly protects sensitive data by ensuring only the authorized playbook identity can authenticate to Azure SQL.

Option A (dynamic data masking) limits data exposure in query results but does not control which principals can access the database. Option B (CMK for TDE) protects data at rest via encryption key management, not playbook authorization. Option C (SQL firewall rules for Sentinel IPs) is impractical because Sentinel playbooks run as Logic Apps without a fixed, reliable set of Sentinel IP addresses, and firewall rules alone do not authenticate the playbook.

Option C is correct because Azure Application Gateway with WAF provides a web application firewall that can inspect incoming HTTP/HTTPS traffic and block common SQL injection patterns using OWASP rule sets before requests reach the application or database. Option D is correct because parameterized queries in the application code ensure user input is treated as data rather than executable SQL, which is the primary defense against SQL injection at the application layer. Together, these two components satisfy both stated requirements: a WAF and parameterized queries.

Option A, Azure SQL Database firewall rules, only controls which IP addresses or Azure services can connect to the database and does not inspect query content for injection attacks. Option B, Transparent Data Encryption (TDE), encrypts data at rest and does not prevent SQL injection or filter malicious queries.

The correct answer is C: Accounts that had more than 10 failed logon attempts in the last 7 days. This is because the KQL query filters SigninLogs for failed sign-in results (e.g., ResultType != 0 or ResultType == 50126) and summarizes the count by user over a 7-day window, returning accounts whose failure count exceeds 10. Option A is wrong because account lockout is a specific event/status (e.g., ResultType 50053) and the query counts failures rather than lockout events.

Option B is wrong because the query aggregates by account, not by computer or source IP address. Option D is wrong because the query targets failed logons, not successful sign-ins.

Auto-labeling policies (option A) are the correct choice because they are the Microsoft Purview feature designed to automatically apply sensitivity labels to content that matches specified conditions, such as documents containing credit card numbers detected via sensitive information types. This directly satisfies the compliance officer's requirement to apply a 'Confidential' label automatically without user intervention. Data loss prevention policies (B) can detect and block or warn about sensitive content but do not apply sensitivity labels.

Trainable classifiers (C) can identify content categories by example, but they are used as conditions within labeling or DLP, not as the labeling mechanism itself. Manual labeling (D) requires users to apply labels themselves, which does not meet the automation requirement.

The correct answer is A: an App protection policy (MAM) with 'Restrict cut, copy, and paste'. App protection policies in Intune operate at the app layer, so they can block copying corporate data from Microsoft 365 apps into personal apps on the same device, even on unmanaged or BYOD devices. This directly addresses the requirement to prevent data leakage between managed and personal apps.

Option B (Conditional Access requiring a compliant device) controls access to resources but does not prevent copy/paste between apps. Option C (device configuration profile with restrictions) applies device-level settings and cannot selectively govern app-to-app data sharing. Option D (device compliance policy) only evaluates and reports device state; it does not enforce app-level copy/paste restrictions.

Azure Web Application Firewall (WAF) policy on Azure Front Door (option C) is correct because WAF is specifically designed to inspect HTTP/HTTPS traffic and block Layer 7 attacks such as SQL injection and cross-site scripting using managed rule sets (OWASP rules). Azure Front Door provides global edge delivery and integrates WAF policies directly, making it the appropriate choice for protecting a public web application. Azure Firewall (A) is a Layer 3-4 network firewall with limited FQDN filtering and does not provide OWASP-style web attack protection.

Azure DDoS Protection (B) mitigates volumetric and protocol-level attacks, not application-layer injection or scripting attacks. NSGs (D) filter traffic by IP, port, and protocol at the network layer and cannot inspect HTTP payloads for SQLi or XSS.

Microsoft Purview Data Map is the correct choice because it is the component that scans and automatically classifies data sources such as Azure SQL Database, detecting sensitive information types like credit card numbers and applying classifications. It builds the metadata catalog and applies built-in or custom classification rules during scans, which is exactly what's needed for automated sensitive-data discovery. Microsoft Defender for Cloud provides security posture management and threat protection, not data classification.

Microsoft Entra ID handles identity and access management, and Microsoft Sentinel is a SIEM/SOAR solution for security analytics, so neither performs data classification.

Option A is correct because enabling secret scanning in GitHub automatically detects committed credentials such as API keys and tokens, allowing them to be revoked before they can be exploited in the pipeline. Option D is correct because storing secrets in Azure Key Vault and referencing them through variable groups linked to Key Vault keeps credentials out of pipeline YAML and repository history, enforcing centralized access control and auditing. Option E is correct because branch protection rules in GitHub that require status checks prevent unreviewed or failing code from being merged, ensuring only validated commits reach the CI/CD pipeline.

Option B is incorrect because running all pipeline tasks with administrative privileges violates least privilege and expands the blast radius of a compromised task. Option C is incorrect because disabling pull request code reviews removes a critical human verification gate and increases the risk of malicious or flawed code being deployed.

A session policy (option A) is correct because in Microsoft Defender for Cloud Apps, session policies are used with Conditional Access App Control to monitor and control user sessions in real time, including blocking downloads of sensitive files from sanctioned cloud apps to unmanaged devices. Session policies can apply actions such as block download, protect, or block based on the sensitivity of the content and the device state. App discovery policies (option B) are used to identify and assess shadow IT and unsanctioned apps, not to control file downloads in real time.

Anomaly detection policies (option C) trigger alerts on unusual user behavior but do not enforce download blocking. Access policies (option D) in Defender for Cloud Apps are used to allow or block sign-ins to apps based on conditions, not to control in-session file download activity.

Option A is correct because Microsoft Purview sensitivity labels support auto-labeling policies that can use built-in sensitive information types (SITs) such as Credit Card Number, and the label itself can enforce encryption via the label's encryption settings when applied to documents in SharePoint Online. This directly satisfies the requirement to automatically label and encrypt PII-containing documents using built-in SITs. Option B is incorrect because retention labels govern retention/deletion, not encryption, and DLP policies do not apply retention labels.

Option C is incorrect because trainable classifiers are for custom content patterns, not built-in PII SITs like credit card numbers. Option D is incorrect because manual labeling does not meet the automatic labeling requirement.

Option D is correct because it satisfies all three requirements: enabling HTTPS-only on both apps enforces TLS, configuring the web app with Microsoft Entra ID authentication restricts access based on corporate identity, and using a system-assigned managed identity lets the API authenticate to Azure SQL Database without storing credentials. Managed identity works with Azure SQL via Entra ID authentication, so no password is needed in the connection string. Option A is wrong because Azure AD Domain Services-based Windows authentication is not the recommended App Service approach and SQL authentication with a managed identity is contradictory.

Option B is wrong because a username/password connection string does not use managed identity. Option C is wrong because client certificates do not provide corporate identity-based access and SQL authentication does not meet the managed identity requirement.

Input validation on all user inputs (B) is correct because it directly mitigates injection flaws such as SQL injection, command injection, and cross-site scripting (XSS) by rejecting or sanitizing untrusted data before it reaches interpreters or the browser. Content Security Policy (CSP) headers (C) are correct because they restrict which scripts, styles, and other resources the browser may load, providing defense-in-depth against XSS and data injection attacks listed in the OWASP Top 10. A Web Application Firewall (WAF) (D) is correct because it inspects HTTP/HTTPS traffic and blocks common attack patterns like SQLi, XSS, and path traversal, offering a compensating control for vulnerabilities that may not yet be patched in the application.

Role-Based Access Control (A) and Multi-factor authentication (E) are valuable identity and access management controls, but they address authentication and authorization concerns rather than the broad set of injection, misconfiguration, and client-side vulnerabilities targeted by the OWASP Top 10, so they are not among the three required controls here.

The Microsoft Entra ID connector (option A) is correct because it is the built-in Microsoft Sentinel data connector designed to ingest sign-in logs, audit logs, and other security events from Azure Active Directory / Microsoft Entra ID. Enabling it streams Entra ID diagnostic logs into the Sentinel workspace for analytics and detection. The Office 365 connector (B) ingests Exchange, SharePoint, and Teams activity logs, not Entra ID sign-in or audit events.

The Azure Activity connector (C) collects subscription-level control-plane operations from Azure Resource Manager, not directory events. The Microsoft Defender XDR connector (D) pulls alerts and incidents from Defender services rather than raw Entra ID security logs.

The correct answer is A: the policy is not enforced because user risk is not being evaluated (e.g., missing licenses or risk policy). For a Conditional Access policy that blocks high-risk users to work, Microsoft Entra ID Protection must actually compute user risk, which requires Entra ID P2 (or equivalent) licensing and the risk detections feeding the risk level; if risk is never evaluated, the condition never matches and high-risk users sign in. Report-only mode (C) would also let users through, but it is a deliberate configuration state rather than the most likely cause of risk-based enforcement silently failing, and the scenario implies the policy is intended to be active.

Options B and D are irrelevant here because client app types and locations are separate conditions that do not affect whether user risk is evaluated.

Option B is correct because private endpoints assign a private IP address from your virtual network to the Azure SQL Database and Storage account, so those PaaS services are reachable only through the private link and public network access can be disabled, satisfying the requirement to restrict network access to only the App Service (when the App Service is VNet-integrated). Option C is correct because a system-assigned managed identity gives the App Service an identity in Microsoft Entra ID, allowing it to authenticate to Azure SQL Database and Storage without storing credentials, which directly fulfills the managed-identity authentication requirement. Option A is incorrect because using a storage account access key in a connection string relies on a shared secret rather than a managed identity and exposes a highly privileged key.

Option D is incorrect because SAS tokens are shared secrets with delegated permissions, not managed-identity authentication, and they do not restrict network access to the App Service. Option E is incorrect because service endpoints only extend the VNet identity to the PaaS service over the Azure backbone; they do not give the SQL Database or Storage account a private IP, and the service still exposes a public endpoint, so they do not meet the strict 'only the App Service' network restriction as well as private endpoints do.

The correct option is C: an auto-labeling policy for sensitivity labels with encryption. In Microsoft Purview, auto-labeling policies scan SharePoint Online content for sensitive information types such as credit card numbers and automatically apply a sensitivity label; when that label is configured with encryption, the document is encrypted and the protection travels with the file even when shared with external users. Option A is wrong because a DLP policy that blocks sharing prevents external sharing rather than encrypting the document, and DLP does not itself apply encryption.

Option B is wrong because SharePoint IRM encrypts files at rest in the library and relies on the service to enforce permissions, but it does not automatically classify and encrypt documents based on sensitive content detection. Option D is wrong because a retention policy with a hold only preserves content for compliance and does not encrypt it.

The correct condition is A: trigger the high-severity incident when the user risk level is 'high'. In Microsoft Entra ID Identity Protection, user risk represents the probability that a given identity has been compromised, and a 'high' user risk is the strongest aggregate signal for an account-level compromise, making it the appropriate trigger for a high-severity Microsoft Sentinel incident. Option B is not the best fit because sign-in risk is scoped to a single authentication attempt rather than the overall user account.

Option C is too narrow, since 'leakedCredentials' is only one risk detection type and does not by itself indicate the highest severity. Option D is incorrect because 'medium' user risk is a lower severity than 'high' and would not justify a high-severity incident.

Option D is correct because the built-in policy definition audits whether SQL databases have transparent data encryption (TDE) enabled, and an audit-effect policy evaluates resources and flags non-compliant ones in the compliance report without blocking or modifying them. Since the assignment targets a resource group, it evaluates the SQL databases within that scope and marks those lacking TDE as non-compliant. Option A is wrong because audit policies do not remediate or enable TDE; that would require a DeployIfNotExists or Modify effect.

Option B is incorrect because 'audit' is the effect, not merely a reporting mode, and the policy still evaluates and flags resources. Option C is wrong because the assignment targets a resource group, not a management group, so its scope is limited to that resource group.

The best way to enforce that all Azure Storage accounts have secure transfer required enabled is to assign an Azure Policy initiative that includes the built-in policy 'Secure transfer to storage accounts should be enabled' with a 'Deny' effect (option C). Azure Policy is the native governance service that evaluates resource properties and can block non-compliant deployments, so a Deny effect prevents creation or modification of storage accounts that do not have secure transfer required enabled. A custom recommendation in Defender for Cloud (option A) only provides visibility and alerts; it does not enforce the setting.

Azure Blueprints (option B) can orchestrate policy assignments but is not itself the enforcement mechanism, and it is being deprecated in favor of template specs and deployment stacks. Granting the Storage Account Contributor role (option D) relies on manual action and does not guarantee enforcement.