Ec2 practice questions

Rapid elasticity

Why it fails: Rapid elasticity is the ability to quickly scale resources up or down based on demand. While the scenario includes Auto Scaling, the question specifically asks about the 'usage-based billing model', not the scaling capability. Therefore, rapid elasticity is not the characteristic being illustrated by the billing approach.

Resource pooling

Why it fails: Resource pooling refers to the provider's ability to serve multiple customers from shared physical resources, with isolation at the virtual level. This characteristic is about multi-tenancy, not about how customers are billed. The scenario does not focus on multi-tenancy or shared infrastructure.

On-demand self-service

Why it fails: On-demand self-service means customers can provision computing resources automatically without requiring human interaction with the provider. While the Auto Scaling group automates provisioning, the question is about the usage-based billing model, not the provisioning process. Thus, on-demand self-service is not the characteristic being illustrated.

Resource pooling

Why it fails: Resource pooling is an AWS characteristic in which the provider's compute, storage, and network resources are combined into a shared pool and dynamically assigned to multiple customers on a multi-tenant basis. The scenario's focus is on rapidly provisioning 100 instances for a monthly run and terminating them afterward, which directly illustrates rapid elasticity (scaling capacity up and down). Resource pooling would still exist even if the company ran a fixed number of instances year-round; it does not explain the ability to match capacity to workload demand. Therefore, it is a plausible but incorrect answer for this specific scenario.

Measured service

Why it fails: Measured service means that cloud resource usage is metered and reported for billing and optimization. While AWS does meter usage, the core benefit shown here is the ability to scale quickly, not the metering itself.

On-demand self-service

Why it fails: On-demand self-service allows users to provision resources without human interaction. Although the company automates provisioning, the primary characteristic demonstrated is the rapid scaling up and down, which is elasticity. On-demand self-service is a supporting aspect but not the best fit for the scenario's emphasis on handling peak load efficiently.

Hardcode the IAM user access keys in the application code

Why it fails: Hardcoding IAM user access keys in application code is a severe security risk because the keys become embedded in source files, build artifacts, and version-control history. Any source-code leak, shared repository, or decompiled artifact exposes the long-term credentials, and they remain valid until manually revoked. Since these keys are long-lived, rotating them requires editing and redeploying the application, creating downtime and operational burden.

Store IAM access keys in environment variables on the EC2 instance

Why it fails: Storing IAM access keys as environment variables on the EC2 instance only moves the plaintext credentials from source code to runtime memory. Any process able to inspect the environment, such as through /proc/self/environ, process listings, debugging tools, or a compromised container, can capture them. Additionally, the keys are long-term, so they do not rotate automatically and remain at risk in AMI snapshots or user-data scripts.

Create an IAM user and configure the instance with its credentials

Why it fails: Creating a dedicated IAM user and installing its access keys on the instance introduces long-term static credentials that require manual rotation whenever they are exposed or for compliance. These keys are stored in files on the instance or in configuration, making them targets for exfiltration via local exploits or backups. If multiple instances share the IAM user, privilege separation is lost, and auditing individual workloads becomes difficult.

AWS Cost Explorer

Why it fails: AWS Cost Explorer is a tool for visualizing, understanding, and managing AWS costs and usage over time. It does not provide the ability to set budget thresholds, send email alerts when costs exceed a limit, or automatically stop resources.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor inspects your AWS environment and provides recommendations to help you follow best practices in cost optimization, performance, security, and fault tolerance. It does not allow you to set spending limits, configure email alerts based on cost thresholds, or take automated actions like stopping instances.

AWS Pricing Calculator

Why it fails: AWS Pricing Calculator is a pre-build planning tool that generates estimated monthly costs for AWS services based on your anticipated usage inputs, such as instance type, storage, and data transfer. It does not monitor live spending, compare actual usage against a threshold, or trigger any automated actions like stopping EC2 instances. Because it operates independently of your account's real-time billing data, it cannot send email alerts when actual costs exceed a budget. Therefore, it cannot satisfy either the alerting or the automated shutdown requirement of this scenario.

