Cost Optimization practice questions

Which TWO actions improve the security of an S3 bucket that stores sensitive data?

Trap 1: Enable S3 Transfer Acceleration.

Transfer Acceleration speeds uploads and downloads through edge locations; it adds no authorisation, encryption or monitoring control over the sensitive objects. It tempts because it is a legitimate S3 feature, correct when the requirement is improving throughput for geographically distant clients.

Trap 2: Configure a lifecycle policy to transition objects to Glacier.

Lifecycle transitions to Glacier change storage class and cost, not access control, encryption or logging, so sensitive objects remain equally exposed. It tempts because lifecycle policies are a genuine S3 management feature, correct when the goal is archival or cost reduction rather than security hardening.

Trap 3: Enable S3 Select to filter data.

S3 Select filters object contents during retrieval; it neither restricts who may read objects nor encrypts them, so it leaves the bucket's exposure unchanged. It tempts because it is a real S3 capability, appropriate when the requirement is reducing data transferred for analytics queries.

A
Enable default encryption with SSE-S3 or SSE-KMS.
SSE-S3 or SSE-KMS encrypts objects at rest, so data written to the bucket is unreadable without the corresponding key. This directly satisfies the sensitive-data protection requirement, mitigating exposure if storage media or snapshots are compromised.
B
Block all public access using the S3 Block Public Access feature.
S3 Block Public Access overrides bucket policies and ACLs that would otherwise grant anonymous or public access, closing accidental exposure paths. It satisfies the sensitive-data constraint by preventing any public read or write regardless of individual object permissions.
C
Enable S3 Transfer Acceleration.
Why it fails: Transfer Acceleration speeds uploads and downloads through edge locations; it adds no authorisation, encryption or monitoring control over the sensitive objects. It tempts because it is a legitimate S3 feature, correct when the requirement is improving throughput for geographically distant clients.
D
Configure a lifecycle policy to transition objects to Glacier.
Why it fails: Lifecycle transitions to Glacier change storage class and cost, not access control, encryption or logging, so sensitive objects remain equally exposed. It tempts because lifecycle policies are a genuine S3 management feature, correct when the goal is archival or cost reduction rather than security hardening.
E
Enable S3 Select to filter data.
Why it fails: S3 Select filters object contents during retrieval; it neither restricts who may read objects nor encrypts them, so it leaves the bucket's exposure unchanged. It tempts because it is a real S3 capability, appropriate when the requirement is reducing data transferred for analytics queries.

Question 2mediummultiple choice

A company is migrating a large-scale batch processing system from on-premises to AWS. The system runs millions of short-lived jobs each day. The company wants to minimize operational overhead and cost. Which AWS compute service should the company use?

Trap 1: Amazon EC2 with Spot Fleet

Spot Fleet still requires the company to manage instance fleets, AMIs, and interruption handling, which does not minimise operational overhead for millions of short-lived jobs. Spot suits long-running, interruption-tolerant workloads such as continuous batch or CI runners, where capacity cost, not per-job orchestration, dominates.

Trap 2: Amazon ECS with AWS Fargate

Fargate still requires the team to build images, define task definitions, and manage cluster capacity and scheduling, adding operational overhead for millions of short-lived jobs. Fargate suits containerised services or long-running batch tasks where container portability matters more than per-job invocation cost.

Trap 3: AWS Lambda

Lambda is the correct answer here; it is not incorrect. It runs each short-lived job without servers, scaling automatically and charging per invocation, which minimises both operational overhead and cost for millions of daily jobs. No analysis of an incorrect option is required.

A
Amazon EC2 with Spot Fleet
Why it fails: Spot Fleet still requires the company to manage instance fleets, AMIs, and interruption handling, which does not minimise operational overhead for millions of short-lived jobs. Spot suits long-running, interruption-tolerant workloads such as continuous batch or CI runners, where capacity cost, not per-job orchestration, dominates.
B
Amazon ECS with AWS Fargate
Why it fails: Fargate still requires the team to build images, define task definitions, and manage cluster capacity and scheduling, adding operational overhead for millions of short-lived jobs. Fargate suits containerised services or long-running batch tasks where container portability matters more than per-job invocation cost.
C
AWS Lambda
Why it fails: Lambda is the correct answer here; it is not incorrect. It runs each short-lived job without servers, scaling automatically and charging per invocation, which minimises both operational overhead and cost for millions of daily jobs. No analysis of an incorrect option is required.
D
AWS Batch
AWS Batch dynamically provisions optimal compute (Spot or On-Demand) for millions of short-lived jobs, queues and schedules them automatically, and scales to zero between runs. This removes cluster management overhead and cuts cost versus continuously running servers.

Question 3mediummulti select

A company is designing a new solution that requires a highly available and scalable architecture for a stateless web application. The application will run on Amazon EC2 instances behind an Application Load Balancer (ALB). The company wants to ensure that the instances are automatically replaced if they fail health checks and that the application scales based on demand. The company also wants to minimize costs by using a mix of On-Demand and Spot Instances. Which two actions should be taken to meet these requirements? (Choose two.)

