Cyber Security Quiz: Shared Responsibility Model
10 questions · exam conditions
0:00
Shared Responsibility ModelQuestion 1 of 10

A cloud provider supplies audit reports showing that its data centers and platform controls meet several security standards. A customer plans to tell regulators that these reports prove the customer's entire cloud-hosted business process is compliant, without assessing account configurations, user access, data retention, or application controls.

What is the most significant flaw in the customer's plan?

Provider reports apply only to physical security and cannot provide evidence for any technical or operational controls.
Regulatory compliance cannot use third-party reports and always requires regulators to inspect the provider directly.
The customer must independently operate every provider control before it may rely on the provider's audit reports.
Provider reports support inherited controls, but the customer must still assess controls remaining within its responsibility.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Shared Responsibility Model

Practice Shared Responsibility Model in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Shared Responsibility Model, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A cloud provider supplies audit reports showing that its data centers and platform controls meet several security standards. A customer plans to tell regulators that these reports prove the customer's entire cloud-hosted business process is compliant, without assessing account configurations, user access, data retention, or application controls.

What is the most significant flaw in the customer's plan?

  1. Provider reports apply only to physical security and cannot provide evidence for any technical or operational controls.
  2. Regulatory compliance cannot use third-party reports and always requires regulators to inspect the provider directly.
  3. The customer must independently operate every provider control before it may rely on the provider's audit reports.
  4. Provider reports support inherited controls, but the customer must still assess controls remaining within its responsibility. (correct answer)
Explanation: When you see a question about cloud compliance, immediately think about the shared responsibility model — the foundational principle that cloud providers and customers each own distinct portions of the overall control environment. Audit reports from a provider certify that their controls work correctly, but they say nothing about how the customer has configured or managed what falls on the customer's side. This is exactly why D is correct. Provider audit reports are genuinely useful — they let customers "inherit" credit for controls the provider operates (physical facilities, hypervisor security, platform-level encryption, etc.). But controls like account configurations, user access management, data retention policies, and application logic belong to the customer's responsibility layer. The customer in this scenario skipped assessing those entirely, which means their compliance posture has unexamined gaps regardless of what the provider's reports say. A is wrong because provider reports absolutely do cover technical and operational controls — not just physical security. Standards like SOC 2 and ISO 27001 address access controls, change management, incident response, and more. B is wrong because regulators routinely accept third-party audit reports (SOC 2 Type II, FedRAMP packages, etc.) as valid compliance evidence — direct inspection of every provider is not a requirement. C is wrong because the entire point of inherited controls is that the customer doesn't have to independently operate them; the provider operates them, and the audit report documents that. Study tip: On exam questions involving cloud compliance, always ask yourself: "Who owns this control — provider or customer?" If the question describes a customer ignoring their own side of the shared responsibility model, that's the flaw.

Question 2

A cloud provider detects malicious activity on a physical host and isolates it according to its incident response procedures. During the investigation, the customer discovers that an attacker also used a stolen customer API key to modify resources in the customer's account. The customer assumes the provider will perform all containment and recovery because the incident began in provider infrastructure.

What is the most appropriate interpretation of the parties' incident response duties?

  1. The provider owns the complete response because the first detected activity occurred on a provider-controlled physical host.
  2. The customer owns the complete response because activity involving its API key supersedes the provider's infrastructure duties.
  3. Each party responds within its control boundary and coordinates evidence, notifications, containment, and recovery as needed. (correct answer)
  4. Neither party should act on the other's findings until investigators determine which event occurred chronologically first.
Explanation: When you see a cloud security incident question involving both provider infrastructure and customer accounts, think immediately about the shared responsibility model. This framework defines who owns what based on control boundaries — the provider controls physical infrastructure, networking, and hypervisors, while the customer controls their accounts, credentials, and application-layer resources. Incidents rarely respect those boundaries neatly, which is exactly the trap this question sets. The correct answer is C because the incident has two distinct threads: malicious activity on provider-controlled hardware, and unauthorized use of a customer-owned API key to modify customer resources. The provider has both the authority and the forensic access to respond to its infrastructure; the customer has the authority and visibility to rotate the compromised API key, audit resource changes, and recover their account. Neither party can fully act within the other's domain — so coordination, shared evidence, and parallel containment are the only realistic path forward. A is wrong because where an incident begins does not transfer ownership of the entire response. The provider simply cannot revoke a customer's API key or restore customer-managed resources on their behalf without consent or contractual authority. B falls into the opposite trap — the API key misuse doesn't erase the provider's responsibility for its own physical host compromise. Blaming the customer for "starting it" with a stolen credential ignores what actually happened on provider infrastructure. D is dangerous advice in practice; waiting for chronological attribution before acting allows ongoing damage to both environments. Your study tip: on exam questions involving cloud incidents, ask yourself "who controls that layer?" — the answer almost always determines who owns that piece of the response.