AWS Budgets

Why it fails: AWS Budgets only tracks spend against thresholds and fires alerts; it cannot consolidate invoices or enforce Region restrictions. It is tempting because it addresses the CFO's cost visibility, and would be the right choice for notifying on budget overruns, not for billing consolidation or preventive guardrails.

AWS Identity and Access Management (IAM) cross-account roles

Why it fails: IAM cross-account roles enable users in one account to assume roles in another account for temporary access, but they do not provide a way to consolidate billing or enforce blanket restrictions like a region lock across all accounts. Setting up such restrictions would require manual configuration in each account and does not offer central enforcement.

AWS Cost and Usage Reports

Why it fails: AWS Cost and Usage Reports provide detailed cost and usage data that can be analyzed with tools like Amazon Athena, but they do not consolidate billing or provide any policy enforcement capabilities. They are a reporting tool, not a governance or billing consolidation service.

Data transfer into AWS (inbound)

Why it fails: Data transfer into AWS from the internet is entirely free; AWS deliberately sets ingress pricing to zero to encourage customers to migrate and store data in the cloud. Uploading large datasets to Amazon S3 or EC2 incurs no data transfer charge, so this option cannot be a significant cost driver for an application that exports large amounts of data to end users. The only inbound charges you might encounter are for specific service features (e.g., certain AWS Marketplace or NAT gateway scenarios), but standard internet ingress remains free.

Data transfer between EC2 instances in the same Availability Zone

Why it fails: Data transferred between EC2 instances in the same Availability Zone over private IP addresses is free because it stays entirely within AWS's internal network and never crosses a metered boundary. This is different from cross-AZ or cross-Region traffic, which incurs per-GB charges. If two instances are in the same AZ and communicate via private IPs, there is no data transfer cost, so this option cannot be the reason for high data export charges. (Note: using public or Elastic IPs for same-AZ traffic does incur charges, but the standard private path is free.)

API calls to AWS services

Why it fails: API calls to AWS services are typically billed per request, not per gigabyte of data transferred, making them a relatively minor cost compared to outbound data transfer. For example, Amazon S3 charges per 1,000 requests for PUT/GET/LIST operations, but these costs are negligible when compared to the per-GB egress fees for large-scale data export. While a high volume of API calls could add up, the dominant cost for an application serving large files to end users is always the network egress, not the control-plane or data-plane API request overhead.

AWS Elastic Beanstalk

Why it fails: AWS Elastic Beanstalk is a PaaS service that simplifies deploying and scaling applications. It automatically provisions underlying resources (e.g., EC2, load balancers) based on the application needs, but it does not give you direct control to define arbitrary resources like custom VPCs or RDS with specific configurations. The requirement is for a service that defines the entire infrastructure as code, not just an application platform.

AWS OpsWorks

Why it fails: AWS OpsWorks is a configuration management service that uses Chef and Puppet to automate server configuration and application deployment. While it can manage EC2 instances, it is not designed for provisioning core network resources (VPC, subnets) or managed databases. The team needs an infrastructure-as-code service, not a configuration management tool.

AWS CodeDeploy

Why it fails: AWS CodeDeploy automates the deployment of application code to running instances (EC2, Lambda, etc.). It does not provision infrastructure resources such as VPCs, subnets, or databases. The requirement is about defining and creating the infrastructure itself, not deploying code onto existing infrastructure.

Broad network access

Why it fails: Incorrect. Broad network access means that resources are available over the network and can be accessed by standard mechanisms from various client platforms (e.g., mobile phones, laptops, workstations). While the developer used the console over the internet, the core of the scenario is about the ability to provision resources without human interaction, not the variety of access methods.

Resource pooling

Why it fails: Incorrect. 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 customer demand. This scenario does not demonstrate multi-tenancy or shared infrastructure; it focuses on the ease and speed of provisioning.

