CCNA Design security solutions for applications and data Questions

Option B is correct because configuring App Service authentication with Microsoft Entra ID (formerly Azure AD) enables the built-in Easy Auth middleware to authenticate users against the Entra ID identity provider, satisfying the requirement to use Azure AD for authentication. Option C is correct because a Conditional Access policy in Microsoft Entra ID can enforce MFA for all users and apply named locations or IP-based conditions to restrict access to specific IP ranges, meeting both the MFA and IP restriction requirements at the identity layer. Option A is not correct because an NSG applied to the App Service subnet only filters network traffic by IP/port at the network layer and does not provide Azure AD authentication or MFA.

Option D is not correct because Azure Firewall filters inbound/outbound traffic but does not perform user authentication or MFA enforcement. Option E is not correct because registering the application in Microsoft Entra ID only creates the identity object/service principal; it does not by itself enable authentication, IP restrictions, or MFA.

The correct option is B: Microsoft Entra entitlement management with an access package that grants read-only access to a SharePoint Online site. Entitlement management is designed for B2B collaboration, allowing external partner users from another Entra ID tenant to request and receive governed access to resources, and an access package can assign a read-only permission level (e.g., SharePoint Visitors/Read) so the partner can query but not modify PHI. Option A is wrong because Entra ID B2C is for customer-facing identity scenarios, not partner B2B collaboration, and a custom API would require you to build and enforce read-only authorization yourself.

Option C is wrong because Purview Information Protection labels and encrypts data but does not provide the partner query access or enforce read-only permissions. Option D is wrong because Azure DevOps repositories are for source code, not for sharing PHI with a partner organization.

The correct answer is A: the storage account creation is denied. Because the Azure Policy definition is assigned with the effect set to 'Deny', Azure Policy evaluates the resource request before deployment and blocks any storage account whose network rules use defaultAction set to Allow, so the create operation fails with a policy violation. Deny is a preventive enforcement effect, not a remediation or audit effect, so it stops the request rather than modifying the resource.

Option B is wrong because Azure Policy does not automatically rewrite network rules to deny all traffic, and option C is wrong because audit events are produced by the Audit effect, not Deny. Option D is wrong because Deny actively blocks the noncompliant creation instead of allowing it with no action.

Microsoft Defender for Cloud [CORRECT] is the right choice because it provides container image vulnerability scanning for images stored in Azure Container Registry and can be integrated into CI/CD workflows to gate deployments before production. It continuously assesses images and surfaces findings that Azure DevOps pipelines can act on. Azure Policy is for enforcing governance and compliance rules on resources, not for scanning container images for vulnerabilities.

Azure Key Vault manages secrets and keys, and Azure Monitor collects telemetry and logs, so neither performs vulnerability scanning.

Option C is correct because setting 'publicAccess' to 'None' on a blob container disables anonymous read access, and Azure AD (Microsoft Entra ID) authorization is always available for Blob Storage data-plane operations when a caller presents a valid OAuth 2.0 token with the appropriate RBAC role. No additional template property is required to enable Azure AD authentication; it is a service-level capability. Option A is wrong because disabling shared key access is an optional hardening step, not a prerequisite for Azure AD-only access.

Option B is wrong because 'Blob' or 'Container' publicAccess values actually permit anonymous read access, the opposite of the requirement. Option D is wrong because firewall rules restrict network origin, not the authentication method, and are not required to enforce Azure AD authorization.

The correct answer is D, a brute-force password guessing attack, because a logon failure event on a domain controller most directly indicates repeated or attempted authentication with incorrect credentials, which is the signature of password guessing. Brute-force attacks generate failed logon events (e.g., Windows Security Event ID 4625) as the attacker tries multiple passwords against an account. In contrast, a Kerberos golden ticket attack (A) forges a TGT using the KRBTGT hash and typically does not produce logon failures, and a DCSync attack (B) abuses directory replication permissions to extract password hashes, not to guess passwords.

A pass-the-hash attack (C) authenticates using a stolen NTLM hash and usually succeeds without failed logon attempts, so it does not match the failed-logon scenario.

