Skip to main content

Core path

Your path through this level

Progress saves in this browser and syncs after you sign in

Completed
0 of 9
You will be able to
  • Map user journeys, define NFRs, and apply threat modelling fundamentals.
  • Document architecture using C4 models, ADRs, and security by design principles.
  • Implement secure coding practices including input validation and session management.
Optional
Full module map
Use this if you want the shape of the level before you start
Show
Good requirements come from understanding journeys, risks, and constraints before design starts.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain discovery to requirements in your own words and apply it to a realistic scenario.
  2. Good requirements come from understanding journeys, risks, and constraints before design starts.
  3. Check the assumption "The problem is explicit" and explain what changes if it is false.
  4. Check the assumption "Non-functional needs are named" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Building the wrong thing. If discovery is weak, teams build the wrong system very efficiently.
  • Hidden constraints. Hidden constraints appear later as incidents and delays.
Architecture design is choosing boundaries, responsibilities, and the flows between them.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain design as boundaries in your own words and apply it to a realistic scenario.
  2. Architecture design is choosing boundaries, responsibilities, and the flows between them.
  3. Check the assumption "Boundaries are explicit" and explain what changes if it is false.
  4. Check the assumption "Decisions are recorded" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Diagram-first design. If you draw before you understand, diagrams become fiction.
  • Unowned interfaces. Interfaces without owners drift and break consumers.
Implementation is safer when guardrails prevent common mistakes and failures are visible.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain implementation with guardrails in your own words and apply it to a realistic scenario.
  2. Implementation is safer when guardrails prevent common mistakes and failures are visible.
  3. Check the assumption "Inputs are untrusted" and explain what changes if it is false.
  4. Check the assumption "Errors are safe" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Silent failure. Silent failure breaks trust and increases incident cost.
  • Leaky errors. Leaky errors expose internals and help attackers.
Tests are how you prove architectural claims about safety, performance, and reliability.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain verification proves claims in your own words and apply it to a realistic scenario.
  2. Tests are how you prove architectural claims about safety, performance, and reliability.
  3. Check the assumption "Tests match risk" and explain what changes if it is false.
  4. Check the assumption "Failures are actionable" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Green build theatre. A green build can hide gaps if you test the wrong things.
  • No regression coverage. If you cannot prevent regression, you re-learn the same lessons under stress.
CI/CD is where you enforce quality, not where you hope it exists.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain pipeline as control surface in your own words and apply it to a realistic scenario.
  2. CI/CD is where you enforce quality, not where you hope it exists.
  3. Check the assumption "Checks are fast enough" and explain what changes if it is false.
  4. Check the assumption "Deployments are reversible" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Bypass behaviour. If gates feel unfair, bypass becomes normal.
  • Unsafe defaults. If defaults are unsafe, you ship risk repeatedly.
Operations is feedback. Signals should trigger action, not only dashboards.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain operate with signals in your own words and apply it to a realistic scenario.
  2. Operations is feedback. Signals should trigger action, not only dashboards.
  3. Check the assumption "Signals reflect user impact" and explain what changes if it is false.
  4. Check the assumption "Runbooks exist" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Alert fatigue. Too many alerts teaches people to ignore them.
  • No learning loop. If incidents do not improve systems, you repeat them.
OSI thinking is useful when it helps you isolate problems with evidence and tests.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain evidence-first diagnostics in your own words and apply it to a realistic scenario.
  2. OSI thinking is useful when it helps you isolate problems with evidence and tests.
  3. Check the assumption "Each step is testable" and explain what changes if it is false.
  4. Check the assumption "Claims are written" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Guessing. Guessing is slow. Tests are faster.
  • Tool worship. Tools help, but the model makes output meaningful.
Quality attributes are trade-offs: you choose what to optimise and what to accept.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain ilities as trade-offs in your own words and apply it to a realistic scenario.
  2. Quality attributes are trade-offs: you choose what to optimise and what to accept.
  3. Check the assumption "Trade-offs are explicit" and explain what changes if it is false.
  4. Check the assumption "Measures exist" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Optimising one quality only. Optimising one axis can harm users elsewhere. Balance is the job.
  • Vague requirements. Vague ‘fast’ and ‘secure’ requirements create confusion and rework.
Assessment is useful when it checks judgement and produces defensible evidence.
Open
Prerequisites
  • No previous technical background required
  • Read the section explanation before using tools
Outcomes
  1. Explain assessment as evidence in your own words and apply it to a realistic scenario.
  2. Assessment is useful when it checks judgement and produces defensible evidence.
  3. Check the assumption "Assessment checks reasoning" and explain what changes if it is false.
  4. Check the assumption "Evidence is safe" and explain what changes if it is false.
Practice
  • Complete one guided exercise and explain your decision in plain language
  • Use the recap only after reading the main section
Artefact and failure modes
  • A short module note with one key definition and one practical example
  • Exam cramming. Cramming fades quickly. Practice builds judgement.
  • No feedback loop. Without feedback, assessment does not improve learning.
Optional
Planning and evidence
Objectives, timing, and CPD tracking
Show

If you want to start learning now, leave this closed. Come back when you want to plan your practice or keep evidence for CPD. This is guidance and it is not endorsed by awarding bodies. Standards mapping lives on the course overview page.

