Cloud Concepts practice questions

Configure a NAT Gateway

Why it fails: NAT Gateway is for internal network traffic.

Attach an Elastic IP

Why it fails: Elastic IP is for EC2 instances.

Create an EC2 instance

Why it fails: EC2 is for dynamic applications.

Route Table

Why it fails: Route tables direct traffic between subnets and gateways; they contain no port or protocol fields, so a 443-only rule cannot be expressed there. Route tables are the right place for directing subnet traffic to an internet or NAT gateway.

Network ACL

Why it fails: A network ACL filters at the subnet boundary and is stateless, so it cannot enforce a rule scoped to one web server's port 443 while permitting return traffic. Network ACLs suit broad subnet-level allow or deny lists, not per-instance port control.

VPC Peering

Why it fails: VPC peering connects two VPCs so their resources can route privately; it carries no port or protocol filtering, so it cannot restrict traffic to 443. Peering is correct when two VPCs must exchange traffic over private IP addresses.

To provide a single point of failure

Why it fails: Regions aim to prevent failure.

To simplify the billing structure

Why it fails: Billing is global or service-based.

To lower the cost of hardware

Why it fails: Regions are about location, not cost.

VPC Security Groups

Why it fails: This protects network traffic.

SSL/TLS

Why it fails: This is for data in transit.

Multi-factor authentication

Why it fails: This secures user identities.

IaaS

Why it fails: IaaS is a service model.

Community Cloud

Why it fails: This is not a standard hybrid component.

Serverless

Why it fails: Serverless is a service model.

SaaS

Why it fails: SaaS requires software to be built specifically for cloud consumption, which contradicts the goal of migrating legacy applications.

PaaS

Why it fails: PaaS requires specific application frameworks and runtimes that may not support legacy binary dependencies.

Serverless

Why it fails: Serverless requires event-driven architectural changes to the application code.

Multi-Cloud

Why it fails: Multi-cloud refers to using multiple vendors, which increases complexity regarding data sovereignty.

Public Cloud

Why it fails: Public cloud providers are global, and data may traverse multiple international jurisdictions, making compliance harder to guarantee.

Hybrid Cloud

Why it fails: Hybrid models bridge public and private, but public components may still introduce data residency risks.

Configuration of customer firewall rules

Why it fails: Firewall rules are the customer's responsibility.

Management of customer guest OS

Why it fails: The guest OS is the customer's responsibility.

User access management

Why it fails: User access is the customer's responsibility.

Software as a Service (SaaS)

Why it fails: SaaS delivers a complete application managed by the provider, but it does not allow the firm's developers to write and deploy their own custom code. The scenario requires developers to write code, so SaaS is not suitable. Additionally, SaaS is multi-tenant by nature and does not provide the dedicated kernel isolation the security team demands.

Platform as a Service (PaaS)

Why it fails: PaaS abstracts away the OS, runtime, and middleware, letting developers focus on code. However, PaaS typically runs on a shared infrastructure where multiple tenants may share the same OS kernel, which violates the security team's requirement for a dedicated, isolated environment with no other tenants sharing the kernel.

Infrastructure as a Service (IaaS)

Why it fails: IaaS provides virtualized computing resources, but the customer is responsible for managing the operating system, runtime, and middleware. This does not meet the developers' desire to avoid patching those components. While IaaS can offer dedicated hosts, it still requires the customer to handle OS and runtime management, which conflicts with the requirement to focus only on code.

Broad network access

Why it fails: Broad network access describes the ability to reach cloud services over standard networks from diverse client devices. It says nothing about how consumption is priced or attributed, so it cannot deliver the per-business-unit cost visibility the finance team requires, nor does it explain how idle capacity is avoided.

Resource pooling

Why it fails: Resource pooling lets the provider serve many tenants from shared physical infrastructure, which improves provider economics but does not by itself give the retailer elastic capacity or per-unit cost reporting. It is an enabler of multi-tenancy rather than the metering mechanism the finance team needs for granular chargeback.

Rapid elasticity

