Describe cloud concepts practice questions

A) Scalability

Why wrong: Scalability is incorrect because it describes the capability of a system to handle increasing workloads by adding resources (scale out/up) or reducing resources as demand decreases, which is about performance under load rather than about maintaining availability during a catastrophic regional outage. Scalability does not inherently include redundancy, failover, or geo-replication; a scalable system might still be a single point of failure if all its resources reside in one datacenter or one region. Even if a system can scale to meet heavy traffic, it cannot automatically recover or redirect users to another region when the primary region is destroyed. Thus, scalability addresses growth and workload demands, not the disaster recovery scenario posed in the question.

B) Elasticity

Why wrong: Elasticity is incorrect because it refers to the ability of a cloud system to dynamically add or remove compute, storage, or networking resources automatically in response to changes in demand, such as scaling out virtual machines during a traffic spike and scaling them back in afterward. It focuses on handling variable load rather than on failure recovery or continuity of operations during a disaster. While an elastic system may also be part of a resilient architecture, elasticity itself does not provide the data replication or geographic failover mechanisms needed to maintain availability when an entire Azure region goes down. Therefore, elasticity does not satisfy the requirement of 'available even if a [regional] failure' as implied by the scenario.

D) Disaster recovery

Why wrong: Disaster recovery (DR) is the correct answer because it is explicitly designed to restore IT systems and data after a catastrophic, region-wide failure that takes down an entire Azure datacenter or even an Azure region. In Azure, DR commonly involves replicating workloads, databases, and storage to a paired or secondary region using services like Azure Site Recovery or Azure SQL Database geo-replication, so that failover can occur when the primary region becomes unavailable. Unlike high availability, which typically tolerates component or datacenter-level faults, DR addresses the full regional outage scenario described in the question by enabling recovery in a geographically separate location. This aligns with the broader business continuity and disaster recovery (BCDR) strategy where the recovery point objective (RPO) and recovery time objective (RTO) are met through regional replication.

Measured service

Why wrong: Measured service refers to the capability of the cloud provider to meter and bill for resource usage. While Azure does measure resource consumption, this scenario describes resource isolation and guaranteed performance, not metering or billing.

Rapid elasticity

Why wrong: Rapid elasticity is a cloud characteristic that describes the ability to provision and release resources dynamically in response to workload fluctuations — for example, scaling out VM instances during a traffic spike and scaling back down afterward. In this scenario, the VMs are simply running on shared physical infrastructure, and there is no mention of changing the number or size of resources over time. Therefore, while Azure does support rapid elasticity, it is not the mechanism that ensures each VM's resources remain separate and consistent.

On-demand self-service

Why wrong: On-demand self-service refers to a user's ability to provision cloud services, such as creating or resizing VMs, through a web portal or API without requiring manual intervention from the cloud provider's staff. The scenario does not describe any provisioning action or self-service interaction; it describes the operational state of already-running VMs and the performance isolation they receive from the underlying hypervisor. Thus, self-service is unrelated to the physical resource separation that guarantees each VM's own resources, making it an incorrect choice.

Public cloud

Why wrong: A public cloud deployment runs on shared, multi-tenant infrastructure operated by a third-party provider off the customer's physical site. Adopting this model would require moving all workloads — including sensitive customer data — to the provider's data centers, which directly violates the regulatory mandate that prohibits storing or processing such data outside the company's premises. Public cloud also offers no dedicated on-premises component, so it cannot satisfy the data-residency constraint while enabling separate compute-intensive workloads in the cloud.

Private cloud

Why wrong: A private cloud model keeps everything on-premises, which satisfies the data residency requirement but does not allow the company to take advantage of cloud computing for its compute-intensive workloads. The goal is to use public cloud for some workloads, so private cloud alone is insufficient.

Community cloud

Why wrong: A community cloud is designed for multiple organizations with shared concerns (e.g., compliance, security) and is not specific to a single organization's regulatory data residency needs. It does not inherently allow for keeping data on-premises while using public cloud for other workloads.

Elasticity

