Business Principles OF Cloud Environments practice questions

Vendor marketing brochure

Why it fails: Marketing materials do not provide verifiable proof of regulatory compliance.

Service Level Agreement (SLA)

Why it fails: An SLA defines uptime availability, not regulatory compliance status.

Public pricing catalog

Why it fails: Pricing is irrelevant to regulatory compliance requirements.

API Activity Log

Why it fails: CloudTrail logs API calls, not cost-based resource utilization data.

Service Quotas

Why it fails: Service Quotas manage limits, not billing efficiency.

Resource Tagging

Why it fails: Tagging is for organization, not for identifying idle resource patterns directly.

Debt-to-Equity Ratio

Why it fails: This measures financial leverage and is not directly tied to the infrastructure cost model.

Internal Rate of Return (IRR)

Why it fails: IRR is typically used for long-term project viability rather than operational expense shifts.

Net Present Value (NPV)

Why it fails: NPV is used to analyze the profitability of a projected investment, not the shift in accounting models.

Written in Java

Why it fails: Java is a widely supported, portable language with mature cloud runtimes, so it presents no migration barrier. Legacy difficulty arises from unsupported runtimes, hard-coded dependencies or monolith coupling. Java would be the correct answer only if the question asked which language eases portability.

Used by a small team

Why it fails: Small-team usage is an organisational attribute, not a technical legacy trait; it does not impede migration. Legacy difficulty stems from tight coupling, unsupported runtimes or hard-coded dependencies. A small user base would actually ease migration, since fewer consumers must be retested and cut over.

Web-based interface

Why it fails: A web-based interface is a migration advantage, not a legacy obstacle, because browser clients need no redistribution after the backend moves. Legacy difficulty comes from unsupported runtimes, hard-coded dependencies or tight coupling. Web interfaces would be the right answer if the question asked which characteristic simplifies cloud migration.

Global network physical cabling

Why it fails: This is the provider's responsibility.

Physical data center security

Why it fails: This is the provider's responsibility.

Lower security

Why it fails: Security is not inherently lower, just not optimized.

Increased hardware maintenance

Why it fails: Maintenance is handled by the provider.

Updating the break room menu

Why it fails: Not part of the cloud strategy.

Buying office chairs for the staff

Why it fails: Not part of the cloud strategy.

Service Level Agreement (SLA) uptime

Why it fails: SLAs relate to availability, not infrastructure cost modeling.

Return on Investment (ROI)

Why it fails: ROI is a performance metric, not a cost comparison tool for infrastructure.

Mean Time to Repair (MTTR)

Why it fails: MTTR is an operational metric, not a financial business case metric.

Amazon S3 Transfer Acceleration

Why it fails: S3 Transfer Acceleration speeds up uploads to S3 buckets by using edge locations. It does not control where data is stored or who can access it. It is a performance optimization, not a compliance feature for data residency or access restriction.

AWS Artifact

Why it fails: AWS Artifact provides on-demand access to AWS compliance reports and agreements. It helps with auditing but does not enforce data residency or access control. It is a documentation resource, not a technical control for meeting the stated requirements.

AWS Lambda functions

Why it fails: Lambda is a serverless compute service that runs code in response to events. While useful for processing, it does not enforce data residency or access control by itself. It can be part of a solution, but it does not directly satisfy the compliance requirements.

Cost of physical server hardware depreciation

Why it fails: When moving to the cloud, the company no longer purchases physical servers, so hardware depreciation is eliminated. Including it in the TCO for the cloud model would overstate costs and misrepresent the financial comparison. The goal is to compare the on-premises costs with cloud costs, and hardware depreciation is an on-premises cost that goes away.

Cost of data center cooling and power

Why it fails: Data center cooling and power are on-premises operational costs that are typically eliminated or significantly reduced when migrating to the cloud. Including them in the cloud TCO would be incorrect because the cloud provider assumes those responsibilities. The analysis should focus on costs that remain or are newly introduced.

Cost of hardware maintenance contracts

Why it fails: Hardware maintenance contracts are associated with on-premises equipment and are usually discontinued after migration. They are not a cost of the cloud model, so they should not be included in the cloud TCO. Including them would incorrectly inflate the cloud cost comparison.

