Security Architecture and Engineering
What to know
Architecture translates risk decisions into structure. Understand security models and principles: least privilege, separation of duties, defense in depth, fail-safe defaults, complete mediation, and economy of mechanism. Know the difference between security architecture (the target structure and its rationale) and security engineering (implementing controls).
Understand trust boundaries and data flows - drawing them exposes where controls are needed. Know reference architectures, zoning, and the placement of enforcement points. Understand the role of assurance: certification, accreditation, and independent assessment. Physical security concepts (perimeter, access control, surveillance, environmental controls) appear in architecture questions and should not be dismissed.
Cryptographic architecture, key management design, and resilience concepts - redundancy, high availability, backup, and recovery objectives (RTO and RPO) - belong here. Understand that resilience is a security property: availability is part of the CIA triad, and denial of service is an attack on it.
Traps
Questions often present a control that is technically strong but architecturally misplaced - for example, encryption applied after data leaves the trust boundary. Another trap: confusing RTO (how fast you must restore) with RPO (how much data loss is tolerable). Beware options that add controls without addressing the root design flaw, and options that treat compliance certification as proof of security.
Worked example
A design sends sensitive data through a shared logging service. The architectural fix is to move the trust boundary so sensitive fields are redacted before crossing it - adding access controls to the log store alone leaves the exposure.
Rule of thumb: draw the trust boundary first; place the control at the boundary, not downstream.