Databricks · DB-DEP · Professional

Databricks Data Engineer Professional — Übungsfragen und Probeprüfung

Name: Pass-IT
Author: Pass-IT

Übe mit realistischen DB-DEP-Fragen, die an den Prüfungszielen ausgerichtet sind. Alex erklärt jede Antwort, und dein Readiness Score zeigt dir, was du als Nächstes lernen solltest.

Jetzt kostenlos für DB-DEP üben Zugang zu DB-DEP für $29.99 kaufen

Zugang zu DB-DEP für $29.99 kaufen Jetzt kostenlos für DB-DEP üben

Einmal zahlen. Dauerhafter Zugang zu dieser Zertifizierung.

Erst 5 Fragen ausprobieren →

59Fragen

120minZeitlimit

Geprüft gegen Databricks · August 2026Aktuelle Prüfungsversion

Überblick

Über die Prüfung

Die Prüfung Databricks Certified Data Engineer Professional weist fortgeschrittene Kenntnisse darin nach, produktive Datensysteme auf der Databricks Data Intelligence Platform zu bauen und zu optimieren. Geprüft werden Datenverarbeitungscode in Python und SQL, Ingestion und Transformation von Daten, Kosten- und Performance-Optimierung, Datensicherheit und Governance sowie das Debuggen und Deployen von Pipelines. Du musst zeigen, dass du die Interna von Delta Lake, die Governance mit Unity Catalog und das Performance-Tuning von Spark sicher beherrschst.

Die Zertifizierung richtet sich an erfahrene Data Engineers, die seit mindestens einem Jahr produktive Datenpipelines auf der Databricks Lakehouse Platform betreuen. Sie belegt, dass du komplexe Datensysteme im großen Maßstab entwerfen, absichern und betreiben kannst.

Prüfungsbereiche

Was geprüft wird

Die Entwicklung von Code für die Datenverarbeitung ist mit 22 % der größte Prüfungsbereich. Dazu gehören der Aufbau von Python-Projekten für Automation Bundles, eigene UDFs und produktionsreife ETL-Pipelines mit Structured Streaming und dem deklarativen Pipeline-Framework von Lakeflow. Danach folgt mit 13 % die Kosten- und Performance-Optimierung: Geprüft werden Liquid Clustering, Deletion Vectors und Tuning anhand von Query Profiles, nicht der einfache Bau einer Pipeline.

Ingestion, Transformation, Sharing, Monitoring, Security, Governance, Debugging und Modellierung machen mit je 5 bis 10 % den Rest aus und decken enger gefasste Praxisfähigkeiten ab: die Konfiguration von Delta Sharing, PII-Masking, Debugging über Event-Logs und dimensionale Modellierung, bei der Liquid Clustering an die Stelle manueller Partitionierung tritt.

Prüfungsaufbau: DB-DEP

Developing Code for Data Processing using Python and SQL22%

Structure Python projects for automation bundles and write the UDFs they call, build production ETL with Lakeflow pipelines, Autoloader, and Structured Streaming, handle change-data-capture and control-flow logic within them, and cover the result with unit and integration tests.

≈ 26 Std.

Data Ingestion and Acquisition7%

Fortgeschrittene Ingestion-Muster, Schema Evolution, Datenbeschaffung aus unterschiedlichen Quellen und der Umgang mit komplexen Datenformaten.

≈ 8 Std.

Data Transformation, Cleansing, and Quality10%

Fortgeschrittene Frameworks für Datenqualität, Expectations, Cleansing-Strategien und komplexe Transformationsmuster.

≈ 12 Std.

Data Sharing and Federation5%

Delta Sharing, Datenzugriff über Workspaces hinweg, Muster für Data Federation und die Integration externer Daten.

≈ 6 Std.

Monitoring and Alerting10%

Monitoring von Pipelines, Alerting-Strategien, Logging, Observability und Troubleshooting produktiver Daten-Workflows.

≈ 12 Std.

Cost and Performance Optimization13%

