Scenario practice questions

The cloud provider is fully responsible for patching all components.

Why wrong: This statement is incorrect in an IaaS deployment such as virtual machines. The cloud provider is responsible only for patching the physical infrastructure, including the hardware, network, storage, and the hypervisor layer that hosts your VMs. However, the customer retains full responsibility for the guest operating system and all installed applications, including applying security updates. Thus, claiming the provider patches 'all components' ignores the explicit customer duties that remain in the shared responsibility model.

The cloud provider patches the OS for all services equally.

Why wrong: This is false because patching responsibilities vary dramatically across cloud service models. In SaaS, the provider patches the entire service, including the OS, but in IaaS the provider does not patch the guest OS of your VMs—you do. Even within a single provider, different services have different shared-responsibility boundaries; for example, Azure App Service (PaaS) patches the OS for you, while Azure VMs (IaaS) do not. Thus, the provider does not patch the OS 'for all services equally'—the responsibility is model-dependent.

No patching is needed because the cloud handles everything.

Why wrong: This is a misconception that ignores the fundamental shared responsibility model. Though the cloud provider manages the physical data center and often the virtualization layer, patching is still required for any component the customer owns. In an IaaS VM, the guest OS is under the customer's control, so the provider cannot automatically patch it; leaving it unpatched can expose the workload to vulnerabilities. Therefore, the cloud does not 'handle everything'—the customer must actively patch and maintain the OS and applications within their scope.

Infrastructure as a Service (IaaS)

Why wrong: IaaS (Infrastructure as a Service) is wrong because it only supplies virtualized hardware — compute, storage, and networking — leaving the customer fully responsible for configuring, patching, and managing the OS, middleware, and any applications installed on top. In this scenario, employees need immediate, ready-to-use email, calendar, and document tools, which are end-user applications, not infrastructure components. Buying IaaS would mean the organization must purchase, deploy, and maintain its own email and office software, far exceeding the simple goal of providing access.

Platform as a Service (PaaS)

Why wrong: PaaS (Platform as a Service) is incorrect because it offers a managed cloud environment for developing, testing, and deploying custom applications, including runtimes, databases, and dev tools. It does not deliver packaged, off-the-shelf productivity applications to end users — there is no built-in email client or document editor that employees can simply open in a browser. The scenario asks for turnkey services like email and document processing, not a platform to code and host them, so PaaS is the wrong service model.

Desktop as a Service (DaaS)

Why wrong: DaaS (Desktop as a Service) is not the correct choice because it primarily delivers virtualized desktops and full Windows sessions, not individual productivity applications as standalone services. While a DaaS environment could include email and document apps, the core offering is a complete managed desktop OS, which is overkill for the stated need of providing only email, calendar, and document access. The scenario does not mention virtual desktops or a full desktop experience, so the more direct and appropriate model is SaaS.

Platform as a Service (PaaS)

Why wrong: PaaS (Platform as a Service) abstracts away both the underlying infrastructure and the operating system, offering a managed runtime environment, middleware, and development services. The customer only writes and deploys application code; they cannot install a custom OS or manage VMs because the provider automatically handles those layers. Since the scenario explicitly involves virtual machines that the company uses directly, PaaS does not fit — the VM would be entirely managed by the provider.

Software as a Service (SaaS)

Why wrong: SaaS (Software as a Service) provides a complete, ready-to-use application that is accessed over the internet, such as Microsoft 365 or Salesforce. The customer does not deploy any compute resources or virtual machines; they simply sign in and use the software, with all underlying infrastructure, OS, and applications fully operated by the vendor. This is fundamentally different from a cloud service that provides virtual machines for the company to use directly.

Desktop as a Service (DaaS)

Why wrong: DaaS (Desktop as a Service) is a specialized offering that delivers virtual Windows desktops and applications to end users through remote display protocols. Although it runs on VMs, its purpose is to replace local desktop environments — not to give customers general-purpose VMs for running custom workloads. The company uses VMs as compute resources, so DaaS, which is scoped to desktop virtualization and user profiles, does not apply.