Functions as a Service (FaaS)

Why it fails: FaaS, or serverless computing, executes code in response to events without managing servers. It is ideal for building microservices or event-driven applications, not for running a full CRM system. The agency would need to develop and maintain the CRM application code, which contradicts their goal of minimizing operational effort. FaaS is too low-level for their need to consume a complete application.

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 would increase the operational burden on the agency's limited IT staff. Since the agency wants to minimize infrastructure management and focus on application customization, IaaS is not the best fit; it would require them to handle patching, scaling, and other administrative tasks.

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 infrastructure. However, the agency is not developing a new application; they are using an existing CRM system. PaaS would still require them to manage the application and data, but it is more suited for custom development. For a ready-to-use CRM, a higher-level service model is more appropriate.

Negotiating a fixed monthly fee with the cloud provider

Why it fails: A fixed monthly fee would not align with the variable nature of rendering workloads. The company would either overpay during low-usage months or exceed the fee during peak periods, leading to additional charges. Fixed fees are more suitable for stable, predictable consumption. For bursty workloads, a pay-as-you-go model with cost controls is more appropriate.

Purchasing reserved instances for a three-year term

Why it fails: Reserved instances offer discounts for steady-state workloads, but they require a long-term commitment. For unpredictable rendering jobs that run only occasionally, this would lead to paying for unused capacity. The company would not achieve cost savings and might incur waste. Reserved instances are better suited for predictable, continuous workloads, not bursty rendering.

Using only spot instances for all rendering jobs

Why it fails: Spot instances can reduce costs significantly, but they can be interrupted with little notice. For rendering jobs that must complete within a deadline, interruptions could cause delays and require restarting work. While spot instances are useful for fault-tolerant batch processing, they are not suitable for all rendering tasks. A mix of instance types and a checkpointing strategy would be more appropriate.

Public cloud

Why it fails: Public cloud offers scalability and cost efficiency but may not meet the ultra-low latency requirements of high-frequency trading. Data must travel over the internet or dedicated connections to the provider's data centers, and multi-tenancy can introduce variability. While some providers offer high-performance computing instances, the specialized hardware and proximity required for trading may not be fully replicable, making public cloud a risky choice for this scenario.

Private cloud

Why it fails: Private cloud provides dedicated infrastructure and greater control, which can reduce latency compared to public cloud. However, it may not offer the same elasticity and global reach as public cloud. For high-frequency trading, the company already has specialized on-premises hardware; a private cloud would essentially replicate that environment without the benefits of cloud scalability. It does not address the need to leverage cloud benefits while maintaining performance.

Community cloud

Why it fails: Community cloud is shared by several organizations with common interests, such as regulatory compliance. While it can offer cost savings and shared management, it does not provide the dedicated, low-latency environment needed for high-frequency trading. The shared infrastructure may introduce variability and does not leverage the company's existing specialized hardware, making it unsuitable for this performance-critical application.

Community cloud

Why it fails: A community cloud is shared by several organizations with common interests and can be hosted anywhere. It does not inherently guarantee that data remains within a specific geographic region. While it may offer more control than public cloud, it does not provide the same level of assurance as a private cloud for data residency.

Hybrid cloud

Why it fails: Hybrid cloud combines on-premises and public cloud resources, which can introduce complexity in ensuring all data stays within the EU. If any part of the hybrid deployment uses public cloud outside the EU, it could violate residency requirements. Without careful architecture, hybrid cloud does not guarantee compliance.

Public cloud

Why it fails: Public cloud resources are shared among many customers and can be located in various regions worldwide. While providers offer EU regions, data could potentially be replicated or accessed from outside the EU depending on configuration. Without strict controls, public cloud may not guarantee data residency, so it is not the best choice for this strict requirement.

Internal rate of return (IRR)

Why it fails: IRR is the discount rate that makes the net present value of a project zero, used to evaluate the profitability of potential investments. It does not directly compare the total costs of two different operating models. The CFO's request for a cost comparison is best served by TCO, which enumerates all costs, whereas IRR focuses on the rate of return.

Net present value (NPV)

