least privilege

Definitions take ten seconds. The interviewer wants a worked failure: which layer broke, which one held, and why they did not break together.

Capabilities split root into pieces, but some pieces are nearly the whole thing. A strong answer knows the sets, the dangerous capabilities, and why 'drop all, add one' is the only defensible default.

OpenSSH's design is the model answer, but interviewers want you to derive it: what the parser must never hold, how small the privileged half can get, and the three mistakes that make a privilege drop reversible.

A checklist recital scores 'weak'. The strong answer orders controls by the attacker they stop, treats the baseline as code, and explains how you would notice when someone drifts from it.

Escalation rarely needs an admin permission, just a permission that leads to one. The scored answer names the common paths, finds them as a graph, and removes the edges that matter.

A seasonal exporter and an overprivileged service share an unused-access finding. Decide what evidence supports removal without preserving every broad grant indefinitely.

Most database breaches are not clever. They are a reachable database, an over-privileged account, a leaked credential or an exposed backup.

The same injection bug can leak one table or hand over the server. The difference is decided by grants made long before the bug was written.

Design around actual read, draft, preview and send audiences. Bind current grants and approvals to the operation, handle queued changes and evaluate the content risks that remain.

Compare each task’s required effects with the functionality, permissions and autonomy the system exposes. Narrow the effective authority at enforceable boundaries while preserving legitimate workflows.

Build a permission worksheet for each tool: acting principal, task grant, objects, recipients, bounds and enforcement. Treat reads and reversible writes as potentially consequential.

Treat repository code and shell execution as part of the threat model. Define reachable files, credentials, services and publication paths, then verify the actual sandbox and CI handoff rather than trusting command names.

Review customer, operator and service authority separately. Enforce order access and email release policy, govern contact changes, and test valid work alongside unauthorized reads and disclosures.

Separate proposal, verification and deployment authority. Bind approval to the executed artifact and environment, protect every policy dependency, and plan for drift, partial application and limited rollback.

Choose fixed query tools or bounded exploratory SQL, then verify the database role, tenant context, views, callable functions and resource controls. Read-only and row limits alone do not protect confidentiality or cost.