Lesson 18 · Senior auth & authz
Senior auth/authz interview questions
High-signal questions about trust boundaries, verification, authorization design, RLS, and service-to-service identity — with answer shapes that sound like real engineering judgment.
Your win: answer senior auth/authz questions with model + trade-off + repo-grounded consequence, not just security vocabulary.
Why these questions feel different
Junior or mid-level auth questions often ask for definitions. Senior auth questions usually ask whether you can reason about trust boundaries, delegated authority, operational failure, and layered enforcement without getting lost in jargon.
That is why the strongest answer style in this course is not “name the concept.” It is “name the model, the risk, and the consequence.”
How to get the most out of this page
Do not read the right-hand column as if it were a script to memorize. Read it as the shape of a good answer.
The strongest earlier lessons work because they help you hear the hidden question underneath the visible one. This page does the same: each prompt is really asking whether you can explain a boundary, a failure mode, or a deliberate layering choice.
Question bank
| Question | Best answer shape |
|---|---|
| What is the difference between authentication and authorization here? | Authentication is JWT-backed identity proof at the interceptor; authorization is the layered role, permission/location, and RLS chain. |
| Why use token exchange instead of trusting the original external token forever? | Because the repo needs a first-party identity model with its own roles, group, and tenant context rather than delegating final authority decisions to the external issuer. |
| How is JWT verification more than just checking a signature? | It also validates issuer, audience, expiry, key material, and rotation behavior through JWKS-backed verifier logic. |
Why is rbacDecider only the first authorization tier? | Because roles are coarse; business capability and location scope need finer modeling, and tenant isolation belongs in the DB. |
| Why use RLS as well as app-layer checks? | Because RLS shrinks the blast radius of app bugs by enforcing tenant and scoped visibility at the data layer itself. |
What is the difference between nil and an absent RBAC entry? | nil deliberately allows any authenticated user with a role; an absent key returns runtime PermissionDenied. |
| What risk exists in service-to-service auth? | The confused-deputy problem: an internal service can accidentally act with broader authority than intended if identity scope is not pinned explicitly. |
| Why does the pool hook stamp session variables on every acquire? | Because pooled connections are reused across requests, so tenant and user context must be reset per checkout to keep RLS trustworthy. |
| Why is the docs “panic at startup” claim a useful interview detail? | Because it shows you checked the real code path and can distinguish documented intent from implemented behavior. |
| What makes this repo’s auth design defense in depth? | Independent enforcement layers catch different failures: verifier, role gate, permission/location logic, repo filters, and RLS. |
GroupDecider.Check semantics, setPostgres, and fake JWT context for internal methods.Use the playbook and repo map together
The playbook compresses the senior lessons; the repo map gives you the source anchors that make your answer sound grounded.
What a weak answer sounds like
A weak answer usually sounds like a glossary. It names JWT, RBAC, and RLS but never explains why the system was designed that way, what failure it is preventing, or what concrete repo behavior proves the point.
A strong answer sounds calmer and more selective. It chooses the few details that reveal understanding.
Check yourself (from memory)
Q1. A strong senior auth answer usually includes…
Sources. Repo playbook and repo auth map.