Something to consider with this solution is that the KeyId field is not infinite; that is at some point, if you ever remove records and the key wraps round you will get the situation where the order of the KeyId does not correspond to the chronological order that the records were inserted.
OK this might be quite hypothetical but as software engineers it is our job consider all the problems that could arise with our solution and then decide if we need to mitigate against them. In this case possibly not for a simple exercise which will never have more than a few rows but a table that processes and then deletes millions of rows a day might have future trouble with this solution.
Additionally the mitigation in this case is quite easy as all you need to do is add a datatime column to you table to record the entry time for the record and use that for your ordering.
In general it is a bad idea to assume a pattern in a small test data set will (or won't) be present in a larger real world data set. Your only real guarantee with a key field is that it is unique (assuming the person creating the table did it properly).
It comes down to 4 questions
What is the potential issue?
What will be the consequences if this issue arises?
How often will or likely is it that this issue arises?
How easy is it to mitigate against?