Option D is correct because Microsoft Purview DLP policies can block sharing of sensitive information across workloads such as Exchange Online, SharePoint, OneDrive, and Teams, preventing users from sending or sharing content that matches a DLP rule. Option E is correct because DLP policies can display policy tips to users in supported apps (for example, Outlook, Word, Excel, and Teams), notifying them that content matches a rule and offering override or report options. Option A is not a native DLP action; encryption with Azure Information Protection is typically achieved through sensitivity labels or auto-labeling policies, not directly as a DLP policy action.

Option B is not a standard DLP action in Microsoft Purview; DLP can block, restrict access, or notify, but it does not quarantine files for administrator review. Option C is not a DLP policy action; automatically applying a sensitivity label is performed by auto-labeling policies in Microsoft Purview, not by DLP policies.

The correct answer is A: some resources are in a different resource group than expected. If the PowerShell script scopes its protection (for example, applying locks or policies) to a specific resource group, any resource tagged 'Confidentiality=High' that resides in another resource group is outside the script's scope and remains unprotected, which matches the symptom of some tagged resources still being unprotected. Option B is not the likely cause because the failure is about scope, not lock-detection logic.

Option C is incorrect because tag inheritance from resource groups is not the issue here—the resources already carry the tag. Option D is irrelevant because overwriting existing locks would not leave tagged resources unprotected.

The correct option is B: create a custom scan rule in Microsoft Purview and configure auto-labeling. Microsoft Purview is the data governance service that supports scanning Azure Data Lake Storage with custom classification rules (using regex or dictionaries) to detect PII such as email addresses, and its auto-labeling policies can then apply sensitivity labels automatically to matching content. Option A is wrong because Azure Policy enforces resource configuration and compliance, not content-level PII detection or sensitivity labeling.

Option C is wrong because Power Automate is a workflow automation tool and does not provide Purview's built-in classification scanning for Data Lake Storage. Option D is wrong because Microsoft Defender for Cloud focuses on security posture and threat protection, not data classification or sensitivity labeling.

Azure Key Vault with managed identities (option C) is correct because it provides a fully managed, cloud-native secrets store that integrates natively with Microsoft Entra ID, and managed identities let the AKS pods authenticate to Key Vault without storing credentials, minimizing administrative overhead. The application can retrieve database connection strings and API keys at runtime via the Key Vault SDK or the Secrets Store CSI Driver, so nothing is hardcoded. Kubernetes Secrets (A) are only base64-encoded and stored in etcd, lack Entra ID-based access control, and require manual rotation and RBAC management.

HashiCorp Vault on AKS (B) is powerful but self-managed, adding significant operational and administrative overhead. Azure App Configuration (D) is designed for application settings and feature flags, not for secure secret storage with Entra ID access control.

Key Vault automatic rotation with Event Grid integration (option A) is correct because it lets Key Vault rotate secrets on a schedule and emit near-real-time events (e.g., Microsoft.KeyVault.SecretNewVersionCreated) that the application can subscribe to, so it can fetch the new secret version before the old one expires and avoid downtime. Manual rotation (option B) requires an operator to create new secret versions, which cannot guarantee timely, zero-downtime rotation. Soft-delete (option C) only retains deleted vaults/secrets for recovery and does not rotate anything.

RBAC (option D) governs authorization to Key Vault operations but provides no rotation mechanism.

The correct answer is C: the policy denies creation or update of storage accounts that do not require HTTPS traffic. In Azure Policy, a Deny effect blocks the request at the resource provider during create or update operations when the resource does not satisfy the condition, so a storage account with supportsHttpsTrafficOnly set to false would be rejected. Option A is incorrect because Modify effects change properties via remediation and do not block the request.

Option B is incorrect because Audit only records non-compliance without preventing deployment. Option D is incorrect because DeployIfNotExists remediation tasks are triggered after evaluation and do not deny the original request.

Microsoft Entra application proxy (option B) is correct because it is designed to publish on-premises web applications, including legacy apps without modern authentication support, and enforce Entra ID pre-authentication plus conditional access before traffic reaches the app, while also providing access logging for auditing. It fits the zero-trust scenario by brokering remote access through the Application Proxy connector without exposing the app directly to the internet. Azure AD B2C (option A) is for customer identity and access management for consumer-facing apps, not for securing internal legacy on-premises apps.

