Scenario practice questions

A small business is considering moving its email and collaboration suite to a cloud-based service where the provider manages the application, including updates and security patches. The business will access the software via a web browser. Which cloud service model is being described?

Trap 1: Platform as a Service (PaaS)

PaaS offers a platform for developing, running, and managing applications without the complexity of building and maintaining the underlying infrastructure. However, the customer typically manages the applications and data. Here, the business is using a complete application managed by the provider, so PaaS is not the correct model.

Trap 2: Function as a Service (FaaS)

FaaS, often part of serverless computing, allows developers to run code in response to events without managing servers. It is not used for delivering a full email and collaboration suite to end users. The business in this scenario is not writing or deploying code; it is consuming a ready-made application, so FaaS is not applicable.

Trap 3: Infrastructure as a Service (IaaS)

IaaS provides virtualized computing resources such as virtual machines, storage, and networks, but the customer is responsible for managing the operating system, middleware, and applications. In this scenario, the business does not manage any of those layers; it simply uses the email and collaboration software. Therefore, IaaS does not match the described service model.

A
Platform as a Service (PaaS)
Why it fails: PaaS offers a platform for developing, running, and managing applications without the complexity of building and maintaining the underlying infrastructure. However, the customer typically manages the applications and data. Here, the business is using a complete application managed by the provider, so PaaS is not the correct model.
B
Software as a Service (SaaS)
SaaS delivers a complete application over the internet, with the provider managing all underlying infrastructure, platforms, and application updates. The business simply accesses the software via a browser, exactly as described. This model eliminates the need for the business to handle any maintenance or patching, aligning perfectly with the scenario.
C
Function as a Service (FaaS)
Why it fails: FaaS, often part of serverless computing, allows developers to run code in response to events without managing servers. It is not used for delivering a full email and collaboration suite to end users. The business in this scenario is not writing or deploying code; it is consuming a ready-made application, so FaaS is not applicable.
D
Infrastructure as a Service (IaaS)
Why it fails: IaaS provides virtualized computing resources such as virtual machines, storage, and networks, but the customer is responsible for managing the operating system, middleware, and applications. In this scenario, the business does not manage any of those layers; it simply uses the email and collaboration software. Therefore, IaaS does not match the described service model.

Question 2mediummulti select

Which TWO scenarios are appropriate for using a load balancer?

Trap 1: To store persistent data

Storing persistent data is the role of block or object storage, not a load balancer, which distributes inbound traffic across backend instances. It is tempting because load balancers sit in front of servers that hold data, but they hold no state themselves; a load balancer suits spreading HTTP requests across a pool.

Trap 2: To reduce network latency to the internet

A load balancer distributes connections across backend instances; it does not shorten the network path to the internet, so latency is unchanged. It is tempting because distributing load can reduce queueing delay on saturated servers, which is the correct reason when backend capacity, not internet transit, is the bottleneck.

Trap 3: To encrypt data at rest

Load balancers operate at Layers 4 and 7, forwarding traffic; encryption at rest is handled by storage-layer mechanisms such as BitLocker or TDE. It is tempting because TLS termination at the balancer encrypts data in transit, which is the correct scenario when protecting client-to-service traffic is the requirement.

A
To store persistent data
Why it fails: Storing persistent data is the role of block or object storage, not a load balancer, which distributes inbound traffic across backend instances. It is tempting because load balancers sit in front of servers that hold data, but they hold no state themselves; a load balancer suits spreading HTTP requests across a pool.
B
To reduce network latency to the internet
Why it fails: A load balancer distributes connections across backend instances; it does not shorten the network path to the internet, so latency is unchanged. It is tempting because distributing load can reduce queueing delay on saturated servers, which is the correct reason when backend capacity, not internet transit, is the bottleneck.
C
To distribute traffic across multiple instances
A load balancer spreads incoming requests across multiple backend instances, preventing any single server from becoming a bottleneck. This satisfies the scaling constraint, allowing capacity to grow horizontally while presenting one stable endpoint to clients.
D
To improve fault tolerance
A load balancer improves fault tolerance by health-checking backend instances and automatically rerouting traffic away from failed nodes, satisfying the availability constraint. Distributing requests across multiple servers removes the single point of failure, so one instance's outage does not interrupt service, which is precisely the resilience outcome the scenario requires.
E
To encrypt data at rest
Why it fails: Load balancers operate at Layers 4 and 7, forwarding traffic; encryption at rest is handled by storage-layer mechanisms such as BitLocker or TDE. It is tempting because TLS termination at the balancer encrypts data in transit, which is the correct scenario when protecting client-to-service traffic is the requirement.