Software as a Service (SaaS)

Why wrong: SaaS delivers a fully managed, ready-to-use software application over the internet, such as Microsoft 365. The provider owns the entire stack—data center, network, servers, operating system, and application—so the customer only logs on and configures settings. Because the company here runs a custom application and presumably controls the OS, a multi-tenant or single-tenant SaaS offering would not give it the required flexibility or administrative access.

Platform as a Service (PaaS)

Why wrong: PaaS supplies an application-hosting platform, including the underlying servers, operating system, runtime, and middleware, which the provider patches and updates. Customers deploy their application code or containers but never manage the guest OS, so they cannot perform OS-level patching, configure the OS registry, or install custom system components. The scenario described is IaaS because the customer is responsible for those OS management tasks, not PaaS.

Function as a Service (FaaS)

Why wrong: FaaS runs individual, event-driven code functions in a stateless, serverless execution environment; all host, OS, and runtime infrastructure is abstracted and auto-managed by the provider. It is billed per execution and scales every function independently, making it a poor fit for a long-running, stateful custom application that needs a specific OS environment. Since the customer here manages the OS and operates a custom application as a persistent workload, FaaS does not match.

Microsoft Identity Manager

Why wrong: Microsoft Identity Manager is an on-premises identity management product used for synchronizing and provisioning user accounts between local data sources and directories. It lacks the cloud-native event-driven workflow engine and prebuilt connectors to modern SaaS HR systems, and managing it requires significant infrastructure, so it does not replace Power Automate for automated HR event responses.

Microsoft Entra ID Connect

Why wrong: Microsoft Entra ID Connect is specifically a hybrid identity synchronization tool that connects on-premises Active Directory with Microsoft Entra ID. It only replicates directory objects such as users and groups according to synchronization rules; it has no ability to subscribe to or react to events in a third-party HR system, and therefore cannot automate business workflow actions like onboarding or deprovisioning.

Microsoft Graph API

Why wrong: Microsoft Graph API is a RESTful programmatic interface that can be used to query and change Microsoft 365 data, but building automation with it requires writing and maintaining custom code, handling authentication, pagination, and retry logic. It is an underlying technology rather than a managed workflow service, whereas Power Automate provides ready-made triggers, connectors, and designer-based logic for connecting HR systems without development effort.

Data Lifecycle Management retention policy

Why wrong: Data Lifecycle Management retention policies enforce retention and deletion rules at a large scale, such as applying a single policy to all Exchange mailboxes or all SharePoint sites. They are not designed for targeted, custodian-specific legal holds, and a policy cannot be scoped to one user's data across multiple services without a complex custom scope that would still apply the same rules to other users. Furthermore, these policies are designed to automate disposition schedules, not to freeze data for litigation.

Sensitivity label with retention marking

Why wrong: Sensitivity labels with retention markings use classification-based criteria that require each item to be labeled, either manually or via an automatic rule that scans content. It is not a blanket hold on all data belonging to a former employee because it cannot retroactively tag existing items in every location, and it does not integrate with eDiscovery cases or legal holds. A retention label preserves labeled content indefinitely, but unlabeled content remains unprotected from deletion.

Audit log search

Why wrong: Audit log search in Microsoft Purview provides a record of user and administrator activities across Microsoft 365, including who accessed an item, when, and what action was performed. It does not store the content of emails, documents, or Teams messages, nor does it prevent content from being permanently deleted. Therefore, running an audit search would help after the fact to track what may have been lost, but it cannot preserve the data itself to meet a legal preservation obligation.

Resource pooling

Why wrong: Resource pooling refers to the provider's computing resources being pooled to serve multiple customers, with physical and virtual resources dynamically assigned and reassigned according to demand. This multi-tenant model emphasizes location independence and shared infrastructure, but the scenario describes a single marketing manager accessing existing cloud services from multiple devices. It does not illustrate resource sharing or dynamic assignment, so resource pooling is not the characteristic at play.

