Let's encrypt is a way to obtain publicly signed certificates. That means the certificate signing authority must have some way of verifying that the domain in the Cert signing request can be associated with the request. Generally that's done by either adding a public DNS CNAME or TXT record with the content that "proves" you own the domain, or by adding content to a web endpoint on the domain, which achieves the same evidence that you own the domain.

As an unqualified hostname, nobody owns ZZ-UBUNTU1. it's merely a string identifier. You can't get a public certificate for this name because there would be no way to verify it before signing.

Here's some things you can do:

• you can sign a certificate with a non-public CA key. Keep the CA key somewhere safe, provide the CA cert to the client and the signed cert and key to the postgres server. The public won't trust the certificate, but they're not connecting to the postgres server anyway. If the CA key is secure, this is cryptographically as secure as a publicly signed certificate. This is only an appropriate solution if the certificate need not be validated by the public, who would have no reason to trust your CA certificate.
• as a similar alternative, you can use a self-signed certificate. This means that the key associated with the certificate is also the key used to sign the CSR, so the CA key materials and the server key materials are the same. You can then specify the self-signed certificate as the ca-cert in your client config so the key can be verified. This also is only valid for privately used certificates, as the public would have no way to verify authenticity.
• you can use a FQDN under a domain your organization controls. Your ogranization would have to allow you to update DNS or handle public http requests to the FQDN so that you can provide proof of ownership. For example, if you had example.com, you could get a publicly signed certificate for db.internal.example.com. Then you could define db.internal.example.com to be 127.0.0.1 or whatever IP in /etc/hosts. you should be aware that any FQDN with a publicly signed certificate can be discovered in the Certificate transparency logs. Further, public DNS may not reliably resolve to 127.0.0.1 or other private addresses due to security considerations, but that's more likely on home networks than in azure.

Let's Encrypt certificates are good for 90 days. The article says to restart postgres to pick up the new certificates, but this heavy-handed approach will interrupt postgresql service while the restart happens. As of postgres 10 which was some time ago, ssl certs can be reloaded without restarting the server or interrupting existing clients. So if you do end up using let's encrypt, instead of restarting your db server every 10 days and causing an outage, issue a reload instead.