Cost and Performance Optimization

The correct answer is 'hibernate'. When configuring EC2 Spot Instance interruption behavior, hibernation is the valid option that causes the instance to enter a suspended state with memory contents preserved to the root EBS volume.

When a Spot Instance is configured for hibernation and gets interrupted:
- The instance RAM contents are saved to the root EBS volume
- The instance enters a stopped/suspended state
- When the instance is resumed, it picks up exactly where it left off with the RAM contents restored

This is particularly useful for long-running applications or workloads that need to preserve their in-memory state.

The other options are incorrect:

• 'stop with memory persistence enabled on the root volume' - This is not a valid Spot Instance interruption behavior option. While you can configure 'stop' as an interruption behavior, it does not preserve memory contents - it only keeps the EBS volume data.

• 'terminate with snapshot checkpoint to EBS storage' - This is not a valid option. Terminate simply ends the instance and does not create any snapshot checkpoint of memory.

• 'suspend' - This is not a valid Spot Instance interruption behavior option in AWS. The valid options are: terminate, stop, and hibernate. 'Suspend' is not one of the configurable behaviors.

Cost allocation tags must be activated in the Billing and Cost Management console before they appear in cost reports and billing data. This is the key distinguishing characteristic between cost allocation tags and standard resource tags.

While standard resource tags can be applied to AWS resources immediately and used for purposes like resource organization, access control, and automation, cost allocation tags require an additional activation step. After you apply tags to your resources, you must go to the Billing and Cost Management console and specifically activate those tags as cost allocation tags. Only after activation will these tags appear in your Cost and Usage Reports and other billing tools.

The other options are incorrect:

• Cost allocation tags are NOT automatically enabled when applied. This is the opposite of how they work - they require explicit activation in the Billing console, which can take up to 24 hours to appear in reports after activation.

• Cost allocation tags do NOT require root account credentials. IAM users with appropriate permissions to access the Billing and Cost Management console can activate cost allocation tags. AWS also provides AWS-generated cost allocation tags that can be activated.

• Cost allocation tags do NOT apply retroactively to historical data. Once activated, cost allocation tags only appear in cost reports for usage that occurs after the activation date. They do not backfill historical billing data, which is an important consideration when planning your tagging strategy.

The correct answer is to use a maintain request type to keep the target capacity running continuously.

Spot Fleet supports different request types that determine how the fleet behaves:

Maintain Request Type: This is the appropriate choice when you need to maintain a specific target capacity continuously. With a maintain request, Spot Fleet automatically replenishes interrupted Spot Instances to maintain the desired capacity. Since the requirement states the fleet needs to maintain exactly 20 instances at all times throughout the day, the maintain request type is ideal. When Spot Instances are interrupted due to capacity or price changes, Spot Fleet will automatically launch replacement instances to maintain the target capacity of 20.

Why the other options are incorrect:

• The one-time batch request (request type) only submits a single request for the desired capacity. Once instances are terminated or interrupted, they are not replaced. This does not meet the requirement of maintaining 20 instances at all times.

• The instant request type makes a synchronous one-time request for the desired capacity. It either gets the capacity immediately or returns an error. It does not maintain capacity over time and does not replace interrupted instances.

• There is no scheduled request type for Spot Fleet. AWS does have Scheduled Reserved Instances, but this is not a Spot Fleet request type option. Even if scheduling were available, it wouldn't address the need to maintain continuous capacity and replace interrupted instances.

Since the application needs exactly 20 instances running continuously and can handle interruptions (with progress saved to S3), the maintain request type ensures that the fleet automatically replaces any interrupted Spot Instances to maintain the target capacity.