Question 3

An organization replaces a customer-managed email server running on an infrastructure-as-a-service virtual machine with a software-as-a-service email platform. The SaaS provider operates the application, operating system, and supporting infrastructure. The organization continues to create user accounts, assign administrator roles, set retention policies, and classify email data.

How does this migration most likely change the responsibility boundary?

  1. Operating-system and application maintenance shift to the provider, while identity and data-governance duties remain with the organization. (correct answer)
  2. All security duties shift to the provider because the organization no longer administers the email server directly.
  3. Only physical security shifts to the provider, while the organization retains application patching and platform maintenance.
  4. Identity management shifts to the provider, while the organization becomes responsible for the SaaS application code.
Explanation: When you see a question about cloud migrations, immediately think about the shared responsibility model — the framework that defines which security duties belong to the cloud provider and which stay with the customer. The split depends on the service model: IaaS, PaaS, or SaaS. In SaaS, the provider owns the most, but the customer never escapes responsibility for identity and data. In this scenario, the organization moves from IaaS (where they managed the OS, application, and everything above the hypervisor) to SaaS (where the provider handles infrastructure, OS, and the application itself). That shift means OS patching, application updates, and platform maintenance all move to the provider's side of the line. However, the organization still creates accounts, assigns roles, sets retention policies, and classifies data — these are identity management and data governance tasks that always remain with the customer in any cloud model. Answer A captures this boundary precisely and is correct. Answer B is a classic trap: "we don't touch the server anymore, so the provider handles everything." Cloud providers never accept responsibility for your user accounts, access controls, or how you classify and govern your own data — those depend entirely on your organizational decisions. Answer C describes the IaaS model, not SaaS. In IaaS, only physical infrastructure shifts to the provider while you still patch the OS and manage the application. That's exactly the arrangement the organization left behind. Answer D reverses reality entirely. In SaaS, the provider owns the application code, not the customer, and identity management stays firmly with the organization. A reliable study tip: memorize the shared responsibility model as a layered stack — the higher up the stack your service model sits, the more layers the provider absorbs, but identity and data governance never leave you.

Question 4

A company hires a managed service provider to configure its cloud accounts, monitor alerts, and rotate access keys. The cloud contract remains between the company and the cloud provider. The managed service provider fails to rotate a compromised key, leading to unauthorized resource creation. Company executives argue that outsourcing the task removed the company's responsibility under the cloud shared responsibility model.

Which statement is most accurate?

  1. The cloud provider becomes responsible because it allowed the managed service provider to use the compromised customer key.
  2. The company retains accountability for its customer-side duties even when operational performance is delegated by contract. (correct answer)
  3. The managed service provider replaces the company as the cloud customer whenever it receives administrative account access.
  4. Responsibility automatically becomes equal among all three parties when a third party administers customer cloud resources.
Explanation: Whenever you see a question involving outsourced cloud operations, anchor your thinking in the cloud shared responsibility model: the cloud provider covers the infrastructure it controls, while the customer is accountable for everything on their side — identity management, access keys, configurations, and data. Critically, accountability does not transfer just because a company hires someone else to perform those duties. In this scenario, the company signed the cloud contract, owns the cloud account, and retains customer-side responsibilities. When it hired the managed service provider (MSP), it delegated operational tasks, not accountability. The MSP failed to rotate the compromised key, which is an operational error — but the company remains accountable to the cloud provider for ensuring that its customer-side obligations are met. That's exactly what B captures: delegating performance by contract does not strip the company of its accountability for its own duties. A is wrong because the cloud provider has no obligation to police how customers manage their own keys — key lifecycle management is explicitly a customer-side responsibility. The provider isn't culpable for the customer's key hygiene failures. C is wrong because administrative access granted to an MSP does not make that MSP the cloud customer. The legal contract and account ownership stay with the company; the MSP acts as an agent, not a replacement party. D is wrong because responsibility never automatically equalizes among parties. The model assigns specific duties to specific parties; adding a third-party administrator doesn't redistribute those defined roles equally. Study tip: On security exams, watch for scenarios where delegation is used to argue away responsibility — this is almost always a trap. Accountability follows contract ownership, not task performance.

