Show the 21 questions and explanations
Contoso's Azure SQL Managed Instance has a server audit named CorpAudit that writes to blob storage through TO URL and captures logins and batches. Compliance now also needs a record of what Microsoft support engineers do when they access the instance during a support case, and CorpAudit must keep recording Contoso's own activity. What should the DBA do?
Correct answer: A. Create a second server audit with Microsoft support operations selected, leaving CorpAudit as is
The SQL Managed Instance auditing articles say Microsoft support operations are audited by selecting Microsoft support operations when you create an audit, and that it must be a separate server audit: enabling the option on an existing audit overwrites that audit so it logs only support operations. In T-SQL, the separate audit carries OPERATOR_AUDIT = ON, so CorpAudit keeps recording Contoso's own activity unchanged.
Why the other options are wrong:
- B. Select Microsoft support operations in CorpAudit's properties so that a single audit records both Turning the option on for an existing audit overwrites it, so CorpAudit would log only support operations and stop recording Contoso's activity.
- C. Add the DevOps operations Audit Logs category to a diagnostic setting, without creating a new audit A diagnostic setting only routes events from an audit that targets EXTERNAL_MONITOR; with no audit created for support operations, nothing is captured.
- D. Add FAILED_LOGIN_GROUP to CorpAudit's specification so that support engineers' sign-ins are captured Standard action groups record standard events; Microsoft support operations are captured only by an audit created with OPERATOR_AUDIT = ON.
Memory hook: Managed Instance support-ops audit: a separate server audit with OPERATOR_AUDIT = ON, never a checkbox on the existing one.
Microsoft Learn: Auditing configure
Litware deployed a security admin configuration from Azure Virtual Network Manager to the East US and West US regions. The target network group uses dynamic membership. A new virtual network in North Europe matches the policy condition and now shows as a group member, but none of the security admin rules apply to it. What should Litware do?
Correct answer: A. Deploy the security admin configuration to the North Europe region as well
A configuration takes effect only in the regions chosen when its deployment is committed. A network group can hold virtual networks from any region, but each member receives only the configurations applied to the group and deployed to that member's own region. Deploying the security admin configuration to North Europe adds it to that region's goal state. In East US and West US, new members already receive the deployed configuration without a redeployment.
Why the other options are wrong:
- B. Wait up to 24 hours for the eventual consistency model to apply the rules Eventual consistency covers a short delay where the configuration is deployed; North Europe has no deployment, so waiting never applies the rules.
- C. Add the virtual network to the group as a static member instead of a dynamic one Membership type isn't the gap: the network is already a member, and static and dynamic members alike get only what is deployed to their region.
- D. Redeploy the configuration to East US and West US to pick up the new member Redeploying to the same two regions leaves North Europe outside the goal state, so the new member still receives nothing.
Memory hook: Network group membership is global; deployments are regional.
Microsoft Learn: Concept deployments
After a network change, VMs in Fabrikam's application subnet can't reach an on-premises database at 192.168.10.20 over ExpressRoute. No NSG rules changed. The engineer suspects a user-defined route now sends that traffic to a retired network virtual appliance, and needs the next hop type, next hop IP address and route table ID for that destination. Which Network Watcher tool fits?
Correct answer: C. Next hop
The next hop overview describes a tool that returns the next hop type, IP address and route table ID for a specific destination IP. When a user-defined route matches, it names the route table that holds the route; otherwise it reports System Route. A VirtualAppliance result pointing at the retired appliance's address would confirm the misroute, which none of the security rule tools can show.
Why the other options are wrong:
- A. Effective security rules Effective security rules lists the security rules applied to a network interface; it shows nothing about routes or next hops.
- B. IP flow verify IP flow verify evaluates NSG and admin rules for a flow; the stem rules out a security rule change, and the tool reports nothing about routes.
- D. VPN troubleshoot VPN troubleshoot diagnoses virtual network gateways and their connections; it doesn't report the route a VM uses, and this path runs over ExpressRoute.
Memory hook: Where does this packet go next, and which route table says so? Next hop.
Microsoft Learn: Next hop overview
Tailspin Toys runs a TCP licensing service on virtual machines behind an internal Standard Load Balancer whose backend pool is configured by IP address. Customers in their own Microsoft Entra tenants must reach the service privately from their own virtual networks. Several customer address spaces overlap Tailspin's, and no other Tailspin subnet may become reachable. What should Tailspin do?
Correct answer: D. Switch to a NIC-based backend pool, create a Private Link service on the load balancer frontend, then share its alias.
The Private Link service overview lists two load balancer limits: it works only with Standard Load Balancer, and only where the backend pool is configured by NIC, not by IP address. With a NIC-based pool in place, the service fronts the load balancer, customers in other Microsoft Entra tenants connect through private endpoints in their own virtual networks, and destination-side NAT from a provider subnet keeps overlapping address spaces from conflicting.
Why the other options are wrong:
- A. Publish the service on a public load balancer frontend, then allow only the customers' public IP prefixes in an NSG rule. A public frontend carries customer traffic across the internet, which fails the requirement for private access from customer virtual networks.
- B. Peer each customer's virtual network with Tailspin's virtual network, then restrict the peered traffic with NSG rules. Peering is refused when address spaces overlap, and where it works it exposes the whole virtual network rather than a single service.
- C. Create a Private Link service on the existing load balancer frontend without changes, then share its alias with customers. The overview states Private Link service isn't supported on a Standard Load Balancer whose backend pool is configured by IP address, so the pool has to change first.
Memory hook: Private Link service: Standard Load Balancer, NIC-based backend pool, and NAT that absorbs overlapping addresses.
Microsoft Learn: Private link service overview
Adatum piloted point-to-site VPN on a route-based gateway that uses the Basic SKU. For production, users must authenticate through the company's existing NPS server by using RADIUS so that on-premises MFA applies. The team accepts a new gateway public IP address if one is needed. What should the engineer do?
Correct answer: C. Delete the Basic gateway, create a VpnGw1AZ gateway with a Standard SKU public IP address, and configure RADIUS
The Basic SKU doesn't support RADIUS authentication, so the gateway has to move to another SKU. The Upgrade a VPN Gateway SKU article lists Basic to any other SKU as delete and re-create only: remove the connections, delete the gateway, create the new one, update devices with the new public IP address, and download new client profiles. New VPN gateways must use a Standard SKU public IP address, and the RADIUS limit belongs to Basic, so a VpnGw1AZ gateway can use RADIUS.
Why the other options are wrong:
- A. Keep the Basic gateway and set its point-to-site authentication type to RADIUS by using Azure PowerShell cmdlets The Basic SKU is configured only through PowerShell or the Azure CLI, but no tool can enable RADIUS on it, because the SKU itself doesn't support RADIUS authentication.
- B. Upgrade the gateway in place to VpnGw1AZ from its Configuration page, and then set the authentication type to RADIUS In-place SKU upgrades exist for most gateways, which makes this attractive, but the upgrade article marks Basic to any other SKU as not eligible; the gateway must be deleted and re-created.
- D. Keep the Basic SKU but re-create the gateway as policy-based, and then point its point-to-site settings at the NPS server A policy-based Basic gateway supports a single IKEv1 site-to-site tunnel and no point-to-site at all, so this change removes point-to-site instead of adding RADIUS.
Memory hook: Basic means no RADIUS and no in-place upgrade: delete, re-create on an AZ SKU, reissue profiles.
Microsoft Learn: Gateway sku upgrade
Contoso's security admin configuration in Azure Virtual Network Manager targets a network group that includes VNet-Data, which hosts an Azure SQL Managed Instance. None of the configuration's rules reach VNet-Data, while other members enforce both Allow and Deny rules. Contoso wants the Allow rules enforced on VNet-Data without filing an exception request. What should Contoso do?
Correct answer: B. Deploy a security admin configuration whose applyOnNetworkIntentPolicyBasedServices is AllowRulesOnly
By default, security admin rules skip a virtual network that contains Azure SQL Managed Instance or Azure Databricks, because those services' network intent policies govern their traffic. The security admin rules page offers two ways around it: request an exception through Microsoft's form, or use a security configuration whose applyOnNetworkIntentPolicyBasedServices field is set to AllowRulesOnly, which applies only the Allow rules to such networks while Deny rules still skip them.
Why the other options are wrong:
- A. Change the configuration's Allow rules to Always Allow so that they outrank the network intent policy By default the skip covers every security admin rule on that network, whatever its action, so switching to Always Allow doesn't apply them.
- C. Add VNet-Data to the network group as a static member in addition to its current membership VNet-Data is already a member; it's skipped because it hosts a managed instance, and membership type doesn't change that.
- D. Move the Allow rules into a separate rule collection that targets only VNet-Data at priority 1 Neither rule collections nor priorities override the skip; only the configuration-level AllowRulesOnly setting changes it without an exception request.
Memory hook: SQL Managed Instance or Databricks in the network: admin rules skip it; AllowRulesOnly applies just the Allow rules.
Microsoft Learn: Concept security admins
Litware runs VM2 in Subnet-App. NSG-Subnet, associated with Subnet-App, has an inbound rule at priority 200 that allows TCP 443 from the Internet service tag. NSG-NIC2, associated with VM2's network interface, has only the default rules. Internet clients still can't open HTTPS sessions to VM2's public IP address. What should the engineer do?
Correct answer: B. Add an inbound rule to NSG-NIC2 that allows TCP 443 from the Internet service tag
For inbound traffic, Azure processes the subnet NSG first and then the NIC NSG, and each must allow the flow. NSG-Subnet allows TCP 443, so the packet moves on to NSG-NIC2, where no custom rule allows it and the DenyAllInbound default rule at priority 65500 drops it. The How network security groups filter network traffic page says that to permit a port to a VM with NSGs at both levels, both NSGs need a rule that allows it, so the fix is an allow rule in NSG-NIC2.
Why the other options are wrong:
- A. Change the NSG-Subnet rule's priority from 200 to 100 so that Azure processes it sooner Priority orders rules only inside one NSG, and the subnet rule already matches and allows the traffic; the drop happens afterward, in NSG-NIC2.
- C. Delete the DenyAllInbound default rule from NSG-NIC2 so that the subnet rule's decision stands Default rules can't be deleted; they can only be overridden by a custom rule with a lower priority number.
- D. Add an outbound rule to NSG-NIC2 that allows the TCP 443 return traffic to the internet NSGs are stateful: the flow record lets the response leave without an outbound rule, so a return-traffic rule changes nothing.
Memory hook: Inbound: subnet NSG, then NIC NSG; both must say allow.
Microsoft Learn: Network security group how IT works
Contoso's central network team uses Azure Virtual Network Manager. Its monitoring system in 10.100.5.0/24 must always reach agents on TCP 443 in every virtual network of a network group, even if a workload team later adds an NSG rule that blocks that traffic. What should the central team deploy?
Correct answer: B. A security admin rule with the Always Allow action for TCP 443 from 10.100.5.0/24
Security admin rules are evaluated before NSG rules. An Always Allow rule ends evaluation and sends matching traffic straight to the resource, so no NSG rule a workload team adds can block it. The security admin rules page describes Always Allow as allowing traffic regardless of lower-priority rules or user-defined network security groups, while an Allow rule passes the traffic on to NSG evaluation, where a deny still wins.
Why the other options are wrong:
- A. A security admin rule with the Allow action for TCP 443 from 10.100.5.0/24 Allow hands matching traffic on to the NSGs, so a workload team's deny rule would still block the monitoring traffic.
- C. An NSG rule at priority 100 in every workload NSG that allows TCP 443 from 10.100.5.0/24 Workload teams own their NSGs and can edit or delete this rule at any time, so an allow inside their NSGs guarantees nothing.
- D. A hub and spoke connectivity configuration that connects the monitoring network to each spoke A connectivity configuration builds the peering topology; it doesn't override NSG rules that block the traffic.
Memory hook: Always Allow and Deny end evaluation; plain Allow gives the NSG the last word.
Microsoft Learn: Concept security admins
Fabrikam's Azure Virtual Network Manager instance is scoped to its root management group, which holds 400 subscriptions. Every virtual network tagged Environment=Prod, including networks created next year, must receive the production security admin configuration without anyone adding networks by hand. What should the network team configure?
Correct answer: C. A network group with dynamic membership from an Azure Policy that uses the addToNetworkGroup effect
Dynamic membership lets Azure Policy evaluate a condition such as a tag and place matching virtual networks in the network group through the addToNetworkGroup effect, in a custom definition whose mode is Microsoft.Network.Data. Networks created later join when they match. The configuration deployments page adds that membership changes take effect without redeploying the configuration, and below 1,000 subscriptions conditional membership updates within a few minutes.
Why the other options are wrong:
- A. A second network manager whose scope holds only the subscriptions that host tagged virtual networks A network manager's scope only sets which resources it can manage; virtual networks still need network group membership to receive configurations.
- B. An Azure Policy assignment with the deployIfNotExists effect that adds an NSG to each tagged subnet deployIfNotExists can deploy NSGs, but NSGs aren't the security admin configuration the requirement names, and the policy adds no network to a network group.
- D. A network group with static membership that lists every virtual network tagged Environment=Prod today Static members are picked by hand, so a virtual network created next year joins only when someone adds it.
Memory hook: Tag-driven, hands-off membership: Azure Policy with addToNetworkGroup.
Microsoft Learn: Concept Azure policy integration
Woodgrove Bank's security admin configuration, deployed to East US, has one rule collection that targets a network group of all virtual networks and holds a Deny rule for inbound TCP 3389 at priority 10. The jump-host team must now accept RDP into VNet-Jump from 10.50.0.0/24, and wants its own NSG to decide which hosts get it. What should the central network team do?
Correct answer: B. Add a rule collection for a VNet-Jump network group to the deployed configuration with an Allow rule for TCP 3389 from 10.50.0.0/24 at priority 5, and redeploy
A network manager deploys only one security admin configuration to a region, so more rules go into new rule collections inside it. The high-risk ports guide builds this exception: a network group for the excepted networks, a rule collection with an allow rule numbered lower than the blocking rule (1 to 9 against a Deny at 10), then a redeployment, since changes to a deployed configuration apply only after it is deployed again. Allow, unlike Always Allow, passes matching traffic on to NSG evaluation.
Why the other options are wrong:
- A. Create a second security admin configuration with an Allow rule for TCP 3389 from 10.50.0.0/24 at priority 5 for a VNet-Jump network group, and deploy it to East US Only one security admin configuration per network manager can be deployed to a region, so a second one can't run beside the first in East US.
- C. Add a rule collection for a VNet-Jump network group to the deployed configuration with an Always Allow rule for TCP 3389 from 10.50.0.0/24 at priority 5, and redeploy Always Allow ends evaluation and bypasses NSGs, so the jump-host team's NSG could no longer decide which hosts accept RDP.
- D. Have the jump-host team add an NSG rule that allows TCP 3389 from 10.50.0.0/24 at priority 100 on the VNet-Jump subnet, and leave the configuration as it is The Deny security admin rule ends evaluation before any NSG rule runs, so an NSG allow can't rescue the traffic.
Memory hook: Exception to an admin Deny: lower number, new rule collection, same configuration, redeploy.
Microsoft Learn: Block high risk ports
During a review, Contoso finds that a container in a production storage account has its anonymous access level set to Container. The security team wants one change that blocks anonymous reads of every container in the account and prevents anyone from enabling anonymous access on a container later. What should they configure?
Correct answer: A. Set Allow Blob anonymous access to Disabled on the storage account.
Setting AllowBlobPublicAccess to false, shown in the portal as Allow Blob anonymous access set to Disabled, overrides every container's setting: Azure Storage rejects all anonymous read requests, containers already configured for anonymous access stop accepting them, and users cannot configure anonymous access on a container afterward. The Remediate anonymous read access article notes the change can take up to 30 seconds to propagate and does not affect the $web container.
Why the other options are wrong:
- B. Assign an Azure Policy definition that audits anonymous access settings. An audit effect only reports noncompliant accounts; it neither blocks anonymous reads nor stops anyone from changing a container's setting.
- C. Set the anonymous access level of every container to Private. Setting each container to Private closes today's exposure, but while the account still allows anonymous access, a user with the right permissions can set a container back to Blob or Container.
- D. Set Allow storage account key access to Disabled on the storage account. Disallowing Shared Key blocks key-signed requests; anonymous requests carry no authorization and still proceed when the account and container allow them.
Memory hook: Account-level anonymous access set to Disabled beats every container setting.
Microsoft Learn: Anonymous read access prevent
Adatum must let VMs in Subnet-Batch reach Azure Storage in the East US region over TCP 443 and block every other outbound connection to the internet, without maintaining lists of IP addresses. NSG-Batch, associated with Subnet-Batch, has only the default rules. Which outbound rules should the engineer add to NSG-Batch?
Correct answer: D. Allow TCP 443 to the Storage.EastUS service tag at priority 100, then deny all traffic to the Internet service tag at priority 110
The Storage tag supports regional scope, so Storage.EastUS covers only East US storage ranges and stays current as Microsoft changes them. Learn's service tags overview says the Internet tag includes Azure-owned public IP space, so the storage allow needs the lower priority number to be processed first. A custom deny for Internet is required because the AllowInternetOutBound default rule at 65001 is processed before DenyAllOutBound at 65500.
Why the other options are wrong:
- A. Allow TCP 443 to the Storage.EastUS service tag at priority 100, and rely on the DenyAllOutBound default rule for the rest AllowInternetOutBound at priority 65001 is processed before DenyAllOutBound at 65500, so all other internet traffic would still leave the subnet.
- B. Allow TCP 443 to the Storage service tag at priority 100, then deny all traffic to the Internet service tag at priority 110 The global Storage tag covers storage in every region, which breaks the requirement to block everything except East US storage.
- C. Deny all traffic to the Internet service tag at priority 100, then allow TCP 443 to the Storage.EastUS service tag at priority 110 The Internet tag includes Azure-owned public IP addresses, so the deny at priority 100 matches the storage traffic first and the allow is never reached.
Memory hook: Narrow allow first, broad Internet deny second; outbound, the defaults allow the internet at 65001.
Microsoft Learn: Service tags overview
Litware's Azure Firewall Standard uses a Firewall Policy with one rule collection group. An application rule collection at priority 100 denies *.contoso.com over HTTPS from the workload subnet. A network rule collection at priority 300 allows TCP 443 from the workload subnet to any destination. A workload VM opens www.contoso.com over HTTPS. What happens?
Correct answer: A. The connection is allowed, because network rules are processed before application rules whatever the collection priorities.
The Azure Firewall rule processing article states that application rules are always processed after network rules, and network rules after DNAT rules, regardless of rule collection group priority, rule collection priority or policy inheritance. Rules are terminating, so once the network rule allowing TCP 443 matches, processing stops and the application rule that denies *.contoso.com is never evaluated.
Why the other options are wrong:
- B. The connection is denied, because traffic on TCP 443 is evaluated only against application rules, never network rules. Network rules match TCP and UDP traffic on any port, 443 included; application rules are evaluated only when no network rule has matched.
- C. The connection is denied, because the firewall evaluates deny actions before allow actions within a rule collection group. Azure Firewall has no deny-first pass: collections run by rule type and then by priority, and the first matching rule ends processing.
- D. The connection is denied, because the application rule collection has the lower priority number and is processed first. Priority numbers order collections only within one rule type; a lower-numbered application collection still runs after every network collection.
Memory hook: DNAT, then network, then application: priority numbers never jump the rule-type order.
Microsoft Learn: Rule processing
Adatum stores national ID numbers in a column of an Azure SQL Database table. Compliance requires that privileged users, including the server admin, the Microsoft Entra admin and members of db_owner, can never read the plaintext values, while the HR application must still read and write them. Which feature should the security engineer implement?
Correct answer: D. Always Encrypted on the column, with the column master key kept in Azure Key Vault
The Azure SQL security overview describes Always Encrypted as protecting specific columns, such as national identification numbers, from database administrators and other privileged users who have no business need to see the data. Values are decrypted only by client applications that can reach the encryption key, which is never exposed to the database engine, so the HR application keeps working while administrators see only ciphertext.
Why the other options are wrong:
- A. Row-level security, with a filter predicate that hides those rows from administrators Row-level security filters which rows a query returns rather than protecting a column's values, and it doesn't encrypt anything.
- B. Transparent data encryption, with a customer-managed TDE protector in Azure Key Vault TDE protects data files and backups at rest; queries still return plaintext to authorized users, administrators included, whoever manages the key.
- C. Dynamic data masking on the column, with UNMASK granted only to the HR application Masking changes query results only for nonprivileged users; the server admin, the Microsoft Entra admin and db_owner members always see the original data.
Memory hook: Hide it from the DBA: Always Encrypted. From ordinary users: masking. Rows: RLS. Stolen disks and backups: TDE.
Microsoft Learn: Security overview
Contoso wants to retire its legacy VPN by publishing on-premises file shares and web apps to remote staff through Microsoft Entra Private Access. Every user already holds a Microsoft Entra ID P1 license and no other Entra product license. What licensing must be in place for these users before Private Access can go into production?
Correct answer: D. Microsoft Entra Private Access licenses, standalone or through Microsoft Entra Suite, assigned alongside the existing P1 licenses
The licensing overview in What is Global Secure Access states that Microsoft Entra Private Access is included in the Microsoft Entra Suite license and is also sold standalone, and that users of Private Access also need Microsoft Entra ID P1 or P2. P1 or P2 by itself includes only Internet Access for Microsoft services. With P1 already assigned, Contoso adds Private Access standalone or Entra Suite for each user, since most Global Secure Access services are licensed per user.
Why the other options are wrong:
- A. Microsoft Entra ID P2 licenses, because moving the users to P2 adds the Private Access traffic forwarding profile to the tenant Moving to P2 changes the identity tier, not the Global Secure Access entitlement: neither P1 nor P2 includes Private Access, and P2 only meets the prerequisite that P1 already satisfies.
- B. Microsoft Entra Internet Access licenses, because one Global Secure Access add-on covers both the private and internet profiles Internet Access and Private Access are licensed separately; an Internet Access license enables the internet profile, not access to private resources.
- C. No additional licenses, because Microsoft Entra ID P1 already includes the Global Secure Access private and Microsoft traffic features P1 does carry a Global Secure Access entitlement, which is the trap, but it covers Internet Access for Microsoft services only; private resources need a Private Access or Entra Suite license.
Memory hook: Private Access needs Entra Private Access or Entra Suite, on top of P1 or P2.
Microsoft Learn: Overview global secure access
Fabrikam will give three partners read access to a blob container named catalogs by using shared access signatures. Security requires that any one partner's tokens can be revoked at any time without affecting the other partners and without regenerating the storage account keys. Which approach should the engineer use?
Correct answer: B. Create one stored access policy per partner on catalogs, and issue each partner a service SAS bound to its policy.
A stored access policy lets you revoke a service SAS without regenerating the account keys: delete the policy, change its signed identifier, or set its expiry in the past, and every signature bound to it stops working. A container holds up to five stored access policies, so one policy per partner on catalogs isolates each partner. Only a service SAS can reference a stored access policy; user delegation and account SAS are always ad hoc.
Why the other options are wrong:
- A. Issue each partner an account SAS that references its own stored access policy defined on the account. Stored access policies live on a container, file share, queue or table and are not supported for an account SAS, which is always ad hoc.
- C. Issue each partner a user delegation SAS that references its own stored access policy on catalogs. A user delegation SAS cannot reference a stored access policy, so per-partner policies cannot govern these tokens.
- D. Issue each partner a short-lived ad hoc service SAS, and simply stop renewing a partner's tokens when its access must end. An ad hoc SAS stays valid until it expires, so a partner keeps access until then; revoking it sooner would mean regenerating the signing key.
Memory hook: Revocable SAS per audience: one stored access policy each, five per container, service SAS only.
Microsoft Learn: Define stored access policy
Fabrikam replaced its VPN with Quick Access in Microsoft Entra Private Access, which publishes 10.30.0.0/16 to all employees. A finance application at 10.30.8.15 on TCP 443 must now be reachable only by the Finance group and only from compliant devices, while every other internal app keeps its current access. What should the engineer configure?
Correct answer: D. A per-app enterprise application with a 10.30.8.15 TCP 443 segment, assigned only to Finance and targeted by a compliant device policy
Per-app access creates an enterprise application whose segment covers only the finance destination, so user assignment and Conditional Access apply to that app alone. Learn's per-app segmentation tutorial states that when an enterprise application segment overlaps Quick Access, the enterprise application takes precedence for that resource, which enforces explicit assignment. Only assigned Finance users on compliant devices reach the app, and other apps keep their Quick Access path; the segmentation guidance also suggests removing the address from Quick Access.
Why the other options are wrong:
- A. A per-app enterprise application with a 10.30.8.15 TCP 443 segment, assigned to all employees, plus a compliant device policy for Finance The per-app segment is right, but assigning all employees lets everyone reach the finance app, and a Finance-only policy leaves other users unchecked for device compliance.
- B. A Conditional Access policy that targets the Quick Access application, includes only the Finance group, and requires a compliant device Targeting Quick Access forces compliance on every app Finance users reach, yet employees outside Finance still reach the finance app through the broad Quick Access range.
- C. Assignment of only the Finance group to the Quick Access application, plus a compliant device policy that targets that application Scoping Quick Access to Finance does protect the finance app, which is the trap, but every other employee loses access to all the internal apps that Quick Access publishes.
Memory hook: One sensitive app, its own rules: carve it out of Quick Access into a per-app application.
Microsoft Learn: Tutorial private access app segmentation
Fabrikam has three Azure Cosmos DB accounts in one subscription: one is Azure Cosmos DB for NoSQL, one Azure Cosmos DB for MongoDB and one Azure Cosmos DB for Apache Cassandra. The security engineer enables Defender for Azure Cosmos DB at the subscription level. Which accounts can generate Defender for Azure Cosmos DB alerts?
Correct answer: B. Only the NoSQL account, because the plan doesn't support the other two APIs
The Defender for Azure Cosmos DB overview lists Azure Cosmos DB for NoSQL as the only supported API; Azure Cosmos DB for Apache Cassandra, MongoDB, Table and Apache Gremlin aren't supported. Enabling the plan at subscription level is a valid scope on its own, so the NoSQL account is protected with no resource-level step, while the MongoDB and Cassandra accounts produce no alerts.
Why the other options are wrong:
- A. All three accounts, because subscription-level enablement covers every account Subscription scope doesn't extend the plan to unsupported APIs; the MongoDB and Cassandra accounts aren't covered.
- C. None of them until the plan is also turned on for each account at resource level Subscription-level and resource-level enablement are alternatives; turning the plan on for the subscription already covers its supported accounts.
- D. The NoSQL and MongoDB accounts, because the plan supports document APIs only Azure Cosmos DB for MongoDB is document-oriented but sits on the not-supported list; only the API for NoSQL is covered.
Memory hook: Defender for Cosmos DB covers the API for NoSQL only: no MongoDB, Cassandra, Table or Gremlin.
Microsoft Learn: Concept Defender for cosmos
Woodgrove Bank created a private endpoint for the blob subresource of a storage account and linked the privatelink.blob.core.windows.net zone to its virtual networks. Internal apps now resolve the account to a private IP address. A penetration tester outside the company can still read blobs over the internet with a valid SAS token. What should the security engineer change?
Correct answer: D. Set the storage account's public network access to Disabled so that only traffic through private endpoints is accepted
Learn's private endpoint overview states that private endpoints provide a privately accessible IP address for a service but don't necessarily restrict public network access to it. The account's public endpoint stays open until public network access is set to Disabled, after which traffic is allowed only through a private endpoint. DNS resolution and access control are independent: with public access disabled, the service rejects the tester's connection regardless of what the name resolves to.
Why the other options are wrong:
- A. Re-create the private endpoint with the manual approval method so that approving the connection revokes public access Approval decides whether the private endpoint can carry traffic; approving or rejecting a connection has no effect on the account's public network access setting.
- B. Create a private DNS zone named blob.core.windows.net and link it so that the account name no longer resolves publicly A private zone changes resolution only inside linked virtual networks, and Learn cautions against overriding a zone used for public endpoints; internet clients still resolve and reach the public endpoint.
- C. Enable network policies for network security groups on the endpoint subnet and add a rule that denies the Internet tag Network policies make an NSG apply to traffic that reaches the private endpoint, but the tester never touches the endpoint; the requests arrive at the account's public endpoint, which no subnet NSG governs.
Memory hook: A private endpoint adds a private door; it never locks the public one.
Microsoft Learn: Private endpoint overview
Contoso hosts 20 databases on one Azure SQL Database logical server, which already has server-level IP firewall rules for Contoso's administrators. A partner's analysts connect from the public range 203.0.113.16 to 203.0.113.31 and must reach only the PartnerSales database. The DBA who must grant this access holds CONTROL DATABASE on PartnerSales and no Azure role assignment. What should the DBA create?
Correct answer: D. A database-level IP firewall rule for the range, created in PartnerSales with sp_set_database_firewall_rule
The Azure SQL Database IP firewall rules article says database-level rules admit clients to one database only, are stored in that database, and can be created only with Transact-SQL, through sp_set_database_firewall_rule, once a first server-level rule exists. Configuring them needs CONTROL DATABASE, which the DBA holds. Any server-level rule would open all 20 databases to the partner, and the portal routes need Azure role permissions the DBA doesn't have.
Why the other options are wrong:
- A. A server-level IP firewall rule for the range, created in master with sp_set_firewall_rule sp_set_firewall_rule creates a server-level rule that opens every database on the server, and running it requires the server-level principal login or the Microsoft Entra admin connected to master.
- B. A database-level IP firewall rule for the range, created on the database's Networking page in the portal The portal can't create database-level IP firewall rules; they exist only through Transact-SQL.
- C. A server-level IP firewall rule for the range, created on the logical server's Networking page in the portal A server-level rule admits the range to all 20 databases, and managing rules in the portal needs an Azure role such as SQL Server Contributor, which the DBA lacks.
Memory hook: One database for one partner: sp_set_database_firewall_rule, T-SQL only, and checked before server-level rules.
Microsoft Learn: Firewall configure
Fabrikam has Defender for Azure SQL Databases enabled. Its security engineer holds the SQL Security Manager role on the Azure SQL Database servers but no role on any storage account, and policy forbids new storage accounts for security tooling. The engineer must turn on SQL vulnerability assessment and approve baselines that take effect without waiting for a rescan. Which configuration fits?
Correct answer: C. Express configuration, with scan results kept in Microsoft-managed storage in the server's region
The SQL vulnerability assessment article says express configuration needs no customer-managed storage account, stores results in the same region as the logical server, and lets SQL Security Manager change its settings. Its comparison table adds that an express baseline takes effect without rescanning the database. Classic configuration needs a storage account, SQL Security Manager plus Storage Blob Data Reader and Owner on it, and applies baselines only after a rescan.
Why the other options are wrong:
- A. Data discovery and classification, with sensitivity labels applied to the flagged columns Data discovery and classification labels sensitive columns; it isn't a vulnerability scanner and has no baselines.
- B. Classic configuration scoped to each database, with baselines approved one rule at a time Database scope is a classic option, but classic still needs a storage account and still waits for a rescan before a baseline applies.
- D. Classic configuration, with scan results written to a new storage account in the server's region Classic configuration breaks the storage policy, needs Storage Blob Data Reader and Owner on the account, and applies a baseline only after the next scan.
Memory hook: SQL VA express: no storage account, results in the server's region, baselines apply without a rescan.
Microsoft Learn: SQL Azure vulnerability assessment overview