Retired AZ-204 — Azure application-development foundation

AZ-204 courseware retired on 2026-05-29. The exam and Azure Developer Associate certification retired on 2026-07-31. This path preserves useful application-development concepts; it is not a current exam or certification route.

Why this path exists

Administrators and DevOps engineers need to understand the application they deploy. This path connects code, SDK calls, runtime hosting, data access, identity, messages, telemetry, and deployment boundaries. It assumes a learner can read basic code and HTTP/JSON; the prerequisite bridges will teach the Azure-specific parts.

Central mental model

An application receives a request or event, authenticates a principal, authorizes an operation, reads or writes data, emits telemetry, and runs on a managed or containerized compute boundary. A build produces an immutable artifact; a deployment promotes it into that runtime; monitoring and recovery expose whether the workload still meets its purpose.

Map / Canvas

AZ-204 application foundation relationship map

Ordered modules

1. Runtime choices: container images, ACR, ACI, Container Apps, App Service, Functions, settings, TLS, slots, and autoscale.
2. Developer data access and application security: Cosmos DB SDK/consistency/change feed, Blob SDK/properties/metadata, lifecycle policies, identity, SAS, App Configuration, Key Vault, and managed identities.
3. APIs, events, and messages: API Management, OpenAPI, Event Grid, Event Hubs, Service Bus, and Queue Storage.
4. Application observability: Application Insights, metrics, logs, traces, availability tests, and alerts.
5. Deployment and compute: artifact promotion, managed runtimes, configuration, TLS, and autoscale.
6. Functions and data events: triggers, bindings, SDK boundaries, retries, and Cosmos DB change feed.

Important relationships and comparisons

• A container image bundles application and runtime dependencies; a registry stores the image; a runtime pulls and executes it.
• A trigger starts a Function; a binding connects data; an SDK call gives the application explicit control.
• Authentication establishes who or what acts; authorization decides what that principal may do.
• Event Grid announces an occurrence; Event Hubs carries an ordered partitioned stream; Service Bus and Queue Storage carry work messages.
• A managed identity is an Azure-managed principal; a service principal is an application identity whose credential lifecycle the owner manages.
• Application Insights receives application telemetry; an alert rule evaluates a signal; an action group routes a response.

Conceptual checkpoint

For a photo-processing API, choose a compute boundary, trace an upload through identity and Blob Storage to a processing event, select the event or message service, identify the deployment artifact and runtime handoff, and explain how a failed request becomes telemetry and an actionable alert.

Next path

Continue to AZ-400 advanced DevOps.

Sources and re-audit

• AZ-204 study guide, skills measured 2026-01-14; checked 2026-08-31.
• Retired certification exams, checked 2026-08-31.
• Archived MicrosoftLearning AZ-204 structure, checked 2026-08-31; structure reference only.

Re-audit when Microsoft changes the retirement record, republishes course structure, or relevant Azure product behavior changes.

AZ-204 — Runtime choices

Route position

This is the first AZ-204 path after the shared AZ-104 foundation. It turns a program into a deployable workload by separating packaging, hosting, ingress, configuration, scaling, and promotion decisions.

Core idea

Choose the smallest compute boundary that gives the application the control and operational responsibility it actually needs. A container image packages bytes; a registry stores them; a runtime executes them; a deployment process promotes a tested version; telemetry reveals whether the runtime works.

Map / Canvas

Application foundation map

Ordered modules

1. Container images, ACR, ACI, and Container Apps
2. App Service, settings, TLS, slots, and autoscale
3. Existing shared notes: Functions, triggers, and bindings.

Key comparisons

VMs provide OS control; App Service provides a managed web runtime; ACI runs an isolated container task; Container Apps manages container revisions and scaling; Functions starts code from events, schedules, or HTTP. A deployment slot is a runtime version boundary, while an environment is a broader delivery and configuration boundary.

Checkpoint

Given a bursty image-processing API and a long-running internal worker, choose a runtime for each, identify the image/artifact handoff, state how identity reaches the registry and data store, and predict what telemetry would distinguish a bad image from a blocked network.

Sources and re-audit

• AZ-204 study guide, compute objectives, skills measured 2026-01-14; checked 2026-08-31.
• Azure compute options, checked 2026-08-31.

Re-audit when supported hosting, image, ingress, or scaling behavior changes.

AZ-204 — Data and application security

Route position

After selecting a runtime, the learner needs to decide where application state lives and how code reaches it without embedding durable credentials. This path precedes event integration and observability.

