AWS Pricing practice questions

A company operates separate AWS accounts for its engineering, marketing, and finance departments. The CFO wants to consolidate billing to receive a single monthly invoice and to benefit from volume pricing discounts. The security team also requires a centralized mechanism to prevent users in any department from launching Amazon EC2 instances outside of the us-east-1 and eu-west-1 Regions to meet data residency compliance. Which AWS service or feature should the company use to meet both requirements?

Trap 1: AWS Budgets

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.

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

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.

Trap 3: AWS Cost and Usage Reports

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.

A
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.
B
AWS Organizations with Service Control Policies (SCPs)
AWS Organizations provides consolidated billing for a single invoice and volume discounts, and SCPs allow you to centrally define and enforce permission guardrails (e.g., restricting Regions) across all member accounts. This directly meets both requirements.
C
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.
D
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.

Question 2mediummultiple choice

A company runs a batch processing workload on an on-premises data center. The servers are powerful machines that are used at maximum capacity only for a few days each month during financial reporting periods. For the rest of the month, the servers run at very low utilization. The CFO wants to migrate this workload to AWS to reduce costs. Which characteristic of AWS cloud computing is most directly aligned with the CFO's goal of paying only for the compute capacity actually used?

Trap 1: High availability across multiple Availability Zones

High availability across multiple Availability Zones is a resilience architecture pattern that duplicates workloads and data across physically separate data centers within an AWS Region to withstand infrastructure failures. While this design eliminates a single point of failure and supports business continuity, it does not change the fundamental commercial model of how compute resources are billed. A company could architect for high availability and still pay for idle on-premises servers if it merely replicates the same fixed-capacity approach in the cloud. The CFO's concern about underutilized servers is specifically addressed by the consumption-based pay-as-you-go pricing model, not by geographic redundancy.

Trap 2: Elasticity to automatically scale resources up and down

Elasticity allows resources to be automatically adjusted to match demand, which can reduce waste, but the CFO's stated goal is specifically about the pricing model that charges only for consumed capacity. The pay-as-you-go model is the fundamental advantage that aligns with paying for actual usage.

Trap 3: The ability to choose from a wide variety of instance types

While choosing the right instance type can optimize performance and cost, it does not eliminate the problem of paying for idle resources. The pay-as-you-go model is the key enabler for paying only for actual usage.

A
High availability across multiple Availability Zones
Why it fails: High availability across multiple Availability Zones is a resilience architecture pattern that duplicates workloads and data across physically separate data centers within an AWS Region to withstand infrastructure failures. While this design eliminates a single point of failure and supports business continuity, it does not change the fundamental commercial model of how compute resources are billed. A company could architect for high availability and still pay for idle on-premises servers if it merely replicates the same fixed-capacity approach in the cloud. The CFO's concern about underutilized servers is specifically addressed by the consumption-based pay-as-you-go pricing model, not by geographic redundancy.
B
Elasticity to automatically scale resources up and down
Why it fails: Elasticity allows resources to be automatically adjusted to match demand, which can reduce waste, but the CFO's stated goal is specifically about the pricing model that charges only for consumed capacity. The pay-as-you-go model is the fundamental advantage that aligns with paying for actual usage.
C
Pay-as-you-go pricing model
The pay-as-you-go model lets customers pay only for the compute capacity they actually use, with no upfront capital expenditure or charges for idle resources. This directly meets the CFO's objective of eliminating costs for underutilized on-premises servers.
D
The ability to choose from a wide variety of instance types
Why it fails: While choosing the right instance type can optimize performance and cost, it does not eliminate the problem of paying for idle resources. The pay-as-you-go model is the key enabler for paying only for actual usage.

Question 3mediummultiple choice

A company runs a diverse workload on AWS that includes Amazon EC2 instances of various families and sizes across multiple regions, Amazon RDS databases, and a serverless application using AWS Lambda and AWS Fargate. The finance team wants to reduce compute costs by making a 1-year hourly spend commitment, but they need the flexibility to change instance families, sizes, regions, or switch between EC2, Fargate, and Lambda without losing the discount. Which AWS pricing model should the finance team choose to meet these requirements?

Trap 1: Reserved Instances (Standard)

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.

Trap 2: Reserved Instances (Convertible)

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.

Trap 3: On-Demand

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.

A
Compute Savings Plan
Correct. Compute Savings Plans apply to any EC2 instance (any family, size, region), AWS Fargate, and AWS Lambda. They provide significant discounts in exchange for a consistent hourly spend commitment and offer the maximum flexibility to change instance attributes or move between compute services.
B
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.
C
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.
D
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.

Question 4mediummultiple choice

A company is migrating its on-premises data analytics workload to AWS. Previously, the company had to purchase and maintain dedicated servers with fixed capacity to handle peak workloads, resulting in low utilization during off-peak hours. On AWS, the company can launch compute resources, run the analytics job, and terminate the resources when done. The company only pays for the compute time and storage used during the job. Which essential characteristic of cloud computing does this scenario BEST demonstrate?

Trap 1: Rapid elasticity

Rapid elasticity is the ability to quickly scale resources up or down. This scenario does mention launching and terminating resources, but the primary focus is on paying only for what is used, not on automatic scaling. Elasticity is more about dynamic capacity adjustments rather than billing model.

Trap 2: Resource pooling

Resource pooling refers to the provider's ability to serve multiple customers using shared physical resources with logical isolation. While AWS uses resource pooling to achieve economies of scale, the scenario is about the billing advantage of paying only for consumed resources, not about multi-tenancy.

Trap 3: On-demand self-service

On-demand self-service in AWS is the capability for customers to provision computing resources automatically—through the Management Console, CLI, or SDKs—without requiring any human interaction or manual approval from the cloud provider. While the scenario does involve launching and terminating resources, which is a self-service action, the core advantage being highlighted is purely financial: paying only for the exact capacity consumed rather than for pre-provisioned idle infrastructure. That pay-per-use billing model is the defining trait of measured service, whereas on-demand self-service focuses solely on the access and provisioning mechanism.