Trap 1: Use Spot Fleet with a diversified allocation strategy to launch…

Spot Fleet can launch a mix of Spot and On-Demand instances, but it does not provide the same integration with Auto Scaling groups for automatic replacement based on health checks. It also does not automatically scale based on demand; you would need to manage scaling separately. This option does not meet the requirement for automatic scaling and health-based replacement.

Trap 2: Configure a scheduled scaling policy to add instances every hour to…

Scheduled scaling is based on time, not demand. It does not automatically scale based on actual load, which is required. It could lead to over-provisioning or under-provisioning. The scenario requires scaling based on demand, so a dynamic scaling policy (e.g., target tracking) is needed. Scheduled scaling alone does not meet the requirement.

Trap 3: Enable termination protection on all EC2 instances to prevent…

Termination protection prevents accidental termination but does not help with automatic replacement of unhealthy instances or scaling based on demand. It could actually hinder the Auto Scaling group from replacing instances. This option does not meet the requirements and may interfere with the desired behavior.

A
Use Spot Fleet with a diversified allocation strategy to launch instances across multiple instance types and Availability Zones.
Why it fails: Spot Fleet can launch a mix of Spot and On-Demand instances, but it does not provide the same integration with Auto Scaling groups for automatic replacement based on health checks. It also does not automatically scale based on demand; you would need to manage scaling separately. This option does not meet the requirement for automatic scaling and health-based replacement.
B
Attach the Auto Scaling group to the ALB target group, and configure the group to use ELB health checks.
Attaching the Auto Scaling group to the ALB target group and enabling ELB health checks ensures that instances failing ALB health checks are automatically replaced. This integrates the scaling group with the load balancer for health monitoring and replacement, meeting the requirement for automatic replacement of failed instances.
C
Configure a scheduled scaling policy to add instances every hour to handle expected traffic increases.
Why it fails: Scheduled scaling is based on time, not demand. It does not automatically scale based on actual load, which is required. It could lead to over-provisioning or under-provisioning. The scenario requires scaling based on demand, so a dynamic scaling policy (e.g., target tracking) is needed. Scheduled scaling alone does not meet the requirement.
D
Create an Auto Scaling group with a launch template that specifies multiple instance types and purchase options, and configure the group to use a mixed instances policy.
An Auto Scaling group with a mixed instances policy allows you to use a combination of On-Demand and Spot Instances, and multiple instance types, to increase availability and reduce costs. This meets the requirement for a mix of purchase options and automatic scaling. The group also replaces unhealthy instances based on health checks.
E
Enable termination protection on all EC2 instances to prevent accidental termination.
Why it fails: Termination protection prevents accidental termination but does not help with automatic replacement of unhealthy instances or scaling based on demand. It could actually hinder the Auto Scaling group from replacing instances. This option does not meet the requirements and may interfere with the desired behavior.

Question 4hardmultiple choice

A company uses AWS CodeBuild to run unit tests. The build process is taking longer than expected. The buildspec.yml file includes a pre-build phase that downloads dependencies from a public repository. What is the most effective way to reduce build time?

Trap 1: Run the build in parallel across multiple build projects.

Parallel build projects split separate workloads; they do not shorten a single build whose pre-build phase serially downloads dependencies. It is tempting because parallelism genuinely reduces aggregate pipeline duration, and would be correct if the pipeline ran many independent build jobs that could execute concurrently.

Trap 2: Increase the compute type of the build environment to use more…

More vCPUs do not accelerate a network-bound dependency download in the pre-build phase, which is limited by repository throughput rather than compute. It is tempting because larger compute types speed up CPU-intensive compilation, and would be correct if the bottleneck were compilation or test execution rather than fetching packages.

Trap 3: Reduce the build timeout setting to force faster execution.

The build timeout is a maximum duration limit; lowering it aborts the build rather than making any phase execute faster. It is tempting because it appears to cap wasted time, and would be correct if the goal were to fail stalled builds early rather than to reduce actual build duration.

A
Configure the build project to use an S3 cache for dependencies.
An S3 cache bucket stores the downloaded dependencies between runs, so the pre-build phase retrieves them from S3 rather than re-downloading from the public repository. This directly addresses the stem's constraint: repeated dependency downloads inflating build duration. CodeBuild restores the cache before the pre-build phase, cutting that wait.
B
Run the build in parallel across multiple build projects.
Why it fails: Parallel build projects split separate workloads; they do not shorten a single build whose pre-build phase serially downloads dependencies. It is tempting because parallelism genuinely reduces aggregate pipeline duration, and would be correct if the pipeline ran many independent build jobs that could execute concurrently.
C
Increase the compute type of the build environment to use more vCPUs.
Why it fails: More vCPUs do not accelerate a network-bound dependency download in the pre-build phase, which is limited by repository throughput rather than compute. It is tempting because larger compute types speed up CPU-intensive compilation, and would be correct if the bottleneck were compilation or test execution rather than fetching packages.
D
Reduce the build timeout setting to force faster execution.
Why it fails: The build timeout is a maximum duration limit; lowering it aborts the build rather than making any phase execute faster. It is tempting because it appears to cap wasted time, and would be correct if the goal were to fail stalled builds early rather than to reduce actual build duration.