Performance-Tuning von Spark, Cluster-Sizing, Liquid Clustering, Z-Ordering, Caching-Strategien und Kostenmanagement.

≈ 16 Std.

Ensuring Data Security and Compliance10%

Datenverschlüsselung, Zugriffskontrollen, Audit-Logging, Compliance-Frameworks und Security Best Practices auf Databricks.

≈ 12 Std.

Data Governance7%

Fortgeschrittene Funktionen von Unity Catalog, Data Lineage, Tagging, Klassifizierung und Governance-Richtlinien.

≈ 8 Std.

Debugging and Deploying10%

CI/CD für Datenpipelines, Databricks Asset Bundles, Teststrategien, Debugging-Techniken und Automatisierung des Deployments.

≈ 12 Std.

Data Modeling6%

Design large-scale data models on Delta Lake, replace manual partitioning and Z-ordering decisions with Liquid Clustering, and structure dimensional models built for fast, accurate analytical queries.

≈ 7 Std.

Format

Format und Fragetypen

In 120 Minuten bekommst du 59 gewertete Multiple-Choice-Fragen, dazu können ungewertete Pilotfragen kommen. Die Fragen sind stark szenariobasiert und drehen sich um Performance-Tuning, Security-Umsetzung und Pipeline-Debugging. Erwartet wird Sicherheit bei den Interna von Delta Lake und der Governance mit Unity Catalog, nicht auswendig gelerntes API-Wissen an der Oberfläche.

Fragetypen: DB-DEP

Multiple Choice100%

Eine einzige beste Antwort aus vier oder fünf Optionen — das Brot-und-Butter-Format der Prüfung.

Databricks bestätigt diese Fragetypen — eine prozentuale Verteilung wird nicht publiziert; die Aufteilung spiegelt unseren am Exam ausgerichteten Fragenpool wider.

Jetzt ausprobieren

Fünf DB-DEP-Fragen zum Ausprobieren

Fünf Fragen direkt aus unserem Databricks Certified Data Engineer Professional-Pool. Beantworte eine — Alex erklärt dir das Warum.

Die Prüfung und die App sind auf Englisch — diese Beispielfragen haben wir übersetzt.

Datensicherheit und Compliance sicherstellen1 / 5

Ein Data Engineer stellt fest, dass die Audit-Logs von Unity Catalog unbefugte Zugriffsversuche auf eine sensible Produktionstabelle zeigen. Welche Schritte solltest du zur Untersuchung und Behebung unternehmen?

AlexGanze Erklärung von Alex

Ablauf einer Sicherheitsuntersuchung: 1) Erkennen: Alarm bei fehlgeschlagenen Zugriffsversuchen auf sensible Tabellen. 2) Untersuchen: Audit-Logs nach Benutzeridentität, Zugriffsmustern und Zeitpunkten abfragen. 3) Bewerten: War der Zugriffsversuch des Benutzers legitim (z. B. falscher Tabellenname) oder verdächtig (wiederholte Versuche auf PII-Tabellen)? 4) Beheben: Übermäßige Berechtigungen entziehen (Prinzip der geringsten Rechte), Monitoring-Alerts hinzufügen, Zeilenfilter implementieren, wenn Daten teilweise zugänglich sein müssen. 5) Vorbeugen: Sensible Tabellen mit Klassifizierungs-Tags versehen, an Tags gebundene Datenzugriffsrichtlinien erstellen. 6) Berichten: Vorfall, ergriffene Maßnahmen und Richtlinienänderungen dokumentieren. Laufend: Wöchentliche Reviews der Audit-Logs auf auffällige Zugriffsmuster einplanen.

Quelledocs.databricks.com

Datentransformation, -bereinigung und -qualität2 / 5

Ein Data Engineer hat eine Delta-Tabelle, in der einige Spalten tief verschachtelte Structs und Arrays enthalten. Analysten beklagen, dass sich die Daten nur schwer abfragen lassen. Welche Flattening-Strategie macht sie zugänglich und erhält dabei die Datenbeziehungen?