A
Rapid elasticity
Why it fails: Rapid elasticity is the ability to quickly scale resources up or down. This scenario does mention launching and terminating resources, but the primary focus is on paying only for what is used, not on automatic scaling. Elasticity is more about dynamic capacity adjustments rather than billing model.
B
Measured service
Measured service is the correct answer. Cloud providers meter usage (compute time, storage, etc.) and bill customers based on actual consumption. This eliminates the need to pay for idle capacity and aligns cost directly with usage, as described in the scenario.
C
Resource pooling
Why it fails: Resource pooling refers to the provider's ability to serve multiple customers using shared physical resources with logical isolation. While AWS uses resource pooling to achieve economies of scale, the scenario is about the billing advantage of paying only for consumed resources, not about multi-tenancy.
D
On-demand self-service
Why it fails: On-demand self-service in AWS is the capability for customers to provision computing resources automatically—through the Management Console, CLI, or SDKs—without requiring any human interaction or manual approval from the cloud provider. While the scenario does involve launching and terminating resources, which is a self-service action, the core advantage being highlighted is purely financial: paying only for the exact capacity consumed rather than for pre-provisioned idle infrastructure. That pay-per-use billing model is the defining trait of measured service, whereas on-demand self-service focuses solely on the access and provisioning mechanism.

Question 5mediummultiple choice

A company plans to migrate its on-premises workload to AWS. The finance team wants to compare the total cost of ownership between running the workload on-premises and running it on AWS. They need to estimate monthly costs for different Amazon EC2 instance types, pricing models (On-Demand, Reserved, Spot), and storage options before making any commitment. Which AWS tool should the finance team use to create this detailed cost estimate?

Trap 1: AWS Budgets

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.

Trap 2: AWS Cost Explorer

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.

Trap 3: AWS Trusted Advisor

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.

A
AWS Pricing Calculator
AWS Pricing Calculator is a web-based cost estimation tool that lets you define a workload's architecture—such as EC2 instance types, storage, data transfer, and region—and then produces a monthly cost estimate. It supports comparing On-Demand vs. Savings Plans vs. Reserved Instance pricing, and it can generate a total cost of ownership (TCO) report against on-premises costs, making it the appropriate tool for pre-migration cost planning.
B
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.
C
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.
D
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.

Question 6mediummultiple choice

A startup is planning to build and launch a new mobile application on AWS. The team expects very low initial traffic but hopes to scale rapidly. They have a limited budget and want to avoid any upfront costs. They are unsure which AWS services they will need and want to estimate their monthly AWS charges before committing to an architecture. Additionally, they need access to technical support to help troubleshoot issues that arise during development and production, with a guaranteed response time of less than 12 hours for production-impacting issues. Which combination of AWS tool and support plan should the startup choose to meet these requirements?

Trap 1: AWS Cost Explorer + Basic Support

Incorrect. AWS Cost Explorer is used to analyze historical cost and usage data, not to estimate future costs for an unbuilt architecture. Basic Support does not include technical support, so the startup would not get any guaranteed response time for production issues.

Trap 2: AWS Budgets + Business Support

Incorrect. AWS Budgets is used to set cost alerts and track spending against budgets, not to estimate initial costs before building. Business Support offers faster response times (e.g., 1 hour for production system down) but is more expensive than Developer Support and provides more than what is required for a startup with limited budget.

Trap 3: AWS Total Cost of Ownership (TCO) Calculator + Enterprise Support

Incorrect. The TCO Calculator compares the cost of running infrastructure on-premises vs. on AWS, which is not relevant for a startup that does not have existing on-premises infrastructure. Enterprise Support is the highest tier with a designated Technical Account Manager and is very expensive, far beyond the needs of a small startup with limited budget.

A
AWS Pricing Calculator + Developer Support
Correct. The AWS Pricing Calculator lets you estimate monthly costs for AWS services before building the architecture. The Developer Support plan offers a response time of less than 12 hours for production issues that impair the system, which meets the stated requirement. This combination is cost-effective for a startup with limited budget.
B
AWS Cost Explorer + Basic Support
Why it fails: Incorrect. AWS Cost Explorer is used to analyze historical cost and usage data, not to estimate future costs for an unbuilt architecture. Basic Support does not include technical support, so the startup would not get any guaranteed response time for production issues.
C
AWS Budgets + Business Support
Why it fails: Incorrect. AWS Budgets is used to set cost alerts and track spending against budgets, not to estimate initial costs before building. Business Support offers faster response times (e.g., 1 hour for production system down) but is more expensive than Developer Support and provides more than what is required for a startup with limited budget.
D
AWS Total Cost of Ownership (TCO) Calculator + Enterprise Support
Why it fails: Incorrect. The TCO Calculator compares the cost of running infrastructure on-premises vs. on AWS, which is not relevant for a startup that does not have existing on-premises infrastructure. Enterprise Support is the highest tier with a designated Technical Account Manager and is very expensive, far beyond the needs of a small startup with limited budget.

Question 7easymultiple choice

AWS can offer lower pay-as-you-go pricing than a single company could achieve operating its own data centre because AWS aggregates usage from hundreds of thousands of customers. Which cloud computing benefit does this describe?

Trap 1: Trade capital expense for variable expense

This benefit describes moving IT spend from up-front capital purchases (servers, storage, networking) to an operational expense model under AWS's pay-as-you-go pricing. It changes how you pay for infrastructure, reducing idle capacity risk and removing large initial budgets. However, it does not explain why AWS's unit prices are low; that downward pressure on per-hour or per-GB pricing comes from aggregate purchasing power across millions of customers, which is the economies-of-scale advantage.

Trap 2: Increase speed and agility

This benefit is about how quickly developers can provision and release resources: with self-service APIs, pre-provisioned services, and elastic capacity, you can deploy an environment in minutes instead of months. It enables faster experimentation and faster time-to-market, which are agility gains. This is unrelated to cost-per-unit reductions; even if your unit prices were unchanged, speed and agility would still be a separate advantage.

Trap 3: Go global in minutes

