Skip to content

模擬試験|Professional(59問 / 120分)

本番形式の模擬試験です。05_practice-questions/professional/ の確認問題とは問題が重複しません。 Professional は「長文シナリオを読み切るスタミナ」と「時間配分」が最大の敵です。この模試の目的は知識確認だけでなく 120 分の通し練習にあります。

受験ルール(本番と同じ条件で)

項目設定
問題数59 問(本番は採点対象 59 問+未採点問題)
制限時間120 分(1 問あたり約 2 分)
合格ライン70% 以上 = 42 問正解
教材参照禁止(解き終わるまで開かない)
迷った問題番号をメモして後回し。全問到達を優先
  1. タイマーを 120 分にセットする
  2. 「問題」だけを見て 59 問を解き、解答をメモに書き出す(Q1: C の形式)
  3. 時間が来たら手を止める
  4. 「解答一覧」で自己採点し、「採点表」でドメイン別の正答率を出す
  5. 弱点ドメインの教材・確認問題・ハンズオン課題に戻る

出題数の配分(公式の配点に比例)

ドメイン配点本模試の問題数
① Python/SQL コード開発22%13 問
② コスト・パフォーマンス最適化13%8 問
③ データ変換・クレンジング・品質10%6 問
④ モニタリング・アラート10%6 問
⑤ セキュリティ・コンプライアンス10%6 問
⑥ デバッグ・デプロイ10%6 問
⑦ データインジェスト7%4 問
⑧ データガバナンス7%4 問
⑨ データモデリング6%3 問
⑩ データ共有・フェデレーション5%3 問
合計100%59 問

問題

Q1. Sales 部門に Lisa 10000 / Alex 30000 / Bob 30000 / Evan 32000 の 4 行がある。次のクエリの出力として正しいものはどれか。

sql
SELECT name, salary,
       ROW_NUMBER() OVER (ORDER BY salary) AS rn,
       RANK()       OVER (ORDER BY salary) AS rnk,
       DENSE_RANK() OVER (ORDER BY salary) AS drnk
FROM employees WHERE dept = 'Sales';
  • A. Lisa 1,1,1 / Alex 2,2,2 / Bob 3,3,3 / Evan 4,4,4
  • B. Lisa 1,1,1 / Alex 2,2,2 / Bob 2,2,2 / Evan 3,3,3
  • C. Lisa 1,1,1 / Alex 2,2,2 / Bob 3,2,2 / Evan 4,4,3
  • D. Lisa 1,1,1 / Alex 2,2,2 / Bob 3,3,2 / Evan 4,4,4

Q2. 行フィルターと列マスクを手動でテーブルに割り当てるために必要な権限として正しいものはどれか。

  • A. 関数への EXECUTE、スキーマへの USE SCHEMA、親カタログへの USE CATALOG。新規テーブル作成時に付ける場合はスキーマへの CREATE TABLE。既存テーブルで追加・削除する場合はテーブル所有者、または MANAGESELECT の両方。同じステートメントでスキーマも変更する場合(マスク付き列の追加など)は MODIFY も必要
  • B. テーブルへの SELECT だけあれば割り当てられる
  • C. メタストア管理者権限が必須である
  • D. 関数への OWNERSHIP が必須で、EXECUTE では割り当てられない

Q3. OPTIMIZE の性質について正しい説明はどれか。

  • A. OPTIMIZE はデータの中身を変えるため、実行前後で読み取り結果が変わる可能性がある
  • B. ビンパッキングはべき等(同じデータセットに 2 回実行しても 2 回目は効果なし)で、サイズ的に均等なファイルを目指す(ファイルあたりのタプル数と必ずしも一致しないが相関することが多い)。読み手はスナップショット分離を使うため中断されず、データを変更しないので前後で結果は同じストリーミングソースにも影響しない。戻り値として削除/追加ファイルの統計・Z オーダー統計・バッチ数・最適化されたパーティションを返す
  • C. OPTIMIZE の実行中はテーブルの読み取りがブロックされる
  • D. OPTIMIZE を実行するとストリーミングソースとしてのテーブルが再処理される

Q4. クラウドオブジェクトストレージから SQL で増分取り込みしたい。教材の推奨と、Auto Loader のサポート範囲として正しいものはどれか。

  • A. COPY INTO が最もスケーラブルなので、規模に関わらず COPY INTO を使う
  • B. Auto Loader は SQL からは使えないため、必ず Python / Scala で書く
  • C. Auto Loader がサポートするファイル形式は JSON と Parquet のみである
  • D. COPY INTO ではなく CREATE STREAMING TABLE(内部で read_files = Auto Loader) が、スケーラブルで堅牢なため推奨される。Auto Loader のサポートソースは S3(s3://)/ ADLS(abfss://)/ GCS(gs://)/ UC ボリューム(/Volumes/)/ Azure Blob(wasbs://)、形式は JSON, CSV, XML, PARQUET, AVRO, ORC, TEXT, BINARYFILE(事前圧縮ファイルも可)

Q5. 次のコードを実行した結果として正しいものはどれか。

python
df = spark.createDataFrame([(1, "a")], "id INT, name STRING")
df.withColumnRenamed("name", "full_name")
df.printSchema()
  • A. df は不変なので withColumnRenamed の結果は反映されず、printSchema()id, name を表示する。反映させるには結果を変数に代入する必要がある(Scala では特に新しい変数への代入が必須)
  • B. printSchema()id, full_name を表示する(withColumnRenamed は破壊的変更)
  • C. withColumnRenamed はアクションなので、この時点で列名が変更されて永続化される
  • D. 変数に代入していないため実行時エラーになる

Q6. システムテーブルを本番運用で使う際の注意点として正しいものはどれか。

  • A. スキーマは固定されているため、固定スキーマ前提のクエリを書いても壊れない
  • B. 選択性の低いクエリでも自動的に最適化されるため、述語は不要である
  • C. 既存テーブルに新しい列がいつでも追加され得る(構造体列にも新フィールド)ため、別テーブルへ書き出す場合はスキーマ進化を有効化する。既存列は変更・削除されない。選択性の低いクエリは System Table query returned too much data. Please repeat query with more selective predicates. で失敗するため述語で期間を絞る。非推奨スキーマsystem.operational_datasystem.lineage(空テーブル)
  • D. system.lineage スキーマが現行のリネージ用スキーマである

Q7. データ品質ルール(Expectations の制約定義)を再利用・監査可能にするパターンとして正しいものはどれか。

  • A. 期待値の定義はパイプラインコード内にハードコードするのが唯一の方法である
  • B. ルールを Delta テーブルや Python モジュール/辞書に外部化して再利用・監査・保守できる。例えば name / constraint / tag 列を持つ rules テーブルを作り、get_rules(tag) でタグに一致するルールを辞書として読み込み @dp.expect_all_or_drop(get_rules('validity')) のように適用する。注意: SQL ではファイルからの期待値の動的読み込みは非対応
  • C. ルールの外部化は SQL でのみ可能で、Python では非対応である
  • D. ルールを外部化すると品質メトリックが取得できなくなる

Q8. Spark UI のジョブタイムライン(イベントタイムライン)で着目すべきパターンとして正しいものはどれか。

  • A. 実行のギャップは 1 秒以上あれば必ず異常である
  • B. 失敗したジョブ・Executor は緑で表示される
  • C. タスクが 1 つだけのステージは、並列化が効いている健全な状態である
  • D. 失敗したジョブ/Executor は赤で表示される。実行のギャップは 1 分以上の空白を探す(短い中断はドライバーが調整するため正常。クラスターが常時起動しているだけの一時停止と区別する)。1 つの長いジョブが支配しているならそれを深掘り、数秒以下の小さな青い線が大量にあるなら「多数の小さな Spark ジョブ」。どれにも当てはまらなければ期間(Duration)でソートして最長ジョブを開く。なおタスクが 1 つだけ = 問題のサイン

Q9. explode 系関数の違いとして正しいものはどれか。

  • A. explode(array_or_map) は各要素を個別の行に展開するが空/NULL の要素は行が消えるexplode_outer(...) は空/NULL でも NULL 行を保持する。posexplode(...) は要素と併せて位置(インデックス)も返す。inline(array_of_structs) は構造体配列を複数列に展開する。逆操作は collect_list / collect_set
  • B. explode は空/NULL でも NULL 行を保持し、explode_outer は行を消す
  • C. posexplode は構造体配列を複数列に展開する関数である
  • D. inline は要素と位置の 2 列を返す

Q10. Well-Architected の「データと AI ガバナンス」の柱が示す 3 つのアーキテクチャ原則として正しいものはどれか。

  • A. コスト最適化・パフォーマンス効率・信頼性
  • B. ①データと AI 管理を統合する(統合カタログで全資産とメタデータを一元管理し、検出と系列追跡を可能にする)、②データと AI セキュリティを統合する(「誰がどのデータにアクセスできるか」と「誰が最近どのデータにアクセスしたか」の 2 つの教義。アクセス許可の一元管理+一元的な監査)、③データ品質基準を確立する(完全性・精度・有効性・一貫性などのディメンション)
  • C. 暗号化・ネットワーク分離・監査ログ
  • D. 取り込み・変換・提供の 3 レイヤー

Q11. 予測的最適化の有効化の粒度と挙動について正しい説明はどれか。

  • A. アカウントレベルでのみ有効化でき、カタログやテーブル単位の制御はできない
  • B. 一度無効化しても、後からアカウントレベルで有効化すれば自動的に有効になる
  • C. 有効化するとすべてのテーブル(外部テーブルを含む)で自動メンテナンスが走る
  • D. アカウント / カタログ / スキーマ / テーブルの粒度で制御でき、継承モデルALTER ... ENABLE | DISABLE | INHERIT PREDICTIVE OPTIMIZATION)に従う。明示的に無効化したオブジェクトは、後からアカウントレベルで有効化してもブロックされたまま2024-11-11 以降に作成されたアカウントは既定で有効、既存アカウントは段階的ロールアウトで 2026 年 8 月までに完了予定