Scalability

Why wrong: Scalability, also known as rapid elasticity, is the ability to provision and release cloud resources automatically to match fluctuating workload demand, such as scaling up compute capacity during a traffic spike and scaling back down when demand falls. The scenario contains no mention of changing demand, auto-scaling rules, or resource capacity adjustments; it simply shows a user connecting to static cloud resources from different devices. Therefore, scalability is not the characteristic being demonstrated.

Measured service

Why wrong: Measured service means the cloud provider automatically meters resource usage—such as compute hours, storage, and bandwidth—to control, optimize, and report consumption, typically for billing or pay-per-use purposes. The scenario does not mention any metering, monitoring, or cost attribution related to the marketing manager's access; it focuses solely on the variety of devices used to connect. Consequently, measured service is irrelevant to the scenario.

On-demand self-service

Why wrong: On-demand self-service lets users provision computing capabilities automatically without requiring manual provider intervention, but it applies to the initial setup and configuration of resources, such as creating a storage account or ordering compute instances. It does not address what happens after deployment, so the automatic scaling of storage capacity described in the scenario is outside the scope of this characteristic. Because the key behavior is continuous, dynamic scaling rather than initial self-provisioning, this option is incorrect.

Broad network access

Why wrong: Broad network access means cloud services are available over the network through standard protocols and can be consumed by various client devices such as laptops, phones, and workstations. A cloud storage service is certainly accessible via HTTPS endpoints, and that connectivity is a prerequisite for any use, but this characteristic explains how users reach the service, not how the service adjusts its capacity. The scenario focuses on automatic scaling of storage, which has nothing to do with network reachability, so this option is incorrect.

Resource pooling

Why wrong: Resource pooling describes the multi-tenant model in which the provider's computing resources are pooled to serve multiple customers, with physical and virtual resources dynamically assigned and reassigned according to customer demand. That explains the shared infrastructure and provider-side allocation of resources, but it does not describe a customer-visible, automated scaling behavior for a storage service. The scenario's key is the service automatically scaling its capacity, which is a different characteristic, making resource pooling the wrong choice.

Software as a Service (SaaS)

Why wrong: Software as a Service (SaaS) delivers a fully managed application, where the provider handles everything from the underlying infrastructure to the OS, middleware, and data, and the customer only configures usage. Running a web app on a virtual machine would not be SaaS because Microsoft or another vendor would not be managing your VM's OS or the app itself. You would retain responsibility for the VM at the OS and application layers, which is outside the SaaS model.

Platform as a Service (PaaS)

Why wrong: Platform as a Service (PaaS) abstracts the underlying infrastructure and provides a managed runtime for code, so you'd deploy your web app directly to a hosting service without managing a VM or its OS. In the scenario, the company runs a virtual machine, meaning they control and patch the OS and middleware, which is exactly the level of control PaaS would eliminate. With PaaS, you'd typically use something like Azure App Service, not a dedicated VM.

Function as a Service (FaaS)

Why wrong: Function as a Service (FaaS) is a serverless execution model where you upload functions that run in response to events, and the provider fully manages servers, scaling, and capacity. You never operate a VM or interact with the underlying OS; you only supply code and trigger conditions. Running a dedicated VM for a web application directly contradicts FaaS, as FaaS is designed for event-driven, stateless, short-lived workloads rather than a persistent hosted website.

Scalability and IaaS

Why wrong: Scalability alone is too general: it can describe planned vertical or horizontal expansion that does not necessarily happen automatically or rapidly. More critically, IaaS delivers raw virtual machines, storage, and networking, leaving the customer responsible for configuring, securing, and patching the guest operating system. Because the scenario specifies the provider managing the OS, IaaS contradicts that stated responsibility, so pairing scalability with IaaS cannot be correct.

Rapid elasticity and SaaS