Question 5mediummatching

Match each AWS cost management tool to its use.

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

Concepts

Matches

Visualize and explore cost and usage data

Set custom cost and usage budgets with alerts

Recommendations for cost optimization, performance, security

Flexible pricing model for compute savings

Recommend optimal compute resources based on usage

Trap 1: AWS Cost Explorer: A service that automatically reduces costs by…

Incorrect — this describes AWS Savings Plans or Cost Optimizer, not Cost Explorer.

Trap 2: AWS Budgets: A report that includes all cost and usage data in CSV…

Incorrect — this describes the Cost and Usage Report, not AWS Budgets.

A
AWS Cost Explorer: A visual tool that enables you to view and analyze your AWS costs and usage.
Cost Explorer provides an intuitive interface to explore historical cost data and identify spending patterns.
B
AWS Budgets: Custom budgets that send alerts when costs or usage exceed (or are forecasted to exceed) your budgeted amount.
AWS Budgets help you set spending limits and receive notifications to avoid unexpected charges.
C
AWS Trusted Advisor: Provides best practice checks and recommendations for cost optimization, security, and performance.
Trusted Advisor analyzes your AWS environment and suggests improvements to save money and increase efficiency.
D
AWS Cost and Usage Report (CUR): The most comprehensive set of AWS cost and usage data, available for querying with Athena.
CUR delivers granular data for detailed analysis, often used with Athena, QuickSight, or third-party tools.
E
AWS Cost Explorer: A service that automatically reduces costs by applying savings plans.
Why it fails: Incorrect — this describes AWS Savings Plans or Cost Optimizer, not Cost Explorer.
F
AWS Budgets: A report that includes all cost and usage data in CSV format.
Why it fails: Incorrect — this describes the Cost and Usage Report, not AWS Budgets.

Question 6easymulti select

A company is designing a cost-effective architecture for a batch processing job that runs nightly. The job can tolerate interruptions and requires significant compute power for a few hours. The company wants to minimize costs. Which TWO strategies should the company use?

Trap 1: Purchase Reserved Instances (RI) for a 1-year term.

Reserved Instances bill a steady hourly commitment across the full one-year term, so idle hours between nightly runs are still charged. They are tempting because they cut compute cost substantially, which suits predictable, continuously running workloads rather than short, interruptible nightly batches.

Trap 2: Use On-Demand Instances to ensure availability.

On-Demand Instances carry the highest hourly rate with no discount mechanism, so paying full price for a few hours nightly defeats the cost-minimisation goal. They are tempting because they guarantee capacity without commitment, which suits unpredictable or short-lived workloads that cannot tolerate interruption.

Trap 3: Use Dedicated Hosts for compliance.

Dedicated Hosts charge for the entire physical server plus a per-host fee, and the workload's tolerance for interruption is irrelevant to that billing model. They are tempting because they give full control over socket and core visibility, which suits licensing and compliance-bound workloads, not cost-driven batch processing.

A
Use Spot Instances for compute.
Spot Instances deliver up to 90% discounts versus On-Demand by using spare EC2 capacity, and the job's tolerance of interruptions matches Spot's two-minute termination notice. This satisfies the minimise-cost constraint for a fault-tolerant nightly batch workload.
B
Purchase Reserved Instances (RI) for a 1-year term.
Why it fails: Reserved Instances bill a steady hourly commitment across the full one-year term, so idle hours between nightly runs are still charged. They are tempting because they cut compute cost substantially, which suits predictable, continuously running workloads rather than short, interruptible nightly batches.
C
Configure Auto Scaling to scale out during the job and scale in after.
Auto Scaling adds instances only while the nightly job runs and removes them afterwards, so you pay for capacity solely during the few hours of compute. This satisfies the minimise-cost constraint by eliminating idle overnight capacity.
D
Use On-Demand Instances to ensure availability.
Why it fails: On-Demand Instances carry the highest hourly rate with no discount mechanism, so paying full price for a few hours nightly defeats the cost-minimisation goal. They are tempting because they guarantee capacity without commitment, which suits unpredictable or short-lived workloads that cannot tolerate interruption.
E
Use Dedicated Hosts for compliance.
Why it fails: Dedicated Hosts charge for the entire physical server plus a per-host fee, and the workload's tolerance for interruption is irrelevant to that billing model. They are tempting because they give full control over socket and core visibility, which suits licensing and compliance-bound workloads, not cost-driven batch processing.