Why wrong: Elasticity is the cloud's ability to automatically scale resources up or down in response to fluctuating demand, such as adding virtual machines during a traffic spike and removing them afterward. It is an operational and performance characteristic that helps avoid paying for idle capacity, but it does not represent the fundamental financial shift from capital expenditure (CapEx) to operating expenditure (OpEx). The question asks about the pricing model itself, not how resource utilization is optimized.

High availability

Why wrong: High availability is the design principle that keeps applications running despite component or infrastructure failures by using redundancy, failover, and load balancing across multiple availability zones or regions. It focuses on minimizing downtime and maximizing uptime, which is a resilience property rather than a financial accounting model. The decision to adopt a consumption-based pricing model is unrelated to whether resources are deployed redundantly, so this option cannot be the correct reason for the cloud's CapEx-to-OpEx shift.

Predictable performance

Why wrong: Predictable performance refers to a cloud provider's ability to deliver consistent throughput and latency for workloads, typically guaranteed through service-level agreements (SLAs) that specify uptime and response metrics. This technical guarantee is about reliability and performance consistency, not about the payment structure. While SLAs may include financial credits for breaches, that is compensation for service failure, not the core consumption-based pricing model described in the correct answer.

Spot VMs

Why wrong: Spot VMs offer deep discounts but can be evicted at any time, making them unsuitable for workloads that cannot be interrupted.

Reserved Instances (1 or 3-year)

Why wrong: Reserved Instances provide significant discounts for always-on usage. For a VM running only 4 hours nightly, the cost per hour is effectively higher than Pay-as-you-go because you pay for idle capacity.

Dedicated Hosts

Why wrong: Dedicated Hosts are expensive and designed for regulatory or licensing requirements, not for cost optimization on intermittent workloads.

High availability

Why wrong: High availability is about keeping a service reachable and operational despite failures, typically by distributing workloads across availability zones or regions to achieve high uptime SLAs. Although an HA architecture may include multiple instances behind a load balancer, those instances are usually a fixed count unless a separate scaling policy exists. Thus, HA alone does not automatically adjust capacity to handle unexpected traffic changes.

Disaster recovery

Why wrong: Disaster recovery is a business continuity strategy for recovering an entire application or data center after catastrophic events such as regional outages, using tools like Azure Site Recovery or geo-replicated storage. Its key metrics are recovery point objective and recovery time objective, which measure acceptable data loss and recovery time, not the dynamic resource scaling needed for variable web traffic. Disaster recovery is a reactive process triggered by a disaster, not a proactive scaling response to demand changes.

Fault tolerance

Why wrong: Fault tolerance goes beyond high availability by enabling a system to continue functioning with zero interruption when a specific component, disk, or server fails, often through active-active redundant hardware. It focuses on masking failures and preserving session continuity, not on reading traffic metrics or provisioning extra capacity. A fault-tolerant deployment can still struggle with a sudden load spike because scaling and fault masking are independent concerns.

Scalability

Why wrong: Scalability is the ability of a system to handle increased load by adding resources, either vertically (increasing CPU/RAM of a single instance) or horizontally (adding more instances), often based on both demand and threshold rules. While scaling out can increase capacity and potentially create multiple copies of a workload, it does not by itself guarantee continuous operation if one component fails. For instance, if all instances depend on a single un-replicated database or storage account, a failure in that component will still cause downtime despite scalability.

Elasticity

Why wrong: Elasticity is the capability of a cloud system to automatically add or remove compute, storage, or network resources in response to real-time changes in demand, such as a sudden spike in web traffic. This is a capacity-management mechanism, often implemented via Azure Autoscale, and it does not inherently provide fault tolerance. An elastic workload can still experience downtime if a single virtual machine or service fails because elasticity alone does not include failover or redundancy mechanisms.

Disaster recovery

