Describe cloud concepts practice questions

Software as a Service (SaaS)

Why wrong: SaaS delivers complete, fully managed applications such as email or CRM over the Internet; customers configure only tenant-level settings and never control the operating system, server, or network. Moving on-premises infrastructure to SaaS would require replacing existing workloads with commercial applications, demanding business-process reengineering and data migration rather than a direct infrastructure transfer. Because SaaS abstracts away the infrastructure entirely, it cannot satisfy an evaluation focused on moving existing on-premises server environments.

Platform as a Service (PaaS)

Why wrong: PaaS provides a managed hosting platform—runtime environments, databases, middleware, and development tools—so users write and deploy code without managing VMs or guest operating systems. If the company moved to PaaS, it would have to refactor applications to run on platform services and would lose administrative control over infrastructure, making it unsuited for a scenario that is about relocating existing infrastructure rather than enabling application development. The provider handles patching and scaling, but that is precisely the responsibility the evaluation's infrastructure focus requires the customer to retain.

Private Cloud

Why wrong: Private cloud is a deployment model, not a service model; a private cloud can be built on IaaS, run PaaS workloads, or deliver SaaS applications within a single-tenant, dedicated environment. Describing a move as 'private cloud' indicates exclusivity and isolation of resources but does not define whether the organization will manage VMs, use a platform, or consume applications. For an infrastructure-focused migration, private cloud is insufficiently precise because it does not specify the abstraction level of the underlying service, which is the actual decision being made.

Rapid elasticity

Why wrong: Rapid elasticity is the characteristic that allows cloud resources to scale outward and inward quickly, often automatically, in response to fluctuating demand. While this supports dynamic workload changes, it does not describe the user-initiated, unilateral provisioning of resources without provider interaction. The question specifically asks about enabling a user to automatically obtain resources on demand, which is the domain of on-demand self-service, not the system's responsiveness in scaling.

Resource pooling

Why wrong: Resource pooling describes the provider's multi-tenant model in which computing resources are aggregated to serve multiple consumers, with physical and virtual resources dynamically assigned and reassigned according to demand. This characteristic is centered on the vendor's backend efficiency and cost sharing, not on the user's ability to provision services directly. It does not involve any mechanism by which an end user can automatically acquire resources without manual intervention; that capability belongs to on-demand self-service.

Measured service

Why wrong: Measured service refers to the cloud provider's ability to meter and monitor resource usage, enabling pay-per-use billing, chargeback, and optimization through automatic control and reporting. It provides transparency into consumption for both provider and consumer, but it is fundamentally about metering and billing rather than the provisioning process. Therefore, while it is an essential cloud characteristic, it does not enable a user to automatically get resources as needed; that is the function of on-demand self-service.

Public cloud

Why wrong: Public cloud deploys workloads entirely on shared infrastructure owned by a cloud provider, with no direct private networking or identity bridge back to on-premises systems. In this scenario, moving to public cloud would require the company to either migrate the application completely or create a separate connectivity solution (e.g., VPN, ExpressRoute) that is not inherently present. The requirement to 'extend' on-premises while keeping the critical app running points to a model that preserves the existing local footprint, which public cloud alone does not deliver.

Private cloud

Why wrong: Private cloud is a model where computing resources are dedicated solely to a single organization, typically hosted on-premises or in a colocation facility, and accessed over internal networks. While it could host the critical application, it does not include any mechanism to burst into a public cloud for extra capacity or to leverage cloud-native services. Because the company wants to extend on-premises to handle peak loads, private cloud would just be a continuation of the same capacity constraints, not a hybrid extension.

Multi-cloud

Why wrong: Multi-cloud refers to using multiple distinct public cloud providers (e.g., Azure and AWS) to avoid vendor lock-in, improve resiliency, or leverage best-of-breed services, but it does not inherently connect those clouds back to an on-premises data center. The company's requirement is specifically to extend its on-premises application, not to distribute workloads across several public providers. While a multi-cloud strategy could include an on-prem component, that combination is essentially hybrid cloud; standalone multi-cloud lacks the on-premises extension described in the question.

Measured service

Why wrong: Measured service means the cloud provider meters and monitors resource consumption—compute hours, storage, network I/O—for billing and usage analysis, typically on a pay-per-use basis. Although auto-scaling will change the measured usage and therefore the bill, the metering mechanism itself neither triggers nor performs the scaling action. The scenario describes the behavior of the workload, not the telemetry/billing model that tracks its consumption.

Resource pooling

