Select Two (Multi-Select) Questions

Total control over the physical data center power grid

Why it fails: Community cloud members share the provider's data centre and still rely on its power infrastructure, so no member gains control over the power grid. It is tempting because community clouds offer greater governance than public ones, but that governance covers policy and workloads, not physical utility supply.

Unlimited access to all global regions

Why it fails: Community clouds are built from shared infrastructure serving a defined group, so they inherit the same regional footprint constraints as the underlying provider and grant no broader geographic access. It is tempting because public hyperscalers advertise extensive global regions, but community deployments typically span fewer locations, not more.

Lower initial setup cost than public cloud

Why it fails: Community cloud setup costs are typically higher, since members fund shared infrastructure rather than consuming a provider's existing multi-tenant capacity. It is tempting because sharing costs among a known group sounds cheaper than public cloud, yet the economics favour public providers' massive scale, not smaller community builds.

Bare Metal

Why it fails: Requires full hardware-level control.

IaaS

Why it fails: Requires full OS/server management.

SaaS

Why it fails: Provides a finished application, not a deployment environment.

The provider's data center locations and their proximity to the company's offices.

Why it fails: Data center locations affect latency and data residency, but they are not typically part of the SLA. The SLA defines service level commitments, not geographic details. While important for architecture, location is a separate design consideration and not a core SLA evaluation factor.

The provider's process for handling customer support tickets.

Why it fails: Support processes are important but typically covered in a separate support plan, not the SLA. The SLA focuses on measurable service levels like uptime, latency, and remedies. While support responsiveness may be included in some SLAs, it is not one of the two most fundamental factors for evaluating availability and performance guarantees.

The maximum number of virtual machines the company can deploy.

Why it fails: Service limits and quotas are important for capacity planning, but they are usually documented in service limits, not the SLA. The SLA focuses on performance and availability guarantees. The number of VMs is a scalability consideration, not a service level commitment, so it is not a key SLA evaluation factor.

Employee training manuals

Why it fails: Employee training manuals are awareness material, not incident-specific procedures such as roles, escalation paths, containment steps and communication plans. They are tempting because training documentation is a real part of a security programme, and would be correct when addressing ongoing security awareness rather than response planning.

Budget approval workflows

Why it fails: Budget approval workflows govern financial authorisation, not detection, containment, eradication, recovery or post-incident review, so they contribute nothing during an active incident. They are tempting because they belong in financial governance and change-management documentation, where spend sign-off genuinely matters.

Use a content delivery network to cache dynamic API responses at edge locations.

Why it fails: Content delivery networks excel at caching static assets, but caching dynamic API responses for a trading application risks serving stale prices and can violate consistency requirements. While edge presence reduces latency for cacheable content, it does not address the need for real-time, consistent transaction processing across regions.

Increase the size of the database instance to handle more concurrent connections.

Why it fails: Vertical scaling improves throughput and connection capacity but does not reduce network round-trip time between distributed users and the application. A larger database in one location still forces remote users to traverse long network paths, so this does not address the latency requirement or provide regional fault tolerance.

Consolidate all application instances into a single region with the lowest average latency to all users.

Why it fails: A single region cannot be closest to users spread across multiple continents, so many users would experience higher latency. It also creates a single point of failure, undermining the high availability requirement. Consolidation reduces operational complexity but directly conflicts with the latency and resilience goals of this scenario.

A physical server monitoring camera

Why it fails: A physical server monitoring camera captures video of hardware; it produces no billing, usage or tagging data, so it cannot attribute or constrain cloud spend. It tempts because on-premises monitoring feels like governance, but cost control requires tools such as Microsoft Cost Management, budgets and tagging policies that read resource consumption.

The company's external marketing agency

Why it fails: An external marketing agency is a third-party service provider, not a management tool, and holds no access to cloud billing or resource metadata. It tempts because agencies often manage cloud-hosted campaigns, but cost control needs native instruments like Microsoft Cost Management, budgets, alerts and resource tagging that query actual consumption data.

Ignoring one cloud provider

Why it fails: Deliberately ignoring one provider leaves that environment unmonitored, ungoverned and outside cost and security controls, defeating multi-cloud management. It is tempting as a simplification when one provider dominates, but effective management requires consistent policy, visibility and governance across every provider in use.

Printing physical logs

Why it fails: Physical printouts cannot be aggregated, queried or correlated across providers, so they cannot support multi-cloud monitoring or cost analysis. Printing logs is tempting where hard-copy audit trails are mandated, but effective multi-cloud management requires centralised, machine-readable telemetry and unified logging.

The provider's quarterly stock earnings report