Question 3mediummultiple choice

A retail company is evaluating a move to cloud-based analytics. The CFO asks the cloud team to quantify the benefit of avoiding a large upfront data-center expansion. Which financial metric best captures this specific advantage?

Trap 1: Operational expenditure reduction

Operational expenditure reduction measures savings in ongoing costs such as power, cooling, licensing, and administration. It does not address the avoidance of a large upfront capital outlay for data-center expansion. The CFO specifically asks about avoiding upfront spending, not about lowering recurring operational costs, so this metric addresses a different part of the financial picture.

Trap 2: Return on investment (ROI)

ROI measures the net gain from an investment relative to its cost, but it does not isolate the value of deferring or eliminating capital expenditure. It combines all benefits and costs into a percentage, so it cannot specifically quantify the advantage of avoiding upfront data-center spending. The CFO's question targets the capital-avoidance effect, which ROI alone does not separate out.

Trap 3: Total cost of ownership (TCO)

TCO compares the full lifecycle costs of two alternatives, such as on-premises versus cloud. While it includes capital expenses, its purpose is a total cost comparison, not a focused measure of avoided upfront capital. The scenario asks specifically for the benefit of not making a large initial investment, so TCO is too broad and does not isolate that benefit.

A
Operational expenditure reduction
Why it fails: Operational expenditure reduction measures savings in ongoing costs such as power, cooling, licensing, and administration. It does not address the avoidance of a large upfront capital outlay for data-center expansion. The CFO specifically asks about avoiding upfront spending, not about lowering recurring operational costs, so this metric addresses a different part of the financial picture.
B
Return on investment (ROI)
Why it fails: ROI measures the net gain from an investment relative to its cost, but it does not isolate the value of deferring or eliminating capital expenditure. It combines all benefits and costs into a percentage, so it cannot specifically quantify the advantage of avoiding upfront data-center spending. The CFO's question targets the capital-avoidance effect, which ROI alone does not separate out.
C
Total cost of ownership (TCO)
Why it fails: TCO compares the full lifecycle costs of two alternatives, such as on-premises versus cloud. While it includes capital expenses, its purpose is a total cost comparison, not a focused measure of avoided upfront capital. The scenario asks specifically for the benefit of not making a large initial investment, so TCO is too broad and does not isolate that benefit.
D
Capital expenditure avoidance
Capital expenditure avoidance directly quantifies the financial benefit of not having to purchase and depreciate long-lived assets such as servers and data-center equipment. In this scenario, the company avoids a large upfront data-center expansion, so this metric precisely captures the CFO's requested benefit. It is a recognized cloud business-case metric for shifting from CapEx to OpEx.

Question 4mediummultiple choice

A financial services company runs a regulated workload on a public cloud. The compliance team requires that all data stored in object storage be encrypted at rest using keys that the company generates and controls, and that key usage be independently auditable. The cloud provider's default encryption uses provider-managed keys. Which action should the cloud operations team take?

Trap 1: Encrypt the data on-premises before upload and disable all…

Client-side encryption before upload protects data in transit and at rest, but disabling server-side encryption removes the provider's at-rest control and does not by itself produce an auditable key usage trail tied to the storage service. Compliance frameworks generally expect documented key management with logging, which this approach does not provide for the stored objects.

Trap 2: Enable provider-managed encryption and request an audit log export…

Provider-managed keys are generated, rotated, and stored by the cloud provider, so the company does not generate or control them. Support-provided log exports are not an independent, continuous audit mechanism and do not satisfy a requirement for customer-controlled keys. This approach leaves the compliance gap unaddressed because the control and auditability of the key material remain with the provider.

Trap 3: Store the data in a private subnet and rely on network isolation…

Network isolation controls reachability, not the confidentiality of data written to disk. The requirement explicitly calls for encryption at rest with customer-controlled, auditable keys, and a private subnet does not encrypt stored objects or generate key usage records. This option addresses a different control domain and would fail the compliance assessment.