Why wrong: Resource pooling is a provider-side architectural model in which physical servers, storage, and network equipment are virtualized and shared among multiple tenants, giving the provider economies of scale. This explains why a cloud can host many e-commerce applications on the same hardware, but it does not describe how one application's capacity expands and contracts in response to demand. The pool is the source of available resources; elasticity is the mechanism that draws from the pool on demand.

On-demand self-service

Why wrong: On-demand self-service is the ability for an administrator to provision or deprovision resources—like spinning up a new VM or resizing a database—via a web portal or API without human involvement from the provider. This is a one-time request-driven action, not an automatic, policy-driven adjustment based on current load. The e-commerce application may have been initially provisioned through self-service, but the scenario's continuous scaling in response to demand is fundamentally elasticity.

Public cloud

Why wrong: Public cloud operates on multi-tenant infrastructure where compute and storage are shared across customers, and resources are metered on demand. This model cannot guarantee a fixed set of dedicated hardware for a legacy application that may require persistent licensing tied to specific CPU cores or physical isolation for compliance. Additionally, moving such an app to public cloud without dedicated hosts would not reduce on-premises costs because the organization would still need to maintain its own environment to meet those requirements.

Private cloud

Why wrong: A private cloud is a single-tenant environment dedicated to one organization, but it still requires the organization to own or lease the physical hardware, often housed in its own data center. This means capital expenditure for servers, storage, networking, and ongoing maintenance remains on the organization's balance sheet, so it does not meaningfully reduce on-premises costs. In fact, a private cloud can be more expensive than traditional virtualization because of added orchestration and management layers.

Community cloud

Why wrong: A community cloud is a shared platform used by several organizations with similar compliance or industry requirements, such as government agencies or healthcare providers. It does not provide a dedicated, fixed hardware allocation for a single organization's legacy application, nor does it combine private and public deployments. Therefore, it would not address the need for cost reduction through backup/DR in a public cloud, and it is not a suitable deployment model for this scenario.

Public cloud

Why wrong: In the public cloud, the provider owns and manages the physical data center, hypervisor, and shared multi-tenant infrastructure. You can deploy and configure applications and PaaS services, but you have no control over hardware maintenance, firmware, host-level networking, or security boundaries. Because hundreds of tenants share the same pooled resources, the control plane and underlying architecture are abstracted away, making it the least appropriate choice when the goal is maximum infrastructure control.

Hybrid cloud

Why wrong: Hybrid cloud spans at least one public and one private environment, so control is necessarily split between the organization and a public cloud provider. Workloads placed in the public portion inherit provider-controlled hardware, multi-tenant networking, and provider-defined security operations. While hybrid offers flexibility and data placement choices, the unavoidable public-cloud component reduces the overall level of control an organization holds compared to an all-private deployment.

Community cloud

Why wrong: A community cloud is a shared infrastructure used by several organizations that have common compliance or industry requirements, such as government agencies or healthcare entities. Governance, maintenance, and physical hardware are jointly managed by the community and/or a provider, so no single organization receives exclusive control. Because resources and decision-making are distributed among multiple members, it provides less control than a dedicated private cloud.

Patching the operating system of the database server

Why wrong: Patching the operating system that hosts the Azure SQL Database is entirely automated by Microsoft. The underlying Windows Server operating system receives security and maintenance updates from the Azure platform team, with no customer action or scheduled maintenance window required. In fact, the customer never gets access to the OS nor has any visibility into its patch state because SQL Database is a fully managed platform service. Thus, any expectation that the customer must patch the database server's OS is incorrect under the PaaS shared responsibility model.

Maintaining the physical infrastructure

Why wrong: Maintaining the physical infrastructure, such as rack-mounted servers, storage hardware, and network cables, is carried out by Microsoft datacenter operations staff, not by the customer. In a PaaS model, the hardware is abstracted away: you only provision and connect to a logical database, and your capacity resides in multi-tenant racks that Microsoft monitors and maintains. Because there is no customer access to the datacenter hardware, any obligation for hardware maintenance or replacement is entirely the provider's. Therefore, this is not a customer responsibility in Azure SQL Database.

Managing the virtualization layer

Why wrong: The virtualization layer, which isolates the Azure SQL Database instances and manages the underlying compute resources, is the provider's domain. Microsoft's Azure fabric controls the hypervisor, VM scheduling, and tenant isolation that run each managed database, and customers have no interaction with this layer. You connect only to the database endpoint, never to the underlying virtual machines or container hosts. Consequently, managing the virtualization layer is a Microsoft responsibility, making this option incorrect for the customer.

Infrastructure as a Service (IaaS)