Rapid elasticity

Why it fails: Incorrect. Rapid elasticity is the ability to quickly scale resources up or out and down or in, often automatically, to match demand. While AWS does support elasticity, this scenario describes the initial provisioning of a single test server without any scaling action. The key aspect is the self-service capability, not the scaling itself.

AWS Shield Standard

Why it fails: AWS Shield Standard provides always-on protection against common DDoS attacks at the network and transport layer, but it does not inspect application-layer content like SQL injection payloads. It cannot block or filter specific HTTP requests.

Network ACLs

Why it fails: Network ACLs are stateless, subnet-level filters that allow or deny traffic based solely on L3/L4 attributes such as source/destination IP, port, and protocol. They cannot inspect the payload of an HTTP request, so SQL injection strings embedded in a URI or body would pass through unnoticed. Additionally, because they are stateless, they require separate inbound and outbound rules and provide no session awareness, making them unsuitable for blocking application-layer attacks. To detect and block SQL injection or XSS, you need a web application firewall like AWS WAF that analyzes request content.

Amazon GuardDuty

Why it fails: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior using machine learning and threat intelligence. It can detect SQL injection attempts in logs, but it does not actively block the requests; it only generates alerts.

Amazon Elastic Block Store (EBS)

Why it fails: Incorrect. An Amazon EBS volume is a block-level storage device that can only be attached to a single EC2 instance (except for the limited Multi-Attach capability on some volume types, which is not intended for general concurrent file sharing and has strict constraints). It cannot serve as a shared file system across multiple instances in different Availability Zones.

Amazon Simple Storage Service (S3)

Why it fails: Incorrect. Amazon S3 is an object storage service designed for storing and retrieving large amounts of data via HTTP/HTTPS. It does not provide a file-system interface or support for standard file-level locking required for concurrent access by multiple EC2 instances as a shared file system.

Amazon Relational Database Service (RDS)

Why it fails: Incorrect. Amazon RDS is a managed service for setting up, operating, and scaling relational databases. It is not a file storage solution and cannot be used to share configuration files or static assets among EC2 instances.

AWS Shield Advanced

Why it fails: AWS Shield Advanced provides enhanced DDoS mitigation against volumetric, state-exhaustion, and protocol-based attacks at the network and transport layers, with 24/7 detection and response support. While it can integrate with AWS WAF for layer 7 protection, Shield Advanced itself does not inspect HTTP payloads or maintain custom signature rules to block specific attack patterns like SQL injection or cross-site scripting. Because it lacks application-layer request filtering, it is not the correct service to stop those web application attacks directly.

AWS Firewall Manager

Why it fails: AWS Firewall Manager is a security management service that allows you to centrally configure and manage firewall rules across accounts and resources, including AWS WAF rules. However, it does not directly inspect traffic; it is a policy management tool, not the inspection engine itself.

Amazon Inspector

Why it fails: Amazon Inspector is a vulnerability management service that uses system agents to scan Amazon EC2 instances and container images for known software CVEs and unintended network exposure. It runs on a schedule or on-demand, not inline in the web traffic path, so it cannot monitor or filter live HTTP/HTTPS requests. As a result, it cannot provide real-time protection against SQL injection or cross-site scripting attacks, making it the wrong choice for this requirement.

Reserved Instances (Standard)

Why it fails: Incorrect. Standard Reserved Instances provide a discount but are locked to a specific instance family and region. They do not cover AWS Fargate or AWS Lambda, and changing instance attributes would require purchasing new reservations.

Reserved Instances (Convertible)

Why it fails: Incorrect. Convertible Reserved Instances offer some flexibility to change instance family or region, but they still apply only to Amazon EC2 (not Fargate or Lambda) and require a 1:1 exchange of attributes. They also do not provide the broad service coverage of a Compute Savings Plan.

On-Demand

