Cloud Concepts, Architecture, and Design practice questions

The customer receives a full refund for the service

Why it fails: SLAs typically provide service credits, a percentage of monthly fees, rather than a full refund of all charges. A full refund is tempting because it sounds like the natural remedy for total failure, but credits are the standard contractual compensation mechanism, and outages rarely trigger complete reimbursement.

The contract is immediately terminated

Why it fails: SLA breaches usually entitle the customer to service credits, not automatic contract termination. Termination is tempting because repeated failures may justify exiting the agreement, but that requires the customer to invoke a remedy or exit clause, not an immediate automatic contractual end triggered by any shortfall.

The customer can take legal action

Why it fails: SLAs define service credits as the primary remedy and often exclude consequential-loss claims, so legal action is not a likely direct consequence. It is tempting because breach of contract can be litigated, but the SLA's credit mechanism and liability caps generally displace that route for availability shortfalls.

1.01 hours

Why it fails: Not a standard calculation.

5.26 minutes

Why it fails: That would be 99.999% availability.

8.76 hours

Why it fails: That corresponds to 99.9% availability (0.1% downtime).

Direct exposure of on-premises services to the cloud via public internet

Why it fails: Publishing on-premises services directly to the public internet removes the private transport and encryption a hybrid connection requires, exposing them to untrusted networks. It is tempting as a quick, low-cost link, but it is the correct choice only for deliberately public, internet-facing endpoints.

Cloud access security broker (CASB)

Why it fails: A CASB enforces policy and visibility over cloud service usage; it does not establish the network path between on-premises and cloud environments. It is tempting because CASBs sit between users and cloud services, but that role is access governance, not site-to-site connectivity.

MPLS-based VPN from a telecom provider

Why it fails: MPLS-based VPNs from a telecom provider deliver private WAN connectivity, but they do not extend the organisation's security policy into the cloud environment; the stem requires secure on-premises-to-cloud connectivity, which site-to-site IPsec VPNs or dedicated private links achieve. MPLS suits connecting fixed branch offices across a carrier backbone, not hybrid cloud integration.

Provider's stock price performance

Why it fails: Share price reflects investor sentiment, not the regional footprint, redundancy or interconnect topology that determine latency and availability. It is tempting because financial stability does affect provider longevity, so it belongs in a business-risk assessment, but it cannot evidence the resilience of the application's delivery.

Number of employees at the provider

Why it fails: Employee count is not a direct factor for availability or latency.

PCI DSS

Why it fails: PCI DSS is a payment-card industry data security standard, not an independent audit report or certification of a provider's security controls. It is tempting because it is a recognised compliance framework, and would be relevant when assessing cardholder-data handling rather than general control verification.

FedRAMP

Why it fails: FedRAMP is a US government program, not a general audit.

Shared database for all tenants

Why it fails: A single shared database gives every tenant access to the same tables and rows, so no logical boundary separates their data; isolation requires per-tenant schemas, row-level security or separate stores. Consolidating tenants onto one database is tempting because it reduces cost and administrative overhead, and it is valid only when strict row-level security enforces separation.

Single sign-on (SSO) for all tenants

Why it fails: Single sign-on authenticates identities across tenants; it does not partition data, compute or network traffic, so it provides no tenant separation. It is tempting because SSO is a standard SaaS feature and does appear in multi-tenant designs, but it belongs to identity federation, not to the isolation mechanisms the question asks for.

Using a single database schema for all tenants

Why it fails: A shared schema gives tenants no logical separation at the data layer, so a query flaw or misconfigured row-level filter exposes other tenants' records. It is tempting because it minimises storage and administrative overhead, and it is acceptable in single-tenant deployments or where every consumer is trusted to see all data.

Shared memory segments across tenants for performance

Why it fails: Shared memory between tenants lets one tenant read or corrupt another's data, defeating isolation entirely. It is tempting because shared memory boosts inter-process performance within a single trust boundary, which is legitimate for processes inside one tenant's own workload, not across tenants.

