Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust
Key Takeaways
- Least privilege grants only the access required for the task, for the required time, under the required conditions — scope, duration, accountability.
- Defense in depth layers controls so the failure of one does not expose the whole environment.
- Secure by design builds security into architecture and development from requirements, not as a bolt-on after deployment.
- Zero trust removes implicit network trust and continuously verifies identity, device posture, context, and session risk.
- SY0-701 frames zero trust as a Control Plane (policy engine, policy administrator) and Data Plane (policy enforcement point) — know the components.
Security Principles in Practice
Security principles guide control selection when every answer choice sounds plausible. They tell you which option reduces risk without creating excess access, single points of failure, or unverified trust — the three things SY0-701 distractors love to sneak in.
| Principle | Practical meaning | Scenario clue |
|---|---|---|
| Least privilege | Grant only required access | "excess permissions", "temporary access", "admin rights" |
| Defense in depth | Use layered, independent controls | "if one control fails", "multiple safeguards" |
| Secure by design | Build security in from the start | "new application", "architecture review", "requirements" |
| Zero trust | Verify explicitly and continuously | "no implicit trust", "device posture", "context-aware" |
| Separation of duties | Split sensitive tasks across roles | "same person requests and approves" |
| Fail secure | Default to a protected state on failure | "if the system fails, what should happen?" |
Separation of duties is distinct from least privilege: least privilege limits one person's access, while separation of duties ensures no single person controls an entire sensitive transaction (for example, the requester of a payment cannot also approve it). A related control the exam may test alongside it is mandatory vacation or job rotation, both of which expose fraud that depends on one person continuously occupying a role. These principles are not interchangeable, and SY0-701 will offer them as competing answers to a fraud-prevention scenario specifically to check that you can tell them apart.
Least Privilege and Defense in Depth
A developer needs to troubleshoot a production app for one weekend. Least privilege is about scope, time, and accountability — not convenience.
| Weak answer | Better answer |
|---|---|
| Add developer to Domain Admins | Grant scoped, just-in-time access for the approved window |
| Share an administrator password | Use a named account with MFA and logging |
| Leave access in place "in case" | Set an expiration and review after the work |
Defense in depth assumes any single layer can fail. A public web app handling customer data layers independent controls so a single bypass does not equal compromise.
| Layer | Example control |
|---|---|
| Edge | WAF, anti-DDoS, TLS |
| Application | Input validation, secure session management, code review |
| Identity | MFA for admins, RBAC, privileged access management |
| Network | Segmentation between web, app, and database tiers |
| Data | Encryption at rest, key management, database permissions |
| Monitoring | Centralized logs, alerts, file integrity monitoring |
| Recovery | Tested backups and documented restoration |
If an attacker bypasses the WAF, segmentation and least-privilege database permissions still cap the damage. The exam rewards answers that add an independent layer over answers that strengthen one already-present layer.
A closely related principle is fail securely (also called fail-safe or fail-closed). When a control fails, the system should default to the protected state rather than the open one. A door lock that defaults to locked on a power outage protects assets but can endanger life safety, which is why physical egress often deliberately fails open — the exam expects you to recognize that fail-secure is the norm for data confidentiality but that human-safety controls may intentionally fail open.
Pairing defense in depth with fail-secure defaults is what keeps a single component failure from cascading into a full compromise, and questions often hinge on choosing the option that preserves protection when something breaks.
Secure by Design and Zero Trust
Secure by design means security requirements are written into a project before launch — threat modeling, RBAC, encryption, secure defaults, and logging are design decisions, not patches. Adding a WAF after go-live helps but never replaces secure input handling, authentication, authorization, and logging baked into the architecture.
Zero trust does not mean "block everything." It means no request is trusted merely because it originated inside the network. SY0-701 expects you to know its plane model:
| Component | Plane | Role |
|---|---|---|
| Policy Engine (PE) | Control plane | Decides grant/deny using identity, device, and context |
| Policy Administrator (PA) | Control plane | Establishes or tears down the session based on the PE decision |
| Policy Enforcement Point (PEP) | Data plane | Actually allows or blocks the traffic to the resource |
Supporting inputs include the Policy Decision Point concept, adaptive identity, threat scope reduction, and implicit trust zones that must be eliminated.
Common Traps
| Trap | Better exam reasoning |
|---|---|
| "Internal traffic is trusted" | Zero trust requires explicit verification every time |
| "One strong control is enough" | Defense in depth expects layered failure resistance |
| "Admin rights are faster" | Least privilege favors scoped, time-bound access even under urgency |
| "Security can be added later" | Secure by design starts at requirements and architecture |
| "Fail open is user friendly" | For sensitive systems, fail secure (deny by default) is preferred |
When a scenario pits usability against verification, the principle-driven answer almost always chooses verification with the least added friction — not the option that removes verification entirely.
To summarize the four flagship principles in one line each for rapid recall: least privilege limits how much access; defense in depth controls how many independent layers protect an asset; secure by design fixes when security enters the lifecycle (at the start); and zero trust changes whether location confers trust (it does not). When two principles seem to fit a scenario, ask which dimension the stem is really stressing — the amount of access, the number of layers, the timing of design, or the basis of trust — and the correct principle usually resolves immediately.
A contractor needs access to one project repository for 14 days. Which option best applies least privilege?
In a zero trust architecture, which component actually allows or blocks traffic to the protected resource?
A team is finalizing a new customer portal. Which choice best reflects secure by design rather than a bolt-on fix?
Which examples show defense in depth? Select all that apply.
Select all that apply