Questions 1–3
A11.1 — Security in the Software Lifecycle
Lifecycle ownership, security evidence, traceability, change triggers, and retirement.
High School AdvancedModule A1125 QuestionsModule Test
A11 Module Assessment
Secure Software Architecture Module Test
This 25-question test checks your understanding of the full A11 module: lifecycle security, requirements, threat modeling, secrets, dependencies, error handling, logging, code review, safe validation, deployment, and integrated architecture decisions.
Answers remain hidden until you reveal them through the quiz component. Use the explanations to identify exactly which lesson needs review.
Readiness Check
A11 Module Test Readiness
0/4 ready
Assessment Coverage
What the 25 Questions Measure
Questions 4–6
A11.2 — Secure Design Requirements
Specific, scoped, owned, traceable requirements and acceptance evidence.
Questions 7–9
A11.3 — Threat Modeling for Software
Assets, trust boundaries, threat statements, controls, evidence, and uncertainty.
Questions 10–11
A11.4 — Secrets Management Concepts
Metadata, ownership, environment separation, scope, rotation, redaction, and retirement.
Questions 12–14
A11.5 — Dependency and Supply Chain Risk Concepts
Provenance, support, runtime context, ownership, updates, exceptions, and evidence limits.
Questions 15–17
A11.6 — Secure Error Handling and Logging
Audience separation, correlation, redaction, auditability, retention, and source health.
Questions 18–19
A11.7 — Code Review for Security
Requirements-driven review, implementation evidence, findings, limitations, and validation needs.
Questions 20–21
A11.8 — Testing Security Requirements Safely
Authorization, expected outcomes, synthetic data, evidence, stop conditions, and bounded conclusions.
Questions 22–23
A11.9 — Secure Deployment Concepts
Artifact identity, configuration, release gates, monitoring, rollback, and post-release validation.
Questions 24–25
A11.10 — Secure Software Design Lab
Integrated architecture assessment, residual risk, evidence conflicts, decision records, and final release reasoning.
Before You Start
How to Use This Test
Reason from evidence
When two answers sound possible, choose the one that best matches the evidence actually provided.
Protect uncertainty
Do not turn missing evidence into a pass or convert a possible concern into proof of harm.
Think lifecycle
Ask how a decision affects requirements, ownership, validation, release, operation, maintenance, and retirement.
Use the explanations
After revealing an answer, note the lesson behind any question you missed.
A11 Module Test
25 Questions
Check Your Understanding
A11 Secure Software Architecture — 25-Question Module Test
Choose your answers first. Explanations appear only after submission.
1. 1. Which statement best describes security in the software lifecycle?
2. 2. Why is traceability valuable in a secure software lifecycle?
3. 3. A new privileged role is added after the original architecture review. What is the strongest response?
4. 4. Which requirement is strongest?
5. 5. Why should a secure design requirement avoid over-prescribing implementation when possible?
6. 6. What is the strongest way to handle a requirement exception?
7. 7. What is the main purpose of software threat modeling?
8. 8. Which is the best example of a trust boundary?
9. 9. A threat statement identifies a possible unauthorized-access outcome. What does that prove?
10. 10. Which information belongs in a metadata-only secrets governance record?
11. 11. Why is environment separation important for secrets?
12. 12. A dependency is listed in test tooling but is absent from the production artifact. What is the strongest conclusion?
13. 13. Why does dependency provenance matter?
14. 14. What is the strongest response when a business-critical dependency cannot be updated immediately?
15. 15. Why should user-facing errors and protected diagnostics contain different levels of detail?
16. 16. What is the purpose of a correlation ID?
17. 17. A security dashboard shows no authorization events, but the source-health monitor says the source is stale. What is the strongest conclusion?
18. 18. What should guide a security-focused code review?
19. 19. Pseudocode calls a function named RecoveryPolicy.check, but the policy rules are not supplied. What is the strongest review conclusion?
20. 20. What should happen before security validation begins?
21. 21. A required validation result is not present in the evidence package. What is the strongest status?
22. 22. Why must the released artifact match the artifact that was reviewed and validated?
23. 23. A production configuration differs from the approved baseline with no change record. What is the strongest response?
24. 24. Why should residual risk appear in the final architecture assessment?
25. 25. The final A11 assessment has one mandatory release gate with missing current evidence. What is the strongest recommendation?
Performance Guide
Interpret Your Result
This guide is for self-review. The most useful result is not only the total score — it is knowing which security reasoning patterns need more practice.
22–25 correct
Strong A11 readiness. You are reasoning across the module rather than memorizing isolated terms.
18–21 correct
Good understanding. Review the specific evidence or lifecycle areas behind the questions you missed.
14–17 correct
Developing understanding. Revisit the targeted lessons before moving to the next Advanced architecture module.
0–13 correct
Rebuild the core concepts first: requirements, threat modeling, evidence discipline, ownership, validation, and release reasoning.
Targeted Review Map
Where to Go Back if You Missed Questions
Lifecycle and requirements
Review A11.1–A11.2
You missed questions about ownership, traceability, requirement quality, acceptance evidence, or exceptions.
Threat modeling
Review A11.3
You confused threat concerns with proof, or had trouble with trust boundaries and evidence limits.
Secrets and dependencies
Review A11.4–A11.5
You missed metadata, environment separation, provenance, runtime context, updates, or exceptions.
Logging and code review
Review A11.6–A11.7
You missed correlation IDs, source health, audience separation, implementation evidence, or review limitations.
Validation and deployment
Review A11.8–A11.9
You missed authorization scope, stop conditions, artifact identity, configuration drift, rollback, or release gates.
Integrated architecture reasoning
Review A11.10
You struggled with residual risk, evidence conflicts, change triggers, or final release recommendations.
A11 Mastery
What You Should Be Able to Explain After This Module
A11 is not about memorizing isolated security vocabulary. It is about understanding how software security decisions remain connected over time.
1
Why secure requirements need owners, evidence, and change triggers.
2
Why a threat concern is not proof of compromise.
3
Why secret values should stay out of reviews and portfolio artifacts.
4
Why dependency context matters more than version age alone.
5
Why useful logging includes redaction, correlation, retention, access, and source health.
6
Why code review and runtime validation answer different questions.
7
Why safe testing starts with authorization, scope, expected outcomes, and stop conditions.
8
Why a release decision must match the exact artifact, configuration, and current evidence.
9
Why residual risk and Unknowns belong in a professional architecture assessment.
10
Why meaningful changes should reopen earlier security assumptions.
Defender Habits
A11 Module Completion Checklist
Key Takeaways
What You Should Remember
1.A11 connects software security decisions from planning through retirement.
2.Requirements create the expected behavior that later review and validation must support.
3.Threat models identify design concerns without proving harmful activity occurred.
4.Secrets and dependencies require lifecycle ownership, not one-time setup.
5.Logging should be useful, minimized, redacted, and supported by source-health evidence.
6.Code review supports implementation claims but does not replace runtime validation.
7.Safe validation is authorized, bounded, synthetic, evidence-driven, and governed by stop conditions.
8.Deployment readiness depends on the exact artifact, configuration, monitoring, rollback, exceptions, and current evidence.
9.A mature architecture assessment keeps Unknowns and residual risk visible.
10.The strongest security decisions are traceable, owned, evidence-based, and revisited when meaningful changes occur.
Assessment Safety Boundary
A11 remains defensive and evidence-based
This module does not authorize scanning, exploitation, bypass testing, credential attacks, fuzzing, malicious payloads, real secret collection, or access to production systems. All examples and assessment scenarios are fictional and school-appropriate.
Module Complete
A11 Secure Software Architecture
Completing this assessment finishes Module A11. The next Advanced module is A12 — Cloud Security Architecture, where you will apply architecture reasoning to cloud identity, services, data, configuration, monitoring, resilience, and governance.