Q12. AUTO CDC の付加機能と要件について正しい説明はどれか。

  • A. AUTO CDC のターゲットはパイプライン実行中に一切の DML を受け付けない
  • B. AUTO CDC のターゲットは CDF を出力できないため、下流は変更を消費できない
  • C. 標準ストリーミングテーブルと異なり、AUTO CDC ターゲット(Unity Catalog テーブル)はパイプライン実行中でも INSERT / UPDATE / DELETE / MERGE をサポートする。ターゲットは独自の CDF を出力でき、下流パイプラインが AUTO CDC 出力の変更を消費できる。実行ごとに num_upserted_rows / num_deleted_rows のメトリクスが自動キャプチャされる。要件は Pro または Advanced エディション(あるいはサーバーレス) のパイプラインで、Apache Spark 宣言パイプラインでは非サポート
  • D. AUTO CDC は Standard エディションのパイプラインでも制限なく使える

Q13. Unity Catalog 管理 UDF とセッションスコープ UDF の違いとして正しいものはどれか。

  • A. UC 管理 UDF はチーム・ノートブック・ジョブ・SQL ウェアハウス間で安全に共有するのに適し、対応言語は SQL, Python, Scala, Java、UC の権限で管理されカタログエクスプローラーで検出でき、UC に永続化されセッション間で再利用できる。セッションスコープ UDF は 1 ノートブック/ジョブ内での迅速な反復開発に適し、対応言語は SQL, Python, Scala(Java は不可)、現在の SparkSession 限定で管理も共有もされない
  • B. UC 管理 UDF は SQL のみ対応で、Python は使えない
  • C. セッションスコープ UDF も UC に永続化され、他ユーザーから参照できる
  • D. UDAF は UC 管理 UDF として永続化できる

Q14. 行フィルター/列マスク付きテーブルに対して REPLACE TABLE を実行したときの挙動として正しいものはどれか。

  • A. 行フィルターと列マスクはすべて削除されるため、明示的に再定義する必要がある
  • B. スキーマ変更に関係なく既存の行フィルターは保持される。新テーブルにマスク付き列と同名の列があれば列マスクも保持される(明示的に再定義しなくてもポリシーが残る=誤消去防止)。ただし保持されたポリシーが削除/変更された列を参照すると後続クエリが失敗し得るため、その場合は ALTER TABLE で更新/削除する
  • C. REPLACE TABLE 自体がエラーになり実行できない
  • D. 行フィルターは保持されるが、列マスクは必ず削除される

Q15. 1 つのジョブで複数のストリームを動かす 2 つの戦略の違いとして正しいものはどれか。

  • A. どちらの戦略でも、1 つのストリームが失敗するとジョブ全体が即座に失敗する
  • B. 複数のタスク戦略では全ストリームが同じコンピューティングを共有しなければならない
  • C. 複数のタスク(Multiple tasks): 各ストリーミングタスクに適サイズの Jobs Compute を推奨(必要ならタスク間で共有可)。ジョブ再試行前にすべてのタスクが失敗する複数のクエリ(Multiple queries): すべてのクエリが同じコンピューティングを共有(必要ならスケジューラプールに割当)。クエリが失敗するとそのタスクが再試行する。なお継続的トリガーを使う場合、タスク間の依存関係は設定できない
  • D. 複数のクエリ戦略では、1 クエリの失敗が他のクエリに一切影響しない

Q16. MERGE INTO における欠損値(NULL)の扱いについて正しい説明はどれか。

  • A. INSERT (...) VALUES (...) でターゲット列を省略するとエラーになる
  • B. DEFAULT を式に指定することはできない
  • C. INSERT * EXCEPT (col) で除外した列は元の値が保持される
  • D. INSERT (...) VALUES (...) でターゲット列を省略すると、列の既定値が、無ければ NULL が挿入されるDEFAULT を明示指定して既定値に更新/挿入することもできる(DBR 11.3 LTS 以上)。INSERT * EXCEPT (col) / UPDATE SET * EXCEPT (col) で除外した列は null に設定される(スキーマ進化有効時はソース列参照&進化対象外に変わる)

Q17. PySpark で「パーティション全体を対象にした平均」をウィンドウ関数で計算したい。正しい定義はどれか。

  • A. Window.partitionBy("id").orderBy("v") とだけ書けば、フレームは自動的にパーティション全体になる
  • B. Window.partitionBy("id").rowsBetween(Window.unboundedPreceding, Window.unboundedFollowing) のようにフレームを明示する(orderBy を付けて集計する場合、フレームを省略すると既定が RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW累積計算になってしまう)
  • C. Window.partitionBy("id").rangeBetween(0, 0) と書く
  • D. PySpark ではフレームを指定できないため SQL で書く必要がある

Q18. Delta Sharing のプロバイダー側で、共有に資産を追加・維持するために必要な権限として正しいものはどれか。

  • A. 共有の作成にはメタストアに対する CREATE SHARE、資産の追加には共有の所有者であり、カタログ/スキーマに USE CATALOG / USE SCHEMA、テーブルに SELECT(ボリュームは READ VOLUME)を持つこと。共有し続けるにはこれらの権限を保持する必要がある(失うと受信者もアクセスできなくなる)。受信者の作成には CREATE RECIPIENT
  • B. 共有の作成にはワークスペース管理者権限が必要である
  • C. 一度共有に追加すれば、その後プロバイダーが権限を失っても受信者は読み続けられる
  • D. 共有への資産追加には MODIFY 権限が必要である

Q19. 液体クラスタリングのバージョン境界とプロトコルについて正しい説明はどれか。

  • A. Delta テーブルの液体クラスタリングは DBR 13.3 LTS で GA になった
  • B. 液体クラスタリング有効テーブルは、どの Delta クライアントからでも読める
  • C. Delta テーブルは DBR 15.4 LTS 以降で GA、Iceberg テーブルは DBR 16.4 LTS 以降でパブリックプレビュー。クラスタリングのトリガー(OPTIMIZE)は DBR 13.3 LTS 以降が必要で、大きなテーブルの OPTIMIZE 性能向上には DBR 17.3 LTS 以降が推奨。液体クラスタリングは Delta ライター v7 / リーダー v3 を使用し、これらをサポートしないクライアントは読めず、プロトコルのダウングレードはできない
  • D. プロトコルバージョンは後から自由にダウングレードできる

Q20. StreamingQueryProgressdurationMs に含まれる段階として正しいものはどれか。

  • A. readOffset / writeOffset / compact / vacuum
  • B. numInputRows / inputRowsPerSecond / processedRowsPerSecond
  • C. chi_squared_test / ks_test / population_stability_index
  • D. addBatch(マイクロバッチ実行。計画時間を除く)、getBatchlatestOffsetqueryPlanningtriggerExecution(計画+実行の合計)、walCommit(新オフセットのコミット)、commitOffsets。処理時間のボトルネック分析に使う

Q21. pandas UDF の「Series → Scalar」型について正しい説明はどれか。

  • A. 型ヒントは pd.Series, ... -> Any で、集計に使う(groupBy.agg / Window で使用)。部分集計に対応しておらず、各グループ全体をメモリにロードする点が制約
  • B. 型ヒントは Iterator[pd.Series] -> Iterator[pd.Series] で、状態初期化に使う
  • C. 部分集計に対応しているため、大きなグループでもメモリを消費しない
  • D. select / withColumn で使うスカラー操作用の型である