Microsoft Defender for Cloud Apps (option C) is a CASB for discovering, monitoring, and controlling cloud app usage, not for publishing and pre-authenticating on-premises web apps. Microsoft Intune (option D) is for device and mobile application management, not for brokering authenticated access to legacy on-premises web applications.

Option A is correct because deploying AKS as a private cluster with no public endpoint removes the API server's public exposure, ensuring all control-plane communication stays on the private network and reducing the PCI DSS attack surface. Option B is correct because Always Encrypted protects sensitive cardholder data columns in Azure SQL Database by keeping encryption keys outside the database engine, so even DBAs or compromised SQL instances cannot read plaintext data. Option D is correct because private endpoints for Azure SQL Database and Azure Cache for Redis route traffic over Azure Private Link, keeping data off the public internet and satisfying PCI DSS network segmentation and encryption-in-transit expectations.

Option C is not among the required three because Azure RBAC for Kubernetes authorization is a general access-control hardening measure, not a PCI DSS-specific control for protecting cardholder data in this scenario. Option E is incorrect because disabling TLS on Azure Cache for Redis exposes data in transit and directly violates PCI DSS encryption requirements for cardholder data.

The correct option is D, OAuth 2.0 authorization code flow with PKCE, because it is the recommended flow for customer-facing web applications that authenticate users interactively via Microsoft Entra ID and call Microsoft Graph on their behalf. With PKCE, the client proves possession of a one-time code verifier, and the user authenticates directly against Entra ID, so the application never handles or sees user passwords. The resulting delegated access token also allows reading user profiles through Microsoft Graph with the appropriate scopes.

Option A (implicit grant) is deprecated and exposes tokens in the browser URL fragment, while option B (device authorization flow) is intended for input-constrained devices and is not suited to a normal web app. Option C (client credentials grant) is app-only authentication with no user context, so it cannot authenticate users or read their profiles as required.

The correct answer is B: the policy's block condition requires both user risk and sign-in risk to be high, so a user with high user risk but low sign-in risk would not be blocked as intended. In Microsoft Entra Conditional Access, user risk and sign-in risk are separate conditions, and if the JSON combines them so that both must be 'high' for the block to apply, the policy fails to block all high-risk users. The intended design should block when user risk is high, regardless of sign-in risk, or use separate grant controls for medium-risk MFA and high-risk block.

Option A is wrong because report-only mode would not enforce MFA or blocking at all. Option C is wrong because the scenario describes a logic problem, not invalid JSON syntax. Option D is wrong because combining conditions with 'Or' would make the policy broader, not narrower, and would not explain the failure to block high-risk users.

Option B is correct because Azure Data Lake Storage Gen2 supports Azure RBAC role assignments, such as Storage Blob Data Contributor, Storage Blob Data Reader, and Storage Blob Data Owner, to authorize security principals (users, groups, service principals, managed identities) at the container or account scope. Option C is correct because ADLS Gen2 implements a POSIX-like ACL model at the directory and file level, allowing fine-grained read, write, and execute permissions for named users and groups in addition to RBAC. Option A is not a valid authorization method here; IP firewall rules are network-level access restrictions, not an authorization mechanism for data access.

Option D is not itself an authorization method—managed identities are an identity type that must still be granted access via RBAC or ACLs. Option E is not the intended answer because SAS tokens are a delegation mechanism primarily associated with Blob Storage and are not the standard authorization approach for ADLS Gen2 hierarchical namespace access via RBAC and ACLs.

Option B is correct because Azure Key Vault is the dedicated Azure service for centrally storing and managing secrets such as API keys, with encryption at rest and fine-grained access policies, so pipeline code never contains the secret values. Option C is correct because Azure DevOps variable groups can be linked to Azure Key Vault, which lets pipelines consume Key Vault secrets as variables at runtime without duplicating or hardcoding them in the pipeline definition. Option E is correct because managed identities for Azure resources give the pipeline or compute an automatically managed identity in Microsoft Entra ID, allowing it to authenticate to Key Vault without storing credentials, which directly supports controlled access to production resources.

Option A is not correct because pipeline variables with encryption enabled still store the secret within Azure DevOps rather than in a dedicated vault, lacking Key Vault's centralized governance, rotation, and auditing. Option D is not correct because a configuration file in a private Git repository still places secrets in source control, which is exactly the practice the scenario requires avoiding.

