Cloud Concepts practice questions

Elasticity

Why wrong: Elasticity is incorrect for this scenario because elasticity refers to automatically scaling computing capacity up or down in response to changing demand, such as adding EC2 instances during a traffic spike and removing them when traffic recedes. The question focuses on maintaining operation when an Availability Zone fails, not on adjusting capacity to match load. An elastic design—for example, with EC2 Auto Scaling and Application Load Balancing—would help handle variable traffic, but it does not, by itself, make the application resilient to an AZ loss unless that scaling is paired with Multi-AZ redundancy and other high-availability patterns.

High availability

Why wrong: High availability is the correct answer because the scenario describes a critical e-commerce application that must keep operating even if an entire Availability Zone fails. By running the application redundantly across multiple AWS Availability Zones, you can design the system to absorb an AZ outage and continue serving customers, which is precisely what the Well-Architected Framework defines as high availability. While failover may involve a brief interruption (e.g., a DNS TTL or health-check delay), the overall system remains available, which is the key on-demand characteristic in this context.

Scalability

Why wrong: Scalability is incorrect because scalability is the ability to increase system capacity to handle growth in load, either by resizing instances (vertical scaling) or by adding more instances (horizontal scaling). The scenario does not mention growing traffic, peak seasons, or demand fluctuations; it describes a failure event in one or more Availability Zones. Maintaining service during an infrastructure failure is a matter of redundancy and failover, not adding capacity to handle more load. While scaling is an important AWS architecture consideration, it does not address the specific fault-tolerance scenario described in the question.

Rapid elasticity

Why wrong: Rapid elasticity is the ability to automatically and quickly scale cloud resources up or down in response to changing demand, for instance by using EC2 Auto Scaling or managed scaling policies. The scenario says that the application runs on multiple AWS services and is accessed remotely, but it never mentions traffic patterns, load spikes, or dynamic capacity adjustments. Even though the underlying infrastructure could be elastic, the scenario simply demonstrates remote network access rather than any scaling behavior, so rapid elasticity is incorrect.

Resource pooling

Why wrong: Resource pooling describes the provider's multi-tenant model in which physical and virtual computing resources are pooled and dynamically assigned to multiple customers based on demand. The scenario focuses on how users access the application across the network, not on how the infrastructure is shared among tenants or allocated under the hood. Without any mention of shared hardware, multi-tenancy, or provider-side resource allocation, resource pooling is not the characteristic evidenced here.

Measured service

Why wrong: Measured service is a cloud characteristic centered on metering and usage-based billing: AWS tracks the amount of compute, storage, and network bandwidth each customer consumes and bills accordingly. The scenario only describes that the application is accessible via web browsers and APIs over the internet, which relates to connectivity and protocols, not to usage tracking. Because no billing, monitoring, or pay-as-you-go details are present, measured service is not the characteristic the scenario is illustrating.

Design for failure

Why wrong: Design for failure is a core Reliability pillar principle that emphasizes building architectures resilient to component failures, such as using Multi-AZ deployments, auto scaling, and health checks. While this reduces downtime risk, it focuses on fault tolerance and recovery, not on offloading the undifferentiated infrastructure tasks like patching, backups, or capacity management. Thus, it addresses architectural resilience, not the operational burden reduction that the question targets.

Implement least-privilege access controls

Why wrong: Implementing least-privilege access controls is a Security pillar best practice that limits IAM users, roles, and resources to only the permissions required for their tasks. While this is crucial for minimizing security risk, it is about identity and access management, not about reducing the workload of managing servers, databases, or other infrastructure components. It does not offload operational tasks; it merely constrains who can perform them.

Automate infrastructure provisioning

Why wrong: Automating infrastructure provisioning with tools like AWS CloudFormation or Terraform reduces manual effort and improves consistency, but it still requires your team to design, write, and maintain the infrastructure code itself. Unlike managed services, which offload the entire underlying infrastructure to AWS, automation merely accelerates the same undifferentiated work—it does not eliminate it. As such, it improves operational efficiency but falls short of the broader goal of removing infrastructure toil altogether.

Step 1: Create the IAM user. Step 2: Enable programmatic access (generate access keys). Step 3: Attach a policy to the user. Step 4: Securely store the access key ID and secret access key.