Q22. foreachBatch の実務上の注意点として正しいものはどれか。

  • A. foreachBatch に空の DataFrame が渡されることはないため、空チェックは不要である
  • B. 空の DataFrame を受け取りうる(Delta ソースの OPTIMIZE で処理対象ファイルがない、述語プッシュダウン/ファイルプルーニングで全レコード削除など)ため処理が必要。ステートフル演算子を使う場合は各バッチの DataFrame を完全に消費するshow(2) などで一部しか使わないと次バッチで失敗しうるので batch_df.foreach(do_nothing) で残りを消費)。複数シンクに書くと書き込みがシリアル化されレイテンシが増えるためシンクごとに別ライターを推奨。エラーはオーケストレーション層に再試行を委譲し、不正レコードはデッドレターキュー(DLQ) に退避する
  • C. 複数シンクへの書き込みは並列化されるため、レイテンシは改善する
  • D. コード内に複雑な再試行ループを実装するのが Databricks の推奨である

Q23. ジョブの継続的(Continuous)トリガーの既定動作として正しいものはどれか。

  • A. 複数の実行を同時に開始し、スループットを最大化する
  • B. 実行が失敗しても新しい実行は開始されず、手動介入が必要になる
  • C. 再試行は固定間隔で行われる
  • D. ①ジョブの複数同時実行を阻止する、②前の実行が失敗したら新しい実行を開始する、③再試行に指数バックオフ(exponential backoff) を使う

Q24. ABAC ポリシーの表示・説明・編集について正しい説明はどれか。

  • A. ポリシーの一覧表示には常に親カタログへの権限が必要である
  • B. CREATE OR REPLACE POLICY では変更したい句だけを指定すればよい
  • C. SHOW POLICIES ON ... でオブジェクトに定義されたポリシーを一覧でき、SHOW EFFECTIVE POLICIES は親スコープ(カタログ等)のポリシーも含む。テーブルの有効ポリシー表示に親への権限は不要(テーブル管理者が適用ルールを確認できるようにするため)。DESCRIBE POLICY ... は詳細を返し、ターゲットへの MANAGE(または所有権)が必要。SQL の CREATE OR REPLACE POLICY は全句を再指定=定義全体を置換(名前とアタッチ先は変更不可)で、Python SDK の update_policyupdate_mask による部分更新が可能
  • D. ポリシーの操作は監査ログに記録されない

Q25. サーバーレスや標準アクセスモードにおける PySpark UDF の制限として正しいものはどれか。

  • A. サーバーレスの PySpark UDF はメモリ無制限で、外部ネットワークにも自由にアクセスできる
  • B. サーバーレスの PySpark UDF はメモリ 1 GB/UDF(超過で UDF_PYSPARK_USER_CODE_ERROR.MEMORY_LIMIT_SERVERLESS)。標準アクセスモードはインスタンスの利用可能メモリに依存。標準アクセスモードクラスター・サーバーレスの PySpark UDF はブロードキャスト変数に非対応サーバーレス SQL ウェアハウスの Python UDF は既定で送信ネットワーク要求ができない(ハングする)。DBR 14.2 以下の共有クラスターの PySpark UDF は Git フォルダー / ワークスペースファイル / UC ボリュームにアクセスできない。スカラー Python UDF / pandas UDF は DBR 13.3 LTS 以降で全アクセスモード対応
  • C. ブロードキャスト変数はどのアクセスモードでも使える
  • D. DBR 12.2 LTS 以下でも UC 標準アクセスモードで Python UDF が使える

Q26. 複数バージョンのスキーマが混在するソース(旧 V1 と新 V2)を統合するパターンとして正しいものはどれか。

  • A. Python は unionByName(new_data, allowMissingColumns=True)、SQL は SELECT *, NULL as col3 FROM legacy_sourceUNION で結合し、期待値で後方互換を担保しつつ品質を適用する
  • B. スキーマが異なるソースは統合できないため、別テーブルとして保持するしかない
  • C. union()unionByName ではない)を使えば列名でマッチングされるため問題ない
  • D. MERGE WITH SCHEMA EVOLUTION は複数ソースの統合には使えない

Q27. AQE が「小さい結合テーブルをブロードキャストしなかった」理由として、公式 FAQ が挙げているものはどれか。

  • A. AQE は既定で無効なので、有効化しない限りブロードキャストは行われない
  • B. ブロードキャストしきい値が 256MB なので、それ以下のテーブルはブロードキャストされない
  • C. AQE は結合順序を動的に並べ替えるため、ブロードキャストは行わない
  • D. ①結合の種類が非対応(例: LEFT OUTER JOIN左側の関係はブロードキャストできない)、②リレーションに空のパーティションが多い場合(空でないパーティションの割合が spark.sql.adaptive.nonEmptyPartitionRatioForBroadcastJoin より低いと、AQE はソートマージ結合をブロードキャストハッシュ結合に変更することを回避する)

Q28. Unity Catalog のカタログの種類について正しい説明はどれか。

  • A. すべてのカタログは標準カタログであり、種類の区別はない
  • B. hive_metastore カタログは現行の推奨で、Unity Catalog への移行は不要である
  • C. 標準カタログ(データオブジェクト整理の主要ユニット)、外部カタログLakehouse フェデレーション専用。外部データシステムの DB をミラーし読み取り専用クエリを可能にする)がある。新規ワークスペース作成時に自動プロビジョニングされるのは hive_metastore(レガシ Hive メタストア管理データのリポジトリ。Hive メタストアは非推奨で UC への移行が推奨)とワークスペースカタログ(通常ワークスペース名を共有。自動有効化時は既定カタログに指定され既定でそのワークスペースにバインドされる)。__databricks_internal は内部状態格納用の予約カタログで照会・変更・削除してはならない(監査ログやシステムテーブルに現れることはある)
  • D. 外部カタログは書き込みも可能で、外部 DB への ETL に使える

Q29. DataFrame と Spark の実行エンジンについて正しい説明はどれか。

  • A. DataFrame は RDD(Resilient Distributed Datasets)を基盤に構築された抽象化であり、Spark DataFrames と Spark SQL は統合された計画・最適化エンジン(Catalyst) を使うため Python / SQL / Scala / R のいずれでもほぼ同じパフォーマンスが得られる。基盤の Delta Lake などは列でデータを格納するが、Spark は最適化のため行を使ってキャッシュとシャッフルを行う。.dropselect での省略は結果から除かれるだけで、データソースから列が物理的に削除されることはない
  • B. DataFrame は RDD とは無関係の独立した実装である
  • C. Scala で書いたほうが Python より常に高速になる
  • D. select で列を省略すると、データソースからその列が削除される

Q30. StreamingQueryProgressstateOperators に含まれるメトリクスとして正しいものはどれか。

  • A. numFilesOutstanding / numBytesOutstanding / approximateQueueSize
  • B. operatorNamestateStoreSave / dedupe / symmetricHashJoin 等)ごとに numRowsTotal, numRowsUpdated, numRowsRemoved, memoryUsedBytes, numRowsDroppedByWatermark(遅すぎて集計に含められなかった行=遅延データの存在を示す), numShufflePartitions, numStateStoreInstancesストリーム結合はパーティションごとに 4 インスタンス)などを持ち、customMetrics に RocksDB 等のバックエンド固有メトリクスが入る
  • C. avgOffsetsBehindLatest / maxOffsetsBehindLatest
  • D. accuracy_score / roc_auc_score / confusion_matrix

Q31. 次の CDC 入力に AUTO CDC ... STORED AS SCD TYPE 2KEYS (userId), SEQUENCE BY sequenceNum, APPLY AS DELETE WHEN operation = "DELETE")を適用したとき、userId = 125 の履歴は何行になり、__END_AT はどうなるか。