This benefit refers to AWS's global infrastructure, which spans dozens of geographic Regions and multiple Availability Zones, letting you place infrastructure close to customers around the world in a few clicks. Deployments to a new region can be initiated in minutes, improving latency and resilience for global users. It has nothing to do with cost per unit falling due to scale; it is a reach-and-architecture benefit, not a purchasing-power benefit.

A
Trade capital expense for variable expense
Why it fails: This benefit describes moving IT spend from up-front capital purchases (servers, storage, networking) to an operational expense model under AWS's pay-as-you-go pricing. It changes how you pay for infrastructure, reducing idle capacity risk and removing large initial budgets. However, it does not explain why AWS's unit prices are low; that downward pressure on per-hour or per-GB pricing comes from aggregate purchasing power across millions of customers, which is the economies-of-scale advantage.
B
Benefit from massive economies of scale
AWS purchases hardware, cooling, networking, and power in volumes that no single enterprise can match, and it operates its data centers at hyperscale efficiency. Because this aggregated demand is spread across hundreds of thousands of users, the per-unit cost of compute, storage, and bandwidth falls, and AWS passes these savings on as lower on-demand prices. This is the 'massive economies of scale' benefit: the customer benefits from AWS's scale without having to build their own data center.
C
Increase speed and agility
Why it fails: This benefit is about how quickly developers can provision and release resources: with self-service APIs, pre-provisioned services, and elastic capacity, you can deploy an environment in minutes instead of months. It enables faster experimentation and faster time-to-market, which are agility gains. This is unrelated to cost-per-unit reductions; even if your unit prices were unchanged, speed and agility would still be a separate advantage.
D
Go global in minutes
Why it fails: This benefit refers to AWS's global infrastructure, which spans dozens of geographic Regions and multiple Availability Zones, letting you place infrastructure close to customers around the world in a few clicks. Deployments to a new region can be initiated in minutes, improving latency and resilience for global users. It has nothing to do with cost per unit falling due to scale; it is a reach-and-architecture benefit, not a purchasing-power benefit.

Question 8mediummultiple choice

A startup is planning a new web application on AWS. The architecture will use Amazon EC2 for compute, Amazon RDS for the database, and Amazon S3 for static assets. The team needs to estimate the monthly cost of running this application before building it. They want to compare costs across different instance types, regions, and pricing models (On-Demand vs. Reserved Instances), and they also need to account for data transfer costs. Which AWS tool should the team use to create this estimate?

Trap 1: AWS Cost Explorer

AWS Cost Explorer is used to visualize, understand, and analyze historical cost and usage data. It is not designed to create cost estimates for a new, unbuilt architecture. It works with actual incurred costs, not hypothetical future configurations.

Trap 2: AWS Total Cost of Ownership (TCO) Calculator

The AWS TCO Calculator compares the cost of running infrastructure on-premises versus running on AWS. It requires input about existing on-premises servers, storage, and networking. It is not suitable for estimating costs for a new, cloud-native application that does not have an on-premises baseline.

Trap 3: AWS Budgets

AWS Budgets allows you to set cost or usage budgets and receive alerts when you exceed or are forecasted to exceed your thresholds. It is used for monitoring and controlling costs after they have started accruing, not for estimating the cost of a planned architecture.

A
AWS Cost Explorer
Why it fails: AWS Cost Explorer is used to visualize, understand, and analyze historical cost and usage data. It is not designed to create cost estimates for a new, unbuilt architecture. It works with actual incurred costs, not hypothetical future configurations.
B
AWS Total Cost of Ownership (TCO) Calculator
Why it fails: The AWS TCO Calculator compares the cost of running infrastructure on-premises versus running on AWS. It requires input about existing on-premises servers, storage, and networking. It is not suitable for estimating costs for a new, cloud-native application that does not have an on-premises baseline.
C
AWS Budgets
Why it fails: AWS Budgets allows you to set cost or usage budgets and receive alerts when you exceed or are forecasted to exceed your thresholds. It is used for monitoring and controlling costs after they have started accruing, not for estimating the cost of a planned architecture.
D
AWS Pricing Calculator
The AWS Pricing Calculator enables users to estimate the monthly cost of AWS services by selecting specific configurations (e.g., EC2 instance type, RDS database class, S3 storage class, etc.), regions, and pricing models. It provides a detailed cost breakdown and is the correct tool for pre-deployment cost estimation.

Question 9easymultiple choice

A company operates three separate AWS accounts: development, testing, and production. Each account independently incurs Amazon S3 data transfer charges. The company signs up for AWS Organizations and enables consolidated billing. How does consolidated billing affect the S3 data transfer pricing for the company?

Trap 1: It applies a flat 20% discount to all S3 data transfer charges…

Consolidated billing does not impose an arbitrary flat discount rate such as 20% on S3 data transfer. Instead, AWS uses volume-based tiered pricing that is calculated by summing the total data transfer usage across all linked accounts; the first x TB fall into one price tier, and subsequent amounts qualify for lower per-GB rates in the next tier. For example, the tier schedule might charge $0.09 per GB for the first 10 TB, then $0.085 per GB for the next 40 TB, so the savings are graduated and depend on total aggregate usage, not a single uniform percentage off the entire bill.

Trap 2: It allows the company to use a single payment method and…

While it is true that consolidated billing allows the organization to use a single payment method across all linked accounts, the second part of this statement is fundamentally incorrect. Reserved Instance pricing applies to compute services such as Amazon EC2, RDS, or Redshift, where you commit to a specific instance configuration for a one- or three-year term in exchange for lower hourly rates. S3 data transfer charges are usage-based per gigabyte and do not have reserved-pricing offerings, so enabling consolidated billing will not convert those variable data-transfer costs into discounted fixed rates.

Trap 3: It creates a single combined bill and automatically applies an…

Consolidated billing does combine usage from all linked accounts into a single monthly invoice issued to the payer account, but it does not automatically attach or activate an Enterprise Discount Program (EDP) that a company may have negotiated. Enterprise discounts are separate contractual agreements negotiated directly with AWS, usually with a minimum spend commitment, and they require explicit application to the organization's accounts rather than being triggered by the billing feature itself. Without that agreement in place, enabling consolidated billing simply aggregates charges for tier-based pricing, not discount percentages from a custom contract.

