Concept questionMedium~7 minAuthorization Boundaries / 4 of 7

Interview question

How would you use ASP.NET Core policy-based authorization for API permissions?

Use ASP.NET Core policies for authorization

Explains policy-based authorization, requirements, handlers, claims, capabilities, and resource-aware checks.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would define policies for important capabilities or security requirements, then apply them to endpoints with authorization attributes or endpoint metadata. The policy can require an authenticated user, specific claims, roles, or capabilities. For resource-specific checks, a handler can evaluate both the user and the target resource.

Full answer below

Practice focus

Policies, requirements, handlers, claims, capabilities, resource checks, endpoint protection, and testability.

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
Policy-based authorization keeps security rules out of scattered if-statements. It also makes permission checks easier to test and review.
I would define policies for important capabilities or security requirements, then apply them to endpoints with authorization attributes or endpoint metadata. The policy can require an authenticated user, specific claims, roles, or capabilities. For resource-specific checks, a handler can evaluate both the user and the target resource.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid putting all authorization into controller code. Policies give a consistent entry point, but they still need the right level of detail. A simple endpoint can require content.update; a resource-sensitive endpoint may load the target and check ownership, tenant membership, status, or workflow state. If claims are stale, the handler may need to consult current application data.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate reusable requirements from handlers that know how to evaluate claims or resource state. Policy names and capability values live in one contract, failures deny by default, and handlers do not perform side effects. Resource authorization uses narrow queries and avoids loading the same object repeatedly when the endpoint already has trusted state. Integration tests prove middleware, endpoint metadata, fallback policies, and handler registration work together, including anonymous, stale-claim, cross-tenant, and administrative paths.

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

Hardcoding role checks in many controllers.
Using broad policies that hide resource-specific rules.
Not testing denied paths.
Doing expensive authorization queries without measurement.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain policy, requirement, and handler roles.
No resource-aware authorization story.
No central policy naming or tests.
Treats claims as always fresh application state.

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.

When do you need a resource-based handler?
What belongs in a policy name?
How would you test authorization failures?

Continue the section

Next in Authorization Boundaries: Admin Audit

Step 5 of 7

Audit privileged admin actions

Opening drill

Concept questionMedium~7 minAuthorization Boundaries / 4 of 7

Interview question

How would you use ASP.NET Core policy-based authorization for API permissions?

Use ASP.NET Core policies for authorization

Explains policy-based authorization, requirements, handlers, claims, capabilities, and resource-aware checks.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Policies, requirements, handlers, claims, capabilities, resource checks, endpoint protection, and testability.

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
Policy-based authorization keeps security rules out of scattered if-statements. It also makes permission checks easier to test and review.
I would define policies for important capabilities or security requirements, then apply them to endpoints with authorization attributes or endpoint metadata. The policy can require an authenticated user, specific claims, roles, or capabilities. For resource-specific checks, a handler can evaluate both the user and the target resource.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid putting all authorization into controller code. Policies give a consistent entry point, but they still need the right level of detail. A simple endpoint can require content.update; a resource-sensitive endpoint may load the target and check ownership, tenant membership, status, or workflow state. If claims are stale, the handler may need to consult current application data.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate reusable requirements from handlers that know how to evaluate claims or resource state. Policy names and capability values live in one contract, failures deny by default, and handlers do not perform side effects. Resource authorization uses narrow queries and avoids loading the same object repeatedly when the endpoint already has trusted state. Integration tests prove middleware, endpoint metadata, fallback policies, and handler registration work together, including anonymous, stale-claim, cross-tenant, and administrative paths.

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

Hardcoding role checks in many controllers.
Using broad policies that hide resource-specific rules.
Not testing denied paths.
Doing expensive authorization queries without measurement.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain policy, requirement, and handler roles.
No resource-aware authorization story.
No central policy naming or tests.
Treats claims as always fresh application state.

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.

When do you need a resource-based handler?
What belongs in a policy name?
How would you test authorization failures?

Continue the section

Next in Authorization Boundaries: Admin Audit

Step 5 of 7

Audit privileged admin actions

How would you use ASP.NET Core policy-based authorization for API permissions?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you use ASP.NET Core policy-based authorization for API permissions?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section