Importing Data: Databricks Data Analyst Associate Practice Questions

A data analyst needs to upload a 5 MB comma-delimited CSV file to Databricks using only the Workspace UI — without writing any code or using the CLI. The file has a header row and several columns where the inferred data types are incorrect (for example, a column named order_id is inferred as DOUBLE instead of STRING, and order_date is inferred as STRING instead of DATE). Which statement CORRECTLY describes what the analyst can do during the UI upload workflow to fix the type issues before the table is created, and what format the table will be stored in?

1. AThe Workspace UI auto-infers column types from the CSV header row only — it does not parse any data rows for type inference. As a result, type inference is always wrong and produces STRING for every column. The analyst cannot change column types during the upload wizard; all type corrections must be made after the upload completes by running ALTER TABLE catalog.schema.table_name ALTER COLUMN order_id TYPE STRING and ALTER TABLE catalog.schema.table_name ALTER COLUMN order_date TYPE DATE in the SQL Editor. The uploaded table is stored in CSV format on cloud storage to preserve the original file layout.
2. BDuring the upload wizard, the analyst can preview the parsed data and manually override the inferred data types for individual columns — for example, changing order_id from DOUBLE to STRING and order_date from STRING to DATE — before the table is created. The analyst can also edit column names if needed. Once the analyst confirms the schema and selects a target catalog and schema, Databricks writes the data as a managed Delta table in Unity Catalog storage. The resulting table is stored in Delta format (not CSV), enabling full ACID transaction support, time travel, and standard SQL DML.
3. CThe Workspace UI upload wizard infers data types by running a statistical profile of the first 1,000 rows and locks in the inferred types — column type overrides are not permitted during the upload wizard because changing types could alter how row values are parsed, which Databricks considers a data integrity risk. After upload, the table is created with all static types and stored in Parquet format. To change the order_id column to STRING after the fact, the analyst must drop and recreate the table with the corrected schema definition using a CREATE OR REPLACE TABLE statement that casts the columns during the SELECT.
4. DThe Workspace UI upload is designed for append-only scenarios and creates an external table pointing to the uploaded CSV file in DBFS rather than a managed Delta table. Since it is an external CSV table, the analyst cannot change column types in the wizard — the inferred types are derived directly from the CSV header metadata embedded in the file itself. To correct the type for order_date, the analyst must rename the column in the CSV header from order_date to order_date_DATE — the Databricks CSV reader recognizes this suffix naming convention and automatically casts the column to DATE type at query time.
5. EThe Workspace UI upload wizard allows column type changes only for numeric columns (INT, BIGINT, FLOAT, DOUBLE) — date and timestamp type corrections are not supported because DATE parsing requires specifying a locale and date format string, which is beyond the scope of the upload wizard's interface. The analyst can change order_id from DOUBLE to STRING but must accept STRING for order_date and handle the conversion in a downstream SQL view using CAST(order_date AS DATE FORMAT 'yyyy-MM-dd'). Tables created via the upload wizard are stored in Delta format but are automatically marked as read-only, requiring the analyst to clone the table with CREATE TABLE ... DEEP CLONE before any DML operations are permitted.

A data engineering team is evaluating five different data ingestion scenarios for their Databricks platform and needs to identify the BEST-FIT mechanism for each. The scenarios are: (A) continuously ingesting new JSON files dropped into an Amazon S3 bucket by an upstream ETL tool throughout the day, (B) giving a business partner on a non-Databricks platform read-only access to a live Delta table without copying the data to their system, (C) pulling fresh records from a SaaS application's REST API on a scheduled basis, (D) allowing a separate Databricks account (on Azure) to query tables managed in the current AWS-based workspace, and (E) making a curated reference dataset produced internally available to any Databricks customer globally. Which mapping of scenario to ingestion mechanism is CORRECT?

