Power Query Privacy-Level Interview Questions: Formula Firewall and Data Combination

Power Query privacy-level interview questions ask you to explain where data can travel during a combination. A Formula.Firewall message is not simply a broken join or a credential failure. The engine may be preventing values from one source from being sent to another as part of query evaluation and folding.

Quick answer: identify the host and version, actual source classifications, intended data movement, and evaluation-partition pattern. Then distinguish an incompatible privacy combination from a structural restriction on referencing partitions while accessing a source. Current Power BI Desktop behavior differs from older advice, so version is part of the answer.

Evidence boundary: Microsoft documents the privacy classifications, Firewall purpose, and July 2026 Desktop change. The customer-list and catalog examples here are original reasoning exercises. No candidate reports, production privacy settings, or universal employer questions are claimed.

Use Walk Through an ETL Project to rehearse how you would explain sources, transformations, and deployment boundaries. This article adds the specific Power Query question: which source could receive values originating elsewhere?

Power Query privacy-level interview questions begin with data movement

Official purpose: the Data Privacy Firewall helps prevent unintended movement of data between sources during evaluation. Folding can translate transformations into operations performed by a source. The important boundary is therefore not just where the final report is shown. See Microsoft's Firewall explanation.

Consider an original confidential customer list containing account IDs. You merge it with a public product catalog. One possible execution strategy could use those account IDs to construct a request to another endpoint. Even if the returned table stays on your laptop, the request has already disclosed values to that endpoint.

Conversely, retrieving a permitted public catalog and combining it locally with confidential data is a different movement pattern. Both workflows can produce similar final tables, but they have different recipients. The interview answer should name the sender, receiving source, and actual values crossing the boundary.

Do not infer a specific folded request solely from M source text. Inspect supported query diagnostics, source requests, and the deployed connector behavior. The example illustrates a potential risk and a design question; it does not claim every merge sends the small table to the large table's server.

The Firewall also is not a network firewall, database permission grant, or complete governance policy. Source authentication and report sharing remain separate. A privacy classification describes combination behavior; it does not replace authorization to access a source or publish its contents.

Distinguish classifications from the option to ignore them

Microsoft's privacy-level reference lists source classifications including None, Private, Organizational, and Public. It distinguishes these classifications from app options that enforce or ignore privacy checks. “The source is Organizational” and “this file ignores privacy levels” are different statements.

The official directional rules matter. Private data cannot fold into another source, including another private source. Organizational data can fold into private or organizational sources, but not public ones. Public data can fold into other sources. These statements concern permitted movement, not a simple ordering that makes every higher label compatible with every lower label.

In an original classification exercise, a public price list and an organizational warehouse are not symmetric recipients. Public values moving into the organizational source and organizational values moving into the public endpoint are different directions. Trace the proposed operation before pronouncing the labels compatible.

Set classifications according to the real trust boundary. Relabeling confidential account IDs as Public to satisfy a refresh can make the engine's decision consistent with a false description. A query that runs after such a change has not established that the disclosure is appropriate.

None is not a synonym for safely public. Likewise, two sources both called Private are not thereby authorized to exchange each other's values through folding. Read the host's supported controls and the approved data-sharing policy instead of reducing privacy to a checkbox convention.

What is an evaluation partition, and why does it matter?

A query name in the editor is not necessarily one Firewall evaluation partition. The engine can partition evaluation and manage references between those partitions. A partition is part of the evaluation model; it is not simply a file, worksheet, database table, or visible query folder.

The historical rule described in Microsoft's Firewall article prevented a partition from directly accessing sources while also referencing other partitions. A query that obtained a parameter from another query and then built a source request could therefore trigger a structural Firewall message even when the classifications were compatible.

Use a small original dependency diagram: AccountParameter reads an approved source, and OrdersRequest references its result while constructing a source request. Ask where the reference crosses a partition boundary and whether the evaluation also directly accesses a source. Do not equate “references another query” with “definitely leaks confidential data.”

A staging-query redesign can sometimes separate source access from later combination. But creating a staging query by itself does not establish a safe final boundary. The engine's actual partitioning, folding, host behavior, and privacy classifications still determine evaluation.

This is why copying an old workaround without the original environment is weak interview reasoning. The error text indicates a restriction to investigate. It does not establish that one particular refactoring is necessary for every product and version.

State the July 2026 Desktop change precisely

Current official version detail: Microsoft documents a setting introduced in July 2026 Power BI Desktop that permits partitions to reference other partitions and access sources when the involved source privacy levels are compatible. It is enabled by default from that version. The documentation says this aligns Desktop with behavior already used by the service. See the partition-setting guide.

That change relaxes the structural restriction; it does not abolish privacy compatibility checks. A previously rejected compatible parameter/reference pattern may now succeed. An incompatible transfer may still require a different design.

Original diagnostic case	What to check	Meaning of the result
Compatible sources, older Desktop behavior	Host version and partition structure	Structural restriction may apply
Compatible sources, new setting enabled	Actual references and source access	Old workaround may be unnecessary
Incompatible source movement	Source classifications and recipient	Version change does not authorize transfer
Desktop succeeds, service fails	Deployment source mappings and error phase	Do not assume the same cause