A
Encrypt the data on-premises before upload and disable all server-side encryption on the bucket.
Why it fails: Client-side encryption before upload protects data in transit and at rest, but disabling server-side encryption removes the provider's at-rest control and does not by itself produce an auditable key usage trail tied to the storage service. Compliance frameworks generally expect documented key management with logging, which this approach does not provide for the stored objects.
B
Enable provider-managed encryption and request an audit log export from the provider's support team.
Why it fails: Provider-managed keys are generated, rotated, and stored by the cloud provider, so the company does not generate or control them. Support-provided log exports are not an independent, continuous audit mechanism and do not satisfy a requirement for customer-controlled keys. This approach leaves the compliance gap unaddressed because the control and auditability of the key material remain with the provider.
C
Configure customer-managed keys in the cloud provider's key management service and enable key usage logging.
Customer-managed keys in a cloud KMS let the organization generate, control, rotate, and revoke the key material itself. Enabling key usage logging produces an auditable record of every cryptographic operation, which directly satisfies the compliance requirement for independently auditable, customer-controlled encryption at rest. This is the standard pattern for regulated workloads on public cloud object storage.
D
Store the data in a private subnet and rely on network isolation instead of encryption at rest.
Why it fails: Network isolation controls reachability, not the confidentiality of data written to disk. The requirement explicitly calls for encryption at rest with customer-controlled, auditable keys, and a private subnet does not encrypt stored objects or generate key usage records. This option addresses a different control domain and would fail the compliance assessment.

Question 5mediummultiple choice

A retail company is migrating its order-processing application to the cloud. The application experiences unpredictable traffic spikes during flash sales, and the finance team wants to avoid paying for idle capacity. The IT manager proposes a cloud deployment model where the provider manages the infrastructure and the company pays only for what it consumes. Which cloud characteristic best describes this financial benefit?

Trap 1: On-demand self-service

On-demand self-service allows consumers to provision resources automatically without human interaction with the provider. While this supports agility, it does not describe the billing mechanism. The scenario emphasizes cost avoidance for idle capacity, which is a function of measured service, not the ability to self-provision.

Trap 2: Resource pooling

Resource pooling enables a provider to serve multiple customers using a multi-tenant model, dynamically assigning physical and virtual resources. This improves efficiency and cost for the provider, but it does not directly describe how the customer is billed. The finance team's concern is about paying for idle capacity, which is addressed by measured service, not pooling.

Trap 3: Rapid elasticity

Rapid elasticity allows resources to scale outward and inward automatically based on demand, but it does not inherently define the billing model. While the company benefits from scaling during spikes, the financial benefit of paying only for what is used is specifically tied to measured service. Rapid elasticity alone does not guarantee cost alignment.

A
Measured service
Measured service is a core cloud characteristic where resource usage is monitored, controlled, and reported, enabling pay-per-use billing. In this scenario, the retail company only pays for the capacity consumed during flash sales, aligning costs with actual demand. This directly addresses the finance team's goal of avoiding payment for idle capacity.
B
On-demand self-service
Why it fails: On-demand self-service allows consumers to provision resources automatically without human interaction with the provider. While this supports agility, it does not describe the billing mechanism. The scenario emphasizes cost avoidance for idle capacity, which is a function of measured service, not the ability to self-provision.
C
Resource pooling
Why it fails: Resource pooling enables a provider to serve multiple customers using a multi-tenant model, dynamically assigning physical and virtual resources. This improves efficiency and cost for the provider, but it does not directly describe how the customer is billed. The finance team's concern is about paying for idle capacity, which is addressed by measured service, not pooling.
D
Rapid elasticity
Why it fails: Rapid elasticity allows resources to scale outward and inward automatically based on demand, but it does not inherently define the billing model. While the company benefits from scaling during spikes, the financial benefit of paying only for what is used is specifically tied to measured service. Rapid elasticity alone does not guarantee cost alignment.

Question 6easymultiple choice

Which cloud characteristic allows a startup to automatically increase their compute resources during a marketing campaign and decrease them afterward without manual intervention?

Trap 1: Resource pooling

Resource pooling lets a provider serve multiple tenants from shared physical infrastructure, hiding location from the consumer. It concerns multi-tenancy, not demand-driven scaling. Automatic increase and decrease of compute during a campaign is rapid elasticity, so pooling does not satisfy the requirement.

Trap 2: Measured service

Measured service meters and reports consumption for billing and chargeback; it does not itself trigger scaling. Automatic provisioning and de-provisioning of compute in response to demand is rapid elasticity, which is the characteristic the marketing campaign scenario describes.

Trap 3: Broad network access

