Databases

databases

databases is the data-platform triage command for exposed, central, or identity-linked database services.

Use it when you need to know which database platforms deserve attention before deeper engine- or service-specific detail.

What This Command Answers

• Which database platforms matter first?
• Which ones combine exposure, trust, or identity cues in a way that changes risk quickly?
• Which data service most deserves follow-up before quieter internal databases?

Run It

azurefox databases --output table

For saved structured output:

azurefox databases --output json

Example Table Output

server	engine	endpoint	identity	inventory	exposure
sql-public-legacy	AzureSql	sql-public-legacy.database.windows.net	-	dbs=2; orders,reporting	fqdn; public=Enabled
pg-public-legacy	PostgreSqlFlexible	pg-public-legacy.postgres.database.azure.com	-	dbs=2; app,orders	fqdn; public=Enabled
sql-ops-01	AzureSql	sql-ops-01.database.windows.net	SystemAssigned	dbs=1; appdb	fqdn; public=Disabled

When To Use It

• when data platforms are likely to be more consequential than general workload inventory
• when you need to rank database services before any deeper engine-specific analysis
• when public reachability, private-link posture, or managed identity make one service stand out

What To Look For

• public_network_access=Enabled
• identity or trust cues that make the service more central
• delegated subnet, private DNS, or private-link-style anchoring
• signs of broader operational consequence than a routine internal database

Why It Matters

Database services are often where access risk turns into direct business impact.

A reachable or weakly isolated database, or one tied closely to important workloads and identities, can matter more immediately than many other resources. databases helps you identify those platforms first without turning into schema or record-level exploration.

What Should Stand Out First

• visible exposure or broader reachability
• identity or trust cues that make the service central
• private-link and delegated-subnet context that changes how internal access works
• the services whose placement and posture imply higher consequence

If You See..., Go Next To...

• If you see public_network_access=Enabled on a database server, go next to Resource-Trusts because it shows whether that public data-service boundary stands out across other exposed resources.
• If you see a database server with managed identity, go next to Permissions because it shows whether that data-platform identity already carries broader Azure control.
• If you see delegated subnet or private DNS linkage, go next to DNS because it shows the private namespace paths anchoring that internal database access.

What To Do Next

• Start with the database services that combine reachability with higher operational consequence.
• Treat private-link and namespace cues as part of the data-service trust story, not just network detail.
• Use the service posture to decide whether your next step is trust review, identity review, or service-specific follow-up.

Boundary

databases is a first-pass data-platform command.

It should rank the database services that most deserve follow-up first. It is not a schema dump, record-access workflow, or engine-specific deep analysis surface.