The incident phase stabilized the fictional Northbridge service, but immediate recovery does not answer every governance question. A20.6 reviews who and what can act in the cloud environment, why that access exists, which controls belong to the customer, and what evidence proves that access and configuration remain governed.
The focus is defensive governance: workforce access, privileged roles, workload identities, federation, monitoring identities, recovery access, configuration evidence, shared responsibility, lifecycle, and ownership. No real cloud account or identity system is used.
High School Advanced • A20: Advanced Capstone • Lesson 6 of 10
60% complete
Readiness Check
Before You Start
0/4 ready
Professional Hook
Cloud Security Depends on Who Controls the Decision, Not Just Who Operates the Platform
A managed service can reduce the number of infrastructure tasks an organization performs directly, but it does not remove decisions about identity, privilege, configuration, data, logging, recovery, privacy, risk, and ownership.
The professional question is therefore not “Is the cloud secure?” It is “Which security outcome are we evaluating, which part belongs to the provider capability, which part belongs to Northbridge governance, and what evidence shows the customer-controlled part is being managed?”
Learning Objectives
Five Outcomes for A20.6
1
Explain how cloud shared responsibility separates provider capability from customer-controlled identity, configuration, data, monitoring, recovery, and governance decisions.
2
Review workforce, privileged, federated, workload, monitoring, and recovery identities by purpose, owner, privilege, approval, lifecycle, evidence, and review trigger.
3
Distinguish intended access design from current authorization evidence, successful authentication from permitted action, and service availability from governed cloud security.
4
Evaluate cloud control evidence across access, configuration, logging, data protection, recovery, exceptions, ownership, and post-incident follow-up.
5
Create a Cloud and Identity Governance Review that carries clear findings, evidence gaps, owners, residual questions, and handoffs into A20.7 risk and privacy review.
Shared Responsibility
Separate Platform Capability From Northbridge Governance
Underlying cloud platform
Provider capability: Operates the fictional physical facilities, foundational infrastructure, and managed-service platform capabilities described by the case.
Northbridge responsibility: Chooses how those capabilities are configured, which services are used, and how access, data, monitoring, and governance are managed.
Capstone meaning: Northbridge can rely on fictional managed-service capabilities while still owning role design, data use, configuration review, monitoring, and recovery decisions.
Identity and access
Provider capability: Provides authentication, role, token, federation, and audit features in the fictional service model.
Northbridge responsibility: Defines who or what receives access, why it is needed, how much privilege is allowed, who approves it, and when it changes or ends.
Capstone meaning: The capstone must review both privileged human access and workload identities rather than assuming the identity platform makes access correct automatically.
Capstone meaning: The 09:11 privileged event cannot be classified only by the fact that a cloud setting changed; task-level purpose and approval still matter.
Logging and monitoring
Provider capability: Provides fictional audit and service-health signals.
Northbridge responsibility: Chooses which evidence is enabled, collected, retained, reviewed, protected, and connected to source-health monitoring.
Capstone meaning: Collector delay remains a customer-side decision-quality issue even though the underlying services may continue producing records.
Recovery
Provider capability: Provides fictional backup, replication, or recovery capabilities available in the service model.
Northbridge responsibility: Defines recovery objectives, dependencies, identities, runbooks, test cadence, validation, and risk ownership.
Capstone meaning: Current backup status does not automatically prove complete restoration readiness.
Identity Types
Different Identities Need Different Governance
Identity review should not stop with employees. Modern environments also depend on application identities, worker identities, monitoring identities, recovery roles, and federation relationships. Each one has a purpose, owner, scope, lifecycle, and evidence requirement.
Standard workforce identity
Purpose: Supports ordinary staff access to approved application functions.
Risk: Access can become stale when job responsibilities change or when role scope is broader than business need.
A draft incident follow-up says the 09:11 privileged action was authorized because the user authenticated successfully and the maintenance window was active.
Defensive recommendation: Preserve successful authentication as evidence of identity use, then separately verify role purpose, task-level approval, action scope, ownership, and whether the action matched the approved maintenance task.
Fake Log Panel
Synthetic Northbridge Cloud and Identity Notes
training-log-viewer.log
[IDENTITY] standard workforce access uses documented application roles
[PRIV] privileged role has approved maintenance purpose and named fictional owner
[09:11] privileged action confirmed; exact task-level authorization still unresolved
[WORKLOAD] portal identity has defined back-end service relationships
[WORKLOAD] worker identity requires queue and protected-data access; exact current scope review pending
[MONITOR] monitoring identity has defined collection purpose; privacy minimization review pending
[RECOVERY] recovery role governed; full restoration evidence remains older than preferred window
[CLOUD] shared responsibility separates provider capabilities from Northbridge access and configuration decisions
[SAFETY] all roles, cloud services, identities, records, and findings are fictional
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Evidence Analysis 1 — Authenticated or Authorized?
The privileged identity authenticated successfully.
The action is recorded by identity and application evidence.
An approved maintenance window was active.
The summarized task record does not explicitly map the exact action to the approved work.
What is the strongest conclusion about the 09:11 privileged action?
Access Review
Eight Questions for Human and Workload Access
Purpose
Why does this person or workload need access, and which business or technical outcome does the access support?
Weak signal: Access exists because it was historically assigned but no current purpose is documented.
Scope
Which resources, actions, environments, data, and administrative capabilities are actually required?
Weak signal: The role grants broad access to resources that the workload or job function does not use.
Owner
Who is accountable for confirming that the access remains necessary and appropriate?
Weak signal: The role exists but no service, identity, or business owner accepts responsibility for review.
Approval
What authorized process granted or activated the access?
Weak signal: Authentication succeeds but no evidence explains why the privilege was approved.
Lifecycle
What event should create, change, suspend, expire, or remove the access?
Weak signal: The access persists after role, service, project, or recovery need changes.
Evidence
What records show current role assignment, action history, review, and decision context?
Weak signal: A design document says access should be narrow, but current authorization evidence is missing.
Review trigger
What event should cause immediate re-evaluation outside the normal review cycle?
Weak signal: Major service or ownership changes occur without triggering an access review.
Residual risk
What meaningful exposure remains even when the current access is considered necessary?
Weak signal: A highly privileged role is accepted with no documented rationale, compensating control, or owner decision.
Evidence Review
Six Identity Evidence Records From the Capstone
ID-EV-01
Privileged administrator role
Partially validated
Evidence: Synthetic role inventory confirms a named privileged role with an approved maintenance purpose.
Supports: The role exists and has a documented purpose.
Limitation: Does not prove the exact 09:11 action was included in the approved task.
ID-EV-02
09:11 privileged action
Event confirmed; meaning unresolved
Evidence: Identity and application records agree that the fictional action occurred.
Supports: The event itself is confirmed.
Limitation: Does not prove intent, exact authorization, or direct service causation.
ID-EV-03
Worker workload identity
Review required
Evidence: Architecture shows the worker requires queue and protected-data relationships.
Supports: The workload identity has a legitimate business purpose.
Limitation: Current exact authorization scope is not fully represented in the briefing evidence.
ID-EV-04
Portal workload identity
Strong design evidence
Evidence: Application architecture and role mapping identify approved back-end service relationships.
Supports: Expected application-to-service access can be documented.
Limitation: Current authorization still needs periodic review and change-triggered validation.
ID-EV-05
Monitoring service identity
Security evidence strong; privacy review pending
Evidence: Source inventory identifies the fictional monitoring services and collection purpose.
Supports: The monitoring identity has a defined operational purpose.
Limitation: A20.7 still needs to review whether all collected fields and retention remain proportionate.
ID-EV-06
Recovery operator role
Access governed; recovery evidence partly stale
Evidence: Recovery records identify an approved fictional recovery role and owner.
Supports: Recovery access is governed by a named role and process.
Limitation: Older full-restoration evidence means complete recovery-readiness confidence remains bounded.
Cloud Controls
Six Control Areas That Need Evidence, Not Just Policy
Identity governance
Expected: Human and workload access has purpose, owner, approval, scope, lifecycle, and review.
Northbridge finding: No major unresolved cloud exception is confirmed yet; later risk review should preserve any temporary monitoring or access exception.
Analyze the Evidence
Evidence Analysis 2 — Workload Purpose vs. Scope
The architecture documents a legitimate worker business purpose.
The worker processes approved background jobs.
The exact current permission scope is not fully represented in the supplied evidence.
No supplied evidence proves the role is either excessive or perfectly scoped.
The worker service clearly needs access to the queue and protected-data service, but the exact current authorization map is incomplete. What is the strongest finding?
Federation
Federated Trust Still Needs Purpose, Owners, Lifecycle, and Degraded-State Planning
Federation does not eliminate identity governance. It moves part of the trust decision across an organizational or technical boundary. The relying service still needs to know what identity information it trusts, who owns that trust, how lifecycle changes propagate, and what happens when the relationship is degraded.
What is the trust purpose?
A federation relationship should exist for a documented business reason rather than convenience alone.
Which identity information is trusted?
Only the claims or attributes needed for the intended access decision should be relied on.
Who owns each side?
Federation needs accountable owners for the identity source and the relying service.
How does lifecycle propagate?
Role changes, suspension, termination, or service changes should affect downstream access appropriately.
How is trust reviewed?
Configuration, claims, ownership, business need, and exception state should be reviewed periodically and after material change.
What happens when federation is degraded?
The service should have defined safe behavior when trusted identity evidence is unavailable or delayed.
Capstone Findings
Five Cloud and Identity Findings to Carry Into A20.7
Finding: Cloud shared responsibility is documented clearly enough to separate platform capability from Northbridge governance.
Evidence: Architecture and control records distinguish provider features from customer identity, configuration, monitoring, data, and recovery decisions.
Impact: Later risk statements can assign ownership more accurately.
A20.7 handoff: A20.7 should use these ownership boundaries when assigning risk and treatment.
Common Cloud and Identity Mistakes
What Weakens Governance Quality
Treating provider capability as customer control evidence
A feature existing in a cloud service does not prove Northbridge configured, owns, reviews, or validates it appropriately.
Treating authentication as authorization
A successful identity event proves access was established, not that every later action was approved or expected.
Ignoring workload identities
Applications, workers, monitoring services, and recovery tools can hold meaningful access that needs purpose and lifecycle governance.
Using service success as least-privilege evidence
An application working correctly does not prove its identity has only the permissions it needs.
Treating monitoring as privacy-neutral
Defensive collection still needs purpose, minimization, protected access, retention, and review.
Treating backups as complete recovery governance
Recovery also depends on identity, configuration, dependencies, restoration evidence, ownership, and risk.
Safe Fictional Lab
Build the Cloud and Identity Governance Review
Use only the fictional Northbridge architecture, identity records, change records, monitoring notes, and recovery evidence already provided. No cloud tenant, account, login, or live identity system is needed.
Task 1 — Build shared-responsibility notes
For identity, data, configuration, monitoring, and recovery, separate provider capability from Northbridge responsibility.
Task 2 — Inventory identities
Record at least six fictional identities or identity types with purpose, owner, privilege, resources, lifecycle, and review trigger.
Task 3 — Review privileged access
Compare the 09:11 event with role purpose, maintenance scope, action evidence, ownership, and unresolved task authorization.
Task 4 — Review workload access
Compare portal and worker business purpose with required resources and current synthetic authorization evidence.
Task 5 — Review cloud controls
Assess identity, configuration, data, monitoring, recovery, and exception governance by expected state and evidence.
Task 6 — Create A20.7 handoffs
Identify which issues become residual risk, privacy review items, treatment decisions, or owner actions in the next phase.
The 09:11 privileged action is confirmed. The user authenticated successfully and maintenance was approved, but the exact task is not explicitly mapped in the supplied change evidence.
Scenario Decision Lab
Scenario Decision 2 — Worker Identity Scope
The worker identity must process queue jobs and access protected data, but exact current permissions are not fully represented in the synthetic evidence.
Advanced Challenge
Explain One Identity Finding to Four Different Reviewers
Use the worker workload identity as the example. Preserve the same underlying facts while changing the depth and decision focus for four professional audiences.
Cloud architect
Explain the worker purpose, queue/data dependencies, trust boundaries, expected scope, and control design.
Identity reviewer
Explain role purpose, owner, required resources, lifecycle, review evidence, and current scope gap.
Risk / privacy reviewer
Explain potential overbreadth, data access, privacy impact, uncertainty, residual risk, and treatment need.
Executive reviewer
Explain why the issue matters, what is confirmed, what remains uncertain, who owns it, and what decision is needed.
Defender Habits
Cloud and Identity Review Phase Checklist
Assessment
A20.6 Knowledge Check
Check Your Understanding
A20.6 Mini Quiz: Cloud and Identity Review Phase
Choose your answers first. Explanations appear only after submission.
1. What does cloud shared responsibility mean in the A20 capstone?
2. A privileged user successfully authenticated. What does that prove?
3. What is the strongest treatment of the worker workload identity when its business purpose is clear but exact current authorization scope is incomplete?
4. Why is a recovery operator identity high sensitivity?
5. What is the strongest conclusion about monitoring service identity?
6. What is the best evidence that a cloud access control is governed?
7. What is safest for the A20 cloud and identity review?
Portfolio Prompt
Portfolio Prompt — Cloud and Identity Governance Review
Create a fictional Northbridge Cloud and Identity Governance Review. Include a shared-responsibility map for identity, data, configuration, monitoring, and recovery; at least six identity types or named fictional identities; purpose, owner, required resources, privilege, approval, lifecycle, review trigger, evidence, and residual risk for each; a focused review of the 09:11 privileged event; a workload-identity review for the portal and worker services; federation governance questions; cloud control evidence for identity, configuration, data protection, monitoring, recovery, and exceptions; findings with stable IDs, owners, evidence, limitations, and treatment or review needs; and a clear handoff identifying which findings A20.7 should evaluate as risk or privacy decisions.
Keep authentication, authorization, approval, and business purpose separate.
Treat workload identities as governed identities with purpose, owner, scope, lifecycle, and review.
Do not treat a cloud feature as proof that the customer configured or governs it correctly.
Carry monitoring collection purpose into A20.7 privacy review.
Keep backup availability separate from validated restoration readiness.
Use only fictional Northbridge cloud and identity evidence.
Confidence / Readiness Reflection
Are You Ready for A20.7?
A20.7 moves into Risk and Privacy Review Phase. Before continuing, make sure the cloud and identity findings are expressed as evidence, uncertainty, ownership, and decision needs rather than unsupported security labels.
1
I can explain why the 09:11 event is confirmed while task-level authorization remains unresolved.
2
I can explain why the worker workload identity has a legitimate purpose but still needs current scope evidence.
3
I can identify monitoring-data purpose and privacy questions that A20.7 should review.
4
I can carry recovery evidence freshness into residual-risk analysis.
5
I can assign each major cloud and identity finding to a fictional owner and next decision.
Portfolio Build Guide
Make the Cloud and Identity Review Useful in the Final Capstone
Use stable identity IDs
Later risk, privacy, and executive artifacts should be able to reference the same privileged and workload identity findings.
Separate design from evidence
Record what access should look like and what current synthetic evidence actually confirms.
Record lifecycle triggers
Role change, project completion, service redesign, ownership change, incident, or recovery use may trigger review.
Link findings to owners
Identity, cloud, monitoring, recovery, privacy, and risk owners should remain consistent across A20.
Track open authorization questions
Do not silently convert an unresolved action into approved or unauthorized status later.
Carry privacy purpose forward
Monitoring and audit collection should identify why data is needed so A20.7 can evaluate proportionality.
Track recovery evidence age
Fresh backup evidence and older restoration evidence should remain visibly different.
Maintain publication safety
Keep all cloud services, role names, identifiers, records, diagrams, and findings fictional and synthetic.
Key Takeaways
What You Should Remember
1.Cloud shared responsibility separates provider capability from customer-controlled identity, configuration, data, monitoring, recovery, and governance decisions.
2.Authentication, authorization, business purpose, approval, and action-level evidence are related but not interchangeable.
3.Human, privileged, federated, workload, monitoring, and recovery identities need different governance because their purposes and consequences differ.
4.Workload identities should be reviewed by purpose, resource scope, owner, lifecycle, evidence, and change triggers just like human access.
5.A design requirement does not prove current implementation, and a successful service does not prove least-privilege access.
6.Security monitoring can have a valid purpose while still requiring privacy review for data minimization, access, and retention.
7.Recovery access and recovery capability require evidence beyond current backup status.
8.The entire A20 cloud and identity phase remains fictional, synthetic, defensive, non-operational, and publication-safe.
Lesson Safety Boundary
Cloud and identity review stays fictional, defensive, and non-operational
Use only synthetic Northbridge cloud services, identities, roles, configurations, access records, change records, and recovery evidence supplied for CyberShield Academy. Do not connect to real cloud tenants, test credentials, enumerate accounts, inspect private access controls, change permissions, probe services, collect real logs, bypass identity protections, or investigate real organizations. The lesson evaluates governance, evidence, ownership, lifecycle, and defensive reasoning only.
Lesson Complete
A20.6 Cloud and Identity Review Phase Complete
The capstone now has a shared-responsibility model, identity inventory, privileged and workload access review, cloud-control evidence, and clearly owned governance findings. Next, A20.7 turns those findings into risk, privacy, treatment, exception, and residual-risk decisions.