ASP.NET Core Web API interview questions covering error handling, logging, caching, rate limiting, CORS and reliability.
Open a question for the full answer, code and interview guidance.
Centralized exception handling catches unhandled exceptions at a common point in the HTTP pipeline instead of repeating try/catch blocks in every controller action. It is typically implemented with ASP.NET Core exception-handling middleware.
Repeated try/catch logic makes controllers noisy and often produces inconsistent logging and response formats. Expected business outcomes should normally be represented explicitly, while unexpected exceptions can be handled centrally.
ProblemDetails is a standardized structure for HTTP API errors. It commonly includes type, title, status, detail, and instance, and can be extended with additional safe metadata such as a trace identifier.
Validation errors are expected client-facing failures and should identify invalid input with an appropriate 4xx status and useful field-level details. Unexpected exceptions indicate an unplanned server failure and normally result in a safe 500 response.
Structured logging records named properties separately from the human-readable message. This lets logging systems filter, aggregate, and search by fields such as OrderId, UserId, or elapsed time.
Common levels are Trace, Debug, Information, Warning, Error, and Critical. The level should reflect the operational significance of an event rather than simply how much text is being logged.
Avoid logging passwords, access tokens, refresh tokens, private keys, connection strings, payment secrets, and unnecessary personal or confidential information. Request and response bodies can also contain sensitive data and should not be logged indiscriminately.
A correlation or trace identifier lets related log entries and distributed operations be connected to the same request or workflow. ASP.NET Core exposes request tracing information through HttpContext, and distributed tracing can propagate context across service boundaries.
Response caching stores and reuses HTTP responses according to HTTP caching semantics and cache headers. It is most suitable for responses that can safely be reused for equivalent requests.
Output caching stores endpoint responses on the server and can reuse them according to configured policies. It provides application-controlled caching behavior and can reduce repeated work for suitable endpoints.
In-memory caching stores data in the memory of the current application process. It is fast and simple for data that is safe to recreate and where process-local cache behavior is acceptable.
A distributed cache is shared by multiple application instances, commonly through a dedicated system such as Redis or another supported distributed-cache provider. It can support consistent cached data across a scaled-out API.
Cache invalidation removes or replaces cached data when it is no longer valid. Common strategies include time-based expiration, explicit removal after writes, versioned keys, and event-driven invalidation.
Rate limiting restricts the number or rate of requests accepted for a client or partition. It can protect service capacity, reduce accidental overload, and enforce usage policies.
429 Too Many Requests indicates that a client has exceeded an applicable request limit. A rate-limited API may also provide retry information such as a Retry-After header when the policy can determine an appropriate delay.
CORS controls whether browser JavaScript from one origin is permitted to read responses from another origin. It is enforced by browsers and is important for frontend integration.
For certain cross-origin requests, a browser first sends an OPTIONS request to ask whether the actual method, headers, and origin are permitted. This is called a preflight request.
A timeout limits how long an operation is allowed to wait before it is treated as failed. Without suitable timeouts, slow downstream dependencies can consume request resources for excessive periods and contribute to cascading failures.
A retry policy repeats an operation after a transient failure that may succeed on a later attempt, such as a brief network interruption. Retries should use bounded attempts and usually delay or backoff between attempts.
A circuit breaker temporarily stops calls to a dependency after repeated failures. This prevents every incoming request from continuing to wait on a dependency that is already known to be unhealthy.
POST is not inherently idempotent, so retrying a request can create duplicate orders, payments, or other effects. For operations where clients may safely retry, the API can support an idempotency key and remember the result associated with that key.
Health checks expose application health information for infrastructure such as orchestrators, load balancers, and monitoring systems. Checks can report whether the process is running and whether critical dependencies are available.
A liveness check answers whether the application process is alive enough to continue running. A readiness check answers whether the instance is currently ready to receive traffic.
Use bounded timeouts, cancellation, carefully targeted retries, circuit breakers, fallback behavior where semantically safe, and clear failure responses. Monitor downstream latency and failure rates so reliability problems are visible.
Handle unexpected exceptions centrally and return consistent, safe ProblemDetails responses. Use structured logs with correlation or trace identifiers while excluding secrets and unnecessary sensitive data. Distinguish expected client errors from unexpected server failures.