userIdcityoperationsequenceNum
125TijuanaINSERT2
125GuadalajaraUPDATE6
125MexicaliUPDATE5
  • A. 1 行(Guadalajara、__END_AT = NULL
  • B. 2 行(Tijuana 2→6、Guadalajara 6→NULL
  • C. 3 行だが、__END_AT はすべて NULL
  • D. 3 行: Tijuana(__START_AT=2, __END_AT=5)、Mexicali(5, 6)、Guadalajara(6, NULL)。シーケンス値がそのまま __START_AT / __END_AT に伝播し、順序外の seq=5 も履歴として残る

Q32. Databricks の開発言語サポートについて正しい説明はどれか。

  • A. Lakeflow パイプラインは Python / SQL / Scala / Java をサポートし、ワークフロー(ジョブ)は Python / SQL のみである
  • B. 新規プロジェクトの推奨言語は Scala と R である
  • C. 新規プロジェクトの推奨は Python と SQLScala / R はサポートが限定的で新規データエンジニアリングには非推奨(R は Databricks ノートブックでのみ完全にサポート)。言語サポートは使う機能にも依存し、Lakeflow パイプラインは Python と SQLワークフロー(ジョブ)は Python・SQL・Scala・Java をサポートする。統一エンジンのため言語間で性能はほぼ同じ
  • D. ノートブックは 1 ノートブックにつき 1 言語のみで、混在させられない

Q33. バンドルのライフサイクルと対応コマンドについて正しい説明はどれか。

  • A. 6 段階は「作成(Create)→ 開発(Develop)→ 検証(Validate)デプロイ(Deploy)実行(Run)破棄(Destroy)」。作成の 3 方法は①既定テンプレート(databricks bundle init)②カスタムテンプレート(databricks bundle init <url-or-path>)③手動作成(databricks bundle schema で JSON スキーマを生成して IDE の入力補完を使う)。ほかに bundle generate(既存リソースから構成を自動生成)、bundle deployment bind(既存リソースにリンク)がある
  • B. ライフサイクルは「作成 → デプロイ → 検証 → 開発 → 実行 → 破棄」の順である
  • C. bundle validate はデプロイ後にのみ実行できる
  • D. bundle generate はバンドルからノートブックを生成するコマンドである

Q34. ディスクキャッシュと VACUUM の相互作用について正しい説明はどれか。

  • A. VACUUM を実行するとディスクキャッシュも即座にクリアされる
  • B. ディスクキャッシュが有効な場合、クラスターに VACUUM で削除された Parquet ファイルのデータが残っていることがあるため、ファイルが削除された以前のテーブルバージョンのデータをクエリできてしまうことがある。クラスターを再起動するとキャッシュされたデータが削除される
  • C. ディスクキャッシュは VACUUM の対象なので、実行後は必ず空になる
  • D. ディスクキャッシュは _delta_log のみをキャッシュするため、VACUUM とは無関係である

Q35. マッピングテーブル(ACL)を使って行レベルセキュリティを実装するとき、次の関数と適用文の意味として正しいものはどれか。

sql
CREATE FUNCTION row_filter()
  RETURN EXISTS(SELECT 1 FROM valid_users v WHERE v.username = SESSION_USER());

CREATE TABLE data_table (x INT, y INT, z INT)
  WITH ROW FILTER row_filter ON ();
  • A. ON () は構文エラーで、必ず 1 つ以上の列を指定しなければならない
  • B. SESSION_USER() は関数の定義者を返すため、常に同じ結果になる
  • C. マッピングテーブルを使った行フィルターは Databricks では非サポートである
  • D. 引数を取らない行フィルターは ON () で列を指定せずテーブル全体に適用できる。フィルターは基本「定義者の権限(definer's rights)」で実行されるが、SESSION_USER() / IS_ACCOUNT_GROUP_MEMBER() など呼び出し元コンテキストをチェックする関数は例外的に呼び出し元として評価される。ただしパフォーマンス上は、マッピングテーブルやサブクエリより単純な CASEが推奨される

Q36. MERGE WITH SCHEMA EVOLUTIONUPDATE SET * / INSERT * の前提について正しい説明はどれか。

  • A. MERGE WITH SCHEMA EVOLUTION は DBR 11.3 LTS から使える
  • B. UPDATE SET * はソースとターゲットの列名が異なっていても位置でマッピングされる
  • C. MERGE WITH SCHEMA EVOLUTION(DBR 15.2 以上) でターゲットのスキーマをソースに合わせて自動更新できる。UPDATE SET * / INSERT * は「ソース列=ターゲット列」を前提とし、列名が異なると分析エラーになる。Delta は既定でスキーマを強制し、一致しない書き込みを拒否する
  • D. Delta は既定でスキーマ進化するため、WITH SCHEMA EVOLUTION の指定は不要である

Q37. 「3 行移動平均」を計算するウィンドウ指定として正しいものはどれか。

  • A. ROUND(AVG(salary) OVER (PARTITION BY dept ORDER BY salary ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING))(前 1 行 + 現在行 + 後 1 行)
  • B. AVG(salary) OVER (PARTITION BY dept ORDER BY salary ROWS BETWEEN 3 PRECEDING AND CURRENT ROW)
  • C. AVG(salary) OVER (PARTITION BY dept ORDER BY salary RANGE BETWEEN 1 PRECEDING AND 1 FOLLOWING)
  • D. AVG(salary) OVER (PARTITION BY dept ORDER BY salary)

Q38. Delta Sharing でデータを共有する方法として、教材が挙げている 4 つはどれか。

  • A. D2D 共有 / オープン共有 / Lakehouse フェデレーション / Databricks Marketplace
  • B. ①Databricks 間(D2D)共有プロトコル(UC 対応ワークスペース同士。組み込みサーバー利用。ノートブック/ボリューム/モデル共有、UC ガバナンス、監査、使用状況追跡など他方式にない機能)、②Databricks オープン共有プロトコル(UC 対応ワークスペースの表形式データを任意のプラットフォームの任意のユーザーと共有)、③オープンソース Delta Sharing サーバーの自己実装、④SAP Business Data Cloud (BDC) コネクタ。なお同一アカウント内の UC メタストア間の D2D 共有は常に有効(メタストアで Delta Sharing を有効化する必要すらない)
  • C. D2D 共有 / オープン共有 / クリーンルーム / Delta Live Tables
  • D. トークン共有 / OIDC 共有 / 署名付き URL 共有 / ディレクトリベース共有

Q39. Delta テーブルをストリーミングソースにするときの開始位置とレート制限について正しい説明はどれか。

  • A. startingVersionstartingTimestamp は同時に指定できる
  • B. ストリーミングソースのスキーマは開始バージョン時点のスキーマが使われる
  • C. maxFilesPerTrigger の既定は 100 である
  • D. startingVersion(Delta のバージョン。latest で最新のみ)/startingTimestamp で開始位置を指定でき、両者の同時指定は不可ストリーミングソースのスキーマは常に最新スキーマ。レート制限は maxFilesPerTrigger(既定 1000)maxBytesPerTrigger(ソフト上限、未設定が既定) で、両方指定時はどちらかの上限到達までを 1 バッチとする

Q40. 通知先(Notification destinations)について正しい説明はどれか。

  • A. 通知先は各ユーザーが自分で作成し、他ユーザーとは共有されない
  • B. Slack や Microsoft Teams のメッセージスキーマは固定されているため、それに依存した処理を作ってよい
  • C. 管理にはワークスペース管理者である必要があり、構成すると全ユーザーが利用可能になる。サポートされる宛先は Email / Slack / Webhook / Microsoft Teams / PagerDuty。宛先構成は暗号化保存され、宛先ごとに異なる資格情報を推奨(侵害時に個別失効できる)。HTTPS 必須でコントロールプレーンとデータプレーンの送信 IP を許可リストに追加する(送信 IP は 30 日に 1 回更新され得る)。Slack / Teams のメッセージ内容・書式は将来変更され得るため特定スキーマに依存する処理を作らない(厳密なスキーマが必要ならユーザー定義 Webhook)。通知先を構成できるのは Databricks SQL とジョブのみ
  • D. 通知先はパイプラインとモデルサービングにも構成できる

Q41. インスタンスファミリとワークロードの対応として正しいものはどれか。

  • A. メモリ最適化=ストリーミング / コンピュート最適化=ML / ストレージ最適化=メンテナンス
  • B. メモリ最適化=シャッフル/スピルが多い ML、コンピュート最適化=ストリーミング、メンテナンスジョブ(OPTIMIZE / VACUUM)、ストレージ最適化=キャッシュの恩恵が大きいアドホック/対話型分析(ローカル SSD)、GPU 最適化=特定の ML / DL、汎用=特定要件がない場合
  • C. すべてのワークロードで汎用インスタンスを使うのが推奨である
  • D. OPTIMIZE はメモリ集約なのでメモリ最適化インスタンスが推奨される

Q42. JSON / 半構造化データを扱う関数について正しい説明はどれか。

  • A. from_json(col, schema) で JSON 文字列を struct に、to_json(col) で struct を JSON 文字列に変換する。get_json_object / json_tuple で JSON 文字列から値を抽出できる。Databricks には半構造化データ用の VARIANT 型もあり、UDF から VariantVal.parseJson(...) で生成できる
  • B. from_json は struct を JSON 文字列に変換する関数である
  • C. JSON 文字列から値を抽出する関数は存在せず、必ず from_json で struct 化する必要がある
  • D. VARIANT 型は UDF からは生成できない

Q43. データリネージの確認方法と要件について正しい説明はどれか。

  • A. 確認方法は Catalog Explorer のみで、プログラム的なアクセス手段はない
  • B. 系列キャプチャにはテーブルが Hive メタストアに登録されていれば十分である
  • C. Lakeflow パイプラインの系列表示には所有権が必要である
  • D. 確認方法は 3 つ: ①Catalog Explorer(テーブルの[系列]タブ →[系列グラフの表示]。既定 1 レベル表示、列をクリックで列レベル系列)、②Genie Code/getTableLineages / /getTableInsights)、③システムテーブルsystem.access.table_lineage / system.access.column_lineage)。キャプチャ要件はテーブルが Unity Catalog メタストアに登録され、クエリが Spark DataFrame または Databricks SQL インターフェイスを使うこと。表示要件は親カタログへの最低 BROWSE、ノートブック/ジョブ/ダッシュボードは各オブジェクトへの権限、UC 対応パイプラインは CAN VIEW

Q44. バンドルの presets について正しい説明はどれか。

  • A. presetsmode より優先度が低いため、mode の既定動作を上書きできない
  • B. presets で指定できるのはタグのみである
  • C. modepresets を併用すると、プリセットが既定モード動作を上書きし、個別リソース設定がプリセットを上書きする(優先順位: 個別リソース > presets > mode)。指定できる項目には name_prefixpipelines_developmenttrigger_pause_statusjobs_max_concurrent_runstags などがある
  • D. presetsmode は同時に指定できない

Q45. 期待値(Expectations)のメトリックが得られないケースとして、教材が挙げているものはどれか。

  • A. 期待値が定義されていれば、どのような状況でも必ずメトリックが取得できる
  • B. ①期待値が未定義、②期待値非対応の演算子/フロー種別(例: シンク)、③当該実行で対象テーブルへの更新がない、④pipelines.metrics.flowTimeReporter.enabled 等の設定不足、⑤ビューは実行時のみ計算されるため取得できない/複数セットになる場合がある。また期待値は AUTO CDC FROM SNAPSHOT では非対応fail はメトリックが記録されない
  • C. シンク(sink)でも期待値とメトリックが完全にサポートされる
  • D. ビューでは常に安定してメトリックが取得できる

Q46. pandas UDF の Arrow バッチサイズとタイムゾーンについて正しい説明はどれか。

  • A. Arrow バッチサイズは spark.sql.execution.arrow.maxRecordsPerBatch(既定 1 万レコード/バッチ)で調整でき、列数が多い場合は下げる。ただしサーバーレスや DBR 13.3〜14.2 の標準アクセスモードでは無効(プラットフォームが内部管理)。タイムゾーンは Spark が内部で UTC 保持、pandas は datetime64[ns] で、toPandas() や pandas UDF で自動変換される
  • B. Arrow バッチサイズの既定は 100 万レコード/バッチである
  • C. 列数が多い場合はバッチサイズを上げるべきである
  • D. Spark は内部でローカルタイムゾーンを保持する

Q47. ネストした STRUCT フィールドを選択的にマスクする関数として正しいものはどれか。

  • A. ネストした STRUCT のフィールドは個別にマスクできない
  • B. CASE WHEN ... THEN data.secret ELSE 'REDACTED' END のように、STRUCT のフィールドを直接返す
  • C. named_struct() で STRUCT を再構築して返す。戻り値の型は元の STRUCT と一致させる必要がある。例:
    sql
    CREATE FUNCTION mask_nested_field(data STRUCT<value: STRING, secret: STRING>)
    RETURN IF(is_account_group_member('privileged_users'), data,
              named_struct('value', data.value, 'secret', 'REDACTED'));
  • D. STRUCT 列にマスクを適用するには、事前にフラット化しておく必要がある

Q48. コスト最適化の「リソースを動的に割り当てる」原則に含まれる施策として正しいものはどれか。

  • A. Delta Lake を使う・ジョブコンピュートを使う・最新の DBR を使う
  • B. タグ付けによるコスト配分・予算とアラート・システムテーブルでの監視
  • C. 常時稼働 vs トリガーストリーミングのバランス・オンデマンド vs スポットのバランス
  • D. 自動スケーリング(ジョブ特性に応じワーカーを動的増減。静的サイズよりコスト削減。ストリーミングは縮小に制限があるため Lakeflow パイプラインの強化自動スケーリングを推奨)、自動終了(対話型コンピュートに設定。営業時間限定なら自動終了+スケジュール起動/事前ウォーミング)、クラスタープール(起動/自動スケール時間を短縮。プール内でアイドル中は DBU 課金なし)、コンピュートポリシー(最小ワーカー数付き自動スケール、妥当な自動終了、コスト効率の良い VM のみ許可、スポット戦略の強制)

Q49. SQL アラートの通知テンプレートと詳細設定について正しい説明はどれか。

  • A. 通知テンプレートはカスタマイズできず、既定の文面のみが使われる
  • B. 標準エディターでは {{VARIABLE_NAME}} で変数を参照する(ALERT_STATUS, ALERT_CONDITION, ALERT_THRESHOLD, ALERT_COLUMN, ALERT_NAME, ALERT_URL, QUERY_RESULT_TABLE(先頭 100 行の HTML テーブル。HTML 表示は Email 宛先のみ), QUERY_RESULT_VALUE, QUERY_RESULT_ROWS, QUERY_RESULT_COLS)。Markdown エディターでは @VARIABLE_NAME で参照する。詳細設定にはOK 時に通知(Notify on OK)空の結果状態テンプレートがある
  • C. 変数参照は Markdown エディターでも {{VARIABLE_NAME}} である
  • D. QUERY_RESULT_TABLE は全行を HTML で表示し、Slack でもレンダリングされる

Q50. SQL で UDTF(テーブルを返す関数)を定義する構文として正しいものはどれか。

  • A. RETURNS TABLE (...)LANGUAGE PYTHONHANDLER '<クラス名>' を使い、ハンドラークラスの eval メソッドで yield する。例:
    sql
    CREATE OR REPLACE FUNCTION get_sum_diff(x INT, y INT)
    RETURNS TABLE (sum INT, diff INT)
    LANGUAGE PYTHON
    HANDLER 'GetSumDiff'
    AS $$
    class GetSumDiff:
        def eval(self, x: int, y: int):
            yield x + y, x - y
    $$;
    SELECT * FROM get_sum_diff(10, 3);   -- sum=13, diff=7
  • B. RETURNS INT を指定し、RETURN で複数値をカンマ区切りで返す
  • C. PARAMETER STYLE PANDAS を指定する必要がある
  • D. SQL では UDTF を定義できず、PySpark の @udtf のみが使える

Q51. APPLY AS TRUNCATE WHEN の挙動と、バイテンポラル追跡について正しい説明はどれか。

  • A. APPLY AS TRUNCATE WHEN は条件に一致する行のみを削除する
  • B. APPLY AS TRUNCATE WHEN は SCD Type 2 専用の機能である
  • C. APPLY AS TRUNCATE WHEN / apply_as_truncates(任意)は、そのシーケンス時点でテーブルをクリアする(Type 1 系の全消去)。公式例では sequenceNum=3TRUNCATE を有効にすると、それ以前に取り込まれたレコードが消え、最終的に後続の更新のみが残る。バイテンポラル追跡(ベータ、AUTO CDC のみ) は「業務時間」と「システム時間」の 2 軸を追跡し、STORED AS BITEMPORAL(SQL)/stored_as_scd_type="bitemporal"(Python)、業務時間に SEQUENCE BY、システム時間に SYSTEM SEQUENCE BY を指定して __SYSTEM_START_AT / __SYSTEM_END_AT を追加し、順序外イベントが来ると末尾追加ではなく影響を受ける履歴を修正する
  • D. バイテンポラル追跡は AUTO CDC FROM SNAPSHOT でのみ利用できる

Q52. Git フォルダーの運用上の注意点として正しいものはどれか。

  • A. ブランチを切り替えてもワークスペース資産が消えることはない
  • B. アップストリームの変更をプルしてもノートブックの状態は保持される
  • C. ソースファイル形式(.py 等)ではノートブックの出力が既定でコミットに含まれる
  • D. ブランチ切り替えで、新しいブランチにその資産が無い場合はワークスペース資産が削除されることがある(元のブランチに戻すと新しい ID / URL で再作成され、取り消せない)。アップストリームの変更をプルするとノートブックの状態がリセットされる。ソースファイル形式(.py, .scala, .sql, .r)は既定でノートブック出力をコミットに含めない(IPYNB 形式なら出力コミットを制御可能)。コラボレーションでは各メンバーが自分の Git フォルダーを持ち、1 つの Git フォルダーで Git 操作するのは 1 人だけにする

Q53. 型不一致(type mismatch)のクレンジングを Expectations で行う方法として正しいものはどれか。

  • A. 期待値の制約内で SQL 関数を使って検証する(例: year(transaction_date) >= 2020、日付キャスト to_date(updateTime,'M/d/yyyy h:m:s a') > '2010-01-01')。CASEで型・状態に応じた条件分岐検証も可能(例: WHEN type = 'ORDER' THEN status IN (...) WHEN type = 'REFUND' THEN status IN (...) ELSE false END)。複合ブールAND / OR)も使える
  • B. 期待値の制約では SQL 関数を使えないため、型変換は別ステップで行う必要がある
  • C. 型検証にはカスタム Python 関数を制約内で呼び出すのが推奨である
  • D. CASE 式は制約句では使えない

