AZ-204 Implement Azure security Practice Question
An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The architecture review board prefers a managed Azure-native control.
⚠ Common exam trap
A common mix-up: candidates confuse 'claims that are present in the token' (like display name) with 'claims that must be validated for security' (issuer, audience, signature), leading them to select non-essential claims as validation requirements.
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
✓
Issuer and signature are valid for the trusted tenant
Option A is correct because the API must verify that the JWT was issued by the trusted Microsoft Entra ID tenant (the iss claim matches the tenant's issuer, e.g., https://login.microsoftonline.com/{tenantid}/v2.0) and that its signature validates against Entra ID's published signing keys, ensuring the token is authentic and untampered. Option C is correct because the API must confirm the aud claim matches its own application ID URI or client ID, which prevents tokens issued for a different resource from being replayed against this API. Option B is not required for security validation — a display name is optional and not a reliable authorization check. Option D is incorrect and insecure: tokens should be sent in the Authorization header as a Bearer token, never in a query string, which would expose them in logs and URLs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Issuer and signature are valid for the trusted tenant
Why this is correct
Validating the issuer confirms the token came from the trusted Microsoft Entra ID tenant, and verifying the signature proves it was not tampered with. Together these establish authenticity before the API accepts the request, using Azure-native token validation.
- ✗
The user's display name is present
Why it's wrong here
A display name is a cosmetic profile claim, not a security assertion, so validating it proves nothing about the caller's identity or authorisation. It is tempting because the name appears in the token payload alongside real claims, but the API should instead validate the issuer, audience, signature and expiry.
- ✓
Token audience matches the API application ID URI or client ID
Why this is correct
The audience claim must match the API's application ID URI or client ID, confirming the token was issued specifically for this API rather than another resource. Validating audience prevents token replay against unintended services and satisfies the managed Azure-native control preference.
- ✗
The token was sent in a query string
Why it's wrong here
Token transport location is not a claim to validate; query strings expose tokens in logs and referrers, so the API should reject them outright. Validation must cover issuer, audience, signature, expiry and scope. This option confuses secure transmission with token verification, which is why it fails the scenario.
Go deeper
Related to this question
About these practice questions
This AZ-204 question is part of Courseiva's 883-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.