Why it fails: Rapid elasticity lets the retailer scale capacity out and back quickly to match demand, which addresses the traffic spikes. However, it does not inherently provide the granular consumption data needed for per-business-unit chargeback, so it satisfies only half of the stated requirement and is not the most complete answer.

High availability

Why it fails: High availability ensures that systems remain operational despite failures, but it does not automatically scale resources up and down based on workload. While important, it does not address the need to process files only when they arrive or to minimize cost during idle periods. The company needs dynamic scaling, not just redundancy.

Multi-tenancy

Why it fails: Multi-tenancy refers to sharing underlying infrastructure among multiple customers, which can improve cost efficiency for the provider. However, it does not provide the automatic scaling or event-driven resource allocation the company needs. It is a characteristic of public clouds but not the primary mechanism for minimizing cost in this scenario.

Measured service

Why it fails: Measured service means the provider meters resource usage and bills accordingly. While it supports cost transparency, it does not automatically scale resources. The company would still need to provision and de-provision compute manually or through automation. Measured service is a billing characteristic, not a scaling mechanism, so it alone does not meet the requirement.

Availability Zone replication

Why it fails: Availability Zones sit within one region, so a regional disaster can affect every zone simultaneously. It is tempting because zone replication genuinely provides fault tolerance against a single datacentre outage, and it would be correct where the requirement is resilience to a localised failure rather than a regional one.

Load Balancer

Why it fails: A load balancer distributes traffic across healthy instances but does not place resources in separate geographic regions. It is tempting because load balancing genuinely maintains service during instance failure, and it would be correct where the requirement is distributing demand or surviving a single node outage.

Auto Scaling Group

Why it fails: Auto Scaling adjusts instance count in response to demand or health checks, all within one region. It is tempting because scaling genuinely maintains capacity during workload spikes, and it would be correct where the requirement is handling variable traffic rather than surviving a regional disaster.

Site-to-Site VPN

Why it fails: A Site-to-Site VPN traverses the public internet, failing the private-connectivity requirement. It tempts because it is quick to deploy and encrypts traffic, but encryption does not make the path private; AWS Direct Connect provides a dedicated private circuit instead.

Client VPN

Why it fails: A Client VPN tunnels a single remote device to a VPC over the public internet, so it cannot provide the private, dedicated link between an on-premises data centre and a VPC that the scenario demands. It is tempting because it does grant remote users access to VPC resources, which is its actual purpose.

Public IP peering

Why it fails: Public IP peering routes traffic over public internet exchange points, breaching the private-connectivity requirement. It tempts because peering can reduce latency and cost for public workloads, but it offers no dedicated private path; AWS Direct Connect is the private option.

Hybrid Cloud

Why it fails: Hybrid cloud combines on-premises infrastructure with public cloud, so it does not inherently deliver pay-per-use billing or multi-tenant shared hardware; those traits define public cloud. It is tempting because hybrid genuinely suits workloads needing data residency or gradual migration, where some systems must remain on-premises.

Community Cloud

Why it fails: Community cloud shares infrastructure among a limited group of organisations with common concerns, not the general public, and its cost model is not inherently pay-per-use. Public cloud is correct here: resources are metered on demand and hardware is shared across unrelated tenants.

Private Cloud

Why it fails: Private cloud dedicates infrastructure to a single organisation, so hardware is not shared with other tenants and costs are typically fixed rather than consumption-based. It suits strict regulatory or security isolation requirements, whereas this scenario describes the public cloud model.

Internet Gateway

Why it fails: An internet gateway attaches to the VPC and enables public subnets to reach the internet, but a private subnet requires a NAT gateway for outbound traffic instead. It is tempting because the gateway is genuinely the egress component, and would be correct if the subnet were public and hosted the instance directly.

VPC Endpoint

Why it fails: A VPC endpoint connects privately to specific AWS services, not the public internet, so it cannot serve the general update download described. It is tempting because endpoints do provide private-subnet connectivity, and would be correct if the application needed to reach S3 or DynamoDB without traversing the internet.

Route Table

Why it fails: A route table already exists in every subnet; the missing element is the route entry directing 0.0.0.0/0 traffic to a NAT gateway or internet gateway. It is tempting because routing is genuinely required for egress, and a misconfigured route table would be the correct diagnosis if routes were absent.