Why wrong: This is the correct order because in the AWS IAM console, you first create the user, then select programmatic access to generate access keys, attach policies (or add to groups) to grant permissions, and finally securely store the credentials after the user is created.

Step 1: Enable programmatic access (generate access keys). Step 2: Create the IAM user. Step 3: Attach a policy to the user. Step 4: Securely store the access key ID and secret access key.

Why wrong: Placing access-key generation before user creation is invalid in IAM because access keys are cryptographic credentials bound to a specific IAM principal. Until the user exists, there is no principal to own the keys, and the CreateAccessKey API call will fail. In the console, the wizard only surfaces access keys after you define the user and select 'Programmatic access' on the first screen.

Step 1: Enable programmatic access (generate access keys). Step 2: Attach a policy to the user. Step 3: Create the IAM user. Step 4: Securely store the access key ID and secret access key.

Why wrong: Attempting to generate access keys and attach a policy before the user exists violates two IAM prerequisites: CreateAccessKey requires an existing user name, and AttachUserPolicy requires both the policy and the user to exist to establish the permission relationship. The order also skips the wizard's required permission step after identity creation; without a principal, both operations are impossible. Functional credentials and permissions cannot be provisioned in a vacuum.

1. Check system logs (e.g., cloud-init output). 2. Check security group inbound rules. 3. Check network ACL. 4. Verify the instance has a public IP.

Why wrong: This is incorrect because system logs should be checked only after verifying network-level configurations; also, verifying public IP should be one of the first steps, not last.

1. Check network ACL. 2. Check security group inbound rules. 3. Check route table. 4. Verify the instance has a public IP.

Why wrong: This is incorrect because network ACLs are evaluated after security groups for inbound traffic; security groups should be checked first. Also, public IP should be verified early.

1. Check security group inbound rules. 2. Check route table. 3. Check network ACL. 4. Check system logs.

Why wrong: This is incorrect because route table should be checked after network ACL, and system logs are a last resort after verifying network path; also missing public IP check.

Ensuring the physical security of AWS data centers

Why wrong: Ensuring the physical security of AWS data centers is wholly AWS's responsibility under the shared responsibility model. This includes perimeter fencing, biometric access controls, 24/7 security personnel, video surveillance, and environmental systems. A customer migrating on-premises applications has no visibility into or control over these physical controls, so this task cannot be performed by the customer. Even if the customer previously managed physical security for its own data center, AWS handles all physical security once workloads run in the cloud.

Patching the hypervisor layer that runs Amazon EC2 instances

Why wrong: The hypervisor layer that runs Amazon EC2 instances is fully managed and patched by AWS because the hypervisor is part of the virtualization infrastructure that AWS controls. Customers are only responsible for patching the guest operating system and applications inside their instances, such as applying updates to Linux or Windows within the guest OS. AWS applies hypervisor security updates and often live-migrates running instances to avoid downtime during maintenance. Therefore, a customer migrating from on-premises virtualization environments must adapt to this division of responsibility but never patches AWS's hypervisor.

Replacing defective hardware components in the AWS global infrastructure

Why wrong: Replacing defective hardware components in the AWS global infrastructure is a maintenance task owned entirely by AWS as part of the 'security of the cloud.' This spans failed hard drives, faulty network switches, and degraded memory modules inside AWS data centers. Customers never touch or manage the underlying hardware; they interact only with virtualized resources such as Amazon EC2 instances, which AWS automatically migrates off failing hosts. Thus, although a customer may have replaced server hardware on premises, that responsibility does not transfer to the cloud.

Scalability

Why wrong: Scalability generally refers to the ability to increase or decrease resources, but it can be manual or automated. The question specifies 'automatically adjust resources without manual intervention,' which is the defining feature of elasticity, not scalability alone.

High availability

Why wrong: High availability is about maximizing uptime by eliminating single points of failure, typically through redundant components across multiple Availability Zones. While it ensures the application remains reachable if a server fails, it does not automatically adjust capacity to accommodate sudden traffic increases. In this scenario, even a highly available deployment would require manual scaling or pre-provisioned excess capacity to handle surges. Therefore, high availability addresses resilience, not the automatic resource adjustment described.

Durability

Why wrong: Durability refers to the long-term persistence and integrity of data, ensuring that stored data is not lost or corrupted over time, often through replication and backup mechanisms like Amazon S3's 99.999999999% durability. This is a storage-level guarantee and is completely unrelated to the compute capacity or scaling behavior of an application. The problem statement focuses on handling variable traffic loads, not data protection, so durability does not apply to the requirement. In short, durability is about data survival, not resource elasticity.

Elasticity

Why wrong: Elasticity is the ability of a cloud system to automatically scale computing capacity up or down in response to changing demand, typically implemented with services like Amazon EC2 Auto Scaling. It matches the number of running resources to the current workload, so you pay for exactly what you need and can handle traffic spikes by adding instances. However, elasticity alone does not guarantee that those instances are distributed across multiple Availability Zones, nor does it provide any mechanism to maintain service if an entire zone fails. A single-AZ deployment with elastic scaling still has a single point of failure, so elasticity is concerned with capacity alignment, not continuous availability during a data center outage.

Scalability

Why wrong: Scalability is the ability of a system to support increasing workloads by adding resources, either through vertical scaling (larger instances) or horizontal scaling (more instances). It focuses on performance and throughput under load, ensuring the application can grow without degrading responsiveness. But scalability does not inherently include redundancy or failover; a scalable system could run on one large instance or a set of instances all placed in the same Availability Zone, and it would still go down if that zone fails. Thus scalability is about managing growth, not about surviving component failure, making it incorrect for this question because it lacks the fault-tolerant characteristics needed for uninterrupted operation.

Resource pooling

Why wrong: Resource pooling is a foundational characteristic of cloud computing where the provider's physical and virtual resources are dynamically assigned and reassigned among multiple customers, enabling multi-tenancy and cost efficiency. It is about how the cloud shares infrastructure, not about how an individual workload survives component failures. Even if resources are pooled across many customers, a single Availability Zone outage can still take down every instance running in that zone, because pooling provides no mechanism for detecting a failure or redirecting traffic. Therefore, resource pooling is incorrect because it addresses the provider's operational model, not the application's resilience to an Availability Zone failure.

On-demand self-service

Why wrong: On-demand self-service describes the ability of a customer to unilaterally provision computing resources, such as instances or storage, through a web console or API without requiring manual approval or intervention from the provider. This characteristic is about the automation and speed of service delivery, rather than the physical sharing or isolation of servers. Because users can provision resources instantly without human interaction, it may superficially suggest dedicated hardware, but those resources are still drawn from a common pool shared by many tenants, which does not address the CIO's security concerns about multi-tenant hardware.

Measured service

Why wrong: Measured service is the cloud attribute that automatically controls and optimizes resource usage by applying a metering capability at an appropriate level of abstraction, such as compute hours, storage capacity, or data transfer. This telemetry enables pay-as-you-go billing, cost allocation, and capacity planning, allowing customers to pay only for what they consume. While measured service implies efficient utilization across the provider's infrastructure, it does not explain the multi-tenant pooling of physical hardware, nor does it speak to the data isolation mechanisms that would reassure the CIO about sharing servers with other companies.

Broad network access

Why wrong: Broad network access is a cloud characteristic describing how services are made available over the network through standard protocols and supported by heterogeneous client platforms such as laptops, smartphones, and workstations. This attribute centers on the reachability and ubiquity of cloud endpoints, not on the underlying multi-tenant architecture. The CIO's concern about shared physical hardware pertains to resource pooling, where AWS consolidates compute capacity across customers with strong isolation controls; broad network access says nothing about how or with whom the hardware is shared.

Availability Zones

Why wrong: Availability Zones are physically separate data centers within an AWS Region. While they provide high availability, they do not offer a way to choose a different country or legal jurisdiction; they are part of the Region you select. Therefore, they are not the primary element to evaluate for data residency.

Edge Locations

Why wrong: Edge Locations are endpoints used by AWS services like Amazon CloudFront to cache content closer to users. They do not run customer workloads or store primary data, so they are not suitable for meeting data residency requirements for compute and storage.

Local Zones

Why wrong: Local Zones extend an existing AWS Region and are designed for low-latency applications. They are still within the same country as the parent Region, so they do not provide an additional option for changing data location. The Region selection is the primary factor for data residency.