A
It applies a flat 20% discount to all S3 data transfer charges across accounts.
Why it fails: Consolidated billing does not impose an arbitrary flat discount rate such as 20% on S3 data transfer. Instead, AWS uses volume-based tiered pricing that is calculated by summing the total data transfer usage across all linked accounts; the first x TB fall into one price tier, and subsequent amounts qualify for lower per-GB rates in the next tier. For example, the tier schedule might charge $0.09 per GB for the first 10 TB, then $0.085 per GB for the next 40 TB, so the savings are graduated and depend on total aggregate usage, not a single uniform percentage off the entire bill.
B
It aggregates the data transfer usage across all accounts, allowing the company to benefit from lower pricing tiers that are based on total usage.
This is correct. With consolidated billing, the data transfer usage from all accounts is summed. AWS's pricing tiers (e.g., up to 10 TB, next 40 TB, etc.) are then applied to the aggregate total, often resulting in a lower effective per-GB cost than if each account were billed separately.
C
It allows the company to use a single payment method and automatically applies Reserved Instance pricing to data transfer.
Why it fails: While it is true that consolidated billing allows the organization to use a single payment method across all linked accounts, the second part of this statement is fundamentally incorrect. Reserved Instance pricing applies to compute services such as Amazon EC2, RDS, or Redshift, where you commit to a specific instance configuration for a one- or three-year term in exchange for lower hourly rates. S3 data transfer charges are usage-based per gigabyte and do not have reserved-pricing offerings, so enabling consolidated billing will not convert those variable data-transfer costs into discounted fixed rates.
D
It creates a single combined bill and automatically applies an enterprise discount negotiated with AWS.
Why it fails: Consolidated billing does combine usage from all linked accounts into a single monthly invoice issued to the payer account, but it does not automatically attach or activate an Enterprise Discount Program (EDP) that a company may have negotiated. Enterprise discounts are separate contractual agreements negotiated directly with AWS, usually with a minimum spend commitment, and they require explicit application to the organization's accounts rather than being triggered by the billing feature itself. Without that agreement in place, enabling consolidated billing simply aggregates charges for tier-based pricing, not discount percentages from a custom contract.

Question 10mediummultiple choice

A company wants to use AWS for a short-term proof-of-concept project lasting one month. They need EC2 instances and RDS databases but don't want any long-term commitment. Which pricing model is most appropriate?

Trap 1: Reserved Instances (1-year, All Upfront)

Reserved Instances with a 1-year, All Upfront term require you to pay the entire cost of EC2 capacity for the full year at purchase time. For a one-month proof-of-concept, this means you would be paying for 11 months of capacity you never use, and RIs cannot be canceled or refunded mid-term. Even if you were to resell the RI on the Reserved Instance Marketplace, it adds unnecessary complexity and does not align with the short, bounded nature of the project.

Trap 2: Savings Plans (3-year commitment)

A 3-year Savings Plan requires you to commit to a consistent amount of compute usage measured in dollars per hour for three full years, and you must keep paying that amount every hour regardless of whether you are using the resources. For a one-month proof-of-concept, you would be contractually obligated to pay for 35 additional months of consumption you do not need, which is financially unjustifiable. Savings Plans are designed for stable, predictable production workloads, not for short-lived experiments or temporary testing.

Trap 3: Spot Instances for all workloads

Spot Instances can be terminated by AWS with only a two-minute warning when capacity is reclaimed, making them unsuitable for RDS databases that require persistent, uninterrupted operation for the one-month proof-of-concept. This option is tempting because Spot Instances offer significant cost savings for fault-tolerant, stateless workloads, and would be the correct choice for batch processing or data analysis jobs that can handle interruptions.

A
Reserved Instances (1-year, All Upfront)
Why it fails: Reserved Instances with a 1-year, All Upfront term require you to pay the entire cost of EC2 capacity for the full year at purchase time. For a one-month proof-of-concept, this means you would be paying for 11 months of capacity you never use, and RIs cannot be canceled or refunded mid-term. Even if you were to resell the RI on the Reserved Instance Marketplace, it adds unnecessary complexity and does not align with the short, bounded nature of the project.
B
On-Demand pricing
On-Demand pricing lets you launch an RDS database instance with no upfront payment, no long-term commitment, and per-second billing, so you pay only for the hours the instance actually runs during the one-month PoC. You can terminate the instance at any time without penalties, giving you complete flexibility to scale, stop, or adjust the workload as the proof-of-concept evolves. This makes On-Demand the only sensible choice for a time-bounded project where future usage patterns are unknown.
C
Savings Plans (3-year commitment)
Why it fails: A 3-year Savings Plan requires you to commit to a consistent amount of compute usage measured in dollars per hour for three full years, and you must keep paying that amount every hour regardless of whether you are using the resources. For a one-month proof-of-concept, you would be contractually obligated to pay for 35 additional months of consumption you do not need, which is financially unjustifiable. Savings Plans are designed for stable, predictable production workloads, not for short-lived experiments or temporary testing.
D
Spot Instances for all workloads
Why it fails: Spot Instances can be terminated by AWS with only a two-minute warning when capacity is reclaimed, making them unsuitable for RDS databases that require persistent, uninterrupted operation for the one-month proof-of-concept. This option is tempting because Spot Instances offer significant cost savings for fault-tolerant, stateless workloads, and would be the correct choice for batch processing or data analysis jobs that can handle interruptions.

Question 11mediummultiple choice

A solutions architect is planning a new web application on AWS. The workload will include 3 Amazon EC2 instances (t3.medium) running 24/7, an Application Load Balancer, and an Amazon RDS for MySQL db.t3.small database. The architect needs to estimate the monthly cost for the first year, considering different purchasing options (On-Demand, 1-year All Upfront Reserved Instance, and Compute Savings Plan). Which AWS tool should the architect use to create this estimate?

Trap 1: AWS Total Cost of Ownership (TCO) Calculator

The TCO Calculator is designed to compare on-premises infrastructure costs with AWS costs. It is not intended to estimate costs for a new AWS-only deployment with specific pricing options like Reserved Instances or Savings Plans.

