QA interview guide

How would you test roles and permissions?

Roles and permissions questions test whether you understand authorization, not just hidden buttons. A strong answer checks UI, API, data visibility, session behavior, and privilege escalation paths.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

Interviewers expect role matrix coverage, allowed and forbidden actions, backend authorization, 401 and 403 responses, IDOR, tenant isolation, direct URL or API access, role changes, cached permissions, and audit logs.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Functional and RBAC checks

  • Each role can access allowed features and cannot access forbidden features.
  • Admin-only actions, owner-only actions, member actions, guest actions, and read-only restrictions work.
  • Hidden UI actions, disabled controls, and access denied pages match permission rules.

Permission changes and sessions

  • Role upgrade, downgrade, removal, conflicting roles, and multiple roles update access correctly.
  • Existing sessions, cached permissions, expired tokens, and revoked tokens reflect permission changes.
  • Last admin protection and role assignment rules prevent unsafe account states.

Security and backend risks

  • Direct URL access and direct API access are denied when unauthorized.
  • Tenant isolation, workspace isolation, IDOR, payload tampering, mass assignment, and privilege escalation are blocked.
  • 401, 403, safe error responses, CSRF, XSS, SQL injection, open redirect, and rate limiting are verified.

Data, audit, UX, and performance

  • Search, filters, pagination, exports, and reports do not leak restricted data.
  • Role changes create audit logs, metrics, alerts, and useful diagnostic logs.
  • Concurrent role changes, transaction consistency, permission cache invalidation, and performance are tested.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

Each role can access allowed features and cannot access forbidden features.
Admin-only actions, owner-only actions, member actions, guest actions, and read-only restrictions work.
Hidden UI actions, disabled controls, and access denied pages match permission rules.
Role upgrade, downgrade, removal, conflicting roles, and multiple roles update access correctly.
Existing sessions, cached permissions, expired tokens, and revoked tokens reflect permission changes.
Last admin protection and role assignment rules prevent unsafe account states.
Direct URL access and direct API access are denied when unauthorized.
Tenant isolation, workspace isolation, IDOR, payload tampering, mass assignment, and privilege escalation are blocked.
401, 403, safe error responses, CSRF, XSS, SQL injection, open redirect, and rate limiting are verified.
Search, filters, pagination, exports, and reports do not leak restricted data.
Role changes create audit logs, metrics, alerts, and useful diagnostic logs.
Concurrent role changes, transaction consistency, permission cache invalidation, and performance are tested.
Structure your answer: Start with a role matrix: each role, allowed actions, forbidden actions, and expected UI state.
Structure your answer: Add backend authorization: direct URL, direct API, status codes, and safe errors.
Structure your answer: Add permission changes: upgrade, downgrade, revoked token, cached permissions, existing sessions.
Structure your answer: Add security and data leakage: tenant isolation, IDOR, mass assignment, privilege escalation, audit logs, and concurrency.
Do not miss: Direct API access when UI controls are hidden.
Do not miss: Tenant isolation, workspace isolation, and IDOR.
Do not miss: Cached permissions after role changes.
Do not miss: Audit logs and last admin protection.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with a role matrix: each role, allowed actions, forbidden actions, and expected UI state.
  2. Add backend authorization: direct URL, direct API, status codes, and safe errors.
  3. Add permission changes: upgrade, downgrade, revoked token, cached permissions, existing sessions.
  4. Add security and data leakage: tenant isolation, IDOR, mass assignment, privilege escalation, audit logs, and concurrency.

Common missed areas

Common missed risks

Direct API access when UI controls are hidden.
Tenant isolation, workspace isolation, and IDOR.
Cached permissions after role changes.
Audit logs and last admin protection.

Answer template

Use this interview answer template

I would start with a role matrix for allowed and forbidden actions, then cover direct URL and API access, 401/403 behavior, role changes, cached permissions, tenant isolation, IDOR, privilege escalation, hidden UI actions, audit logs, concurrency, UX, and performance.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would test admin and user access.”

This names the topic but does not prove coverage. It misses role matrix depth, direct API access, tenant isolation, permission changes, data leakage, privilege escalation, and auditability.

Stronger answer
“I would test each role against a permission matrix, allowed features, forbidden features, admin-only actions, read-only restrictions, owner role management, disabled and unverified users, multiple and conflicting roles, role upgrade and downgrade, existing sessions, cached permissions, expired and revoked tokens, direct URL access, direct API access, backend authorization, 401 and 403 status codes, tenant and workspace isolation, IDOR, payload tampering, mass assignment, privilege escalation, last admin protection, role assignment rules, hidden UI actions, access denied page, search/filter/pagination data leaks, audit logs, CSRF, XSS, SQL injection, open redirect, rate limiting, concurrent role changes, transaction consistency, permission cache invalidation, and performance.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test roles and permissions?"

Start with a role matrix: each role, allowed actions, forbidden actions, and expected UI state.

Should I include negative and edge cases?

Yes. Add invalid inputs, empty states, duplicates, expired states, service failures, and recovery paths.

Should I include security, API, or backend risks?

Direct URL access and direct API access are denied when unauthorized. Tenant isolation, workspace isolation, IDOR, payload tampering, mass assignment, and privilege escalation are blocked.

What are common missed risks?

Direct API access when UI controls are hidden. Tenant isolation, workspace isolation, and IDOR. Cached permissions after role changes. Audit logs and last admin protection.

How can I practice this answer?

Use the interactive how would you test roles and permissions? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario