Greetings @Fatimah-Tariq , thanks for calling me out to help with your issue. I did some digging and here is what I found:
Let’s break down what’s really happening here and a few safe, predictable ways to test your new notebook interactively.
What’s happening
Foreign catalog tables created through Lakehouse Federation are, by design, read-only in Databricks. Unity Catalog will happily vend read credentials for them, but it will not issue write credentials under any circumstance. So when you test a write against a foreign table, you’ll see exactly the error you pasted: “Only READ credentials can be retrieved for foreign tables.”
That message is UC doing its job. Any attempt to write to a federated table or a path governed by a foreign catalog’s authorization boundary will trigger UC to ask for write credentials it refuses to provide. Hence the failure.
Now, why you’re still seeing success in your scheduled job on DBR 16.2: older runtimes and certain job-cluster paths can still fall back to legacy auth. If that happens, UC’s stricter foreign-table checks never fire, which explains why the job runs cleanly while your 16.4 interactive cluster shuts it down immediately.
How to test safely in an interactive environment
Depending on what outcome you need, here are the cleanest, least risky ways to validate:
• Test on a job cluster.
Spin up a small dev job using a job cluster and manually trigger it with your new notebook. This mirrors prod behavior and avoids the interactive cluster differences entirely. It’s the simplest way to keep things safe and predictable.
• Point your writes to a UC-native target when testing.
On your 16.4 interactive cluster, redirect writes to a catalog/schema you actually own—something UC-managed or a UC external location that isn’t federated. Validate the transformations there, then switch back to the foreign-catalog target only in the job where you already know it works today.
• If you must write to the same path as production, use fallback mode sparingly.
If the target path sits under a federated connection’s authorized location, you can temporarily enable fallback mode on the UC External Location. That lets the write go through using legacy auth instead of UC’s foreign-table checks. It works, but treat it like a temporary testing valve, not an everyday setting.
• If this is Glue/HMS federation, write through hive_metastore.
Federated HMS objects are read-only, but hive_metastore (the legacy metastore) can still be writable depending on how the environment is set up. For interactive work, write to hive_metastore instead of the federated Glue catalog object.
• Double-check that your target location isn’t explicitly marked read-only.
That’s a different enforcement path, but it’s worth ruling out if permissions were recently tightened.
Why this matters long-term
Lakehouse Federation’s contract is clear: foreign tables are read-only from UC’s perspective. If your production job is slipping through on legacy or fallback behavior, treat that as a flag to revisit the pattern. A safer long-term approach is to stage data into UC-native storage and then load it into the remote system using that system’s writer or connector. It keeps you out of the line of fire as runtimes continue to tighten enforcement.
Hope this helps, Louis.