Why wrong: IaaS is the wrong choice because the cloud provider only supplies the underlying virtual infrastructure—compute, storage, and network—and you remain responsible for deploying and managing the operating system, installing and configuring the database engine, and applying OS and database patches. Even if you migrate to a cloud VM, you perform all database administration tasks such as backup, recovery, and high availability. This goes beyond the scenario described, where the database itself has been moved to a cloud service that presumably manages those underlying components.

Software as a Service (SaaS)

Why wrong: SaaS is the wrong choice because it delivers a complete application (e.g., CRM, ERP, or Microsoft 365) managed entirely by the provider, and you interact only through the application interface or APIs. The customer does not directly manage the underlying database schema or run custom SQL queries against the data store; the provider handles all database operations behind the scenes. Thus, migrating an existing database—which implies maintaining some control over its structure—does not match a pure SaaS model.

On-premises

Why wrong: On-premises is the wrong choice because it means the company would own and maintain physical servers, storage, networking, software licenses, and all operational responsibilities within its own data center. Since the question explicitly states that the company migrates its database to a cloud service, an on-premises deployment would entail no cloud provider involvement and no shared operational responsibility. This option directly contradicts the described migration to cloud infrastructure.

Platform as a Service (PaaS)

Why wrong: Platform as a Service (PaaS) abstracts away the operating system, runtime engine, middleware, and scaling infrastructure, so the customer only manages their application code and data, not the underlying OS or server configuration. Because the provider controls OS-level patching, runtime versions, and platform services, the customer has significantly less control than with IaaS, making it an incorrect choice for maximum control.

Software as a Service (SaaS)

Why wrong: Software as a Service (SaaS) provides a fully managed, ready-to-use application where the provider handles everything from the underlying servers to the application version and security updates. Customer control is typically restricted to tenant-level settings, user permissions, data entry, and feature toggles, offering the least administrative control among cloud service models and therefore not the answer when maximum control is required.

Hybrid cloud

Why wrong: Hybrid cloud is a deployment model that combines a private cloud or on-premises environment with a public cloud, not a service model that defines who controls compute infrastructure. Its control level varies depending on whether IaaS, PaaS, or SaaS is used in each component, so hybrid cloud itself does not automatically grant maximum control over the deployment, making it the incorrect answer.

Public cloud

Why wrong: Public cloud services are offered by third-party providers over the internet using a multi-tenant architecture, where compute, storage, and networking are pooled and shared among many customers. Because the provider owns and operates the infrastructure, an individual organization does not have exclusive use of the underlying physical resources; isolation is logical (e.g., VMs, virtual networks) rather than physical. This directly contradicts the exclusivity requirement, making public cloud incorrect.

Hybrid cloud

Why wrong: A hybrid cloud is a composition of two or more distinct cloud infrastructures—typically a private cloud and a public cloud—that remain unique entities but are bound together by orchestration or integration to enable workload portability. Because it necessarily includes public cloud components, the overall model does not exclusively use resources dedicated to a single organization; part of the environment is on shared multi-tenant infrastructure even if other workloads remain on private resources. This fails the exclusivity condition, so hybrid is incorrect.

Community cloud

Why wrong: A community cloud is a shared infrastructure provisioned for exclusive use by a specific community of consumers from organizations that have common concerns such as compliance, jurisdiction, or security objectives. Although the infrastructure may be dedicated to that community, it is shared among multiple organizations rather than owned or used by a single organization, and governance is distributed across the member organizations. Therefore it does not satisfy the requirement of exclusive use by one organization, making it incorrect.

Infrastructure as a Service (IaaS)

Why wrong: IaaS provides virtualized computing resources such as VMs, storage, and networking, but leaves the operating system, runtime, and application stack to the customer. This means users must build, deploy, and manage their own business applications on top, rather than receiving ready-to-use business software. The provider only manages the underlying physical infrastructure.

Platform as a Service (PaaS)

Why wrong: PaaS offers a managed hosting and development environment, including application runtimes, databases, and middleware, yet it still requires code to be written or customized before a business application exists. It targets developers who need to deploy and scale custom apps, not business users looking for immediately usable tools like email or CRM. Without development effort, no ready-made business functionality is delivered.

Private cloud

Why wrong: Private cloud is a deployment architecture in which cloud infrastructure is provisioned for exclusive use by a single organization, either on-premises or hosted, rather than a classification of what capability the cloud delivers. It does not, by itself, supply ready-made business applications; an organization could run IaaS, PaaS, or SaaS on it, but the service model must still be chosen. Therefore, it cannot be the correct answer to a question asking for a service model offering ready-to-use business software.

Public cloud