Public cloud

Why it fails: Public cloud typically stores data in data centers that may be located in various jurisdictions, making it difficult to guarantee data sovereignty unless the provider offers specific regional controls. However, public cloud alone does not inherently ensure data remains within a specific legal jurisdiction, and integration with on-premises systems may be limited without additional architecture.

Private cloud

Why it fails: Private cloud offers dedicated infrastructure and can be located on-premises or in a specific jurisdiction, which helps with data sovereignty. However, it may not provide the same level of integration with external systems as a hybrid cloud, and it may lack the scalability and cost benefits of public cloud.

Community cloud

Why it fails: Community cloud is shared by several organizations with common concerns, but it does not inherently guarantee that data remains within a specific legal jurisdiction. It may be hosted in multiple locations, and integration with on-premises systems depends on the specific implementation.

Public cloud

Why it fails: Public cloud is multi-tenant and may store data in multiple regions unless explicitly restricted. While it avoids capital expenditure, it does not inherently guarantee that data remains within one country or that access is limited to the startup's employees. The startup would need additional controls, making public cloud less appropriate than a model designed for exclusive use.

Hybrid cloud

Why it fails: Hybrid cloud combines private and public elements, which introduces complexity and potential data movement across environments. The startup needs a single-country, employee-only deployment, and hybrid does not inherently enforce that. It also may not reduce capital costs if private infrastructure is still required, making it less appropriate here.

Private cloud

Why it fails: A private cloud can meet residency and exclusivity requirements, but building and operating one typically requires significant capital and operational expense. The startup explicitly wants to avoid building a data center, so a private cloud on-premises is not the best fit. It may be overkill for the stated constraints.

Platform as a Service (PaaS)

Why it fails: PaaS provides a development and deployment environment but abstracts away the underlying servers and scaling mechanisms. While it can auto-scale, it may not offer the granular control needed for a high-performance streaming platform that requires specific configurations. The media company likely needs more control over the infrastructure than PaaS provides.

Function as a Service (FaaS)

Why it fails: FaaS is event-driven and executes code in response to events, but it is not ideal for long-running streaming sessions or persistent connections. It has execution time limits and may not support the continuous, high-bandwidth data transfer required for live streaming. The media company needs a more persistent and controllable environment, making FaaS inappropriate.

Software as a Service (SaaS)

Why it fails: SaaS delivers a complete application managed by the provider, but it does not give the media company control over the underlying infrastructure to handle sudden scaling of its own streaming platform. SaaS is typically used for standard business applications like email or CRM. Here, the company needs to manage its own application and scaling, so SaaS is not suitable.

Community cloud shared by several retail organizations

Why it fails: A community cloud is shared by multiple organizations with common interests, so the compute layer is not dedicated to the single retailer. Even if all members are retailers, the data could be processed on shared infrastructure, violating the explicit requirement that only the chain's own systems handle point-of-sale transactions.

Private cloud hosted in the retailer's own data center

Why it fails: A private cloud gives the required dedication and control, but it sacrifices the public cloud elasticity and cost benefits the retailer explicitly wants. Because the stem requires retaining public cloud scalability and pay-per-use economics, a fully on-premises private cloud does not satisfy the stated business and financial objectives.

Public cloud with a customer-managed virtual private cloud (VPC)

Why it fails: A VPC provides logical network isolation within a public cloud, but the underlying physical hosts, hypervisor, and storage may still be shared with other tenants. It does not guarantee dedicated compute at the hardware layer, so it fails the requirement that transaction data be processed only by systems dedicated to the retail chain.

Function as a Service (FaaS)

Why it fails: FaaS executes small, event-driven functions with strict execution time and resource limits, which makes it a poor fit for sustained, high-throughput video transcoding that may run for hours. While FaaS scales automatically, the per-invocation duration and memory ceilings would force complex chunking, adding latency and operational overhead compared with provisioning dedicated IaaS compute for the event.