Learning objectives

What you will be able to do

  1. 1. Map user journeys, define NFRs, and apply threat modelling fundamentals.
    User journeys and NFRs decide what you are really building, so I start there.
  2. 2. Document architecture using C4 models, ADRs, and security by design principles.
    C4 models and ADRs give you a shared language and traceable decisions.
  3. 3. Implement secure coding practices including input validation and session management.
    Secure coding basics prevent the easiest ways systems are abused.
  4. 4. Apply comprehensive testing strategies including OWASP ASVS and accessibility testing.
    Testing and verification show whether your design survives reality.
  5. 5. Design CI/CD pipelines with DevSecOps integration.
    CI and CD are how safe change happens in the real world.
  6. 6. Apply SRE principles for reliable operations and incident response.
    Operations and incident response are part of architecture, not an afterthought.
  7. 7. Use OSI model and diagnostic tools for troubleshooting.
    OSI diagnostics give you a reliable troubleshooting mental model.
  8. 8. Evaluate systems across multiple quality attributes (the 'ilities').
    The ilities force you to think beyond features and into quality.
What comes next
Next we dig into styles, boundaries, and trade offs because those choices define system health.

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Assessment intent
Foundations

Correct diagrams, boundaries, and responsibilities.

Style
mixed
20 questions
Pass standard
Coming next
Not externally certified
Evidence you can save (CPD friendly)
  • One clear system sketch (C4 at a simple level): users, core components, data stores, and external dependencies.
  • Two ADRs: one trade-off you chose, and one assumption you wrote down with a plan to verify it.
  • A lifecycle evidence pack for one feature: NFRs, threat sketch, tests, rollout plan, and an ops checklist.

CPD timing

Foundations time breakdown

Defensible timing based on page content: reading, labs, checkpoints, and reflection.

Reading
32m
4,795 words × 1.3
Practice
120m
8 × 15m
Checkpoints
45m
9 × 5m
Reflection
72m
9 × 8m
Estimated total
4h 29m
Based on page content
Claimed hours
4h
Includes reattempts + capstone

CPD tracking

Fixed hours for this level are 4. Timed assessment time is included once on pass.

View in My CPD
Progress minutes
0.0 hours

Learning objectives

What you will be able to do

  1. 1. Map user journeys, define NFRs, and apply threat modelling fundamentals.
    User journeys and NFRs decide what you are really building, so I start there.
  2. 2. Document architecture using C4 models, ADRs, and security by design principles.
    C4 models and ADRs give you a shared language and traceable decisions.
  3. 3. Implement secure coding practices including input validation and session management.
    Secure coding basics prevent the easiest ways systems are abused.
  4. 4. Apply comprehensive testing strategies including OWASP ASVS and accessibility testing.
    Testing and verification show whether your design survives reality.
  5. 5. Design CI/CD pipelines with DevSecOps integration.
    CI and CD are how safe change happens in the real world.
  6. 6. Apply SRE principles for reliable operations and incident response.
    Operations and incident response are part of architecture, not an afterthought.
  7. 7. Use OSI model and diagnostic tools for troubleshooting.
    OSI diagnostics give you a reliable troubleshooting mental model.
  8. 8. Evaluate systems across multiple quality attributes (the 'ilities').
    The ilities force you to think beyond features and into quality.
What comes next
Next we dig into styles, boundaries, and trade offs because those choices define system health.

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Assessment intent
Foundations

Correct diagrams, boundaries, and responsibilities.

Style
mixed
20 questions
Pass standard
Coming next
Not externally certified
Evidence you can save (CPD friendly)
  • One clear system sketch (C4 at a simple level): users, core components, data stores, and external dependencies.
  • Two ADRs: one trade-off you chose, and one assumption you wrote down with a plan to verify it.
  • A lifecycle evidence pack for one feature: NFRs, threat sketch, tests, rollout plan, and an ops checklist.

Learning contract

Foundations outcomes

About 4 hours

Read the explanation first, then use the tools to test the idea. Skip any tool that is not useful for your goal.

  1. Map user journeys, define NFRs, and apply threat modelling fundamentals.
  2. Document architecture using C4 models, ADRs, and security by design principles.
  3. Implement secure coding practices including input validation and session management.
  4. Apply comprehensive testing strategies including OWASP ASVS and accessibility testing.
  5. Design CI/CD pipelines with DevSecOps integration.
Loading content...

Next step

Practise this level, then move on

I recommend you use the practice assessment for Foundations to test your understanding and write a short reflection. Timed assessments are being prepared for this track.

Practice

Assessment

No timer

Pace

Reflection

Evidence

Practice assessment

Start the practice assessment for Foundations

It is designed for confidence and evidence, and you can retry as often as you need.

The timed assessment for this level is being prepared. Use the practice assessment and labs until it is ready.

Sign in to save progress and keep your pass record

You can complete the course while signed out, and your progress saves in this browser. Sign in before assessments so your pass record is attached to your account.

Courses and assessments are free. There is no paywall for the learning path, practice questions, or formal assessments. Optional donations support hosting, maintenance, and ongoing updates.

During timed assessments, copy and the context menu are restricted to reduce casual cheating. Passed assessments are recorded in your account as evidence.

Course materials are protected by intellectual property rights.View terms