Benjamic Navarez has an excellent article on how the cost-based optimizer in SQL Server works.
Essentially, when SQL Server is asked to read a table it looks at several methods of returning the requested data, and chooses the "best" path it can by assigning costs to each type of operation. It then chooses the cheapest path, or plan. This may or may not include either seeking the clustered index, scanning the clustered index, or perhaps doing seeks or scans on the non-clustered indexes, if they exist.
Since the plan is cost-based, there is no single piece of code that will always perform a clustered-index scan, except perhaps for the case of
SELECT * FROM dbo.[table with a clustered index];. Even adding an
ORDER BY ... clause to that statement may make SQL Server choose a different plan.
In your question you mention that your query performs a clustered index scan whenever the selected number of rows climbs above 10% of the total rows in the table. The number of rows requested versus the total number of rows in the table is part of the cost-based-optimization, and is likely causing SQL Server to think it will be faster to simply scan the entire clustered index (the clustered index is the table), rather than using a series of index seeks followed by lookups.
Look at point #2 in this article by Aaron Bertrand. Rob Farley also has a good write-up about it.
Martin Smith's answer on this question also contains some excellent details on this topic.