Broad network access means services are reachable over the network from diverse client devices. It addresses connectivity, not capacity. Automatic scaling up during a campaign and down afterwards is rapid elasticity, which broad network access alone cannot deliver.

A
Resource pooling
Why it fails: Resource pooling lets a provider serve multiple tenants from shared physical infrastructure, hiding location from the consumer. It concerns multi-tenancy, not demand-driven scaling. Automatic increase and decrease of compute during a campaign is rapid elasticity, so pooling does not satisfy the requirement.
B
Measured service
Why it fails: Measured service meters and reports consumption for billing and chargeback; it does not itself trigger scaling. Automatic provisioning and de-provisioning of compute in response to demand is rapid elasticity, which is the characteristic the marketing campaign scenario describes.
C
Broad network access
Why it fails: Broad network access means services are reachable over the network from diverse client devices. It addresses connectivity, not capacity. Automatic scaling up during a campaign and down afterwards is rapid elasticity, which broad network access alone cannot deliver.
D
Elasticity
Elasticity automatically provisions and deprovisions compute capacity in response to real-time demand, scaling out during the campaign and back in afterwards without manual intervention. This matches the stem's requirement for automatic, unprompted adjustment, whereas scalability alone only describes the capacity ceiling.

Question 7hardmulti select

Which THREE types of costs should be included in a thorough TCO analysis for cloud migration?

Trap 1: Marketing budget for the migration project

Marketing spend promotes the migration but is not a cost of operating the resulting cloud environment, so it sits outside TCO. It is tempting because it is a real project cost, but TCO analysis captures the total cost of owning and running the solution, not discretionary promotional expenditure.

Trap 2: Physical office building rent

Physical office rent is a facility cost unaffected by moving workloads to cloud, so it falls outside migration TCO. It is tempting because it is a genuine IT-adjacent operating expense, but TCO for cloud migration covers costs that change with the migration, such as compute, storage, licensing, and transition labour.

A
Application refactoring and development labor
Migration is not merely subscription substitution: existing applications often need re-platforming or rewriting before they run in the cloud. Counting refactoring and development labour satisfies the stem's thorough TCO requirement by capturing the one-off transformation cost that precedes any ongoing cloud consumption.
B
Marketing budget for the migration project
Why it fails: Marketing spend promotes the migration but is not a cost of operating the resulting cloud environment, so it sits outside TCO. It is tempting because it is a real project cost, but TCO analysis captures the total cost of owning and running the solution, not discretionary promotional expenditure.
C
Physical office building rent
Why it fails: Physical office rent is a facility cost unaffected by moving workloads to cloud, so it falls outside migration TCO. It is tempting because it is a genuine IT-adjacent operating expense, but TCO for cloud migration covers costs that change with the migration, such as compute, storage, licensing, and transition labour.
D
Data egress and ingress network charges
Cloud providers typically charge nothing for inbound data but bill for outbound transfer, so egress fees scale with usage and can dominate long-term spend. Including these network charges satisfies the stem's requirement for a thorough TCO analysis, capturing costs absent from on-premises comparisons.
E
Cloud service subscription and consumption costs
Subscription and consumption charges are the recurring operational cost of running workloads in the cloud, covering compute, storage and managed services. Including them satisfies the stem's thorough TCO analysis requirement by establishing the baseline ongoing spend against which migration savings are measured.

Question 8hardmultiple choice

When performing a TCO analysis for migrating a legacy on-premises database to Azure SQL, which hidden cost is most likely to be overlooked?

Trap 1: Power and cooling

Power and cooling are removed by decommissioning on-premises hardware, so they are savings from migration, not overlooked costs. It is tempting because these facility charges are easily forgotten in on-premises budgets, which would make this correct if the question asked which existing costs migration eliminates.

Trap 2: Software licensing

Software licensing is a real on-premises cost, but migrating to Azure SQL shifts it into the Azure subscription price, so it is not the overlooked hidden cost. It is tempting because licensing is often undercounted, which would be correct if the question asked about on-premises TCO rather than migration.

Trap 3: Hardware maintenance

Hardware maintenance disappears once the database runs on Azure SQL, so it is a cost eliminated by migration rather than a hidden cost to overlook. It is tempting because it is a genuine on-premises expense, which would make it correct if the question asked which costs the business case removes.

