Network vulnerability scanners make network requests, try to figure out what’s listening, what services are behind it, what protocols are being used. There are looking for vulnerable versions of server applications or vulnerable configurations. As an example, a network vulnerability scanner can determine that one of the services on the system is allowing insecure connections, maybe facing a POODLE attack, based on the information in an SSL/TLS handshake or the port ssh 22 uses a default configuration.
Obviously, network vulnerability scanners cannot scan the entire internet, or your entire cloud provider, and magically your system is protected. We need the lists of network addresses to scan, and if you’ve missed any addresses, you’re going to have maybe issues or system not full compliant. For this we have the inventory management because attackers can exploit vulnerabilities discovered using lateral movement very quickly.
Network vulnerabilities found on a segment private zone network have a lower priority than vulnerabilities on a component directly exposed to the internet, but you should anyway put this on medium/low priority. Maybe could be part of lateral movement from the attackers point of view.
You could incorporate a network vulnerability scan of the test environment into the deployment process and include any findings in the test environment, put into a bug tracker system like Jira and follow your issues. As the scanner test multiple ports and protocols, you must have a well-documented, effective process for masking false positives or you have the risk that the teams start to ignore all of the scan results in the feature.