This is a pretty old question, so I would assume the OP doesn't need the answer anymore. But I thought I would add some comments for anyone who comes along later and is bumping into similar things.
As a side note, there appears to be something weird with line 2, because it mentions inside interface. I'm not sure why it says that, but it might just be mentioning the ingress interface of the packet that triggered the processing. Not sure. Your NAT is tied to outside, plus the MM processing worked, so this is an issue that i will ignore.
Anyways, moving on. In the debug output, everything seems to be going just fine until about line 76 when your side sends a Quick Mode packet. (This means Main Mode finished successfully, as line 58 confirms.) After that point, your side receives nothing back from the cloud side aside from DPD probes (because lines 77-100 are all DPD chatter). The line you highlighted, line 102, contains a historical list of states of the connection, newest listed first. You can see a while back that it was waiting for Message2 to arrive and it timed out (QM_WAIT_MSG2, EV_TIMEOUT). So, it resent Message1 (QM_SND_MSG1, EV_RESEND_MSG), it started a new timer (QM_SND_MSG1, EV_START_TMR), and then it timed out again waiting for Message2 to arrive (QM_WAIT_MSG2, EV_TIMEOUT). So, your side gives up with an error (QM_DONE, EV_ERROR). Lines 103-118 are all about tearing down the connection, and line 119 mentions the reason: Lost Service (basically "communication failed").
In my experience, the cloud providers don't build VPN tunnels the same way network engineers build VPN tunnels. In an ASA, for example, we fully define all the details of how a tunnel should work. And we always make sure that both sides match each other. And we make sure the ACLs match each other except flipped direction. But, the cloud providers don't configure all of that, just most of it. They stay flexible because they don't know exactly what you are going to configure on your side.
In this case, when Phase 2 was establishing, your "local proxy" (or "interesting traffic", or "encryption domain") is set to 0.0.0.0/0 (lines 2, 71 & 108), which is "any". At this point, the other side goes completely silent and never replies.
What I think has happened here is that the remote side has received your local proxy address, and installed it into its routing logic (that's how they stay flexible with you, since they don't ask you what addresses you will use on your side; instead, they LEARN what addresses you use and they dynamically install them, unlike how we do it on an ASA where it's manually defined). That installation has affected its path to you and it sees you through the tunnel, rather than through the internet. It creates a chicken-and-egg scenario where the remote side can't reach you anymore. When it attempts to send Message2, it never gets to you because QM didn't finish establishing the SA yet.
If my hypothesis is correct, the solution is to use smaller blocks for your local proxy. Here is one example, but there are many correct ways to break it up.
access-list ACL-VPN-CLOUD extended permit ip object-group obj-NET-PRIVATE object-group obj-NET-CLOUD
no access-list ACL-VPN-CLOUD extended permit ip any4 object-group obj-NET-CLOUD
That relies on the object-group you already have called obj-NET-PRIVATE. For someone else on a different firewall, just specify the numeric subnets, like:
access-list ACL-VPN-CLOUD extended permit ip 10.0.0.0 255.0.0.0 10.200.4.0 255.255.255.0
access-list ACL-VPN-CLOUD extended permit ip 192.168.0.0 255.255.0.0 10.200.4.0 255.255.255.0
debug crypto ipsec 127will provide the missing information on why phase 2 is failing to complete.