The correct choice is Create a custom CloudWatch metric and publish statistic sets that roll up the 5 second results, sending one update every 60 seconds. This option satisfies the requirement to record metrics at one minute intervals while keeping ingestion and storage costs low.

Create a custom CloudWatch metric and publish statistic sets that roll up the 5 second results, sending one update every 60 seconds works because you aggregate the high frequency probe locally on each instance and send a single PutMetricData call per minute using the StatisticValues payload. This approach reduces the number of PutMetricData requests and retains the required one minute granularity so alarms can be evaluated without incurring high costs from high resolution ingestion.

Use a default CloudWatch metric at standard resolution and add a dimension so the script can publish once every 60 seconds is incorrect because default metrics are emitted by AWS services and you cannot push your application script output into them. Adding a dimension only annotates an existing metric and does not enable publishing custom application data.

Amazon CloudWatch Synthetics is not the best fit because synthetics runs external canaries or browser tests and usually incurs additional cost compared to batching custom metric publishes. Synthetics also does not leverage the lightweight in-instance probe that the startup already runs every five seconds.

Use a custom CloudWatch metric at high resolution and push data every 5 seconds is unnecessary for this requirement because the desired visibility is one minute. Pushing high resolution metrics every five seconds increases PutMetricData calls and cost, so reserve high resolution for true sub minute alarm needs.

Full AWS Practitioner Certification Question