AlexGanze Erklärung von Alex

Muster zum Flachlegen verschachtelter Daten: 1) Struct: df.select('order_id', 'customer.name', 'customer.email'). SQL: SELECT customer.name FROM orders. 2) Array: df.select('order_id', explode('items').alias('item')). SQL: SELECT EXPLODE(items) FROM orders. 3) Verschachteltes Array von Structs: df.select('order_id', explode('items').alias('item')).select('order_id', 'item.product', 'item.qty'). 4) Map: df.select('order_id', explode('metadata').alias('key', 'value')). 5) Star-Expansion: df.select('order_id', 'customer.*'). Erweitert das Struct zu einzelnen Spalten. 6) Rekursives Flattening: Schreibe für tief verschachtelte Strukturen eine rekursive Funktion, die das Schema durchläuft und die select-Ausdrücke generiert. 7) Zu beachten: Kardinalitätsexplosion — EXPLODE auf Arrays vervielfacht die Zeilenzahl. Nutze array_size(), um die Vergrößerung abzuschätzen. Bei Arrays mit hoher Kardinalität (100+ Elemente) solltest du eine Aggregation vor dem Flattening in Betracht ziehen.

Quelledocs.databricks.com

Data Governance3 / 5

Ein Data Engineer soll eine Lösung umsetzen, bei der verschiedene Geschäftsbereiche ihre eigenen Datenkataloge unabhängig verwalten und sich zugleich ein gemeinsames Governance-Framework teilen. Wie unterstützt der dreistufige Namespace von Unity Catalog das?

AlexGanze Erklärung von Alex

Unity-Catalog-Namespace: 1) Dreistufig: catalog.schema.table. Catalog: organisatorische Grenze auf oberster Ebene. Schema: logische Gruppierung innerhalb eines Katalogs. Table/View/Function: Datenobjekte. 2) Katalogstrategien: pro Geschäftsbereich: finance_catalog, marketing_catalog. Pro Umgebung: dev_catalog, staging_catalog, prod_catalog. Pro Domäne: customers_catalog, orders_catalog. Hybrid: prod_finance, prod_marketing, dev_shared. 3) Delegation der Eigentümerschaft: Der Katalogeigentümer verwaltet seinen Katalog. Kann Schemas anlegen und Berechtigungen vergeben. Kann andere Kataloge nicht ändern. 4) Einheitliche Governance: Der Metastore-Admin legt fest: Standardberechtigungen. Aufbewahrung der Audit-Logs. Anforderungen an die Datenklassifizierung. Das gilt für alle Kataloge. 5) Migration: vom Hive Metastore: default (ein einzelner Katalog) → Migration auf mehrere Kataloge. SHOW DATABASES → wird zu Schemas in einem Katalog. 6) Grenzen: ein Metastore pro Region. Mehrere Kataloge pro Metastore. Hunderte Schemas pro Katalog. Millionen Tabellen pro Schema.

Quelledocs.databricks.com

Code für die Datenverarbeitung mit Python und SQL entwickeln4 / 5

Ein Data Engineer baut einen PySpark-Batch-Job, der eine komplexe, in reinem Python geschriebene Scoring-Berechnung auf Zeilenebene auf ein DataFrame mit 200 Millionen Zeilen anwenden muss. Die Logik lässt sich nicht mit integrierten Spark-SQL-Funktionen ausdrücken. Gewünscht sind der geringste Serialisierungs-Overhead und die beste in der DataFrame API verfügbare Performance. Welcher Ansatz sollte gewählt werden?

AlexGanze Erklärung von Alex

