Lesson A18.3
Cloud security is not one setting. It is a relationship among identity, data, exposure, logging, backup, architecture, ownership, and change governance. This case asks you to review that relationship without treating any single configuration as the whole answer.
Every cloud service, identity, role, data store, dashboard, and change record in this lesson is fictional. No real cloud access is required or permitted.
Lesson Progress
High School Advanced • A18: Advanced Defensive Labs • Lesson 3 of 10
Readiness Check
0/4 ready
Professional Hook
A fictional storage policy may look perfectly restrictive today, yet the data classification supporting that policy may be a year old. A privileged role may still be technically valid while its temporary exception has expired. Backups may run every night while nobody has tested recovery recently.
That is why cloud review is not simply “look for open settings.” Strong reviewers ask whether the design is appropriate, current, observable, recoverable, owned, and governed.
Cloud security quality lives in both the technical state and the evidence that proves the state is still intentional.
Learning Objectives
Review a fictional cloud environment using shared responsibility, identity, storage, network boundaries, logging, backup, recovery, ownership, and configuration-governance evidence.
Distinguish cloud configuration state from governance evidence so a technically safe setting is not confused with a current review, approval, or ownership record.
Evaluate cloud findings using exposure, privilege, business criticality, data sensitivity, monitoring quality, resilience, reversibility, and evidence freshness.
Design bounded remediation recommendations that reduce risk without broadening permissions, bypassing controls, or requiring access to any real cloud tenant.
Build a Cloud Security Case Review with evidence references, findings, risk statements, owners, compensating controls, validation criteria, and a prioritized remediation sequence.
Shared Responsibility
The provider operates and protects the underlying cloud infrastructure and service platform according to the service model.
Review implication: Do not assume the provider automatically configures the customer's identities, storage exposure, logging, retention, or business permissions.
The organization still owns decisions about identities, access, data use, configuration, monitoring, retention, governance, and workload architecture.
Review implication: Ask which controls the fictional customer must configure, review, and evidence.
Some protections depend on both provider capabilities and customer configuration.
Review implication: Separate platform capability from whether the fictional organization actually enabled, reviewed, and governed it.
Cloud Review Domains
Ask: Which identities can access the environment? Are privileges appropriate, approved, current, and reviewed?
Evidence: Role assignments, service identities, approval records, review dates, exceptions, privileged-access logs.
Ask: What data is stored? How sensitive is it? Who can read or modify it? Is exposure consistent with purpose?
Evidence: Storage classification, access policy summary, owner, review date, encryption status, sharing boundary.
Ask: Which services are externally reachable? Which private paths exist? Are trust boundaries documented?
Evidence: Architecture diagram, approved ingress/egress purpose, service dependency records, management path.
Ask: Are identity, administrative, storage, and workload events visible? Are logs attributable, retained, and monitored?
Evidence: Log-source inventory, health status, retention, ownership, alert coverage, evidence completeness.
Ask: Are important workloads and data recoverable? Are backups protected, monitored, and periodically validated?
Evidence: Backup policy, last validation date, recovery owner, failure evidence, dependency list.
Ask: Are changes approved, attributable, reviewed, and reflected in current architecture and ownership records?
Evidence: Change records, configuration version, owner, exception, review cadence, drift findings.
Ask: Are secrets handled through approved conceptual mechanisms with limited exposure and no unnecessary logging?
Evidence: Secret references, ownership, rotation/revocation policy, access boundary, audit evidence.
Ask: Who owns each cloud service, dependency, data store, and exception? Are owner records current?
Evidence: Service registry, owner review date, escalation path, business service mapping.
Cloud Case File
Fictional workload APP-C1 uses service identity SVC-C1 with read access to DATA-C1 and write access to QUEUE-C2.
Confidence
High
Review concern
Write permission is justified for queue updates, but the approval record is six months old.
Two fictional administrator roles exist: Cloud Platform Admin and Security Review Admin.
Confidence
High
Review concern
One user retains both roles under a temporary exception.
Exception EXC-C17 permits dual-role access for 14 days.
Confidence
High
Review concern
The exception expired three days ago and no closure or renewal evidence is attached.
DATA-C1 is classified Internal and restricted to APP-C1 plus the Security Review Admin role.
Confidence
High
Review concern
The access setting appears bounded, but classification review is 11 months old.
DATA-C2 is classified Restricted with an approved owner and current review date.
Confidence
High
Review concern
No immediate exposure issue is shown.
WEB-C1 is publicly reachable by design through a fictional managed gateway.
Confidence
High
Review concern
Public reachability is expected; review should focus on gateway purpose, logging, identity boundaries, and backend exposure.
WEB-C1 reaches APP-C1 only through the approved gateway-to-application service path.
Confidence
High
Review concern
The architecture package does not show a backup path, which may be acceptable if fail-safe service degradation is documented.
Identity and administrative logs are forwarded to MON-C1.
Confidence
High
Review concern
Storage access logs for DATA-C1 are marked optional in the current logging matrix.
MON-C1 health check failed twice during the last synthetic monthly review window.
Confidence
High
Review concern
No evidence indicates total loss, but health instability should be reviewed with fallback visibility.
DATA-C2 has daily fictional backups and a successful recovery validation 21 days ago.
Confidence
High
Review concern
Healthy evidence.
DATA-C1 has daily backup records, but the last documented recovery validation was 13 months ago.
Confidence
High
Review concern
Backup existence is current; recovery confidence is stale.
Change CHG-C44 modified APP-C1 queue-writing behavior last week.
Confidence
High
Review concern
Change approval exists, but the architecture dependency summary was not refreshed.
Cloud architecture diagram version 5.0 predates CHG-C44.
Confidence
High
Review concern
Current behavior and documentation are out of sync.
The case package references a fictional managed-secret identifier for APP-C1 and does not display any secret value.
Confidence
High
Review concern
Appropriate evidence pattern; no secret value is needed for the review.
APP-C1 owner is Team Atlas; DATA-C1 owner is Team Atlas; MON-C1 owner is Security Platform.
Confidence
High
Review concern
Ownership is clear.
APP-C1 uses EXT-C3 for a noncritical reference lookup.
Confidence
High
Review concern
The runbook says the application may continue without the lookup, but the monitoring dashboard does not show degraded-state status.
Fake Dashboard
Fictional evidence volume, priority findings, expired exceptions, and safety posture
Cloud evidence records
16
Identity, privilege, storage, logging, backup, change, secrets, ownership, and external dependency
Priority findings
8
One P0, five P1, two P2
Expired exceptions
1
Dual-role privilege exception requires immediate governance review
Real cloud access
0
All analysis remains fictional, inert, and evidence-based
Fake SOC Alert
Source: Fictional Cloud Review Queue • Time: 10:16
Fake Log Panel
[08:10] CLD-1801 identity=SVC-C1 access=DATA-C1:READ,QUEUE-C2:WRITE approval_age=6_MONTHS [08:28] CLD-1803 exception=EXC-C17 state=EXPIRED age=3_DAYS [08:46] CLD-1804 storage=DATA-C1 classification=INTERNAL review_age=11_MONTHS [09:04] CLD-1808 logging=DATA-C1_ACCESS requirement=OPTIONAL [09:22] CLD-1809 monitor=MON-C1 failed_health_checks=2 window=MONTHLY [09:40] CLD-1811 backup=DATA-C1 daily=YES recovery_validation_age=13_MONTHS [09:58] CLD-1812 change=CHG-C44 approved=YES architecture_refreshed=NO [10:16] CLD-1816 dependency=EXT-C3 criticality=NONCRITICAL degraded_state_visible=NO
Training note: this is fake data for defensive analysis practice only.
Cloud Findings
Evidence
CLD-1802, CLD-1803
Observed condition
One fictional user still has two privileged roles after the approved exception expired.
Risk
Separation-of-duties intent may be weakened if temporary privilege remains beyond approved scope.
Impact
High
Likelihood
Moderate
Recommendation
Return to the approved role model or obtain a new explicit, time-bounded exception with current evidence and compensating controls.
Owner
Identity Governance Owner
Validation
Confirm role state and exception closure in the synthetic access review record.
Evidence
CLD-1804
Observed condition
DATA-C1 access is bounded, but the classification review is eleven months old.
Risk
The storage configuration may still be correct while the governance basis for its classification is stale.
Impact
Moderate
Likelihood
Moderate
Recommendation
Revalidate the data classification and owner approval without changing access solely because the review date is old.
Owner
Data Governance Owner
Validation
Record a current classification decision and owner signoff.
Evidence
CLD-1808
Observed condition
Storage access telemetry for DATA-C1 is not required in the current fictional logging matrix.
Risk
Reviewers may have weaker evidence for understanding access to an important internal data store.
Impact
Moderate
Likelihood
Moderate
Recommendation
Evaluate whether access logging should become a required evidence source based on data sensitivity and review needs.
Owner
Security Monitoring Owner
Validation
Update the fictional logging matrix and confirm evidence completeness.
Evidence
CLD-1809
Observed condition
MON-C1 health checks failed twice in one synthetic review window.
Risk
If monitoring becomes unavailable, the team may lose timely visibility into identity and administrative events.
Impact
High
Likelihood
Low to Moderate
Recommendation
Review monitoring health evidence, fallback visibility, and recovery ownership before the next expansion.
Owner
Security Platform Owner
Validation
Run a fictional tabletop and confirm the team retains required evidence during MON-C1 degradation.
Evidence
CLD-1811
Observed condition
DATA-C1 backups are current, but recovery validation evidence is thirteen months old.
Risk
Backup creation alone does not prove the organization can restore the data within expected conditions.
Impact
High
Likelihood
Moderate
Recommendation
Schedule a synthetic recovery validation and update recovery ownership and evidence.
Owner
Application Resilience Owner
Validation
Document successful fictional recovery validation and review date.
Evidence
CLD-1812, CLD-1813
Observed condition
APP-C1 queue-writing behavior changed, but the architecture dependency summary still shows the older design.
Risk
Reviewers may reason from an outdated model of current service behavior.
Impact
Moderate
Likelihood
High
Recommendation
Refresh the architecture diagram and dependency summary with the approved change evidence.
Owner
Cloud Architecture Owner
Validation
Compare the new diagram with CHG-C44 and current service behavior records.
Evidence
CLD-1816
Observed condition
APP-C1 may continue without EXT-C3, but the dashboard does not expose that degraded mode.
Risk
The service may appear fully healthy while optional capability is unavailable.
Impact
Low to Moderate
Likelihood
Moderate
Recommendation
Add a visible degraded-state indicator to the fictional operational health model.
Owner
Application Service Owner
Validation
Use a synthetic EXT-C3 outage scenario and confirm degraded state is visible.
Evidence
CLD-1801
Observed condition
SVC-C1 permissions match documented function, but the approval record is six months old.
Risk
The permission may remain appropriate while the governance evidence becomes stale.
Impact
Moderate
Likelihood
Low
Recommendation
Revalidate the permission purpose and owner approval without broadening access.
Owner
Cloud IAM Owner
Validation
Record current approval and confirm the permission set remains least-privileged.
Analyze the Evidence
Interpretation Quality
Public service is intentionally reachable through an approved gateway.
Weak conclusion
Public means insecure.
Stronger conclusion
Public reachability is expected; review control placement, backend exposure, identity, logging, and ownership.
Backup jobs succeed every day.
Weak conclusion
Recovery is guaranteed.
Stronger conclusion
Backup creation is healthy, but recovery confidence depends on current validation evidence.
A storage policy appears restrictive.
Weak conclusion
Governance is current.
Stronger conclusion
Configuration looks bounded; review classification, owner, approval, and evidence freshness separately.
An administrator has two roles.
Weak conclusion
The access is definitely unauthorized.
Stronger conclusion
Check the approval, purpose, exception, expiration, and current role requirements before concluding.
Monitoring health failed twice.
Weak conclusion
All cloud logging is lost.
Stronger conclusion
Monitoring stability is a risk signal; inspect fallback evidence and actual collection health before making a stronger claim.
A diagram is stale.
Weak conclusion
The environment itself is misconfigured.
Stronger conclusion
The documentation no longer proves the current architecture; reconcile it with approved change records.
Cloud Risk Prioritization
Is the service intentionally public, private, internal, or restricted, and is the boundary appropriate for its purpose?
How much authority does the identity have and is it still necessary?
Would incorrect access or loss affect internal, restricted, regulated, or critical information?
How important is the workload to normal organizational operations?
Would important changes, access, or failures be visible to reviewers?
Can the workload degrade or recover safely when dependencies fail?
Can the configuration or permission be safely corrected without broad disruption?
Are the owner, approval, classification, architecture, and validation records current?
Review Artifact
Stable reference for the case finding.
Example: CF-1805
Names the fictional workload, identity, data store, logging service, or dependency.
Example: DATA-C1
Links the finding to specific cloud records.
Example: CLD-1811
States what the case package actually shows.
Example: Daily backups exist; last recovery validation is 13 months old
Explains what could happen and why the condition matters.
Example: Backups may not provide expected recovery confidence without current validation
Rates consequence in the fictional environment.
Example: High
Rates plausibility from current evidence.
Example: Moderate
Orders remediation attention.
Example: P1
Defines the bounded defensive improvement.
Example: Perform a synthetic recovery validation and refresh ownership evidence
Names the accountable fictional role.
Example: Application Resilience Owner
Records an interim safeguard while remediation is pending.
Example: Daily backup-job health review
Defines what proves the issue is resolved.
Example: Current recovery validation with documented result
Scenario Decision Lab
A fictional user still holds two privileged cloud roles even though the approved temporary exception expired three days ago.
Scenario Decision Lab
A fictional web service is intentionally public through an approved managed gateway. Backend application and data services remain on private paths.
Safe Fictional Lab
Review a synthetic cloud environment as a combination of identity, data, exposure, evidence, resilience, ownership, and governance.
Create at least forty fictional CLD records.
Give every record a stable CLD ID.
Include at least six identity and access records.
Include at least six storage and data-governance records.
Include at least five network-boundary records.
Include at least five logging and monitoring records.
Include at least five backup and recovery records.
Include at least five configuration-governance records.
Include at least three secret-governance records using identifiers only, never secret values.
Include at least five service-ownership records.
Mark evidence freshness.
Mark source ownership.
Distinguish configuration state from governance evidence.
Record public, private, internal, or restricted exposure purpose where relevant.
Record service identity purpose.
Record privileged-role purpose and review date.
Record exceptions and expiration.
Record data classification and review date.
Record logging coverage.
Record monitoring health.
Record backup existence.
Record recovery-validation freshness.
Record current architecture version.
Record approved changes not yet reflected in documentation.
Create at least fifteen CF findings.
Give every finding a stable CF ID.
Link every finding to CLD evidence.
Write bounded observed-condition statements.
Write bounded risk statements.
Assign impact.
Assign likelihood.
Assign priority.
Assign a fictional owner.
Identify compensating controls.
Define validation evidence.
Create at least three findings where configuration looks safe but governance evidence is stale.
Create at least three findings where a public or external boundary is expected and not automatically a vulnerability.
Create at least three resilience findings.
Create at least three monitoring or logging findings.
Create at least three identity-governance findings.
Write a prioritized remediation sequence.
Write a one-page leadership summary.
Keep every record fictional, synthetic, and non-disruptive.
Lab boundary
Use only fictional cloud identities, roles, storage records, architecture diagrams, logging evidence, backup records, change records, and managed-secret identifiers. Never use real secrets, credentials, tenants, cloud consoles, accounts, or live services.
Analyze the Evidence
Advanced Challenge
Using the Northbridge case, create a prioritized remediation sequence that explains what should happen first, why, who owns it, what evidence is needed, and what can wait.
P0 governance issue
Highest identity risk
Highest storage-governance issue
Highest logging concern
Highest monitoring concern
Highest recovery concern
Highest documentation concern
Highest external-dependency concern
Compensating control
Owner
Validation evidence
Review date
What should not change yet
Leadership summary
The strongest sequence should distinguish urgent governance gaps from lower-priority documentation or usability improvements.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the third artifact for your A18 Advanced Defensive Casebook: a fictional Cloud Security Case Review. Include shared-responsibility assumptions, identity and privileged-access evidence, storage classification and exposure, network boundaries, logging and monitoring, backup and recovery, configuration governance, secret references, ownership, external dependencies, at least fifteen findings, evidence links, impact, likelihood, priority, compensating controls, remediation owners, validation criteria, remediation sequence, and a one-page leadership summary.
Confidence / Readiness Reflection
A18.4 focuses on a fictional identity access review. Before continuing, make sure you can distinguish cloud identity, configuration, exposure, logging, recovery, and governance evidence without treating one setting as the entire security story.
I can explain shared responsibility.
I can separate configuration state from governance freshness.
I can review cloud identity, storage, logging, backup, and architecture evidence together.
I can prioritize cloud findings without exaggerating what the evidence proves.
I can write remediation recommendations without accessing or changing a real cloud environment.
Portfolio Build Guide
A reviewer should know which workloads, data stores, identities, and dependencies are in scope.
A safe-looking configuration can still have stale approval or ownership evidence.
Every finding should trace directly to specific fictional cloud records.
Use managed-secret identifiers or metadata only; never include secret values.
Backup, recovery, monitoring health, and degraded-mode behavior all belong in the cloud story.
Intentional public access should be evaluated by purpose and controls, not labeled unsafe by default.
P0 and P1 findings should clearly outrank lower-impact documentation improvements.
A18.4 narrows the focus to identity access review, approval, stale privilege, and exception decisions.
Key Takeaways
Lesson Safety Boundary
Do not access real cloud consoles, tenants, accounts, secrets, credentials, tokens, private records, or production tools. Do not test or modify real cloud configurations. This lesson uses synthetic evidence to practice cloud architecture, identity, data, logging, recovery, governance, and risk review.
Lesson Complete
You now have a defensible cloud-review model covering shared responsibility, identity, storage, network boundaries, logging, monitoring, backup, recovery, secrets, ownership, configuration governance, findings, and remediation priorities. Next, A18.4 moves into an Identity Access Review Case.