Ordered modules

1. Cosmos DB and Blob Storage through SDKs
2. Application configuration, Key Vault, SAS, and managed identities

Core relationships

The application authenticates as a principal, receives authorization at the data service, uses an SDK to make a data-plane request, and emits telemetry about the outcome. A storage lifecycle policy changes stored data over time; it is not a backup. A managed identity removes application-managed credentials, but it still needs an explicit role or data permission.

Checkpoint

Explain the complete path for an API request that reads a Blob and writes Cosmos DB: identity, authorization, SDK call, partition/key or object boundary, lifecycle consequence, and telemetry. Then diagnose a 403 as either missing permission, an expired delegation, or a wrong endpoint.

Sources and re-audit

• AZ-204 study guide, storage and security objectives, skills measured 2026-01-14; checked 2026-08-31.
• Azure storage security, checked 2026-08-31.

Re-audit when SDK, authorization, data-protection, or lifecycle behavior changes.

AZ-204 — APIs, events, and messages

Route position

This path follows runtime, data, and security. It teaches how a workload crosses service boundaries and how to choose notification, streaming, or durable work-delivery semantics.

Ordered modules

1. API Management, Event Grid, Event Hubs, Service Bus, and Queue Storage
2. Application Insights and alerting are shared with the observability route.

Core mental model

An API exposes a contract and request/response boundary. An event announces that something happened. A stream carries ordered telemetry or events for consumers. A message represents work that a consumer must process and acknowledge. The sender’s delivery guarantee and the consumer’s retry/idempotency design determine the application behavior.

Checkpoint

Given a webhook notification, clickstream, order command, and simple background job, choose Event Grid, Event Hubs, Service Bus, or Queue Storage; explain the producer/consumer boundary, retry or checkpoint behavior, and what happens when a consumer is unavailable.

Sources and re-audit

• AZ-204 integration objectives, skills measured 2026-01-14; checked 2026-08-31.
• Choose an Azure messaging service, checked 2026-08-31.

Re-audit when delivery, ordering, retry, access, or service capability changes.

AZ-204 — Application observability

Route position

This path closes the AZ-204 application loop. It follows runtime, data, identity, and integration and teaches how an application exposes evidence for diagnosis and availability decisions.

Ordered modules

1. Instrument, query, and alert on application behavior.

Core mental model

Instrumentation emits telemetry; collection stores it; queries interpret it; alert rules evaluate signals; action groups route a response. Metrics summarize numeric behavior, logs preserve structured records, and traces connect a request across components. None of these proves the workload is healthy unless the signal measures a meaningful user or service outcome.

Checkpoint

Given a failed API request, identify whether metrics, logs, or traces provide the fastest evidence; trace the signal into an alert rule and action group; and explain how an availability test differs from internal application telemetry.

Sources and re-audit

• AZ-204 monitoring objectives, skills measured 2026-01-14; checked 2026-08-31.
• Azure Monitor overview, checked 2026-08-31.

Re-audit when telemetry, query, availability-test, or alert behavior changes.

Container image

What it is

A container image is an immutable package containing an application, its runtime dependencies, metadata, and a filesystem assembled from layers. A container is a running process created from that image; the image is not the running workload.

Why it exists and what to understand first

Images make the application/runtime boundary portable and repeatable. First understand git, packages, processes, ports, and the difference between a build artifact and a runtime. A Dockerfile describes how to assemble layers; a registry stores named image tags or digests; a container host pulls and runs the image.

Relationships, choices, and failure modes

The build produces an image, Azure Container Registry stores it, and ACI or Container Apps pulls it using an authorized identity. The handoff fails when the image reference is wrong, the registry is unreachable, or the runtime principal lacks pull permission. A tag can move, so deployment traceability should prefer an immutable digest. An image is not a package feed item and does not replace an application artifact when the target runtime is not container-based.

Worked example

Northwind builds orders:2026.09.16, pushes it to ACR, records its digest, and deploys that digest to a staging revision. After health checks, it promotes the same digest. Rebuilding during promotion could make the tested and deployed bytes differ.

Where it appears

AZ-204 compute module, before ACR, ACI, Container Apps, App Service containers, and AZ-400 build/release artifacts.

Re-audit

📘 Sources: Microsoft Learn — Serverless containers in Azure and Azure Container Registry overview.

Microsoft identity platform

What it is

The Microsoft identity platform is the protocol and service model applications use to sign users or workloads in and obtain tokens for protected resources. Microsoft Entra ID is the tenant identity provider; the platform describes how an app registration, authority, scopes, consent, and tokens fit together.

