AWS SysOps Cost and Performance Optimization: 60 practice questions

12 of the 60 Cost and Performance Optimization questions in the Certsqill AWS SysOps bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS SysOps? Take the free 5-min readiness check →

1. AWS Cost Explorer: Which AWS tool provides this capability?

1. AWS Cost Explorer — provides interactive charts and filtering to analyze costs by service, instance type, region, account, and tags over custom date ranges ✓

   AWS Cost Explorer provides detailed cost visualization and filtering. Costs can be filtered and grouped by service, instance type, resource tag, region, and linked account. It supports up to 13 months of historical data.
2. AWS Trusted Advisor — identifies underutilized EC2 instances and provides cost optimization recommendations to help reduce spend across all accounts over time

   Trusted Advisor identifies cost savings opportunities (e.g., idle instances) but does not provide historical spend analysis or cost breakdown by instance type. Cost Explorer is the appropriate tool for spend analysis.
3. AWS Budgets — tracks current and forecasted spend against configured budget thresholds and sends alerts when EC2 costs approach the defined limits

   AWS Budgets tracks spend against budget thresholds and sends alerts. It provides high-level spend tracking, not the granular interactive cost analysis and instance-type breakdown available in Cost Explorer.
4. AWS CloudWatch — provides per-instance EC2 billing metrics and dashboards that can be filtered by instance type for historical cost analysis

   CloudWatch provides operational metrics (CPU, network, etc.) and billing alerts but does not provide the interactive cost breakdown and filtering capabilities of Cost Explorer.

AWS Cost Explorer provides interactive cost analysis with filtering by service, instance type, region, and tags over custom time ranges up to 13 months.

2. Cost Explorer RI and Savings Plans recommendations: Which Cost Explorer feature provides this analysis?

1. AWS Budgets Actions — automatically purchases Reserved Instances on the account's behalf whenever monthly EC2 spend exceeds the configured budget thresholds

   AWS Budgets Actions can restrict IAM permissions or apply SCPs when budgets are exceeded. They do not automatically purchase Reserved Instances.
2. Cost Explorer RI and Savings Plans recommendations — analyzes usage patterns and recommends specific reservation purchases with estimated savings ✓

   Cost Explorer provides dedicated recommendation pages for Reserved Instances and Savings Plans. It analyzes historical usage patterns and recommends specific RI purchases (instance type, term, payment option) or Savings Plan commitment levels with projected savings percentages and payback periods.
3. AWS Compute Optimizer — analyzes EC2 usage metrics and recommends the best instance types and sizes to commit to for the greatest cost savings

   AWS Compute Optimizer recommends right-sizing EC2 instances and instance types based on actual utilization metrics. It does not recommend RI purchases or Savings Plans commitment levels.
4. AWS Trusted Advisor Low Utilization Amazon EC2 Instances check — identifies consistently busy instances that are strong candidates for RI purchase

   Trusted Advisor's EC2 low utilization check identifies idle instances to terminate, not instances suitable for RI purchase. RI recommendations require consistent high utilization, not low utilization.

Cost Explorer's RI and Savings Plans recommendations analyze historical usage to recommend specific purchases with estimated savings percentages and payback periods.

3. Convertible Reserved Instances: Which type of Reserved Instance allows this change?

1. Scheduled Reserved Instances — allow schedule and instance family changes to accommodate different instance types during a recurring reservation window

   Scheduled Reserved Instances (for predictable recurring workloads) are a legacy feature that has been retired. They did not allow instance family changes.
2. Standard Reserved Instances — can be modified to use any instance family within the same region at any point during the reservation term

   Standard RIs can only be modified within the same instance family (e.g., m5.large to m5.xlarge) or to a different AZ/scope. They cannot be exchanged for a different instance family (m5 → r5). Convertible RIs support cross-family exchanges.
3. Convertible Reserved Instances — allow exchange for a different instance family, OS, tenancy, or payment option, subject to equal or greater value ✓

   Convertible RIs can be exchanged for different instance families, sizes, operating systems, or tenancy during the term. The exchange must be for equal or greater value. Standard RIs cannot be exchanged for a different instance family.
4. Savings Plans — provide automatic instance family flexibility for EC2 without requiring the purchase of any new Reserved Instance reservations

   Savings Plans (Compute Savings Plans) do provide instance family flexibility automatically, but the question specifically asks about Reserved Instances. Among RI types, only Convertible RIs allow instance family exchange.

Convertible Reserved Instances can be exchanged for a different instance family, OS, or tenancy. Standard RIs can only be modified within the same instance family.

4. Compute Savings Plans: Which Savings Plan type should they choose?

1. EC2 Instance Savings Plans — apply across all compute services including Lambda and Fargate while delivering the highest available discount rate

   EC2 Instance Savings Plans are scoped to a specific instance family in a specific region. They do not apply to Lambda, Fargate, or to EC2 usage in other regions or other instance families. They offer higher discounts than Compute Savings Plans but with much less flexibility.
