Lesson A12.10
The final A12 lesson brings the entire module together. You will act as a defensive cloud architecture reviewer and decide whether a fictional production release has enough current evidence, ownership, resilience, monitoring, configuration assurance, and governance to move forward.
Every identity, service, log, record, risk, finding, and architecture detail in this lesson is fictional and synthetic. No real cloud environment is accessed or tested.
Lesson Progress
High School Advanced • A12: Cloud Security Architecture • Lesson 10 of 10
Readiness Check
0/5 ready
Professional Hook
The fictional Northbridge Student Services Platform has many strong controls: workload identity, private data services, bounded public exposure, current application recovery evidence, monitoring, and a governance model. It also has a few unresolved findings.
Your job is not to make the review look good. Your job is to decide which claims are supported, which remain conditional, which are unknown, and which findings materially block approval.
A professional review protects the decision from optimism, not just the system from threats.
Learning Objectives
Integrate shared responsibility, IAM, storage, network, monitoring, secrets, resilience, configuration assurance, and governance into one evidence-based cloud architecture assessment.
Evaluate a fictional cloud release candidate by separating confirmed controls, conditional evidence, unknowns, blocked findings, exceptions, and accepted residual risk.
Connect architecture claims to owners, current evidence, dependencies, review triggers, remediation, and governance decisions instead of relying on diagrams or configuration labels alone.
Produce a defensible cloud release recommendation that distinguishes technical readiness from unresolved governance, recovery, identity, monitoring, and lifecycle risk.
Complete the A12 Cloud Security Architecture Assessment as a portfolio-ready capstone artifact.
Capstone Scenario
Northbridge is preparing a production architecture approval for a fictional Student Services Platform. The platform includes a public web application, private application services, a restricted managed database, generated report storage, an analytics capability, a notification provider, a scheduling SaaS integration, cloud monitoring, backups, workload identities, managed key references, certificates, and privileged administration.
Release candidate
NB-CLOUD-A12-RC1
Business service
Student Services Platform
Environment
Production
Primary owner
Application Owner
Data classes
Restricted, Sensitive, Internal, Public
External dependencies
Notification Provider + Scheduling SaaS
Recovery priority
Critical
Architecture review
A12 Cloud Security Assessment
Decision authority
Cloud Architecture Review Board
Review Domains
Which security outcomes are handled by the provider, which are handled by Northbridge, and which require coordination?
Strong evidence
Service-model responsibility matrix, provider capability assumptions, customer-owned controls, named owners, and evidence boundaries.
Review warning
Provider capability should never be treated as proof that customer configuration, ownership, or governance is correct.
Can every important human and workload access path explain who or what acts, why access exists, what scope is allowed, who approves it, and when it ends?
Strong evidence
IAM architecture matrix, workload identity records, privileged-access evidence, guest lifecycle, access review, and ownership.
Review warning
Shared credentials, stale roles, unowned service identities, or permanent broad admin access weaken the architecture.
Where does data live, which copies exist, who can access them, what exposure is intended, and how do retention and deletion work?
Strong evidence
Storage exposure review, classification, access scope, copy lineage, retention, logging, backup relationships, and ownership.
Review warning
Encryption alone does not prove storage is private, least-privileged, correctly retained, or properly owned.
Which sources can reach which destinations, why do those paths exist, where does trust change, and which flows should not exist?
Strong evidence
Trust-boundary map, public/private service paths, partner connectivity, administrative path, egress, environment separation, and monitoring.
Review warning
Private network location should not be confused with identity or authorization.
Can the cloud produce current evidence about identity, configuration, data access, network, application, recovery, and source health?
Strong evidence
Monitoring coverage matrix, source-health checks, alert ownership, event context, retention, and known gaps.
Review warning
No alert is not reassuring when the required telemetry source may be missing or stale.
Are workload identities, service credentials, key references, certificates, and emergency credentials owned, narrow, monitored, revocable, and lifecycle-managed?
Strong evidence
Secrets/key governance register, workload identity adoption, rotation/renewal evidence, revocation paths, environment separation, and dependency mapping.
Review warning
Architecture artifacts should never contain real secret values or private key material.
What must recover, how quickly, with how much acceptable data loss, through which dependencies, and what current evidence proves recovery?
Strong evidence
Recovery assessment, RTO/RPO, protected-resource scope, restore exercises, identity/key dependencies, external dependencies, monitoring, and owner sign-off.
Review warning
Healthy backups do not prove a service can be restored and validated end-to-end.
Does the observed cloud state still match the approved baseline, and are drift, exceptions, manual changes, and remediation governed?
Strong evidence
Configuration assurance register, current baseline, drift evidence, exceptions, compensating controls, validation, and closure evidence.
Review warning
A one-time secure launch does not prove the architecture remains secure months later.
Who owns each service, control, evidence source, exception, residual risk, review decision, and retirement obligation?
Strong evidence
Governance decision register, service inventory, standards, review triggers, risk decisions, exception lifecycle, and retirement conditions.
Review warning
Unowned cloud risk should not become accepted risk by default.
Assessment States
Current evidence supports the architecture claim within its stated scope.
Use: Use only when ownership, evidence freshness, and relevant dependencies are sufficiently established.
Important control evidence exists, but one bounded gap, dependency, review, or follow-up remains.
Use: Use when the design is partly supported but readiness depends on a known unresolved condition.
The review cannot establish whether the expected control or condition is present.
Use: Use when evidence is missing, stale, incomplete, conflicting, or outside the reviewer’s scope.
A material finding prevents the architecture from meeting the required release or governance condition.
Use: Use for unresolved high-impact issues such as unowned privileged access, unsupported exposure, missing lifecycle control, or invalid environment crossover.
A known residual risk remains after mitigation and has been explicitly accepted by an authorized risk owner under defined conditions.
Use: Use only when risk, mitigation, residual impact, authority, review date, and triggers are documented.
The control or architecture question does not apply to the reviewed service for a documented reason.
Use: Use sparingly and explain why the domain or requirement is outside the architecture scope.
Review Principles
Every important architecture claim should point to current evidence and an accountable owner.
Reviewer test: Could another reviewer independently understand why the claim is trusted?
The cloud service depends on identity, keys, logging, data, networks, partners, recovery, and governance beyond the visible application.
Reviewer test: What breaks if one supporting platform or external dependency is unavailable?
A professional review does not force every item into Pass or Fail when evidence is incomplete but bounded.
Reviewer test: Is the unresolved condition specific, owned, and reviewable?
A missing or stale record is itself a meaningful review result.
Reviewer test: Does the assessment preserve uncertainty instead of inventing confidence?
A temporary approved deviation remains a deviation and should retain its target state and expiration.
Reviewer test: What happens when the exception reaches its review date?
A technical team can describe residual risk, but only an authorized owner should accept it for the relevant business scope.
Reviewer test: Who owns the impact if the residual risk becomes real?
A production service should have a credible recovery story appropriate to its business priority.
Reviewer test: Does current evidence show the actual service, not only a backup, can recover?
The final output should explain what is ready, what is not, what remains conditional, and what must happen next.
Reviewer test: Can leadership or an engineering team act on the conclusion without rereading every raw record?
Vocabulary
A structured review that compares cloud design intent, current evidence, ownership, risk, and governance to determine readiness.
A statement about how the cloud environment is intended to behave, such as a storage location being private or a privileged role being time-bounded.
The records used to support an architecture claim, including ownership, configuration, logs, reviews, tests, lifecycle evidence, and related decisions.
A documented decision such as Ready, Ready with Conditions, Hold, or Reject based on current evidence and risk.
A material unresolved issue that prevents the reviewed architecture from meeting required release or governance conditions.
The risk that remains after current controls and mitigations are considered.
An alternate control used to reduce risk when the preferred standard cannot yet be met.
How current the supporting record is relative to the architecture claim and recent system changes.
A scheduled or event-driven condition that should cause an architecture decision to be reassessed.
The person or role authorized to approve release, accept residual risk, approve exceptions, or require remediation.
Known design, ownership, lifecycle, evidence, or governance weakness that remains unresolved and can increase future risk.
Proof that a finding or exception has actually reached the approved target state and can be closed.
A12 Portfolio Integration
Contribution
Defines provider, customer, and shared responsibility boundaries across the reviewed cloud service.
Capstone use
Prevents the review from assuming the provider owns customer IAM, data classification, guest lifecycle, monitoring design, or risk acceptance.
Contribution
Maps human, privileged, workload, service, temporary, and external identities.
Capstone use
Supports identity scope, least privilege, workload identity, approval, lifecycle, and ownership decisions.
Contribution
Maps data stores, classifications, access, exposure, copies, retention, encryption responsibility, logging, and owners.
Capstone use
Supports data-boundary and public/private exposure conclusions.
Contribution
Maps public ingress, private service paths, administration, partner integration, egress, recovery, and environment boundaries.
Capstone use
Supports reachability and trust-change conclusions.
Contribution
Maps telemetry domains, source health, event context, retention, alert ownership, and known visibility gaps.
Capstone use
Supports confidence in the evidence used by the architecture review itself.
Contribution
Maps workload identity, managed secret references, service credentials, keys, certificates, emergency access, rotation, revocation, and ownership.
Capstone use
Supports service trust, identity, availability, and lifecycle conclusions without exposing secret values.
Contribution
Maps RTO, RPO, protected resources, restore evidence, dependencies, failure domains, owners, and monitoring.
Capstone use
Supports production recovery readiness and business continuity conclusions.
Contribution
Compares approved baseline to observed state and tracks drift, exceptions, remediation, validation, and change triggers.
Capstone use
Supports current-state confidence rather than launch-day confidence.
Contribution
Maps service owners, standards, evidence, exceptions, residual risk, decision authority, review cadence, and lifecycle.
Capstone use
Supports final release authority, risk decisions, and ongoing ownership.
Evidence Register
Evidence
A12.1 responsibility map + current service inventory
Owner
Cloud Service Owner
Finding
Provider-managed capabilities remain inputs; customer configuration and governance remain Northbridge responsibilities.
Evidence
IAM-03 workload identity + IAM-02 privileged access records
Owner
Application Team + Platform Engineering
Finding
Workload identity is current; one emergency admin activation still lacks linked post-use review.
Evidence
STO-01 database + STO-02 report storage records
Owner
Data Platform + Reporting Team
Finding
No public access is required for restricted application data or generated reports.
Evidence
NET-01, NET-02, NET-03 trust-boundary records
Owner
Application Platform Team
Finding
Public exposure is intentionally limited to the approved application entry point.
Evidence
NET-07 + CFG-06
Owner
Unknown
Finding
A legacy development-to-production reporting path still exists without current owner or valid exception.
Evidence
LOG-01 through LOG-08 monitoring matrix
Owner
Security Monitoring
Finding
Critical sources are broadly covered, but temporary-export freshness automation remains incomplete under a time-bounded exception.
Evidence
SEC-01 Student Portal Workload Identity
Owner
Application Team
Finding
Portal workload access is bound to named non-human identity and approved service scope.
Evidence
SEC-05 Legacy Reporting Credential
Owner
Unknown
Finding
Legacy credential remains active with Unknown ownership, overdue rotation, and no documented revocation path.
Evidence
REC-01 full service recovery exercise
Owner
Application Recovery Owner
Finding
Current exercise includes application, database, workload identity, report storage, logging, and service validation.
Evidence
REC-03
Owner
Reporting Team
Finding
Backup state is current, but restoration evidence predates the current storage architecture.
Evidence
CFG-01 through CFG-08 configuration assurance records
Owner
Cloud Security + Service Owners
Finding
Most domains are governed, but blocked legacy identity/network drift and several conditional follow-ups remain.
Evidence
GOV-01 through GOV-08 + RISK-01 through RISK-04
Owner
Cloud Governance
Finding
Legacy credential and cross-environment path remain unowned and therefore cannot be validly accepted as residual risk.
Fake Dashboard
Fictional release-candidate evidence and readiness summary
Architecture domains reviewed
9
Responsibility, IAM, storage, network, monitoring, secrets, resilience, configuration, and governance
Evidence records
12
Cross-domain claims linked to current A12 artifacts
Blocking findings
2
Unowned legacy credential and unowned development-to-production path
Conditional findings
4
Privileged post-review, telemetry freshness, report restore evidence, and certificate validation
Fake SOC Alert
Source: Fictional Cloud Architecture Review Board • Time: 11:26
Conflicting Evidence
Evidence packages often contain statements that are individually true but collectively inconsistent. The reviewer should reconcile the conflict rather than selecting whichever record looks safer.
Evidence A
Network architecture says production services are private and environment-separated.
Evidence B
NET-07 / CFG-06 show a legacy development-to-production reporting path.
Interpretation
The general design intent is strong, but the observed environment state conflicts with it.
Decision
Keep the environment-separation claim Blocked until the path is removed or validly governed.
Evidence A
Monitoring dashboard shows no concerning temporary-export events.
Evidence B
LOG-08 does not yet verify temporary-export source freshness automatically.
Interpretation
No-event evidence is weaker while source-health confidence is incomplete.
Decision
Keep the monitoring claim Conditional under the time-bounded exception.
Evidence A
Report-storage backup configuration is current.
Evidence B
The latest restore exercise predates the current storage architecture.
Interpretation
Backup operation and restoration readiness are different claims.
Decision
Keep report-storage recovery Conditional until current restoration evidence exists.
Evidence A
Northbridge has a standard requiring owned, revocable, lifecycle-managed service credentials.
Evidence B
SEC-05 has no owner, overdue rotation, and no revocation path.
Interpretation
The legacy credential is not a valid exception or accepted risk.
Decision
Keep it Blocked and require replacement or retirement.
Fake Log Panel
[08:11] ARCH-01 responsibility-map owner=CloudServiceOwner state=CONFIRMED [08:34] ARCH-02 privileged-access JIT=YES post_review=PARTIAL state=CONDITIONAL [08:57] ARCH-05 dev-to-prod path=LEGACY owner=UNKNOWN state=BLOCKED [09:21] ARCH-06 monitoring temp-export-source-health=PARTIAL state=CONDITIONAL [09:48] ARCH-08 legacy-credential owner=UNKNOWN rotation=OVERDUE state=BLOCKED [10:14] ARCH-09 full-service-recovery evidence=42d state=CONFIRMED [10:39] ARCH-10 report-storage-restore evidence=STALE state=CONDITIONAL [11:02] ARCH-12 governance unowned-material-risks=2 state=BLOCKED [11:26] REVIEW recommendation=HOLD pending=REM-01+REM-02
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Release Criteria
| Criterion | Evidence | Current state | Result |
|---|---|---|---|
| No unowned production privileged or credential path | IAM and secrets governance records | Not met — SEC-05 has no confirmed owner | Blocker |
| No unsupported cross-environment production access | Network and configuration assurance records | Not met — NET-07 / CFG-06 remain unresolved | Blocker |
| Critical application recovery evidence current | REC-01 full service recovery | Met | Ready |
| Critical monitoring sources current enough for release review | LOG-01 through LOG-08 | Mostly met; temporary-export source-health exception remains bounded | Conditional |
| Restricted application data remains private | STO-01, STO-02, NET-02, NET-03 | Met | Ready |
| Privileged administration governed | IAM-02 + CFG-01 | Mostly met; one post-use review missing | Conditional |
| Material residual risks have authorized ownership | Governance decision register | Not met for two blocked legacy findings | Blocker |
| Configuration findings have current owners and next actions | Configuration assurance register | Not met for two legacy findings | Blocker |
Remediation Register
Owner
Cloud Service Owner to assign accountable service owner
Action
Confirm whether the legacy reporting service is still needed; replace with governed identity/credential or retire service and credential.
Closure evidence
Named owner, approved target state, replacement/retirement evidence, and monitoring confirmation.
Trigger
Before production architecture approval.
Owner
Platform + Application Owner
Action
Remove the path or document a narrowly scoped, time-bounded, monitored exception if a current business requirement truly exists.
Closure evidence
Updated trust-boundary map, configuration evidence, owner, and validation of target state.
Trigger
Before production architecture approval.
Owner
Platform Engineering Manager
Action
Complete the required post-use review and verify privileged-access workflow evidence.
Closure evidence
Review record linked to activation and governance item returned to Confirmed.
Trigger
Before final release sign-off or within approved governance window.
Owner
Security Monitoring
Action
Complete automated source-health integration while maintaining the approved manual compensating control.
Closure evidence
Freshness alert validated, exception closed, monitoring source state Confirmed.
Trigger
Before EX-01 expires.
Owner
Reporting Team
Action
Complete an authorized current-architecture restoration exercise and validate application access.
Closure evidence
New restore evidence supports present architecture and REC-03 returns to Confirmed.
Trigger
Before recovery readiness is claimed as complete.
Owner
Integration Owner
Action
Complete renewal and replacement validation before the current certificate reaches the defined safety window.
Closure evidence
Replacement validation evidence, updated certificate metadata, and successful integration health evidence.
Trigger
Before certificate lifecycle exception expires.
Architecture Decision
Decision
NB-CLOUD-A12-RC1 demonstrates strong architecture in workload identity, private storage, bounded public exposure, critical application recovery, monitoring design, configuration assurance, and governance structure. However, two material findings prevent approval:
Blocker 1 — REM-01
Unowned long-lived production reporting credential with overdue rotation and no documented revocation path.
Blocker 2 — REM-02
Unowned development-to-production reporting path with no valid environment exception.
The remaining Conditional findings are important but bounded and owned. They should remain tracked with due dates and closure evidence rather than being hidden or incorrectly marked Confirmed.
Scenario Decision Lab
Most architecture domains are Confirmed or bounded Conditional, but an unowned production credential and an unowned development-to-production path remain unresolved.
Scenario Decision Lab
Temporary-export logs are enabled, but automated freshness monitoring is incomplete. A current 14-day exception has an owner, manual compensating check, expiration, and target state.
Safe Fictional Lab
Build the final portfolio artifact using the fictional Northbridge scenario or another completely fictional cloud system. Do not inspect, test, access, or change a real cloud environment.
Create a one-page executive architecture summary.
Define service purpose, environment, owner, business priority, data classes, and provider/service model.
Include a shared-responsibility summary.
Include the IAM architecture matrix.
Include the storage exposure review.
Include the cloud trust-boundary map.
Include the monitoring coverage matrix.
Include the secrets and key governance register.
Include the recovery and resilience assessment.
Include the configuration assurance register.
Include the governance decision register.
Create at least twelve cross-domain architecture claims.
Link each claim to evidence and an owner.
Use Confirmed, Conditional, Unknown, Blocked, Accepted Risk, or Not Applicable.
Identify at least three evidence conflicts or contradictions.
Create a release-criteria table.
Create a remediation register with owners and closure evidence.
Document any valid exceptions separately from ungoverned drift.
Document residual risk and decision authority.
Give one final recommendation: Ready, Ready with Conditions, Hold, or Reject.
Explain what would cause the architecture to be reviewed again.
Capstone boundary
Use fictional services, synthetic evidence, invented owners, safe metadata, and conceptual architecture only. Do not access real cloud accounts, logs, credentials, storage, network settings, private policies, recovery systems, or production services.
Analyze the Evidence
Advanced Challenge
Prepare a concise professional briefing for a fictional Cloud Architecture Review Board. The board should be able to understand the decision without reading every detailed artifact first.
Service and business purpose
Primary architecture strengths
Shared-responsibility boundary
Top IAM conclusion
Top data/storage conclusion
Top network conclusion
Top monitoring conclusion
Top secrets/key conclusion
Top resilience conclusion
Top configuration-assurance conclusion
Top governance conclusion
Blocking findings
Conditional findings
Residual risks
Final recommendation
Exact conditions for re-review or approval
Board briefing standard
The briefing should be short enough to support a decision, but every important conclusion should trace back to a stable evidence, finding, remediation, or governance ID.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a polished fictional Cloud Security Architecture Assessment that integrates all nine earlier A12 portfolio artifacts. Include an executive summary, service context, responsibility matrix, IAM review, storage exposure review, trust-boundary map, monitoring matrix, secrets/key register, resilience assessment, configuration assurance register, governance decision register, cross-domain evidence claims, conflicts, release criteria, remediation register, residual-risk decisions, final recommendation, and re-review triggers.
Confidence / Readiness Reflection
Before taking the module test, make sure you can review cloud architecture as one connected system rather than nine isolated topics.
I can connect provider capability to customer responsibility without confusing the two.
I can review identities, data, networks, telemetry, credentials, resilience, configuration, and governance together.
I can preserve evidence uncertainty instead of inventing confidence.
I can distinguish a blocker from a bounded conditional finding.
I can explain when residual risk can and cannot be accepted.
I can produce a release recommendation supported by evidence, ownership, and next actions.
Portfolio Build Guide
Put Ready, Ready with Conditions, Hold, or Reject near the beginning with a one-paragraph explanation.
Architecture claims, findings, exceptions, risks, and remediation actions should reference stable IDs.
Show what the record says before explaining what the reviewer concludes.
A board should not have to search through dozens of pages to find the issues preventing approval.
For every Conditional item, show owner, unresolved condition, due trigger, and closure evidence.
Identify service owners, control owners, evidence owners, risk owners, and release authority.
Explain which architecture, provider, identity, data, partner, monitoring, recovery, policy, or ownership changes reopen the decision.
The final artifact should read like a defensive architecture assessment rather than a collection of disconnected class worksheets.
Key Takeaways
Capstone Safety Boundary
Do not access, scan, probe, enumerate, modify, restore, test, or interfere with real cloud accounts, services, networks, storage, credentials, logs, identity systems, backups, partner integrations, or private organizational records. Everything in this lab is fictional, synthetic, and designed for defensive architecture learning.
Lesson Complete
You have completed all ten lessons in A12 Cloud Security Architecture and built the final Cloud Security Architecture Assessment. The next page is the A12 Module Test.