Q54. ストリーム間結合とウィンドウの種類について正しい説明はどれか。

  • A. ストリーム間結合は update モードでも使える
  • B. ストリーム間結合は追加(append)モードのみサポート。内部結合は各ソースにウォーターマークを推奨(無いと毎トリガーで両側の全キー結合を試み性能が悪化)、外部結合はウォーターマーク必須(不一致は null 行で、遅延しきい値到達まで書かれない)。ウィンドウはタンブリング(重複しない固定サイズ。各行は 1 ウィンドウ)/スライディング(重複可能な固定サイズ。1 行が複数ウィンドウに属す。slideDuration <= windowDuration)/セッション(可変サイズ。行到着で開き、ギャップ期間の無入力で閉じる。TimestampType / TimestampNTZType が必要。月以上の期間は非サポート)
  • C. 外部結合ではウォーターマークを付けてはいけない
  • D. セッションウィンドウは固定サイズで、重複しない

Q55. 分離レベルの変更と Bloom フィルターインデックスについて正しい説明はどれか。

  • A. 既定は「シリアル化可能(serializable)」で、「書き込みシリアル化可能」に変更するとスループットが上がる
  • B. Bloom フィルターインデックスは現在も推奨されており、高カーディナリティ列のフィルターに使うべきである
  • C. 既定は「書き込みシリアル化可能(write serializable)」で、「シリアル化可能(serializable)」に変更すると読み取りシリアル化が保証される代わりに、同時実行操作のスループットが低下しうるBloom フィルターインデックスは非推奨で、代わりに予測 I/O(predictive I/O) または液体クラスタリングを使う。なお範囲結合の最適化は桁違いの高速化が可能だが手動チューニングが必要
  • D. 分離レベルは変更できない