1. AA → Delta Sharing open sharing; B → Auto Loader with file notification mode; C → Databricks Marketplace listing; D → Direct S3 mount with cross-account IAM role; E → API-driven intake via a Databricks Job that calls the Databricks REST API to replicate tables across accounts. Delta Sharing cannot be used between organizations on different cloud providers because the Delta Sharing protocol is cloud-specific and the bearer token credential format differs between AWS, Azure, and GCP.
2. BA → Auto Loader (cloudFiles Structured Streaming source); B → Delta Sharing open sharing (bearer token or OIDC — recipient consumes from any platform); C → API-driven intake (a Databricks Job or notebook calling the SaaS REST API and writing results to Delta); D → Delta Sharing Databricks-to-Databricks sharing (cross-account, cross-cloud, no token management needed for D-to-D); E → Databricks Marketplace (publish the dataset as a listing so any Databricks customer can discover and install it). These five mechanisms are distinct, purpose-built ingestion and sharing tools in the Databricks platform.
3. CA → Lakeflow Jobs cron-triggered batch COPY INTO from S3; B → Auto Loader with file notification mode on the partner's storage; C → Databricks Marketplace REST connector listing that Databricks manages on behalf of all customers; D → Delta Sharing open sharing using a long-lived bearer token sent to the Azure-based account; E → S3 cross-region replication configured outside Databricks, followed by Unity Catalog external table registration. Databricks-to-Databricks Delta Sharing is only supported between workspaces in the same Databricks account — it cannot be used across separate accounts.
4. DA → Databricks Marketplace; B → Auto Loader with schema inference enabled pointing to the partner's cloud storage path; C → Delta Sharing open sharing, because SaaS APIs use HTTP and Delta Sharing is built on HTTPS — they are architecturally equivalent; D → Unity Catalog cross-metastore catalog binding, which enables read-only catalog access across all accounts globally without any data movement; E → COPY INTO with a public S3 presigned URL published in documentation. The Auto Loader feature cannot process JSON files from Amazon S3 because it only supports PARQUET and AVRO formats natively; JSON requires a separate schema registry integration.
5. EA → Delta Lake MERGE with a Structured Streaming trigger; B → Databricks Marketplace (publish the live table as a commercial listing visible only to the single partner); C → Auto Loader in file notification mode configured to detect webhook payloads written to a Unity Catalog volume by the SaaS provider; D → Lakeflow Jobs cross-account task cluster with unity_catalog_cross_account=true set in the cluster policy JSON; E → Delta Sharing Databricks-to-Databricks sharing restricted to internal accounts only. API-driven data intake and Auto Loader are the same feature set in Databricks — Auto Loader is the official name for applying Structured Streaming to REST API polling patterns when the source is external to Databricks.

A business analyst with no engineering background wants to load a 15 MB CSV file of monthly sales data into Databricks for ad-hoc analysis in a SQL notebook. The analyst has Contributor access to a Unity Catalog workspace. A colleague suggests using the Databricks Workspace UI file upload feature. Which description MOST ACCURATELY describes the file upload experience and what happens to the data after the upload completes?