Software as a Service (SaaS)

Why it fails: SaaS delivers a complete, provider-managed application to end users, which removes control over the runtime and infrastructure. A media company needing custom transcoding pipelines and direct control over compute instances cannot customize the underlying platform or tune performance for live video workloads, making SaaS unsuitable for this processing-intensive, timing-sensitive scenario.

Platform as a Service (PaaS)

Why it fails: PaaS provides a managed environment for deploying applications without managing the underlying infrastructure, but it does not inherently deliver the rapid, short-lived compute elasticity needed for bursty video transcoding. The customer would still need to design scaling logic, and PaaS runtimes are optimized for application hosting rather than ephemeral, high-throughput compute jobs driven by live event timing.

PaaS

Why it fails: PaaS reduces patching by managing the runtime and often the database service, but the development team wants control over the runtime and libraries, and the organization wants to manage the relational database itself. PaaS would abstract away or restrict those layers, creating a mismatch with both the control and database management requirements.

DBaaS

Why it fails: Database as a Service would provide a managed database, but the scenario specifies that the organization wants to manage the relational database itself. It also does not address compute, runtime, or application hosting needs, so it cannot serve as the primary service model for the customer-facing application.

SaaS

Why it fails: SaaS would minimize patching because the provider manages nearly the entire stack, including the application. However, it removes control over the runtime, libraries, and application code that the development team requires, and it does not allow the organization to manage its own relational database. It therefore over-satisfies the security goal while failing the control requirements.

A content delivery network edge cache configured to hold the master files

Why it fails: A content delivery network caches content close to viewers to accelerate delivery; it is not an authoritative storage tier. Edge nodes evict content based on popularity and time-to-live, so masters would be purged and could not be guaranteed retrievable for seven years. There is also no retention, versioning, or immutability control suited to archival compliance.

Block storage volumes attached to persistent virtual machines in a private cloud

Why it fails: Block volumes are tied to compute instances, so 800 TB requires provisioning and paying for many hosts and their attached disks continuously. Block storage also lacks native lifecycle tiering and HTTP retrieval, making long-term archival both expensive and operationally heavy. It solves latency for databases, not cheap petabyte-scale retention with occasional reads.

A distributed file system hosted on dedicated bare-metal servers inside the corporate data center

Why it fails: A self-managed distributed file system gives control but shifts all capital and operational cost back on premises: hardware refresh, rack space, power, replication, and patching for seven years. It does not deliver cloud elasticity, and the organization explicitly wants to reduce recurring cost. The retention requirement is met, but the economics and resilience are inferior to a managed archive tier.

Private cloud

Why it fails: A private cloud is provisioned for exclusive use by a single organization, so it satisfies the isolation requirement, but a purely private deployment cannot burst into external capacity without becoming hybrid. The scenario explicitly requires seasonal bursting beyond owned capacity. Standing up enough private hardware for peak demand also wastes the enterprise's existing investment during off-peak periods, so this model alone is incomplete.

Public cloud

Why it fails: A public cloud is provisioned for open use by the general public and its underlying hosts are shared across many unrelated tenants through logical isolation. That directly conflicts with the legal requirement that the infrastructure never be shared with unrelated organizations. Although a public cloud bursts easily during seasonal peaks, it fails the controlling constraint in this scenario, which is tenant exclusivity of the infrastructure.

Community cloud

Why it fails: A community cloud is provisioned for use by a specific set of organizations that share concerns such as compliance or mission, so the infrastructure is intentionally shared among several tenants. That violates the requirement that the platform never share infrastructure with unrelated organizations. Community clouds also do not inherently provide the elastic bursting capability the seasonal analytics peaks demand, so this option fails on both counts.

Elasticity

Why it fails: Elasticity is the ability to rapidly scale resources up and down to match demand, which is a provisioning characteristic rather than a monitoring or auditing function. It does not provide visibility into usage and performance across environments, so it does not match the capability described in the requirement.

Auditability