Treat this as a versioned decision table rather than a timeless rule about M. Record the exact Desktop version and setting state. If the question concerns Excel, a gateway, a dataflow, or another host, verify that host's documented behavior instead of assuming the Desktop toggle exists there.

An interview answer can say: “The older partition restriction is one hypothesis. I would first verify the host and whether the compatible-source relaxation applies, then inspect the classification and intended transfer.” That is more precise than saying all cross-query source access is always forbidden.

Separate the two Firewall messages from other refresh failures

One message says a query references other queries or steps and therefore may not directly access a source. Another says sources have privacy levels that cannot be used together. Microsoft's Firewall article shows both. Preserve the exact error text and failing step instead of paraphrasing both as “Power Query cannot join.”

A credentials error, unavailable file path, gateway mapping failure, type conversion error, or timeout is a different category. Privacy settings should not be changed merely because refresh failed. Locate the phase and boundary indicated by the actual evidence.

For an original Desktop-success/service-failure case, a query reads a local CSV and an organizational database. First verify whether the refresh environment can reach the file and source under the configured identity. A laptop preview is not proof that the gateway has that path or permission.

If both sources are reachable and the error is genuinely Firewall-related, compare classifications and host behavior. If the failing step is a date conversion, reduce the input value and culture issue instead. Changing privacy settings cannot validate the conversion rule.

Save a minimal reproduction with synthetic values when possible. Remove unrelated transformations one at a time while preserving the same source-reference pattern. A reproduction that replaces both sources with an in-memory constant table may remove the very boundary being investigated.

Why buffering and disabling checks are not universal repairs

Table.Buffer is sometimes suggested as a way to change evaluation or folding. Microsoft's Table.Buffer reference describes shallow buffering and notes that it can make queries slower, including by preventing downstream folding. It is not a declaration that every buffered combination is authorized or Firewall-compatible.

If you propose buffering, identify the specific evaluation behavior you need to change and the expected effect on source requests. Measure row counts, memory use, and refresh time in the target host. A successful preview after adding a buffer may still hide a deployment or scale problem.

The option commonly called Fast Combine ignores privacy-level checks; it is not the same as classifying sources correctly. It should not be presented as the default fix for an unexplained message. The business needs to authorize the intended combination, and the operating environment must support the chosen policy.

An alternative is an approved staging boundary: ingest permitted source data into a controlled environment, record its provenance and access controls, then combine within that boundary. This is an architectural recommendation, not an automatic Firewall exemption. Verify how Power Query sees the resulting source and which values can leave it.

Also consider whether the query needs confidential identifiers at all. A public catalog lookup keyed only by public product codes has a different exposure from one keyed by private account IDs. Minimizing the transferred fields can be a concrete design change, provided it still meets the analytical requirement.

Make the remedy and verification plan concrete

For the customer-list example, write down allowed and prohibited recipients before changing anything. Decide whether public catalog retrieval can occur independently, whether the join must stay within an approved environment, and whether a source-side operation is explicitly permitted.

Then choose one bounded change. Correct an inaccurately recorded source classification, update the relevant host setting when authorized and applicable, refactor the reference pattern, or move combination to an approved stage. These alternatives address different causes and should not be bundled into an untraceable “try everything” fix.

Verify the resulting table against an independent control: expected customer count, allowed product matches, unmatched identifiers, and excluded test records. A successful refresh can still be analytically wrong if the refactoring altered filters or key normalization.

Separately inspect supported diagnostics or source logs to see whether the expected boundary was preserved. Do not print private values into general logs or a public troubleshooting report. Use synthetic identifiers for the teaching fixture and protected evidence channels for real incidents.

Record host/version, setting state, source identity and classification, failing step, chosen change, observed requests, and final reconciliation. If the deployment environment differs, rerun the same case there. State explicitly which environment passed rather than claiming one Desktop refresh proves every service configuration safe.

Practice explaining the boundary in an ETL answer

For Power Query privacy-level interview questions, the strongest answer connects error evidence to a particular movement and version rule. It also names what remains unverified: source requests, deployment mapping, or the final data reconciliation. The following prompts are adjacent ETL design practice, not a native Power Query question bank.

Question	Practice focus
Explain ETL schema changes and ensure integrity	Document source/schema changes before repairing refresh
Walk Through an ETL Project	Trace source access and staging boundaries
Design a 25,000-CSV ETL pipeline	Design explicit file-loading and combination steps
Design Data Quality and Observability Pipeline	Separate row validation from privacy controls
Design batch and streaming ETL architecture	Choose an approved architecture for data movement

Start with Explain ETL schema changes and ensure integrity. Explain your assumptions and expected result before implementing the solution.

Sources and further reading

• Microsoft: Data Privacy Firewall
• Microsoft: Privacy levels
• Microsoft: July 2026 Power BI Desktop partition behavior
• Microsoft: Table.Buffer