A
Power and cooling
Why it fails: Power and cooling are removed by decommissioning on-premises hardware, so they are savings from migration, not overlooked costs. It is tempting because these facility charges are easily forgotten in on-premises budgets, which would make this correct if the question asked which existing costs migration eliminates.
B
Data egress fees
Data egress fees are charged for outbound data leaving Azure regions or the cloud, so they rarely appear in initial migration estimates yet accumulate with ongoing query and replication traffic, making them the commonly overlooked TCO line item.
C
Software licensing
Why it fails: Software licensing is a real on-premises cost, but migrating to Azure SQL shifts it into the Azure subscription price, so it is not the overlooked hidden cost. It is tempting because licensing is often undercounted, which would be correct if the question asked about on-premises TCO rather than migration.
D
Hardware maintenance
Why it fails: Hardware maintenance disappears once the database runs on Azure SQL, so it is a cost eliminated by migration rather than a hidden cost to overlook. It is tempting because it is a genuine on-premises expense, which would make it correct if the question asked which costs the business case removes.

Question 9mediummultiple choice

A healthcare organization stores electronic protected health information (ePHI) in a public cloud. The security team must ensure that only authorized users can access the data and that all access is logged for audit purposes. Which cloud security control should be implemented to meet these requirements?

Trap 1: Encrypt the data at rest using provider-managed keys.

Encryption at rest protects data if the storage media is compromised, but it does not enforce user authorization or produce access logs. Unauthorized users with valid credentials could still access the data. The scenario requires both access control and logging, which encryption alone does not provide.

Trap 2: Configure a web application firewall (WAF) to filter malicious…

A WAF protects web applications from common exploits like SQL injection and cross-site scripting, but it does not control which users can access the data nor does it log user-level access to ePHI. It is a perimeter defense, not an access control or auditing mechanism.

Trap 3: Enable multi-factor authentication (MFA) for all user accounts.

MFA strengthens authentication by requiring a second factor, but it does not provide the detailed access logging needed for audit purposes. While it reduces the risk of credential compromise, it does not by itself ensure that all access attempts are recorded. The scenario explicitly requires logging, so MFA alone is insufficient here.

A
Encrypt the data at rest using provider-managed keys.
Why it fails: Encryption at rest protects data if the storage media is compromised, but it does not enforce user authorization or produce access logs. Unauthorized users with valid credentials could still access the data. The scenario requires both access control and logging, which encryption alone does not provide.
B
Configure a web application firewall (WAF) to filter malicious traffic.
Why it fails: A WAF protects web applications from common exploits like SQL injection and cross-site scripting, but it does not control which users can access the data nor does it log user-level access to ePHI. It is a perimeter defense, not an access control or auditing mechanism.
C
Enable multi-factor authentication (MFA) for all user accounts.
Why it fails: MFA strengthens authentication by requiring a second factor, but it does not provide the detailed access logging needed for audit purposes. While it reduces the risk of credential compromise, it does not by itself ensure that all access attempts are recorded. The scenario explicitly requires logging, so MFA alone is insufficient here.
D
Implement role-based access control (RBAC) and enable audit logging.
RBAC restricts data access to users based on their role, ensuring only authorized personnel can view ePHI. Enabling audit logging captures all access events, satisfying the requirement to log access for audits. Together, these controls address both the authorization and logging aspects of the scenario.

Question 10mediummultiple choice

A healthcare startup stores patient records in a public cloud. The security team wants to ensure that data cannot be read if the underlying storage media is physically stolen from the provider's data center. Which control should they verify is enabled?

Trap 1: Multi-factor authentication for all administrative accounts

MFA strengthens authentication and reduces the risk of unauthorized access via stolen credentials, but it does not encrypt data on disk. If the physical storage media is stolen, MFA is irrelevant because the attacker bypasses logical access controls. This control addresses a different threat vector than physical theft.

Trap 2: Role-based access control (RBAC) for storage bucket permissions

RBAC governs who can access data through the cloud APIs, but it does not protect data if the physical disk is stolen. An attacker with physical possession of the drive can bypass RBAC entirely. This control is about logical access management, not physical media protection, so it fails to meet the scenario's requirement.

Trap 3: Transport Layer Security (TLS) for all API calls

TLS protects data in transit between the client and the cloud service, not data stored on physical media. If a disk is stolen, TLS does nothing to protect the data at rest. While important for overall security, it does not satisfy the requirement of protecting data if the storage media is physically removed.