Question 5

A storage service automatically encrypts all objects on provider media. A customer uploads confidential files, then configures the storage container so that unauthenticated internet users can read them. The customer argues that the provider's encryption guarantee means the files were adequately protected.

Which response best applies the shared responsibility model?

  1. Encryption satisfies the provider's media-protection duty, but the customer remains responsible for logical access configuration. (correct answer)
  2. Encryption transfers access-control responsibility to the provider because the provider possesses the encryption infrastructure.
  3. The provider's encryption obligation and the customer's access configuration are the same control, so fulfilling one satisfies both.
  4. The customer bears responsibility for access configuration only if it chose to manage its own encryption keys rather than use provider-managed keys.
Explanation: Whenever you see a question about cloud security responsibilities, anchor your thinking to the shared responsibility model: the provider secures the infrastructure, while the customer secures what they do with it. These are distinct, non-overlapping duties — and the exam loves to test whether you can keep them separate. In this scenario, the provider encrypts data at rest on its physical media. That satisfies the provider's obligation to ensure that a stolen hard drive, for example, doesn't expose plaintext data. However, the customer then deliberately opened the storage container to unauthenticated public access. Encryption protects data from physical media theft — it does nothing to stop an authorized HTTP request from a browser. The customer configured logical access, so the customer owns that failure. Answer A correctly identifies both halves: the provider met its media-protection duty, and the customer still bears responsibility for access control. Answer B is wrong because owning the encryption infrastructure does not transfer access-control responsibility to the provider. Infrastructure ownership and access policy ownership are separate concerns under the shared responsibility model. Answer C contains a fundamental logical error — two different controls (encryption and access configuration) address two different threats; satisfying one cannot satisfy the other by definition. Answer D introduces a false condition: the customer's responsibility for access configuration exists regardless of whether it uses provider-managed or self-managed encryption keys. Key management decisions don't reassign access-control obligations. A useful study tip: on exam questions involving shared responsibility, ask yourself "what layer does this control protect?" Physical media protection and logical access configuration operate at different layers — conflating them is the trap the distractors are designed to set.

Question 6

A development team deploys a function to a serverless computing service. The provider maintains the physical infrastructure, operating system, and managed language runtime. The team's deployment package includes a vulnerable third-party library, which an attacker exploits through crafted input sent to the function.

Which conclusion most accurately assigns responsibility?

  1. The provider is responsible because serverless computing removes customer responsibility for everything below the business workflow.
  2. The third-party library author is responsible because customers cannot reasonably inspect externally maintained software components.
  3. The provider and customer are equally responsible because the provider runtime executed the customer's vulnerable library.
  4. The customer is responsible for its code, dependencies, and input handling, while the provider secures the managed runtime. (correct answer)
Explanation: Whenever you see a serverless or cloud security question, anchor your thinking to the shared responsibility model — the framework that divides security duties between cloud provider and customer based on what each party controls. In serverless computing, the provider manages physical hardware, the hypervisor, the OS, and the managed runtime. The customer controls everything they deploy into that environment: application code, third-party libraries, and input validation logic. In this scenario, the attacker exploited a vulnerable library the team included in their own deployment package. That library sits squarely in the customer's zone of ownership. No matter how well the provider secures the runtime, it cannot patch a library it never managed. D is correct because it maps responsibility accurately to each party's actual control surface. A overstates what "serverless" means. Serverless removes infrastructure management, not all security responsibility. Customers still own their code and dependencies — the word "serverless" refers to server provisioning, not server accountability. B is a dangerous misconception. Third-party authors may introduce vulnerabilities, but the customer who selects, packages, and deploys a library accepts responsibility for vetting and updating it. Blaming the author doesn't relieve the deploying team of their duty to perform dependency scanning. C sounds balanced but is logically flawed. The provider executing your code doesn't make them co-responsible for vulnerabilities you introduced. Shared responsibility is divided by control domain, not by execution involvement. When you see cloud security scenarios on the exam, ask yourself: Who controlled the thing that failed? That question almost always points you to the correct responsibility assignment.