Standard-Python-UDFs in Spark serialisieren die Daten zeilenweise über die Grenze zwischen JVM und Python, was bei großen Datenmengen teuer ist. Pandas-UDFs (auch vektorisierte UDFs genannt) nutzen stattdessen Apache Arrow, um spaltenweise Batches zu übertragen, und führen pandas-Code auf Series oder DataFrames aus, wodurch sich die Serialisierung über viele Zeilen amortisiert. Anders als collect() halten sie die Arbeit über die Executor verteilt, und anders als die RDD API behalten sie die Catalyst-Planung bei. Für eigene Python-Logik, die sich nicht mit nativen Spark-Funktionen ausdrücken lässt, ist eine Pandas-UDF die empfohlene Variante mit hoher Performance. Native Spark-SQL-Funktionen bleiben die erste Wahl, wenn sich die Logik damit ausdrücken lässt. Prüfungstipp: Wenn eine Frage 'eigene Python-Logik' mit 'bester Performance' auf großen Datenmengen kombiniert, wähle die Pandas- bzw. vektorisierte UDF statt einer einfachen Python-UDF.

Quelledocs.databricks.com

Datenaustausch und Föderation5 / 5

Ein Data Engineer soll eine Reverse-ETL-Pipeline bauen, die aggregierte Daten aus dem Delta-Lakehouse über dessen API zurück in ein operatives CRM-System schiebt. Welche Architektur unterstützt zuverlässiges Reverse ETL?

AlexGanze Erklärung von Alex

Bestandteile von Reverse ETL: 1) Quellabfrage: SELECT customer_id, total_orders, avg_order_value, churn_score FROM gold.customer_360 WHERE updated_at > last_sync_time. 2) Sync-Tracking: CREATE TABLE sync_status (record_id STRING, target STRING, last_synced TIMESTAMP, status STRING, error_message STRING). 3) API-Integration: for batch in batches: try: response = crm_api.upsert(batch). update_status(batch, 'synced'). except RateLimitError: sleep(backoff). retry. except APIError as e: update_status(batch, 'failed', str(e)). 4) Idempotenz: Upsert-API-Aufrufe verwenden (anlegen oder aktualisieren). Ein erneuter Lauf synchronisiert dieselben Datensätze ohne Duplikate. 5) Monitoring: Alarm, wenn die Fehlerrate der Synchronisation den Schwellwert überschreitet. Dashboard: synchronisierte Datensätze pro Lauf, Fehlerraten, Latenz. 6) Zeitplan: an den Aktualisierungsrhythmus der Gold-Tabelle anpassen. Wenn Gold täglich um 6 AM aktualisiert wird, synchronisiere um 7 AM mit dem CRM.

Quelledocs.databricks.com

Kostenlos starten

Fragenpool

318 Fragen, gebaut wie die Prüfung

Der DB-DEP-Pool deckt jede Domain ab und wird laufend um neue Fragen erweitert. Eine Probeprüfung stellt dir 59 Fragen am Stück, mit derselben 120-Minuten-Uhr wie am Prüfungstag.

Prüfprotokoll: DB-DEP

Spec-Abgleich gegen Databricks4. August 2026

zuletzt gegen die offizielle Databricks-Quelle verifiziert

Blueprint-Deckung27 offizielle Lernziele

verteilt auf 10 Domains, laut offiziellem Prüfungsleitfaden

Pool-Größe318 Fragen

= 5 volle Probeprüfungen à 59 Fragen — nie dieselbe Frage zweimal

Kanonisch validiert318 von 318

einzeln gegen offizielle Databricks-Dokumentation geprüft — Antwort, Optionen und Erklärung, Quelle zitiert

Methodik offen dokumentiert.So entstehen unsere Fragen →

Planung

Vorbereitung auf DB-DEP

Wie lange du brauchst, hängt davon ab, wie viel Praxiserfahrung du mitbringst. Den Rest legt der Anbieter fest: wie die Prüfung abläuft, wie schnell du wiederholen darfst und wie lange das Zertifikat gültig bleibt.

Die Prüfung läuft online mit Remote-Proctor oder in einem Testcenter, angeboten auf Englisch, Japanisch, Portugiesisch (BR) und Koreanisch. Das Zertifikat gilt zwei Jahre; für die Rezertifizierung bestehst du die jeweils aktuelle Version der Prüfung.