Why wrong: Disaster recovery is a strategy for restoring an entire workload or data center after a catastrophic event, such as a regional outage, cyberattack, or natural disaster, using backups and replication to a secondary location. It is measured by recovery time objective (RTO) and recovery point objective (RPO), which typically allow for minutes to hours of downtime. Unlike HA, DR does not prevent interruption during a component failure; it only recovers operations after the fact, making it unsuitable for the scenario that demands minimal downtime during a localized fault.

Encrypting customer data at rest

Why wrong: Encrypting customer data at rest is the customer's responsibility to configure and manage, even though Azure provides encryption by default at the storage platform level. The customer must enable and control encryption options such as Azure Disk Encryption, customer-managed keys in Azure Key Vault, or adjust storage service encryption settings. Microsoft may offer platform-managed keys, but the customer is responsible for choosing, configuring, and managing the encryption approach and key lifecycle for their data.

Patching virtual machines

Why wrong: Patching virtual machines is the customer's responsibility in an IaaS deployment because the customer maintains the guest operating system and applications running inside the VM. Microsoft patches the physical host and hypervisor, but the customer must apply OS and application updates to the VM itself, unless they implement Azure Automation Update Management or similar. Therefore, patching VMs is not a provider-managed security control.

Managing customer access policies

Why wrong: Managing customer access policies is the customer's responsibility because they own their identity and access management. The customer uses Azure AD and RBAC to define who can sign in, which roles they hold, and what resources they can access. Microsoft provides the identity platform but does not decide or enforce the customer's specific access rules, so this is a customer-side control.

Broad network access

Why wrong: Broad network access describes the ability to reach cloud services over standard network connections from diverse client platforms. It is a connectivity enabler, not an efficiency mechanism; while remote access may reduce some travel-related emissions, the characteristic itself does not consolidate workloads or improve energy utilization, so it is not the primary reason for carbon footprint reduction.

On-demand self-service

Why wrong: On-demand self-service lets users provision IT resources automatically without human intervention, speeding up deployment and reducing operational overhead. But this convenience can encourage more resource creation and does not inherently improve energy efficiency; the consumption pattern stays the same unless resources are pooled and shared. Hence, it is a usability feature, not a direct driver of reduced carbon footprint.

Rapid elasticity

Why wrong: Rapid elasticity allows resources to scale up and down in response to demand, which can avoid overprovisioning and wasted power. However, elasticity alone does not create efficiency—it simply adjusts capacity; without the underlying resource pooling that shares physical servers, scaling still runs on dedicated infrastructure with equivalent or worse energy concentration. Thus, the carbon benefit comes from pooling, not the scaling behavior itself.

Infrastructure as a Service (IaaS)

Why wrong: IaaS provides virtualized computing resources such as virtual machines, storage, and networking on demand, but it does not include a ready-made accounting application. The customer remains responsible for deploying and managing the entire software stack, including the operating system, middleware, and the accounting software itself, which still requires purchasing a license. Thus, IaaS only avoids the capital cost of physical servers, not the software purchase.

Platform as a Service (PaaS)

Why wrong: PaaS offers a managed development and hosting environment with tools for building, testing, and deploying custom applications, but it does not furnish end-user business software. To use accounting functionality on PaaS, an organization must either develop its own application or acquire and deploy a third-party package onto the platform, which still involves a purchasing or development effort. PaaS enables custom solutions rather than providing an instant, ready-to-run accounting package.

Function as a Service (FaaS)

Why wrong: FaaS is an event-driven serverless execution model where individual functions or code snippets run in response to triggers, abstracting away infrastructure management. It is designed for microservices and integrations, not for delivering a complete, user-facing application such as accounting software; using FaaS for accounting would require writing and maintaining all of the application's business logic and data processing code. Therefore, FaaS does not help avoid the cost or effort of sourcing the accounting software itself.

Public cloud

Why wrong: Public cloud services run on shared infrastructure owned by a provider and are typically multi-tenant, meaning multiple customers share the same physical hardware. Although providers like Azure offer a wide range of regional data centers that can be selected to keep data in a specific region, the default configurations often replicate data across multiple availability zones or regions for redundancy, which can inadvertently move data outside the required boundary. Additionally, enforcing strict residency in a public cloud requires carefully implementing data residency policies, data classification, and possibly disabling certain services, and even then the provider's operational processes may not guarantee zero data movement beyond the chosen region.

