Project brief — DevSecOps pipeline with full detection stack
This capstone brings together every module of the course into one connected project: a CI/CD pipeline hardened per Modules 1 and 2, deploying infrastructure validated per Module 3, monitored by the logging and detection stack from Module 4, and defended by the incident-response thinking from Module 5. Rather than five separate exercises, you will build one coherent system where each earlier skill plugs directly into the next, exactly as a real DevSecOps platform is assembled in practice.
Analogy🏏Cricket
✈️ Think of it like travel: booking a single multi-leg journey where each connecting flight only works because the previous one landed on time and at the right airport. One ticket chains provisioning, building, deploying, monitoring, and responding into one itinerary, so a delay or gate change in one leg ripples straight into the next rather than being an isolated inconvenience. You are not taking five unrelated trips; you are completing one continuous journey where every transfer must line up. This reveals why the capstone insists each earlier skill plugs directly into the next stage instead of standing alone.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
The scope is a small web application deployed to a cloud environment through Terraform, built and released through a CI/CD pipeline, with centralised logging feeding a Sigma-based detection rule and a SOAR-style automated response, all validated by a simulated attack you will trigger yourself. This is deliberately smaller than a production system, but it exercises the full chain end to end, which is the capability this course has been building toward from its very first lesson.
Analogy🏏Cricket
🍳 Think of it like cooking: preparing a single small tasting plate that still demands every technique a full banquet would — you knife-cut, sear, season, plate, and taste-check, just at a reduced portion. The dish is deliberately modest so it fits one pan and one sitting, yet nothing in the method is skipped, which is exactly why a good tasting plate proves a kitchen's range better than one oversized casserole. The capstone app is that tasting plate: Terraform, pipeline, logging, detection, and response all present in miniature. This reveals how a small scope can still exercise the entire chain end to end.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Under the hood, the capstone is organised into three project lessons plus this brief and the final submission. Lesson 32 builds the secure pipeline with SAST, SCA, and image signing. Lesson 33 stands up centralised logging and a Sigma-based detection. Lesson 34 simulates an attack and confirms the automated response triggers. Lesson 35 packages the complete portfolio project, the artifact you will actually submit and can showcase to demonstrate applied DevSecOps skill.
Analogy🏏Cricket
💼 Think of it like business: running a product launch as a sequence of dependent workstreams rather than one chaotic scramble. One team builds the secure pipeline, the next stands up monitoring, another runs the go-live rehearsal, and a final team packages the whole effort into the deliverable the client actually receives. Each workstream hands a finished component to the one after it, and the closing package is only credible because every prior stage completed cleanly. The four capstone lessons map to exactly these phases. This reveals why the project is staged as ordered lessons instead of one undivided task.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
Best practice for a capstone of this kind is to build incrementally and verify each stage before moving to the next, exactly as the pipeline itself gates each stage before the following one runs. Keep every artifact — Terraform files, pipeline configuration, Sigma rule, playbook definition, and your final write-up — organised in one project structure, since Lesson 35's submission expects a single coherent package rather than five disconnected pieces stitched together at the last minute.
Analogy🏏Cricket
💪 Think of it like fitness: adding weight to a lift only after you have cleanly completed the current set, never jumping straight to a max attempt. A disciplined program verifies each stage — form, then reps, then load — before progressing, because a failure caught early is a missed rep while a failure caught late is an injury. Building the capstone the same way means confirming the pipeline works before wiring detection, and detection before simulating an attack. This reveals why incremental verification mirrors the pipeline's own habit of gating each stage before the next one is allowed to run.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
In the real world, this exact pattern — provision, build securely, deploy verified artifacts, watch continuously, and respond automatically — is what separates a team that merely has security tools installed from a team that has genuine DevSecOps operating capability. Completing this capstone demonstrates you can assemble that capability yourself, end to end, rather than only understanding each individual piece from the five modules in isolation.
Analogy🏏Cricket
♟️ Think of it like chess: owning a full set of pieces is nothing like knowing how to coordinate them into a winning position. A beginner has the same queen, rooks, and knights as a grandmaster, yet only one can make them work together across the whole board under pressure. Many teams have every security tool installed, sitting unused like pieces left on their starting squares; a DevSecOps team actually orchestrates provision, build, deploy, watch, and respond as connected moves. This reveals why completing the capstone proves operating capability, not the mere possession of the tools.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.
The capstone integrates all five prior modules into one connected pipeline.
Scope: a Terraform-provisioned app, a hardened CI/CD pipeline, and a working detection/response chain.
Lessons 32-34 build the pipeline, logging/detection, and attack simulation in sequence.
Lesson 35 packages everything into a single submittable portfolio project.
Build and verify incrementally, mirroring the way the pipeline itself gates each stage.