CoAP runs over unreliable UDP. How does it provide reliability when needed?

It makes reliability optional and per-message. A message can be Confirmable (CON), meaning the receiver must acknowledge it with an ACK; if the sender doesn't get the ACK within a timeout, it retransmits with exponential backoff up to a limit, so CON messages are delivered reliably much like a minimal version of TCP's retransmission, used for data that must arrive such as a command or an important reading. Alternatively a message can be Non-confirmable (NON), which is fire-and-forget with no ACK, used for frequent disposable telemetry where an occasional loss is acceptable and the overhead of acking isn't worth it. To handle the duplicates that CON retransmission can cause, every message carries a Message ID the receiver uses to de-duplicate, and to match a response to the correct request (since UDP responses can arrive out of order or be delayed) CoAP uses a Token that the response echoes. So CoAP gives you "reliable when you ask for it", you choose CON for important exchanges and NON for cheap telemetry, with dedup and request/response correlation built in, all without TCP's full connection machinery and state cost.