Why it fails: On-Demand pricing is incorrect because it involves no upfront commitment or term agreement, so customers pay the full, undiscounted hourly rate for every instance hour consumed. While On-Demand offers maximum flexibility—you can launch, stop, or terminate instances at any time without penalty—it does not provide the cost reduction that the finance team requires. Since the workload is diverse and steady enough to warrant savings, committing to a Compute Savings Plan would yield significantly lower prices than On-Demand, making On-Demand the least economical choice for this scenario.

Scalability

Why it fails: Scalability is the ability to handle increased load by adding resources, but it does not inherently imply automatic scaling down. While the system is scalable, the key feature demonstrated is the dynamic, bidirectional adjustment that defines elasticity.

High availability

Why it fails: High availability ensures the application remains accessible despite component failures, often through redundancy across multiple Availability Zones. The scenario does not describe a failure or redundancy configuration; it focuses on scaling to meet variable demand.

Fault tolerance

Why it fails: Fault tolerance is the property that lets an application continue operating without interruption even when a component, such as an EC2 instance or Availability Zone, fails. The scenario describes only a variation in customer traffic and the corresponding scaling actions; there is no mention of a failed instance, a failed dependency, or a redundant architecture designed to mask component loss. Auto Scaling can replace unhealthy instances, but here the group is responding to load changes, not to a fault event, so fault tolerance is not the concept being tested.

Deploy the website on additional Amazon EC2 instances in the eu-west-1 and ap-southeast-1 Regions, and use a Network Load Balancer to distribute traffic across all Regions.

Why it fails: Adding EC2 instances in new Regions with a Network Load Balancer does not cache static assets at edge locations; it merely distributes traffic across regional origins, so users still fetch assets from distant servers, failing to reduce latency for a global user base. This option is tempting because a Network Load Balancer is designed for regional traffic distribution and fault tolerance, and would be correct if the goal were to balance load across multiple compute instances within a single Region.

Use Amazon Route 53 with geolocation routing policies to route users to the nearest AWS Region for the website.

Why it fails: Route 53 geolocation routing directs DNS queries to the appropriate origin based on the user's location, but the origin servers remain in a single Region or few Regions. It does not cache content, so users still experience latency from the origin server's location.

Enable S3 Transfer Acceleration on the Amazon S3 bucket that stores the static assets.

Why it fails: S3 Transfer Acceleration uses AWS edge locations to speed up the upload of data into an S3 bucket, not to accelerate downloads for end users. It optimizes the network path for content being written to S3, typically for large uploads or migration scenarios, but it does not cache or serve static assets from edge locations. When a website visitor requests a static asset, the request still goes directly to the bucket's regional endpoint, so the geographic distance and latency remain unchanged. Therefore, enabling it would not reduce load times for a global audience.

AWS CloudTrail

Why it fails: AWS CloudTrail records API activity (who made what call, when, from where) but does not evaluate the actual configuration of resources against policies. It is not designed for compliance rule evaluation or a compliance dashboard.

Amazon GuardDuty

Why it fails: Amazon GuardDuty is a threat detection service that uses machine learning to identify malicious or unauthorized behavior, such as unusual API calls or compromised instances. It does not evaluate resource configurations for compliance with internal policies.

Amazon Inspector

Why it fails: Amazon Inspector is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure. It does not evaluate resource configurations against custom compliance rules or provide a compliance dashboard for resources like S3 bucket policies or security group rules.

AWS Budgets

Why it fails: AWS Budgets is a governance tool that lets you set custom cost and usage thresholds for your account, then alerts you—via email, Amazon SNS, or AWS Chatbot—when actual or forecasted spending approaches or exceeds those limits. It only operates on real billing metrics and forecast patterns from existing usage, so it cannot model a not-yet-deployed on-premises migration or answer 'how much will it cost?' It is for managing spend after you begin using AWS.

AWS Cost Explorer