Q56. Unity Catalog のアイデンティティ設計(プリンシパル)について、教材のベストプラクティスとして正しいものはどれか。

  • A. ワークスペースレベルの SCIM を使い、ワークスペースごとに ID を管理する
  • B. 権限と所有権はユーザー個人に割り当てるのが望ましい
  • C. 運用ジョブは人間のユーザー ID で実行するのが望ましい
  • D. 特権はアカウントレベルで定義したプリンシパルに割り当て、SCIM で IdP からアカウントへプロビジョニングするのが推奨。ワークスペースレベルの SCIM は避けアカウントレベルで一元管理する。グループは IdP で定義・管理し、ユーザー個人ではなくグループに権限・所有権を割り当てるサービスプリンシパルでジョブを実行する(ユーザーで運用書き込みを実行すると誤上書きリスクがある)

Q57. system.billing.usagesystem.billing.list_prices を結合して USD コストを算出するとき、正しい結合条件はどれか。

  • A. sku_name で結合し、さらに p.price_start_time <= u.usage_start_time かつ (p.price_end_time >= u.usage_start_time OR p.price_end_time IS NULL) かつ p.currency_code = 'USD' を条件に加える(list_prices は価格変更ごとに行が追加される履歴ログなので、使用時点で有効だった価格を選ぶ必要がある)
  • B. sku_name だけで結合すれば十分である
  • C. usage_dateprice_start_time を等値で結合する
  • D. list_prices は単一の現行価格のみを持つため、期間条件は不要である

Q58. ALTER SHARE ... ADD TABLE / ADD SCHEMA の指定について正しい説明はどれか。

  • A. スキーマ全体を共有に追加するとき、PARTITIONAS(エイリアス)を指定できる
  • B. パーティション指定による部分共有はできない
  • C. テーブル追加時には PARTITION(<clause>)(例: PARTITION (year = "2021"), (year = "2020", month = "Dec"))や AS <alias>WITH HISTORY | WITHOUT HISTORY を指定できる。受信者プロパティで動的にフィルターする PARTITION (country = CURRENT_RECIPIENT().country) も使える(マルチテナント共有)。一方スキーマ全体の追加(ADD SCHEMA、DBR 13.3 LTS 以降)では PARTITION / AS は使用不可で、スキーマ共有は常に WITH HISTORY
  • D. WITH HISTORY はスキーマ共有では指定できず、テーブル共有でのみ有効である

Q59. 行フィルター/列マスクのパフォーマンス推奨として、教材が挙げているものはどれか。

  • A. マッピングテーブルやサブクエリを使うほうが CASE 式より高速である
  • B. 単純な UDF を使う(マッピングテーブル・サブクエリより単純な CASE 式)。大きなテーブルでの個別の列マスク数を制限する(各マスクがクエリ中に評価されるため、真に機密な列だけに適用し関数を再利用)。UDF 引数の数を減らす(引数由来の列参照はクエリで未使用でも最適化できない)。AND 結合が多すぎる行フィルターを避けるエラーを送出しない決定的な式を使う(ANSI 除算のようにエラーになるとフィルター/マスク前の値情報が漏れるため SQL コンパイラが操作をプッシュダウンできない。try_divide などを使う)。Python UDF より SQL を優先する
  • C. UDF の引数は多いほうが最適化が効く
  • D. エラーを送出する式のほうがプッシュダウンされやすい

解答一覧(自己採点用)

Q正解ドメインQ正解ドメインQ正解ドメイン
1C① コード21A① コード41B② 最適化
2A⑤ セキュリティ22B⑦ インジェスト42A① コード
3B② 最適化23D⑥ デバッグ43D⑧ ガバナンス
4D⑦ インジェスト24C⑤ セキュリティ44C⑥ デバッグ
5A① コード25B① コード45B③ 品質
6C④ 監視26A③ 品質46A① コード
7B③ 品質27D② 最適化47C⑤ セキュリティ
8D⑥ デバッグ28C⑧ ガバナンス48D② 最適化
9A① コード29A① コード49B④ 監視
10B⑧ ガバナンス30B④ 監視50A① コード
11D② 最適化31D⑨ モデリング51C⑨ モデリング
12C⑨ モデリング32C① コード52D⑥ デバッグ
13A① コード33A⑥ デバッグ53A③ 品質
14B⑤ セキュリティ34B② 最適化54B⑦ インジェスト
15C⑥ デバッグ35D⑤ セキュリティ55C② 最適化
16D③ 品質36C③ 品質56D⑧ ガバナンス
17B① コード37A① コード57A④ 監視
18A⑩ 共有38B⑩ 共有58C⑩ 共有
19C② 最適化39D⑦ インジェスト59B⑤ セキュリティ
20D④ 監視40C④ 監視

採点表(弱点ドメインを特定する)

自分の正答数を書き込んでください。目標は各ドメイン 70% 以上です。

ドメイン配点該当問題満点目標自分の正答数弱点だった場合に戻る先
① Python/SQL コード開発22%1, 5, 9, 13, 17, 21, 25, 29, 32, 37, 42, 46, 501310/13教材確認問題課題 1〜4
② コスト・パフォーマンス最適化13%3, 11, 19, 27, 34, 41, 48, 5586/8教材確認問題課題 5〜6
③ データ変換・品質10%7, 16, 26, 36, 45, 5365/6教材確認問題課題 7〜8
④ モニタリング・アラート10%6, 20, 30, 40, 49, 5765/6教材確認問題課題 9〜10
⑤ セキュリティ・コンプライアンス10%2, 14, 24, 35, 47, 5965/6教材確認問題課題 11
⑥ デバッグ・デプロイ10%8, 15, 23, 33, 44, 5265/6教材確認問題課題 12〜13
⑦ データインジェスト7%4, 22, 39, 5443/4教材確認問題課題 12〜13
⑧ データガバナンス7%10, 28, 43, 5643/4教材確認問題課題 14
⑨ データモデリング6%12, 31, 5132/3教材確認問題課題 15
⑩ データ共有・フェデレーション5%18, 38, 5832/3教材確認問題Free Edition では実機練習不可 → 座学で固める
合計100%5942/59

