Implement Azure security →mediumMultiple ChoiceObjective-mapped

AZ-204 Implement Azure security Practice Question

Exhibit

Refer to the exhibit.

{
  "type": "Microsoft.Web/sites/config",
  "apiVersion": "2022-03-01",
  "name": "[concat(parameters('siteName'), '/authsettingsV2')]",
  "properties": {
    "platform": {
      "enabled": true
    },
    "globalValidation": {
      "requireAuthentication": true,
      "unauthenticatedClientAction": "RedirectToLoginPage"
    },
    "identityProviders": {
      "azureActiveDirectory": {
        "enabled": true,
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0",
          "clientId": "11111111-1111-1111-1111-111111111111"
        }
      }
    }
  }
}

Refer to the exhibit. You deploy this ARM template to an App Service named 'myapp'. After deployment, users report they are able to access the app without being prompted to log in. What is the most likely reason?

⚠ Common exam trap

A common mix-up: candidates assume a missing client secret causes a deployment error or a login failure, but Azure App Service silently disables the identity provider when the secret is absent, allowing unauthenticated access.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The Azure Active Directory registration is missing the client secret.

The ARM template configures the `identityProviders` section with Azure Active Directory settings, but without a `clientSecret` property. The EasyAuth middleware requires a valid client secret to complete the OAuth 2.0 authorization code flow; without it, the authentication provider is effectively disabled, allowing unauthenticated access.

Answer analysis

Option-by-option breakdown

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

✓
The Azure Active Directory registration is missing the client secret.
Why this is correct
Azure App Service's Easy Auth, when configured with Azure AD, operates as a confidential client. This means it needs to securely authenticate itself to Azure AD to exchange authorization codes for access tokens and refresh tokens. A client secret (or certificate) serves as this credential, and its absence prevents the App Service from establishing a trusted connection and completing the OAuth 2.0 authorization code flow, leading to authentication failures because the identity provider cannot verify the client's identity.
✗
The redirect URI is not configured in the Azure AD app registration.
Why it's wrong here
Azure App Service's Easy Auth feature dynamically generates and manages the redirect URI for the Azure AD application registration. When you enable Easy Auth and select Azure AD as the identity provider, the platform automatically registers the necessary `/.auth/login/aad/callback` endpoint with Azure AD. Therefore, a manual misconfiguration or absence of the redirect URI is generally not the cause of authentication issues when Easy Auth is properly enabled, as the platform handles this configuration automatically.
✗
The issuer URL is incorrect; it should include the tenant ID.
Why it's wrong here
The issuer URL `https://login.microsoftonline.com/{tenantid}/v2.0` is a standard format for Azure AD v2.0 endpoints, where `{tenantid}` is a placeholder that Azure AD resolves at runtime based on the authentication request. For multi-tenant applications, the common endpoint `https://login.microsoftonline.com/common/v2.0` is often used, and the actual tenant ID is inferred. The provided issuer URL format is correct and aligns with how Azure AD v2.0 endpoints are designed to function, making this option incorrect.
✗
The client ID is from a different tenant.
Why it's wrong here
While a client ID is globally unique, it is initially registered within a specific Azure AD tenant (e.g., Contoso). However, an application can be configured as multi-tenant, allowing users from other Azure AD tenants to sign in. The issue isn't typically that the client ID *originates* from a different tenant, but rather if the application registration itself isn't correctly configured for the intended tenant or if the client ID provided to Easy Auth doesn't match the registered application. The statement implies a fundamental incompatibility that isn't inherently true for multi-tenant applications.

Go deeper

AZ-204 Implement Azure security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question