Capstone review
A fictional integrated assessment that combines all major A10 defensive control areas into one evidence-based architecture review.
High School AdvancedModule A10Lesson A10.10Capstone Review Lab
A10.10 Web Defense Architecture Review Lab
Complete the A10 capstone by reviewing one fictional Northbridge web architecture from end to end. Use supplied evidence to assess architecture, sessions, authorization, input/output safety, APIs, browser protections, secrets/configuration, and monitoring. Produce bounded findings, prioritized remediation, validation evidence, residual-risk decisions, and audience-specific communication.
Lesson Progress
Web Defense Architecture Review Lab
High School Advanced • A10: Advanced Web Security Defense • Lesson 10 of 10
100% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
The Capstone Question: Can You Defend the Whole System?
Individual controls are useful, but real architecture decisions rarely stay inside one lesson. A release can affect authorization, APIs, browser behavior, configuration, monitoring, supplier dependencies, and user experience at the same time.
Your task is to act like a defensive reviewer: understand the whole fictional system, determine which evidence is healthy, avoid overclaiming, identify the most important control gaps, assign owners, define remediation, and prove closure through validation.
Learning Objectives
Five Objectives for A10.10
Objective 1
Apply the complete A10 defensive workflow to one fictional web architecture using scope, trust boundaries, identity, sessions, authorization, input/output contracts, APIs, browser protections, secrets/configuration, and monitoring.
Objective 2
Evaluate a supplied fictional evidence set by separating observation, interpretation, Unknowns, source-health limits, alert lineage, findings, business impact, remediation, validation, and residual risk.
Objective 3
Build a prioritized fictional remediation plan with accountable owners, dependencies, rollback conditions, validation criteria, monitoring updates, and closure evidence.
Objective 4
Communicate the same fictional case appropriately to engineers, product owners, operations, identity teams, governance/privacy reviewers, leadership, and a public-safe portfolio audience.
Objective 5
Produce the module portfolio outcome: a complete fictional Web Defense Architecture Review package that demonstrates professional defensive reasoning without offensive testing or sensitive real-world details.
Capstone Vocabulary
Twelve Review Terms to Use Professionally
Architecture decision
A fictional choice about components, boundaries, trust, data, identities, APIs, suppliers, privilege, monitoring, resilience, or recovery.
Control dependency
A fictional relationship in which one defensive control relies on another service, owner, source, policy, or workflow to work correctly.
Cross-control finding
A fictional issue that affects more than one A10 control area, such as a supplier change that alters API scope, browser policy, privacy, secrets, and monitoring.
Evidence lineage
The relationship showing where fictional evidence originated and whether observations are independent, copied, transformed, delayed, or derived.
Source-health limitation
A fictional condition that reduces how strongly the review can rely on a telemetry or configuration source.
Compensating control
A fictional defensive measure that reduces risk when the preferred control cannot yet be fully implemented.
Remediation dependency
A fictional prerequisite that must be addressed before another remediation can be completed safely.
Validation evidence
Fictional proof that a remediation achieved its intended security and business outcome.
Residual risk
Risk remaining after the fictional remediation, exception, or compensating control is applied.
Closure state
The fictional review status showing whether an item is Open, Planned, In Progress, Validation Pending, Accepted, or Closed.
Leadership decision
A fictional priority, resource, timeline, exception, or risk-acceptance decision supported by the review.
Fake Dashboard
Fictional Northbridge Capstone Dashboard
A10.10 — integrated architecture review
Architecture components
11
Browser through recovery, including supplier and monitoring boundaries
Evidence records
12
Architecture, policy, API, browser, supplier, config, identity, secrets, input/output, and lineage
Primary findings
5
Authorization mapping, supplier visibility, config closure, secret rotation, alert lineage
Portfolio outcome
1
Complete Web Defense Architecture Review package
Architecture
Northbridge Web Defense Architecture
ARCH-01Public / authenticated boundary
Browser Client C
Fictional user-facing browser environment.
Assets
Session state, user input, browser policy state.
Dependencies
Application Service B and Identity Service I.
A10 controls
A10.2, A10.4, A10.6, A10.8
ARCH-02Application boundary
Application Service B
Primary fictional web application workflow.
Assets
Case workflow, authorization requests, API calls, error behavior.
Dependencies
Identity I, Authorization A, API P, Data D, Config C, Monitoring M.
A10 controls
A10.1, A10.3, A10.4, A10.5, A10.8
ARCH-03Identity boundary
Identity Service I
Fictional authentication, recovery, and session assurance service.
Assets
Identity/session metadata and recovery state.
Dependencies
Application B, Admin Console F, Monitoring M.
A10 controls
A10.2, A10.8
ARCH-04Policy boundary
Authorization Policy A
Fictional decision service for protected actions.
Assets
Roles, ownership rules, decisions, exception references.
Dependencies
Application B, API P, Identity I.
A10 controls
A10.3, A10.5, A10.8
ARCH-05Service boundary
API Service P
Purpose-limited fictional API layer.
Assets
Case status, reporting, preference, admin, recovery, and supplier workflows.
Dependencies
Application B, Authorization A, Data D, Supplier S, Monitoring M.
A10 controls
A10.3, A10.5, A10.8
ARCH-06Data boundary
Data Store D
Protected fictional application data store.
Assets
Cases, profiles, report data, approved configuration references.
Dependencies
Application B and API P.
A10 controls
A10.1, A10.3, A10.4, A10.5
ARCH-07Privileged boundary
Admin Console F
Separated fictional privileged administration workflow.
Assets
Configuration and administrative functions.
Dependencies
Identity I, Authorization A, Config C, Monitoring M.
A10 controls
A10.1, A10.2, A10.3, A10.7, A10.8
ARCH-08Configuration boundary
Configuration Service C
Fictional owner-approved security-relevant configuration state.
Assets
Browser profile, logging profile, API profile, feature state, supplier state.
Dependencies
Admin F, Application B, Monitoring M.
A10 controls
A10.6, A10.7, A10.8
ARCH-09Monitoring boundary
Monitoring M
Privacy-aware fictional telemetry and source-health layer.
Assets
Minimized identity, access, API, browser, config, and secret metadata.
Dependencies
All approved components.
A10 controls
A10.8
ARCH-10External trust boundary
Supplier S
Purpose-limited fictional external status integration.
Assets
Service-status metadata only.
Dependencies
API P and Monitoring M.
A10 controls
A10.1, A10.5, A10.6, A10.7, A10.8
ARCH-11Recovery boundary
Recovery R
Fictional staged recovery and validation service.
Assets
Recovery state, temporary access context, dependency-health summaries.
Dependencies
Identity I, Application B, Config C, Monitoring M.
A10 controls
A10.1, A10.2, A10.7, A10.8
Case Timeline
Eighteen Fictional Events
CASE-0108:00Release R-3 is approved for staged production rollout.
CASE-0208:15Reporting UI begins using API V2 for Team Blue aggregate reports.
CASE-0308:20API scope denials increase for several legitimate Team Blue users.
CASE-0408:25Application support reports that users see a generic authorization error.
CASE-0508:30Authorization matrix shows Team Blue access should be allowed for those users.
CASE-0608:35Role-mapping evidence suggests one application-to-policy mapping may still reference the previous release label.
CASE-0708:40Browser-policy pilot remains Healthy for sign-in, reporting, accessibility, and logout.
CASE-0808:45Supplier S monitoring source becomes Unknown during an ownership transition.
CASE-0908:50Supplier API scope remains purpose-limited to service-status metadata.
CASE-1009:00Configuration State C becomes Degraded during planned maintenance.
CASE-1109:05A configuration dashboard still shows Feature F-7 Enabled, while the approved baseline says Disabled.
CASE-1209:10Change record CHG-44 documents an approved temporary F-7 enablement ending at 09:30.
CASE-1309:20Secret metadata shows Application-to-Service Credential Class is Rotation Pending as planned.
CASE-1409:25One dependent service has not yet posted validation evidence for the new secret reference state.
CASE-1509:30A proposed Internal Explanation field remains excluded from user notifications pending privacy review.
CASE-1609:40Monitoring confirms three dashboard alerts about CHG-44 all derive from one underlying authorization event.
CASE-1709:45Identity source independently confirms the privileged session linked to CHG-44.
CASE-1810:00Leadership requests a concise risk summary and remediation priorities.
Fake SOC Alert
Fictional Capstone Priority Alert
Source: A10.10 integrated review board • Time: Northbridge capstone 10:05
Legitimate Team Blue reporting users are being denied after Release R-3. The current authorization matrix says they should be allowed, and application evidence shows one role mapping still references the previous release label. No supplied evidence indicates an exploit, credential theft, or malicious action.
Defensive recommendation: Treat this as a high-priority authorization/configuration finding. Correct the application-to-policy mapping through approved change control, validate Team Blue allow and Team Gold deny cases, monitor the rollout, and avoid unsupported compromise language.
Evidence Register
Twelve Fictional Evidence Records
EV-01Current
Architecture Map
Observation
Eleven components, trust boundaries, owners, and dependencies are documented.
Supports
Architecture scope and cross-control reasoning.
Limits
Does not prove runtime state.
Lineage
Independent architecture record.
EV-02Current
Authorization Matrix
Observation
Affected Team Blue users should be allowed to generate Team Blue aggregate reports.
Supports
Expected authorization result for the reporting workflow.
Limits
Does not prove the application passed the correct role context.
Lineage
Independent policy record.
EV-03Current
Application Role-Mapping Record
Observation
One mapping references the previous release label rather than R-3.
Supports
Possible application-policy mapping mismatch.
Limits
Does not by itself prove every denial has this cause.
Lineage
Independent application configuration record.
EV-04Conditional
API Events P
Observation
Team Blue scope denials increased after R-3 rollout.
Supports
A change-correlated API authorization symptom.
Limits
Supplier-related events may be delayed; timing does not prove causation.
Lineage
Independent API telemetry.
EV-05Healthy
Browser Policy Events H
Observation
Sign-in, reporting UI rendering, accessibility, and logout remain within pilot expectations.
Supports
No current evidence of a browser-policy compatibility regression in those tested journeys.
Limits
Does not prove authorization or API correctness.
Lineage
Independent browser-policy telemetry.
EV-06Unknown
Supplier Status S
Observation
No reliable current supplier-status events are available during ownership transition.
Supports
A visibility and ownership gap.
Limits
Cannot prove supplier health or failure.
Lineage
Single unhealthy supplier source.
EV-07Degraded
Configuration State C
Observation
Feature F-7 is reported Enabled, but the latest snapshot is delayed.
Supports
Possible state requiring reconciliation.
Limits
Freshness is reduced.
Lineage
Single degraded configuration source.
EV-08Current
Change Record CHG-44
Observation
F-7 temporary enablement is approved until 09:30 with an identified privileged session.
Supports
The observed F-7 state may be expected during the approved window.
Limits
Does not prove state returned to baseline after 09:30.
Lineage
Independent change-control record.
EV-09Healthy
Identity Events I
Observation
A privileged session linked to CHG-44 existed during the approved window.
Supports
Independent confirmation of the approved privileged-session context.
Limits
Does not prove every configuration effect was correct.
Lineage
Independent identity telemetry.
EV-10Healthy
Secret Metadata K
Observation
Application-to-Service Credential Class is Rotation Pending; one consumer validation is missing.
Supports
Rotation is in progress but not yet ready for closure.
Limits
Does not reveal or test secret values.
Lineage
Independent secret-lifecycle metadata.
EV-11Current
Input/Output Review
Observation
Internal Explanation field is blocked from user notifications pending privacy and output-context approval.
Supports
A preventive hold is working as intended.
Limits
Does not prove future implementations will preserve the rule.
Lineage
Independent design-review record.
EV-12Healthy
Alert Lineage Map
Observation
Three dashboard alerts for CHG-44 derive from one Authorization event.
Supports
Those three alerts are not independent corroboration.
Limits
Does not determine whether CHG-44 itself is appropriate.
Lineage
Derived-alert mapping.
Fake Log Panel
Fictional Capstone Evidence Log
training-log-viewer.log
10:00 | RELEASE | R-3 | stage=production-rollout | owner=AppOwner 10:02 | API | TeamBlue-report | result=Deny | source=Conditional 10:03 | POLICY | TeamBlue-report | expected=Allow | source=Current 10:04 | APP_MAPPING | release_label=R-2 | expected=R-3 10:05 | FINDING | authorization-mapping | confidence=High 10:06 | SUPPLIER | source_health=Unknown | status_claim=limited 10:07 | CONFIG | source_health=Degraded | F7-current=Unknown 10:08 | SECRET_META | rotation=Pending | consumer_validation=1-missing 10:09 | LINEAGE | alerts=3 | underlying_events=1 10:10 | PRIVACY | InternalExplanation | user_output=Blocked
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Analyze the Reporting Failure
Team Blue policy says the affected users should be allowed.
One application role mapping references the previous release label.
API Team Blue denials increased after Release R-3.
No evidence shows credential theft, bypass, or malicious activity.
Which conclusion is best supported by EV-02, EV-03, and EV-04?
Control Review
Integrated A10.1–A10.8 Assessment
A10.1 Architecture
Strong with one supplier visibility dependencyEvidence
EV-01, EV-06
Owner
Architecture Owner + Supplier Owner
Core boundaries and separation are documented. Supplier dependency visibility needs ownership restoration.
A10.2 Authentication / Sessions
StrongEvidence
EV-09
Owner
Identity Owner
Privileged CHG-44 session is independently confirmed and linked to an approved change window.
A10.3 Authorization
Needs RemediationEvidence
EV-02, EV-03, EV-04
Owner
Application Owner + Authorization Owner
Team Blue reporting denials conflict with expected policy and likely involve an application-to-policy role-mapping mismatch.
A10.4 Input / Output
Preventive Hold WorkingEvidence
EV-11
Owner
Application Owner + Privacy Reviewer
Internal Explanation remains blocked from user-facing output until privacy review is complete.
A10.5 API Security
Needs ValidationEvidence
EV-02, EV-04, EV-06
Owner
API Owner
API purpose and scope remain bounded, but reporting authorization behavior and supplier visibility require review.
A10.6 Browser Protections
StrongEvidence
EV-05
Owner
Application Owner
Key browser and accessibility journeys remain Healthy in supplied evidence.
A10.7 Secrets / Configuration
Validation PendingEvidence
EV-07, EV-08, EV-09, EV-10
Owner
Configuration Owner + Secret Owner
F-7 may be expected during CHG-44, but post-window state needs revalidation; secret rotation remains open until all consumers validate.
A10.8 Monitoring
MixedEvidence
EV-04, EV-05, EV-06, EV-07, EV-09, EV-10, EV-12
Owner
Monitoring Owner
Most sources are useful, but supplier is Unknown, configuration is Degraded, and alert lineage must be respected.
Scenario Decision Lab
Scenario Decision Lab 1: Should Release R-3 Be Rolled Back?
Reporting authorization is failing for legitimate Team Blue users, but browser workflows are Healthy, the likely role-mapping defect is identified, and the team has an approved narrow configuration correction with validation criteria.
Finding Register
Five Primary Capstone Findings
LAB-F01Priority: HighConfidence: High
Reporting role mapping is inconsistent with approved authorization policy
Observation
Affected Team Blue users should be allowed, while application mapping evidence references a previous release label and API denials rose after R-3.
Impact
Legitimate users may lose access to approved reporting workflows.
Owner
Application Owner + Authorization Owner
Remediation
Correct the application-to-policy mapping for R-3 through the approved change process and review other release-label mappings.
Validation
Fictional Team Blue allow cases succeed, Team Gold deny cases remain denied, source health is Healthy, and no new over-broad access appears.
Residual risk
Future release-to-policy mapping changes remain a recertification trigger.
LAB-F02Priority: HighConfidence: High
Supplier status visibility is Unknown during ownership transition
Observation
Supplier Status S has Unknown source health while API scope remains purpose-limited.
Impact
Defenders cannot make strong current supplier-status claims.
Owner
Supplier Owner + Monitoring Owner
Remediation
Complete ownership transfer, restore source health, define alternate evidence, and revalidate expected supplier-status telemetry.
Validation
Source becomes Healthy/Conditional with documented owner, coverage, event expectations, and successful fictional validation.
Residual risk
External supplier dependency risk remains.
LAB-F03Priority: MediumConfidence: Medium
Post-change Feature F-7 state is not yet confirmed
Observation
F-7 was approved Enabled until 09:30, but Configuration C is Degraded and has not confirmed return to baseline.
Impact
A temporary security-relevant feature state could persist longer than intended.
Owner
Configuration Owner
Remediation
Restore configuration source health and compare current F-7 state against the baseline and CHG-44 closure record.
Validation
Healthy source confirms F-7 matches the approved post-change state.
Residual risk
Future maintenance windows need alternate evidence for closure.
LAB-F04Priority: MediumConfidence: High
Application-to-Service secret rotation is not ready for closure
Observation
Rotation is planned and in progress, but one dependent consumer lacks validation evidence.
Impact
Retiring the previous secret state too early could disrupt a legitimate service dependency.
Owner
Secret Owner + Application Owner
Remediation
Obtain consumer validation, confirm dependency health, then retire the previous state under the approved rotation plan.
Validation
All approved consumers use the new reference state, service health is Healthy, and old state is Retired.
Residual risk
Secret lifecycle requires future rotation and owner review.
LAB-F05Priority: MediumConfidence: High
Derived alert count could overstate evidence strength
Observation
Three dashboard alerts for CHG-44 come from one underlying Authorization event.
Impact
Reviewers could incorrectly treat alert volume as independent corroboration.
Owner
Monitoring Owner
Remediation
Collapse derived alerts into one lineage group and display independent source count separately.
Validation
Dashboard distinguishes alert count, underlying-event count, and independent-source count.
Residual risk
Future new alert pipelines must preserve lineage metadata.
Analyze the Evidence
Analyze Feature F-7 After 09:30
CHG-44 approved F-7 Enabled only until 09:30.
Identity evidence confirms the privileged session used during the change window.
Configuration source is Degraded after the window.
No Healthy source currently proves the post-window state.
What is the strongest current conclusion?
Remediation Roadmap
Immediate, Near-Term, and Planned Work
ImmediateLAB-F01
Correct reporting role mapping under approved change control.
Owner
Application + Authorization
Success
Restore legitimate Team Blue reporting without expanding Team Gold access.
ImmediateLAB-F02
Complete supplier monitoring ownership and restore visibility.
Owner
Supplier + Monitoring
Success
Source health and alternate evidence become defined.
Near TermLAB-F03
Revalidate F-7 after Configuration C returns Healthy.
Owner
Configuration
Success
Baseline alignment is confirmed.
Near TermLAB-F04
Finish remaining consumer validation before retiring old secret state.
Owner
Secret + Application
Success
Rotation closes without service disruption.
Near TermLAB-F05
Update dashboard lineage presentation.
Owner
Monitoring
Success
Derived alerts are not overcounted.
PlannedCross-Control
Add release-change trigger requiring authorization mapping, API version, browser policy, config baseline, and monitoring review.
Owner
Architecture + Governance
Success
Future releases inherit a repeatable cross-control review.
Validation Board
Six Closure Tests
VAL-01Authorization fix
Criteria: Team Blue allowed, Team Gold denied, no broad privilege increase.
Evidence: Authorization + API + Application evidence
Owner: Application Owner
VAL-02Supplier visibility
Criteria: Healthy/Conditional source, owner assigned, expected events visible, alternate evidence documented.
Evidence: Supplier + Monitoring evidence
Owner: Supplier Owner
VAL-03F-7 closure
Criteria: Current state matches approved post-change baseline.
Evidence: Healthy configuration source + CHG-44 closure
Owner: Configuration Owner
VAL-04Secret rotation
Criteria: All consumers validate new reference state; old state retired.
Evidence: Secret metadata + service health
Owner: Secret Owner
VAL-05Alert lineage
Criteria: Dashboard separates derived alerts from independent sources.
Evidence: Monitoring dashboard review
Owner: Monitoring Owner
VAL-06Internal Explanation
Criteria: Field remains excluded from user notification until approved output contract exists.
Evidence: Field/output review
Owner: Application Owner + Privacy Reviewer
Scenario Decision Lab
Scenario Decision Lab 2: Close the Secret Rotation?
The new fictional Application-to-Service secret reference is active for most consumers, but one dependent service has not posted validation evidence. No outage is currently visible.
Audience Communication
Seven Capstone Deliverables
Engineering
Exact architecture, evidence IDs, control findings, configuration/authorization dependencies, remediation, validation, rollback.
Product
Affected reporting workflow, user impact, release dependency, priority, expected restoration, residual risk.
Identity / Authorization
Role mapping, privileged session, object/team scope, service identity, recertification implications.
Operations
F-7 closure, secret rotation, supplier visibility, monitoring restoration, rollback readiness.
Governance / Privacy
Supplier ownership, monitoring gap, output-field privacy hold, exceptions, residual risk.
Leadership
Top three decisions, business impact, confidence, owners, timeline, blockers, residual risk.
Public-Safe Portfolio
Fictional architecture, review workflow, bounded findings, owner/remediation/validation model, no sensitive operational detail.
Leadership Summary
Eight Decision-Ready Statements
1.Primary business issue: legitimate Team Blue reporting is being denied after Release R-3, with high-confidence evidence of an application-to-policy mapping problem.
2.Primary visibility issue: supplier-status monitoring is Unknown during an ownership transition, limiting current supplier-status confidence.
3.Primary closure issue: Feature F-7 needs post-window validation because the configuration source is Degraded.
4.Secret rotation is proceeding normally but should not close until one remaining consumer posts validation evidence.
5.Browser protections and key user journeys are Healthy in the supplied evidence.
6.Internal Explanation remains prevented from reaching user notifications while privacy review is open.
7.No supplied evidence supports a claim of compromise, data theft, malicious intent, or supplier breach.
8.Recommended leadership decision: prioritize reporting restoration and supplier visibility first, then complete configuration and secret-rotation closure evidence.
Common Mistakes
Eight Capstone Mistakes to Avoid
Treat the case as one giant incident
Why it fails
The supplied evidence contains several different control conditions with different owners and confidence.
Professional correction
Separate findings by control and connect them only where evidence supports a dependency.
Call the role-mapping issue a compromise
Why it fails
Evidence supports a release/configuration mismatch, not malicious activity.
Professional correction
Use bounded finding language.
Treat three derived alerts as three confirmations
Why it fails
They share one underlying source.
Professional correction
Use lineage and independent-source counts.
Say F-7 is definitely still Enabled
Why it fails
The configuration source is Degraded after the approved window.
Professional correction
Record current state as needing validation.
Retire the old secret state immediately
Why it fails
One dependent consumer has not yet validated the new reference.
Professional correction
Finish dependency-aware rotation validation first.
Assume Supplier S is down
Why it fails
Supplier source health is Unknown.
Professional correction
Treat supplier status as Unknown and restore visibility.
Close findings when work is performed
Why it fails
Implementation is not equivalent to validated risk reduction.
Professional correction
Require closure evidence.
Use live testing to fill evidence gaps
Why it fails
This curriculum uses fictional supplied evidence only.
Professional correction
Resolve gaps with owners, documentation, source restoration, and safe expected-state validation.
Safe Fictional Lab
Build the Complete Web Defense Architecture Review
Complete all eight phases using only the fictional Northbridge architecture and evidence supplied on this page.
Phase 1 — Review Charter
Define scope, exclusions, business goals, safety boundary, evidence rules, privacy rules, owners, stop conditions, and closure definition.
Phase 2 — Architecture Model
Map all eleven components, trust boundaries, assets, service identities, privileged paths, supplier dependency, monitoring, and recovery.
Phase 3 — Timeline and Evidence
Place CASE-01 through CASE-18 in sequence and connect EV-01 through EV-12 to the claims each record can and cannot support.
Phase 4 — A10 Control Assessment
Complete the A10.1–A10.8 control review using state, evidence, conclusion, owner, and Unknowns.
Phase 5 — Finding Register
Write LAB-F01 through LAB-F05 in your own professional wording while preserving the same evidence strength.
Phase 6 — Remediation Roadmap
Group actions into Immediate, Near Term, and Planned work with dependencies, rollback, owners, and success evidence.
Phase 7 — Validation and Closure
Use VAL-01 through VAL-06. Mark each finding Open, In Progress, Validation Pending, Accepted, or Closed based only on supplied evidence.
Phase 8 — Communication Package
Create engineering, product, operations, governance, leadership, and public-safe summaries plus one final architecture review diagram.
Capstone safety boundary
Use only fictional supplied evidence. Do not scan, probe, exploit, fuzz, bypass, enumerate, attack, test credentials, test sessions, test real APIs, test real browser policies, access real secret stores, inspect real private logs, or perform live-site testing.
Advanced Challenge
Build a Zero-Overclaim Executive Review
Produce a complete executive-ready review that remains useful while never claiming more than the fictional evidence supports.
Name the three highest-priority decisions and explain why each is prioritized.
Separate every Healthy, Conditional, Degraded, and Unknown source.
Show where evidence is independent and where alerts are derived.
Explain why the Team Blue finding is high confidence without calling it an incident.
Explain why Supplier S status remains Unknown rather than safe or compromised.
Explain why F-7 post-window state requires validation.
Explain why secret rotation remains open even though no outage is visible.
Create one remediation dependency graph using words and arrows.
Write one paragraph of residual risk after all planned remediation.
Write a public-safe portfolio summary that demonstrates the method without revealing sensitive implementation details.
Defender Habits
A10.10 Web Defense Architecture Review Checklist
Check Your Understanding
A10.10 Mini Quiz: Web Defense Architecture Review Lab
Choose your answers first. Explanations appear only after submission.
1. What is the strongest finding for the Team Blue reporting problem?
2. What can be concluded about Supplier S while its source health is Unknown?
3. Why can three CHG-44 alerts not be treated as three independent confirmations?
4. What is strongest for F-7 after the approved window ends?
5. When should the secret rotation close?
6. What is the strongest remediation strategy for the role-mapping defect?
7. What proves a capstone finding is closed?
Portfolio Prompt
Portfolio Prompt: Complete Web Defense Architecture Review
Create the complete fictional A10 portfolio outcome for Northbridge: a Web Defense Architecture Review package. Include review charter; scope; exclusions; architecture diagram; trust boundaries; data classes; identity/session map; authorization matrix; input/output contracts; API catalog; browser-protection review; secret/configuration metadata review; monitoring/source-health map; CASE-01 through CASE-18 timeline; EV-01 through EV-12 evidence register; A10.1–A10.8 control assessment; LAB-F01 through LAB-F05 findings; confidence and priority rationale; remediation roadmap; dependencies; rollback conditions; VAL-01 through VAL-06 validation board; residual risk; closure states; technical summary; product summary; operations summary; governance/privacy summary; leadership summary; and public-safe portfolio summary. Every organization, system, user, supplier, event, secret reference, configuration item, and outcome must remain fictional.
Do not invent evidence that the case does not supply.
Use source health and lineage to control confidence.
Keep findings bounded to what the evidence supports.
Separate remediation work from validation evidence.
Record residual risk after each major correction.
Make the public-safe artifact demonstrate reasoning without exposing sensitive operational detail.
Confidence / Readiness Reflection
Are You Ready for the A10 Module Test?
Rate your readiness from 1 to 5 across architecture, sessions, authorization, input/output, APIs, browser protections, secrets/configuration, monitoring, evidence quality, findings, remediation, validation, and communication.
I can review the entire A10 architecture as one defensive system.
I can identify trust boundaries and control dependencies.
I can evaluate source health and evidence lineage.
I can keep Unknowns explicit.
I can write bounded findings and avoid unsupported incident claims.
I can connect findings to business impact and priority.
I can build remediation with owner, dependency, rollback, and validation.
I can distinguish implementation from validated closure.
I can communicate clearly to multiple audiences.
I am ready for the 25-question A10 Module Test.
Portfolio Build Guide
What the Final A10 Portfolio Artifact Should Contain
Portfolio element 1
Review charter and safety boundary
Portfolio element 2
Architecture and trust-boundary diagram
Portfolio element 3
Identity and session model
Portfolio element 4
Authorization and ownership matrix
Portfolio element 5
Input/output field and context review
Portfolio element 6
API caller/resource/action review
Portfolio element 7
Browser protection and cookie review
Portfolio element 8
Secrets/configuration metadata review
Portfolio element 9
Monitoring and source-health map
Portfolio element 10
Case timeline
Portfolio element 11
Evidence register and lineage
Portfolio element 12
A10.1–A10.8 control matrix
Portfolio element 13
Five bounded findings
Portfolio element 14
Remediation roadmap
Portfolio element 15
Validation and closure board
Portfolio element 16
Residual-risk and audience summaries
Key Takeaways
What You Should Remember
1.A strong web defense review evaluates the entire architecture, not isolated controls.
2.Trust boundaries, identities, APIs, suppliers, configuration, monitoring, and recovery create cross-control dependencies.
3.Source health and evidence lineage determine how confidently a finding can be stated.
4.A release-related authorization defect is not automatically a security incident or malicious action.
5.Unknown supplier visibility must remain Unknown until evidence quality improves.
6.Temporary configuration changes require post-window validation before closure.
7.Secret rotation remains open until all dependent consumers validate the new state and the old state is retired.
8.Derived alerts should never be counted as independent evidence.
9.Remediation is complete only after validation proves the intended result and residual risk is recorded.
10.A10.10 completes the Web Defense Architecture Review portfolio outcome and prepares you for the A10 Module Test.
Safety Boundary
Defensive Capstone Only — No Live Testing
Nothing in A10.10 authorizes scanning, probing, fuzzing, exploitation, bypass testing, credential attacks, session attacks, object enumeration, API abuse, browser-policy evasion, secret testing, or testing real websites, services, accounts, devices, or networks. Use only fictional supplied evidence and safe defensive validation.
Lesson Complete
A10 Lessons Complete — Continue to the Module Test
You have now completed all ten Advanced Web Security Defense lessons. The A10 Module Test will assess secure architecture, authentication and sessions, authorization, input/output safety, API security, browser protections, secrets/configuration, web monitoring, the review process, and the integrated architecture review lab.