Practise Microsoft Azure Developer Associate AZ-204 practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.
These are the questions most candidates get wrong. They require connecting multiple concepts, reading tricky output, or knowing edge-case behaviour that isn't on most study cards. Practising them trains you to operate under uncertainty — a necessary skill on the real exam.
Quick answer
Hard Difficulty Questions questions test whether you can apply the concept in context, not just recognise a definition.
How the topic appears in realistic exam-style scenarios.
Which detail in the question changes the correct answer.
How to eliminate plausible but wrong options.
How to connect the question back to the wider exam objective.
Related practice questions
Related AZ-204 topic practice pages
Scenario questions usually connect to one or more exam topics. Use these links to review the underlying concepts behind the scenario.
You are monitoring an Azure App Service using Application Insights. You notice that HTTP 500 errors are increasing, but the standard server response time metric remains normal. You suspect that the errors are occurring in an external API call made by the application. How can you identify the dependency that is failing?
A
Enable snapshot debugging for the application.
Why wrong: Snapshot debugger captures a snapshot of the application state on exceptions but does not show dependency-level failure rates across all requests.
B
Use Application Insights Profiler to capture code-level traces.
Why wrong: Profiler is for diagnosing performance bottlenecks in code, not for identifying external dependency failures.
C
Configure Application Insights dependency tracking and view the Dependency Metrics blade.
Dependency tracking records each call to external services, and the metrics blade aggregates failures and durations for each dependency, making it easy to spot failures.
D
Set up a custom event telemetry for each external call.
Why wrong: While possible, custom events require manual instrumentation and do not automatically provide the aggregated failure metrics that built-in dependency tracking does.
You have an Azure App Service web app that experiences intermittent slowness. You enable Application Insights and notice that the "Failed Requests" metric is low, but "Server Response Time" is high for a subset of requests. You want to identify the specific code path causing the delay. Which feature should you use?
A
Live Metrics.
Why wrong: Incorrect. Live Metrics shows real-time telemetry but does not provide code-level profiling.
B
Snapshot Debugger.
Why wrong: Incorrect. Snapshot Debugger captures state on exceptions, not general slowness.
C
Profiler.
Correct. Profiler traces requests and identifies slow code paths.
D
Availability tests.
Why wrong: Incorrect. Availability tests monitor uptime and responsiveness from external locations, not internal code paths.
You need to analyze all exceptions that occurred in the last 24 hours from an application monitored by Application Insights. You want to group them by exception type, and for each type show the URL where it occurred and the count. Which Log Analytics Kusto query should you use?
A
exceptions | where timestamp > ago(24h) | summarize count() by type, cloud_RoleInstance
Why wrong: This groups by exception type and cloud role instance, not by URL as required.
B
exceptions | where timestamp > ago(24h) | summarize count() by type, url
This query correctly filters the last 24 hours and groups by exception type and URL with a count of occurrences.
C
exceptions | where timestamp > ago(24h) | summarize count() by type, operation_Name
Why wrong: Grouping by operation name gives the name of the operation (e.g., controller action) but not the URL as required.
D
exceptions | where timestamp > ago(24h) | summarize count() by type
Why wrong: This groups only by exception type, missing the URL information needed.
You are building a web application that uses Microsoft Entra ID for authentication. The application needs to call Microsoft Graph API to read user profiles and send emails on behalf of the signed-in user. You want to ensure that the user's consent is obtained only once and that the application can refresh tokens silently. Which OAuth 2.0 flow should you implement?
A
OAuth 2.0 Client Credentials flow.
Why wrong: Client Credentials flow is for server-to-server authentication without a user context. It cannot act on behalf of a signed-in user.
B
OAuth 2.0 Implicit Grant flow.
Why wrong: The Implicit flow is deprecated and does not support refresh tokens, requiring user interaction each time tokens expire. It is less secure than the Authorization Code flow with PKCE.
C
OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange).
This flow is secure for web apps, provides refresh tokens for silent renewal, and obtains user consent during the initial authentication. It is the recommended flow by Microsoft for web applications calling APIs on behalf of users.
Why wrong: ROPC flow requires the user to provide their password directly to the application, which is not recommended due to security risks. It also does not work with accounts that have multi-factor authentication or federated identities.
A single-page app signs in users with Microsoft Entra ID and calls a protected API. The app cannot safely keep a client secret. Which OAuth flow should be used? The design must avoid adding custom operational scripts.
A
Implicit flow
Why wrong: Implicit flow is legacy and less secure than authorization code with PKCE.
B
Client credentials flow
Why wrong: Client credentials is for daemon/service-to-service access, not user sign-in in a SPA.
C
Resource owner password credentials flow
Why wrong: ROPC is discouraged and incompatible with many modern security controls.
D
Authorization code flow with PKCE
PKCE protects public clients that cannot store secrets and is recommended for SPAs.
A document rendering job in Azure App Service must safely access Key Vault secrets without connection strings in configuration. Which two steps are required?
A
Enable a managed identity for the web app
A managed identity gives the app an Azure AD identity without stored credentials.
B
Enable anonymous access on the vault
Why wrong: Anonymous access is not allowed and would be insecure.
C
Grant the identity permission to read the required secrets
The identity must be authorized on Key Vault through RBAC or access policies.
D
Store the Key Vault access key in app settings
Why wrong: Key Vault does not use access keys, and storing credentials defeats the purpose.
Application Insights ingestion cost is rising because a high-traffic app emits large telemetry volume. The team needs statistically useful telemetry while reducing ingestion. What should be configured?
A
Move the app to a larger App Service plan
Why wrong: Scaling compute does not reduce telemetry ingestion.
B
Adaptive sampling
Adaptive sampling reduces telemetry volume while preserving representative diagnostic data.
C
Disable all exception telemetry
Why wrong: Disabling important telemetry weakens troubleshooting.
You develop a C# application that stores sensitive documents in Azure Blob Storage. You need to generate a time-limited shared access signature (SAS) that allows a client to only read and list blobs in a specific container. The SAS must be valid for exactly 1 hour from the current time. Which code snippet correctly creates the SAS? (Assume BlobServiceClient and BlobContainerClient are properly initialized.)
A
var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
This correctly sets resource to 'c' for container-level SAS, includes Read and List permissions, and generates the SAS URI using the container client.
B
var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "b", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
Why wrong: Resource = 'b' creates a blob-level SAS, which restricts access to a single blob, not the entire container's read and list operations.
C
var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.All }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
Why wrong: Permissions = All grants full control (read, write, delete, etc.), exceeding the requirement of only read and list.
D
var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow.AddDays(-1), ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
Why wrong: StartsOn is set to yesterday, which would make the SAS valid from that earlier time, not from the current time, potentially exposing the container for a longer period.
Application Insights ingestion cost is rising because a high-traffic app emits large telemetry volume. The team needs statistically useful telemetry while reducing ingestion. What should be configured? The design must avoid adding custom operational scripts.
A
Move the app to a larger App Service plan
Why wrong: Scaling compute does not reduce telemetry ingestion.
B
Adaptive sampling
Adaptive sampling reduces telemetry volume while preserving representative diagnostic data.
C
Disable all exception telemetry
Why wrong: Disabling important telemetry weakens troubleshooting.
Application Insights ingestion cost is rising because a high-traffic app emits large telemetry volume. The team needs statistically useful telemetry while reducing ingestion. What should be configured? The architecture review board prefers a managed AWS-native control.
A
Move the app to a larger App Service plan
Why wrong: Scaling compute does not reduce telemetry ingestion.
B
Adaptive sampling
Adaptive sampling reduces telemetry volume while preserving representative diagnostic data.
C
Disable all exception telemetry
Why wrong: Disabling important telemetry weakens troubleshooting.
You are developing a web API that must authenticate requests using Microsoft Entra ID (Microsoft Entra ID) and OAuth 2.0 bearer tokens. You want to validate the token in your API code. Which library should you use?
A
Microsoft Authentication Library (MSAL)
Why wrong: MSAL is used by client applications to acquire tokens, not by APIs to validate tokens.
B
Microsoft.Identity.Web
Microsoft.Identity.Web provides middleware and helper classes to validate Microsoft Entra ID tokens in ASP.NET Core APIs.
C
ADAL.NET
Why wrong: ADAL is deprecated and should not be used for new development; it does not provide the latest token validation standards.
D
Azure.Identity
Why wrong: Azure.Identity is for authenticating to Azure services using credentials, not for validating bearer tokens in an API.
You need to emit a custom metric in Application Insights that tracks the number of page views per browser. You expect high volume (millions of events per day). Which API should you use to ensure efficient pre-aggregation and avoid performance issues?
A
TrackEvent
Why wrong: TrackEvent sends each event individually. At millions of events per day, this can lead to high costs and potential throttling.
B
TrackMetric
Why wrong: TrackMetric does not support dimensions (like browser type) natively and is less flexible for pre-aggregation.
C
GetMetric
GetMetric is designed for high-volume metrics with dimensions and performs client-side aggregation for efficiency.
D
TrackDependency
Why wrong: TrackDependency is used for recording calls to external dependencies, not for custom metrics like page views.
An e-commerce platform writes orders to a Cosmos DB container. A downstream inventory service must process every new or updated order exactly once, even if the inventory service restarts mid-batch. The solution must scale horizontally when order volume increases. What is the recommended design?
A
Use the change feed processor library with a dedicated lease container; each worker instance claims partition leases and commits checkpoints after processing each batch
The lease container stores the last-processed continuation token per partition. On restart, a worker reads its leases and resumes from the checkpointed position. Adding more worker instances automatically redistributes leases across instances, providing linear horizontal scaling.
B
Poll the Cosmos DB container every 30 seconds using a _ts timestamp filter to find recently modified documents
Why wrong: Timestamp polling has two problems: clock skew can cause missed documents near the query boundary, and repeated full-container scans increase RU consumption. The change feed is a purpose-built, push-based stream that avoids both issues.
C
Subscribe to Azure Event Grid Cosmos DB events and process them in an Azure Function
Why wrong: Azure Event Grid does not natively emit per-document Cosmos DB change events at the document level in a way that supports the exactly-once-with-checkpoint semantics required. The change feed processor is the supported pattern for this use case.
D
Enable Cosmos DB analytical store and run batch queries from an Azure Synapse Spark pool every hour
Why wrong: The analytical store serves OLAP workloads with high latency (minutes to hours). The inventory service needs near-real-time processing after each order write. Spark batch queries are unsuitable for event-driven, low-latency inventory updates.
Three microservices collaborate on a single user transaction: an App Service API, an Azure Function that processes a Service Bus message, and a downstream storage service. Traces appear separately in Application Insights with no parent-child relationship. What is needed to correlate all three into a single end-to-end trace?
A
Install the Application Insights SDK on all three services and ensure W3C Trace Context header propagation is enabled for both HTTP calls and Service Bus messages
The SDK propagates the traceparent header on outgoing HTTP requests automatically. For Service Bus, the SDK injects and reads correlation properties in the message's ApplicationProperties collection. With the same operation ID flowing through all three services, Application Insights assembles the calls into a single end-to-end trace in the Application Map and end-to-end transaction view.
B
Use the same Application Insights instrumentation key for all three services — no additional configuration is needed
Why wrong: Sharing an instrumentation key sends all telemetry to the same resource but does not automatically correlate traces. Without header propagation, each service generates its own independent operation IDs, so the calls appear unrelated even in the same Application Insights resource.
C
Add a custom x-correlation-id header in each service and log it with TelemetryClient.TrackEvent
Why wrong: A custom header logged as a custom event produces correlated log entries but does not integrate with Application Insights' built-in distributed tracing model. The Application Map, end-to-end transaction view, and dependency diagrams require the SDK's native W3C correlation, not custom event logging.
D
Enable Azure Monitor cross-resource queries and write a KQL join across all three services' logs
Why wrong: KQL cross-resource joins can correlate log data after the fact but do not create live distributed trace relationships. This approach requires manual query authoring for every investigation and does not produce the automatic visual correlation that W3C Trace Context provides.
An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The team wants the control to be enforceable during normal operations.
A
Issuer and signature are valid for the trusted tenant
Issuer and signature validation confirms the token came from the expected identity provider.
B
The user's display name is present
Why wrong: Display name is not a security validation control.
C
Token audience matches the API application ID URI or client ID
The audience proves the token was issued for this API.
D
The token was sent in a query string
Why wrong: Bearer tokens should not be accepted because they appear in query strings.
An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The design must avoid adding custom operational scripts.
A
Issuer and signature are valid for the trusted tenant
Issuer and signature validation confirms the token came from the expected identity provider.
B
The user's display name is present
Why wrong: Display name is not a security validation control.
C
Token audience matches the API application ID URI or client ID
The audience proves the token was issued for this API.
D
The token was sent in a query string
Why wrong: Bearer tokens should not be accepted because they appear in query strings.
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 AWS-native control.
A
Issuer and signature are valid for the trusted tenant
Issuer and signature validation confirms the token came from the expected identity provider.
B
The user's display name is present
Why wrong: Display name is not a security validation control.
C
Token audience matches the API application ID URI or client ID
The audience proves the token was issued for this API.
D
The token was sent in a query string
Why wrong: Bearer tokens should not be accepted because they appear in query strings.
These AZ-204 practice questions are part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style AZ-204 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.