Elasticity

Why wrong: Elasticity is the ability of a cloud system to automatically scale computing resources up or down based on real-time demand. While this can indirectly reduce waste and thus lower costs, it does not describe the financial mechanism of shifting from capital expenditure (purchasing hardware) to operational expenditure (paying for usage). The finance department's goal to avoid large upfront purchases is a pricing-model concern, not a scalability feature.

Economies of scale

Why wrong: Economies of scale refer to the cost advantages that AWS passes on to customers due to its massive infrastructure. This is a benefit of AWS pricing, but it does not specifically describe eliminating upfront capital investment in favor of variable monthly payments.

High availability

Why wrong: High availability ensures that applications remain operational and accessible even when failures occur, typically achieved through redundant infrastructure, load balancing, and multi-AZ deployments. This is a reliability and fault-tolerance design principle, not a cost-structure attribute. It does not affect how AWS bills customers or whether an organization makes an upfront capital investment versus a variable monthly payment.

On-demand self-service

Why wrong: On-demand self-service is a cloud characteristic that lets users unilaterally provision computing resources, such as storage or virtual machines, through a web portal or API without requiring manual approval from the provider. While this enables rapid setup and scaling, it is solely concerned with the provisioning workflow and the elimination of human interaction, not with how those resources are reached. The scenario specifically demands accessibility from diverse client devices, such as mobile phones, laptops, and workstations, which is the domain of broad network access rather than self-service provisioning.

Resource pooling

Why wrong: Resource pooling refers to the provider's computing resources being pooled to serve multiple customers using a multi-tenant model, with physical and virtual resources dynamically assigned according to consumer demand. It does not relate to device accessibility.

Measured service

Why wrong: Measured service means that cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service. It is about monitoring and billing, not about multi-device access.

Scalability

Why wrong: Incorrect. While scalability involves the ability to increase capacity to handle growth, it does not inherently require automatic scaling down. The scenario specifically requires automatic removal of resources when traffic decreases, which is a key aspect of elasticity rather than scalability alone.

High availability

Why wrong: High availability is incorrect because it refers to designing workloads to remain operational and accessible despite component failures, typically achieved through redundancy across multiple Availability Zones and automatic failover mechanisms. While the auto-scaling group may span AZs to maintain availability, the core behavior in this scenario is the dynamic addition and removal of EC2 instances in response to fluctuating traffic during flash sales. That capacity adjustment is the defining characteristic of elasticity, not high availability, which does not inherently involve scaling resources up or down based on demand.

Fault tolerance

Why wrong: Incorrect. Fault tolerance is the ability of a system to continue operating even when one or more of its components fail. The scenario does not describe failure recovery, but rather the scaling of resources to match fluctuating demand.

High availability

Why wrong: High availability refers to systems that are designed to remain operational even when individual components fail, typically through redundancy across multiple Availability Zones. While AWS offers high availability, the scenario specifically highlights cost advantages from large-scale purchasing, not system uptime.

Elasticity

Why wrong: Elasticity is the ability to automatically scale resources up or down based on demand. Although AWS provides elasticity, the scenario focuses on the cost reduction arising from AWS's large-scale operations, not on the ability to adjust resource capacity dynamically.

Fault tolerance

Why wrong: Fault tolerance is the ability of a system to continue operating without interruption when one or more components fail. While AWS provides fault-tolerant services, the scenario does not discuss system resilience or failure handling; it centers on cost advantages from scale.

Public cloud

Why wrong: A public cloud deployment means all infrastructure is hosted by a third-party provider (like AWS) and accessible over the internet. In this scenario, the company retains data on-premises, so it is not a purely public cloud model.

Private cloud

Why wrong: A private cloud deployment dedicates the entire infrastructure stack to a single organization, typically hosted on-premises or in a separate, isolated environment, offering maximum control and compliance. In this scenario, the company uses AWS's public cloud platform for analytics, which means the infrastructure is not exclusively private. Since the workload is split between on-premises storage and AWS services, the environment is a hybrid model rather than a purely private cloud.

Community cloud

