Scenario practice questions

Scalability

Why it fails: Scalability adjusts compute and storage capacity to match demand; it does nothing to maintain service availability when a datacenter fails. It is tempting because scaling supports growth in users and workload, and it would be the right answer if the requirement were handling sudden traffic spikes rather than surviving a site outage.

Disaster recovery

Why it fails: Disaster recovery restores systems and data after an incident, so it addresses recovery time rather than continuous accessibility during a datacenter outage. It is tempting because it is the closest-sounding resilience term, and it would be correct if the question asked how to rebuild services following a catastrophic failure.

Elasticity

Why it fails: Elasticity scales resources dynamically with demand; it does not replicate services across datacentres or redirect traffic during an outage. It is tempting because elasticity and resilience are both cloud benefits, and it would be correct where workloads must automatically scale to meet fluctuating load rather than survive a datacentre failure.

The cloud provider is fully responsible for patching all components.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

On-demand self-service

Why it fails: On-demand self-service refers to a consumer's ability to unilaterally provision computing capabilities—such as server time, storage, or applications—through a web portal or API without requiring human interaction with the provider. It addresses how resources are requested and managed, not how or from which endpoints they are subsequently accessed. Therefore, accessing files from multiple devices says nothing about automatic provisioning, making this choice incorrect.

Resource pooling

Why it fails: Resource pooling describes the provider's computing resources being aggregated in a multi-tenant model to serve many customers, with physical and virtual resources dynamically assigned and reassigned based on demand. The customer generally has no control or knowledge of the exact underlying resource location, such as which datacenter or server holds the data. It concerns shared infrastructure efficiency, not the range of devices a user can employ to access files, so it does not explain multi-device access from a work desktop.

Rapid elasticity

Why it fails: Rapid elasticity focuses on the ability to scale computing resources outward or inward dynamically—often automatically—so capacity can match fluctuating demand, such as adding more virtual machines during a traffic spike. Although this may give the appearance of unlimited resources, it has no relationship to where or from what type of device a user accesses files. The scenario of using a work desktop and other endpoints is about connectivity and client diversity, not about resource scaling, making this option incorrect.

Microsoft 365 E5 Security

Why it fails: Microsoft 365 E5 Security is not the right choice because it is purpose-built for threat protection, not data governance. It adds capabilities like Defender for Office 365, identity and access management enhancements, and threat intelligence, which do not address retention, legal hold, or eDiscovery requirements. Selecting it would leave the compliance gap unchanged and would not satisfy the legal or regulatory obligations.

Microsoft 365 E5

Why it fails: Upgrading to full Microsoft 365 E5 would technically include the compliance features, but it is an all-in-one SKU that also bundles advanced security, analytics, and other workload capabilities the company does not need. Since the organization already holds E3 licenses, purchasing the standalone E5 Compliance add-on is far more cost-effective than paying for the entire full-E5 suite, making the full upgrade an inefficient use of budget.

Office 365 E5

Why it fails: Office 365 E5 also contains many of the same compliance tools, but it is a separate, standalone subscription rather than an add-on to Microsoft 365 E3. For a company already on Microsoft 365 E3, adding a full Office 365 E5 license would create redundancy with existing messaging and collaboration services and incur unnecessary cost. The correct path is the Microsoft 365 E5 Compliance add-on, which is designed to layer onto the existing E3 tenant and deliver the specific compliance features needed.

Microsoft Identity Manager

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Microsoft Whiteboard

Why it fails: Microsoft Whiteboard is a collaborative canvas, not a licensing or admin concept, so it does not determine which subscription covers frontline workers. It is tempting because frontline teams often need visual collaboration, and Whiteboard would be the correct choice when the requirement is shared brainstorming or planning across devices.

Microsoft Stream

Why it fails: Microsoft Stream is a video service, not a licensing construct, so it cannot specify which plan suits frontline workers' lighter needs. It is tempting because frontline staff often consume training videos, and Stream would be the correct choice when the requirement is hosting and sharing recorded content rather than choosing a licence.

Microsoft Forms

Why it fails: Microsoft Forms is a survey and quiz tool, not a licensing construct, so it cannot address which SKU covers frontline workers. It is tempting because frontline scenarios often involve data collection, and Forms would be the correct choice when the requirement is gathering shift feedback or inspection responses rather than licensing.

Rapid elasticity

Why it fails: 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 it fails: 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 it fails: 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.

Rapid elasticity

Why it fails: Rapid elasticity is the ability to scale resources automatically (often based on demand) to meet fluctuating workloads, without manual intervention or pre-provisioning. In the scenario, the administrator manually adds or removes VMs via a web portal, which is a self-service action, not automatic scaling. The key distinction is that elasticity focuses on the system's internal autonomic scaling, whereas the scenario describes explicit user-initiated provisioning on demand.

Measured service

Why it fails: Measured service refers to the cloud provider's ability to automatically monitor, meter, and report resource usage for billing and capacity planning, typically on a pay-as-you-go basis. While the scenario mentions consumption-based billing, measured service is a secondary characteristic that explains how the provider charges for the VMs; it does not describe the administrator's ability to self-provision. The primary action in the scenario is the user-initiated provisioning through the portal, not the metering mechanism. In other words, measured service is about the provider's telemetry, not the consumer's interactive control.

Resource pooling

Why it fails: Resource pooling is a multi-tenant model where the provider's physical and virtual resources (compute, storage, network) are dynamically assigned and reassigned to serve multiple customers, creating economies of scale. The scenario does not mention any details about shared infrastructure, multi-tenancy, or location independence; it only describes an administrator's actions in a web portal. Resource pooling is an underlying architectural aspect of public clouds, but it is not the characteristic being demonstrated by the administrator's ability to add or remove VMs. The focus of the scenario is the user's direct control, not the provider's resource sharing.