Why wrong: Rapid elasticity is indeed a core cloud characteristic, but in SaaS the service provider owns the entire application stack and weaves scaling into the multitenant platform, which tenants cannot directly control or invoke. The operating system is completely abstracted and managed by the vendor, so there is no OS for the customer to manage or patch, unlike the division of labor implied in the question. Thus, while the wording partially describes cloud behavior, it mismatches the responsibilities described for an application-level service.

Measured service and PaaS

Why wrong: Measured service is about usage metering and pay-per-use billing, such as monitoring VM hours or storage consumption; it does nothing to automatically scale resources or transfer OS and platform maintenance to the provider. Although PaaS does provide OS and platform management, combining it with measured service fails to explain the rapid, demand-driven scaling capability mentioned in the scenario. Elasticity is the missing characteristic, making this pairing incorrect despite PaaS's correct service model.

Rapid elasticity

Why wrong: Rapid elasticity refers to the ability of a cloud system to automatically and dynamically scale resources outward or inward to match fluctuating demand, often appearing unlimited to the user. While this scaling can indirectly influence costs, it is a performance and provisioning feature, not a pricing mechanism that charges based solely on usage.

Resource pooling

Why wrong: Resource pooling is a multi-tenant model where the provider's physical and virtual resources are shared among multiple customers, with abstraction and isolation to ensure each consumer is unaware of others. This sharing affects efficiency and availability, but it does not define how individual consumption is metered or billed, so it does not explain usage-based charging.

On-demand self-service

Why wrong: On-demand self-service enables users to provision and configure computing resources automatically through a web portal or API, without requiring manual intervention from the service provider. Although it facilitates immediate access to services, this capability addresses the provisioning workflow rather than the billing methodology, so it is incorrect for a model that charges solely on consumption.

Public cloud

Why wrong: A public cloud deployment is a multi-tenant environment owned and operated by a third-party provider (e.g., Azure, AWS), where compute and storage are delivered over the internet with no on-premises infrastructure. It does not include dedicated private servers or data centers under the firm's control, so it cannot accommodate the sensitive data that the financial services firm must keep on-premises. Since the scenario clearly mixes public cloud services with on-premises resources, a purely public cloud model is incomplete and therefore incorrect.

Private cloud

Why wrong: A private cloud is a cloud environment dedicated exclusively to a single organization, often built on on-premises infrastructure or hosted in a single-tenant data center. While it provides strong control and compliance for sensitive financial data, it does not involve the use of a public cloud provider's shared, multi-tenant services. The question explicitly states the firm uses a public cloud provider, so a private-only architecture fails to account for that public component; hence it is incorrect.

Community cloud

Why wrong: A community cloud is a shared infrastructure used by several organizations that have common compliance, security, or regulatory concerns (e.g., healthcare, government), and it may be managed internally or by a third party. However, it does not represent a mix of public and private clouds for a single firm; instead, it is a multi-tenant deployment tailored to a group's shared needs. Since the question describes one financial services firm combining public cloud with its own infrastructure, a community cloud model is not an accurate fit.

Platform as a Service (PaaS)

Why wrong: PaaS is wrong for this scenario because it strips away OS-level control: the provider fully manages the operating system, runtime, and middleware, and the customer merely deploys application code into a managed hosting environment. Customers do not provision virtual machines, choose a specific OS image, patch the OS, or configure its internal settings, which contradicts the requirement that the customer controls the OS and applications. Even though PaaS is a cloud service, its fundamental abstraction of the platform makes it an incorrect fit.

Software as a Service (SaaS)

Why wrong: SaaS is wrong because it delivers a completely finished application (such as email or CRM) over the internet, with the provider managing the entire stack—servers, OS, storage, and app updates. The customer only configures business settings and manages data, without ever provisioning infrastructure or controlling the OS itself. This directly contradicts the described scenario where the customer retains control of the OS and applications, so SaaS cannot be the answer.

On-premises

