Greetings @Janis404 , 

Nice work pulling system.access.outbound_network and narrowing this to serverless. That table is where the answer lives, so let me walk through what it's telling you.

Read the log rows first:

• access_type is DROP, which is real enforcement, not a dry-run entry (dry-run shows up as DRY_RUN_DENIAL). So egress is being blocked right now, not merely recorded.
• The rcode: 5 in the dns_event is a DNS REFUSED. The serverless DNS layer refused the lookup, and that is exactly what produces the Python gaierror [Errno -2] Name or service not known. Your code is fine. The block sits upstream of Python.
• One nuance: denials are logged to this table even when a policy is in Full access mode, so the presence of rows isn't the smoking gun by itself. The DROP verdict is.

Now the apparent contradiction: the policy screenshot says "Allow access to all destinations," but google.com, a plain public name, is being dropped. Under a Full access policy that's actually in force, that lookup should succeed. Two things explain the gap, and I'd rule them out in this order.

1. The config you're showing may not be the config that was active when those DROP rows were written. Your policy view and your log output aren't necessarily from the same moment, so pin them together: terminate the serverless environment on the notebook (or start a brand-new serverless run rather than reusing one that's still warm), re-run the socket test immediately, then query outbound_network again and confirm whether there are fresh DROP rows for google.com with new timestamps. This also handles the warm-compute angle: network access mode changes apply to newly provisioned serverless compute, not to a session that was already running when you flipped the setting. The "wait 15 minutes" advice was reaching for this, but 15 minutes is optimistic, and a session that never fully recycles can lag much longer.
2. If a fresh session still drops it, have an account admin inspect the policy through the account API, CLI, or Terraform and confirm restriction_mode is FULL_ACCESS with no blocked_internet_destinations entries. Databricks lets you block specific domains even while a policy is in Full access mode, so the General tab's radio button doesn't tell the whole story. Check for an entry matching google.com or a broader parent domain. One caveat: a single blocklist entry wouldn't explain your own domains getting dropped too, so if everything is failing, the timing issue above is the likelier culprit than a targeted block.

On the NCC: since you called it out, salfy-prod-ncc is almost certainly not behind these particular rows. A private endpoint rule for your Postgres routes that one FQDN privately by matching its hostname; it doesn't produce a DROP for an unrelated public name like google.com in the egress table. The DROP is an egress policy decision, so that's where to look, not the private-connectivity path.

If you've confirmed Full access on genuinely fresh serverless compute, with no blocked destinations, and it still drops google.com, that no longer matches expected Full access behavior and it's a Support case. Give them everything on the first pass: workspace ID (dbc-6b9d00ae-0ac6), region eu-central-1, the policy name, the outbound_network rows with their timestamps, and a failing run ID, and state plainly that you're serverless-only and Full access is set.

Takeaway: the Python gaierror is a symptom, not the problem. Your logs already show the serverless egress layer refusing DNS, so the fix is getting a Full access policy actually in force on fresh compute, confirmed by fresh DROP-free rows, before you change anything else. Start with a cold session and matching timestamps.

Regards,
Louis