Microsoft retired AZ-204, Developing Solutions for Microsoft Azure, on July 31, 2026. That makes it inappropriate to present an old exam study checklist as a route to a presently bookable Azure Developer Associate credential. Its engineering topics, however, still describe problems that Azure developers solve: delivering an API, persisting data, handling events, protecting secrets, observing failures and shipping changes safely. This article turns those enduring concepts into a bounded set of practical engineering exercises rather than repeating a comparison of retired AZ-204 with its AI-200 replacement.<\/p>\n
The exercise is a small task-processing application. Users submit jobs through a secured API, receive an acknowledgment, and later retrieve processing status. The application stores request metadata, queues work, invokes a worker, writes results and emits useful telemetry. Each section produces an artifact or a testable observation. You can work through it with authorized development resources, but do not copy production credentials or customer data into a learning subscription.<\/p>\n
Define who can submit a task, what data a task contains, how long processing may take, and what a failure should mean to a caller. In the example, a submission has a unique request identifier, tenant context, creation timestamp, state and optional result reference. An API accepts a validated request and returns an acknowledgment without pretending the background work is already complete. Define a maximum payload size and retention period before choosing services. Those limits prevent later surprises in billing, privacy and queue behavior.<\/p>\n
Draw the application boundary: public client, authenticated API, managed identity, data store, message broker, worker and monitoring. The trust boundary between a caller and the API differs from the boundary between the worker and storage. Record which component creates the job, which performs it and which can cancel it. An observable failure path is essential: if the worker fails permanently, the job should not remain silently marked running forever. This design contract will guide every following deployment choice.<\/p>\n
Keep the lab cost-bounded. Choose a nonproduction resource group, establish a spend alert and decide when resources will be removed. If a service tier or region is unavailable, use an approved equivalent or document the limitation without implying a test passed. The goal is to prove architectural decisions and operational behavior, not to install every Azure service that appeared on the historical AZ-204 objective list.<\/p>\n
Implement a POST operation for new tasks and a GET operation for status. Validate the input schema, reject unknown or oversized fields and return consistent error codes. Avoid inserting raw customer-supplied values into resource names, query strings or logs. Give each accepted task a server-controlled identifier so clients cannot impersonate another user’s job by choosing an ID. A simple contract test should cover missing authorization, invalid input, duplicate submission and a valid request.<\/p>\n
Azure App Service and Azure Functions can both host useful application entry points, but their scaling, execution, hosting and operational characteristics differ. Select based on how the workload runs: a consistently used API with application-specific hosting requirements may favor one approach, while an event-oriented handler may favor another. Do not claim a single choice guarantees lower cost. Document connection limits, timeout behavior, cold-start tolerance where relevant and the observability you need before deployment.<\/p>\n
An API fronted by Azure API Management<\/a> can gain centralized policy and gateway controls in appropriate architectures. This does not replace authorization inside the API. A gateway rate limit may reduce abusive traffic, but the application still needs a correct tenant and resource access decision. Test that a caller with valid authentication cannot retrieve a different tenant’s task. Record the denied result alongside one accepted request; positive-only tests hide important security defects.<\/p>\n The task application needs durable metadata with predictable access by task identifier. A relational database, Azure Table Storage or Cosmos DB can each be reasonable depending on indexing, transactions and query patterns. Define the critical operations before selecting a data store: create a job, update its state with concurrency protection, fetch by ID and list recent jobs by authorized owner. A schema or container that is convenient for one sample query should not force cross-tenant scans in production.<\/p>\n If the worker produces a file, keep the large result in Blob Storage and save a scoped reference in the metadata store rather than returning a huge payload inside a queue message. Configure retention, access policy and recovery behavior for both the metadata and the object. A backup of only the result file cannot reconstruct the processing state if the task database has been lost. Test how a caller responds when metadata exists but the referenced blob was removed or is temporarily unavailable.<\/p>\n Use optimistic concurrency so that a slow worker cannot overwrite a newer terminal state. For example, an authorized cancellation might win a race against a completion update; the application must define which transition is allowed and reject an invalid change. Track explicit state transitions instead of treating status as an unrestricted text field. For a high-volume design, understand how partition keys, transaction boundaries and reads affect cost. Never equate encrypted storage with a guarantee of recoverability.<\/p>\n After an API accepts a job, it can place a work message into a durable queue for asynchronous execution. The API acknowledgment means that the request has been accepted into the defined workflow, not necessarily completed. Choose queue semantics based on ordering, retry, duplicate handling and poison-message behavior. Azure Service Bus<\/a> offers messaging capabilities relevant to more controlled enterprise workflows, but no broker removes the need for application idempotency and explicit acknowledgment rules.<\/p>\n A duplicate delivery may occur after a worker processes a message successfully but fails before recording its completion. Make the operation safe to repeat by using a stable job identifier, recording completed work and checking whether a side effect has already occurred. Avoid automatically retrying a permanently invalid payload forever. Define when to move a message to a dead-letter handling process, what diagnostics can be retained and who is authorized to replay it.<\/p>\n Event Grid supports event-distribution patterns rather than serving as an interchangeable replacement for every work queue. Decide whether the system needs a durable command to perform a task, or a notification that an event already happened. A single workflow may use both, but the difference must remain clear in documentation and testing. Run a controlled consumer outage, verify eventual processing, and record the system’s visible state during the interruption. The presence of messages alone does not prove successful business processing.<\/p>\n Give the API and worker separate managed identities when their tasks and data scopes differ. An identity used to enqueue work need not also be permitted to delete results. Assign narrowly scoped data-plane roles and check the authorization mechanism supported by each service. Roles to administer an Azure resource do not necessarily grant permission to read or write its application data. Test denials deliberately: a worker missing a required role should fail clearly, not silently fall back to an embedded account key.<\/p>\n Azure Key Vault<\/a> can protect secrets, keys and certificates in appropriate configurations, but a secret vault is not a substitute for eliminating secrets when managed identity will work. Keep development configuration distinct from production configuration and do not commit connection strings or vault credentials into a repository. Record who can rotate a secret, who can grant access and how an application responds when rotation happens while requests are in flight.<\/p>\n For external clients, distinguish authentication from authorization. Valid bearer tokens do not automatically grant access to every task record. Validate intended audiences, issuers and relevant scopes or roles; then enforce resource ownership based on trusted claims and application state. If the application receives data from multiple tenants, avoid inferring tenant authority from a client-provided request body alone. Capture only sanitized identity context in diagnostics, and never log raw credentials or complete authentication tokens.<\/p>\nChoose Storage by State and Recovery Behavior<\/h2>\n
Use Messages and Events for Different Reasons<\/h2>\n
Use Managed Identity and Keep Secrets Out of Code<\/h2>\n
Instrument the API and Worker as One Workflow<\/h2>\n