Why it fails: Earnings reports disclose revenue, margins and shareholder returns, not control environments or uptime commitments. They are tempting because they are public and quantify financial stability, which matters when assessing vendor viability, but reliability and security posture are evidenced by audit reports such as SOC 2 and ISO 27001 certifications.

Employee payroll records

Why it fails: Payroll records expose employee compensation, not the controls protecting customer data or service availability. They are tempting because staff vetting and personnel screening support physical and operational security, but that evidence appears in audit attestations and certification reports, not in individual remuneration data.

Internal office floor plans

Why it fails: Floor plans show physical layout, not logical access controls, encryption or availability guarantees. They are tempting because physical security is a genuine component of a CSP assessment, and building layouts would inform a data centre site inspection, but the question asks for business-focused documentation evidencing reliability and security posture.

Server-side encryption at rest

Why it fails: Server-side encryption at rest protects stored data on disk, not data moving across networks, so it cannot satisfy a data-in-transit requirement. It is tempting because it is a core cloud encryption control, and it would be the right answer if the question asked how to protect data at rest in storage.

User access logs

Why it fails: Access logs record who accessed what after the fact; they do not encrypt or protect data moving across networks. It tempts because logging supports security monitoring, and would be correct for auditing or forensic investigation, not for securing data in transit, which requires TLS or IPsec.

Static hardware provisioning

Why it fails: Cloud computing requires rapid elasticity and on-demand self-service, so capacity is provisioned dynamically in response to demand; static hardware provisioning describes traditional on-premises infrastructure. It is tempting because reserved instances and dedicated hosts involve committed capacity, yet even those remain software-provisioned and elastically adjustable rather than fixed hardware.

Physical media access

Why it fails: Cloud characteristics are on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service; physical media access contradicts broad network access, since consumers reach services over the network rather than handling media. It is tempting because providers do use physical media internally for backup and transport, but that is invisible to consumers.

Patching the hypervisor that hosts virtual machines

Why it fails: Patching the hypervisor is typically the cloud provider's responsibility in a public cloud IaaS model. The provider manages the physical infrastructure and virtualization layer, while the customer is responsible for the guest operating system and applications. Therefore, this is not a customer responsibility.

Managing the lifecycle of encryption keys stored in a hardware security module (HSM)

Why it fails: While customers can manage their own keys, the responsibility depends on the service model. In many cloud services, the provider manages the HSM and key lifecycle if using provider-managed keys. However, even with customer-managed keys, the provider secures the HSM hardware. This is not a universal customer responsibility under the shared responsibility model, and the question asks for customer responsibilities in a public cloud context.

Ensuring physical security of data center facilities

Why it fails: Physical security of data centers is always the cloud provider's responsibility. The provider controls access, surveillance, and environmental controls. Customers do not have physical access to these facilities, so they cannot be responsible for this aspect of security.

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.

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.

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.

Availability of free trial gifts

Why it fails: Free trial gifts are a promotional incentive, not an evaluation criterion; enterprise selection weighs service-level agreements, compliance certifications, security controls and exit provisions. Trials are tempting because they let teams test a platform cheaply, but they say nothing about production reliability, contractual guarantees or regulatory fit.

The number of employees at the cloud company

Why it fails: Headcount does not determine whether a provider meets an enterprise's requirements; assessments centre on SLA commitments, security certifications, data residency and support responsiveness. Company size is tempting as a rough proxy for stability, but staffing levels reveal nothing about contractual guarantees or compliance posture.

The physical location of the cloud company's headquarters

Why it fails: Headquarters location does not establish where data is stored or processed; data residency, jurisdiction and compliance certifications govern that. It is tempting because geography feels relevant to sovereignty, but a provider may host in many regions, so the contractual data-residency terms matter, not the corporate address.

Ability to modify the database source code

Why it fails: Managed database services abstract the engine, so customers cannot alter source code; only self-hosted or open-source deployments permit that. It tempts because some providers expose engine parameters and extensions, which would be the correct choice when a team needs custom engine behaviour not offered by the managed platform.

Lower network latency

Why it fails: Cloud databases sit behind the provider's network, so latency depends on the client's distance and routing; self-managed databases can be colocated with the application. It tempts because providers offer regions and edge caching, which would be the correct choice for globally distributed read-heavy workloads needing local proximity.

Unlimited database schema design control

Why it fails: Managed services constrain schema through supported engines and migration tooling, so unlimited design control is not a benefit; self-managed databases grant that. It tempts because providers allow schema changes via standard SQL, which would be the correct choice when a workload demands non-standard storage engines or bespoke indexing.

Installing OS patches

