Module
A2
Second module in the High School Advanced track.
High School AdvancedModule A210 Lessons + Module Test
A2 Security Architecture
Learn how professional defenders design fictional systems in which trust, identity, data, networks, controls, visibility, resilience, ownership, and change work together. This module moves beyond isolated tools and focuses on the complete security design.
Lessons
10
Ten architecture lessons plus one module assessment.
Assessment
25
Twenty-five hidden-answer questions after A2.10.
Portfolio
1
One integrated fictional security architecture package.
Main Question
How Do Professionals Design Systems That Stay Secure When Individual Controls Fail?
Security architecture is not a diagram filled with products. It is a documented set of fictional decisions about mission, trust, identities, data, networks, services, dependencies, prevention, detection, response, recovery, ownership, evidence, exceptions, and change. A strong design does not assume perfection. It expects controls, people, suppliers, data sources, and services to fail—and provides safe, visible, recoverable outcomes.
Design for failure
Assume that fictional identities, controls, services, logs, and dependencies may become unavailable or unreliable.
Design for evidence
Make important fictional decisions and boundary crossings visible, traceable, reviewable, and privacy-aware.
Design for recovery
Preserve critical functions, known restore points, owner coordination, communication, and measurable validation.
Safety Boundary
Architecture Learning Must Remain Fictional, Defensive, and Non-Operational
This module includes
- Invented organizations, systems, identities, data flows, logs, diagrams, services, and decisions.
- Conceptual defensive architecture, ownership, tradeoff, monitoring, resilience, and validation exercises.
- Static evidence analysis and safe portfolio artifacts.
This module does not authorize
- Accessing, scanning, testing, bypassing, changing, or investigating real systems.
- Using real credentials, private records, internal diagrams, configuration exports, logs, or supplier information.
- Operational instructions for evading controls or exploiting architecture weaknesses.
Professional Workflow
Ten Steps from Mission to Governed Architecture
1
Understand the mission
Define the fictional service purpose, users, critical functions, success conditions, operating environment, and business constraints.
Required output
Mission and architecture-context statement
2
Inventory assets and dependencies
Map fictional systems, identities, data, networks, suppliers, services, owners, locations, and operational dependencies.
Required output
Asset, identity, data, and dependency inventory
3
Draw trust boundaries and flows
Show where ownership, authority, sensitivity, network, identity, and control assumptions change.
Required output
Trust-boundary and data-flow diagram
4
Define security requirements
Translate fictional risks, obligations, privacy needs, service goals, and recovery expectations into measurable design requirements.
Required output
Security and resilience requirements register
5
Design layered controls
Combine prevention, detection, response, recovery, identity, segmentation, logging, hardening, and governance controls.
Required output
Defense-in-depth architecture
6
Analyze failures and tradeoffs
Test fictional assumptions, control dependencies, bypass paths, outages, privacy effects, usability costs, supplier limits, and recovery challenges.
Required output
Failure-mode and tradeoff matrix
7
Assign ownership
Name fictional design, system, identity, data, network, service, logging, recovery, supplier, communication, and risk owners.
Required output
Architecture responsibility map
8
Validate the design
Use fictional reviews, evidence, test cases, diagrams, configuration checks, control checks, and recovery exercises.
Required output
Architecture validation plan
9
Communicate the decision
Create technical, service-owner, leadership, privacy, and portfolio views from one approved architecture fact set.
Required output
Multi-audience architecture package
10
Govern change
Define fictional versioning, exceptions, approvals, monitoring, review cadence, retirement, and residual-risk ownership.
Required output
Architecture lifecycle and governance plan
Module Objectives
What You Will Be Able to Do
Objective 1
Explain security architecture as a coordinated system of trust, identity, data, network, control, visibility, resilience, and ownership decisions.
Objective 2
Design fictional defense-in-depth controls that do not all fail for the same reason.
Objective 3
Identify and document fictional trust boundaries, zones, communication paths, dependencies, and validation points.
Objective 4
Create identity-centered, visibility-aware, resilient, and securely configured fictional architectures.
Objective 5
Compare fictional architecture options using security, privacy, service, usability, performance, cost, complexity, supplier, and recovery criteria.
Objective 6
Assign fictional owners for design, systems, identities, data, networks, services, logs, recovery, suppliers, communication, and residual risk.
Objective 7
Validate fictional architecture decisions using evidence, failure cases, recovery tests, review records, and measurable outcomes.
Objective 8
Build a portfolio-ready fictional architecture package that is safe, defensive, non-operational, and fully invented.
A2 Lesson Path
Complete All Ten Lessons
Each lesson uses fictional architecture evidence, professional reasoning, safe case decisions, hidden-answer checks, and a portfolio artifact.
A2.1
Lesson 1 of 10
What Security Architecture Means
Define security architecture as the intentional arrangement of systems, identities, data, networks, controls, trust relationships, visibility, resilience, and ownership.
Core skills
- Separate architecture from individual tools
- Map business purpose to security design
- Identify assets, dependencies, owners, and assumptions
- Explain how architecture affects prevention, detection, response, and recovery
Portfolio outcome
Create a fictional security-architecture purpose statement and system context map.
A2.2
Lesson 2 of 10
Defense-in-Depth Design
Design multiple coordinated safeguards so one failed control does not automatically expose an entire fictional system or service.
Core skills
- Distinguish preventive, detective, corrective, and recovery controls
- Avoid duplicated controls that fail for the same reason
- Map control layers to assets and trust boundaries
- Validate whether each layer produces independent protection
Portfolio outcome
Build a fictional defense-in-depth control stack with failure and recovery paths.
A2.3
Lesson 3 of 10
Trust Boundaries and Security Zones
Identify where identities, data, authority, ownership, networks, services, and assumptions change across a fictional architecture.
Core skills
- Recognize trust changes and security zones
- Document allowed and denied data flows
- Assign validation at boundary crossings
- Avoid assuming internal systems are automatically trusted
Portfolio outcome
Create a fictional trust-boundary diagram and boundary-control matrix.
A2.4
Lesson 4 of 10
Network Segmentation Strategy
Use fictional segmentation to limit unnecessary communication, reduce impact, improve monitoring, and support recovery without creating brittle operations.
Core skills
- Group systems by purpose, sensitivity, ownership, and dependency
- Define approved communication paths conceptually
- Balance isolation with service availability
- Document exceptions, validation, and change ownership
Portfolio outcome
Design a fictional segmentation strategy and communication-allowlist review.
A2.5
Lesson 5 of 10
Identity-Centered Architecture
Treat identity, authentication, authorization, privilege, service accounts, lifecycle, and monitoring as central architectural controls.
Core skills
- Map human, service, device, and workload identities
- Separate authentication from authorization
- Apply least privilege and lifecycle ownership
- Plan identity logging, review, and recovery
Portfolio outcome
Create a fictional identity architecture with role, privilege, lifecycle, and monitoring maps.
A2.6
Lesson 6 of 10
Logging and Visibility by Design
Plan fictional telemetry, context, time, ownership, retention, health, and access before incidents occur.
Core skills
- Choose evidence sources for defender questions
- Design source-health and time-quality checks
- Protect log privacy and integrity
- Connect visibility to triage, validation, and improvement
Portfolio outcome
Build a fictional visibility architecture and evidence-coverage map.
A2.7
Lesson 7 of 10
Resilience and Recovery Planning
Design fictional services to continue safely, degrade predictably, restore from known states, and validate recovery after disruption.
Core skills
- Identify critical functions and dependencies
- Compare redundancy, backup, restoration, and continuity
- Define recovery ownership and validation
- Include communication and residual risk in recovery
Portfolio outcome
Create a fictional resilience map, recovery sequence, and validation checklist.
A2.8
Lesson 8 of 10
Secure Defaults and Hardening Strategy
Reduce unnecessary exposure through fictional secure defaults, approved baselines, least functionality, configuration ownership, exception handling, and change validation.
Core skills
- Distinguish defaults, baselines, hardening, and exceptions
- Reduce unnecessary services, access, and data
- Preserve usability, supportability, and recovery
- Validate effective state rather than written intent alone
Portfolio outcome
Develop a fictional secure-baseline and exception-management package.
A2.9
Lesson 9 of 10
Architecture Tradeoffs and Constraints
Compare fictional security, privacy, cost, performance, usability, complexity, reliability, legal, supplier, and time constraints without hiding residual risk.
Core skills
- Separate requirements from preferences
- Compare options using consistent criteria
- Identify second-order and long-term effects
- Document owner decisions and residual risk
Portfolio outcome
Create a fictional architecture decision record with options, tradeoffs, and owner signoff.
A2.10
Lesson 10 of 10
Security Architecture Design Lab
Integrate all A2 concepts into a complete fictional architecture review involving trust, identity, segmentation, visibility, resilience, hardening, tradeoffs, and validation.
Core skills
- Build a defensible architecture from requirements
- Map trust boundaries and control layers
- Compare design alternatives and failure modes
- Communicate the final design to technical and leadership audiences
Portfolio outcome
Produce a complete fictional security architecture package and executive design brief.
Fictional Evidence Preview
Architecture Evidence You Will Learn to Analyze
ARCH-01
Fictional system context diagram
Observation
A public application, identity provider, internal service, database, logging platform, and backup service exchange information.
Supports
The architecture contains multiple ownership and trust changes.
Does not prove
Does not prove the actual controls or allowed paths are correct.
Design use
Use it to identify trust boundaries, dependencies, owners, and validation questions.
ARCH-02
Fictional access matrix
Observation
One support role can reach application, identity, database, and backup administration functions.
Supports
Privilege concentration may increase impact and weaken separation of duties.
Does not prove
Does not prove misuse occurred.
Design use
Review identity architecture, least privilege, approval, and emergency access.
ARCH-03
Fictional network-flow record
Observation
The application can communicate directly with systems outside the documented service zone.
Supports
Segmentation and boundary assumptions may not match effective behavior.
Does not prove
Does not prove harmful traffic occurred.
Design use
Compare intended and effective paths and assign corrective validation.
ARCH-04
Fictional logging coverage map
Observation
Identity and application events are visible, but database and backup administrative actions are not included.
Supports
Important defender questions may be unanswerable.
Does not prove
Does not prove an incident occurred.
Design use
Expand evidence coverage while protecting privacy, retention, integrity, and source health.
ARCH-05
Fictional recovery exercise
Observation
Application service returns, but identity synchronization and logging remain incomplete.
Supports
Technical availability alone does not prove full recovery.
Does not prove
Does not prove every future recovery will fail.
Design use
Define multi-system recovery sequence and validation gates.
ARCH-06
Fictional architecture decision record
Observation
A simpler design has lower cost but concentrates identity, application, and logging responsibilities in one platform.
Supports
The design has efficiency benefits and correlated-failure risk.
Does not prove
Does not determine the correct choice without mission and risk context.
Design use
Compare options and document owner acceptance of residual risk.
Architecture Risk Preview
Common Design Failures You Will Learn to Recognize
Tool-first architecture
Choosing fictional products or controls before defining mission, assets, trust, data, users, dependencies, and requirements.
Strong control
Begin with context, requirements, and ownership before selecting design patterns.
Flat trust assumptions
Treating all fictional internal systems, users, devices, services, and networks as equally trusted.
Strong control
Identify trust changes and validate every boundary crossing.
Correlated control failure
Using several fictional controls that depend on the same identity, platform, data source, administrator, or network path.
Strong control
Review independence, diversity, failure modes, and fallback paths.
Invisible architecture
Designing fictional controls without evidence sources, source-health checks, time quality, and review ownership.
Strong control
Plan logging and validation as part of the architecture rather than an afterthought.
Brittle segmentation
Creating fictional isolation that breaks service dependencies or leads to uncontrolled exceptions.
Strong control
Map approved flows, service context, exception ownership, monitoring, and recovery.
Privilege concentration
Allowing one fictional identity or team to administer too many security-critical functions.
Strong control
Use least privilege, role separation, approval, temporary access, monitoring, and review.
Recovery mismatch
Restoring one fictional system while identity, logging, data consistency, dependencies, and communication remain incomplete.
Strong control
Validate recovery as an end-to-end service outcome.
Unmanaged architecture drift
Allowing fictional systems, data flows, exceptions, suppliers, identities, and controls to change without review.
Strong control
Use architecture versioning, change control, evidence, review cadence, and owner signoff.
Portfolio Outcome
Build a Complete Fictional Security Architecture Package
By the end of A2, you will have one connected architecture package rather than ten unrelated worksheets. Each lesson adds a new layer to the same fictional organization and concludes with an integrated design lab.
1.Fictional mission, system context, users, critical functions, and architecture assumptions
2.Asset, identity, data, service, network, supplier, location, and dependency inventory
3.Trust-boundary, security-zone, and approved data-flow diagrams
4.Defense-in-depth control map with prevention, detection, response, recovery, and governance layers
5.Identity architecture covering human, service, device, workload, privilege, lifecycle, and monitoring
6.Segmentation and communication-path review with exceptions and validation
7.Logging and visibility architecture with source health, time quality, privacy, retention, and access
8.Resilience, backup, restoration, continuity, rollback, and recovery-validation package
9.Secure-baseline, hardening, exception, effective-state, and change-control plan
10.Architecture options, failure modes, tradeoffs, decision record, owner signoff, and residual risk
11.Technical architecture review and leadership-ready executive brief
12.Full fictionalization, safety boundary, revision history, and portfolio reflection
Every artifact must use invented organizations, systems, identities, data, logs, diagrams, services, suppliers, decisions, dates, and outcomes. Do not upload or reproduce real internal architecture, configurations, credentials, private records, or confidential technical information.
A2 Module Test
Complete the 25-Question Assessment
After A2.10, test your ability to reason about mission, trust, defense in depth, segmentation, identity, visibility, resilience, hardening, tradeoffs, ownership, evidence, validation, and architecture governance.
Module Navigation
Begin Security Architecture
Start with the meaning and purpose of security architecture before moving into layered controls, boundaries, segmentation, identity, visibility, recovery, hardening, tradeoffs, and the final design lab.