Trap 2: AWS Cost Explorer

AWS Cost Explorer analyzes historical cost and usage data, with interactive charts for filtering by service, region, or tag to identify billing trends. Its forecasting features extrapolate from past usage, so they are meaningless for a workload that has never been deployed; there are no configuration inputs for CPUs, storage sizes, or pricing plans. Therefore, it is a post-launch analysis tool, not a pre-deployment pricing estimator.

Trap 3: AWS Budgets

AWS Budgets is a cost governance service that tracks actual and forecasted spend against the thresholds you define, sending alerts or triggering actions when limits are exceeded. It only works with resources that already exist in your account and have generated cost data, so it cannot model a not-yet-built architecture or compare pricing options. Using it to estimate a new deployment would be impossible because there is no billing history to evaluate.

A
AWS Total Cost of Ownership (TCO) Calculator
Why it fails: The TCO Calculator is designed to compare on-premises infrastructure costs with AWS costs. It is not intended to estimate costs for a new AWS-only deployment with specific pricing options like Reserved Instances or Savings Plans.
B
AWS Pricing Calculator
The AWS Pricing Calculator is a web-based tool for building a cost estimate for a new AWS workload before any resources are provisioned. You can select services, configure compute, storage, and data transfer parameters, and choose purchasing options like On-Demand, Reserved Instances, or Savings Plans to see a line-item monthly and annual estimate. It directly addresses the scenario of planning a new web application with no existing usage data.
C
AWS Cost Explorer
Why it fails: AWS Cost Explorer analyzes historical cost and usage data, with interactive charts for filtering by service, region, or tag to identify billing trends. Its forecasting features extrapolate from past usage, so they are meaningless for a workload that has never been deployed; there are no configuration inputs for CPUs, storage sizes, or pricing plans. Therefore, it is a post-launch analysis tool, not a pre-deployment pricing estimator.
D
AWS Budgets
Why it fails: AWS Budgets is a cost governance service that tracks actual and forecasted spend against the thresholds you define, sending alerts or triggering actions when limits are exceeded. It only works with resources that already exist in your account and have generated cost data, so it cannot model a not-yet-built architecture or compare pricing options. Using it to estimate a new deployment would be impossible because there is no billing history to evaluate.

Question 12mediummultiple choice

A company wants to purchase EC2 capacity that provides a discount over On-Demand pricing and is available only when AWS has excess capacity, with the option of interruption with a 2-minute warning. Which option is this?

Trap 1: Reserved Instances

Reserved Instances offer a lower hourly rate in exchange for a 1-year or 3-year commitment, not because they use spare capacity. They are not interruptible—once you purchase a Reserved Instance, your capacity is guaranteed for the entire term, regardless of AWS's spare capacity levels. The scenario specifically requires instances that can be interrupted when AWS needs the capacity back, and it makes no mention of a long-term commitment; therefore, Reserved Instances do not match the described use case.

Trap 2: On-Demand Instances

On-Demand Instances are incorrect as they do not provide a discount over their standard pricing and are not subject to interruption, failing to meet the scenario's requirements for cost savings and interruptibility based on excess capacity. This option is tempting because it offers immediate availability and sustained capacity for applications that cannot tolerate interruptions, making it suitable for critical, unpredictable workloads where flexibility and guaranteed uptime are prioritised over cost optimisation.

Trap 3: Dedicated Instances

Dedicated Instances run on physical hardware that is dedicated exclusively to your AWS account, providing strong isolation for compliance or licensing requirements. They are not related to spare capacity and do not receive any discount for being interruptible; in fact, they are more expensive than standard On-Demand Instances. Because the scenario asks for low-cost, interruptible capacity based on excess AWS resources, Dedicated Instances fail on both cost reduction and interruption tolerance, making them incorrect.

A
Reserved Instances
Why it fails: Reserved Instances offer a lower hourly rate in exchange for a 1-year or 3-year commitment, not because they use spare capacity. They are not interruptible—once you purchase a Reserved Instance, your capacity is guaranteed for the entire term, regardless of AWS's spare capacity levels. The scenario specifically requires instances that can be interrupted when AWS needs the capacity back, and it makes no mention of a long-term commitment; therefore, Reserved Instances do not match the described use case.
B
On-Demand Instances
Why it fails: On-Demand Instances are incorrect as they do not provide a discount over their standard pricing and are not subject to interruption, failing to meet the scenario's requirements for cost savings and interruptibility based on excess capacity. This option is tempting because it offers immediate availability and sustained capacity for applications that cannot tolerate interruptions, making it suitable for critical, unpredictable workloads where flexibility and guaranteed uptime are prioritised over cost optimisation.
C
Spot Instances
Spot Instances are the only option that meets the scenario's requirements: they let you use AWS's unused EC2 capacity at a discount of up to 90% compared to On-Demand pricing. The trade-off is that AWS can reclaim this capacity with a 2-minute warning when it needs it back for other workloads, making them ideal for fault-tolerant, interruption-tolerant applications. The discount is directly tied to the availability of spare capacity, and if capacity is no longer available, the instance is interrupted—this matches the scenario precisely.
D
Dedicated Instances
Why it fails: Dedicated Instances run on physical hardware that is dedicated exclusively to your AWS account, providing strong isolation for compliance or licensing requirements. They are not related to spare capacity and do not receive any discount for being interruptible; in fact, they are more expensive than standard On-Demand Instances. Because the scenario asks for low-cost, interruptible capacity based on excess AWS resources, Dedicated Instances fail on both cost reduction and interruption tolerance, making them incorrect.

Question 13easymultiple choice

Which Amazon EC2 pricing option allows customers to bid for unused EC2 capacity with potential savings of up to 90%, while accepting that instances may be interrupted?

Trap 1: On-Demand Instances

On-Demand Instances are a poor fit for this question because they offer full compute capacity at standard, non-discounted prices with no risk of interruption. Unlike Spot Instances, they are not sourced from AWS's unused spare capacity and are never reclaimed based on fluctuating capacity needs, making them the opposite of the cost-efficient, interruptible option the scenario requires.

