AZ-204 Develop Azure compute solutions Practice Question
A company runs an ASP.NET Core web app on Azure App Service. They need to implement health checks that monitor the app's dependencies, such as a database and an external API. The health endpoint should return a 200 status if all dependencies are healthy, a 503 if any dependency is unhealthy, and a 400 if the request is malformed. Which approach should you take?
⚠ Common exam trap
Many candidates confuse the built-in Azure App Service health check endpoint (which only returns 200 OK for the app's root) with the customizable ASP.NET Core Health Checks middleware that supports dependency monitoring and custom status codes.
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
✓
Implement custom health checks using the ASP.NET Core Health Checks middleware.
The ASP.NET Core Health Checks middleware allows you to implement custom health checks that monitor specific dependencies like a database and an external API. You can configure the middleware to return a 200 OK status when all checks pass, a 503 Service Unavailable when any check fails, and a 400 Bad Request for malformed requests by using the appropriate response writer and status code mapping.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement custom health checks using the ASP.NET Core Health Checks middleware.
Why this is correct
The ASP.NET Core Health Checks middleware provides a robust and extensible framework for monitoring the operational health of an application and its dependencies. Developers can register custom health checks for various components like databases, external APIs, or message queues, defining specific logic to determine their status. This middleware exposes an endpoint that returns detailed health reports, allowing for custom HTTP status codes (e.g., 200 for healthy, 503 for unhealthy, or even 400 for specific application-defined issues) based on the aggregated health of all registered checks, making it ideal for granular application-level monitoring.
- ✗
Use the ASP.NET Core Diagnostics middleware to generate a health page.
Why it's wrong here
The ASP.NET Core Diagnostics middleware, primarily exemplified by `UseDeveloperExceptionPage` or `UseExceptionHandler`, is designed to assist developers by providing detailed error information during development or a user-friendly error page in production. It is not intended for programmatic health monitoring by external systems or for reporting the operational status of application dependencies. This middleware focuses on error handling and display, rather than exposing a structured, machine-readable health endpoint for automated checks.
- ✗
Configure Application Insights availability tests.
Why it's wrong here
Application Insights availability tests are external synthetic monitors that periodically send HTTP requests to a specified URL to assess basic reachability and response time from various geographic locations. While they can confirm if an endpoint is responding, these tests operate from outside the application's process and cannot inspect internal component health, database connectivity, or other critical application dependencies. They are a valuable monitoring tool for uptime, but they do not provide an internal health endpoint for other services to query.
- ✗
Use the built-in health check endpoint in Azure App Service.
Why it's wrong here
The built-in health check feature in Azure App Service allows the platform to monitor a specific path within your web application to determine if an instance is responsive. This feature primarily serves for platform-level instance management, such as removing unhealthy instances from a load balancer, and typically only distinguishes between healthy (200-299 status) and unhealthy (any other status, often resulting in a 503). It does not support custom health logic or the ability to return specific, application-defined HTTP status codes like 400 based on granular internal application state.
Go deeper
Related to this question
About these practice questions
One of 881 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.