判定の目安

合計正答数判定次にやること
54〜59(91%〜)合格圏。仕上げ段階用語対訳集数値チートシートで最終確認して受験
47〜53(80〜89%)ほぼ合格圏弱点ドメインの確認問題を周回。①(22%)を落としていないかを最優先で確認
42〜46(71〜78%)ぎりぎり合格圏弱点ドメインの教材を読み直し → ハンズオン課題 → 確認問題の順で戻る
41 以下(〜69%)対策不足①(22%)と②(13%)で合計 35% を占めるので、まずこの 2 ドメインを固める

時間もチェックする

所要時間評価
〜100 分余裕あり。見直し時間も確保できる
100〜120 分適正。本番は問題文がさらに長いので油断しない
120 分超(解き切れなかった)時間対策が必要。ロードマップの「問われている核心を 1 文で要約 → 消去法 → 迷ったらフラグ」を訓練する。通し練習を最低 2 回やる

解説

Q1. 正解: C — Alex と Bob が同じ 30000(2 位タイ)。ROW_NUMBER はタイでも連番(1,2,3,4)、RANK はタイの数だけ飛ぶ(1,2,2,4)、DENSE_RANK は飛ばない(1,2,2,3)。→ 教材 3-3

Q2. 正解: A — 関数への EXECUTEUSE SCHEMAUSE CATALOG。新規テーブル作成時は CREATE TABLE、既存テーブルでの追加・削除はテーブル所有者または MANAGESELECT の両方、スキーマも同時変更するなら MODIFY。→ 教材 3-2

Q3. 正解: B — ビンパッキングはべき等でサイズ的に均等化。読み手はスナップショット分離で中断されず、データを変更しないので前後で結果は同じ。ストリーミングソースにも影響しない。→ 教材 3-2

Q4. 正解: D — SQL での増分取り込みは COPY INTO ではなく CREATE STREAMING TABLEread_files)が推奨。Auto Loader のサポート形式は 8 種(JSON, CSV, XML, PARQUET, AVRO, ORC, TEXT, BINARYFILE)。→ 教材 3-1・3-2

Q5. 正解: A — DataFrame は不変で、変換は元を変更せず新しい DataFrame を返す。後続でアクセスするには変数に保存する必要がある。→ 教材 3-1

Q6. 正解: C — 新しい列がいつでも追加され得るため別テーブルへ書き出すならスキーマ進化を有効化。選択性の低いクエリは専用エラーで失敗する。非推奨スキーマは system.operational_datasystem.lineage。→ 教材 3-1

Q7. 正解: B — ルールを Delta テーブルや Python モジュールに外部化し、タグでフィルターして辞書として適用する(可搬性・再利用・監査)。SQL ではファイルからの動的読み込みは非対応。→ 教材 4-2

Q8. 正解: D — 失敗は赤、ギャップは1 分以上を探す、長いジョブは深掘り、小さな青い線が大量なら「多数の小さなジョブ」、該当なしなら Duration でソート。タスク 1 つは問題のサイン。→ 教材 3-1

Q9. 正解: Aexplode は空/NULL で行が消え、explode_outer は NULL 行を保持、posexplode は位置も返し、inline は構造体配列を複数列に展開する。→ 教材 3-4

Q10. 正解: B — 3 原則は「データと AI 管理の統合」「データと AI セキュリティの統合(誰がアクセスできるか+誰が最近アクセスしたか)」「データ品質基準の確立」。→ 教材 3-1

Q11. 正解: D — アカウント / カタログ / スキーマ / テーブルの粒度で継承モデル(ENABLE | DISABLE | INHERIT)に従う。明示的に無効化したオブジェクトはアカウントレベルで有効化してもブロックされたまま。→ 教材 3-2

Q12. 正解: C — AUTO CDC ターゲットは実行中でも DML 可、CDF を出力でき、num_upserted_rows / num_deleted_rows を自動キャプチャ。Pro / Advanced(またはサーバーレス)が必要で Apache Spark 宣言パイプラインでは非サポート。→ 教材 3-2

Q13. 正解: A — UC 管理は共有・永続化・ガバナンス向けで Java も対応。セッションスコープは反復開発向けで SQL/Python/Scala、現在の SparkSession 限定。UDAF はセッションスコープ限定(D が誤り)。→ 教材 3-5

Q14. 正解: BREPLACE TABLE でも行フィルターは保持され、同名列があれば列マスクも保持される(誤消去防止)。ただし削除/変更された列を参照するポリシーは後続クエリを失敗させ得る。→ 教材 3-2

Q15. 正解: C — 複数タスクはジョブ再試行前にすべてのタスクが失敗、複数クエリはクエリが失敗するとそのタスクが再試行。継続的トリガーではタスク間の依存関係を設定できない。→ 教材 3-2

Q16. 正解: D — 列を省略すると既定値、なければ NULLDEFAULT を明示指定も可能。EXCEPT で除外した列は null に設定される(元の値の保持ではない)。→ 教材 3-3・3-4

Q17. 正解: BrowsBetween(Window.unboundedPreceding, Window.unboundedFollowing) でフレームを明示する。orderBy を付けて省略すると既定が累積計算になる。→ 教材 3-3

Q18. 正解: ACREATE SHARE(メタストア)、資産追加は共有所有者+USE CATALOG/USE SCHEMASELECT(ボリュームは READ VOLUME)。共有し続けるにはこれらの権限を保持する必要がある。受信者作成は CREATE RECIPIENT。→ 教材 3-2

Q19. 正解: C — Delta は DBR 15.4 LTS で GA、Iceberg は 16.4 LTS でプレビュー。クラスタリングのトリガーは 13.3 LTS 以降。ライター v7 / リーダー v3 でダウングレード不可。→ 教材 3-2数値チートシート §16

Q20. 正解: DdurationMs の主な段階は addBatch / getBatch / latestOffset / queryPlanning / triggerExecution / walCommit / commitOffsets。B はレート系メトリクス、C はドリフト指標。→ 教材 3-3

Q21. 正解: A — 「Series → Scalar」は pd.Series, ... -> Any で集計用。部分集計非対応で各グループ全体をメモリにロードする点が制約。→ 教材 3-5

Q22. 正解: B — 空 DataFrame は渡されうる、ステートフル時はバッチを完全消費、複数シンクはシリアル化されるのでシンクごとに別ライター、エラーはオーケストレーション層に委譲し不正レコードは DLQ へ。→ 教材 3-4

Q23. 正解: D — 継続的トリガーは①複数同時実行を阻止②失敗時に新実行を開始③指数バックオフで再試行。→ 教材 3-2

Q24. 正解: CSHOW POLICIES / SHOW EFFECTIVE POLICIESテーブルの有効ポリシー表示に親への権限は不要)/ DESCRIBE POLICYMANAGE 必要)。SQL の CREATE OR REPLACE POLICY定義全体を置換。ポリシー操作は system.access.audit に記録される(D が誤り)。→ 教材 3-4

Q25. 正解: B — サーバーレスは 1 GB/UDF、ブロードキャスト変数は標準アクセスモード/サーバーレスで非対応、サーバーレス SQL ウェアハウスの Python UDF は送信ネットワーク不可、DBR 14.2 以下の共有クラスターはファイルアクセス不可。→ 教材 3-5

Q26. 正解: A — Python は unionByName(..., allowMissingColumns=True)、SQL は SELECT *, NULL as col3UNION。期待値で後方互換を担保する。→ 教材 3-3

Q27. 正解: D — 結合種別が非対応(LEFT OUTER JOIN の左側はブロードキャスト不可)か、空パーティションが多い(nonEmptyPartitionRatioForBroadcastJoin 未満)。しきい値は 30MB(B が誤り)で AQE は既定有効(A が誤り)、結合順序は変えない(C が誤り)。→ 教材 3-3

Q28. 正解: C — 標準カタログ / 外部カタログ(Lakehouse フェデレーション専用・読み取り専用)、自動プロビジョニングされる hive_metastore非推奨)とワークスペースカタログ(既定カタログ)、予約カタログ __databricks_internal触ってはならない)。→ 教材 3-2

Q29. 正解: A — DataFrame は RDD 上の抽象化で、統一エンジン(Catalyst)により言語間で性能差がほぼない。Spark は最適化のためでキャッシュとシャッフルを行い、select での省略はデータソースから列を物理削除しない。→ 教材 3-1

Q30. 正解: BstateOperatorsoperatorName ごとの状態メトリクス。numRowsDroppedByWatermark(遅延データの存在)とストリーム結合はパーティションごとに 4 インスタンスが要注意ポイント。A はバックログ、C は Kafka の遅れ、D はモデル精度。→ 教材 3-3

