Provider-operated
The provider runs and protects a layer the customer cannot directly operate, such as physical infrastructure.
High School AdvancedA12.1Cloud Security Architecture
Lesson A12.1
Cloud Architecture and Shared Responsibility
Cloud security starts with a deceptively simple question: who owns what? The provider may operate the cloud service, but the organization still makes critical decisions about identity, data, configuration, access, applications, logging, resilience, and governance.
This lesson uses fictional cloud services and synthetic evidence to show how responsibility changes across service models and how ownership gaps become architecture risk.
Lesson Progress
Cloud Architecture and Shared Responsibility
High School Advanced • A12: Cloud Security Architecture • Lesson 1 of 10
10% complete
Readiness Check
A12.1 Entry Readiness
0/4 ready
Professional Hook
The Provider Can Secure the Cloud Service While the Customer Still Configures It Unsafely
Imagine a fictional team chooses a managed object-storage service. The provider operates the storage hardware, service software, and underlying infrastructure. The customer organization still decides who can access the storage, whether it is exposed publicly, how long files remain, which applications write to it, whether logging is enabled, and how backup or deletion works.
Both sides matter. The provider secures the service layer it operates. The organization must securely configure and use the service.
Shared responsibility is about control boundaries, not shared blame.
Learning Objectives
Five Capabilities for This Lesson
1
Explain shared responsibility as a cloud security ownership model rather than a slogan that assigns all security work to either the provider or the customer.
2
Compare how responsibility changes across infrastructure, platform, managed-service, and software-service models without assuming the same boundary applies everywhere.
3
Map cloud security responsibilities for identity, data, configuration, applications, networks, logging, resilience, and lifecycle ownership.
4
Evaluate fictional cloud evidence to determine which responsibilities are Confirmed, Conditional, Unknown, or misassigned.
5
Build a Shared Responsibility and Ownership Map that becomes the first artifact in the A12 Cloud Security Architecture Assessment.
The Core Idea
Security Responsibility Follows Control
A useful way to think about cloud responsibility is to ask who can actually operate or change each layer. The provider controls the provider-operated infrastructure. The organization controls how it configures identities, data, access, applications, integrations, logging, and business processes.
Some outcomes are genuinely shared. For example, the provider may offer an identity service and protect the infrastructure behind it, while the organization defines privileged roles, account lifecycle, federation, access reviews, and application authorization.
Customer-managed
The organization configures, owns, reviews, or validates the control directly.
Shared outcome
Provider capability and customer configuration both contribute to the security result.
Service Models
Responsibility Changes as the Provider Operates More of the Stack
Service models are useful because they show how operational responsibility moves. They do not remove the need to read the provider's actual service documentation in real-world work.
Infrastructure-oriented cloud service
Provider
The provider generally operates physical facilities, physical servers, core networking, and the underlying virtualization or hardware service.
Organization
The organization often retains significant responsibility for guest operating systems, application software, identities, data, security configuration, workload networking, logging, patching choices, and recovery design.
Architecture lesson
More infrastructure control usually means more direct operational and configuration responsibility for the organization.
Platform-oriented cloud service
Provider
The provider operates more of the underlying compute platform, runtime, or managed application environment.
Organization
The organization still owns application code, identities, data, permissions, service configuration, integration choices, monitoring expectations, and secure use of the platform.
Architecture lesson
Managed platforms reduce some infrastructure work but do not remove application, identity, data, or configuration responsibility.
Managed data or application service
Provider
The provider may operate the service engine, availability mechanisms, patching of the managed service, and the underlying infrastructure.
Organization
The organization still decides what data enters the service, who can access it, how identities are configured, which network paths exist, how retention works, and what evidence is monitored.
Architecture lesson
A highly managed service can still be insecure when access, configuration, data handling, or monitoring is poorly designed.
Software-as-a-service style product
Provider
The provider operates the application platform and most of the software stack.
Organization
The organization still owns account lifecycle, role assignment, tenant configuration, data-sharing decisions, integrations, user behavior, retention choices, audit review, and governance.
Architecture lesson
Using finished software shifts technical operations to the provider, but the organization still owns how the service is configured and used.
Responsibility Domains
Twelve Cloud Security Areas That Need Named Owners
Physical infrastructure
Provider role
Typically provider-operated in public cloud environments.
Organization role
Usually no direct operation of provider facilities or hardware.
Shared-responsibility question
What provider assurance or service documentation supports the organization's trust assumptions?
Cloud service availability
Provider role
Operates the underlying service according to the published service design and commitments.
Organization role
Chooses architecture patterns, regions or zones where applicable, dependencies, recovery strategies, and business continuity plans.
Shared-responsibility question
Does the organization's architecture actually use the provider's resilience features correctly?
Identity and access
Provider role
Provides identity, authentication, authorization, federation, or access-control capabilities depending on the service.
Organization role
Defines users, workloads, roles, privileges, approvals, lifecycle rules, and access reviews.
Shared-responsibility question
Who owns role design, privileged access, stale identities, and evidence that least privilege is maintained?
Data
Provider role
Protects the provider-operated storage service and underlying infrastructure.
Organization role
Classifies data, chooses where it is stored, controls access, manages retention, approves sharing, and determines backups and deletion expectations.
Shared-responsibility question
Who decides whether the data belongs in the service and which identities may access it?
Application code
Provider role
May provide the hosting platform, runtime, managed service, or deployment infrastructure.
Organization role
Owns application logic, secure design, dependencies, authorization behavior, error handling, and release evidence for custom software.
Shared-responsibility question
Which application controls are implemented by the organization versus inherited from the platform?
Configuration
Provider role
Provides configuration mechanisms and supported security settings.
Organization role
Chooses and maintains the actual tenant, service, identity, storage, network, logging, and retention configuration.
Shared-responsibility question
What is the approved baseline and how is drift detected?
Network exposure
Provider role
Operates the cloud networking service and underlying infrastructure.
Organization role
Defines which services are public or private, which flows are allowed, and how ingress, egress, and service-to-service trust are bounded.
Shared-responsibility question
Who approves internet exposure or cross-boundary connectivity?
Logging and monitoring
Provider role
Produces platform and service telemetry according to service capabilities.
Organization role
Enables required logs, routes them, protects them, defines retention, reviews alerts, monitors source health, and responds to findings.
Shared-responsibility question
A provider can offer logs, but who confirms they are enabled, current, retained, and reviewed?
Secrets and keys
Provider role
May provide managed secret and key services and protect underlying infrastructure.
Organization role
Controls key or secret purpose, access policy, workload identity, rotation expectations, environment separation, and lifecycle ownership.
Shared-responsibility question
Who owns the access policy and evidence that secrets are not over-scoped?
Backup and recovery
Provider role
May provide backup, snapshot, replication, and recovery capabilities.
Organization role
Defines recovery requirements, configures backups, protects backup access, validates restoration, and maintains recovery ownership.
Shared-responsibility question
Does backup existence actually support the organization's recovery objective?
Compliance and governance
Provider role
Provides service assurances, documentation, certifications, and contractual information depending on the service.
Organization role
Determines whether the service and its configuration meet organizational, legal, contractual, and policy requirements.
Shared-responsibility question
Who maps provider assurances to the organization's actual use of the service?
Incident response
Provider role
Responds to incidents affecting provider-operated infrastructure and service layers.
Organization role
Responds to compromised identities, unsafe configuration, application issues, data exposure, tenant activity, and organization-owned evidence.
Shared-responsibility question
How do provider notification and organization response responsibilities connect during an incident?
Vocabulary
Shared Responsibility Terms
Shared responsibility model
A way to divide cloud security responsibilities among the provider, the organization, and sometimes multiple internal teams based on which layer each party operates or controls.
Cloud provider
The organization that operates cloud infrastructure, platforms, managed services, or software services used by a customer organization.
Customer organization
The organization consuming the cloud service and deciding how its identities, data, applications, configuration, integrations, and governance use that service.
Inherited control
A security capability primarily operated by another party, such as provider physical security, that the organization relies on through the service relationship.
Customer-managed control
A security control the organization must configure, operate, review, or validate itself.
Shared control
A security outcome where both provider capability and customer configuration or operation contribute to the final result.
Service model
The level of cloud capability consumed, which influences how much infrastructure, platform, application, and configuration responsibility remains with the organization.
Control owner
The accountable person or team responsible for ensuring a security control is configured, monitored, evidenced, and maintained.
Evidence owner
The person or team responsible for producing or maintaining the evidence needed to support a security claim.
Responsibility gap
A condition where a needed security responsibility is not clearly assigned or where each party assumes another party owns it.
Assumption
A belief the architecture relies on that should be supported by evidence or clearly marked as uncertain.
Boundary
A point where ownership, trust, identity, data handling, network exposure, or security responsibility changes.
Fictional Architecture
Northbridge Cloud Student Services Platform
The Northbridge scenario uses seven fictional cloud services. The goal is not to memorize the services. The goal is to see how responsibility changes across each one.
CLD-01Confirmed
Managed Application Platform
Purpose: Hosts the fictional Student Services Portal application
Provider responsibility
Operates underlying platform infrastructure, service runtime, and platform availability mechanisms.
Organization responsibility
Owns application code, application configuration, identity integration, data handling, dependencies, release evidence, and application logging requirements.
Accountable owner
Application Platform Team
CLD-02Confirmed
Managed Workforce Identity Service
Purpose: Authenticates counselors and administrators
Provider responsibility
Operates identity service infrastructure and supported authentication capabilities.
Organization responsibility
Defines staff lifecycle, federation, role design, privileged access, account disablement, access review, and application authorization mapping.
Accountable owner
Identity Platform Team
CLD-03Conditional
Managed Database
Purpose: Stores student-support application records
Provider responsibility
Operates database service infrastructure, service engine maintenance, and platform availability.
Organization responsibility
Owns data classification, schema, database identities, permissions, retention, application queries, backup settings, audit configuration, and recovery objectives.
Accountable owner
Data Platform + Application Team
CLD-04Conditional
Object Storage
Purpose: Stores approved generated reports and export packages
Provider responsibility
Operates storage infrastructure and supported durability and security features.
Organization responsibility
Controls storage access, public/private exposure, object lifecycle, retention, encryption configuration choices, logging, and data classification.
Accountable owner
Reporting Team
CLD-05Confirmed
Cloud Logging Service
Purpose: Collects application, identity, configuration, and platform events
Provider responsibility
Operates the logging service and supported collection/storage capabilities.
Organization responsibility
Enables required sources, defines schemas, routes events, protects access, sets retention, monitors source health, and reviews alerts.
Accountable owner
Security Monitoring
CLD-06Unknown
Managed Backup Service
Purpose: Protects critical database and storage data
Provider responsibility
Operates the backup service capability and supporting infrastructure.
Organization responsibility
Configures protected resources, retention, recovery access, restoration ownership, recovery objectives, and restoration validation.
Accountable owner
Data Platform + Recovery Owner
CLD-07Conditional
Scheduling SaaS Integration
Purpose: Coordinates approved appointment information
Provider responsibility
Operates the external scheduling product and its service infrastructure.
Organization responsibility
Controls tenant configuration, integration identity, outbound fields, user access, retention choices available to the customer, and vendor governance.
Accountable owner
Integration Owner
Fake Dashboard
Northbridge Shared Responsibility Dashboard
Fictional ownership and evidence status
Cloud services reviewed
7
Application, identity, database, storage, logging, backup, and SaaS integration
Responsibilities mapped
31 / 34
Three recovery and storage evidence duties still need ownership clarification
Current evidence
82%
Most identity, application, and logging evidence is current
Open ownership gaps
3
Two recovery items and one storage-source health item remain incomplete
Fake SOC Alert
Recovery Responsibility Gap
Source: Fictional Cloud Architecture Review • Time: 10:28
The managed backup service is configured, but the current architecture record does not identify who owns restoration validation for one critical data path.
Defensive recommendation: Keep recovery readiness Unknown until restoration ownership and current recovery evidence are established.
Ownership Evidence
A Responsibility Claim Needs Evidence
| Claim | Evidence | Owner | Status |
|---|---|---|---|
| Provider operates the physical infrastructure supporting the managed application service. | Provider service documentation and assurance materials referenced by the fictional architecture record. | Cloud Governance | Confirmed |
| Production application identities are reviewed every quarter. | Current access-review record exists for workforce identities. | Identity Platform Team | Confirmed |
| All critical storage has current restoration evidence. | Backup configuration exists, but the last documented restoration exercise predates the current architecture baseline. | Recovery Owner | Unknown |
| Cloud logging sources are healthy and current. | Identity, application, and configuration sources are current; one object-storage source lacks freshness monitoring. | Security Monitoring | Conditional |
| The scheduling SaaS receives only approved appointment fields. | Integration requirement and application test evidence support minimum-field payload. | Integration Owner | Confirmed |
| All shared responsibilities have an accountable owner. | Six services have owners; the recovery evidence owner for one backup path is still unresolved. | Cloud Architecture Owner | Conditional |
Fake Log Panel
Fictional Shared Responsibility Review Log
training-log-viewer.log
[08:30] CLD-01 app-platform provider=PLATFORM organization=APP_CODE+CONFIG owner=ApplicationPlatform [08:47] CLD-02 workforce-identity lifecycle_owner=IdentityPlatform status=CONFIRMED [09:11] CLD-03 managed-db backup_config=ENABLED restore_evidence=STALE [09:36] CLD-04 object-storage logging=ENABLED source_health=UNKNOWN [10:05] CLD-05 logging-service critical-sources=4 healthy=3 conditional=1 [10:28] CLD-06 backup-service restore-owner=UNRESOLVED status=UNKNOWN [10:54] CLD-07 scheduling-saas fields=minimized owner=IntegrationOwner status=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Evidence Analysis: Managed Backup Service
Backup jobs are configured for the critical database.
The provider operates the backup service capability.
The last documented restoration exercise predates the current architecture baseline.
One critical recovery path has no clearly assigned restoration owner.
What is the strongest conclusion about the fictional managed backup service?
Responsibility Gaps
Common Ways Teams Misread the Cloud Boundary
1
The provider handles security
Why it fails: This statement ignores customer responsibilities for identity, data, configuration, access, applications, logging, integrations, and governance.
Better approach: Name the exact provider-operated responsibility and the exact customer responsibility for each service.
2
We own everything because it is our data
Why it fails: The organization owns decisions about its data, but it does not operate the provider's physical facilities or underlying managed infrastructure.
Better approach: Separate responsibility for data governance from responsibility for infrastructure operation.
3
Managed means secure by default
Why it fails: A managed service can still be configured with overbroad access, weak retention, missing logs, unsafe integrations, or unclear ownership.
Better approach: Review how the organization configures and uses the managed service.
4
Compliance certification means our configuration is compliant
Why it fails: Provider assurance describes the provider's controls and service scope, not automatically the customer's tenant configuration or business process.
Better approach: Map provider assurance to the organization's actual architecture and control responsibilities.
5
The application team owns cloud security
Why it fails: Identity, networking, logging, data, recovery, and governance may belong to different platform and security teams.
Better approach: Use a responsibility matrix with accountable owners and evidence owners.
6
If no one is sure, mark it shared
Why it fails: Shared should describe a real division of work, not hide uncertainty or missing ownership.
Better approach: Use Unknown when ownership is unclear and resolve the gap explicitly.
Provider Assurance
Inherited Controls Still Need Customer Context
Real cloud providers publish documentation about service security, architecture, responsibilities, and assurance. Those materials can support claims about provider-operated layers. They do not automatically prove that the customer has configured its own tenant, identities, networks, storage, logging, or applications correctly.
Provider evidence can support
Provider physical and environmental controls
Provider-operated service architecture
Provider service maintenance responsibilities
Provider assurance scope
Published shared-responsibility guidance
Customer evidence still needs to support
Identity and role design
Tenant and service configuration
Data classification and access
Application behavior
Logging and monitoring configuration
Recovery testing and governance
Scenario Decision Lab
Scenario Decision Lab 1 — Backup Service vs. Recovery Ownership
Northbridge uses a managed backup service. Backup jobs are visible, but no current restoration exercise exists for the new architecture and one critical restore path has no accountable owner.
Scenario Decision Lab
Scenario Decision Lab 2 — SaaS Does Not Remove Tenant Responsibility
Northbridge adopts a fictional scheduling SaaS product. The provider operates the application and infrastructure, while Northbridge controls users, roles, tenant settings, integration fields, and audit review.
Safe Fictional Lab
Build a Shared Responsibility and Ownership Map
Use the fictional Northbridge services or create your own fictional cloud application. Do not sign in to, inspect, configure, or test a real cloud account.
1
List at least eight fictional cloud services or architecture components.
2
Write the business purpose of each service.
3
Identify the provider-operated responsibilities.
4
Identify the organization-controlled responsibilities.
5
Identify any genuinely shared outcomes.
6
Assign an accountable internal owner.
7
Assign an evidence owner where different.
8
List the evidence that supports each responsibility claim.
9
Mark the status Confirmed, Conditional, Unknown, or Not Applicable.
10
Identify at least two responsibility gaps.
11
Explain how the gap could affect identity, data, configuration, monitoring, or recovery.
12
Define the next action for each gap.
13
Add change triggers for new services, provider changes, identity changes, new data flows, or service-model changes.
Lab boundary
This is an ownership and architecture exercise. Use fictional services, synthetic identifiers, and safe evidence only.
Analyze the Evidence
Evidence Analysis: Cloud Logging Responsibility
The provider operates the managed logging service.
Northbridge enabled application, identity, and configuration log sources.
Northbridge defined retention and access policies.
One object-storage source is enabled but lacks freshness monitoring.
What is the strongest shared-responsibility conclusion?
Advanced Challenge
Resolve a Responsibility Dispute
A fictional application owner says, “The database is managed, so backup, recovery, encryption, access, and logging are all the provider's responsibility.” Write a professional architecture response that separates the responsibilities accurately.
1
Provider-operated database responsibilities
2
Organization data-classification responsibility
3
Database identity and access ownership
4
Application query and authorization ownership
5
Backup configuration ownership
6
Restoration validation ownership
7
Logging and audit configuration ownership
8
Retention ownership
9
Encryption configuration or key-governance ownership where applicable
10
Recovery objective ownership
11
Evidence owner
12
Change triggers
The strongest answer does not minimize the provider's role or the customer's role. It explains the actual boundary and the evidence needed on each side.
Defender Habits
A12.1 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A12.1 Mini Quiz: Cloud Architecture and Shared Responsibility
Choose your answers first. Explanations appear only after submission.
1. What does the cloud shared responsibility model describe?
2. Why does responsibility change across different cloud service models?
3. A cloud provider offers a managed logging service. What remains an organization responsibility?
4. A managed backup service shows successful backup jobs, but no current restoration test exists. What is the strongest recovery conclusion?
5. Which statement about SaaS is strongest?
6. When responsibility for a cloud control is unclear, what is the strongest approach?
7. Why should provider assurance documents not be treated as proof that the customer's cloud architecture is secure?
Portfolio Prompt
Portfolio Build — Shared Responsibility and Ownership Map
Create the first artifact for your A12 Cloud Security Architecture Assessment: a fictional Shared Responsibility and Ownership Map. Include at least eight cloud services or architecture components, business purpose, provider-operated responsibilities, organization responsibilities, shared outcomes, accountable owner, evidence owner, supporting evidence, status, responsibility gaps, next actions, and change triggers.
Use fictional cloud services and synthetic identifiers only.
Include more than infrastructure — identity, data, application, logging, recovery, and SaaS responsibilities should appear.
Include at least one managed service and one SaaS-style service.
Use Unknown when ownership or evidence is unclear.
Show at least one example where provider capability exists but customer configuration is still required.
Keep the map provider-neutral enough that it teaches architecture reasoning rather than memorizing one vendor.
Confidence / Readiness Reflection
Are You Ready for A12.2?
A12.2 moves deeper into Cloud IAM Architecture. Before continuing, make sure you can identify who owns identity decisions when the provider supplies the identity capability but the organization defines access.
1
I can explain shared responsibility without saying the provider handles all security.
2
I can compare infrastructure, platform, managed-service, and SaaS responsibility boundaries.
3
I can assign provider, organization, shared, and Unknown responsibilities.
4
I can connect responsibility claims to evidence owners.
5
I can explain why managed backup, logging, identity, and storage services still require customer configuration and governance.
Portfolio Build Guide
How to Make the Ownership Map Look Professional
Use stable service IDs
Give each cloud service a unique reference so later IAM, storage, network, monitoring, and governance artifacts can connect back to it.
Separate responsibility types
Use clear columns for provider-operated, organization-managed, shared, and Unknown responsibilities.
Show internal ownership
The provider/customer split is not enough. Name the accountable internal team for each customer responsibility.
Link evidence
Record what supports each responsibility claim and who maintains that evidence.
Show gaps
A professional map makes missing ownership visible instead of hiding it inside a generic Shared label.
Use service-model context
Explain how responsibility changes when the organization moves from infrastructure to a more managed platform or SaaS service.
Add change triggers
Revisit the map when the provider, service model, identity system, data type, region, network path, or integration changes.
Keep it safe to share
Use fictional provider-neutral names, synthetic IDs, and no real tenant, account, project, subscription, credential, or infrastructure details.
Key Takeaways
What You Should Remember
1.Shared responsibility is a design and ownership model, not a statement that one side handles all security.
2.The cloud service model changes which technical layers the provider operates, but customer identity, data, configuration, and governance responsibilities remain important.
3.Managed services reduce operational burden but can still be insecure when configured or governed poorly.
4.Provider assurance supports inherited-control claims but does not automatically validate the customer's tenant or architecture.
5.Shared controls require a clear division of work between provider capability and customer configuration or operation.
6.Responsibility gaps appear when teams assume another party owns a control.
7.Backup capability does not prove recovery readiness without current restoration evidence.
8.SaaS still requires customer account lifecycle, role design, data-sharing, integration, audit, and governance decisions.
9.The Shared Responsibility and Ownership Map becomes the foundation for the rest of A12.
Lesson Safety Boundary
Cloud architecture review does not require real cloud access
Do not use real cloud credentials, tenant consoles, account IDs, subscriptions, projects, storage locations, keys, private logs, or production resources. All evidence in this lesson is fictional and defensive.
Lesson Complete
A12.1 Cloud Architecture and Shared Responsibility Complete
You now have a responsibility model for understanding who operates, configures, monitors, validates, and governs each part of a cloud architecture. Next, A12.2 applies that ownership thinking to Cloud IAM Architecture.