Cloud service
A fictional provider-hosted computing capability such as storage, identity, networking, databases, applications, or managed processing.
High School IntermediateModule I13Lesson 1 of 8
I13.1 Shared Responsibility and Cloud Security Foundations
Learn how defenders map fictional cloud services, deployment models, provider and customer duties, accounts, projects, regions, assets, owners, data flows, trust boundaries, evidence, and responsibility gaps before making any cloud-security decision.
Lesson Progress
Shared Responsibility and Cloud Security Foundations
High School Intermediate • I13: Cloud Security Basics • Lesson 1 of 8
13% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
The Cloud Provider Can Operate the Service while the Customer Still Owns the Risky Setting
The fictional Northbridge Learning Cloud uses a managed application platform, object storage, a managed database, a serverless export function, cloud identity, virtual networking, logging, and managed backups. A storage role is broader than the export workflow requires, one network path is wider than the approved private design, and logging coverage differs between storage collections. None of these customer-controlled conditions are automatically fixed merely because the services are provider-managed.
Weak assumption
The provider secures the cloud, so customer roles, storage permissions, network routes, logging, retention, and recovery do not require separate ownership.
Professional approach
Define the service boundary, assign every control to a named provider or customer owner, identify shared handoffs, examine evidence, preserve limits, and coordinate safe action.
Objective 1
Explain fictional cloud service and deployment models without treating the cloud as one undifferentiated system.
Objective 2
Map fictional provider, customer, partner, application-owner, identity-owner, data-owner, and user responsibilities across a complete cloud service.
Objective 3
Identify fictional accounts, subscriptions, projects, regions, identities, data stores, networks, services, dependencies, and trust boundaries before evaluating risk.
Objective 4
Separate direct observations from supported findings, alternative explanations, confidence, limitations, and missing evidence.
Objective 5
Create a portfolio-safe fictional shared-responsibility and cloud-asset package with owners, controls, evidence, gaps, and review decisions.
Why This Matters
Unclear Responsibility Creates Unprotected Controls and Delayed Response
Fictional cloud failures often occur because a security duty is assumed rather than assigned. The provider may offer logging, but the customer must enable, retain, protect, and review it. The provider may offer encryption, but the customer must choose the correct design, key ownership, access, and recovery process. The provider may operate a managed database, but the customer still controls identities, network access, data classification, backup choices, and application usage.
Core Concept
Use the Service–Asset–Boundary–Owner Model
Service
Which fictional cloud service and deployment model are used, and which platform layers does the provider operate?
Asset
Which fictional applications, identities, data stores, networks, keys, logs, backups, dependencies, and business processes require protection?
Boundary
Where do fictional data, identity, authority, network path, provider control, customer control, or partner responsibility change?
Owner
Which fictional provider, team, data owner, identity owner, application owner, network owner, user, or partner owns each decision and action?
Key Vocabulary
Cloud Foundations and Responsibility Terms
Service model
A fictional division of technical responsibility between provider and customer, commonly described as infrastructure, platform, or software services.
Deployment model
A fictional way cloud services are organized, such as public, private, hybrid, community, or multi-cloud environments.
Shared responsibility
The fictional division of security duties among the provider, customer organization, application team, data owner, identity owner, network owner, user, and partner.
Tenant
A fictional organization or isolated customer environment within a shared provider platform.
Account or subscription
A fictional administrative and billing boundary containing cloud resources, identities, policies, logs, and ownership.
Project or resource group
A fictional organizational boundary used to group related services, permissions, budgets, policies, and environments.
Region
A fictional geographic provider location containing one or more availability areas and services.
Availability zone
A fictional separated provider location within a region used to improve resilience and reduce common failure risk.
Managed service
A fictional cloud capability where the provider operates more of the platform while the customer still owns configuration, access, data, and usage decisions.
Trust boundary
A fictional point where data, identity, authority, ownership, network path, or responsibility changes.
Cloud asset
A fictional identity, service, data store, application, network, key, configuration, log source, dependency, or business process that requires ownership and protection.
Responsibility gap
A fictional security duty that is missing, unclear, duplicated without coordination, or incorrectly assumed to belong to another party.
Evidence boundary
The fictional limit of what supplied records can support about configuration, activity, ownership, exposure, or impact.
Service Models
Provider and Customer Duties Change by Service Type
Infrastructure as a Service
Provider generally operates
Fictional physical facilities, hardware, core virtualization, and foundational provider network.
Customer generally owns
Fictional operating systems, workloads, identities, data, application configuration, network rules, logging, patching choices, and recovery.
Common gap
The customer assumes the provider secures the guest operating system or application configuration.
Review evidence
Asset inventory, deployment records, operating-system baseline, network rules, identity audit, monitoring, and recovery evidence.
Platform as a Service
Provider generally operates
Fictional managed runtime, platform patching, core service availability, and underlying infrastructure.
Customer generally owns
Fictional application code, identities, secrets, data, service configuration, access, logging, dependencies, and secure deployment.
Common gap
The application team assumes managed runtime automatically means secure application, identity, secret, and data configuration.
Review evidence
Application configuration, deployment pipeline, identity roles, secret references, audit logs, source-health records, and owner approvals.
Software as a Service
Provider generally operates
Fictional application platform, core service operation, infrastructure, and provider-controlled software maintenance.
Customer generally owns
Fictional tenant settings, identities, access policies, data classification, sharing, retention, integration security, monitoring, and user governance.
Common gap
The customer assumes provider operation removes the need for tenant-level access, sharing, retention, and identity controls.
Review evidence
Tenant configuration, identity records, sharing audit, retention settings, integration list, administrator actions, and support evidence.
Serverless or Function Service
Provider generally operates
Fictional execution platform, scaling mechanism, infrastructure, and provider-managed runtime components.
Customer generally owns
Fictional function code, trigger configuration, identities, permissions, dependencies, secrets, data access, logging, and event handling.
Common gap
The customer overlooks broad function roles, unsafe triggers, unreviewed dependencies, or missing logging because no server is directly managed.
Review evidence
Function configuration, trigger map, role policy, deployment artifact, dependency inventory, invocation logs, and data-flow records.
Managed Database Service
Provider generally operates
Fictional database platform operation, infrastructure, service availability features, and provider-controlled engine maintenance boundaries.
Customer generally owns
Fictional database identities, network access, encryption choices, backups, retention, schema permissions, query logging, and data governance.
Common gap
The customer assumes managed database means provider-owned access control, backup validation, classification, and network exposure.
Review evidence
Database role map, network configuration, backup reports, encryption settings, retention, audit logs, and recovery validation.
Managed Object Storage
Provider generally operates
Fictional storage service availability, durability mechanisms, underlying infrastructure, and service APIs.
Customer generally owns
Fictional object permissions, public-access settings, encryption choices, keys, versioning, retention, lifecycle, classification, and monitoring.
Common gap
The customer assumes durable storage is automatically private, correctly retained, recoverable, and monitored.
Review evidence
Storage policy, access list, sharing audit, encryption settings, key ownership, versioning, lifecycle, logging, and restore tests.
Deployment Models
Public, Private, Hybrid, Multi-Cloud, and Partner Boundaries
Public cloud
A fictional provider operates shared infrastructure while each customer controls its own tenant, identities, data, configuration, and usage.
Responsibility focus
Tenant isolation, provider assurance, customer configuration, access, data protection, logging, and third-party dependency.
Evidence needed
Provider documentation, tenant controls, identity records, configuration exports, audit logs, data-flow maps, and owner decisions.
Private cloud
A fictional organization or dedicated provider operates cloud-like infrastructure for one organization.
Responsibility focus
Internal platform operation, capacity, patching, virtualization, identity, network, data, application, backup, and governance ownership.
Evidence needed
Platform ownership, infrastructure records, baseline, patching, network maps, tenant policies, logging, recovery, and internal assurance.
Hybrid cloud
Fictional on-premises and cloud services exchange identity, data, applications, or network traffic across trust boundaries.
Responsibility focus
Connector security, identity federation, data movement, routing, logging continuity, ownership handoffs, and failure isolation.
Evidence needed
End-to-end architecture, identity trust, connection records, data classification, routing, service logs, ownership, and recovery plans.
Multi-cloud
A fictional organization uses services from more than one cloud provider for different workloads or resilience goals.
Responsibility focus
Consistent identity, policy, inventory, logging, keys, data movement, ownership, skills, vendor coordination, and incident response.
Evidence needed
Cross-provider asset register, identity map, policy comparison, logging coverage, data flows, provider contacts, and shared incident plan.
Responsibility focus
Evidence needed
Responsibility focus
Evidence needed
Responsibility focus
Evidence needed
Responsibility focus
Evidence needed
Responsibility focus
Evidence needed
Responsibility focus
Evidence needed
Responsibility Matrix
Eight Control Domains and Their Common Gaps
Physical and facility security
Provider responsibility
Operates fictional facilities, hardware access, environmental protections, physical monitoring, and hardware retirement.
Customer responsibility
Reviews provider assurance and selects an appropriate service and region based on business needs.
Shared coordination
Documents provider assurance, customer requirements, exceptions, and residual risk.
Common responsibility gap
No owner verifies whether provider assurance matches the sensitivity and resilience requirement.
Identity and access
Provider responsibility
Provides fictional identity, role, policy, authentication, federation, and audit capabilities.
Customer responsibility
Designs identities, roles, approvals, least privilege, privileged access, lifecycle, reviews, and monitoring.
Shared coordination
Coordinates identity incidents, provider support, and evidence exchange.
Common responsibility gap
Broad roles remain because provider capability exists but customer governance does not.
Network and service exposure
Provider responsibility
Operates fictional core provider networking and service availability.
Customer responsibility
Configures virtual networks, routes, gateways, endpoints, security rules, load balancers, and service exposure.
Shared coordination
Maintains provider service protections and customer-specific network boundaries.
Common responsibility gap
A customer-managed endpoint becomes public even though the underlying service is provider-managed.
Data protection
Provider responsibility
Provides fictional storage durability, encryption features, key options, backups, replication, and service controls.
Customer responsibility
Classifies data, selects encryption, manages access, controls sharing, validates backup and restore, retention, and disposal.
Shared coordination
Defines technical features, customer choices, contractual requirements, and recovery expectations.
Common responsibility gap
The customer mistakes provider durability for complete backup, retention, and recovery assurance.
Application and workload security
Provider responsibility
Secures fictional provider-managed runtime components within the service boundary.
Customer responsibility
Secures code, configuration, dependencies, secrets, workload identities, deployment, validation, and application logging.
Shared coordination
Coordinates platform updates, compatibility, advisories, and incident evidence.
Common responsibility gap
An insecure customer configuration remains because the service itself is managed.
Logging and monitoring
Provider responsibility
Generates fictional platform and service audit capabilities within documented coverage.
Customer responsibility
Enables, retains, protects, monitors, correlates, reviews, and responds to relevant records.
Shared coordination
Documents available events, delivery, health, retention, access, and incident support.
Common responsibility gap
Logs exist as a feature but are disabled, unowned, unretained, or never reviewed.
Incident response and recovery
Provider responsibility
Responds to fictional provider-controlled incidents and supports customer cases within service terms.
Customer responsibility
Owns tenant investigation, containment, identity actions, configuration correction, communication, recovery, and closure.
Shared coordination
Coordinates evidence, timing, provider support, customer decisions, and notifications.
Common responsibility gap
Each party waits for the other because the handoff and decision authority are unclear.
Cloud Asset Map
Northbridge Learning Cloud Assets, Owners, and Trust Boundaries
NLC-A-01
Learning portal application
Managed application platformOwner
Learning Application Team
Data
Student practice records and fictional course progress
Dependencies
Identity, object storage, database, logging, and private API
Trust boundary
Public user edge → managed application → private services
Review evidence
Deployment, application audit, identity, network, storage, and monitoring records
NLC-A-02
Course-content storage
Managed object storageOwner
Content Platform Owner
Data
Fictional lesson media, worksheets, and approved public assets
Dependencies
Content delivery, encryption, key service, logging, and lifecycle policy
Trust boundary
Private administration → storage; approved public delivery through content service
Review evidence
Storage policy, access audit, encryption, versioning, lifecycle, sharing, and restore records
NLC-A-03
Student-progress database
Managed databaseOwner
Learning Data Owner
Data
Fictional student identifiers, progress events, and assessment summaries
Dependencies
Application identity, private network, encryption, backup, and audit logging
Trust boundary
Private application service → managed database
Review evidence
Database roles, network rules, encryption, query audit, backup, restore, and retention records
NLC-A-04
Export automation function
Serverless functionOwner
Learning Operations Team
Data
Approved fictional progress exports
Dependencies
Service identity, object storage, database read role, event trigger, and logging
Trust boundary
Scheduled trigger → function identity → approved data stores
Review evidence
Function configuration, role policy, trigger, invocation log, storage transaction, and deployment artifact
NLC-A-05
Cloud identity tenant
Identity serviceOwner
Identity Governance Team
Data
Fictional users, groups, roles, service identities, and sessions
Dependencies
Federation, authentication policy, privileged workflow, access review, and audit logs
Trust boundary
External identity provider → cloud tenant → application and service roles
Review evidence
Role map, sign-in audit, service identities, privileged approvals, lifecycle, and access review
NLC-A-06
Learning cloud network
Virtual network and private servicesOwner
Cloud Network Team
Data
Fictional application, administration, storage, database, and monitoring traffic
Dependencies
Subnets, routes, gateways, private endpoints, load balancer, security rules, and flow logs
Trust boundary
Public edge, application subnet, private-service subnet, administrative path, and provider services
Review evidence
Network map, rules, routes, flow records, endpoint configuration, and change approvals
NLC-A-07
Cloud audit and monitoring pipeline
Logging and detection serviceOwner
Cloud Security Operations
Data
Fictional identity, control-plane, storage, network, application, and configuration events
Dependencies
Source enablement, delivery, retention, access, detection rules, alerts, and source-health monitoring
Trust boundary
Cloud services → logging pipeline → restricted monitoring workspace
Review evidence
Source matrix, delivery status, retention, access, detections, alerts, and response records
NLC-A-08
Backup and recovery repository
Managed backup storageOwner
Continuity and Recovery Team
Data
Fictional database backups, configuration exports, and approved recovery points
Dependencies
Encryption, separate identity, retention, immutability concept, restore testing, and incident access
Trust boundary
Protected services → controlled backup repository → recovery workflow
Review evidence
Backup jobs, retention, encryption, access, restore tests, exceptions, and owner approvals
Defensive Workflow
Build a Fictional Shared-Responsibility Review
Confirm the fictional cloud service boundary
Restate the approved business service, service model, deployment model, tenant, accounts, projects, regions, evidence sources, owners, privacy limits, and prohibited real-system actions.
Output: Cloud review objective and scope.
Inventory assets and dependencies
Record fictional applications, identities, storage, databases, networks, keys, logs, backups, deployment systems, users, data classes, and service dependencies.
Output: Cloud asset and dependency register.
Map trust boundaries and data flows
Identify where fictional identity, data, traffic, authority, ownership, provider control, customer control, or partner responsibility changes.
Output: Trust-boundary and data-flow map.
Assign responsibility by control domain
For each fictional domain, document provider duty, customer duty, shared coordination, named owner, evidence, reviewer, and escalation.
Output: Shared-responsibility matrix.
Find responsibility gaps
Look for fictional missing ownership, duplicated effort, unclear handoffs, disabled controls, unreviewed provider assumptions, and unsupported customer expectations.
Output: Responsibility-gap register.
Correlate supporting evidence
Compare fictional architecture, identity, configuration, deployment, network, storage, database, application, logging, backup, support, and provider records.
Output: Evidence-backed findings and alternatives.
Plan defensive ownership
Assign fictional actions, approvals, deadlines, validation, rollback, monitoring, communication, residual risk, and closure evidence.
Output: Owned cloud security action plan.
Review and communicate
Confirm fictional evidence lineage, source health, privacy, need-to-know, confidence, limitations, reviewer approval, and portfolio-safe communication.
Output: Reviewed responsibility package.
Fake Dashboard
Fake Northbridge Cloud Responsibility Dashboard
Training dashboard for fictional cloud evidence only.
Mapped cloud assets
8
Applications, identity, storage, database, network, logging, export automation, and recovery are assigned.
Responsibility gaps
3
Broad storage role, wider network path, and incomplete logging ownership require review.
Unresolved owner decisions
2
Final permission approval and network-exception ownership remain undocumented.
Fake SOC Alert
Managed Storage Has a Customer-Owned Access Gap
Source: Fake Cloud Responsibility Console • Time: 10:18 AM
The fictional provider operates the managed storage service, but the customer-managed export role can read two storage collections even though the approved workflow requires one.
Defensive recommendation: Do not blame the provider or assume misuse. Confirm the service boundary, effective access, business requirement, migration history, owners, logging coverage, network paths, dependencies, and validation plan. Assign coordinated fictional action to the identity, application, storage, network, monitoring, and change-approval owners.
Fake Log Panel
Fake Northbridge Shared-Responsibility Records
training-log-viewer.log
09:00 SCOPE service='Northbridge Learning Cloud' model='managed platform' 09:05 ASSET count='8' owners='assigned' 09:12 ROLE name='export-automation-role' collections='approved,archive-secondary' 09:14 REQUIREMENT collections_needed='approved only' 09:18 HISTORY role_scope='migration temporary' closure='missing' 09:25 NETWORK private_endpoint='enabled' wider_route='present' 09:31 LOGGING approved_collection='enabled' archive_secondary='disabled' 09:38 PROVIDER assurance='physical, infrastructure, managed service' 09:44 GAP identity_owner='assigned' final_approver='missing' 09:50 FINDING overpermission='supported' misuse='not proven' 10:02 FINDING route_gap='supported' public_reachability='not proven' 10:10 ACTION teams='application,identity,storage,network,security,change' 10:18 REVIEW evidence_lineage='complete' confidence='high' 10:25 LIMIT contract_detail='approved agreement required' 10:30 PORTFOLIO fictionalization='required'
Training note: this is fake data for defensive analysis practice only.
Supplied Case Records
Northbridge Responsibility Evidence
NLC-R-01
Provider service description
Direct observation
The fictional provider operates the managed object-storage service, underlying infrastructure, and service APIs.
Supported meaning
The provider owns service operation within the documented service boundary.
Limitation
The description does not show the customer's tenant configuration or data-access decisions.
NLC-R-02
Tenant storage policy
Direct observation
The fictional customer allows the export automation role to list and read two storage collections, although its approved workflow needs one.
Supported meaning
The customer-managed role appears broader than the documented business need.
Limitation
Effective access still requires identity, inherited policy, and service-control correlation.
NLC-R-03
Network architecture
Direct observation
The fictional storage service supports a private endpoint, but the tenant also permits a wider provider-service route.
Supported meaning
The customer has not fully limited the service to the approved private path.
Limitation
Reachability and exposure require route, rule, endpoint, and flow evidence.
NLC-R-04
Audit configuration
Direct observation
Control-plane logging is enabled, but object-level access logging is enabled only for the approved collection.
Supported meaning
Monitoring coverage differs across the two collections available to the role.
Limitation
A missing event cannot be interpreted until expected event types, health, and retention are verified.
NLC-R-05
Ownership register
Direct observation
The application team owns the export function, the identity team owns roles, and the content owner owns storage data.
Supported meaning
Several teams must coordinate to reduce the broad access safely.
Limitation
The register does not define who approves the final permission change.
NLC-R-06
Provider assurance statement
Direct observation
The fictional provider documents physical, infrastructure, and managed-service controls.
Supported meaning
Provider assurance supports provider-controlled responsibilities.
Limitation
It does not prove the customer's identities, access policies, logging, retention, or network configuration are secure.
NLC-R-07
Business requirement
Direct observation
The export automation must read one approved content collection and write generated packages to one export collection.
Supported meaning
The documented workflow provides the least-privilege reference.
Limitation
Operational exceptions and emergency workflows require separate evidence.
NLC-R-08
Change history
Direct observation
The broader storage role was created during a fictional migration and never reduced after the migration ended.
Supported meaning
Temporary migration access became a persistent responsibility gap.
Limitation
The record does not prove misuse or impact.
Findings Matrix
Northbridge Responsibility Findings and Limits
NLC-F-01
The fictional provider operates the managed storage service, but the customer owns tenant identities, permissions, network paths, logging choices, data classification, retention, and recovery decisions.
HighEvidence support
Provider service description, tenant architecture, ownership register, identity policy, storage policy, and business requirements.
Alternative
No evidence supports transferring these tenant responsibilities entirely to the provider.
Limitation
Exact contractual duties require the approved fictional agreement.
NLC-F-02
The export automation role has broader storage access than its documented workflow requires.
HighEvidence support
Tenant role policy, effective-access record, application requirement, storage collection map, and migration history.
Alternative
A still-active migration need is possible but not supported by current owner documentation.
Limitation
No evidence supports misuse or unauthorized data access.
NLC-F-03
The wider provider-service network route is a customer-managed design gap because the approved architecture expects the private endpoint.
Medium-HighEvidence support
Architecture diagram, endpoint configuration, route policy, network rules, flow records, and owner requirement.
Alternative
The wider route may support an undocumented operational exception.
Limitation
Reachability and practical exposure remain bounded by effective rule and service-control evidence.
NLC-F-04
Monitoring coverage is incomplete for one storage collection available to the export role.
HighEvidence support
Audit configuration, source-health matrix, event coverage documentation, role access, and storage ownership.
Alternative
Provider-level service logs may contain limited related events but do not replace tenant object-access coverage.
Limitation
No missing event should be interpreted as proof of no activity.
NLC-F-05
The main control weakness is an ownership and lifecycle gap that allowed temporary migration access to remain after the migration ended.
HighEvidence support
Change history, business requirement, ownership register, access review, and absent closure evidence.
Alternative
A deliberate permanent exception is possible but no approved exception record is supplied.
Limitation
The evidence supports governance failure, not malicious intent.
NLC-F-06
The safest corrective path requires coordinated action by the application, identity, storage, network, security-operations, and change-approval owners.
HighEvidence support
Responsibility map, dependency register, role ownership, network ownership, logging ownership, and validation requirements.
Alternative
A single-team change could be faster but would risk incomplete validation or service disruption.
Limitation
Final implementation depends on approved fictional change procedures.
Analyze the Evidence
Who Owns the Broad Storage Role?
The fictional provider operates the managed object-storage service and underlying infrastructure.
The customer defines the export automation identity and role policy.
The role can read two storage collections, but the approved workflow requires one.
The broader access was created for a completed migration and has no current approved exception.
Logging coverage is incomplete for the second collection.
The provider assurance statement does not evaluate customer tenant roles or logging choices.
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Cloud Responsibility Analysis
Treating the cloud provider as responsible for every fictional security control.
Treating the customer as responsible for provider-controlled physical or core platform controls.
Using the label managed service as proof that customer configuration, identity, data, logging, and recovery are automatically secure.
Beginning a cloud review without identifying the fictional service model, deployment model, tenant, accounts, projects, regions, owners, and trust boundaries.
Listing cloud resources without business purpose, data class, owner, dependency, evidence source, and lifecycle state.
Assuming provider assurance proves the customer's tenant configuration is secure.
Assuming customer access to a provider feature means the feature is enabled, owned, retained, reviewed, or effective.
Using one dashboard as complete evidence of identity, network, storage, application, logging, and impact.
Treating a broad role as proof of misuse rather than a least-privilege and governance finding.
Treating a public-capable service as proof that a resource is publicly reachable.
Ignoring hybrid, multi-cloud, partner, federation, and integration trust boundaries.
Failing to identify who approves changes when several fictional teams share responsibility.
Writing remediation without owner, approval, deadline, validation, rollback, monitoring, and completion evidence.
Using or exposing any real cloud account, tenant, project, role, bucket, database, key, route, log, alert, owner, or private data.
Safe Practice Lab
Build the Northbridge Shared-Responsibility and Cloud-Asset Package
Your fictional assignment
Service Boundary, Asset Map, Responsibility Matrix, and Action Plan
Use only the supplied fictional Northbridge records to map the cloud environment and identify responsibility gaps.
Required deliverables
- Service model, deployment model, tenant, accounts, projects, regions, and review scope.
- Asset inventory with owner, data, dependency, trust boundary, and evidence source.
- Provider, customer, shared, reviewer, and escalation responsibilities for each control domain.
- Trust-boundary and data-flow map.
- Responsibility-gap register with evidence, alternatives, confidence, and limitations.
- Owned action plan with approval, deadline, validation, rollback, monitoring, and completion evidence.
- Technical summary, leadership summary, and portfolio-safety statement.
Do not sign in to or inspect any real cloud environment. Complete the lab only with fictional records displayed on this page.
Scenario Decision Lab
The Team Says the Provider Owns the Broad Role
The fictional export automation role is broader than required, but the application team argues that the provider owns storage security.
Scenario Decision Lab
A Private Endpoint Exists, but a Wider Route Also Remains
The fictional architecture expects private access, yet a wider provider-service route is still allowed.
Defender Habits
Shared Responsibility and Cloud Foundations Checklist
Check Your Understanding
I13.1 Mini Quiz: Shared Responsibility and Cloud Security Foundations
Choose your answers first. Explanations appear only after submission.
1. What does fictional shared responsibility mean?
2. Which responsibility usually remains with the fictional customer in a managed object-storage service?
3. Why should a fictional cloud review identify the service model?
4. What is a fictional trust boundary?
5. What can a fictional provider assurance statement support?
6. Which statement about a broad fictional service role is strongest?
7. What makes a fictional shared-responsibility finding defensible?
Portfolio Prompt
Portfolio Prompt
Create a fictional Shared Responsibility and Cloud Security Foundations Package for the Northbridge Learning Cloud. Include service and deployment models, tenant and account boundaries, asset inventory, owner map, data-flow diagram, trust boundaries, responsibility matrix, provider assurance boundary, evidence register, responsibility gaps, findings, alternatives, confidence, limitations, action owners, validation, rollback, monitoring, and a portfolio-safety statement.
Use only fictional providers, organizations, tenants, accounts, projects, identities, services, data, networks, keys, logs, owners, and decisions.
Do not assign a control to the provider or customer without showing the service boundary and supporting evidence.
Distinguish a responsibility gap from proof of misuse, compromise, or impact.
Make every asset, control, finding, and action traceable to a named fictional owner and parent evidence.
Key Takeaways
What You Should Remember
1.Cloud security is divided across provider, customer, application, data, identity, network, user, and partner responsibilities.
2.Managed service does not mean managed customer configuration, access, data governance, logging, or recovery decisions.
3.Service and deployment models change the location of responsibilities and trust boundaries.
4.A cloud review should begin with assets, owners, data, dependencies, regions, accounts, projects, and evidence boundaries.
5.Provider assurance supports provider-controlled duties but does not prove customer tenant settings are secure.
6.Responsibility gaps should be supported by evidence and reported without assuming misuse or intent.
7.Portfolio artifacts should recreate cloud responsibility reasoning with fully fictional services and records.
Navigation