Why it fails: Auditability refers to the ability to collect and retain evidence for assessments, but the described capability is broader, encompassing ongoing monitoring and control of service usage and performance. Auditability is a component of the broader capability but does not by itself cover the continuous control aspect named in the requirement.

Measured service

Why it fails: Measured service means resource usage is metered and reported for billing and chargeback purposes, but it does not inherently provide the control and audit functions across multiple cloud environments. The requirement emphasizes monitoring, control, and auditing, which measured service alone does not deliver as a governance capability.

Data minimization

Why it fails: Data minimization is a GDPR principle that requires collecting only necessary data, but it does not address geographic restrictions. It is about reducing the amount of data collected, not about where it is stored. Therefore, it does not meet the requirement to keep data within the EU.

Data sovereignty

Why it fails: Data sovereignty is the concept that data is subject to the laws of the country where it is stored. While relevant, it does not provide a technical design principle to prevent replication. It is more of a legal concept. The company needs a technical control to ensure data stays in the EU.

Data residency

Why it fails: Data residency refers to the physical location where data is stored, which is important for GDPR, but it does not by itself prevent replication to other regions. The company must also enforce policies to control data movement. Data residency is a component, but not the complete principle.

Software as a Service (SaaS)

Why it fails: SaaS delivers ready-to-use software applications over the internet, but it does not provide a platform for developing custom applications. The startup needs to deploy its own backend code, so SaaS is not suitable. SaaS is for end-users who want to use existing software, not for developers building new applications.

Function as a Service (FaaS)

Why it fails: FaaS, also known as serverless computing, allows running code in response to events without managing servers. While it reduces management overhead, it is designed for event-driven, short-lived functions and may not be the best fit for a full backend application that requires persistent connections or long-running processes. The startup may need a more comprehensive platform.

Infrastructure as a Service (IaaS)

Why it fails: IaaS provides virtualized computing resources over the internet, but the customer is responsible for managing the operating system, middleware, and runtime. This requires significant operational expertise and does not minimize management overhead. A startup with limited ops expertise would need to invest time in patching, scaling, and securing the infrastructure, which detracts from focusing on coding.

Public cloud

Why it fails: A public cloud shares physical infrastructure across tenants, so it cannot deliver the dedicated, unshared environment the company demands. It is tempting because public cloud offers rapid provisioning and low cost for workloads without isolation requirements, but the stem's no-shared-infrastructure constraint rules it out.

Hybrid cloud

Why it fails: Hybrid cloud combines private infrastructure with public cloud services, so workloads still traverse shared provider hardware — failing the no-shared-infrastructure requirement. It is tempting because hybrid genuinely suits gradual migrations, bursting, or regulatory data-residency splits between on-premises systems and public cloud. Here, only a private cloud delivers a dedicated, unshared environment.

Community cloud

Why it fails: A community cloud still pools infrastructure across several organisations, so hardware remains shared rather than dedicated to one tenant. It tempts because it genuinely serves groups with common compliance or regulatory needs, such as several banks sharing a hardened environment. A private cloud, provisioned exclusively for a single organisation, is what the no-shared-infrastructure requirement demands.

SaaS

Why it fails: SaaS delivers finished applications; consumers cannot deploy their own code or choose the provider's languages and libraries. It is tempting because SaaS also hides all underlying infrastructure, which matches part of the stem, but it would be correct when the requirement is simply consuming a complete hosted application.

IaaS

Why it fails: IaaS provides raw compute, storage and networking, leaving the consumer to install runtimes, libraries and tools themselves. It is tempting because IaaS also denies management of the physical infrastructure, but it would be correct when the requirement is provisioning virtual machines rather than deploying code onto a managed platform.

CaaS

Why it fails: CaaS orchestrates containers, so the consumer supplies and maintains the application runtime, libraries and tooling inside those containers. It is tempting because CaaS abstracts the underlying hosts, but it would be correct when the requirement is deploying containerised workloads rather than using provider-supplied programming languages and tools.