So I am using the cert for mongodb tls connections. When I connect to testinv2.southeastasia.cloudapp.azure.com:27017 it is working fine, however when I try to use the publicIP:27017 I am encountering error: "Hostname/IP does not match certificate's altnames: IP: publicIP is not in the cert's list"
If you need a certificate for an IP address you can manually request an IP certificate from ZeroSSL but I'm not aware of any ACME enabled certificate authorities which currently have live support for IP address certificates.
If Clients will be connecting to your service via an IP address you should ideally tell them to use the proper domain name which is valid for your certificate instead. You can circumvent certificate name validation in clients that you control (e.g. code you write), but in a standard desktop web browser you can't.
Well, my other clients would be application server since my use case for this cert is for mongodb tls/ssl connections. Communicating to it via private IP would be the ideal scenario. Connecting via public IP/DNS would just be for contingency purposes only
You can use a public DNS name that points to a private IP if you use DNS validation as your method of validating the domain in your ACME client. That way you get a DNS name you can administer (so you can repoint it in the future when migrating servers, without changing your app server clients), and you get a publicly trusted cert from Let's Encrypt so you don't have to run your own CA or use a self-signed cert.
If you do opt to use your own internal CA you could use step-ca (smallstep) or others, the general process is to sign a cert using your own "trust anchor" root certificate then distribute the public cert for that as a CA cert file to your clients. So that way only your internal clients trust the certs issued by your internal CA, and you control the private issuance and use of those certs, but they are untrusted outside of clients you control.