Why wrong: A public cloud deployment would place all workloads, including production, on the vendor's shared infrastructure, which is not the case since production remains on-premises. The company's own physical data center is an essential part of the architecture, so labeling the entire solution as public cloud ignores that critical component and the regulatory constraints driving that design. While the public provider is used, the overall model is not exclusively public.

Private cloud

Why wrong: Private cloud is dedicated infrastructure for a single organization, typically on-premises or hosted by a third party, but in this scenario the company also consumes public cloud resources for dev/test. That active use of a public provider means the environment cannot be called a private cloud, even if production resides in a private datacenter. The mix of dedicated and shared infrastructure points to hybrid cloud instead.

Community cloud

Why wrong: Community cloud is a shared environment designed for organizations with common compliance or operational concerns, such as agencies in the same industry, and it does not inherently involve an on-premises component. Here the architecture is a single company combining its own physical infrastructure with a general public cloud provider, which does not match the multi-organizational sharing model of community cloud. The regulatory driver is specific to the company, not a shared community requirement.

Infrastructure as a Service (IaaS)

Why wrong: Infrastructure as a Service (IaaS) delivers raw compute, storage, and networking, but the customer is responsible for the operating system, runtime, web server, middleware, and all patching. To run a custom web application, the team would need to provision and continuously maintain VMs, install and update the application stack, and manage scalability and availability. This does not match the requirement of focusing on code deployment while the platform is managed, so it is incorrect.

Software as a Service (SaaS)

Why wrong: Software as a Service (SaaS) delivers a complete, ready-to-use application such as Microsoft 365 or Dynamics 365, where the vendor manages everything from the infrastructure to the application features. Customers can only configure or customize the software within pre-defined limits and cannot deploy or run their own custom code in that environment. Because the development team needs to build a new custom web application, SaaS is not the right model.

Function as a Service (FaaS)

Why wrong: Function as a Service (FaaS), such as Azure Functions, is an event-driven serverless compute model where you deploy individual, stateless functions that are executed in response to triggers. It does not offer a persistent application platform with middleware, routing, and session management that a full custom web application typically requires. While FaaS is useful for specific microservices and API endpoints, deploying a complete custom web application would require re-architecting the app into functions, so it is incorrect here.

IaaS and SaaS

Why wrong: Incorrect. SaaS would involve consuming a pre-built application (e.g., Office 365), not deploying custom code on a managed platform.

PaaS and SaaS

Why wrong: Incorrect. While serverless is PaaS, the VMs are IaaS, not SaaS. This option omits IaaS entirely.

IaaS only

Why wrong: Incorrect. VMs indeed represent IaaS, but the serverless service is PaaS, not IaaS. The scenario uses two models, not just IaaS.

Infrastructure as a Service (IaaS)

Why wrong: With IaaS, the cloud provider supplies virtualized compute, storage, and networking, but the development team remains responsible for provisioning and patching the operating system, installing and configuring the web server and database middleware, and handling high availability and scaling. For a custom web application, this means significant operational overhead beyond writing code, whereas a platform layer would abstract those components. Thus, IaaS is not the most appropriate model here.

Software as a Service (SaaS)

Why wrong: SaaS delivers a complete, ready-to-use software application, such as Microsoft 365 or Salesforce, accessed over the internet with the vendor managing everything from infrastructure to application data and updates. In this scenario, the development team needs to deploy and run their own custom web application code, not subscribe to an existing product. As such, SaaS is unsuitable because it provides no mechanism for uploading arbitrary custom code and would require any customization to be done solely through vendor-defined configuration.

Function as a Service (FaaS)

Why wrong: FaaS, such as Azure Functions, runs discrete pieces of stateless code in response to triggers like HTTP requests, queue messages, or timers, scaling each function independently. It is not designed to host a complete web application with a persistent web server, long-running sessions, or an integrated database layer, and an HTTP-triggered function would require additional services and custom code to replicate a full application stack. Because the team wants to deploy a complete custom web application, FaaS would introduce more complexity than PaaS and is therefore incorrect.

The cloud provider

Why wrong: In the IaaS shared responsibility model, the cloud provider is accountable only for the physical data center, network infrastructure, and the hypervisor that isolates virtual machines. The provider does not log into your guest OS or patch the applications you deploy, so any compromise of the OS or application layer is not the provider's fault. Thus, saying 'the cloud provider' is incorrect because it incorrectly assigns guest-OS security duties to a party that lacks the access and contractual obligation to manage them.

Both the provider and the customer share equally

