Azure data engineer interview questions — grouped by what they're really probing.

Most question lists hand you fifty definitions and call it preparation. An interviewer is not checking whether you memorized what ETL stands for; they are checking whether you can move data through a system without losing or corrupting it. So here are the real questions, grouped by what each one is quietly measuring.

New to cloud? CAMPUX is a free, build-first course. Start here →

An Azure data engineer interview tests whether you can move, transform, and serve data reliably on Azure — pipelines, storage and the lakehouse, and streaming — not whether you memorized definitions. Treat the specific question wording below as a sample, not gospel; the direction is settled even if any one interviewer phrases it differently. Almost every question maps to one of five jobs: getting data in, storing and modeling it, transforming it at scale, handling it in motion, and keeping it cheap and correct. Learn to hear which job a question is probing and the answer writes itself.

First, the certification question — because the internet is wrong about it

Half the interview-prep pages still tell you to study for DP-203. Do not. Microsoft retired DP-203, "Data Engineering on Microsoft Azure," on 31 March 2025, and the associated instructor-led course was pulled with it. The role now points at exam DP-700, which earns the Microsoft Certified: Fabric Data Engineer Associate credential — built around Microsoft Fabric, and assessed on ingesting and transforming data, securing and managing an analytics solution, and monitoring and optimizing it, with SQL, PySpark, and KQL as the working languages.

Here is the honest tension, and you should be ready to name it in the room: Microsoft's certification moved to Fabric, but the majority of live job postings still say Azure Data Factory, Synapse, and Databricks. So the questions below stay grounded in the services teams run today, and I flag where Fabric is the direction of travel. No certification is required to get hired — it is supporting evidence, the same as for any cloud role, which is the whole point of passing the exam and still getting no interviews.

Ingestion and orchestration — Azure Data Factory

This block asks whether you can get data from a messy source onto the platform on a schedule and recover when it fails. Data Factory is the default answer, so know it cold.

Q: What are the integration runtimes in Data Factory and when do you use each? There are three. The Azure integration runtime is the managed, serverless compute for cloud-to-cloud copy and data flow execution. The self-hosted integration runtime is an agent you install on a machine inside a private network or on-premises so the service can reach sources behind a firewall. The Azure-SSIS integration runtime is a managed cluster for lifting and running existing SQL Server Integration Services packages. The tell in a good answer is connecting the self-hosted runtime to a real constraint: "the source was an on-prem SQL Server with no public endpoint, so a self-hosted IR was the only way in."

Q: How do you do incremental loading instead of reloading everything? You track a high-water mark — a watermark column such as a LastModified timestamp or an increasing id — persist the last value loaded, and on each run pull only rows greater than it, then update the watermark. For change-heavy sources you reach for change data capture or change tracking. The point being tested is that full reloads do not scale and you know how to load only the delta.

Q: What trigger types are there, and what makes a tumbling window trigger different? Schedule, tumbling window, storage event, and custom event. A tumbling window trigger fires over fixed, non-overlapping time slices, keeps a one-to-one relationship with its pipeline run, supports dependencies between windows, and can backfill history — which is why you use it for reliable, ordered, catch-up-capable batch loads rather than a plain schedule.

Storage and modeling — ADLS Gen2 and the lakehouse

Now the question shifts to where the data lands and whether it is laid out so queries are fast and cheap.

Q: What makes ADLS Gen2 different from plain Blob storage? Azure Data Lake Storage Gen2 is Blob storage with a hierarchical namespace turned on. That gives you real directories with atomic directory-level operations and POSIX-style access control lists, instead of a flat key space where "folders" are just name prefixes. Engines can rename or delete a directory in one operation rather than touching every object, and you can grant access at the folder level.

Q: What is Delta Lake and why not just write Parquet? Delta Lake is an open table format that sits on top of Parquet files plus a transaction log. The log buys you ACID transactions, schema enforcement, time travel, and reliable upserts and deletes — the things raw Parquet cannot do. It is what makes a "lakehouse" behave like a warehouse while the data stays as files in the lake. In Databricks and Fabric it is the default table format, which is why interviewers now expect the term.

Q: How do you decide partitioning, and what goes wrong? Partition by the columns you filter on most, usually a date, so queries can prune whole directories instead of scanning everything. The classic failure is the small-file problem: over-partitioning shatters the data into thousands of tiny files and query planning and I/O collapse. The second is partitioning on a high-cardinality column like a user id, which creates a partition per value. A senior answer names both traps, not just the happy path.

Q: When would you still model a star schema in 2026? When analysts and BI tools query the data. A star schema — a central fact table of measures surrounded by dimension tables — keeps queries predictable and joins cheap, and it is still how a Power BI serving layer is built even when the raw data lives as Delta in a lake. Lakehouse did not kill dimensional modeling; it moved it downstream.

Processing — Synapse SQL pools and Spark

The probe here is whether you pick the right engine for the work or reach for the biggest hammer every time.

Q: Dedicated versus serverless SQL pool in Synapse? A dedicated SQL pool is provisioned massively-parallel storage and compute, sized in data warehouse units, that you pay for by the hour whenever it is running; tables are physically distributed by hash, round-robin, or replication. It fits a stable, heavily queried warehouse. A serverless SQL pool provisions nothing — it queries files already in the lake on demand via OPENROWSET or external tables and bills per terabyte of data scanned, which fits ad hoc exploration without standing cost. The mistake is running exploratory one-off queries on an always-on dedicated pool.

