Data-Engineer-Associate - Data Ingestion and Loading (21% of the exam) - Section 2.5

Use JDBC/ODBC or REST clients in notebooks to land data into cloud storage or Unity Catalog governed tables, orchestrated with Lakeflow Jobs.

Read from relational sources over JDBC, and call REST APIs from a notebook, to land data in a volume or directly in a Unity Catalog table. Schedule and orchestrate the notebook with Lakeflow Jobs, and keep credentials in secrets rather than in code.

JDBC readsREST API ingestionUnity Catalog volumessecret scopesLakeflow Jobs

Practice question for this objective

Free sampleData Ingestion and Loadinghard

A team is standing up ingestion from a cloud storage bucket that a partner writes JSON files into throughout the day. Security policy states that no cloud credential may appear in notebook code, in cluster configuration or in job parameters, and that every read of the bucket must be attributable in the Unity Catalog audit log. The ingestion itself must stay incremental as the file count grows. How should the team set up the access path for the ingestion?

AStore the cloud access key in a Databricks secret scope, read it into a Spark configuration at the start of the ingestion notebook, and point Auto Loader at the bucket URI directly.
BRegister the bucket as a Unity Catalog external location backed by a storage credential, grant READ FILES on that location to the ingestion identity, and point Auto Loader at the location path. Correct
CAttach a cloud instance profile with read rights on the bucket to the ingestion cluster, and have every job that reads the partner data run on that one dedicated cluster.
DHave the partner copy the files into a Unity Catalog managed volume by hand each morning, then load the volume contents into the bronze table with a scheduled COPY INTO statement.

Govern object storage ingestion through a Unity Catalog external location and storage credential rather than credentials attached to code or compute. A storage credential holds the cloud identity once, and an external location binds that credential to a specific path so that READ FILES can be granted to particular users or service principals. Access then flows through Unity Catalog, which records it and enforces the grant, and Auto Loader reading that path inherits the governance. Secrets in a Spark configuration and instance profiles on a cluster both attach the credential to compute, which leaves access ungrantable per identity and unaudited by the governance layer.

Why A is wrong: Tempting because a secret scope does keep the literal key out of the source file, but the credential still reaches the cluster configuration and the read bypasses Unity Catalog, so it is not attributable in the audit log.

Why B is correct: Correct, because the storage credential holds the cloud identity centrally, the external location makes access grantable and auditable in Unity Catalog, and Auto Loader reads the path through that governed route.

Why C is wrong: Tempting because no key is written down anywhere, but the credential is bound to compute rather than to a governed object, so access cannot be granted per identity and the reads are not recorded by Unity Catalog.

Why D is wrong: Tempting because a managed volume is governed by Unity Catalog, but the manual daily copy replaces continuous incremental ingestion with a batch handover the partner has not agreed to perform.

See more Data-Engineer-Associate practice questions, answers explained.

Exam traps in Data Ingestion and Loading

Answers that look right on this material and are not. Each one is a distractor from a different question in the Data-Engineer-Associate bank for this domain.

An external table registered over the landing path, with the notebook writing the payload files into that path using ordinary Python file operations.
Why it is wrong: Tempting because an external table does sit over a governed storage path, but a table governs tabular reads of registered data rather than arbitrary file operations against the path.
Secrets resolve only during interactive sessions and cannot be read by code running in a Lakeflow Jobs task, so a scheduled run has to receive the password as a job parameter.
Why it is wrong: Tempting because unattended runs do behave differently in other respects, but a job task reads secrets the same way a notebook does, and a job parameter would store the password in the job definition.
Schedule the two notebooks as separate Lakeflow Jobs and set the second schedule forty minutes after the first, which is longer than the pull normally takes.
Why it is wrong: A time offset usually holds and looks simple to configure, but it is a guess about duration rather than a dependency, so a slow or failed pull still lets the parse start against incomplete files and the run status sits in two places.

Examworthy is not affiliated with or endorsed by Databricks. Original, blueprint-aligned practice material only.