What the AZ-204 exam covers
- Develop Azure Compute Solutions152 questions
- Develop for Azure Storage141 questions
- Implement Azure Security129 questions
- Monitor, Troubleshoot, and Optimize83 questions
- Connect to and Consume Azure Services195 questions
Free AZ-204 sample questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 700.
-
You are deploying an ASP.NET Core web application to Azure App Service. The application requires a background process that runs continuously to process messages from a queue. Which feature should you use?
- ACustom warm-up handlers
- BDeployment slots
- CWebJobs with the continuous typeCorrect
- DApp Service built-in authentication
✓ Correct answer: CAzure App Service WebJobs with the continuous type are designed to run a background process that stays alive indefinitely, making them the ideal choice for long-running tasks such as continuously processing messages from a queue. Continuous WebJobs start automatically when the App Service starts and keep running until the App Service is stopped or the WebJob is disabled. They are commonly used in conjunction with the Azure WebJobs SDK to provide trigger-based processing of queue messages.
Why the other options are wrong- ACustom warm-up handlers is incorrect because warm-up handlers are used to perform initialization tasks before an instance receives traffic during slot swaps or scale-out events. They do not provide continuous background processing capabilities.
- BDeployment slots is incorrect because deployment slots are used for staging and swapping application deployments to enable zero-downtime releases. They are a deployment strategy feature and have no relation to running background processes.
- DApp Service built-in authentication is incorrect because this feature, also known as Easy Auth, provides turn-key authentication and authorization for the web application. It handles identity verification for incoming requests and does not provide any background job processing functionality.
-
Which trigger type runs an Azure Function on a schedule?
- ABlob trigger
- BQueue trigger
- CHTTP trigger
- DTimer triggerCorrect
✓ Correct answer: DThe timer trigger in Azure Functions allows you to run a function on a defined schedule using CRON expressions. When you configure a timer trigger, you specify a CRON expression that defines when the function should execute, such as every five minutes, once per hour, or at a specific time each day. The Azure Functions runtime manages the scheduling and ensures the function is invoked at the specified times. This is the only built-in trigger type specifically designed for scheduled execution.
Why the other options are wrong- ABlob trigger is incorrect because a blob trigger fires when a new or updated blob is detected in an Azure Storage container. It is event-driven based on blob changes, not based on a time schedule.
- BQueue trigger is incorrect because a queue trigger fires when a new message appears in an Azure Storage queue. It processes messages as they arrive in the queue, not on a scheduled basis.
- CHTTP trigger is incorrect because an HTTP trigger fires when an HTTP request is received at the function's endpoint. It is designed for request-response scenarios and has no scheduling capability.
-
You need to store and retrieve images in Azure Blob Storage with the lowest possible latency. The images are accessed frequently during the first week and rarely after that. Which storage tier strategy should you implement?
- AStore in the Premium block blob tier permanently for all images
- BStore all images in the Cool tier from the beginning for the whole lifetime
- CStore in Hot tier and configure a lifecycle management policy to move to Cool after 7 daysCorrect
- DStore all images in the Archive tier and rehydrate to Hot on demand
✓ Correct answer: CStoring images in the Hot tier initially ensures the lowest possible access latency during the first week when images are frequently accessed. The Hot tier is optimized for data that is accessed frequently, with the lowest access costs but higher storage costs compared to cooler tiers. By configuring an Azure Blob Storage lifecycle management policy, you can automatically transition blobs to the Cool tier after 7 days based on the last modified date. The Cool tier has lower storage costs but slightly higher access costs, making it ideal for data that is accessed infrequently. This tiered approach optimizes costs by matching the storage tier to the actual access pattern over time.
Why the other options are wrong- APremium block blob delivers low latency but is far more expensive per GB, and paying that rate forever for images that are rarely accessed after a week is not cost-effective.
- BThe Cool tier carries higher access costs and an early-deletion penalty; using it during the first week of frequent access raises costs and latency instead of lowering them.
- DArchive is offline storage with hours-long rehydration latency, so it cannot serve the frequent first-week reads that require the lowest possible latency.
-
You have an Azure Function that needs to read secrets from Azure Key Vault. You want to avoid storing any credentials in code or configuration. Which approach should you use?
- AUse a service principal with a client secret stored in app settings
- BStore a Key Vault SAS token in an app setting and read secrets with it
- CAuthenticate with a certificate embedded in the deployment package
- DUse a managed identity for the Function App and grant it access to Key VaultCorrect
✓ Correct answer: DUsing a managed identity for the Azure Function App is the most secure and recommended approach for accessing Azure Key Vault without storing any credentials. When a managed identity is enabled on the Function App, Azure automatically provisions and manages the identity's credentials. The Function App can then authenticate to Key Vault using this identity, and access is granted through either Key Vault access policies or Azure RBAC. This approach eliminates the need to store, rotate, or manage any secrets, connection strings, or credentials in code, configuration files, or environment variables, following the zero-credential security principle.
Why the other options are wrong- AStoring a client secret in app settings still keeps a credential in configuration, which contradicts the requirement; the secret is visible in exports and must be rotated manually before it expires.
- BKey Vault does not issue SAS tokens for secret access; it authenticates through Microsoft Entra ID, and any stored token would itself be a credential the requirement says to avoid.
- CA certificate shipped inside the deployment package is a credential you must store, protect, and rotate, so it fails the goal of holding no credentials in code or configuration.
-
A developer is using Microsoft Graph to read the signed-in user's profile in a single-page application (SPA). The developer uses MSAL.js to acquire tokens. Which token should the developer include in the request to Microsoft Graph?
- AThe ID token in the Authorization header
- BThe refresh token in the Authorization header
- CThe access token as a query string parameter
- DThe access token in the Authorization header as a Bearer tokenCorrect
✓ Correct answer: DWhen a single-page application calls Microsoft Graph, it must present the OAuth 2.0 access token acquired by MSAL.js in the HTTP Authorization header using the Bearer scheme, in the form Authorization: Bearer {access_token}. The access token is a JWT whose scopes (such as User.Read) authorize the specific Graph operations, and Graph validates that token to authorize the request. MSAL.js obtains this token silently or interactively and the app attaches it to every Graph request.
Why the other options are wrong- AThe ID token in the Authorization header is wrong because an ID token is an OpenID Connect artifact that proves the user's identity to the client application; it is not an authorization credential for a resource API, and Microsoft Graph will reject it because it is not issued for the Graph audience.
- BThe refresh token in the Authorization header is wrong because a refresh token is a long-lived credential used only by the client (via MSAL.js and the token endpoint) to obtain new access tokens; it is never sent to a resource API such as Microsoft Graph and would be rejected.
- CThe access token as a query string parameter is wrong because, although it is the correct token, placing it in the query string exposes it in server logs, browser history, and referrer headers; Microsoft Graph expects the bearer token in the Authorization header, not the URL.
-
A developer is optimizing an Azure Cosmos DB application that performs frequent point reads of individual documents by their ID. The current implementation uses queries with SELECT * FROM c WHERE c.id = @id. How should the developer optimize these reads?
- AUse ReadItemAsync with the document ID and partition key instead of a queryCorrect
- BIncrease the provisioned throughput so the point-read query consumes fewer RUs relatively
- CEnable server-side result caching so repeated id lookups return from cache
- DAdd a composite index on the id field to speed up the equality filter
✓ Correct answer: AReadItemAsync is a direct-read operation in Azure Cosmos DB that retrieves a single document by its ID and partition key without executing a query, making it significantly more efficient than running a SELECT query. Direct reads consume less throughput (1 RU instead of variable RUs based on query complexity) and have lower latency because they bypass the query engine entirely. When you know the exact document ID and partition key, using ReadItemAsync is the optimal approach for point reads in Cosmos DB. This is a fundamental optimization technique for applications performing frequent lookups by document ID.
Why the other options are wrong- BAdding throughput raises capacity and cost but a query still costs more RUs and latency than a direct point read; it does not change that a query is the wrong access pattern here.
- CThe integrated cache helps repeated identical reads but does not convert a query into an efficient point read; a direct ReadItemAsync is the correct optimization for lookups by id.
- DThe id and partition key are already indexed and directly addressable; a point read bypasses the query engine entirely, so adding an index does not match the direct-read optimization.
-
You are designing an Azure Event Grid solution. Which TWO event delivery guarantees does Event Grid provide? (Select two.)
- AExponential backoff retry with configurable retry count and TTLCorrect
- BGuaranteed in-order delivery of all events
- CExactly-once delivery with deduplication
- DAt-least-once delivery to each event subscriptionCorrect
✓ Correct answer: A, DAzure Event Grid provides specific delivery guarantees designed for reliable event distribution. First, Event Grid implements exponential backoff retry with configurable retry count and time-to-live (TTL), meaning when delivery fails, Event Grid automatically retries using progressively longer intervals between attempts until the TTL expires or maximum retry count is reached. This mechanism handles transient failures while eventually giving up on permanently unreachable endpoints. Second, Event Grid provides at-least-once delivery semantics, guaranteeing that each event is delivered at least once to each subscription; however, in rare failure scenarios, duplicate delivery may occur. These guarantees together ensure that events reach subscriptions reliably without being silently lost.
Why the other options are wrong- BEvent Grid does not guarantee exactly-once delivery (preventing all duplicates) or in-order delivery across multiple events, as these guarantees would require significantly increased complexity and would conflict with the scalability design. Guaranteed in-order delivery of all events is incorrect because Event Grid does not guarantee strict ordering across all events; ordering is not preserved when multiple subscriptions receive the same event.
- CExactly-once delivery with deduplication is incorrect because Event Grid provides at-least-once semantics, which may result in duplicates in edge cases.
-
A team is planning Connect procedures for Connect to and Consume Azure Services. What should they prioritize?
- AWire up service connections manually in the portal for each environment
- BAutomate repeatable processes using infrastructure as codeCorrect
- CKeep connection scripts on a single engineer's workstation
- DRecreate integrations by hand from a written checklist each time
✓ Correct answer: BAutomation through infrastructure as code (IaC) is essential for managing Azure services at scale. IaC enables teams to define cloud resources in version-controlled, declarative code that can be repeatedly deployed with consistent results. This approach eliminates manual configuration errors, reduces deployment time, and enables CI/CD integration for continuous delivery. IaC provides auditability, rollback capabilities, and documentation of infrastructure changes that manual processes cannot achieve.
Why the other options are wrong- AWiring up connections manually per environment is not repeatable and drifts between deployments, unlike declarative IaC applied consistently.
- CConnection scripts kept on one engineer's workstation are unversioned and unshared, creating a single point of failure rather than reviewable automation.
- DRecreating integrations by hand from a checklist reintroduces manual error and inconsistency that infrastructure as code is designed to eliminate.
-
A web app intermittently fails to reach a downstream Azure SQL Database because of brief, self-correcting network and throttling errors. The team wants the app to recover automatically from these short-lived errors while backing off so it does not overwhelm a struggling dependency. Which TWO resilience techniques should they implement? (Choose two.)
- ARetry with exponential backoffCorrect
- BSmart Detection
- CCircuit breaker patternCorrect
- DAvailability tests
- ECache-aside pattern
✓ Correct answer: A, CRetry with exponential backoff reattempts transient failures with progressively longer delays, which handles brief throttling and network blips without immediate hard failure. The circuit breaker pattern trips open when errors persist so the app fails fast and stops sending requests to a struggling dependency, giving it time to recover. Combining both yields graceful recovery plus protection against overload.
Why the other options are wrong- BSmart Detection is a monitoring feature that alerts on anomalies; it does not make the app recover from transient call failures.
- DAvailability tests observe endpoint uptime but do not implement retry or overload protection in the calling code.
- EThe cache-aside pattern improves read performance by caching data and does not address transient fault recovery or dependency protection.
-
You configure an Azure Cosmos DB account with multi-region writes enabled across three regions for a globally distributed app. Two users in different regions update the same document concurrently. By default, which conflict-resolution behavior applies, and how can you customize it for the SQL (NoSQL) API?
- AAll conflicts are written to a conflicts feed for manual resolution, because the NoSQL API has no automatic conflict policy
- BLast-Writer-Wins based on a system timestamp by default; you can change the conflict-resolution path to a custom numeric property or use a stored procedure for custom resolutionCorrect
- CThe write in the account's primary write region always wins, and writes from secondary regions are silently discarded
- DStrong consistency is enforced automatically once multi-region writes are enabled, so write conflicts cannot occur
✓ Correct answer: BWhen multiple regions accept writes, concurrent updates to the same item can conflict. The default conflict-resolution policy is Last-Writer-Wins (LWW) using the system-defined timestamp (_ts), keeping the document with the highest value. For the NoSQL API you can instead designate a custom integer property as the LWW comparison path, or select a Custom policy backed by a merge stored procedure; unresolved custom conflicts are surfaced in the conflicts feed. This flexibility is core to designing globally distributed, multi-master apps.
Why the other options are wrong- AThe conflicts feed is only used when you select the custom (manual) resolution mode; the NoSQL API's default is automatic Last-Writer-Wins, so conflicts are not routed to a feed by default.
- CThere is no fixed primary-region-wins rule in multi-region writes; the default tiebreaker is the highest system timestamp under Last-Writer-Wins, and no region silently discards writes.
- DStrong consistency is not compatible with multi-region writes, so conflicts absolutely can occur and are resolved by the account's conflict-resolution policy.
Related Microsoft resources
- AZ-204 study guideKey concepts
- Microsoft practice examsAll Microsoft
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- SC-200 practice examRelated
- AZ-140 practice examRelated
- AZ-900 practice examRelated
AZ-204 practice exam FAQ
How many questions are in the AZ-204 practice exam on CertGrid?
CertGrid has 700 practice questions for AZ-204: Azure Developer Associate, covering 5 exam domains. The real AZ-204 exam is 40-60 qs in 100 min. CertGrid's timed mock is a fixed 50 questions.
What is the passing score for AZ-204?
The AZ-204 exam passing score is 70%, and you have about 100 min to complete it. CertGrid scores your practice attempts the same way so you know when you are ready.
Are these official AZ-204 exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the AZ-204: Azure Developer Associate exam.
Can I practice AZ-204 for free?
Yes. You can start practicing AZ-204: Azure Developer Associate for free with daily practice and sample questions. Paid plans unlock full timed exams, complete explanations, and domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Microsoft. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.