How do i know that 2ubuntu3.9 has the latest security patches
This is not a simple. Not all vulnerabilities listed on the Apache security page are relevant for the version shipped with Ubuntu. Ubuntu ships version 2.4.18 with backported patches they consider relevant.
The starting point to look what is fixed would be the Changelog and compare it with the list of bugs published by Apache.
But, that a CVE is not found in the Changelog does not mean that the version shipped is vulnerable against this. For example CVE-2018-8011 is considered to only affect Apache 2.4.33 and not the version 2.4.18 shipped with xenial. Similar the information on CVE-2018-1333 and CVE-2018-11763 say that the specific code where the vulnerability is not included in the version shipped with xenial ("not-affected (code not built)").
Thus, in order to know if a specific vulnerability is still a problem with the shipped version you need to dig through the Changelog and if you don't find the CVE there you need to check why it was not fixed, i.e. likely because it did not affect the version as shipped.
How do i know if my ubuntu apache version is secure?
The basic idea of this question is kind of wrong. That some software is not vulnerable to known CVE does not mean it is secure. If new vulnerabilities get discovered software does not magically gets insecure until the CVE gets fixed: it was insecure before but the newly detected problems were not widely known yet.
There are several factors to look at in order to determine if a software is sufficiently secure for a specific purpose. One is probably the track record of the software: software which is widely used but had only low severity issues in the past is probably more trustworthy compared to software which had lots of serious issues in the past, even though all known issues seem to be fixed know. For example I would definitely not trust Flash even after the latest security patch but just expect that the next issue pops up within a few weeks (it usually does) and that attackers know and already use issues not yet published.
To keep the risk low (and managed) it is also relevant what impact security issues in the software might cause. Limiting potential impact by using the software only for unimportant stuff might limit the risk as does mitigating potential problems by running the software with low privileges, monitoring suspicious activity etc.