Capstone — Submit Cloud Security Architecture Portfolio — Cloud Security

This final lesson assembles everything from Lessons 31 through 34 into one coherent portfolio submission: the design document, the implemented Terraform and policy-as-code, the deployed monitoring configuration, and a written reflection tying every decision back to PayNest's four goals. This is the artefact you can show a real interviewer or client as evidence of applied cloud security capability, not just completed course modules.

Analogy🏏Cricket

✈️ Think of it like travel: A modern airline does not inspect an aircraft once and trust it forever; a maintenance system continuously tracks every component, flags any part drifting out of tolerance, and surfaces the issue before the plane flies. Just as that system inventories every part and checks each against a standard so nothing is missed, CSPM inventories every cloud resource and checks each against best practice. Just as catching a worn part on the ground is far cheaper than discovering it aloft, catching a misconfiguration before an attacker does is far cheaper than after. This reveals why continuous automated checking is the natural defence against a constant risk.

The Capstone Submission

Assemble the Four Components

Gather the account-and-IAM design document from Lesson 32, the Terraform and policy-as-code from Lesson 33, the monitoring and alerting configuration from Lesson 34, and add a short written summary connecting all three to PayNest's original four goals. This summary is not a restatement of what you built — it is the argument for why what you built satisfies the brief, written for a reader seeing the whole picture for the first time.

Analogy🏏Cricket

♟️ Think of it like chess: Gathering the four components into one submission is like recording a full game in notation — every move in sequence, not a handful of clever positions shown out of order. The design document, the Terraform, the monitoring config, and the goal-linking summary must connect move to move so a reader can follow the whole game. Just as an annotated scoresheet lets a coach replay the entire game and see the plan behind it, the assembled portfolio lets a reviewer trace your reasoning from brief to build. This reveals what assembly really produces: a complete, followable record, not scattered highlights.

yaml

# CAPSTONE SUBMISSION STRUCTURE (what to assemble and submit)

1. design-document.md
   - Account/folder structure diagram (Lesson 32)
   - IAM table: identity, scope, notes (Lesson 32)
   - Network segmentation + logging summary (Lesson 32)

2. infrastructure/
   - guardrails.tf          (org-level SCPs/policies, Lesson 33)
   - modules/squad-role/    (reusable per-squad IAM module, Lesson 33)
   - .ci-pipeline.yml       (Checkov gate, Lesson 33)

3. monitoring/
   - security-hub-config    (org-wide enablement, Lesson 34)
   - alerting-rule.json     (critical finding -> Slack + auto-contain)
   - compliance-score-tracking.md  (the trended metric approach)

4. SUMMARY.md
   - One paragraph per PayNest goal, citing which specific artefact(s)
     above satisfy it, and one honest paragraph on what you would add
     next with more time or budget.

Write the Goal-Traceability Summary

For each of PayNest's four goals, write one paragraph naming the specific decisions that serve it and, honestly, any residual gap. For SOC 2, cite the immutable logging, the IAM table, and the tracked score. For containment, cite the per-squad account split and least-privilege module. For velocity, cite the self-service module and narrow guardrails. For GCP extensibility, cite the Security OU structure already mirroring GCP's own hierarchy.

Analogy🏏Cricket

⚽ Think of it like sports: Writing one paragraph per goal, naming the decisions that serve it and the gap that remains, is like a post-match analysis that maps each result back to a specific tactic and admits where the side was still exposed. For each of PayNest's four goals you cite the concrete controls achieving it and, honestly, the residual weakness. Just as an analyst who names both the winning move and the defensive lapse is trusted more than one claiming a perfect game, your summary earns credibility by pairing achievements with honest gaps. This reveals the summary's real job: argue, don't just assert, that the brief was met.

markdown

# Example goal-traceability paragraph (write one like this per goal).

GOAL 2 -- Contain a single compromised service to a small blast radius:

  Achieved through: per-squad, per-environment account separation
  (Lesson 32 design), least-privilege service-account roles scoped to
  one workload each via the reusable Terraform module (Lesson 33),
  and default-deny network segmentation between squads with only
  narrow, documented exceptions.

  Residual gap: cross-squad exceptions are currently manually
  reviewed rather than automatically validated against a policy;
  with more time, this would become a Checkov custom rule.

# Honesty about residual gaps is a STRENGTH in this submission,
# not a weakness -- it shows genuine understanding of trade-offs.

Analogy🏏Cricket

🎮 Think of it like gaming: Naming a residual gap honestly is like a top player reviewing their own ranked replay and openly flagging the one mechanic they still misplay, rather than blaming lag for every loss. That candour is exactly what a coach or teammate trusts. Just as an honest self-review earns more respect than a highlight reel that hides every mistake, an honest gap analysis earns more credibility from a technical reviewer than a claim of a flawlessly solved problem. This reveals why the reflection matters as much as the build itself: judgement about what still remains is as valuable as what was completed.

Final Review Checklist

Before submitting, verify the whole portfolio the way a real reviewer would: does the design document's diagram match what the Terraform actually implements, does the CI pipeline genuinely gate the guardrails, does the alerting rule reference the actual finding types the monitoring produces, and does every one of the four goal paragraphs point to something that genuinely exists in the other three files rather than something merely intended. Internal consistency across all four components is what separates a credible submission from a collection of separately plausible pieces.

Analogy🏏Cricket

💪 Think of it like fitness: Verifying the whole portfolio before submitting is like a lifter checking their form in the mirror across every angle before adding weight — the design, the code, the monitoring, and the summary must all describe the same actual system, with no claim in one that the others do not support. Just as a hidden breakdown in form surfaces the instant real load is applied, an inconsistency between components surfaces the instant a reviewer cross-checks them. This reveals what separates a credible submission from a plausible-looking one: internal consistency across every part, verified deliberately before the final lift.

Warning: The most common weakness in a capstone like this is inconsistency between the parts — a design document describing a control the Terraform never actually implements, or a summary claiming a benefit the monitoring configuration does not produce. A reviewer checking your work will find these gaps quickly, and they undermine trust in the whole submission far more than a modest but fully consistent design would. Cross-check every claim in your summary against the actual artefact before submitting.

Extension Challenge: Add a one-page 'GCP extension plan' describing concretely how you would extend this landing zone to the GCP analytics workload PayNest expects within the year — mapping your AWS account structure to GCP's folder hierarchy from Module 3, and your SCPs to GCP organisation policies. This demonstrates the cross-cloud fluency this entire course has built toward, and directly answers PayNest's fourth goal with a real plan rather than a vague assurance of future flexibility.

Key Points

The final portfolio assembles the design document, implemented Terraform, monitoring configuration, and a goal-traceability summary into one coherent submission.
The summary should argue why the artefacts satisfy each of PayNest's four goals, written for a reader encountering the complete picture for the first time.
Naming residual gaps honestly, rather than claiming a flawless solution, demonstrates genuine understanding of trade-offs and strengthens the submission's credibility.
Before submitting, verify internal consistency: the design, the code, the monitoring, and the summary should all describe the same actual system.
Inconsistency between components is the most common weakness in a capstone like this and undermines trust in the whole submission more than modest scope does.
This portfolio is designed to serve as real evidence of applied cloud security capability to a future interviewer or client, beyond simply completing the course.

Capstone — Submit Cloud Security Architecture Portfolio

The Capstone Submission

Assemble the Four Components

Write the Goal-Traceability Summary

Final Review Checklist

Key Points

Submit your capstone project