Conditional Access App Control is the correct answer because it enables real-time session monitoring and control over sanctioned cloud apps, allowing you to block data exfiltration actions such as downloads, copy/paste, and uploads via reverse proxy integration with Azure AD Conditional Access. It is specifically designed for inline enforcement on user sessions, which matches the requirement to block exfiltration in real time. IP address ranges are used for defining corporate network boundaries in Cloud Discovery, not for session-level blocking.

Cloud discovery only identifies shadow IT usage from logs and does not enforce real-time controls. App connectors provide API-based visibility and governance for sanctioned apps but do not block user actions in real time.

Option A is correct because the OAuth 2.0 authorization code flow with PKCE is the recommended pattern for interactive web applications that sign users in through Microsoft Entra ID and then call a downstream API on the user's behalf; PKCE protects the authorization code exchange against interception, and the resulting access token is presented to the API. Option B is correct because confidential client applications still need credentials (client secrets or certificates), and Azure Key Vault provides centralized, access-controlled, audited storage for those secrets instead of leaving them in code or config. Option C is wrong because storing secrets in app configuration files exposes them to anyone with file or repository access and is not a secure secret-management practice.

Option D is wrong for this scenario because the client credentials flow is a daemon/app-only flow with no user context, so it cannot authenticate interactive users. Option E is wrong because shared access signatures are an Azure Storage authorization mechanism, not an authentication protocol for a Microsoft Entra ID-protected web API.

Data Loss Prevention (DLP) policies in Microsoft Purview are the correct choice because they can inspect email content for sensitive information types such as credit card numbers and trigger protective actions like encryption and user notifications. DLP rules support conditions based on sensitive info types and actions including encrypting messages and sending policy tips or notifications to the sender. Sensitivity labels apply protection based on manual or auto-labeling, but they do not natively detect credit card numbers in transit and send user notifications in the same rule-based way.

Audit log policies only record activity for later review, and insider risk management policies focus on detecting risky user behavior rather than automatically encrypting an email containing a credit card number.

The correct option is A: Azure SQL Database connector and a custom scheduled query rule with geo-location. The Azure SQL Database connector ingests SQL audit and diagnostic logs into Microsoft Sentinel, which include client IP addresses, so a custom scheduled analytics rule can parse those IPs, enrich them with geo-location data (e.g., via the GeoIP watchlist or built-in functions), and alert on access from unusual regions. Option B does not fit because Azure AD sign-in anomaly rules cover identity authentication events, not direct database access.

Option C is wrong because Windows Security Events cover OS-level logons on Windows hosts, not Azure SQL Database access. Option D is wrong because Azure Activity logs track control-plane operations like resource deletion, not data-plane SQL connections.

The correct option is A: Web Application Firewall (WAF) on Azure Front Door. A WAF inspects incoming HTTP/HTTPS traffic and applies managed rule sets (such as the OWASP Core Rule Set) to block common web exploits like SQL injection and cross-site scripting before they reach the App Service. Just-in-time (JIT) VM access (B) only brokers temporary, approved RDP/SSH access to virtual machines and has no bearing on web application layer attacks.

Adaptive Application Controls (C) are an Azure Security Center/Defender for Cloud feature that whitelists processes on VMs to detect anomalous execution, not HTTP payloads. Azure DDoS Protection (D) mitigates volumetric and protocol-level network floods, not application-layer injection attacks.

The correct option is B: create a DLP policy with the action 'Block with override' and enable 'Business justification'. This is the only configuration that both prevents users from sending credit card numbers in Outlook on the web and lets them override the block by supplying a business justification, which is exactly what the scenario requires. Option A ('Audit only') merely logs activity without stopping the email, so it does not prevent sharing.

Option C (encrypting emails) addresses confidentiality but does not block or notify the sender with an override path. Option D ('Block') stops the email but provides no override mechanism, so users cannot proceed with a justification.

Option D is correct because setting denyEncryptionScopeOverride to true on a container prevents clients from specifying a different encryption scope when uploading blobs, forcing them to use the container's default encryption scope. This property is specifically about locking the encryption scope at the container level, not about enabling or requiring encryption itself. Option A is wrong because double encryption is configured via infrastructure encryption settings, not this property.

