How the interviewer opens it
“Design a cloud service that decides whether a principal can perform an action on a resource. It must support roles, inherited policies, cross-account access, and timely permission revocation.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Principals and authentication
- Roles and policy statements
- Inheritance and rule precedence
- Access between accounts
- Stored scale
- Request volume and read-to-write mix
- Latency and availability
- Permission changes and consistency
- Durability and change records
- External responsibilities
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Evaluate a principal, action, and resource against the current permission rules
- Manage roles, role assignments, and inherited resource policies
- Require consent from both accounts for cross-account access
- Enforce permission changes within a fixed deadline
Usually out of scope
- Authenticate users and workloads
- Issue credentials
- Execute arbitrary policy code
- Cancel operations that already started
What interviewers ask about
- Permission rules
- Several rules can apply to one resource through different paths. The evaluator must produce the same result despite policy order and cache state.
- Access between accounts
- Each account controls only its own permissions. A source administrator must not grant access that the resource owner never permits.
- Permission changes
- A cached allow can remain dangerous after a revoke. The five-second deadline must hold across caches, replicas, missed changes, and partitions.
- Check latency and shared policies
- Many requests can share one role or ancestor policy. A change to that policy can remove cache benefits across many principals and resources.
Common mistakes
- Treat a credential or cached role name as proof of current permission.
- Combine cross-account allows with OR and permit access without the resource owner's consent.
- Refresh a cache entry from a stale replica and restart its expiry.
- Trust client-supplied principal IDs, account IDs, or resource parents.
- Invalidate every resource separately after an inherited policy change.
- Continue allow decisions after the five-second freshness limit expires.
The bar by level
- Senior (L5/E5)
- Defines cross-account consent and deny precedence precisely. Designs regional checks with dependency versions and a complete five-second freshness budget. Handles retries, missed changes, and partitions.
- Staff (L6+/E6+)
- Proves the revocation bound across clocks, caches, replicas, and response time. Defines trust boundaries and safe write authority failover. Limits shared-policy costs and explains availability tradeoffs.
Sources · 1 reference
These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.
SysRound · 1 record
No company association
Design a cloud IAM authorization service
Reported date not specified
Source snapshot: Nov 12, 2026
View source