Trap 2: Reserved Instances

Reserved Instances are incorrect here because they deliver a discount through a steady 1- or 3-year commitment, not by tapping into spare capacity. While they can provide a capacity reservation and lower costs compared to On-Demand, they are not subject to the two-minute reclaim notice that characterizes Spot Instances, and the pricing is fixed by upfront commitment rather than dynamic spot market pricing.

Trap 3: Dedicated Instances

Dedicated Instances are wrong because they focus on physical isolation by running your instances on hardware dedicated to a single customer, not on using spare capacity for discount pricing. They actually cost more than standard On-Demand instances due to the dedicated hardware premium, and they are never reclaimed by AWS, so they do not match the 'spare capacity with interruption risk' concept that defines Spot Instances.

A
On-Demand Instances
Why it fails: On-Demand Instances are a poor fit for this question because they offer full compute capacity at standard, non-discounted prices with no risk of interruption. Unlike Spot Instances, they are not sourced from AWS's unused spare capacity and are never reclaimed based on fluctuating capacity needs, making them the opposite of the cost-efficient, interruptible option the scenario requires.
B
Reserved Instances
Why it fails: Reserved Instances are incorrect here because they deliver a discount through a steady 1- or 3-year commitment, not by tapping into spare capacity. While they can provide a capacity reservation and lower costs compared to On-Demand, they are not subject to the two-minute reclaim notice that characterizes Spot Instances, and the pricing is fixed by upfront commitment rather than dynamic spot market pricing.
C
Spot Instances
Spot Instances are the correct answer because they let you use AWS's spare EC2 capacity at discounts reaching up to 90%, with the critical trade-off that AWS can reclaim the instance with only a two-minute notice when that capacity is needed elsewhere. This makes them ideal for stateless, fault-tolerant, or flexible workloads, but you must design applications to handle sudden interruptions—exactly the behavior the question is testing.
D
Dedicated Instances
Why it fails: Dedicated Instances are wrong because they focus on physical isolation by running your instances on hardware dedicated to a single customer, not on using spare capacity for discount pricing. They actually cost more than standard On-Demand instances due to the dedicated hardware premium, and they are never reclaimed by AWS, so they do not match the 'spare capacity with interruption risk' concept that defines Spot Instances.

Question 14mediummatching

Match each AWS pricing concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Pay for compute capacity by the hour/second

Significant discount for 1-3 year commitment

Unused EC2 capacity at steep discount

Flexible pricing model for compute usage

Limited free usage for new customers

Trap 1: On-Demand: Pay a low price but instances can be terminated.

This description incorrectly pairs On-Demand with Spot behavior. On-Demand instances are not terminated due to pricing conditions; they run reliably until you stop or terminate them, and you pay the full On-Demand rate per hour or second without interruption. The ability to be terminated at low cost is a characteristic of Spot Instances, not On-Demand.

Trap 2: Reserved Instances: Pay only for resources used per second.

This statement confuses On-Demand pricing with Reserved Instances. Reserved Instances require a 1- or 3-year commitment for a specific instance family and region, and billing is based on the hourly rate for the reserved capacity, not per-second usage. Per-second metering is a feature of On-Demand and Savings Plans, not of Reserved Instances.

A
On-Demand: Pay for compute capacity by the hour or second with no long-term commitments.
On-Demand pricing is the standard pay-as-you-go model for EC2, with no upfront payment and no long-term commitment. You are billed per second (minimum 60 seconds) for compute capacity, giving you full flexibility to scale up or down. This is the correct definition of On-Demand pricing.
B
Reserved Instances: Reserve capacity and receive a discount in exchange for a 1- or 3-year commitment.
Reserved Instances provide a significant discount (up to 72%) compared to On-Demand, in exchange for a commitment to a specific instance configuration for 1 or 3 years. You reserve capacity in a particular Availability Zone, ensuring it is available when needed, and you pay a reduced hourly rate. This accurately defines Reserved Instances.
C
Spot Instances: Purchase unused EC2 capacity at a significant discount, but instances can be interrupted.
Spot Instances allow you to bid for unused EC2 capacity, often at up to 90% discount from On-Demand prices. However, these instances can be reclaimed by AWS with a two-minute warning when EC2 needs the capacity back, making them interruptible. This is the correct definition of Spot Instances.
D
Savings Plans: Flexible pricing model offering lower prices in exchange for a commitment to a consistent amount of usage for 1 or 3 years.
Savings Plans are a flexible pricing model where you commit to a consistent amount of compute usage (measured in $/hour) for a 1- or 3-year term, in exchange for lower rates (up to 72% off On-Demand). Unlike Reserved Instances, Savings Plans automatically apply to any instance family, size, region, or OS within EC2, Fargate, and Lambda. This definition correctly captures the essence of Savings Plans.
E
On-Demand: Pay a low price but instances can be terminated.
Why it fails: This description incorrectly pairs On-Demand with Spot behavior. On-Demand instances are not terminated due to pricing conditions; they run reliably until you stop or terminate them, and you pay the full On-Demand rate per hour or second without interruption. The ability to be terminated at low cost is a characteristic of Spot Instances, not On-Demand.
F
Reserved Instances: Pay only for resources used per second.
Why it fails: This statement confuses On-Demand pricing with Reserved Instances. Reserved Instances require a 1- or 3-year commitment for a specific instance family and region, and billing is based on the hourly rate for the reserved capacity, not per-second usage. Per-second metering is a feature of On-Demand and Savings Plans, not of Reserved Instances.

Question 15mediummultiple choice

A company traditionally operated an on-premises data center and purchased all server hardware and software licenses with upfront capital expenditure. After migrating its workloads to AWS, the company now receives a monthly invoice that reflects only the compute hours, storage, and data transfer that it actually used. The company can also stop paying for resources when they are no longer needed. Which key characteristic of cloud computing does this scenario best illustrate?

Trap 1: Elasticity

Elasticity is the ability to automatically provision and de-provision compute resources in response to changing demand. While this is an important cloud characteristic, the scenario specifically highlights the change in payment model from upfront capital to monthly variable costs, not automatic scaling.