A
Multi-factor authentication for all administrative accounts
Why it fails: MFA strengthens authentication and reduces the risk of unauthorized access via stolen credentials, but it does not encrypt data on disk. If the physical storage media is stolen, MFA is irrelevant because the attacker bypasses logical access controls. This control addresses a different threat vector than physical theft.
B
Role-based access control (RBAC) for storage bucket permissions
Why it fails: RBAC governs who can access data through the cloud APIs, but it does not protect data if the physical disk is stolen. An attacker with physical possession of the drive can bypass RBAC entirely. This control is about logical access management, not physical media protection, so it fails to meet the scenario's requirement.
C
Transport Layer Security (TLS) for all API calls
Why it fails: TLS protects data in transit between the client and the cloud service, not data stored on physical media. If a disk is stolen, TLS does nothing to protect the data at rest. While important for overall security, it does not satisfy the requirement of protecting data if the storage media is physically removed.
D
Encryption at rest using provider-managed keys
Encryption at rest ensures that data stored on physical media is unreadable without the decryption key. If the storage media is stolen, the ciphertext is useless without the key. Provider-managed keys are acceptable here because the threat is physical theft, not provider insider access. This control directly addresses the scenario's requirement.

Question 11easymultiple choice

A startup deploys a web application on a public cloud. The operations team wants to be notified automatically when average CPU utilization on the application servers exceeds 80 percent for five consecutive minutes, without manually checking dashboards. Which capability should the team configure?

Trap 1: A scheduled script that queries the provider's billing API every…

The billing API reports cost and usage data, not real-time CPU utilization, and billing data is typically delayed by hours. Even if the script ran every five minutes, it could not detect a CPU spike promptly or reliably, so it fails the requirement for timely automatic notification based on a performance metric.

Trap 2: A configuration management runbook that restarts instances when CPU…

A runbook remediates a condition but does not detect it or notify anyone. Without a monitoring alarm feeding it, the runbook has no trigger, and restarting instances is a disruptive action that may not be appropriate. This option confuses remediation with the requested alerting capability and would not satisfy the notification requirement.

Trap 3: A log aggregation query that searches application logs for the word…

Log queries operate on emitted log events, not on infrastructure performance metrics, and application logs rarely contain host CPU percentages. Relying on a text search would produce false positives or miss the condition entirely, and it would not provide the threshold-based, time-windowed evaluation the team needs for automatic notification.

A
A scheduled script that queries the provider's billing API every five minutes.
Why it fails: The billing API reports cost and usage data, not real-time CPU utilization, and billing data is typically delayed by hours. Even if the script ran every five minutes, it could not detect a CPU spike promptly or reliably, so it fails the requirement for timely automatic notification based on a performance metric.
B
A cloud monitoring alarm with a notification action tied to the metric threshold.
Cloud monitoring services evaluate metric streams against defined thresholds over a specified evaluation period. Creating an alarm on average CPU utilization with an 80 percent threshold and a five-minute evaluation window, plus a notification action such as an email or webhook, delivers automatic alerting exactly as requested. This is the native, low-effort way to convert a metric condition into an actionable notification.
C
A configuration management runbook that restarts instances when CPU is high.
Why it fails: A runbook remediates a condition but does not detect it or notify anyone. Without a monitoring alarm feeding it, the runbook has no trigger, and restarting instances is a disruptive action that may not be appropriate. This option confuses remediation with the requested alerting capability and would not satisfy the notification requirement.
D
A log aggregation query that searches application logs for the word CPU.
Why it fails: Log queries operate on emitted log events, not on infrastructure performance metrics, and application logs rarely contain host CPU percentages. Relying on a text search would produce false positives or miss the condition entirely, and it would not provide the threshold-based, time-windowed evaluation the team needs for automatic notification.

Question 12mediummultiple choice

A retail company runs a legacy inventory application on physical servers in its own data center. The CIO wants to keep the application unchanged but gain cloud elasticity for seasonal peaks, and legal requires that all customer data remain on company-owned hardware. Which cloud deployment consideration does this scenario illustrate?

Trap 1: The company should adopt a public cloud because elasticity is only…

Elasticity is not exclusive to public clouds; private and hybrid environments can also scale resources on demand. More importantly, this option ignores the legal requirement that customer data stay on company-owned hardware. Recommending a public cloud would violate that constraint, so this choice misreads the scenario's central tension between elasticity and data residency.

Trap 2: The company should keep everything on-premises because cloud…