1. AThe Databricks Workspace UI file upload feature is only available to workspace administrators — Contributor-level users cannot access it because file uploads bypass the Unity Catalog lineage capture system and Databricks restricts this bypass to administrators. After an admin uploads the file, the analyst must manually convert the raw uploaded file to a Delta table by running CONVERT TO DELTA in a SQL notebook before it becomes queryable.
2. BThe analyst can use the Databricks Workspace UI (via the SQL Editor's 'Add data' or 'Create table' workflow, or via the Catalog Explorer upload entry point) to upload the CSV file directly from their local machine. During the upload wizard, the analyst can preview the parsed data, adjust inferred column types and names, and choose a target catalog and schema. Upon completion, Databricks writes the CSV data to a new managed Delta table in the specified Unity Catalog location — making it immediately queryable in a SQL notebook or the SQL Editor using the standard three-part catalog.schema.table namespace, with no additional conversion step required.
3. CUploading a file through the Workspace UI places the raw CSV file into the Databricks File System (DBFS) root at dbfs:/FileStore/tables/. The analyst must then open a notebook and manually write a PySpark spark.read.csv() command to parse the file, followed by .write.format('delta').saveAsTable('catalog.schema.table_name') to persist it as a queryable Delta table. The UI upload step itself creates no table and has no awareness of Unity Catalog schemas or catalogs — it is purely a raw file transfer to DBFS.
4. DThe Databricks Workspace UI file upload feature supports only files in Apache Parquet and ORC format because those formats embed schema metadata that the UI wizard requires to auto-generate the CREATE TABLE DDL statement. CSV files must first be converted to Parquet by the analyst on their local machine using a tool such as Python's pandas.DataFrame.to_parquet() before they can be uploaded via the Workspace UI. Attempting to upload a CSV directly through the UI raises an 'UnsupportedFileTypeException' that blocks the upload wizard from proceeding.
5. EThe Workspace UI file upload creates a temporary table that exists only for the duration of the current browser session. Once the analyst closes the Databricks workspace tab or the session times out, the uploaded table and all its data are permanently deleted because file upload tables are stored in an in-memory session-scoped schema that does not persist to cloud object storage. To create a persistent table from a CSV upload, the analyst must use the Databricks CLI command databricks fs cp localfile.csv dbfs:/tables/ followed by a COPY INTO SQL statement.

A data engineer is setting up an Auto Loader pipeline to ingest new CSV files that land in an Amazon S3 bucket every hour. The files sometimes have new columns added by the upstream system without advance notice, and the team wants the pipeline to handle this gracefully without manual intervention. The engineer also asks their manager whether Auto Loader guarantees that each file is processed only once even if the pipeline is restarted due to a cluster failure. Which combination of statements about Auto Loader's schema handling and fault tolerance behavior is CORRECT?

1. AAuto Loader does not support schema inference for CSV files — CSV is a schema-less text format and Auto Loader requires the user to provide an explicit schema definition via the .schema() method before the stream can start. If the stream is restarted after a cluster failure, Auto Loader re-reads all previously processed files from the beginning of the S3 directory because there is no external state store to persist the read position; exactly-once semantics require the user to implement their own deduplication logic using a Delta MERGE statement on the target table.
2. BAuto Loader supports schema inference and schema evolution for CSV and other supported file formats — it automatically samples incoming files to infer the schema on the first run and can detect new columns in subsequent batches. New columns are either added to the inferred schema (when evolution mode is configured) or rescued into a separate JSON column so no data is silently dropped. For fault tolerance, Auto Loader persists file metadata and ingestion state in a RocksDB-backed checkpoint location, allowing the pipeline to resume exactly where it left off after a cluster failure and guaranteeing exactly-once processing without any user-managed deduplication logic.
3. CAuto Loader provides exactly-once guarantees only when writing to external databases via JDBC connections — when writing to Delta Lake tables the guarantee degrades to at-least-once because Delta Lake's transaction log does not integrate with Auto Loader's checkpoint mechanism. For schema evolution, Auto Loader requires the pipeline to be stopped, the new schema registered manually in the Unity Catalog using ALTER TABLE ADD COLUMN, and the pipeline restarted. Until the new column is registered, data in the new column is silently dropped without raising any error or alert.
4. DAuto Loader's schema inference samples only the first 50 files in the target directory to build its initial schema — any new columns appearing in later files will cause the stream to throw a SchemaMismatchException and halt. The operator must manually add the column to the schema configuration and restart the stream. Auto Loader does persist a checkpoint, but the checkpoint only stores the directory listing offset and not individual file metadata, so exactly-once semantics are only guaranteed for files that arrive after the checkpoint is initialized — files that were landing during cluster initialization are processed twice.
5. EAuto Loader guarantees exactly-once processing but only for PARQUET files, because PARQUET files embed a schema that Auto Loader uses to verify whether a file has already been processed by comparing embedded file UUIDs with entries in the checkpoint. For CSV and JSON files (which lack embedded schemas), Auto Loader falls back to at-least-once semantics. Schema evolution is handled through a manual process where the data engineer must run ALTER TABLE REFRESH SCHEMA on the target Delta table after each new upstream column is detected, which triggers a one-time backfill of the new column for all previously ingested rows.