Concept questionHard~9 minCaching & Redis Essentials / 14 of 15

Interview question

A user loses access to a tenant, but the API still allows access for a few minutes because permissions were cached. How would you fix it?

Fix a stale permission cache security bug

Explains why cached authorization decisions are risky and how to bound or invalidate permission-related cache safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would treat this as an authorization bug, not just a cache bug. Permission and membership caches need much stricter freshness rules than normal read data. The immediate fix could be a shorter TTL, explicit invalidation on membership change, and making sure cache keys include user, tenant, and relevant role or permission version.

Full answer below

Practice focus

Authorization freshness, revocation, cache scope, fail-safe behavior, invalidation, and security monitoring.

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
A stale permission or membership cache can preserve access after revocation and become a cross-tenant security incident. Authorization freshness, key scope, invalidation, and high-risk bypass rules must be stricter than ordinary response caching.
I would treat this as an authorization bug, not just a cache bug. Permission and membership caches need much stricter freshness rules than normal read data. The immediate fix could be a shorter TTL, explicit invalidation on membership change, and making sure cache keys include user, tenant, and relevant role or permission version.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would look at where authorization is enforced. The API should still check the current principal and resource ownership server-side. If permission decisions are cached, I would prefer caching inputs or permission versions briefly rather than caching broad allowed responses. On revocation, I would delete affected keys or bump a version so old keys stop matching. For sensitive actions, I may bypass cache and read the authoritative permission state.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would add tests for role removal, tenant removal, admin changes, and token/session interaction. I would audit affected access, add alerts for denied/allowed anomalies where possible, and document the acceptable revocation window. Some systems accept a small delay for low-risk reads; admin actions, billing, data export, and cross-tenant access need tighter behavior. The cache cannot be allowed to weaken the security model silently.

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

Treating cached permissions like ordinary cached reference data.
Using keys that omit user, tenant, or permission version.
Relying on the UI to hide revoked access.
No audit or incident review after stale authorization.

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

Details

Does not recognize the security impact.
No revocation strategy.
No server-side authorization check.
Cannot define acceptable revocation delay.

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 would you bypass permission cache?
How can a permission version help?
What tests would prove revocation works?

Continue the section

Next in Caching & Redis Essentials: Cache Metrics

Step 15 of 15

Measure cache health beyond hit rate

Opening drill

Concept questionHard~9 minCaching & Redis Essentials / 14 of 15

Interview question

A user loses access to a tenant, but the API still allows access for a few minutes because permissions were cached. How would you fix it?

Fix a stale permission cache security bug

Explains why cached authorization decisions are risky and how to bound or invalidate permission-related cache safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Authorization freshness, revocation, cache scope, fail-safe behavior, invalidation, and security monitoring.

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
A stale permission or membership cache can preserve access after revocation and become a cross-tenant security incident. Authorization freshness, key scope, invalidation, and high-risk bypass rules must be stricter than ordinary response caching.
I would treat this as an authorization bug, not just a cache bug. Permission and membership caches need much stricter freshness rules than normal read data. The immediate fix could be a shorter TTL, explicit invalidation on membership change, and making sure cache keys include user, tenant, and relevant role or permission version.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would look at where authorization is enforced. The API should still check the current principal and resource ownership server-side. If permission decisions are cached, I would prefer caching inputs or permission versions briefly rather than caching broad allowed responses. On revocation, I would delete affected keys or bump a version so old keys stop matching. For sensitive actions, I may bypass cache and read the authoritative permission state.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would add tests for role removal, tenant removal, admin changes, and token/session interaction. I would audit affected access, add alerts for denied/allowed anomalies where possible, and document the acceptable revocation window. Some systems accept a small delay for low-risk reads; admin actions, billing, data export, and cross-tenant access need tighter behavior. The cache cannot be allowed to weaken the security model silently.

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

Treating cached permissions like ordinary cached reference data.
Using keys that omit user, tenant, or permission version.
Relying on the UI to hide revoked access.
No audit or incident review after stale authorization.

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

Details

Does not recognize the security impact.
No revocation strategy.
No server-side authorization check.
Cannot define acceptable revocation delay.

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 would you bypass permission cache?
How can a permission version help?
What tests would prove revocation works?

Continue the section

Next in Caching & Redis Essentials: Cache Metrics

Step 15 of 15

Measure cache health beyond hit rate

A user loses access to a tenant, but the API still allows access for a few minutes because permissions were cached. How would you fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A user loses access to a tenant, but the API still allows access for a few minutes because permissions were cached. How would you fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section