Why wrong: This option is wrong because responsibility in IaaS is not an even 50/50 split; it is a layered division based on control. The provider secures the physical hosts, storage, and network fabric, while the customer secures everything it creates or installs in the guest VM, such as the OS, applications, and data. A true 'equal share' implies identical duties, but the actual boundary is clear: the provider manages the stack up to the hypervisor, and the customer manages from the guest OS upward.

A third-party managed security service provider

Why wrong: While a customer could hire a third-party managed security service provider (MSSP) to perform patching and monitoring, that engagement does not change the default responsibility contractually held by the customer. The cloud provider still looks only to the customer as the account owner; any MSSP acts as an agent of the customer, and the customer remains accountable for compliance, security outcomes, and any breaches. Therefore, the MSSP is not an inherent party in the IaaS shared responsibility model and is wrong as the direct answer.

Sensitivity labels

Why wrong: Sensitivity labels are Microsoft 365 compliance features that apply classification and encryption to documents and emails, controlling who can access and use content. They enforce governance and data protection policies but have no bearing on how compute resources are procured or paid for. Labeling content does not shift infrastructure costs from capital purchases to operational spending, so it does not help users avoid buying servers.

Data Loss Prevention (DLP)

Why wrong: Data Loss Prevention (DLP) monitors content across Exchange, SharePoint, OneDrive, and endpoints to detect and block accidental sharing of sensitive data such as Social Security numbers or credit card details. It implements security and compliance rules, but it neither provides compute capacity nor changes the financial model of IT procurement. DLP is irrelevant to the operational spending model that lets organizations lease cloud services instead of purchasing servers.

Microsoft Planner

Why wrong: Microsoft Planner is a teamwork tool for organizing projects with boards, buckets, and assignments within Microsoft 365. It helps users manage work and deadlines but has nothing to do with cost management, infrastructure procurement, or the financial arrangements for cloud services. Selecting Planner as the reason for avoiding server purchases confuses a productivity feature with a business model.

Private cloud

Why wrong: Private cloud is a deployment model.

Infrastructure as a Service (IaaS)

Why wrong: IaaS still requires OS and runtime management.

Software as a Service (SaaS)

Why wrong: SaaS delivers a finished application, not a custom app platform.

Platform as a Service (PaaS)

Why wrong: Platform as a Service (PaaS) is a cloud service model that provides a managed development and deployment environment—including runtime, middleware, and tools—for building custom applications. Microsoft 365, however, is not a platform for writing code; it ships finished products like Exchange Online, SharePoint, and Teams. A stakeholder who wants to simply use these services has no need for PaaS, which would require them to develop and manage their own application code on top of a platform.

Community cloud

Why wrong: Community cloud is a deployment model where the cloud infrastructure is shared by several organizations from a specific community with common compliance or security needs. It does not describe how Microsoft 365 delivers its applications; Microsoft 365 is a public SaaS offering with strict multi-tenant isolation rather than a community-based deployment. Thus, it cannot be the correct classification for a stakeholder wanting to use Microsoft 365's business productivity tools.

Infrastructure as a Service (IaaS)

Why wrong: Infrastructure as a Service (IaaS) offers virtualized computing resources like virtual machines, storage, and networking, and the customer must configure, harden, and maintain the operating system and applications. Microsoft 365 does not expose virtual infrastructure; instead, Microsoft manages the entire stack of its productivity applications. Selecting IaaS would create an unrealistic expectation of administrative control and server-level responsibility that is not part of a Microsoft 365 adoption.

Microsoft Planner

Why wrong: Microsoft Planner is a lightweight task management application within the Microsoft 365 suite, used for creating plans, assigning tasks, and tracking progress on shared projects. It does not represent a cloud characteristic or adoption benefit; rather, it is a SaaS tool that helps organize work. Confusing it with rapid elasticity would conflate a specific productivity service with the underlying cloud architecture's scaling capabilities.

Data Loss Prevention (DLP)

Why wrong: Data Loss Prevention (DLP) is a security and compliance feature in Microsoft 365 that detects and safeguards sensitive information such as credit card numbers or personally identifiable information across Exchange, SharePoint, OneDrive, and Teams. It applies policies to prevent unauthorized sharing or leakage, but it does not describe how cloud resources dynamically adjust to demand. Thus it is a control mechanism, not a cloud model benefit.

Sensitivity labels

Why wrong: Sensitivity labels are classification markers that can be applied to documents and emails to enforce encryption, watermarking, and access restrictions based on the organization's information protection policies. Their purpose is to govern content visibility and handling, not to describe the ability of Microsoft 365 infrastructure to provision or release resources on demand. Therefore they do not answer the question about a cloud characteristic or benefit.