Hybrid cloud

Why wrong: A hybrid cloud integrates a private cloud with one or more public cloud services, enabling workload portability and scalability. For strict data residency, this model is risky because even if sensitive data is kept in the private on-premises portion, the hybrid architecture often involves networking connections and data synchronization between the two environments, which could allow data to be replicated or cached in a public cloud region outside the required geographic boundary. Managing and auditing data flow across the hybrid boundary is complex, and a single misconfiguration in a load balancer, backup, or disaster recovery process could result in a residency breach, making it less suitable than a private cloud for a hospital's strict compliance needs.

Community cloud

Why wrong: A community cloud is a shared cloud infrastructure built for a specific group of organizations with common compliance or regulatory concerns, such as hospitals or government agencies, and is often managed by one of the members or a third party. While it may seem appropriate for a hospital, the shared nature means that data from multiple tenants resides on the same infrastructure, and the data residency controls are a collective responsibility rather than a single organization's prerogative. This can make it difficult to enforce a strict, tailored data residency boundary for one hospital's data, and if the community spans multiple jurisdictions, the provider may place data in various locations to serve all members, potentially violating the hospital's specific residency requirement.

Infrastructure as a Service (IaaS)

Why wrong: Infrastructure as a Service (IaaS) gives you virtualized compute, storage, and networking on demand, but you must manage everything above the hardware: the guest operating system, middleware, runtime, security patches, and the accounting application itself. This is the opposite of a fully managed experience, because the customer retains significant administrative responsibility for the underlying stack. Since the question states that no management of the underlying resources is desired, IaaS is incorrect.

Platform as a Service (PaaS)

Why wrong: Platform as a Service (PaaS) provides an integrated hosting environment with managed operating systems, runtimes, and scaling, but it does not deliver a ready-to-use application. You still write, deploy, and maintain the application code, and you remain responsible for application-level configuration, security, and data. Because the user here wants to run an existing accounting application without any hands-on management, PaaS is not the right fit — it would still require your team to develop and manage the application itself.

Functions as a Service (FaaS)

Why wrong: Functions as a Service (FaaS) is a serverless computing model that executes individual units of code in response to events, with the platform handling automatic scaling and runtime environment provisioning. It is not a complete application delivery model: assembling a full accounting system would require many functions, orchestration, durable state, authentication, and integration logic that the user would still have to build and maintain. FaaS is therefore unsuitable as an answer because the objective is to consume a prebuilt application, not construct one from event-driven components.

Public cloud

Why wrong: A public cloud is a multi-tenant environment where compute and storage resources are pooled and shared across many customers, and the provider owns and operates all physical infrastructure. The end customer has limited ability to choose or know the exact server location, and the isolation between tenants relies on virtualized boundaries. For a financial services firm handling sensitive customer data, this lack of control over physical location and tenancy fails to provide the dedicated isolation that regulatory compliance often requires.

Hybrid cloud

Why wrong: A hybrid cloud combines public cloud resources with private cloud or on-premises infrastructure, typically for workload portability or burst capacity. The presence of a public cloud component means that sensitive customer data could be processed in a shared environment unless architecture explicitly restricts it, and the public side remains outside the company's direct control. To guarantee the isolation required for strict data governance, the entire workload would need to be locked to the private component, which effectively makes it a private cloud rather than a hybrid.

Community cloud

Why wrong: A community cloud is shared by two or more organizations that have similar compliance or operational requirements, such as government agencies or healthcare entities. While it offers some shared governance and security controls, it is still a multi-tenant model from the perspective of any single member, meaning the infrastructure is not dedicated to one organization. Because the financial services company would not have exclusive use, the same level of isolation and control as a private cloud is not achieved.

Scalability

