AZ-305 Design infrastructure solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Azure API Management with OAuth 2.0 policy

  Why it's wrong here

  Azure API Management can validate OAuth tokens using a validate-jwt policy, but that only enforces an existing token; the client must still acquire a token on its own and the web application must either handle token acquisition via MSAL or OAuth flows or rely on custom forwarding. Enabling this would require modifying application code to start an OAuth flow or intercept tokens, which does not satisfy the requirement to avoid writing authentication code. Therefore, although API Management adds a layer for API protection, it does not provide end-to-end web application authentication without code.

• ✗

  Microsoft Authentication Library (MSAL) integrated into the application code

  Why it's wrong here

  Microsoft Authentication Library (MSAL) is a developer component that must be explicitly added to the project, initialized with client IDs, and coded to handle login redirects, token acquisition, cache invalidation, and silent renewal. Even though MSAL abstracts many OAuth complexities, integrating it still requires significant application code changes and an understanding of token handling, which directly contradicts the goal of without writing any authentication code. EasyAuth is the platform-managed alternative that avoids this coding burden entirely.

• ✓

  App Service Authentication (EasyAuth)

  Why this is correct

  App Service Authentication, also known as EasyAuth, runs natively in the App Service platform overlay and automatically handles the full OAuth 2.0 and OpenID Connect flow against Microsoft Entra ID. When a request arrives, EasyAuth validates the identity, establishes an encrypted session cookie, and injects security claims into HTTP headers such as X-MS-CLIENT-PRINCIPAL and X-MS-TOKEN-AAD-ID-TOKEN for the app to read. Since this all occurs at the platform level, the application requires zero authentication code; the developer simply enables the feature and configures the identity provider in the Azure portal. For multitenant apps, it also manages tenant restrictions without changes to the app.

• ✗

  Azure Front Door with authentication rules

  Why it's wrong here

  Azure Front Door is a global application delivery and load-balancing service that provides routing, SSL offloading, and web application firewall (WAF) policies, but it does not perform identity-based user authentication against Azure Entra ID. Although you can write custom rules or use the WAF to filter incoming requests by IP or geo-location, those are not authentication methods; they do not challenge a user to sign in or manage session tokens. Implementing any real authentication with Front Door would require a custom server-side redirect or a serverless function, which adds code and fails the requirement.

Go deeper

Related to this question