Why wrong: On-premises is wrong because it is not a cloud service at all: the customer owns, installs, and maintains all physical hardware, virtualization layer, operating systems, and applications entirely within their own facilities. The scenario explicitly states a subscription to a cloud service, which implies that a third-party provider hosts and delivers resources over the internet, eliminating the need for the customer to manage physical infrastructure. Thus, on-premises in no way matches the provisional, provider-managed nature of the described environment.

Scalability

Why wrong: Scalability refers to the ability of a system to handle increased load by adding or removing resources, but this process is often manual or requires pre-planning. Unlike elasticity, scalability does not inherently involve automatic adjustments based on real-time demand, nor does it imply a pay-per-use billing model. The scenario emphasizes both automatic scaling and usage-based pricing, which are defining attributes of elasticity, making scalability an incomplete answer.

High availability

Why wrong: High availability is focused on ensuring a system remains operational and accessible to users in the event of component failures, typically through redundancy and failover mechanisms. It does not directly address the dynamic scaling of resources or the pay-as-you-go billing model described in the scenario. Since the business's requirements center on variable resource usage and corresponding billing, high availability is unrelated to the core need.

Infrastructure as a Service (IaaS)

Why wrong: Incorrect. In IaaS, the customer manages the operating system, applications, and data, while the provider manages physical infrastructure.

Platform as a Service (PaaS)

Why wrong: Incorrect. In PaaS, the customer manages the application and data, but the provider manages the runtime environment and infrastructure.

On-premises deployment

Why wrong: Incorrect. On-premises means the company manages all infrastructure and software, not the provider.

Rapid elasticity

Why wrong: Rapid elasticity is about capacity scaling, not infrastructure sharing: cloud systems can automatically provision and release compute, memory, and storage to match fluctuating demand, making resources appear unlimited to the consumer. A tenant on Microsoft 365 can add or remove licenses or storage quickly, but that dynamic scalability does not explain how multiple customers coexist on the same physical hardware. Therefore, this option describes a different NIST characteristic than resource pooling.

On-demand self-service

Why wrong: On-demand self-service lets a customer provision computing capabilities, such as virtual machines or user licenses, unilaterally through a web portal or API without requiring manual provider intervention. It removes human friction from setup and administration, but says nothing about whether the underlying physical resources are dedicated or shared across customers. Because the scenario is specifically about a provider hosting multiple customers on shared infrastructure, this characteristic is not the one being described.

Measured service

Why wrong: Measured service means the provider automatically meters and optimizes resource usage, using monitoring data to bill each customer for exactly what they consume, often pay-per-use. This characteristic underpins transparent cost allocation and can be applied within a multi-tenant environment, but metering or billing is not the same as physically sharing infrastructure among multiple customers. The question focuses on the shared-hosting aspect, not on usage measurement, so this option is incorrect.

Microsoft Planner

Why wrong: Planner manages tasks and does not describe this cloud model or benefit.

Sensitivity labels

Why wrong: Sensitivity labels classify and protect content, not this cloud concept.

Data Loss Prevention (DLP)

Why wrong: DLP protects sensitive information from inappropriate sharing, not this cloud concept.

It requires every document to be made public

Why wrong: Security and compliance controls do not require public access.

It replaces the need for identity and access management

Why wrong: Compliance controls complement identity controls rather than replacing them.

Software as a Service (SaaS)

Why wrong: Incorrect. In SaaS, the provider manages the entire application stack, including OS patching.

Platform as a Service (PaaS)

Why wrong: Incorrect. In PaaS, the provider manages the runtime environment and typically patches the OS, leaving the customer to focus on application code.

Desktop as a Service (DaaS)

Why wrong: Incorrect. DaaS delivers virtual desktop environments, not general-purpose VMs, and the provider typically manages the OS.

Microsoft Whiteboard

Why wrong: Whiteboard is for visual collaboration, not this licensing or admin requirement.

Microsoft Forms

Why wrong: Forms collects survey responses and does not meet this requirement.

Microsoft Stream

Why wrong: Stream hosts video content and does not address this licensing or support need.