Switch to Query requests where possible and Lower the page size by setting a smaller Limit value are the correct choices to implement before the expected growth because they reduce how much data each request reads and they contain read capacity usage while keeping costs low.

Switch to Query requests where possible is the primary fix because queries use partition key and optional sort key conditions to target specific items and partitions and they avoid the full table reads that drive high read capacity consumption and slow responses. Queries therefore reduce RCU use and improve latency without adding new services or significant expense.

Lower the page size by setting a smaller Limit value helps when a Scan is still necessary because it limits the number of items returned per request and spreads read throughput over time which lowers the chance of throttling and reduces per request cost. This is a low cost tuning step while you refactor access patterns toward queries.

Enable DynamoDB Accelerator (DAX) can reduce latency for some read patterns but it adds ongoing cost and it does not address the underlying inefficiency of full table scans. DAX is most beneficial when you already use Query or GetItem and it is not the best first action here.

Adjust the ScanIndexForward setting to sort query results only changes result order and it does not reduce the amount of data scanned or the read capacity used so it will not resolve the scan driven performance problem.

Increase the table's write capacity units (WCU) raises write throughput but it does not improve read efficiency or lower read costs. Increasing WCU would add cost without addressing the read bottleneck caused by scans.

Full AWS Practitioner Certification Question