Secondary replica indexing
#5: transactional replication.


Why is this an option? Because the documentation explains exactly why it is possible there - once initialized, index changes are not replicated in either direction.


  Indexes can be added at the Publisher or Subscribers with no special considerations for replication (be aware that indexes can affect performance). CREATE INDEX and ALTER INDEX are not replicated, so if you add or change an index at, for example, the Publisher, you must make the same addition or change at the Subscriber if you want it reflected there.


I also think you are reading the text far too literally. If you have configured replication at all, it is highly unlikely you should assume that it would be configured to replicate to another database inside the same instance of SQL Server - I'm not even sure if that is possible, or if there really is a plausible use case for that, but I don't think the wording of the question was slanted to point you that way. To be honest, I just think the quality of questions in those exams, in general, is shady. I wouldn't read too much into them.

Why are none of the other options possible? Because:


In no Availability Groups configuration can you create indexes on the secondaries, since the secondaries are essentially read only (though you can create statistics; these, however, live in tempdb). IIRC there have been requests to support something like this for indexes too, but no plans. This rules out #1, #2, and #4.
Log shipping isn't a good fit for the requirement, since you can't change the destination database and continue applying logs. So - since the question states that logs are restored every 10 minutes - you'd have to restore the database with recovery every 10 minutes, create the indexes, then kick everyone out 10 minutes later to do it again. This is not "up-to-the-minute" reporting. This rules out #3.
Snapshot replication can't be updated once initialized, since it is literally a snapshot - in order to create indexes, you'd have to do it every time you restored a snapshot, since this is an all-or-nothing operation. It is not possible to provide "up-to-the-minute" reporting in this model. This rules out #6.
In failover clustering, there is only one copy of the data, and only one instance of SQL Server, and the data is only visible to any workload (read or write) on the primary ("active") node. So, by definition, it is not possible to make changes to a copy of the data, since there is no "copy." This rules out #7.