Increased control over hardware

Why it fails: Cloud consumption reduces direct control over hardware, since the provider owns and manages the physical estate; the shift moves control away from the customer. It tempts because on-premises CapEx does grant hardware control, and would be correct if the question asked which model gives greater physical infrastructure ownership.

Predictable monthly billing

Why it fails: Predictable monthly billing is a consequence of subscription pricing, not the primary benefit of shifting spend from capital to operating expenditure; the stem asks for the defining advantage. It tempts because OpEx billing is genuinely recurring, and would be correct if the question asked how cloud providers structure payment schedules.

No hardware maintenance

Why it fails: Hardware maintenance transfers to the cloud provider under OpEx, but that is an operational consequence rather than the primary financial benefit the stem seeks. It tempts because removing maintenance overhead is a real cloud advantage, and would be correct if the question asked about operational responsibilities rather than expenditure models.

Cold Storage

Why it fails: Cold storage tiers are archival, with retrieval times measured in minutes or hours, so they cannot meet a live database's low-latency, high-IOPS requirement. It is tempting because it is the correct choice for long-term retention of infrequently accessed backups or compliance archives.

Magnetic HDD

Why it fails: Magnetic HDDs rely on spinning platters and mechanical heads, capping IOPS far below what a demanding database needs and adding rotational latency. It is tempting because HDDs remain the correct choice for bulk capacity, sequential workloads and cost-sensitive archival storage.

Object Storage

Why it fails: Object storage is accessed via HTTP APIs with eventual consistency and high per-request latency, so it cannot deliver the low-latency, high-IOPS block access a database demands. It is tempting because it suits static assets, backups and unstructured data at scale, where throughput matters more than IOPS.

Resource pooling

Why it fails: Resource pooling shares physical compute across tenants; it does not itself add or remove capacity on demand. It is tempting because multi-tenancy underpins cloud economics, and it would be the answer if the question asked how providers serve many customers from shared hardware rather than how elasticity is achieved.

Broad network access

Why it fails: Broad network access means services are reachable over standard networks from diverse client devices; it says nothing about adding or removing capacity. It is tempting because elasticity requires network reachability, and it would be correct if the question asked how cloud services are accessed from anywhere rather than how resources scale.

Measured service

Why it fails: Measured service meters and bills consumption per unit; metering records usage but does not provision or release it. It is tempting because pay-per-use correlates with scaling, and it would be correct if the question asked how cloud consumption is tracked, billed or charged back rather than how capacity expands and contracts.

Data Warehouse

Why it fails: A data warehouse stores structured, schema-on-write data for analytical queries, not schema-less documents, and scales through MPP clusters rather than horizontal write distribution. It tempts because it handles large volumes; it would be correct when the workload is BI reporting over structured historical data.

In-memory Database

Why it fails: In-memory databases hold data in RAM for microsecond reads, but they still impose a schema and scale vertically by adding memory, not by sharding unstructured documents. They tempt because they handle high throughput; they would be correct for caching or session stores needing sub-millisecond latency.

Relational Database

Why it fails: Relational databases enforce a fixed schema with typed columns and scale vertically via larger instances, so they cannot store schema-less documents or shard horizontally without manual partitioning. They tempt because they suit transactional, structured workloads with joins; that is the correct choice when data is tabular and ACID compliance matters.

Local area networking

Why it fails: Local area networking describes on-premises connectivity, not the multi-tenant resource pooling that defines cloud computing's shared-resource benefit. It is tempting because LANs remain the correct choice when workloads must stay on-site for latency, compliance or legacy integration reasons.

Static provisioning

Why it fails: Static provisioning fixes capacity in advance, so it cannot deliver the elasticity and pooled multi-tenant resource sharing the question describes. It is tempting because it suits predictable, steady workloads where reserved capacity guarantees consistent performance without scaling overhead.

Dedicated hosting

Why it fails: Dedicated hosting gives one customer sole use of the hardware, so resources are not pooled across customers at all. It tempts because it offers isolation and control, and it would be correct when compliance or performance requirements demand single-tenant infrastructure.