How would you test an ASP.NET Core endpoint whose result depends on capabilities, resource ownership, and tenant membership?

Test authorization and tenant isolation

Designs integration tests for authentication, capabilities, ownership, account status, and cross-tenant isolation without bypassing the real authorization pipeline.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would run integration tests through the real ASP.NET Core pipeline with a test authentication scheme that can create controlled identities and claims. For each protected operation I would cover unauthenticated, authenticated without permission, allowed capability, owner, non-owner, and cross-tenant cases. I would assert the status and response contract, then verify that denied writes changed no data. The test data would include similar resources in two tenants so a missing tenant filter cannot accidentally pass.

Full answer below

Practice focus

Authorization matrices, authenticated test identities, 401 and 403 behavior, ownership, tenant isolation, side effects, and data-leak prevention.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Authorization bugs often return valid data to the wrong person, so a happy-path unit test is not enough. The valuable evidence crosses routing, authentication, policy evaluation, resource lookup, and the final data boundary.
I would run integration tests through the real ASP.NET Core pipeline with a test authentication scheme that can create controlled identities and claims. For each protected operation I would cover unauthenticated, authenticated without permission, allowed capability, owner, non-owner, and cross-tenant cases. I would assert the status and response contract, then verify that denied writes changed no data. The test data would include similar resources in two tenants so a missing tenant filter cannot accidentally pass.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would express the cases as an access matrix rather than many unrelated tests. The dimensions include account status, membership, capability, resource ownership, tenant, and operation, with parameterized cases for the meaningful combinations. Authentication can be substituted at the identity-provider boundary, but the application's policies and handlers remain real. For reads I would check both direct lookup and list endpoints because filtering leaks can differ from resource authorization. For writes I would verify side effects, audit events where required, and the absence of information that reveals another tenant's resource.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For the highest-risk paths I would run the matrix against the production database provider in an isolated disposable environment, because global filters, collation, query translation, and constraints are part of the boundary. I would add regression cases for role changes, disabled memberships, permission-cache invalidation, and stale sessions when those behaviors exist. A smaller end-to-end identity-provider test can verify token validation without making every authorization test depend on an external service. I would maintain an endpoint-policy inventory check that fails when a protected operation has no registered access-matrix coverage.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Testing only an administrator and one successful request.
Mocking the authorization handler so the real policy never runs.
Asserting a denied status without checking that data was unchanged.
Using one tenant in all fixtures and missing cross-tenant leaks.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Ownership and tenant checks exist only in controller branches.
List endpoints and direct resource endpoints use different isolation rules.
A denied response reveals whether another tenant's identifier exists.
New protected endpoints can be added without any access-matrix coverage.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Would you return 403 or 404 for a resource in another tenant?
How would you test a role change during an active session?
Which part of authentication would you replace in an integration test?

Continue the section