Trap 2: Global reach

Global reach refers to the ability to deploy applications in AWS Regions around the world to reduce latency and meet data residency requirements. The scenario does not mention geographic distribution; it focuses on the financial model of paying for usage.

Trap 3: Security

Security is a shared responsibility between AWS and the customer and includes areas like data protection, identity management, and compliance. The scenario does not discuss security controls or practices; it centers on the change in cost structure.

A
Elasticity
Why it fails: Elasticity is the ability to automatically provision and de-provision compute resources in response to changing demand. While this is an important cloud characteristic, the scenario specifically highlights the change in payment model from upfront capital to monthly variable costs, not automatic scaling.
B
Pay-as-you-go pricing (variable expense)
This is correct. The scenario describes transitioning from a CAPEX model (buying hardware upfront) to an OPEX model where the company pays only for the resources it actually uses each month. This is the 'pay-as-you-go' characteristic of cloud computing, which avoids large upfront investments and matches costs to usage.
C
Global reach
Why it fails: Global reach refers to the ability to deploy applications in AWS Regions around the world to reduce latency and meet data residency requirements. The scenario does not mention geographic distribution; it focuses on the financial model of paying for usage.
D
Security
Why it fails: Security is a shared responsibility between AWS and the customer and includes areas like data protection, identity management, and compliance. The scenario does not discuss security controls or practices; it centers on the change in cost structure.

Question 16mediummultiple choice

A company is planning to migrate a legacy application to AWS and wants to estimate the monthly cost of running the new workload. The company needs to compare costs across different Amazon EC2 instance types, regions, and pricing models (On-Demand, Reserved, and Spot). The team also wants to include estimated costs for related services such as Amazon EBS storage and data transfer. Which AWS tool should the company use to generate this cost estimate?

Trap 1: AWS Cost Explorer

AWS Cost Explorer is incorrect because it is a cost management tool that visualizes and analyzes historical AWS usage and spending after resources have been deployed. While it can provide forecasts based on past consumption patterns, it cannot generate a pre-deployment estimate for a new, not-yet-deployed legacy application migration. Cost Explorer lacks the capability to model hypothetical workloads with specific EC2 instance types, regions, or pricing models.

Trap 2: AWS Budgets

Incorrect. AWS Budgets allows you to set custom budgets and receive alerts when costs or usage exceed (or are forecasted to exceed) your budgeted amount. It does not create upfront cost estimates for new services.

Trap 3: AWS Trusted Advisor

Incorrect. AWS Trusted Advisor inspects your AWS environment and offers recommendations to help you follow best practices, such as optimizing costs on underutilized resources. It does not provide cost estimation for new workloads before deployment.

A
AWS Pricing Calculator
Correct. The AWS Pricing Calculator is designed to produce cost estimates for new AWS workloads. You can select specific EC2 instance types, pricing models, regions, and associated services like EBS and data transfer to get a monthly estimate.
B
AWS Cost Explorer
Why it fails: AWS Cost Explorer is incorrect because it is a cost management tool that visualizes and analyzes historical AWS usage and spending after resources have been deployed. While it can provide forecasts based on past consumption patterns, it cannot generate a pre-deployment estimate for a new, not-yet-deployed legacy application migration. Cost Explorer lacks the capability to model hypothetical workloads with specific EC2 instance types, regions, or pricing models.
C
AWS Budgets
Why it fails: Incorrect. AWS Budgets allows you to set custom budgets and receive alerts when costs or usage exceed (or are forecasted to exceed) your budgeted amount. It does not create upfront cost estimates for new services.
D
AWS Trusted Advisor
Why it fails: Incorrect. AWS Trusted Advisor inspects your AWS environment and offers recommendations to help you follow best practices, such as optimizing costs on underutilized resources. It does not provide cost estimation for new workloads before deployment.

Question 17mediummultiple choice

A startup is planning to migrate its web application to AWS. The CTO wants to estimate the monthly cost of running the application on Amazon EC2 and Amazon RDS, including data transfer costs. The team has not yet created any AWS accounts or resources. They need a tool that allows them to input assumptions about instance types, storage, and data transfer to generate a detailed cost estimate. Which AWS tool should they use?

Trap 1: AWS Cost Explorer

AWS Cost Explorer provides visibility into historical spending and usage, along with forecasts that are extrapolated from existing billing data. Because it has no knowledge of your planned workload specifications—like instance types, storage sizes, or data transfer patterns—it cannot simulate a future migration cost estimate. Cost Explorer requires an active AWS account with past usage data, making it an incorrect choice for planning a migration before resources are created.

Trap 2: AWS Budgets

AWS Budgets allows you to set custom cost and usage budgets and receive alerts when you exceed or are forecasted to exceed your budget. It does not provide a way to estimate costs for a planned migration before any resources exist.

Trap 3: AWS Trusted Advisor

AWS Trusted Advisor is an operational expertise tool that scans an already-active AWS environment for best-practice checks across cost optimization, security, performance, and fault tolerance. It can detect idle resources or underutilized EC2 instances, but it cannot model your intended migration architecture before any resources exist. Therefore, Trusted Advisor is useless for pre-migration cost estimation and only becomes relevant after you have deployed workloads.

A
AWS Cost Explorer
Why it fails: AWS Cost Explorer provides visibility into historical spending and usage, along with forecasts that are extrapolated from existing billing data. Because it has no knowledge of your planned workload specifications—like instance types, storage sizes, or data transfer patterns—it cannot simulate a future migration cost estimate. Cost Explorer requires an active AWS account with past usage data, making it an incorrect choice for planning a migration before resources are created.
B
AWS Budgets
Why it fails: AWS Budgets allows you to set custom cost and usage budgets and receive alerts when you exceed or are forecasted to exceed your budget. It does not provide a way to estimate costs for a planned migration before any resources exist.
C
AWS Pricing Calculator
The AWS Pricing Calculator is a free web-based tool that lets you estimate the cost of AWS services based on your specific input parameters, such as instance types, storage, and data transfer. It is ideal for planning a migration before any AWS resources are created.
D
AWS Trusted Advisor
Why it fails: AWS Trusted Advisor is an operational expertise tool that scans an already-active AWS environment for best-practice checks across cost optimization, security, performance, and fault tolerance. It can detect idle resources or underutilized EC2 instances, but it cannot model your intended migration architecture before any resources exist. Therefore, Trusted Advisor is useless for pre-migration cost estimation and only becomes relevant after you have deployed workloads.