Why wrong: A community cloud is shared by several organizations with similar compliance or security concerns, often managed by a third party. This scenario involves only one company using a mix of on-premises and public cloud, not a shared community infrastructure.

Resource pooling

Why wrong: Resource pooling describes how the provider's resources are shared across multiple customers, providing location independence and economies of scale. The scenario does not involve multi-tenancy or location independence; it focuses on the developer's ability to provision resources without human intervention.

Measured service

Why wrong: Measured service means that cloud systems automatically control and optimize resource use by leveraging a metering capability (e.g., pay-per-use billing). While AWS does provide measured service, this scenario is about the initial provisioning, not about usage tracking or billing.

Rapid elasticity

Why wrong: Rapid elasticity is the ability to scale resources up and down quickly in response to demand. The scenario describes a one-time provisioning of a test environment, not scaling based on fluctuating demand, so it does not best fit rapid elasticity.

Elasticity

Why wrong: Elasticity refers to the ability to automatically scale computing resources up or down based on demand. While the platform may also be elastic, the core requirement described is about surviving a failure with zero interruption, not about scaling.

High availability

Why wrong: High availability typically involves redundant components and automatic failover, but it generally allows for a short period of downtime (seconds or minutes) during the failover process. The scenario explicitly states 'zero downtime,' which is a more stringent requirement that aligns with fault tolerance.

Durability

Why wrong: Durability refers to the long-term protection of data from loss or corruption, often associated with storage services like Amazon S3 (e.g., 99.999999999% durability). It is not related to application uptime or continued processing during an infrastructure failure.

Scalability

Why wrong: Scalability is a valid cloud characteristic, but it is not the benefit this scenario illustrates. The scenario describes a company shifting from purchasing physical servers upfront—a capital expense—to paying a monthly fee based on actual usage, which is an operational expense. Scalability specifically refers to the ability to increase or decrease resources (such as adding EC2 instances or RDS read replicas) in response to changing demand, often automatically through Auto Scaling or manually. The question is not about handling variable workload size; it is about the financial accounting treatment of IT costs, so scalability is a distractor that conflates capacity planning with cost structure.

Elasticity

Why wrong: Elasticity refers to automatically provisioning and de-provisioning resources in response to load changes. While AWS offers elasticity, the primary benefit described in the scenario is the elimination of large upfront capital purchases in favor of variable monthly payments.

Economies of scale

Why wrong: Economies of scale means AWS can achieve lower per-unit costs by aggregating usage across many customers and passing those savings along. The scenario does not mention cost savings from AWS’s scale; instead, it highlights the change in how costs are incurred (upfront vs. monthly).

On-demand self-service

Why wrong: On-demand self-service refers to a consumer being able to unilaterally provision computing capabilities, such as server time and network storage, without requiring human interaction with the service provider. While AWS does support on-demand self-service, the scenario focuses on the shared physical infrastructure and lack of knowledge about the underlying server, not on the self-service provisioning process.

Rapid elasticity

Why wrong: Rapid elasticity involves the ability to quickly scale resources up or down in response to demand. The scenario does not describe any scaling activity or dynamic adjustment of capacity; it only addresses the multi-tenant nature of physical hardware. Therefore, rapid elasticity is not the best fit.

Measured service

Why wrong: Measured service means that cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth). While AWS does provide measured service, the scenario does not involve metering or pay-per-use aspects; it centers on shared physical infrastructure.

High availability

Why wrong: High availability focuses on ensuring that an application remains operational and accessible during component failures, typically by distributing workloads across multiple Availability Zones. While Auto Scaling can contribute to availability by replacing failed instances, the primary purpose of this scenario is to match capacity to demand, not to maintain uptime during failures.

Fault tolerance

Why wrong: Fault tolerance is the ability of a system to continue operating without interruption when one or more of its components fail. While Auto Scaling can replace failed instances, fault tolerance typically involves redundancy (e.g., multiple servers, databases) so that no single point of failure exists. The scenario emphasizes scaling to handle load changes, not surviving failures.

Disaster recovery

Why wrong: Disaster recovery involves strategies and processes to recover IT infrastructure and data after a catastrophic event, such as a natural disaster or large-scale outage. It often includes backups, replication across Regions, and failover procedures. This scenario is about adjusting capacity in real time, not recovering from a disaster.