Why it fails: NPV calculates the present value of future cash flows minus the initial investment, which is useful for investment decisions but requires detailed cash flow projections. While NPV is valuable, it is not the primary metric for comparing the total costs of on-premises and cloud solutions. TCO provides the cost baseline that can feed into NPV analysis, but the CFO specifically asked for a cost comparison.

Return on investment (ROI)

Why it fails: ROI measures the gain or loss generated relative to the investment cost, but it is a broad metric that does not specifically capture the total cost comparison over time. While ROI is important, the CFO's request for a comparison of on-premises versus cloud costs is better addressed by TCO, which includes all direct and indirect costs. ROI can be derived from TCO but is not the primary metric for cost comparison.

Hybrid cloud

Why it fails: A hybrid cloud combines private and public cloud resources, but the public component could introduce latency and potential downtime. For a trading application that must remain on-premises or in a dedicated environment, the hybrid model adds complexity without guaranteeing the required performance. Unless the public portion is used only for non-critical workloads, it does not meet the low-latency, zero-downtime needs.

Community cloud

Why it fails: A community cloud is shared by several organizations with common interests, which can still introduce resource contention and variable latency. While it may offer some cost benefits, it does not provide the dedicated performance and control of a private cloud. For high-frequency trading, the shared nature could lead to unpredictable latency, making it unsuitable for the firm's strict requirements.

Public cloud

Why it fails: Public cloud offers scalability and cost efficiency but may introduce variable network latency due to multi-tenancy and internet routing. For high-frequency trading, even microsecond delays can impact profitability. While some public cloud providers offer low-latency options, they cannot guarantee the deterministic performance required for trading during peak hours. Therefore, public cloud is not the best fit.

Cost of physical data center security

Why it fails: Physical data center security is an on-premises cost that may be reduced or eliminated after migration, but it is not a cost incurred in the cloud. For TCO analysis, the focus should be on costs that change with the migration. Including the current security cost might be relevant for baseline comparison, but it is not a cloud migration cost per se; the question asks for factors to include in the cloud TCO, which are direct cloud expenses.

Cost of existing hardware depreciation

Why it fails: Existing hardware depreciation is a sunk cost that will continue regardless of the migration decision. While it may be relevant for accounting purposes, it should not influence the incremental TCO analysis for the cloud migration. Including it could artificially inflate the cost of the on-premises option and lead to a biased comparison, as the depreciation is not avoidable by moving to the cloud.

Cost of employee salaries for the IT department

Why it fails: Employee salaries for the IT department are generally not incremental to the migration decision; the same staff may be retained and retrained. While reskilling costs might be relevant, ongoing salaries are not a direct cost of the cloud migration itself. Including them could distort the comparison, as they are not a variable cost that changes solely due to moving to the cloud.

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.

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.

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.

PaaS

Why it fails: PaaS manages the operating system, runtime and middleware, so the customer deploys code without controlling the OS or network configuration. It is tempting because it removes patching and server maintenance, yet that managed layer is exactly the control the scenario requires, which IaaS retains.

SaaS

Why it fails: SaaS delivers finished applications, so the provider controls the operating system, runtime and network stack entirely; the customer configures only application settings. It is tempting because SaaS removes all infrastructure maintenance, but that same abstraction eliminates the OS and network control the scenario demands, which IaaS provides instead.

Serverless

Why it fails: Serverless abstracts away the operating system and network configuration entirely, so the company cannot control them, failing the stated requirement. It is tempting because it removes physical server maintenance, but it would be correct only when the company wants to deploy code without managing any infrastructure.

Moving VMs without any changes

Why it fails: Re-platform means modifying the application to exploit cloud services, such as swapping a self-managed database for a managed one — not lifting VMs unchanged. It is tempting because unchanged migration describes re-host, which is correct when speed matters and no code changes are permitted.

Replacing the application with a third-party service

Why it fails: Re-platform means migrating to a new runtime platform with minimal code change, such as moving to Azure App Service or containers. Replacing the application with a third-party SaaS product is retirement or repurchase, which discards the existing codebase entirely. It would suit a decision to drop in-house development for a commercial offering.

Complete rewrite of the application code

Why it fails: Re-platform retains the application's core code, applying targeted changes to use managed services; a complete rewrite is re-architect or refactor. It is tempting because both strategies alter code, but refactoring redesigns the application's architecture rather than adjusting it for cloud.