Why it fails: This is a technical implementation task.

Managing individual virtual machine performance

Why it fails: Tuning individual VM performance is day-to-day operations handled by operations or platform engineers, whereas governance sets policy, guardrails and accountability. It is tempting because governance defines performance and availability objectives, but remediating a specific VM is execution, not committee-level oversight.

Writing application source code

Why it fails: Source code authorship belongs to development teams; a governance committee sets policy, standards and controls rather than producing application code. It is tempting because governance approves development standards and tooling, but writing the code itself is delivery work outside its remit.

Hiring software developers

Why it fails: A CCoE provides governance, standards, best practices and enablement for cloud adoption; it is not a recruitment function. It is tempting because skilled staff underpin cloud delivery, but hiring developers is a line-management activity, not a reason to establish a CCoE.

Managing local desktop hardware

Why it fails: A CCoE governs cloud adoption through standards, guardrails and enablement; it holds no remit over physical desktop hardware, which endpoint management tools handle. It is tempting because the CCoE does define client-access policies, but that is governance of cloud access, not local device maintenance, so it cannot be a valid reason here.

Increasing the speed of physical repairs

Why it fails: IaC provisions and configures cloud or virtual resources; it has no bearing on physical hardware repair, which is a facilities and maintenance activity. It is tempting because IaC accelerates recovery by rebuilding environments, but that is logical redeployment, not shortening the time to fix physical equipment.

Automatically detecting insider threats

Why it fails: IaC enforces configuration consistency and drift detection; identifying malicious user behaviour requires runtime monitoring and behavioural analytics, which templates cannot provide. It is tempting because IaC supports detective controls, but insider threat detection depends on log correlation and anomaly analysis, not provisioning code.

Reducing the number of cloud regions

Why it fails: IaC governs how infrastructure is defined and deployed; it neither adds nor removes cloud regions, which is a separate architectural and data-residency decision. It is tempting because region selection is expressed in templates, but consolidating regions is a design choice, not a compliance benefit of declarative provisioning.

Salaries for IT staff who manage the cloud infrastructure

Why it fails: While some infrastructure management tasks shift to the provider, the company still needs IT staff to manage its cloud resources, applications, and security. The cloud does not eliminate the need for skilled personnel; it changes their focus. Salaries are not eliminated, and in some cases, new skills may be required. Thus, this is not a cost that is typically reduced in the way the CFO might hope.

Costs for application licensing

Why it fails: Application licensing costs generally remain the customer's responsibility, even in the cloud. While some licenses may be included with SaaS, the scenario involves moving existing applications, so the company would still need to pay for its software licenses. The cloud provider does not typically absorb these costs. Therefore, this is not a cost factor that is eliminated.

Costs associated with data egress

Why it fails: Data egress costs are actually a new or increased expense in the cloud. Providers often charge for data transferred out of their network, which can be significant for data-intensive applications. This is not a cost that is eliminated; it is a cost that must be managed. Therefore, it does not fit the CFO's goal of reducing costs.

Reducing cloud costs by automatically shutting down all non-production resources

Why it fails: Cost optimization is a component of governance, but automatically shutting down all non-production resources is a specific tactical action, not a primary objective. Governance provides a framework for cost management, but it does not mandate such a blanket action. This option is too narrow and prescriptive to be a primary objective.

Eliminating all security risks associated with cloud computing

Why it fails: No framework can eliminate all security risks. Governance aims to manage and mitigate risks to an acceptable level, not eliminate them entirely. Claiming to eliminate all risks is unrealistic and not a primary objective. Governance focuses on risk management, not risk eradication.

Maximizing the number of cloud services used to increase flexibility

Why it fails: Governance is about controlled and compliant use of cloud services, not maximizing their number. Using more services can increase complexity and risk. The objective is to enable business agility within guardrails, not to proliferate services. Therefore, this is not a primary objective of governance.

Purchasing new hardware for the data center

Why it fails: Cloud incident response covers detection, containment, eradication, recovery and post-incident review using existing provider resources; hardware procurement is not a response step. It is tempting because on-premises recovery may need replacement kit, but cloud elasticity removes that dependency from the process.

Notifying the cloud provider's sales team

Why it fails: Incident response requires notifying the provider's support or security contact per the shared responsibility model, not its sales team. Sales notification is tempting because account contacts are familiar, but only support channels can action incidents, and sales plays no role in containment or recovery.

Updating the company's social media

Why it fails: Incident response steps are technical and procedural, such as containment and evidence preservation; social media updates are communications handled separately. It is tempting because public disclosure matters in a breach, but posting is not a defined response step and could prejudice the investigation.