4 of the 9 questions we have for this objective, shown with the answer and the reasoning.
Specify requirements for securing SaaS, PaaS, and IaaS services
Oakhurst Bank launched a customer-facing assistant built on Azure OpenAI with retrieval over account documents. Red-team testing showed that prompt injection hidden in uploaded documents could make the assistant reveal other customers' data. The SOC requires security alerts in Microsoft Defender XDR when jailbreak attempts, sensitive data exposure, or credential leakage occur in prompts or responses, with the alert identifying the end user involved so the account can be investigated. Azure AI Content Safety filters are already enabled on the deployment.
What should you recommend?
- AEnable the Defender for AI Services plan in Defender for Cloud on the subscription and have the application pass end-user context, at minimum the EndUserId and SourceIP fields, in the UserSecurityContext parameter of its Azure OpenAI requestsDefender for AI Services analyzes prompts and responses, including Prompt Shields signals, to raise alerts for jailbreak, data leakage, and credential theft in Defender for Cloud and Defender XDR, and the UserSecurityContext fields enrich each alert with the end user's Entra object ID and source IP so the SOC can investigate the account.
- BRaise the Azure AI Content Safety filter severity to the strictest level on the deploymentContent filters block or annotate harmful content inline but do not generate SOC alerts in Defender XDR or attribute attempts to an end user for investigation.
- CEnable Defender for APIs on the subscription to detect anomalous calls to the Azure OpenAI endpointDefender for APIs protects APIs published through Azure API Management and analyzes traffic patterns, not the semantic content of prompts and completions.
- DPlace Azure Application Gateway WAF v2 in front of the application and enable the default rule setWAF rule sets target web attack signatures such as SQL injection; they do not understand natural-language prompt injection or model outputs.
Why: Content Safety and Defender for AI Services solve different problems: Content Safety is a preventive filter in the request path, while Defender for AI Services (formerly called AI threat protection) is the generally available Defender for Cloud plan that turns jailbreak attempts, sensitive data exposure, and credential leakage into security alerts the SOC can investigate in Defender XDR. The deciding constraints are SOC alerts and end-user attribution, which require the Defender plan plus the application passing UserSecurityContext so alerts carry the user identity. The traps are the adjacent Defender plans and WAF, which analyze API traffic patterns or HTTP signatures rather than prompt content.
Specify requirements for securing SaaS, PaaS, and IaaS services
Greywater Municipal Services hosts a citizen payment portal on Azure App Service in a single Azure region; a data residency rule prohibits routing traffic through a global edge network. Security requires inbound requests to be inspected and blocked for OWASP Top 10 patterns in prevention mode, and requires detection of threats that occur inside the web app itself, such as web shell uploads or suspicious process execution on the App Service workers, with alerts in Defender for Cloud.
Which two components should you include in the design? Each correct answer presents part of the solution.
- AAzure Application Gateway WAF v2 with the latest default rule set in Prevention mode in the same region as the App ServiceApplication Gateway WAF v2 is the regional web application firewall; it applies the managed OWASP-based default rule set and can be set to Prevention mode so matching requests are blocked without leaving the region.
- BMicrosoft Defender for App Service enabled on the subscription that hosts the App Service planDefender for App Service analyzes App Service runtime telemetry to detect web shells, dangling DNS, suspicious processes, and other in-app threats, raising alerts in Defender for Cloud with no agent to install.
- CAzure Front Door Premium with a WAF policy in Prevention modeFront Door is a global edge service that terminates traffic at points of presence worldwide, which violates the residency rule against routing through a global network.
- DAzure Firewall Premium with IDPS deployed in front of the App ServiceIDPS inspects network signatures and does not provide OWASP Top 10 HTTP request inspection or TLS termination for a web application, and it does not detect in-app threats on App Service workers.
- EMicrosoft Defender for APIs enabled on the subscriptionDefender for APIs protects APIs published through Azure API Management, which the portal does not use, and it does not detect process-level threats on App Service.
Why: Web workload security has two layers that are tested together: a WAF in front of the app to block malicious requests, and workload protection that watches the app's runtime for signs of compromise. Because of the data residency rule, the WAF must be the regional Application Gateway WAF v2 rather than Front Door, and the runtime layer for App Service is Defender for App Service, which is agentless and raises alerts in Defender for Cloud. The traps are Front Door (right capability, wrong topology for the residency constraint) and network-layer IDPS, which does not understand HTTP application attacks.
Specify requirements for securing SaaS, PaaS, and IaaS services
Harrowgate Clearing operates an AKS cluster that settles securities trades. Regulators require that the Kubernetes API server have no public IP address or public DNS record at all, that cluster operators administer it only from the corporate network over ExpressRoute into a hub virtual network, and that worker nodes have no public IP addresses. The platform team currently relies on API server authorized IP ranges.
What should you recommend?
- ARebuild the cluster as a private AKS cluster with a private DNS zone linked to the hub virtual network, peer the hub to the cluster network, and administer it from the hub over ExpressRouteA private cluster exposes the API server only through a private endpoint in the cluster network with a private DNS zone; peering the hub and linking the zone lets on-premises operators reach it over ExpressRoute while no public endpoint exists.
- BKeep the public API server and restrict authorized IP ranges to the corporate NAT addressesAuthorized IP ranges filter callers but the API server still has a public IP and public DNS name, which the regulator explicitly prohibits.
- CApply a network security group to the node subnet that denies inbound traffic to port 443 from the internetThe API server is hosted by the managed control plane outside the node subnet, so a node subnet NSG has no effect on its exposure.
- DRoute all cluster egress through Azure Firewall Premium with outbound type userDefinedRoutingControlling egress is good practice and complements the design, but it does nothing to remove the public API server endpoint, which is the stated requirement.
Why: The distinction being tested is between filtering access to a public control plane and removing the public endpoint entirely. Authorized IP ranges keep a public API server and merely allowlist callers, whereas a private cluster places the API server behind a private endpoint with a private DNS zone, so it has no public IP or public name. Reaching it from on-premises requires DNS zone links and hub-to-cluster peering over ExpressRoute. The traps are NSGs on the node subnet, which cannot govern the managed control plane, and egress firewalling, which addresses a different risk.
Specify requirements for securing SaaS, PaaS, and IaaS services
Brightmoor Legal is deploying a document-summarization app that calls an Azure OpenAI deployment in Azure AI Foundry from an Azure App Service. Client confidentiality rules require that the Azure OpenAI resource be unreachable from the public internet, that the app authenticate without an API key anywhere in configuration, and that the app's identity be able to call the inference endpoint but not change deployments or read keys. Least privilege is the deciding factor.
Which requirements should you specify?
- ADisable public network access on the Azure OpenAI resource and add a private endpoint; disable local (key-based) authentication; assign the App Service system-assigned managed identity the Cognitive Services OpenAI User role on the resourceA private endpoint with public access disabled removes internet reachability, disabling local auth forces Microsoft Entra tokens, and Cognitive Services OpenAI User grants inference-only data-plane access without key or deployment management rights.
- BRestrict the resource firewall to the App Service outbound IP addresses and store the API key in Azure Key Vault referenced by the appAn IP allowlist still leaves a public endpoint, and the key remains a long-lived shared secret even when held in Key Vault.
- CAdd a private endpoint and assign the App Service managed identity the Cognitive Services Contributor role on the resourceCognitive Services Contributor can manage the resource, including listing keys and changing deployments, which exceeds the inference-only access the scenario requires.
- DAdd a private endpoint and assign the App Service managed identity the Cognitive Services OpenAI Contributor role on the resourceOpenAI Contributor allows creating and modifying deployments and fine-tuning, which is more than calling the inference endpoint.
Why: Securing Azure AI services follows the same three controls as other PaaS: network isolation through private endpoints with public access disabled, identity-based authentication by disabling local keys, and least-privilege RBAC with the narrowest data-plane role, which for inference against Azure OpenAI is Cognitive Services OpenAI User. The deciding constraint is least privilege, which separates the User role from the two Contributor roles that also allow deployment and key management. The trap is the Key Vault option, which protects the key at rest but still relies on a shared secret and leaves the service publicly addressable.