Why it fails: Incorrect. AWS Cost Explorer enables you to visualize, understand, and manage your AWS costs and usage over time, including future forecasts based on historical data. However, it cannot be used to estimate costs for a new migration scenario where no historical usage exists.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor is an automated service that analyzes your existing AWS environment and flags cost optimization opportunities, security gaps, performance bottlenecks, and service limit risks. It works by inspecting live account resources and usage patterns, so it has no mechanism to model a planned on-premises migration or produce a future cost estimate. For pre-migration planning, it is not a cost estimator.

On-demand self-service

Why it fails: On-demand self-service allows users to provision resources without requiring human interaction with the provider. While the company can initially configure the Auto Scaling group via the AWS Management Console or API, the scenario focuses on the automatic scaling behavior itself, not the self-service provisioning.

Broad network access

Why it fails: Broad network access means that resources are accessible over the network by a wide range of client devices (e.g., laptops, phones). The scenario does not mention device diversity or network accessibility as the key benefit.

Measured service

Why it fails: Measured service means that cloud resource usage is metered and billed on a pay-as-you-go basis. While the company benefits from paying only for the capacity used, the scenario primarily highlights the automatic scaling capability, not the metering or billing aspect.

Elasticity

Why it fails: Elasticity is the ability to automatically provision and de-provision resources in response to changing demand. While a multi-instance setup can support elasticity, the primary goal of the described architecture is to maintain service availability despite failures, not to dynamically adjust capacity.

Scalability

Why it fails: Scalability is the ability to handle growing amounts of work by adding resources. Although deploying multiple instances can support scalability, the scenario specifically focuses on maintaining uptime during failures, not on handling increased traffic or growth.

Cost optimization

Why it fails: Cost optimization involves rightsizing resources and eliminating waste to minimize spending. The described architecture may increase costs due to running a second instance and a load balancer. While high availability can be part of a cost-benefit analysis, it is not the primary benefit the architecture aims to achieve.

AWS CloudHSM

Why it fails: AWS CloudHSM provides dedicated hardware security modules (HSMs) for key storage, but it does not offer built-in automatic key rotation. Customers must build and manage their own rotation scripts, increasing operational overhead. It is not a fully managed key rotation service.

AWS Certificate Manager (ACM)

Why it fails: AWS Certificate Manager (ACM) is a service for provisioning, managing, and deploying public and private SSL/TLS certificates, primarily used to secure network traffic over HTTPS and other TLS-based protocols. It does not create, store, or rotate symmetric data keys or customer master keys used for Amazon EBS encryption; EBS encryption relies on AWS KMS keys, not on certificate infrastructure. ACM's automatic renewal applies to issued certificates, not to encryption keys, so it cannot satisfy a policy requiring automatic rotation of EBS encryption keys. Even if ACM were integrated, it lacks the IAM policy and grant mechanisms that EBS uses to authorize encryption and decryption operations.

AWS Secrets Manager

Why it fails: AWS Secrets Manager is designed to securely store, rotate, and manage secrets such as database credentials, API keys, and other sensitive information. It is not intended for managing encryption keys for EBS volumes, and it does not integrate with EBS encryption.

Amazon CloudFront

Why it fails: Amazon CloudFront is a content delivery network (CDN) for fast delivery of static and dynamic web content over HTTP/HTTPS. It does not natively support UDP traffic, which is required by this application. CloudFront is best for caching and accelerating web-based content, not real-time UDP-based game traffic.

Amazon Route 53 latency routing

Why it fails: Amazon Route 53 latency routing is a DNS-based routing policy that directs users to the AWS region with the lowest latency based on DNS resolution. While it can help route players to a nearby region, it does not provide edge-based acceleration or improve the performance of traffic routed to a single region. It also does not reduce latency over the last mile or through ISP networks.

AWS Site-to-Site VPN

Why it fails: AWS Site-to-Site VPN is used to create a secure connection between an on-premises network and AWS VPC. It is not designed to accelerate end-user traffic from the internet or to improve performance for global users accessing a cloud application.