Why wrong: Scalability is the capability to handle increased workload by adding resources, either by increasing the size of existing resources or adding more instances, and it is essential for growth. However, scaling can be manual or require advance planning, and it typically does not release unused resources when demand falls; elasticity is the specific form of scalability that automatically scales both up and down in response to real-time demand.

High availability

Why wrong: High availability keeps an application accessible by using redundant infrastructure across multiple availability zones or regions, with failover and load balancing that mask component failures. It is designed to minimize downtime and meet uptime SLAs, but it does not automatically adjust capacity in response to demand spikes, so resources remain static regardless of sudden traffic increases.

Fault tolerance

Why wrong: Fault tolerance is the ability of an application to continue operating correctly and without interruption even when one or more components, such as a server or network device, fail. It achieves this through redundant components and automatic failover that detect and replace failures, but it does not scale resources up or down based on load, so it cannot help with sudden spikes.

Measured service

Why wrong: Measured service is the cloud feature that meters and reports resource usage (e.g., CPU time, storage, network) to enable transparent billing and monitoring. While it is the technical enabler that makes consumption-based pricing possible, it is not the pricing model itself—it is the telemetry layer, not the financial charge. The correct answer is 'Consumption-based pricing' because that directly names the billing model, whereas measured service is a supporting mechanism.

Rapid elasticity

Why wrong: Rapid elasticity is a cloud characteristic that refers to the ability to automatically scale resources up or down quickly in response to demand, such as adding virtual machines during a traffic spike. It is a technical capability, not a billing model, and while it may influence the amount of usage (and thus the bill), it does not define how costs are charged. The question asks about the pricing model, so elasticity is not the correct answer.

Resource pooling

Why wrong: Resource pooling describes the cloud provider's use of a shared infrastructure to serve multiple customers (tenants) with multi-tenant isolation, enabling efficiency and economies of scale. It is a deployment characteristic that affects the provider's costs, not the customer's billing model. The customer still sees a usage-based bill, but pooling itself is not a pricing mechanism, making it incorrect for this question.

From operational expenditure (OpEx) to capital expenditure (CapEx)

Why wrong: This is the opposite of the financial impact of cloud adoption. Moving to the cloud minimizes capital expenditure by eliminating the need to purchase physical infrastructure, which is a CapEx item. Instead, recurring subscription and consumption charges appear as operational expenditure. Therefore, the direction is from CapEx to OpEx, making this option incorrect.

From direct expenditure to indirect expenditure

Why wrong: Direct versus indirect expenditure is not a classification used in cloud migration planning. The relevant categories are capital expenditure (CapEx) for upfront assets and operational expenditure (OpEx) for ongoing service fees. Cloud costs are directly attributable to usage, but the core financial transformation is between CapEx and OpEx, not between direct and indirect cost accounting.

From variable expenditure to fixed expenditure

Why wrong: This option reverses the actual change. On-premises IT typically involves fixed costs such as hardware purchases and annual software licenses, regardless of utilization. In the cloud, spending becomes variable, scaling with the amount of resources consumed. Thus the true shift is from fixed expenditure to variable expenditure, not the other way around.

High Availability

Why wrong: High Availability (HA) is concerned with maintaining service uptime and resilience in the face of infrastructure failures—such as hardware faults, network outages, or region-wide disasters—by using redundant deployments, availability zones, and fault domains. It does not, however, monitor demand metrics to change the number of running VMs; an HA architecture will keep the same instance count running but ensure those instances remain accessible, so it cannot explain a sudden increase in VM count during a peak traffic period.

Scalability

Why wrong: Scalability is the general capacity of a system to handle growing workloads by adding resources, either vertically (enlarging VM sizes) or horizontally (adding more VM instances). However, scalability by itself does not imply that this scaling happens automatically in response to real-time peaks; it can be a result of manual capacity planning, pre-scheduled scaling, or long-term growth forecasting. Elasticity is specifically the automated, dynamic version of scalability that matches resources to current demand, which is what the question describes.

Load Balancing

