Are iterators reliable in read-write transactions?

Is it safe to rely on the existence of a key via an iterator to decide whether or not to perform a write in a transaction?

To make it more clear what I mean, suppose I have two transactions:

In the first, I want to check the number of keys with prefix k1, and if there is only 1, then delete both this key as well as another key k2. To do this check, I would use a prefix scan and count the number of items.

In the second, I want to add the keys k1.xxx and k2 at the same time.

If I run these two transactions concurrently, is it somehow possible to end up in the state where only k1.xxx ends up in the database?

Specifically, I’m considering a scenario where transaction 1 first does the prefix scan and finds only a single key with prefix k1, so it therefore proceeds to delete this key along with k2. But before it can commit, transaction 2 is executed and committed. When transaction 1 then goes to commit, will it detect a conflict because there is now a new key with prefix k1?