Lesson A19.8
A cloud security review asks whether identity, data, services, dependencies, visibility, recovery, and governance work together to protect the organization's goals. It also asks whether security responsibilities are actually understood and owned.
This project is provider-neutral, fictional, and non-operational. You will review supplied Northbridge architecture and synthetic evidence. You will not sign in to, scan, configure, test, or investigate any real cloud account or environment.
Lesson Progress
High School Advanced • A19: Cybersecurity Portfolio Projects • Lesson 8 of 10
Readiness Check
0/4 ready
Professional Hook
Cloud services can reduce the amount of infrastructure an organization must operate directly, but they do not eliminate the need for security design. Someone still decides who receives access, which data is stored, how services communicate, which logs matter, how exceptions work, and what happens when an important dependency is unavailable.
A professional cloud review therefore begins with responsibility. The reviewer asks which platform capabilities the provider supplies and which outcomes still depend on customer decisions. That prevents two common mistakes: assuming the provider handles everything, or assuming the customer must operate every layer itself.
Learning Objectives
Explain how a cloud security review evaluates shared responsibility, identity, data, network boundaries, logging, resilience, configuration governance, and ownership without assuming the cloud provider manages every security decision.
Review fictional cloud architecture and evidence by separating confirmed design facts, policy requirements, control evidence, assumptions, exceptions, and unknowns.
Identify defensible cloud findings involving least privilege, storage exposure, workload identity, telemetry, recovery, dependency concentration, and lifecycle governance without teaching exploitation or real-system testing.
Prioritize cloud security recommendations using business impact, control strength, evidence confidence, operational dependencies, residual risk, ownership, and validation needs.
Create a portfolio-ready Cloud Security Review Project that demonstrates provider-neutral architecture reasoning, evidence discipline, safe recommendations, governance, and professional communication.
Core Teaching
Cloud reviews should not be reduced to checking whether storage is public or whether a firewall exists. Modern cloud environments are identity-centered, service-dependent, heavily automated, and built from managed capabilities. A review therefore needs several connected perspectives.
Clarify which security responsibilities belong to the fictional cloud provider and which remain with the customer organization.
Review question: Which control outcomes depend on provider capabilities, and which still require Northbridge configuration, ownership, review, or policy?
Review workforce identities, service identities, privileged roles, temporary access, role ownership, and lifecycle decisions.
Review question: Who or what can act, why is the access needed, how much privilege exists, and when should that privilege change or end?
Understand where fictional information is stored, how it is classified, who can access it, how it moves, and how its lifecycle is governed.
Review question: Is the data protected according to its sensitivity, purpose, retention, sharing, recovery, and access requirements?
Review how cloud services communicate, where trust contexts change, and which paths require stronger validation, filtering, segmentation, or ownership.
Review question: Where does identity, data, authority, or responsibility cross a boundary that deserves explicit control?
Confirm that important cloud identity, storage, workload, network, administrative, and service-health events produce enough evidence for defensive decisions.
Review question: Which events must be observable, who owns the telemetry, and what happens when coverage or freshness is reduced?
Review backups, dependencies, recovery ownership, service restoration, and evidence that critical workflows can return to trusted operation.
Review question: Which failures matter most, what must be restored first, and what evidence is needed before declaring recovery complete?
Keep cloud configuration changes approved, attributable, reviewable, and aligned with policy rather than depending on informal one-time fixes.
Review question: Who owns the control, how is change approved, how is drift detected conceptually, and how are exceptions governed?
Identify managed services, identity providers, integrations, and external services whose failure or lifecycle can affect security outcomes.
Review question: What responsibility, evidence, recovery, and exit assumptions exist around each important dependency?
Shared Responsibility
Shared responsibility changes with the cloud service model, but the underlying reasoning stays consistent: the provider operates certain platform layers, while the customer still makes important decisions about use, access, data, configuration, monitoring, resilience, and governance.
Provider side
The fictional cloud provider operates data centers, foundational infrastructure, and underlying platform availability responsibilities defined by its service.
Customer side
Northbridge still decides which cloud services to use, what business data belongs there, and whether the service meets organizational requirements.
Provider side
The provider supplies identity capabilities, authentication features, logging options, and administrative controls.
Customer side
Northbridge defines roles, grants access, reviews privileges, protects privileged identities, and removes access when the need ends.
Provider side
The provider operates the storage service and platform-level durability capabilities.
Customer side
Northbridge classifies data, configures approved access, defines sharing, chooses retention, reviews exposure, and validates recovery expectations.
Provider side
The platform may produce administrative, identity, service, or data-access telemetry depending on the service.
Customer side
Northbridge decides which evidence is required, enables appropriate collection through authorized processes, monitors source health, controls access, and reviews retention.
Provider side
The provider maintains parts of the managed runtime according to the service model.
Customer side
Northbridge remains responsible for application logic, identities, data use, permissions, secure design, dependency choices, and operational governance.
Provider side
The platform may offer redundancy, snapshots, backups, or regional service options depending on the fictional service.
Customer side
Northbridge defines business recovery goals, owns restoration decisions, tests recovery safely, and verifies that restored service is trustworthy.
Evidence Discipline
A relationship explicitly shown in the fictional design or supplied record.
Example: APP-NB-C1 reads from DATA-NB-C2 through a designated workload identity.
An organizational rule that the design should satisfy.
Example: Privileged access must have named ownership and recurring review.
A synthetic record showing that a review, approval, log, recovery exercise, or other control activity occurred.
Example: A fictional quarterly access review shows the owner approved three roles and removed one stale grant.
A condition believed to be true but not yet supported by enough evidence.
Example: The team assumes all required cloud audit sources meet the expected freshness target.
A documented, approved deviation from a requirement with owner, rationale, residual risk, and review.
Example: A legacy reporting workload has a temporary monitoring exception until migration completes.
A missing fact that affects confidence or prioritization.
Example: The student evidence set does not include proof that every backup has been recently restored in a synthetic exercise.
Fictional Architecture
The following inventory is intentionally abstract. It contains no real provider names, addresses, account identifiers, credentials, configuration values, or production routes. It is enough to demonstrate cloud architecture and governance reasoning.
Fictional managed application serving student-facing features.
Trust context
Receives authenticated identity context and communicates with protected data and queue services.
Owner
Application Platform Team
Dependencies
Identity service ID-NB-C3, Data Store DATA-NB-C2, Queue Q-NB-C4, monitoring MON-NB-C8
Managed storage containing synthetic student preference and profile records.
Trust context
Accepts approved workload and administrative identities only in the fictional design.
Owner
Data Services Team
Dependencies
Workload identity, backup service BAK-NB-C7, access review process
Provides workforce, privileged, and workload identity context.
Trust context
Acts as a central dependency for application and administration decisions.
Owner
Identity Governance Team
Dependencies
Role inventory, approval workflow, federation lifecycle, monitoring
Supports asynchronous processing between the portal and background worker.
Trust context
Carries synthetic processing context across a service boundary.
Owner
Application Operations
Dependencies
Worker WRK-NB-C5, monitoring, service-health workflow
Processes approved queued work using a dedicated workload identity.
Trust context
Can update selected synthetic records through a scoped service role.
Owner
Platform Engineering
Dependencies
Queue, workload identity, data store, deployment governance
Restricted administrative interface for approved cloud operations.
Trust context
Crosses from normal workforce context into privileged cloud administration.
Owner
Cloud Operations Lead
Dependencies
Privileged identity, approvals, administrative logs, change governance
Stores synthetic recovery copies and supports restoration exercises.
Trust context
Requires protected administrative access and clear recovery ownership.
Owner
Resilience Team
Dependencies
Data Store, recovery plan, validation record
Collects synthetic identity, workload, administrative, service-health, and storage evidence.
Trust context
Provides evidence used by detections, investigations, governance, and recovery review.
Owner
Security Monitoring Team
Dependencies
Source health, retention policy, access governance
Fake Dashboard
Synthetic portfolio dashboard summarizing the fictional cloud security review.
Cloud assets
8
Application, data, identity, queue, worker, admin, recovery, and monitoring
Review findings
6
Identity, workload, data, monitoring, recovery, and dependency governance
High priorities
3
Privileged review evidence, monitoring freshness, and recovery validation
Open assumptions
4
Control validation, exception lifecycle, telemetry freshness, and recovery evidence
Fake SOC Alert
Source: Northbridge Cloud Governance Queue • Time: Synthetic architecture review
Fake Log Panel
[ID] privileged role inventory includes named owner and strong-authentication requirement [REVIEW] latest quarterly privileged-review artifact not present in supplied evidence set [WORKLOAD] WRK-NB-C5 uses dedicated fictional identity with documented current purpose [DATA] protected storage default prohibits external sharing unless exception is approved [EXCEPTION] one synthetic sharing exception lacks visible expiration date [MON] identity, admin, workload, storage, and service-health sources are present [RECOVERY] backup ownership exists; recent synthetic restoration evidence is not present [SAFETY] all records are fictional, provider-neutral, and non-operational
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Review Findings
Each finding separates evidence from interpretation and then connects the issue to risk, priority, recommendation, and validation. This makes the project more defensible than a checklist containing only pass/fail labels.
Evidence
The fictional role inventory names an owner and shows strong authentication, but the latest quarterly review record is missing from the supplied portfolio evidence.
Interpretation
The design includes the correct governance concept, but current review completion cannot be confirmed from the student evidence set.
Risk
Stale privileged access could persist longer than intended, increasing administrative exposure.
Priority / confidence
High priority · Moderate confidence
Recommendation
Require recurring review evidence, named ownership, temporary-access expiration, and an escalation path for overdue privileged reviews.
Validation evidence
A synthetic completed-review record should show role, owner, disposition, date, and any removed or renewed access.
Evidence
WRK-NB-C5 uses a dedicated fictional identity with a scoped purpose, but the portfolio does not state when permissions must be reconsidered after workload changes.
Interpretation
Least-privilege intent exists, while lifecycle governance around changing workload scope remains under-specified.
Risk
Permissions could accumulate as the worker gains new responsibilities.
Priority / confidence
Medium priority · High confidence
Recommendation
Define change-triggered review whenever the workload adds data access, service dependencies, or materially different responsibilities.
Validation evidence
A synthetic change review should show old purpose, new purpose, required permissions, owner approval, and resulting disposition.
Evidence
DATA-NB-C2 is marked protected and external sharing is prohibited by default, but one fictional exception record has an owner and rationale without a visible expiration date.
Interpretation
The exception process exists, but one required governance field is incomplete.
Risk
A temporary exception could continue longer than intended if it lacks a closure or review trigger.
Priority / confidence
Medium priority · High confidence
Recommendation
Require explicit expiration or scheduled review for storage-sharing exceptions and track closure evidence.
Validation evidence
The revised synthetic exception should include owner, rationale, residual risk, compensating controls, expiration, and closure.
Evidence
MON-NB-C8 receives synthetic identity, administrative, workload, storage, and health records, but only some sources have documented freshness expectations.
Interpretation
Coverage appears broad, yet reduced source freshness could weaken detection confidence without being immediately obvious.
Risk
Defenders may make slower or less confident decisions if a key evidence source is delayed.
Priority / confidence
High priority · Moderate confidence
Recommendation
Document required source coverage, freshness expectations, health ownership, dependent detections, and how reduced visibility changes confidence.
Validation evidence
Synthetic source-health records should demonstrate normal, delayed, maintenance, and recovery states.
Evidence
BAK-NB-C7 has a named fictional owner and documented recovery purpose, but the evidence set includes planning records rather than a recent completed restoration exercise.
Interpretation
Backup existence alone does not prove that the organization can restore the service to trusted operation.
Risk
Recovery capability could be overestimated during a disruption.
Priority / confidence
High priority · High confidence
Recommendation
Schedule safe synthetic restoration validation with defined success criteria, owner sign-off, dependency checks, and post-restore integrity review.
Validation evidence
A fictional exercise record should show scope, expected outcome, result, gaps, owner, and follow-up actions.
Evidence
APP-NB-C1, ADM-NB-C6, and several monitoring decisions depend on ID-NB-C3.
Interpretation
The central identity service is intentionally important, but its dependency concentration raises resilience and continuity questions.
Risk
Identity-service disruption could affect both normal user access and administrative recovery workflows.
Priority / confidence
Medium priority · High confidence
Recommendation
Document identity-service dependency, recovery assumptions, emergency governance, and the evidence required before privileged recovery actions proceed.
Validation evidence
A synthetic tabletop record should show how owners communicate, preserve accountability, and restore trusted identity service.
Analyze the Evidence
Review Questions
Prioritization
Cloud findings should be prioritized the same way other professional security findings are: by considering realistic impact, exposure, privilege, dependencies, current controls, evidence confidence, recovery readiness, business importance, and ownership.
A finding affecting a critical identity or recovery dependency may deserve more attention than a similar issue in a low-impact reporting service.
Administrative and workload identities with broader authority deserve stronger ownership and lifecycle governance.
Identity, monitoring, network, storage, or queue services can influence many downstream functions at once.
Existing controls lower residual risk only when their relevance and evidence are understood.
A confirmed policy gap should not be written the same way as an assumption based on incomplete evidence.
A service with strong prevention but weak recovery evidence may still deserve high resilience priority.
Common Mistakes
Cloud providers operate important platform controls, but customers still own major decisions about identity, data, configuration, workload design, logging, recovery, and governance.
A diagram shows design intent. Keep control evidence separate from what the architecture says should exist.
Modern cloud security also depends heavily on identity, workload permissions, data access, logging, service relationships, recovery, and lifecycle governance.
Managed services reduce some operational work but can become critical dependencies. Ownership, recovery, evidence, and exit assumptions still matter.
Prioritize using business impact, exposure, privilege, dependencies, current controls, uncertainty, and residual risk.
Student portfolio work should stay synthetic and provider-neutral. Architecture review and fictional evidence are enough to demonstrate advanced reasoning.
Safe Fictional Lab
Use only the supplied architecture, findings, policy requirements, and synthetic records. The exercise is a documentation review, not a live cloud assessment.
Choose four cloud capabilities and explain the fictional provider responsibility, Northbridge responsibility, and evidence needed to review the customer side.
Review privileged and workload identities. Identify purpose, owner, lifecycle trigger, evidence gap, and one improvement.
Describe the protected storage asset, approved access, sharing rule, exception process, retention or recovery need, and one governance concern.
List the important synthetic telemetry sources, explain what each supports, and identify how a missing source would change confidence.
Explain why backup evidence differs from restoration evidence and define what a successful synthetic recovery record should contain.
Write one short paragraph naming the top three findings, overall review confidence, and the most important owner decisions.
Scenario Decision Lab
The fictional cloud role inventory is well documented, but the latest recurring privileged-access review cannot be found in the supplied portfolio evidence.
Scenario Decision Lab
A fictional storage-sharing exception has an approved owner and rationale but no expiration or scheduled review date.
Advanced Challenge
Explain trust boundaries, workload identities, data flows, dependencies, shared responsibility, and which design assumptions need validation.
Explain top findings in terms of business impact, residual risk, ownership, recovery, and the decisions required next.
Explain how the artifact demonstrates provider-neutral knowledge, evidence discipline, governance, prioritization, safe recommendations, and professional communication.
Defender Habits
Assessment
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a professional fictional Northbridge Cloud Security Review. Include scope, shared-responsibility summary, cloud asset inventory, identity review, data-protection review, trust-boundary review, logging and monitoring review, resilience and recovery review, configuration-governance review, six findings with evidence and confidence, top-three priorities, owner-based recommendations, validation evidence, one governed exception example, an executive summary, and a publication-safety statement.
Confidence / Readiness Reflection
A19.9 moves into Portfolio Reflection and Presentation. Before continuing, make sure you can explain not only what your cloud review found, but also what the artifact demonstrates about your reasoning, communication, ethical boundaries, revision process, and growth across the entire portfolio module.
I can explain shared responsibility without oversimplifying provider and customer duties.
I can review cloud identity, data, logging, recovery, and governance using fictional evidence.
I can separate architecture intent from control-validation evidence.
I can write a bounded cloud finding with evidence, risk, priority, recommendation, owner, and validation.
I can explain why a student cloud portfolio should remain provider-neutral, fictional, and non-operational.
Portfolio Build Guide
Tell the reader what the fictional environment contains and how provider and customer responsibilities are divided conceptually.
Stable fictional IDs make architecture, findings, risks, and recommendations easy to connect without repeating long descriptions.
Show what the synthetic record says before explaining what you think it means.
Identity, data, monitoring, resilience, governance, and dependency sections help reviewers understand the breadth of the review.
A portfolio looks stronger when priorities are justified rather than when every minor observation is labeled High.
For each major recommendation, state what fictional record or review would demonstrate that the improvement is complete.
Finish with top risks, overall confidence, owner decisions, and the next review milestone rather than repeating every technical detail.
Do not include production screenshots, account IDs, resource names, credentials, secret values, internal routes, or unresolved real findings.
Key Takeaways
Lesson Safety Boundary
Do not sign in to, scan, probe, enumerate, exploit, test, configure, modify, or investigate any real cloud account, identity, storage service, network, workload, monitoring system, or backup environment. Do not publish real account identifiers, credentials, secret values, production diagrams, access policies, logs, private records, internal routes, or unresolved security findings. Use only the synthetic Northbridge evidence supplied in the lesson.
Lesson Complete
You now have a portfolio-ready structure for reviewing cloud security across shared responsibility, identity, data, logging, resilience, and governance. Next, A19.9 focuses on reflecting on your portfolio work and presenting it clearly to different audiences.