SC-100 App Service Authentication (EasyAuth) 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.

• ✓

  Enable App Service Authentication (EasyAuth)

  Why this is correct

  App Service Authentication (EasyAuth) is built into the App Service platform and sits in front of your function code. When enabled, it requires every HTTP request to present a valid token from a configured identity provider (e.g., Microsoft Entra ID), and it rejects unauthenticated requests before they reach your function. It also gives you access to authenticated user claims in your code, so you can enforce fine-grained authorization beyond mere presence of a token.

• ✓

  Configure network restrictions to allow only specific IP ranges

  Why this is correct

  Configuring network restrictions on an Azure Functions app creates a front-end firewall through the App Service Access Restrictions feature. By specifying allowed CIDR ranges, all inbound requests from outside those ranges are rejected at the platform edge, preventing anonymous internet traffic from even reaching your function host. This is particularly effective for functions that only need to be triggered by internal systems or a known set of callers, and it works alongside authentication.

• ✗

  Set authorization level to anonymous

  Why it's wrong here

  Setting the authorization level to anonymous means that your HTTP-triggered function does not require any function key or token in the request. Any caller on the internet can invoke the function endpoint and, if the code has side effects such as writing to a database or sending emails, this can lead to abuse, data exposure, or resource exhaustion. In production, anonymous access should only be used when another trusted gateway or API Management layer is in front of the function.

• ✗

  Enable Application Insights

  Why it's wrong here

  Application Insights is a diagnostics and monitoring service that collects telemetry such as request rates, failures, and performance metrics from your function app. Enabling it gives you visibility into anomalies and latencies, but it does not filter or validate incoming requests. It is a security complement because it helps you detect attacks, but it is not a security control in itself and does not reduce the attack surface.

• ✗

  Use function keys only

  Why it's wrong here

  Function keys are static shared secrets that are scoped either to an individual function or the entire host, and they are included in the request header x-functions-key. While they provide a level of access control, they are not tied to a user identity and can be easily shared, leaked through client side code, or embedded in logs. Relying on function keys as the sole authentication mechanism is less secure than requiring federated identity through EasyAuth, and it lacks the ability to enforce per-user claims or roles.

Go deeper

Related to this question