Explain the principle of least privilege and how you'd apply it.

Least privilege is a foundational principle that shows up everywhere from Active Directory to cloud IAM. Interviewers want to know you understand why it matters and how you'd actually enforce it.

The principle

Every user, account, process, and service should have only the access needed to perform its function — and no more. A help-desk technician doesn't need domain-admin rights; a web application's database account doesn't need to drop tables; a microservice shouldn't have full account-wide cloud permissions.

Why it matters

The core benefit is limiting blast radius. When an account is inevitably compromised — through phishing, a stolen token, or a vulnerable service — least privilege caps what the attacker can reach. An over-privileged account is a skeleton key; a tightly scoped one is a dead end. It also reduces insider-threat risk and shrinks the overall attack surface.

How you apply it

• Role-based access control (RBAC): define roles with scoped permissions and assign people to roles rather than granting ad-hoc rights.
• Separate duties and accounts: admins use standard accounts for daily work and elevate only when needed.
• Just-in-time (JIT) and time-bound access: grant elevated rights temporarily and revoke them automatically.
• Regular access reviews: combat privilege creep, where people accumulate permissions as they change roles but never lose the old ones.
• Scoped service identities: in the cloud, narrow IAM policies and avoid wildcard or admin roles for workloads.

Why this matters

Interviewers ask this to see if you connect the principle to real outcomes. A strong answer ties least privilege to blast-radius reduction, names privilege creep as the enemy, and proposes concrete mechanisms — RBAC, JIT access, and periodic reviews — rather than just defining the term.