Dein Plan: DB-DEP

Vorbereitung

Lernzeit70–180 Std.

typischerweise rund 70 Std., wenn du ohnehin mit diesen Technologien arbeitest, rund 180 Std. bei komplettem Neueinstieg

LevelProfessional

Vorher sinnvollKeine erforderlich. Empfohlen wird mindestens 1 Jahr praktische Erfahrung mit Databricks. Die Zertifizierung Data Engineer Associate ist hilfreich, aber keine Voraussetzung.

Prüfungstag & danach

PrüfungsartOnline beaufsichtigt oder Prüfungszentrum

WiederholungsregelnKeine verpflichtende Wartezeit. Es fällt eine Wiederholungsgebühr an.

Gültig2 Jahre

Alle 2 Jahre musst du dich rezertifizieren, indem du die jeweils aktuelle Prüfungsversion ablegst.

Offizieller LeitfadenAuf der Herstellerseite ansehen

Die Stundenzahl ist unsere eigene Planungsschätzung — Databricks veröffentlicht keine Vorbereitungszeit für diese Prüfung. Ein Startwert für deinen Kalender, keine Vorgabe.

Achtung

Häufige Fehler

Auf dieser Stufe zählen die Interna von Spark mehr als API-Routine. Du sollst Liquid Clustering und Z-Ordering anhand ihrer Trade-offs auseinanderhalten, einen fehlgeschlagenen Job über Cluster-Logs und Query Profiles zurückverfolgen, statt aus Symptomen zu raten, und wissen, wann Change Data Feed eine Einschränkung von Streaming Tables löst, an der Delta Sharing scheitert. Data Sharing und Federation ist mit 5 % ein kleiner Bereich, doch der Unterschied zwischen Databricks-zu-Databricks-Sharing und dem offenen Sharing-Protokoll taucht in konkreten, prüfbaren Details auf. Debugging und Deployment bringt 10 % und zahlt sich vor allem dann aus, wenn du selbst schon eine Pipeline zerschossen und sie über Automation Bundles wieder repariert hast, statt nur darüber gelesen zu haben.

Stolperstellen: DB-DEP

01Quarantine Pipeline Design
Wer für Records, die die Validierung nicht bestehen, keinen eigenen Quarantäne-Pfad baut, sondern sie einfach verwirft oder still durchlaufen lässt, liegt bei Fragen zu Data-Quality-Pipelines falsch.
02Lakehouse Federation
Lakehouse Federation fragt externe Systeme live ab, Delta Sharing kopiert oder streamt Daten dagegen heraus. Wer beides verwechselt, antwortet bei Fragen zur Anbindung von Datenquellen falsch.
03PII Anonymization vs Masking
Column Masking, Row Filtering und echte Anonymisierung bzw. Pseudonymisierung von PII werden gern durcheinandergebracht, dazu bleibt das Löschen von Daten als Teil der Retention-Compliance oft außen vor. Beides kostet dich Punkte bei Security- und Compliance-Fragen.
04Permission Inheritance
Ein Grant auf Catalog-Ebene in Unity Catalog setzt sich nicht automatisch über einen enger gefassten Grant auf Schema- oder Table-Ebene hinweg. Wenn du das annimmst, statt das tatsächliche Vererbungsmodell zu kennen, gehen dir Governance-Fragen durch die Lappen.
05DAB Project Structure
Wer ein Python-Projekt innerhalb von Automation Bundles nicht für modulare Entwicklung und CI/CD-Integration strukturiert, scheitert an Deployment-Fragen, die einen bestimmten, testbaren Code-Aufbau voraussetzen.

Pass-IT trainiert dich gezielt auf genau diese Schwächen — adaptiv & verteilt →

Fragen

Häufige Fragen

Wie lange dauert die Prüfung Databricks Certified Data Engineer Professional?

Die Prüfung Databricks Certified Data Engineer Professional hat 59 Fragen und ein Zeitlimit von 120 Minuten.

