ASP.NET Core interview questions covering senior asp.net core real-world scenarios.
Open a question for the full answer, code and interview guidance.
Start with measurements rather than assumptions. Check request latency percentiles, traces, structured logs, CPU, memory, database timings, outgoing HTTP calls, thread-pool behavior, and cache effectiveness. A distributed trace can show whether the time is spent in middleware, application code, the database, or a downstream service.
Compare the production environment with local development systematically. Verify the deployed build, runtime, environment name, configuration sources, connection strings, file permissions, certificates, network access, database schema, reverse-proxy settings, and external-service endpoints.
Keep request processing stateless where practical so multiple instances can serve traffic behind a load balancer. Use asynchronous I/O, efficient database queries, pagination, appropriate caching, connection pooling, response compression, and bounded outbound calls.
For browser forms, the Post/Redirect/Get pattern prevents ordinary refreshes from resubmitting a successful POST, but it does not solve all duplicate-request scenarios.
Do not keep an HTTP request open for minutes when the work can be performed asynchronously. Validate and accept the request, create a job record, enqueue durable work, and return an identifier that the client can use to query status.
Use IHttpClientFactory, set an appropriate timeout, propagate cancellation, and classify failures. Apply retries only to transient failures and only when retrying the operation is safe. Backoff and jitter help avoid synchronized retry storms.
First determine whether the failure is actually transient. Temporary connectivity or failover conditions may justify a limited retry strategy, while constraint violations or invalid SQL will not improve by retrying.
Use a concurrency strategy appropriate to the business rule. Optimistic concurrency is common: store a concurrency token and include it in the update condition. If another request changed the row first, the second update detects the conflict instead of silently overwriting data.
Decide what can be stale and for how long before choosing a cache. For data that is identical for all users, cache a compact DTO using a stable key such as product:{id}. Use explicit expiration and invalidate or replace the entry when the product changes.
Require authentication and explicit authorization, preferably through a role or policy that represents administrative permission. Apply the requirement at the area/controller or endpoint boundary so new actions do not accidentally become public.
Identify the tenant from a trusted source, such as authenticated claims, a validated host mapping, or another controlled tenant-resolution mechanism. Do not trust an arbitrary tenant ID from the request without verifying the user is entitled to that tenant.
Set explicit size limits and validate the upload according to business requirements. Do not trust the client-provided file name or Content-Type as proof of file contents. Generate a server-side storage name and keep untrusted uploads outside executable application paths.
Use a stream-based response so the server can transfer data progressively rather than creating a large byte array. The underlying storage API should also support streaming.
Measure the process over time and determine whether memory is stable under load, grows because of legitimate caching, or continuously accumulates. Inspect GC metrics, allocation rates, large object heap activity, memory dumps, and profiler results.
Look for increasing request latency and queued work while CPU is not necessarily saturated. Runtime counters, traces, and dumps can reveal thread-pool growth and blocked threads.
The request path should create the business state and enqueue an email command rather than waiting for a slow mail server when immediate delivery is unnecessary. A background worker consumes the queue and sends messages.
The transactional outbox pattern addresses the problem of updating a database and publishing a message as one logical business operation when there is no distributed transaction across both systems.
Use backward-compatible schema evolution so the old and new application versions can operate during the deployment overlap. A common expand-and-contract approach first adds compatible schema, then deploys code that can use it, migrates data if necessary, and only later removes obsolete columns or behavior.
Keep ordinary non-secret defaults in configuration files and override environment-specific values through deployment configuration. Store passwords, API keys, certificates, and signing credentials in a protected secret store or platform secret mechanism rather than source control.
Version an API when incompatible contract changes must coexist with existing clients. Decide whether versions are expressed in the URL, query string, header, or media type and keep the convention consistent.
Require authentication where appropriate and apply authorization to sensitive operations. Add rate limiting or concurrency limiting based on a meaningful partition such as client identity, API key, tenant, or endpoint.
Use centralized structured logs, exception details in protected telemetry, correlation or trace IDs, and distributed traces. Capture the request path, application version, instance, dependency timings, and safe contextual identifiers so failures can be grouped and compared.
Set bounded timeouts so calls fail promptly instead of consuming resources indefinitely. Use limited retries with backoff only for transient and retry-safe operations, and use circuit-breaking behavior when repeated failures indicate a dependency is unavailable.
Verify that Release builds and automated tests pass, configuration is valid, migrations are reviewed, secrets are externalized, and production error handling does not expose internals. Review authentication, authorization, anti-forgery requirements, CORS, upload/request limits, forwarded headers, HTTPS, and security-sensitive cookies.
Start from the request boundary and explain responsibilities rather than listing technologies. Describe how traffic reaches the host, how middleware handles cross-cutting concerns, how routing reaches controllers or endpoints, and how application services coordinate business use cases.