Q: When Spark instead of SQL? When the transformation is too large or complex for a single SQL engine, needs code rather than set-based logic, or has to process semi-structured data at scale. Spark, through Azure Databricks or Synapse Spark pools and now Fabric, distributes the work across a cluster. Expect a PySpark coding round — a DataFrame read and write, a join, a window function, a group-by — and expect to explain partitions, shuffles, and lazy evaluation. If plain SQL on the warehouse does the job, that is the better answer; reaching for a cluster you do not need is a red flag.

Streaming — Event Hubs and Stream Analytics

Here the probe is whether you understand that data in motion is a different problem from data at rest.

Q: What is Event Hubs and what are partitions and consumer groups for? Event Hubs is a high-throughput ingestion service for event streams. Partitions are the unit of parallelism and ordering — events keep order within a partition, and more partitions mean more parallel readers. Consumer groups are independent views over the same stream so multiple applications read it at their own pace without interfering. Capture can also land the raw stream to ADLS or Blob automatically.

Q: How does Stream Analytics windowing work? Azure Stream Analytics runs SQL-like queries over the stream using windowing functions: tumbling (fixed, non-overlapping), hopping (fixed size that can overlap by a hop), sliding (emits when events enter or leave the window), and session (groups bursts of activity separated by gaps). The interviewer wants you to match a window to a question — "average per fixed minute" is tumbling; "moving five-minute average updated every minute" is hopping.

Optimization and cost — the part juniors skip

Every senior loop lands here, because it separates people who ran a pipeline from people who owned a bill. The probe: can you make it faster and cheaper without breaking it? Moves to have ready: prune with partitioning and predicate pushdown so engines scan less; compact small files; pick serverless for spiky exploration and provisioned for steady load; pause or scale down dedicated pools when idle; move cold data to cool or archive tiers; and prefer columnar Parquet and Delta over CSV and JSON. The universal answer to "cut this cost" is "scan less data and stop paying for idle compute."

The question the exam dumps can't script

Every dump has the definitions. None can answer the question that actually decides the loop: "Walk me through a pipeline you built, and tell me what broke." This is where a memorizer falls apart and a practitioner takes over, because you cannot fake the texture of a real failure.

Have one story rehearsed to the bone — not the architecture-diagram version, the one with the 3am page in it. A source that changed its schema without warning so your load silently dropped columns; a pipeline that looked green while writing duplicate rows because a retry re-ran a non-idempotent copy; a Spark job that ran fine on sample data and fell over on a skewed partition in production. Say what broke, how you found it — logs, monitoring, a reconciliation count — what you changed, and the guardrail you added so it could not happen twice. That last part is what tells a hiring manager you learned something.

The definitions get you shortlisted. The story of what broke, and how you caught it, is what gets you hired.

How to prepare without drowning in question lists

Do not grind five hundred questions. For each of the five jobs — ingest, store and model, process, stream, optimize — build the smallest real thing that exercises it and explain the trade-off you made; that covers the definitions and the "what broke" question in one pass. Pair it with the interview questions guide for the general rounds, and if you are still assembling the underlying skills, the Azure cloud engineer roadmap gives the order to learn them in.

Questions people also ask

What questions are asked in an Azure data engineer interview?

They cluster into five areas: ingestion and orchestration (Azure Data Factory, integration runtimes, triggers), storage and modeling (ADLS Gen2, Delta and lakehouse, partitioning, star schema), processing (Synapse SQL pools, Spark on Databricks), streaming (Event Hubs, Stream Analytics), and optimization and cost. Beyond the definitions, expect a design prompt like build ingestion for source X and at least one question about a pipeline you shipped and what broke.

What certification do I need to be an Azure data engineer?

There is no live Azure-branded data engineer exam anymore. Microsoft retired DP-203, Data Engineering on Microsoft Azure, on 31 March 2025 and now points the role at DP-700, which earns the Microsoft Certified: Fabric Data Engineer Associate credential built around Microsoft Fabric. No certification is required to be hired; most job postings still list Data Factory, Synapse, and Databricks, so treat the cert as supporting evidence, not the qualification.

Is Azure Data Factory asked in interviews?

Almost always, because Data Factory is the default orchestration layer on Azure. Expect questions on the three integration runtimes (Azure, self-hosted for private or on-premises sources, Azure-SSIS), the trigger types, incremental versus full loads with watermarking, and how mapping data flows differ from the copy activity. Strong answers tie each feature to a concrete reason you would reach for it.

What is the difference between Synapse dedicated and serverless SQL pools?

A dedicated SQL pool is provisioned MPP storage and compute you pay for by the hour while it is running, sized in data warehouse units, with tables physically distributed by hash, round-robin, or replication — it suits a stable, heavily queried warehouse. A serverless SQL pool has no provisioned resources; it queries files already in the data lake on demand and bills per terabyte scanned, which suits ad hoc exploration without standing cost.

Do Azure data engineers need to know Spark?

Effectively yes for most roles. Spark, usually through Azure Databricks or Synapse Spark pools and now Microsoft Fabric, is how large-scale transformation and lakehouse work gets done, and PySpark shows up in coding rounds. You do not need to be a distributed-systems expert, but you should read and write PySpark DataFrame code, explain partitions, shuffles, and lazy evaluation, and know when Spark is overkill against plain SQL.