Why wrong: Load Balancing distributes incoming network traffic across an existing pool of virtual machines to avoid overloading any single instance and to improve overall availability and responsiveness. It acts as a traffic router, using health probes and algorithms like least connections or round-robin, but it has no mechanism to provision or deprovision VMs; it only works with the set of instances that currently exist. Thus, while a load balancer may work alongside an autoscaler, it is not the component that increases the number of VMs during peak usage.

Infrastructure as a Service (IaaS)

Why wrong: Infrastructure as a Service (IaaS) is wrong because it provides only virtualized compute, storage, and networking resources, such as Azure Virtual Machines. In this model, you are responsible for deploying and managing the operating system, middleware, and the email application itself—there is no ready-to-use email service. Using email via IaaS would still require you to install, configure, and maintain an email server, which contradicts the scenario of using a cloud email service without installing any software.

Platform as a Service (PaaS)

Why wrong: Platform as a Service (PaaS) is wrong because it offers a managed development and deployment environment (e.g., Azure App Service) rather than a ready-made application. Even though the provider manages the runtime and servers, you must still write or deploy your own application code to make an email service work. PaaS does not give you an out-of-the-box email client or mailbox; it is designed for developers building custom applications, not for end users seeking a subscription-based email service.

Anything as a Service (XaaS)

Why wrong: Anything as a Service (XaaS) is wrong because it is not a specific cloud service model but a broad, informal umbrella term describing any capability delivered over the internet. While an email service could technically be labeled 'something as a service,' XaaS does not define a particular operational model, pricing structure, or management boundary. The precise and standard classification for a fully managed email application is SaaS, not the generic XaaS term.

Public cloud

Why wrong: A public cloud model places all storage and computing resources on infrastructure owned and operated by the cloud provider, with customers sharing the underlying hardware. For a bank that must keep sensitive customer data on premises, moving all data to the public cloud would likely violate data residency, sovereignty, or internal security policies. Therefore, public cloud alone is insufficient because it does not allow the bank to retain primary custody of regulated data on its own premises.

Private cloud

Why wrong: A private cloud is dedicated solely to one organization and may be hosted on-premises, but it lacks the integration with public cloud resources that the bank's scenario requires. Even if the bank runs its own private cloud, it would be responsible for all capacity, maintenance, and scaling, and it would not gain the economic or elastic benefits of offloading non-sensitive workloads to a shared public provider. The scenario specifically calls for connecting on-premises data storage with cloud services, which is the essence of hybrid, not private, cloud.

Community cloud

Why wrong: A community cloud is a shared infrastructure used by several organizations from a specific community with common compliance, jurisdictional, or security concerns, but it is not designed to combine on-premises resources with a public cloud. This model is multi-tenant and typically hosted by a third party, so it would not satisfy the bank's explicit requirement to retain sensitive data on premises. The bank's need is a hybrid deployment, not a shared community platform, and community cloud does not provide the same public-cloud elasticity or the private-to-public bridging capability.

Operational expenditure to Capital expenditure

Why wrong: This is the reverse of the actual cloud model. When you move to Azure, you do not buy physical assets; instead you consume services and pay per use, which is OPEX. Capital expenditure would apply if you were building a data center and purchasing hardware with a multi-year depreciation schedule. Therefore, selecting this reverses the correct CAPEX-to-OPEX direction.

Direct cost to Indirect cost

Why wrong: Direct cost and indirect cost are accounting terms that classify whether a cost can be traced to a specific cost object, such as a product or department. They are unrelated to the financial model of cloud consumption. Azure pricing is based on a pay-per-use operational model, not on how costs are allocated in a general ledger. Thus this is not the relevant distinction for moving from on-premises to the cloud.

Fixed cost to Variable cost

Why wrong: While cloud costs can be variable (scaling with usage), the fixed-to-variable distinction is not the primary shift tested in Microsoft's cloud fundamentals. In fact, Azure Reserved Instances allow you to commit to a fixed cost for a term, yet the expense is still classified as OPEX because you own no underlying hardware. The defining change is from capital expenditure (purchasing depreciable assets) to operational expenditure (paying for consumed services), making this description a secondary characteristic rather than the core model.