Design solutions for securing applications

Sablewood Media serves a public video portal from Azure App Service instances in three Azure regions. The company wants a single global entry point that terminates TLS close to users, protects against the OWASP Top 10 and malicious bots before traffic enters Azure regions, and connects to the App Service origins over Private Link so they are not reachable directly from the internet. Minimizing the number of components to manage is a priority.

What should you recommend?

1. AAzure Front Door Premium with an Azure Web Application Firewall policy that uses the Default Rule Set and Bot Manager rule set, and Private Link to the App Service originsFront Door Premium is a global edge service that provides a single anycast entry point, TLS termination at the edge, WAF with managed OWASP-based and bot rule sets, and Private Link connectivity to origins, in one managed component.
2. BAzure Application Gateway WAF v2 deployed in each of the three regions with Traffic Manager for DNS routingApplication Gateway is a regional service; three gateways plus Traffic Manager means more components, and filtering happens inside each region rather than at the global edge.
3. CAzure Firewall Premium with IDPS and TLS inspection in a hub virtual networkAzure Firewall Premium is a network firewall for traffic inside and between virtual networks; it is not an internet-facing global load balancer and does not provide OWASP web application rule sets or bot protection for public web apps.
4. DNetwork security groups on the App Service virtual network integration subnet with rules allowing only HTTPSNSGs filter layer 3 and 4 traffic; they cannot inspect HTTP requests for OWASP attacks or distinguish bots, and they do not provide a global entry point.

Wrenfield Travel runs 25 customer-facing web applications on Azure App Service. Azure Front Door with Web Application Firewall already filters inbound traffic. The security requirements document adds a new item: detect attacks against the running applications, such as web shell uploads, dangling DNS entries, and suspicious process execution on the App Service workers, and send alerts to the SOC without deploying agents or changing application code.

Which technology should you map to this requirement?

1. AMicrosoft Defender for App ServiceDefender for App Service is an agentless Defender for Cloud plan that monitors App Service runtime activity, detecting web shells, dangling DNS, suspicious processes, and attack patterns, and raises alerts that integrate with the SOC.
2. BAn additional Azure Web Application Firewall policy in Prevention modeWAF inspects and blocks malicious HTTP requests at the edge; it does not observe what happens on the App Service workers after a request is processed or detect dangling DNS.
3. CMicrosoft Defender for Cloud Apps connected to the applicationsDefender for Cloud Apps monitors SaaS applications and user sessions; it does not provide runtime threat detection for custom web apps hosted on App Service.
4. DApplication Insights with availability tests for each applicationApplication Insights provides performance telemetry and availability monitoring; it is not a security detection service and does not identify web shells or suspicious processes.

Caldera Energy exposes 40 internal REST APIs to partner organizations through Azure API Management. Each partner currently receives an API Management subscription key. An audit found that subscription keys were shared between partners and that the backends cannot tell which partner user made a call. The new requirement is that every request must carry a Microsoft Entra ID access token issued for the API, that tokens are verified before reaching the backend, and that quota and throttling remain enforced per partner.

What should you recommend?

1. ARotate the subscription keys for every partner and set the keys to expire every 90 daysSubscription keys identify a subscription for quota purposes but are shared secrets with no user identity; rotating them does not authenticate the caller or prevent sharing.
2. BRegister the APIs in Microsoft Entra ID, require partners to obtain OAuth 2.0 access tokens, and add a validate-jwt policy in API Management that checks the issuer, audience, and required claims, while keeping subscriptions for rate limits and quotasThe validate-jwt (or validate-azure-ad-token) policy rejects requests without a valid Microsoft Entra token before they reach the backend, giving caller identity and claims-based authorization, and subscriptions continue to provide per-partner quota and throttling.
3. CEnable client certificate authentication on the API Management gateway and distribute a certificate to each partnerMutual TLS proves possession of a partner certificate but does not provide Microsoft Entra ID access tokens or user-level identity and claims as the requirement states.
4. DDeploy Azure Web Application Firewall in front of API Management with the OWASP managed rule setWAF blocks common web attacks but performs no OAuth token validation and does not establish caller identity.

Juniper Fintech publishes 300 APIs through Azure API Management to serve a multi-tenant lending platform. Several APIs were created by product teams without security review. The architect must continuously discover APIs in API Management that have no authentication, identify APIs that return personally identifiable information in responses, detect anomalous call volumes or data exfiltration from a single API key, and surface the findings as recommendations and alerts in the existing Microsoft Defender for Cloud and Microsoft Sentinel workflow. API Management already enforces validate-jwt on the reviewed APIs.

What should you recommend?

1. AEnable the Microsoft Defender for APIs plan in Defender for Cloud and onboard the API Management APIs to itDefender for APIs inventories APIs published in API Management, recommends fixes for unauthenticated or externally exposed APIs, classifies sensitive data in requests and responses, and produces runtime anomaly alerts that flow into Defender for Cloud and Sentinel.
2. BEnable Azure Web Application Firewall on an Application Gateway in front of API Management with bot protectionWAF blocks known attack signatures and bots in traffic but does not inventory APIs, assess authentication posture, or classify sensitive data in API responses.
3. CTurn on API Management diagnostic logs to Log Analytics and build Sentinel analytics rules for high request countsCustom analytics on gateway logs can detect volume spikes but require significant rule development and do not provide posture recommendations about missing authentication or PII exposure.
4. DEnable Microsoft Defender for App Service on the backend services that host the API implementationsDefender for App Service protects the hosting platform runtime; it does not understand the API inventory in API Management or the authentication and data classification posture of each API.