資格道場
Google CloudLevel 4

難易度は Level 1（やさしめ）〜Level 5（難関） の5段階です。

GCP PDEのサンプル問題（本番形式・解説付き）

GCP PDE（Google Cloud・Professional Data Engineer（PDE））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試 第1回（50問）の冒頭から抜粋したオリジナル問題です。当サイトは全621問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

小売企業のデータ基盤チームが、いくつかの API を順番に呼ぶだけの軽い連携処理を組みたいと考えている。処理は 1 日に数回動くだけで、データの変換や大量の計算は含まない。呼び出しの間に簡単な条件分岐はあるが、処理の大半は応答の待ち時間である。常時起動する基盤の費用は避けたい。取るべき対応はどれか。

  • Cloud Composer の環境を新設し、API の呼び出しを DAG のタスクとして順に並べる
  • Workflows に YAML でステップを定義し、サーバーレスの実行として API を順に呼ぶ（正解）
  • Dataflow のストリーミングジョブを常駐させ、その中から順番に API を呼び出す
  • Dataproc のクラスタを常時起動し、Spark のジョブとして API の呼び出しを実装する

解説

Workflows はサーバーレスのステップ実行(YAML/JSON)で、軽量な API の連鎖やイベント駆動に向き、常時起動のコストを避けたい場面で選びます。Cloud Composer は常時稼働の環境費がかかるため、この要件では過剰です。Dataflow のストリーミングジョブも常駐するワーカーの費用がかかります。Dataproc のクラスタ常時起動はさらに重く、ジョブごとに使い捨てるのが定石である点からも外れます。

設問2

配車サービスのデータ基盤チームは、車両の位置イベントを BigQuery に取り込んでいる。到着したイベントに簡単な条件で印を付ける程度の単純なストリーミング変換を BigQuery の中だけで完結させ、結果を Pub/Sub や Bigtable にも出したいと考えている。別のストリーミング基盤は増やしたくない。使える機能はどれか。

  • BigQuery の federated query
  • BigQuery の外部テーブルで Cloud Storage のデータをその場で読む
  • BigQuery の continuous query（正解）
  • BigQuery の load job

解説

BigQuery には continuous query があり、BigQuery 内で継続的に走り、結果を Pub/Sub や BigQuery や Bigtable に出せるため、単純なストリーミング変換なら Dataflow なしで済む場合があります。federated query は Cloud SQL / Spanner / AlloyDB に EXTERNAL_QUERY で問い合わせる機能です。外部テーブルは取り込まずにその場で読む仕組み、load job はバッチロードの方式であり、いずれも継続的な処理を担いません。

設問3

製造業の夜間バッチが締め切りに間に合わない。処理は BigQuery のクエリを順に流すもので、データの量は先月とほとんど変わっていない。同じ時間帯にほかの部門のジョブも動いている。クエリの中身は、先月から変えていない。原因が資源側か構造側かを切り分けたい。最初に見るものはどれか。

  • クエリのスキャン量を見て、パーティション枝刈りが効いているかを確認する
  • Cloud Billing のレポートを見て、費用が増えているかどうかを確認する
  • INFORMATION_SCHEMA.JOBS_TIMELINE を見て、slot の待ちがあるかを確認する（正解）
  • Cloud Logging を見て、ジョブのエラーが出ていないかどうかを確認する

解説

夜間バッチが間に合わない場合は、まず JOBS_TIMELINE で slot の待ちがあるかを見ます。待ちが原因なら baseline を上げるか競合を別 reservation に分離し、待ちが無く実行自体が遅いならクエリの構造を直します。スキャン量や枝刈りの確認は構造側の調査で、待ちの有無を見たあとの工程です。Cloud Billing のレポートで費用の増減を見ても、遅れが資源側か構造側かは分かりません。Cloud Logging でエラーが出ていないかを見ても、ジョブは遅いだけで失敗していないので切り分けになりません。

設問4

運用担当者が bucket 内のオブジェクトを誤って削除した。削除は数時間前で、bucket は既定の設定のまま使っている。Object Versioning やバックアップの設定は行っていない。オブジェクトは社内の報告書の原本で、ほかに写しはない。取るべき対応はどれか。

  • Object Lifecycle Management のルールを一時的に無効化し、削除を取り消す
  • soft delete の保持期間内なので、削除されたオブジェクトを復旧する（正解）
  • retention policy を後から設定し、削除されたオブジェクトを保護状態に戻す
  • Autoclass を有効にして、直前のストレージクラスにあった世代を呼び戻す

解説

soft delete は削除後も一定期間(既定 7 日)復旧可能にする機能で、誤削除の保険として働き、保持期間はバケット単位で設定します。数時間前の削除であれば保持期間内なので復旧できます。Object Lifecycle Management は期間による自動的なクラス変更と削除の仕組みで、無効化しても済んだ削除は戻りません。retention policy は今後の削除・上書きを禁じる設定で、既に削除されたオブジェクトを復元しません。Autoclass はアクセスに応じたクラス移動で、世代管理の機能ではありません。

設問5

金融系企業の監査対応の会議で、ダッシュボードやレポートなど可視化段階の管理策を要件ごとに割り当てている。要件は、閲覧の追跡・機微データの発見・値の秘匿・限られた範囲だけの提供などである。管理策はダッシュボードの元になる BigQuery の側で用意する。要件と管理策の対応として正しいものはどれか。（2つ選択）

  • 誰が見たかを記録するには、Cloud Audit Logs の Data Access を使う（正解）
  • 機微データを見つけるには、row access policy で対象行を抽出する
  • 列は見せるが値を隠すには、column-level security で policy tag を外す
  • 集計結果だけを見せるには、authorized view や authorized dataset で集計クエリを固定する（正解）
  • 匿名化して配るには、BI Engine の preferred tables に登録する

解説

誰が見たかを記録するのは Cloud Audit Logs の Data Access、集計結果だけを見せるのは authorized view / authorized dataset で集計クエリを固定する手段です。機微データを見つけるのは Cloud DLP の discovery と inspection で、row access policy は行を絞る仕組みです。列は見せるが値を隠すのは dynamic data masking で、policy tag を外す操作ではありません。匿名化して配るのは Cloud DLP の de-identification や集計と丸めで、BI Engine は加速の仕組みです。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く
← GCP PDE の資格ページへ