Cloud elasticity does not require rewriting an application; hybrid bursting and infrastructure scaling can support unchanged workloads. Choosing to stay entirely on-premises abandons the CIO's elasticity objective and offers no path to handle seasonal peaks. This option is technically inaccurate and ignores the hybrid capability that resolves the described conflict.

Trap 3: The company should rehost the application in a community cloud…

A community cloud is shared by organizations with common concerns, but it still runs on infrastructure the company does not own. That directly conflicts with the legal requirement that customer data remain on company-owned hardware. Sharing with competitors also raises competitive and compliance risks, so this option fails both the ownership constraint and the spirit of the scenario.

A
The company should adopt a public cloud because elasticity is only available there
Why it fails: Elasticity is not exclusive to public clouds; private and hybrid environments can also scale resources on demand. More importantly, this option ignores the legal requirement that customer data stay on company-owned hardware. Recommending a public cloud would violate that constraint, so this choice misreads the scenario's central tension between elasticity and data residency.
B
The company should keep everything on-premises because cloud elasticity requires rewriting the application
Why it fails: Cloud elasticity does not require rewriting an application; hybrid bursting and infrastructure scaling can support unchanged workloads. Choosing to stay entirely on-premises abandons the CIO's elasticity objective and offers no path to handle seasonal peaks. This option is technically inaccurate and ignores the hybrid capability that resolves the described conflict.
C
The company should rehost the application in a community cloud shared with competitors
Why it fails: A community cloud is shared by organizations with common concerns, but it still runs on infrastructure the company does not own. That directly conflicts with the legal requirement that customer data remain on company-owned hardware. Sharing with competitors also raises competitive and compliance risks, so this option fails both the ownership constraint and the spirit of the scenario.
D
The company should use a hybrid approach, keeping data on-premises while bursting compute to the cloud
A hybrid deployment connects private infrastructure with public cloud resources, allowing workloads to burst outward for peak demand while sensitive data remains on company-owned hardware. This satisfies both the CIO's elasticity goal and the legal mandate. The legacy application can remain largely unchanged while the hybrid architecture absorbs seasonal load, making this the balanced and compliant choice.

Question 13easymultiple choice

A startup wants to give its data scientists on-demand access to GPU-backed virtual machines for experiments. Usage will be sporadic, and the company wants to pay only for the time the machines run. Which cloud characteristic is the company primarily relying on?

Trap 1: Broad network access from any device

Broad network access describes reachability of cloud services over standard networks from varied clients. While the data scientists presumably connect over the network, that characteristic does not explain the on-demand GPU provisioning or the usage-based cost model described. It addresses accessibility, not consumption-based billing.

Trap 2: Resource pooling across multiple tenants

Resource pooling explains how providers serve many customers from shared physical infrastructure, but it does not by itself deliver the pay-only-while-running billing the startup wants. The scenario's emphasis is on sporadic usage and cost tied to runtime, which is a metering and billing concern rather than a multi-tenancy concern.

Trap 3: Rapid elasticity to scale capacity automatically

Rapid elasticity lets capacity expand and contract with demand, which is useful, but it does not describe how the startup is charged. The scenario specifically states the company wants to pay only for the time machines run, which is a metering characteristic. Elasticity alone could still be paired with fixed subscription pricing.

A
Broad network access from any device
Why it fails: Broad network access describes reachability of cloud services over standard networks from varied clients. While the data scientists presumably connect over the network, that characteristic does not explain the on-demand GPU provisioning or the usage-based cost model described. It addresses accessibility, not consumption-based billing.
B
Resource pooling across multiple tenants
Why it fails: Resource pooling explains how providers serve many customers from shared physical infrastructure, but it does not by itself deliver the pay-only-while-running billing the startup wants. The scenario's emphasis is on sporadic usage and cost tied to runtime, which is a metering and billing concern rather than a multi-tenancy concern.
C
Rapid elasticity to scale capacity automatically
Why it fails: Rapid elasticity lets capacity expand and contract with demand, which is useful, but it does not describe how the startup is charged. The scenario specifically states the company wants to pay only for the time machines run, which is a metering characteristic. Elasticity alone could still be paired with fixed subscription pricing.
D
Measured service with pay-as-you-go billing
Measured service means the provider meters resource consumption and bills accordingly. Because the data scientists use GPU instances sporadically and the company wants to pay only while those machines run, the metered, pay-per-use billing model is the characteristic being leveraged. This directly ties cost to actual consumption rather than to a fixed owned asset.