Question 7

A managed relational database service automatically patches the database engine and underlying hosts. A customer enables a public endpoint and configures a network rule permitting connections from any internet address. Credentials are later obtained through phishing, and the database is accessed remotely.

Which allocation of responsibilities is most accurate?

  1. The provider manages engine and host patching, while the customer manages network exposure, credentials, and data access. (correct answer)
  2. The provider manages all database security, while the customer is responsible only for the accuracy of stored data.
  3. The customer manages engine patching and network exposure, while the provider manages database users and credentials.
  4. The parties are jointly responsible for every control because the database combines provider and customer resources.
Explanation: Whenever you see a cloud security question involving a managed service, your first instinct should be to apply the shared responsibility model: providers secure the underlying infrastructure and platform, while customers remain accountable for everything they configure on top of it. In this scenario, the managed database service automatically handles engine patching and host maintenance — that's the provider's lane. But the customer deliberately enabled a public endpoint and created a permissive network rule allowing connections from any internet address. When phishing led to stolen credentials and unauthorized access, that breach traced directly back to customer-controlled decisions: network exposure settings, credential hygiene, and access controls. Answer A correctly maps this split — the provider owns patching, the customer owns network configuration, credentials, and data access governance. B is wrong because it dramatically overstates provider responsibility. No cloud provider takes ownership of "all database security." Customers always retain control — and therefore accountability — over how they expose and protect their data. C flips the responsibilities incorrectly. Engine patching is explicitly a managed-service function the provider handles automatically (the passage even states this). Assigning it to the customer contradicts both the scenario and how managed services actually work. D sounds nuanced but is a trap. "Jointly responsible for every control" implies the provider shares blame for the customer's decision to open the database to the entire internet — which is not how shared responsibility works. Controls are divided, not merged. For the exam, remember this pattern: managed = provider patches the platform; customer = configures exposure, access, and credentials. When a breach follows a customer misconfiguration, the customer owns it.

Question 8

A company uses a software-as-a-service collaboration platform. The provider maintains the application code, operating systems, and infrastructure. Tenant administrators can enforce multifactor authentication, review privileged accounts, and disable inactive users. An attacker signs in through a dormant tenant administrator account for which the company had not enabled multifactor authentication.

Which assessment best identifies the relevant responsibility?

  1. The provider failed because it is responsible for all security controls implemented within a software-as-a-service platform.
  2. The provider and customer share the task only if the attacker also exploited a vulnerability in the application code.
  3. The customer failed to manage tenant identities and available authentication settings within its administrative control. (correct answer)
  4. Neither party failed because a valid account was used rather than a technical vulnerability being exploited.
Explanation: When you see a cloud security scenario on a cybersecurity exam, your first instinct should be to apply the shared responsibility model. In SaaS environments, the provider owns the infrastructure, operating systems, and application code — but the customer retains responsibility for identity management, access controls, and configuration of security features within the tenant they administer. The scenario makes this division explicit: the company could enforce MFA, review privileged accounts, and disable inactive users — they simply chose not to act on a dormant administrator account. The attacker gained access precisely because the customer neglected these available controls. C is correct because the failure belongs to the customer, who had both the authority and the tools to prevent this breach. A is wrong because it overclaims the provider's responsibility. In SaaS, the provider does not manage who has accounts, which accounts are active, or whether MFA is enforced for tenant administrators — those are customer-side functions by design. B introduces a false condition: shared responsibility in SaaS isn't contingent on application-layer vulnerabilities being exploited; the model is defined by who controls what, not by attack type. D is a tempting trap — it implies that using valid credentials means no failure occurred. However, security failures aren't limited to technical exploits. Leaving a dormant, MFA-exempt admin account active is a process and configuration failure, regardless of how the attacker authenticated. Your study tip: on shared responsibility questions, always map each security control to the party who has administrative control over it. That ownership determines accountability, not the severity or method of the attack.