Prerequisites and mechanics

Understand HTTP, principals, tenants, authorization, and JSON claims. A client requests a token for a resource scope; the identity provider authenticates the caller and issues a token when the request and consent are allowed. The API validates the token and then authorizes the operation. A valid token proves an identity context; it does not automatically grant every API or Azure resource action.

Relationships, boundaries, and failure

Authentication establishes who acts; authorization decides what that principal may do. Entra issues identity/access tokens, while Azure RBAC authorizes Azure control-plane actions and Microsoft Graph permissions authorize Graph data access. A token-audience mismatch, missing consent, expired token, or missing downstream role produces a different failure and should be diagnosed separately.

Worked example and route

A web app signs in a user, requests an API scope, sends the bearer token to the API, and the API checks both token validity and the user’s application permission. This appears before Entra app authentication, Graph, Key Vault, and managed identity in AZ-204.

Re-audit

Re-open when supported protocols, token behavior, consent, or Entra integration changes. Sources checked 2026-08-31: Microsoft identity platform overview and authentication vs authorization.

Azure API Management

What it is

Azure API Management (APIM) is a managed service for putting a gateway in front of one or more APIs. It gives callers a consistent front door while the backend APIs can remain in App Service, Functions, containers, or elsewhere. At the gateway, APIM can apply policies, then forward a request to the configured backend.

Prerequisites and mechanics

Understand HTTP requests and responses, REST resources, JSON, authentication, and OpenAPI. An API definition describes the contract that callers use; the backend implements the actual operation. APIM can import an API definition, expose a frontend API, and use a policy to validate, transform, rate-limit, cache, or route traffic at the gateway boundary.

Relationships and choices

APIM fronts an application runtime; it does not replace App Service, Functions, or a container host. It is also not automatically the authority for every business decision. A subscription key can grant access to an APIM product or API, and a gateway policy can validate a token. The backend may still need to decide whether the authenticated caller may read or change a particular record.

Worked example and route

Northwind imports an OpenAPI description for its orders API. It requires a partner token, rejects oversized requests at the gateway, and routes valid calls to the orders backend. The backend still checks whether that partner is assigned to the requested order. This topic fits after REST/JSON and identity, before event and message integration.

Re-audit

Re-open when gateway policies, API access, supported definitions, or product behavior changes. Sources checked 2026-09-17: API Management key concepts, subscriptions, and authentication and authorization.

Application Insights

What it is

Application Insights is Azure Monitor’s application-performance-monitoring feature. It collects evidence from inside a running application—requests, dependencies, exceptions, traces, and selected user interactions—so a team can understand what customers experienced rather than only what a server did.

Why it exists

Infrastructure monitoring (CPU, disk) tells you the host is fine but not why users are frustrated. Application Insights instruments the app itself to reveal request latency, error rates, failed dependencies (DBs, external APIs), and end-to-end distributed traces — the insight you need for debugging performance.

Key ideas

• Instrumentation sends application telemetry to Application Insights. For many code-based server applications, Microsoft recommends OpenTelemetry-based collection; the exact setup depends on the runtime.
• A request is work the application receives. A dependency is an external call it makes, such as to storage or a database. An exception records an error. A trace supplies diagnostic context across those operations.
• Application Map and transaction views can show how components call each other. Log Analytics and KQL support deeper analysis where configured.
• Availability tests check an endpoint from outside the application. They are useful evidence of reachability, but do not prove every user journey or dependency works.

Northwind example

When a shopper cannot submit an order, Northwind looks in Application Insights. It can see the failed checkout request, the slow call to Blob Storage, the exception message, and correlated telemetry from the same transaction. A VM CPU metric alone could show that the VM was healthy while customers still saw an application error.

Common confusion

• Application Insights is not a substitute for Azure Monitor infrastructure monitoring; it is part of that wider platform.
• Instrumentation can collect sensitive information if configured carelessly. Choose what to collect, scrub sensitive fields, limit access, and set appropriate retention.
• A successful availability test does not prove a logged-in checkout, payment, or data path is working.

How it fits (diagram)

Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/app/app-insights-overview

Where it appears in the route

Read azure-monitor first, then connect this entry to log-analytics, kql, alerts, and an application deployment.

Related

azure-monitor · log-analytics · kql · metric-alert · workbooks · northwind-traders-case-study

📘 Source: Microsoft Learn — Application Insights OpenTelemetry observability, checked 2026-09-16.