Question 18mediummultiple choice

A company runs a monthly batch data analytics job that requires 50 compute instances for exactly 2 hours. On AWS, the company launches 50 Amazon EC2 instances, runs the job, and then terminates all instances. The company's AWS bill shows a charge for only 100 instance-hours (50 instances × 2 hours). Which essential characteristic of cloud computing does this billing model best demonstrate?

Trap 1: Resource pooling

Resource pooling refers to the provider's computing resources being pooled to serve multiple customers, with physical and virtual resources dynamically assigned based on demand. While AWS does pool resources, the billing aspect in this scenario is not about pooling; it is about paying only for what is used.

Trap 2: On-demand self-service

On-demand self-service allows a consumer to provision computing capabilities unilaterally without requiring human interaction. Although the company does launch and terminate instances without manual approval, the question specifically asks about the billing model, which is not the primary characteristic demonstrated by on-demand self-service.

Trap 3: Rapid elasticity

Rapid elasticity enables resources to be quickly scaled up and down. The company scales from 0 to 50 instances and back, but the billing model—paying only for the resources consumed—is the key point, not the speed of scaling.

A
Resource pooling
Why it fails: Resource pooling refers to the provider's computing resources being pooled to serve multiple customers, with physical and virtual resources dynamically assigned based on demand. While AWS does pool resources, the billing aspect in this scenario is not about pooling; it is about paying only for what is used.
B
Measured service
Measured service means that cloud resource usage is metered, monitored, controlled, and reported, enabling a pay-per-use billing model. In this scenario, the company is charged exactly for the 100 instance-hours consumed, which is a direct application of measured service.
C
On-demand self-service
Why it fails: On-demand self-service allows a consumer to provision computing capabilities unilaterally without requiring human interaction. Although the company does launch and terminate instances without manual approval, the question specifically asks about the billing model, which is not the primary characteristic demonstrated by on-demand self-service.
D
Rapid elasticity
Why it fails: Rapid elasticity enables resources to be quickly scaled up and down. The company scales from 0 to 50 instances and back, but the billing model—paying only for the resources consumed—is the key point, not the speed of scaling.

Question 19mediummultiple choice

A company operates in three separate AWS accounts: one for development, one for testing, and one for production. The company wants to take advantage of volume pricing discounts across all accounts for services such as Amazon S3 and Amazon EC2. The finance team also wants to view a single, consolidated monthly bill that aggregates charges from all accounts. Which AWS feature should the company implement?

Trap 1: AWS Cost Explorer

AWS Cost Explorer is a tool for visualizing, understanding, and managing AWS costs and usage over time. It does not consolidate billing across multiple accounts; it only displays cost data for the accounts that are already linked via consolidated billing.

Trap 2: AWS Budgets

AWS Budgets lets you define cost and usage thresholds and trigger alerts when actual or forecasted spending surpasses those limits. While you can create budgets that track combined spend across multiple accounts, Budgets relies on existing consolidated billing infrastructure to see those accounts as a single cost pool. It does not provide the account-linking mechanism itself; instead, it consumes the aggregated cost data that AWS Organizations' consolidated billing produces. Therefore, Budgets cannot consolidate the three accounts' billing by itself.

Trap 3: AWS Trusted Advisor

AWS Trusted Advisor performs automated checks against your environment and delivers recommendations across cost optimization, performance, security, and fault tolerance. It can flag idle resources or suggest reserved capacity purchases, but it does not merge or aggregate usage data from multiple independent AWS accounts into a single billing view. Its cost recommendations operate within the context of existing account relationships, so without AWS Organizations consolidated billing, it cannot unify three separate accounts onto one invoice.

A
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 consolidate billing across multiple accounts; it only displays cost data for the accounts that are already linked via consolidated billing.
B
AWS Budgets
Why it fails: AWS Budgets lets you define cost and usage thresholds and trigger alerts when actual or forecasted spending surpasses those limits. While you can create budgets that track combined spend across multiple accounts, Budgets relies on existing consolidated billing infrastructure to see those accounts as a single cost pool. It does not provide the account-linking mechanism itself; instead, it consumes the aggregated cost data that AWS Organizations' consolidated billing produces. Therefore, Budgets cannot consolidate the three accounts' billing by itself.
C
AWS Organizations with consolidated billing
Consolidated billing is a feature of AWS Organizations that aggregates the usage of all member accounts into a single bill for the management (payer) account. This enables volume discounts across all accounts and simplifies billing administration.
D
AWS Trusted Advisor
Why it fails: AWS Trusted Advisor performs automated checks against your environment and delivers recommendations across cost optimization, performance, security, and fault tolerance. It can flag idle resources or suggest reserved capacity purchases, but it does not merge or aggregate usage data from multiple independent AWS accounts into a single billing view. Its cost recommendations operate within the context of existing account relationships, so without AWS Organizations consolidated billing, it cannot unify three separate accounts onto one invoice.

Question 20mediummultiple choice

A company is currently running its IT infrastructure in an on-premises data center. The finance department wants to understand how moving to the AWS Cloud would change the company's cost structure. In particular, they want to avoid large upfront hardware purchases and instead pay only for the resources they consume on a monthly basis. Which key cloud computing concept does this shift represent?

Trap 1: Elasticity

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.

Trap 2: Economies of scale

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.

Trap 3: High availability

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.

A
Elasticity
Why it fails: 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.
B
Economies of scale
Why it fails: 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.
C
Pay-as-you-go pricing
Pay-as-you-go is a pricing model where customers pay only for the resources they consume, with no upfront commitments. This directly addresses the finance department's desire to avoid large upfront hardware purchases and shift to a variable monthly expense model.
D
High availability
Why it fails: 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.