Question 9

A company deploys containers to a managed Kubernetes service. Under the service terms, the provider patches the hosted control plane and provider-managed worker-node operating systems. The company builds its own container images, defines workload service accounts, and configures role-based access control. A vulnerable package in a company-built image is exploited by a service account that has excessive cluster permissions.

Which statement best explains responsibility for the compromise?

  1. The provider is responsible because it operates both the Kubernetes control plane and the worker-node operating systems.
  2. The company is responsible for the image dependency and workload permissions, despite provider management of platform components. (correct answer)
  3. The package maintainer is solely responsible because the initial vulnerability existed in an open-source dependency.
  4. Responsibility depends only on whether the vulnerable container was running on a provider-managed worker node.
Explanation: When you see a cloud security question involving managed services, your first instinct should be to map each element of the incident to a shared responsibility model — the framework that divides security obligations between a cloud/managed-service provider and the customer. In a managed Kubernetes environment, the provider typically owns the security of the platform itself: the control plane, underlying infrastructure, and managed node operating systems. The customer owns everything they bring to that platform — their application code, container images, and access control configurations. In this scenario, the vulnerability lived inside a company-built image (a customer artifact), and the blast radius expanded because the company configured a service account with excessive cluster permissions (a customer RBAC decision). Both the vulnerable dependency and the overprivileged account fall squarely within the company's responsibility boundary. Answer B correctly captures this: the company bears responsibility for the image dependency and workload permissions regardless of what the provider manages. Answer A is wrong because it conflates platform ownership with responsibility for the exploit. The provider patching worker-node OSes doesn't extend provider responsibility to application-layer packages inside customer-built images. Answer C is a classic misdirection — while the open-source maintainer introduced the flaw, the company chose to include that dependency and failed to patch or monitor it, making the company operationally responsible for its own deployments. Answer D is a red herring; responsibility isn't determined by which physical node the container ran on, but by who controlled the compromised component. For exam purposes, remember: "You own what you build and configure." In any shared responsibility question, trace each failure back to who had control over that specific layer.

Question 10

An organization runs a customer-facing application on virtual machines provided through an infrastructure-as-a-service offering. The cloud provider contract states that the provider secures the physical facilities, storage hardware, network fabric, and hypervisor. An attacker exploits an operating-system vulnerability on one virtual machine. The patch had been available for two months but was never installed by the organization.

Which conclusion most accurately applies the shared responsibility model to this incident?

  1. The provider is responsible because any vulnerability affecting a cloud-hosted workload falls within infrastructure security.
  2. The organization is responsible because patching the guest operating system remains its duty under this service model. (correct answer)
  3. Both parties are equally responsible because the provider hosts the virtual machine while the organization uses it.
  4. The operating-system vendor is responsible because it originally introduced the vulnerability into its software.
Explanation: Whenever you see a cloud security scenario on the exam, your first instinct should be to map responsibilities using the shared responsibility model. In IaaS specifically, the cloud provider owns everything below the operating system — physical hardware, networking, storage, and the hypervisor — while the customer owns everything at and above the OS layer, including the guest operating system, applications, and data. That division is exactly what makes B correct. The patch had been available for two months, and the organization never applied it. Since guest OS patching sits firmly on the customer's side of the responsibility line in an IaaS model, the organization failed its own duty. The provider fulfilled its contractual obligations by securing the infrastructure beneath the VM. A is wrong because it dramatically overstates the provider's scope. The provider's infrastructure responsibility stops at the hypervisor; it has no visibility into or control over what runs inside the customer's virtual machine. Blaming the provider for an unpatched guest OS misreads the entire IaaS model. C is tempting because both parties are involved with the VM, but "equal responsibility" is not how the model works. Responsibility is divided by layer, not split evenly. The organization's failure to patch is the direct, proximate cause of the breach — the provider did nothing wrong here. D introduces a logical distraction. While the OS vendor originally wrote the vulnerable code, it also released the patch. Once a patch is available, responsibility for applying it shifts entirely to the organization running the software. Study tip: Memorize the IaaS/PaaS/SaaS responsibility stack. As you move up the service model, the provider takes on more layers — but in IaaS, the guest OS is always the customer's problem.