Option B is wrong because encryption at rest is always enabled for Azure Storage blobs by default and is not controlled by denyEncryptionScopeOverride. Option C is wrong because customer-managed keys are configured through the account's encryption key source settings, not through this container property.

The correct option is A, OAuth app policies in Defender for Cloud Apps. These policies are purpose-built to detect risky or over-privileged OAuth apps and can automatically revoke user-granted permissions or disable the app when it matches conditions such as excessive scopes or low community use. Intune app protection policies (B) govern mobile app data handling (MAM) and do not revoke OAuth consent grants.

Conditional Access policies (C) control sign-in conditions and session access, not OAuth permission revocation. Azure AD app permissions management (D) allows reviewing and revoking consent grants manually but does not provide the automated, risk-based revocation that Defender for Cloud Apps OAuth app policies deliver.

Option C is correct because it states that the storage account uses customer-managed keys from Key Vault for encryption at rest and restricts network access to a specific virtual network, which exactly matches the company policy requirements. Customer-managed keys stored in Azure Key Vault satisfy the encryption-at-rest requirement, and a virtual network rule or service endpoint scoped to one VNet satisfies the network restriction. Option A is wrong because enabling encryption for blob and file services does not by itself address the customer-managed key or network restriction requirements.

Option B is wrong because it assumes Microsoft-managed keys, which contradicts the scenario where customer-managed keys are used. Option D is wrong because it claims network access is open to any virtual network, which is not the case when access is restricted to a specific VNet.

Option B is correct because assigning a system-assigned managed identity to the application and granting it the Key Vault Secrets User role provides an Azure AD-backed identity that can be authorized via RBAC to read secrets, eliminating stored credentials and enforcing least privilege. The Key Vault Secrets User role grants only read access to secret contents, which matches the requirement that only authorized applications access secrets. Option A is wrong because SAS tokens are not the managed identity mechanism for Key Vault and storing a token in an environment variable introduces a shared secret.

Option C is wrong because restricting inbound IP addresses controls network reachability, not application identity or least-privilege authorization. Option D is wrong because client certificate authentication does not use managed identities and requires certificate lifecycle management rather than Azure RBAC.

Option A is correct because Defender for Cloud Apps monitors and governs sanctioned SaaS apps such as Box and Dropbox by connecting them through an app connector (API connector), which uses the app's APIs and OAuth to pull activity logs, files, and user data for governance and control. Option D is correct because Conditional Access App Control (session control) uses Azure AD Conditional Access policies and a reverse proxy to enforce real-time session controls like block download, block upload, and read-only access for Box and Dropbox. Option B is incorrect because adding apps to the unsanctioned list only tags them in Cloud Discovery as unsanctioned; it does not enable monitoring or control of the apps.

Option C is incorrect because a forward proxy is not required; Cloud Discovery can use log upload or Defender for Cloud Apps log collectors, and session control uses a reverse proxy, not a forward proxy. Option E is incorrect because running a Cloud Discovery report only provides visibility into discovered apps and does not by itself enable monitoring and control of Box and Dropbox.

Security policies and initiatives in Microsoft Defender for Cloud are the correct choice because they let you define and assign Azure Policy definitions—such as the built-in 'Secure transfer to storage accounts should be enabled' policy—that continuously assess storage accounts and flag any that lack Secure transfer required (HTTPS-only). This directly addresses the requirement to ensure all storage accounts have secure transfer enabled. File integrity monitoring is incorrect because it tracks changes to OS files and registry keys on VMs, not storage account configuration.

Adaptive network hardening is incorrect because it generates NSG rules based on traffic analysis, and Just-In-Time VM access is incorrect because it restricts inbound VM ports on demand—neither evaluates storage account encryption-in-transit settings.

The correct option is B: Configure sensitivity labels in Microsoft Purview Information Protection. Copilot for Microsoft 365 honors the sensitivity labels applied to content, so labels must be defined and published through Microsoft Purview Information Protection (the current unified labeling platform) for Copilot to respect classification and protection settings such as encryption and content marking. DLP policies (A) enforce rules on sharing or handling of sensitive data but do not provide the classification metadata Copilot uses to respect sensitivity.

