What factors contribute to amortized constant complexity in a map container?

In std::map (which is a balanced binary search tree, such as a red-black tree), most operations (insertion, deletion, search) have logarithmic time complexity $O(\log N)$, where $N$ is the number of elements in the container.

The amortized constant complexity, sometimes mentioned in the context of associative containers, more often relates to std::unordered_map (hash table, see below). In std::map, such amortized constant complexity for basic operations does not exist.

Perhaps the question concerns amortized constant complexity for operations that are not the main search or modifying operations, such as moving an iterator. Iterators in std::map allow moving through elements in sorted order in amortized $O(1)$ time, since the tree structure allows finding the next/previous element efficiently on average.

It is also worth mentioning std::unordered_map – a hash table. In it, insertion, deletion, and search have an average amortized complexity of $O(1)$ with a good hash function and no many collisions. The worst case, with many collisions or a poor hash function, can reach $O(N)$.

In the context of std::map, talking about amortized constant complexity for key operations is incorrect.