2. Purchase Standard Reserved Instances for each instance family, since they provide the same broad cross-service coverage as Compute Savings Plans

   Standard Reserved Instances apply only to specific EC2 instance types and do not cover Lambda, Fargate, or provide cross-family flexibility. They are less flexible than Compute Savings Plans.
3. SageMaker Savings Plans — provide the broadest commitment coverage spanning EC2, Lambda, and Fargate across all AWS compute services

   SageMaker Savings Plans apply only to SageMaker ML instances and are not applicable to general-purpose EC2, Lambda, or Fargate.
4. Compute Savings Plans — apply to any EC2 instance family, region, OS, or tenancy, plus Lambda and Fargate, providing maximum flexibility ✓

   Compute Savings Plans are the most flexible — they automatically apply to EC2 instances regardless of instance family, size, OS, tenancy, or region, and also apply to Lambda function invocations and Fargate tasks. The discount is slightly lower than EC2 Instance Savings Plans in exchange for this flexibility.

Compute Savings Plans apply across all EC2 instance families, regions, Lambda, and Fargate — the most flexible savings plan type. EC2 Instance Savings Plans lock to a specific family and region.

5. 2 minutes — AWS sends a Spot Instance interruption notice: How much advance notice does AWS provide before a S

1. 2 minutes — AWS sends a Spot Instance interruption notice via the EC2 instance metadata service and EC2 EventBridge events 2 minutes before termination ✓

   AWS provides a 2-minute warning before terminating a Spot Instance. The notice is available at the EC2 instance metadata endpoint (http://169.254.169.254/latest/meta-data/spot/termination-time) and via Amazon EventBridge events (EC2 Spot Instance Interruption Warning). Applications should poll metadata or use EventBridge to detect and respond.
2. 5 minutes — AWS provides a 5-minute interruption warning through the instance metadata service to allow the application to shut down gracefully

   The Spot Instance interruption notice is exactly 2 minutes, not 5 minutes. Applications must complete their checkpoint operations within this window.
3. No advance notice — Spot Instances are reclaimed and terminated immediately, with no interruption warning delivered to the application through metadata or events

   AWS provides a 2-minute termination notice for Spot Instances. This is not a guaranteed SLA but is standard practice. Applications can use this window for graceful shutdown.
4. 30 seconds — the EC2 instance metadata endpoint publishes the scheduled termination time roughly 30 seconds before the Spot Instance is reclaimed

   The interruption notice is 2 minutes, not 30 seconds. The metadata endpoint and EventBridge event both trigger approximately 2 minutes before the scheduled termination time.

Spot Instance interruption notice is 2 minutes. AWS signals via EC2 instance metadata (spot/termination-time) and EventBridge events, allowing applications to checkpoint and shut down gracefully.

6. capacity-optimized: Which Spot Fleet allocation strategy should be configured?

1. price-capacity-optimized — prioritizes lowest cost first, with a secondary optimization for capacity depth

   price-capacity-optimized (introduced after capacity-optimized) balances cost and capacity. When interruption minimization is the primary concern (long 4-hour jobs), capacity-optimized is the appropriate strategy as it focuses entirely on capacity depth.
2. capacity-optimized — selects the pools with the most available Spot capacity, reducing interruption risk ✓

   The capacity-optimized strategy allocates Spot Instances from the pools with the highest available capacity. Instances in deeper capacity pools are less likely to be interrupted because AWS has more excess capacity available. This prioritizes availability over minimal cost.
3. lowest-price — selects the cheapest Spot pools to minimize cost while meeting the fleet's capacity requirements

   The lowest-price strategy selects the cheapest Spot pools but does not consider capacity depth. Cheap pools may have shallow capacity, increasing interruption frequency. For a 4-hour workload where interruptions are costly, lowest-price increases risk.
4. diversified — spreads the requested instances evenly across all of the specified Spot capacity pools

   Diversified allocation spreads capacity across pools to reduce correlation risk (not all instances from one pool). It reduces the blast radius of a single pool interruption but does not specifically select high-capacity pools like capacity-optimized does.

capacity-optimized selects Spot pools with the most available capacity, minimizing interruption risk — the correct choice when job interruptions are costly and job duration is long.

7. AWS Compute Optimizer: Which service provides these recommendations with projected cost savings?

1. Amazon CloudWatch Anomaly Detection — identifies instances whose CPU, memory, and network utilization patterns deviate anomalously from the baseline

   CloudWatch Anomaly Detection identifies statistical anomalies in metrics but does not provide instance type recommendations or projected cost savings. It is an operational monitoring tool, not a rightsizing tool.
2. AWS Trusted Advisor Low Utilization EC2 check — recommends specific replacement instance types based directly on observed CPU and network utilization

   Trusted Advisor's low utilization check identifies instances with low CPU utilization (< 10%) and suggests termination or downsizing, but it does not provide specific replacement instance type recommendations or account for memory/network metrics. Compute Optimizer provides more granular recommendations.
3. AWS Compute Optimizer — analyzes 14 days of CloudWatch metrics and recommends optimal instance types with projected cost and performance impact ✓

   AWS Compute Optimizer uses machine learning to analyze EC2 instance metrics (CPU, memory with CloudWatch agent, network, disk I/O) and recommends right-sized instance types. It shows the projected cost savings or increase and labels recommendations as 'over-provisioned,' 'under-provisioned,' or 'optimized.'
4. AWS Cost Explorer rightsizing recommendations — provides cost-focused instance type change recommendations derived from historical usage

   Cost Explorer does have a rightsizing recommendations feature, but it uses simpler heuristics. Compute Optimizer uses ML-based analysis of multiple metrics (CPU, memory, network, storage) over the observation window for more accurate recommendations.

AWS Compute Optimizer uses ML to analyze CloudWatch metrics over a 14-day window and recommends optimal instance types with projected cost and performance impact.

8. Only the core security checks and service limit checks are: Which checks are available to them?

1. All cost optimization checks such as the underutilized EC2 check are free on every plan; only the security checks require a paid Business or Enterprise support plan

   Cost optimization checks (including underutilized EC2) require Business or Enterprise support. Basic and Developer plans do not include cost optimization checks.
2. All Trusted Advisor checks, including the underutilized EC2 utilization check and the IAM password policy check, are fully available on every support plan including the Basic and Developer plans

   Only a subset of Trusted Advisor checks (core security and service limits) are available on Basic and Developer plans. Full access to all five check categories (cost optimization, performance, security, fault tolerance, service limits) requires Business or Enterprise support.
3. Trusted Advisor is not available on the Basic support plan at all; a Developer support plan is the minimum tier required before any Trusted Advisor checks can be viewed

   Trusted Advisor is available on the Basic plan with limited core security and service limit checks. Developer plan also has limited access; Business and Enterprise unlock full check access.
4. Only the core security checks and service limit checks are available on the Basic support plan; cost optimization and performance checks require Business or Enterprise support ✓

   Trusted Advisor provides full access to all checks on Business and Enterprise support plans. The Basic and Developer plans have limited access — primarily core security checks (S3 bucket permissions, security groups, MFA on root, IAM use, EBS snapshots) and service limit checks. EC2 low utilization (cost optimization) requires Business or higher.

Basic and Developer support plans get only core security checks and service limit checks in Trusted Advisor. Business and Enterprise plans unlock all five check categories including cost optimization.

9. Target tracking scaling policy: Which scaling policy type is correct?

1. Target tracking scaling policy — specify the target metric value (CPU = 60%); Auto Scaling automatically calculates required capacity adjustments ✓

   Target tracking scaling policies automatically adjust the number of instances to keep the specified metric at the target value. Auto Scaling calculates the required scaling actions — no manual threshold or step definitions needed. It scales out when the metric exceeds the target and scales in when below.
2. Simple scaling policy — add a fixed number of instances whenever the CPU alarm triggers, then wait out a cooldown period before another scaling action

   Simple scaling adds or removes a fixed number of instances when an alarm fires, then waits for a cooldown period. It does not automatically adjust to maintain a target metric value.
3. Step scaling policy — define multiple steps that add or remove varying numbers of instances based on the size of the CPU alarm breach

   Step scaling requires manually defining CloudWatch alarms and scaling steps (e.g., +2 instances when CPU > 70%, +4 when > 85%). This requires threshold management and does not automatically target a specific utilization level.
4. Scheduled scaling policy — configure the group to scale to preset instance counts at specified times to maintain target CPU levels

   Scheduled scaling adjusts capacity on a schedule (time-based), not based on actual metric values. It cannot respond to unexpected CPU fluctuations or maintain a target utilization level dynamically.

Target tracking scaling automatically adjusts capacity to maintain a specified metric target (CPU = 60%). No manual alarm thresholds or step definitions are required.

10. Enable predictive scaling: What scaling approach minimizes this lag?

1. Increase the Auto Scaling minimum instance count so the group maintains enough capacity to handle the morning peak at all times

   Maintaining peak capacity 24/7 eliminates the lag but wastes significant compute cost during off-peak hours. Predictive scaling maintains appropriate capacity for current conditions while pre-provisioning for upcoming peaks.
2. Enable predictive scaling — it analyzes historical load patterns and pre-provisions capacity before anticipated demand spikes ✓

   Predictive scaling uses machine learning to analyze historical CloudWatch metrics and forecast future load. For recurring patterns (daily peaks, weekly cycles), it launches additional instances before the anticipated demand, eliminating the reactive lag that occurs with target tracking alone.
3. Reduce the Auto Scaling cooldown period to 30 seconds so that new instances are launched and registered faster during the spike

   Cooldown periods prevent rapid oscillation but do not address the fundamental issue — reactive scaling always lags behind demand because it must observe high utilization before responding. Predictive scaling proactively provisions capacity in advance.
4. Use scheduled scaling to add a fixed number of instances at 7:55 AM on every weekday ahead of the morning traffic spike

   Scheduled scaling could work for this specific recurring pattern but requires manual configuration of exact times and instance counts. Predictive scaling automatically learns the pattern, adjusts over time as patterns change, and handles variations without manual threshold maintenance.

Predictive scaling learns recurring traffic patterns and pre-provisions capacity before anticipated demand spikes, eliminating the reactive lag inherent in target tracking alone.

11. S3 Intelligent-Tiering: Which S3 storage class is most appropriate?

1. S3 One Zone-IA — stores data in a single Availability Zone at lower cost than Standard-IA and charges no retrieval fees, ideal for unpredictable read patterns

   S3 One Zone-IA does charge per-GB retrieval fees and keeps only one copy in a single AZ, raising durability risk. It suits reproducible or easily recreatable data, not workloads with unpredictable access that should stay highly available.
2. S3 Standard combined with lifecycle rules that transition objects to S3 Glacier Flexible Retrieval 90 days after their creation date, requiring no manual lifecycle review

   S3 lifecycle rules based on object age (not real access) would archive objects that are still frequently accessed after 90 days. The prompt specifically calls out unpredictable access patterns, which age-based lifecycle rules cannot handle correctly.
3. S3 Intelligent-Tiering — automatically moves objects between Frequent Access, Infrequent Access, and Archive tiers based on access patterns with no retrieval fees ✓

   S3 Intelligent-Tiering monitors object access and automatically moves objects to the lowest-cost tier based on access frequency. It applies a small monthly monitoring fee per object but has no retrieval fees. This eliminates the need for manual lifecycle rule management for unpredictable workloads.
4. S3 Standard-IA — offers lower per-GB storage than Standard for infrequently accessed objects and applies small retrieval fees only when data is read

   S3 Standard-IA is meant for consistently infrequent access. For unpredictable patterns (sometimes frequent, sometimes rare), Standard-IA's retrieval fees add up whenever objects are read often, potentially costing more than S3 Standard.

S3 Intelligent-Tiering automatically moves objects to the lowest-cost tier based on access patterns with no retrieval fees, ideal for unpredictable access patterns at scale.

12. Transition to S3 Standard-IA at day 30: Which lifecycle configuration meets these requirements at lowest cost?

1. Transition to S3 Standard-IA at day 30, then to S3 Glacier Flexible Retrieval at day 90, then expire at day 360

   S3 Glacier Flexible Retrieval provides retrieval times of minutes to hours, which meets the 'hours acceptable' requirement. However, S3 Glacier Instant Retrieval at the same price tier provides millisecond access and is the same cost — both are valid but Glacier Instant Retrieval is strictly better for this use case. This answer is close but not optimal.
2. Keep logs in S3 Standard for 90 days, then transition to S3 Glacier Deep Archive for 270 days

   Keeping logs in S3 Standard for days 31–90 (when Standard-IA is sufficient) incurs unnecessary storage costs. S3 Glacier Deep Archive (retrieval: 12–48 hours) meets the compliance retention requirement but at the cost of S3 Standard for days 31–90 being unnecessary overhead.
3. Transition to S3 One Zone-IA at day 30, then to S3 Glacier at day 90, then expire at day 360

   S3 One Zone-IA stores data in a single AZ, which is appropriate only for reproducible data. Application logs are not easily reproducible, making One Zone-IA unsuitable despite the lower cost.
4. Transition to S3 Standard-IA at day 30, then to S3 Glacier Instant Retrieval at day 90, then expire at day 360 ✓

   S3 Standard-IA (days 30–90) provides instant retrieval at lower storage cost. S3 Glacier Instant Retrieval (days 90–360) provides millisecond retrieval but at lower storage cost than Standard-IA — meeting the 'hours acceptable' requirement at lowest cost. Objects expire at day 360.

Standard-IA for days 30–90 (instant, lower cost), Glacier Instant Retrieval for days 90–360 (millisecond retrieval, very low cost), expire at day 360.

Other AWS SysOps domains

• Monitoring, Logging, and Remediation — 100 questions →
• Networking and Content Delivery — 90 questions →
• Deployment, Provisioning, and Automation — 89 questions →
• Reliability and Business Continuity — 80 questions →
• Security and Compliance — 79 questions →
• All 498 AWS SysOps questions →