Azure Information Protection (C) is the legacy labeling client/service being retired in favor of Purview Information Protection, so it is not the configuration target. Retention labels (D) govern lifecycle and retention, not sensitivity-based protection, so they do not control how Copilot treats sensitive content.

Option B is correct because Microsoft Entra B2B collaboration lets partner users authenticate with their own organizational credentials and receive tokens from their home tenant, which the app can accept without creating user objects in your tenant. This directly satisfies the requirement to allow only specific external partner organizations while avoiding per-user objects in your directory. Option A is insufficient because IP-range restrictions do not identify or validate partner organizations and can be bypassed or misapplied.

Option C contradicts the requirement by creating guest user objects for each external user. Option D is wrong because Azure AD B2C is intended for customer-facing identity scenarios with local or social accounts, not for federating access with specific partner Microsoft Entra tenants.

Option E is correct because managed identities for Azure resources let Azure VMs and App Service apps authenticate to Key Vault without storing any credentials in code or configuration, which is the recommended, most secure authentication method for this scenario. Option D is correct because Key Vault's secret rotation can be automated by emitting near-expiration events to Event Grid, which triggers an Azure Function to generate and write a new secret version back into Key Vault, satisfying the automatic rotation requirement. Option A is not appropriate because service principals with client secrets require you to store and manage a credential, reintroducing the secret-management problem managed identities solve.

Option B is wrong because manual rotation via Azure Automation runbooks is not automatic rotation and adds operational overhead. Option C is wrong because storing secrets in application configuration files, even if encrypted with Key Vault, does not use Key Vault as the secret store and undermines centralized secure storage and rotation.

The correct option is D, Azure Monitor Agent (AMA). AMA is the current, supported agent for collecting data into Log Analytics workspaces, which back Microsoft Sentinel, and it supports Data Collection Rules (DCRs) to ingest Windows security events from on-premises Active Directory domain controllers via the Azure Arc-enabled servers or the AMA extension. The Microsoft Monitoring Agent (A) and the Log Analytics agent (B) are legacy agents that are deprecated for Sentinel data collection and are being replaced by AMA.

The Microsoft Defender for Cloud agent (C) is not a standalone log-ingestion agent for Sentinel; Defender for Cloud uses the Log Analytics/AMA agents for data collection, so it does not fit the requirement directly.

Option D is correct because Azure Cosmos DB supports encryption at rest with customer-managed keys (CMKs), which are created and stored in Azure Key Vault and then assigned to the Cosmos DB account via its encryption settings. This satisfies the requirement to control the key used for data-at-rest encryption rather than relying on Microsoft-managed keys. Option A is incorrect because Transparent Data Encryption (TDE) is an Azure SQL feature, not a Cosmos DB configuration.

Option B is incorrect because Azure Storage Service Encryption (SSE) applies to Azure Storage services, not Cosmos DB. Option C is incorrect because Always Encrypted is an Azure SQL Database/client-side encryption feature and does not configure CMK encryption for Cosmos DB.

Microsoft Purview can scan data sources like Azure Data Lake Storage and Azure SQL Database, classify sensitive data such as PHI, and auto-apply sensitivity labels. Azure SQL Database supports Azure AD authentication and row-level security (RLS) to restrict access to sensitive data based on user identity. Auditing logs can be sent to Log Analytics for compliance.

Option B is incorrect because it requires manual labeling and does not use row-level security. Option C uses Defender for Cloud (not Purview) and Always Encrypted (which does not prevent access to authorized users). Option D uses data masking (obfuscation) rather than access control and lacks auto-labeling and auditing integration.

The correct option is C: Create a private endpoint and associate it with the App Service. For an Azure App Service app to be reachable from a backend subnet over a private IP, a private endpoint must be created and linked to the app, which provisions a private IP in the target subnet via Azure Private Link. Option A is wrong because setting publicNetworkAccess to Enabled exposes the app publicly rather than providing private access.

Option B is wrong because regional VNet integration enables outbound traffic from the app into a VNet, not inbound private access to the app. Option D is wrong because IP-based SSL only binds a certificate to an IP address and does not create private connectivity.