Q31. 正解: D — SCD Type 2 は全履歴を残すため 3 行。シーケンス値が __START_AT / __END_AT に伝播し、順序外の seq=5(Mexicali)も 5→6 のバージョンとして残る。アクティブ行は __END_AT = NULL。→ 教材 3-3

Q32. 正解: C — 新規推奨は Python と SQL、R はノートブックのみ完全サポート。Lakeflow パイプラインは Python/SQL、ワークフロー(ジョブ)は Python/SQL/Scala/Java(A は逆)。ノートブックは複数言語混在可(D が誤り)。→ 教材 3-1

Q33. 正解: A — 6 段階は作成 → 開発 → 検証デプロイ実行破棄。作成は既定テンプレート / カスタムテンプレート / 手動(bundle schema)の 3 方法。→ 教材 3-3

Q34. 正解: B — ディスクキャッシュに VACUUM で削除された Parquet が残り、削除済みバージョンをクエリできてしまうことがある。クラスター再起動でキャッシュが消える。→ 教材 3-2

Q35. 正解: D — 引数なしの行フィルターは ON () で全体に適用できる。フィルターは定義者権限で実行されるが、SESSION_USER() / IS_ACCOUNT_GROUP_MEMBER()呼び出し元コンテキストで評価される。ただし性能上は単純な CASE 式が推奨。→ 教材 4-2

Q36. 正解: CMERGE WITH SCHEMA EVOLUTIONDBR 15.2 以上(A が誤り)。UPDATE SET * / INSERT *列名一致が前提で、異なると分析エラー(B が誤り)。Delta は既定でスキーマを強制する(D が誤り)。→ 教材 3-3・3-4

Q37. 正解: A — 3 行移動平均は ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING(前 1 + 現在 + 後 1)。B は 4 行分、C は値ベースなので行数が変動、D は既定フレームで累積和になる。→ 教材 3-3

Q38. 正解: B — ①D2D 共有 ②Databricks オープン共有 ③OSS Delta Sharing サーバーの自己実装 ④SAP BDC コネクタ。同一アカウント内の UC メタストア間の D2D は常に有効。→ 教材 3-1

Q39. 正解: DstartingVersion / startingTimestamp同時指定不可、スキーマは常に最新maxFilesPerTrigger の既定は 1000maxBytesPerTrigger はソフト上限。→ 教材 3-4

Q40. 正解: C — 管理はワークスペース管理者、宛先は Email/Slack/Webhook/Teams/PagerDuty、HTTPS 必須、Slack/Teams はスキーマが変わり得るので依存しない(厳密なスキーマが必要なら Webhook)、構成できるのは SQL とジョブのみ(D が誤り)。→ 教材 3-4

Q41. 正解: B — メモリ最適化=ML(シャッフル/スピル多)、コンピュート最適化=ストリーミング・メンテナンス(OPTIMIZE/VACUUMCPU 集約なので D が誤り)、ストレージ最適化=キャッシュが効くアドホック、GPU=DL、汎用=一般。→ 教材 3-4・3-5

Q42. 正解: Afrom_json は JSON 文字列 → struct、to_json は struct → JSON 文字列。get_json_object / json_tuple で値を抽出でき、VARIANT 型は UDF から VariantVal.parseJson(...) で生成できる。→ 教材 3-4

Q43. 正解: D — 3 つの確認方法(Catalog Explorer / Genie Code / システムテーブル)。キャプチャ要件は UC 登録(Hive では不可)と Spark DataFrame / Databricks SQL の使用。表示は最低 BROWSE、UC 対応パイプラインは CAN VIEW。→ 教材 3-3

Q44. 正解: C — 優先順位は個別リソース > presets > modename_prefix / pipelines_development / trigger_pause_status / jobs_max_concurrent_runs / tags などを指定できる。→ 教材 3-3

Q45. 正解: B — メトリックが得られないのは、未定義/非対応の演算子・フロー種別(シンク)/対象テーブルへの更新がない/設定不足/ビュー(実行時のみ計算)のケース。AUTO CDC FROM SNAPSHOT は期待値非対応、fail はメトリック記録なし。→ 教材 3-2

Q46. 正解: AmaxRecordsPerBatch は既定 1 万レコード/バッチで、列数が多い場合は下げる。サーバーレスや DBR 13.3〜14.2 標準アクセスモードでは無効。Spark は内部で UTC 保持。→ 教材 3-5

Q47. 正解: Cnamed_struct() で STRUCT を再構築し、元の STRUCT と型を一致させる。列マスクの戻り値型は列型と一致/キャスト可能である必要があるため。→ 教材 4-2

Q48. 正解: D — 「リソースを動的に割り当てる」は自動スケーリング・自動終了・クラスタープール・コンピュートポリシー。A は「最適なリソースを選択する」、B は「コストの監視と制御」、C は「コスト効率の高いワークロードを設計する」の施策。→ 教材 3-5

Q49. 正解: B — 標準エディターは {{VARIABLE_NAME}}Markdown エディターは @VARIABLE_NAME(C が誤り)。QUERY_RESULT_TABLE先頭 100 行で HTML 表示は Email 宛先のみ(D が誤り)。→ 教材 3-4

Q50. 正解: A — SQL の UDTF は RETURNS TABLE (...)LANGUAGE PYTHONHANDLER 'クラス名' で、evalyield する。PARAMETER STYLE PANDAS はバッチ UC Python UDF の構文(C が誤り)。→ 教材 3-5

Q51. 正解: CAPPLY AS TRUNCATE WHENそのシーケンス時点でテーブルをクリアする(条件に一致する行のみの削除は APPLY AS DELETE WHEN)。バイテンポラルは AUTO CDC のみで、SYSTEM SEQUENCE BY__SYSTEM_START_AT / __SYSTEM_END_AT を使い、順序外イベントで影響を受ける履歴を修正する。→ 教材 3-2・3-3

Q52. 正解: D — ブランチ切り替えで資産が消えることがある(元に戻すと新 ID / URL で再作成、取り消し不可)、プルでノートブック状態がリセット、ソース形式は既定で出力を含めない、1 Git フォルダーで操作するのは 1 人だけ。→ 教材 3-4

Q53. 正解: A — 制約句では SQL 関数・CASE 式・複合ブールが使える(使えないのはカスタム Python 関数・外部呼び出し・他テーブル参照サブクエリ)。→ 教材 3-3・4-1

Q54. 正解: B — ストリーム間結合はappend のみ、外部結合はウォーターマーク必須。ウィンドウはタンブリング(重複なし)/スライディング(重複可)/セッション(可変サイズ、ギャップで閉じる)。→ 教材 3-4

Q55. 正解: C — 既定は書き込みシリアル化可能で、シリアル化可能に上げると読み取りシリアル化が保証される代わりにスループットが低下しうる。Bloom フィルターは非推奨(→ 予測 I/O または液体クラスタリング)。範囲結合の最適化は手動チューニングが必要。→ 教材 3-1

Q56. 正解: DSCIM はアカウントレベルで一元管理(ワークスペースレベルの SCIM は避ける)、グループは IdP で管理し個人ではなくグループに権限・所有権を割り当て、ジョブはサービスプリンシパルで実行する。→ 教材 3-2

Q57. 正解: Alist_prices は価格変更ごとに行が増える履歴ログなので、sku_name に加えて price_start_time <= usage_start_time(price_end_time >= usage_start_time OR price_end_time IS NULL)currency_code = 'USD'使用時点で有効だった価格を選ぶ。→ 教材 4-2

Q58. 正解: C — テーブル追加時は PARTITION / AS / WITH HISTORY | WITHOUT HISTORY が使え、CURRENT_RECIPIENT() による動的パーティションフィルターも可能。ADD SCHEMA(DBR 13.3 LTS 以降)では PARTITION / AS は使用不可で常に WITH HISTORY。→ 教材 4

Q59. 正解: B — 単純な CASE 式、個別マスク数の制限、引数の削減、AND 結合を減らす、エラーを送出しない決定的な式try_divide。エラーは値情報の漏えいにつながりプッシュダウンを妨げる)、Python UDF より SQL を優先。→ 教材 3-2


次にやること

リソース用途
../07_reference/glossary.md英日用語対訳集(用語は英語で覚える
../07_reference/cheatsheet-numbers.md数値・DBR バージョン境界の直前 1 枚
../05_practice-questions/professional/ドメイン別確認問題(各10問・計100問)
../06_hands-on/handson-professional.mdFree Edition で手を動かす 15 課題
mock-associate.mdAssociate の模擬試験