Port Scan — Everything Listening That You Did Not Intend
A port scan probes a host across a range of ports and reports which accept connections, usually with a guess at the service and version behind each. It is the most direct answer available to the question of what a host is actually exposing, as opposed to what it is supposed to be exposing.
Why run it
The gap between those two is where incidents come from. Ports open because a package installed a service and enabled it by default, because a firewall rule was added temporarily during an investigation and never removed, or because a container published a port to the host when it was only meant to be reachable internally. None of those appear in documentation, and none produce a symptom. The version information is equally valuable, since an unexpectedly old version is a strong signal that a host is not in your patching rotation.
Why automate it
Exposure only ever accumulates. Every deployment, every package update, every emergency change is an opportunity for something new to start listening, and nothing removes ports except deliberate effort. Scanning on a schedule and diffing against the previous result changes the question from "what is open" — which is a long list nobody reads — to "what is open that was not open last week", which is short and actionable. Run it against your own hosts only; scanning infrastructure you do not own is a different activity with different consequences.
What it gives you
Your externally visible attack surface as it is rather than as documented, and — scheduled — notification of every addition to it. It is the check that finds the management port somebody exposed six months ago.