Was sind häufige Fehler bei der Prüfung Databricks Certified Data Engineer Professional?

Häufige Fallstricke sind: Quarantine Pipeline Design, Lakehouse Federation, PII Anonymization vs Masking, Permission Inheritance, DAB Project Structure. Konzentriere deine Lernzeit auf diese Bereiche, um keine Punkte zu verlieren.

Wie bestehst du die Databricks Data Engineer Professional Prüfung?

Code für die Datenverarbeitung in Python und SQL zu schreiben ist mit 22% der größte Bereich, und die Fragen zeigen dir Code, statt ihn zu beschreiben. Das Katalogbudget liegt bei 120 Stunden, und Databricks empfiehlt ein Jahr oder mehr praktische Arbeit mit der Plattform. Wer sich schwertut, hat sich meistens mit Dokumentation vorbereitet, statt Pipelines zu bauen und kaputtzumachen.

Wie lange ist die Data Engineer Professional Zertifizierung gültig?

Zwei Jahre ab dem Bestehensdatum. Databricks rezertifiziert per Prüfung, du legst also die aktuelle Version erneut ab, statt Weiterbildungspunkte zu sammeln. Eine Kulanzfrist ist dabei nicht vorgesehen, die Wiederholung muss also vor dem Ablaufdatum stattfinden.

Wie ist die Data Engineer Professional Prüfung gewichtet?

Code für die Datenverarbeitung führt mit 22%, gefolgt von Kosten- und Performance-Optimierung mit 13%. Transformation und Qualität, Monitoring und Alerting, Sicherheit und Compliance sowie Debugging und Deployment machen je 10% aus, den Rest teilen sich Ingestion, Governance, Modellierung und Federation. Verteilt ist das über zehn Themengebiete, die Prüfung nimmt also den ganzen Job in den Blick statt nur einen Teil davon.

Solltest du zuerst den Data Engineer Associate machen?

Databricks nennt die Associate-Zertifizierung hilfreich, aber nicht verpflichtend, du kannst die Professional-Prüfung also direkt buchen. Der Abstand dazwischen ist real: 80 Stunden gegen 120 und Wiedererkennungsfragen gegen Fragen, in denen du Code liest. Wenn du weniger als ein Jahr auf der Plattform hast, ist die Associate-Prüfung der günstigere Weg, um herauszufinden, wo du stehst.

Welche Erfahrung setzt der Data Engineer Professional voraus?

Ein Jahr oder mehr praktische Arbeit mit Databricks, so die eigene Empfehlung von Databricks. Keine Zertifizierung versperrt dir die Buchung. Das Katalogbudget von 120 Stunden setzt diese Erfahrung bereits voraus, sieh es also als Untergrenze und nicht als Gesamtsumme.

Wie schnell kannst du die Data Engineer Professional Prüfung wiederholen?

Sofort, was die Databricks-Policy angeht: Es gibt keine verpflichtende Wartezeit. Die Grenze ist deine eigene Vorbereitung, nicht eine Sperrfrist.

Pass-IT ist ein unabhängiges Lernwerkzeug und weder mit Databricks verbunden noch von Databricks unterstützt; Databricks und Prüfungsnamen sind Marken ihrer jeweiligen Inhaber.

Eine Zertifizierung. Eine Zahlung.

Voller Zugang zu DB-DEP

Du bekommst den vollständigen Fragenpool für diese Zertifizierung. Alex erklärt jede Antwort, und dein Readiness Score zeigt dir, woran du als Nächstes arbeiten solltest.

Zugang zu DB-DEP für $29.99 kaufenEinmal zahlen. Dauerhafter Zugang zu dieser Zertifizierung.

Kostenlos prüfen, ob du bereit bist20 Fragen. Keine Karte nötig. Sieh vor dem Kauf, was du üben solltest.

Erreiche 80 % Readiness und bestehe die Prüfung — oder du bekommst dein Geld zurück.

So funktioniert der Score →