問題集 セクション5：データワークロードの保守と自動化
Google Cloud「Professional Data Engineer」試験（2024年改訂範囲）対策の問題集です。 本番同様の シナリオ形式 を中心に、運用判断・トレードオフ・頻出ひっかけを織り込んでいます。
使い方
- 各問の
▶ 正解と解説を開き、正解の理由と各誤答がなぜ不正解か まで必ず読んでください。 - 選択肢を消去法で絞る練習をすると本番で効きます。
- 目標正答率は 80%。間違えた問題は関連リンク先の学習資料に戻って復習しましょう。
問題数・形式
- 全16問
- 形式：単一選択（4択）13問 + 複数選択 3問（Q7・Q11・Q14）
- 難易度内訳：📘 基礎 4問 / 🔧 応用 8問 / 🎯 発展 4問
- 複数選択は「該当するものをすべて選べ（選ぶ数を明記）」形式です。
カバー範囲
- コスト最適化：ephemeral Dataproc + GCS / Spot・プリエンプティブルVM / BigQueryオンデマンド vs 容量ベース / Editions / 予約・コミットメント
- 自動化：Cloud Composer（DAG）/ Workflows / Cloud Scheduler / 冪等性
- 監視：Cloud Monitoring / Cloud Logging / INFORMATION_SCHEMA / 管理リソースチャート / クォータ / 予算アラート
- 耐障害性：マルチゾーン/マルチリージョン / Cloud SQL HA vs リードレプリカ / BigQueryタイムトラベル / Pub/Subシーク / Dataflowスナップショット / Memorystore
Q1 📘 単一選択
あなたは小売企業のデータエンジニアです。毎晩1回だけ、Spark で売上データを変換するバッチジョブを Dataproc で実行しています。現在は常時起動の永続クラスタを使っており、日中はアイドル状態でもコストが発生しています。コストを最小化する最も適切な構成はどれですか。
- A. 永続クラスタのマシンタイプを小さくし、そのまま常時起動を続ける
- B. ジョブのたびにクラスタを起動して完了後に破棄する ephemeral クラスタにし、データは Cloud Storage に置く
- C. ジョブのたびにクラスタを起動し、データはクラスタ内の HDFS に保持する
- D. 永続クラスタを止めずに、夜間だけ手動でジョブを投入する運用を続ける
▶ 正解と解説
正解：B
解説： 夜間1回のバッチでアイドル時間が長いケースは、ジョブのたびに起動し完了後に破棄する ephemeral（ジョブ単位）クラスタ がコスト最小の定番解です。鉄則として、データはクラスタ内 HDFS ではなく Cloud Storage（GCS） に置き、コンピュートとストレージを分離します。これによりクラスタを破棄してもデータが残ります。
- ❌ A：マシンタイプを小さくしてもアイドル時間中ずっと課金され続けるため、根本的なムダが残る。
- ❌ C：データを HDFS に置くとクラスタ破棄時にデータが消えてしまい、ephemeral 運用が成立しない。
- ❌ D：常時起動を続ける限りアイドルコストは消えず、手動運用は再現性も損なう。
📖 関連：02_応用.md の「5.1 Dataproc：永続 vs ジョブ単位（ephemeral）の判断」
Q2 📘 単一選択
Dataproc クラスタのコストをさらに下げるため、安価で中断され得る Spot VM（プリエンプティブル VM の後継）を導入したいと考えています。クラスタを不安定にせずコストを下げるには、どのノードに Spot VM を使うべきですか。
- A. マスターノード
- B. プライマリワーカー
- C. セカンダリワーカー
- D. マスターとプライマリワーカーの両方
▶ 正解と解説
正解：C
解説： Spot/プリエンプティブル VM は Google の都合でいつでも停止され得るため、セカンダリワーカーのみ に使うのが定石です。プライマリワーカーは通常 VM で安定性を確保します。これにより、一部ノードが中断されてもクラスタ全体は動き続けます。
- ❌ A：マスターが中断されるとクラスタ全体が機能停止するため不可。
- ❌ B：プライマリワーカーは安定稼働の土台。Spot にするとクラスタが不安定化する。
- ❌ D：マスター・プライマリの両方を Spot にするのは最も危険な構成。
📖 関連：03_要点と暗記.md の「安いVMの使い分け」
Q3 🔧 単一選択
ある企業の BigQuery 利用は、月によってクエリ量が大きく変動し、月額コストが読めず高止まりしています。一方でクエリ量は全体として多く、今後も継続的に増える見込みです。コストを安定させ予算を予測可能にする最も適切な対応はどれですか。
- A. すべてのクエリをオンデマンド課金のまま継続する
- B. 容量ベース（Editions + コミットメント）に移行してスロットを予約し、定額化・上限設定する
- C. すべてのクエリをバッチ優先度に変更する
- D. クエリ結果のキャッシュを無効化して再計算を増やす
▶ 正解と解説
正解：B
解説： 「クエリ量が多く継続的で予測可能」かつ「月額が変動して読めない」場合は、容量ベース（Editions + コミットメント） に移行してスロットを予約するのが定番です。確保したスロット時間で課金されるため予算が固定でき、上限スロットでコスト暴走も頭打ちにできます。
- ❌ A：オンデマンドはスキャン量次第でコストが変動し、まさに今の課題そのもの。大量・継続利用には割高になりやすい。
- ❌ C：バッチ優先度はリソース競合の平準化には役立つが、課金モデル（スキャン量課金）は変わらずコストの予測可能性は解決しない。
- ❌ D：キャッシュ無効化はスキャン量を増やしコストを悪化させる、逆効果。
📖 関連：02_応用.md の「5.1 BigQuery：オンデマンド vs 容量ベース」
Q4 📘 単一選択
社内の分析チームは BigQuery を月に数回、不定期に少量のクエリでしか使いません。データ量も読みにくく、利用は散発的です。コスト面で最も適切な課金モデルはどれですか。
- A. Enterprise Plus エディションで大容量のスロットを予約する
- B. 3年コミットメントでスロットを大量購入する
- C. オンデマンド課金（スキャンしたデータ量に対する課金）
- D. Enterprise エディションで baseline スロットを常時確保する
▶ 正解と解説
正解：C
解説： 利用が散発的で量が読めず小規模な場合は、使った分（スキャン量）だけ課金される オンデマンド が最も無駄がありません。たまにしか使わないのに定額の枠を買うと、使わない時間も課金され割高になります。
- ❌ A：Enterprise Plus は最上位で高コスト。散発利用には完全にオーバースペック。
- ❌ B：3年コミットメントは「継続的に一定量を使う」前提。散発利用では空き枠の無駄が大きい。
- ❌ D：baseline スロットを常時確保するとアイドル時間も課金され、散発利用には不向き。
📖 関連：03_要点と暗記.md の「BigQuery 課金モデル」
Q5 🔧 単一選択
あなたのチームは、多数のタスクが複雑に依存し合う ETL を運用しています。タスクには分岐・リトライ・過去日付のバックフィルが必要で、現在は手動でやり直していて再現性がありません。オーケストレーションに最も適したサービスはどれですか。
- A. Cloud Scheduler に cron を登録し、シェルスクリプトで順番に実行する
- B. Cloud Composer（マネージド Airflow）で DAG として依存関係を定義する
- C. Workflows に HTTP 呼び出しを並べて軽量に実行する
- D. Pub/Sub のトピックにメッセージを流して処理を起動する
▶ 正解と解説
正解：B
解説： 多数のタスク・複雑な依存・分岐・リトライ・バックフィル が必要な本格的ワークフローは Cloud Composer（DAG / Airflow） が適任です。retries や execution_date による論理日付の再処理で、失敗時の安全な再実行・過去日付の再処理ができます。
- ❌ A：Scheduler + スクリプトは「定期トリガーだけ」向け。複雑な依存・バックフィルを手組みするのはアンチパターン。
- ❌ C：Workflows は数個のAPI/サービスを順番に呼ぶ軽量編成向け。多数タスクの複雑な依存管理やバックフィルには非力。
- ❌ D：Pub/Sub はメッセージングであり、依存関係のあるワークフローのオーケストレーターではない。
📖 関連：02_応用.md の「5.2 Composer / Workflows / Cloud Scheduler の使い分け」
Q6 🔧 単一選択
あるサービスでは、3つの REST API を順番に呼び出すだけの軽量な連携処理を、1日数回サーバーレスで実行したいと考えています。複雑な依存もバックフィルも不要です。Cloud Composer の常時稼働環境はコスト面でオーバースペックと判断しました。最も適切なサービスはどれですか。
- A. Cloud Composer
- B. Workflows
- C. Dataproc
- D. Dataflow
▶ 正解と解説
正解：B
解説： 数個の API/サービスを順番に呼び出す軽量な編成には、サーバーレスで YAML/JSON 定義の Workflows が最適です。Composer 環境のように常時課金されず、軽量・低コストで実行できます。
- ❌ A：Composer は環境が常時課金される。軽量なAPI連携にはオーバースペックで割高。
- ❌ C：Dataproc は Spark/Hadoop クラスタ。API のオーケストレーション用途ではない。
- ❌ D：Dataflow はデータ処理パイプライン（Apache Beam）用。単純な API 連携の編成には不適。
📖 関連：01_基礎.md の「5.2 オーケストレーションの選択肢」
Q7 🔧 複数選択（2つ選べ）
Cloud Composer の DAG を冪等（idempotent）に設計し、タスクが失敗して再実行されても二重書き込みや破損が起きないようにしたいと考えています。冪等性を担保する設計として 適切なものを2つ 選んでください。
- A. BigQuery への書き込みを毎回
INSERTで追記する - B. 対象パーティションを
WRITE_TRUNCATE（上書き）してから書き込む - C. ターゲットテーブルに対して
MERGE文で upsert する - D. タスクごとにランダムなサフィックスを付けた新規テーブルを毎回作成し続ける
▶ 正解と解説
正解：B と C
解説： 冪等性とは「同じ処理を何回実行しても結果が同じ」になる性質です。パーティションの上書き（WRITE_TRUNCATE） や MERGE による upsert は、再実行しても最終状態が一意に定まるため二重書き込みを防げます。
- ❌ A：
INSERT追記は再実行のたびに行が重複し、冪等ではない（典型的なアンチパターン）。 - ❌ D：毎回新規テーブルを作り続けると結果が増殖し、目的のテーブル状態が一意に定まらない。テーブルの管理も破綻し冪等とは言えない。
📖 関連：01_基礎.md の「5.2 冪等性（idempotency）」
Q8 🔧 単一選択
重要な本番 ETL ジョブが、アナリストのアドホッククエリが集中する時間帯にスロット不足となり、SLA を満たせないことがあります。BigQuery は容量ベース（予約）で運用しています。最も適切な対策はどれですか。
- A. すべてのワークロードを単一の大きな予約にまとめてスロットを共有する
- B. 予約を用途別に分離し（例：
prod-etlとadhoc）、重要 ETL 用のスロットを確保して割り当てる - C. 重要 ETL をオンデマンドに戻す
- D. アナリストの BigQuery 利用を全面的に禁止する
▶ 正解と解説
正解：B
解説： 重要ジョブが他の負荷でスロット枯渇する問題は、予約（reservation）を用途別に分離して割り当てる のが定番解です。prod-etl 予約と adhoc 予約を分ければ、アドホッククエリの増減が重要 ETL のスロットを奪わなくなります。急がないものはバッチクエリに回すのも併用できます。
- ❌ A：単一予約で共有すると、まさに今の競合（アドホックがETLを圧迫）が再発する。
- ❌ C：オンデマンドに戻すとスキャン量課金になりコストが読めず、競合の根本解決にもならない。
- ❌ D：分析業務を禁止するのはビジネス要件を無視した非現実的な対応。
📖 関連：02_応用.md の「5.1 ビジネスクリティカル処理へのリソース確保」
Q9 🔧 単一選択
夜間に実行する大量の集計クエリがあり、即時性は求められません。日中はインタラクティブな同時実行クォータに当たることがあり、リソース競合を避けたいと考えています。この集計クエリに最も適した実行方法はどれですか。
- A. インタラクティブ（デフォルト）優先度で即時実行する
- B. バッチ優先度で実行し、スロットに空きが出たら処理させる
- C. クエリを細かく分割して同時に大量実行する
- D. クエリ結果のキャッシュを無効化する
▶ 正解と解説
正解：B
解説： 急がない大量処理は バッチ（batch）優先度 が適します。スロットに空きが出たタイミングで実行されるため、即時性を犠牲にする代わりにリソース競合を避け、インタラクティブの同時実行クォータにも当たりにくくなります。
- ❌ A：インタラクティブは即時実行でレイテンシ重視。急がない大量処理に使うとクォータ・競合の原因になる。
- ❌ C：細かく分割して同時大量実行すると、同時実行上限に当たりやすく競合を悪化させる。
- ❌ D：キャッシュ無効化は処理量を増やすだけで競合解消にならない。
📖 関連：02_応用.md の「5.3 インタラクティブ vs バッチ クエリの判断」
Q10 🔧 単一選択
あるダッシュボード用 BigQuery クエリが急に遅くなり、コストも増えました。どのクエリがスキャン量・スロットを多く消費しているかを SQL で特定し、原因を分析したいと考えています。最も適切な手段はどれですか。
- A. Cloud Trace でレイテンシの内訳を確認する
- B.
INFORMATION_SCHEMA.JOBSを参照してスキャン量・スロット・実行時間を分析する - C. 予算とアラートを設定してコスト超過を通知する
- D. Cloud SQL の slow query log を確認する
▶ 正解と解説
正解：B
解説： BigQuery のジョブごとのスキャン量・スロット消費・実行時間を SQL で分析するには INFORMATION_SCHEMA.JOBS を使います。高コスト・低速クエリを特定し、パーティション/クラスタリングの不足や SELECT * の多用、スロット不足を切り分けられます。
- ❌ A：Cloud Trace は分散トレースによるレイテンシ追跡用で、BigQuery のジョブ別スキャン量分析には使わない。
- ❌ C：予算アラートはコスト超過の「通知」であり、どのクエリが重いかの特定はできない。
- ❌ D：Cloud SQL のログは BigQuery とは無関係なサービスのもの。
📖 関連：02_応用.md の「5.4 BigQuery トラブルシュートの定番」
Q11 🔧 複数選択（2つ選べ）
本番のデータパイプラインのジョブが、断続的に失敗するようになりました。エラーの原因を切り分けるために、まず確認すべきものとして 適切なものを2つ 選んでください。
- A. Cloud Logging のエラーメッセージ・スタックトレース
- B. プロジェクトのクォータ（同時実行数・APIレート）の使用状況
- C. GCS バケットのオブジェクトバージョニング設定
- D. BigQuery のタイムトラベル保持期間
▶ 正解と解説
正解：A と B
解説： ジョブが断続的に失敗する場合の定番切り分けは、まず Cloud Logging でエラーメッセージ を確認し、加えて クォータ超過（同時実行数・APIレート） を疑うことです。Quota exceeded 系エラーは断続的失敗の頻出原因で、上限引き上げ申請やレート制御で対処します。
- ❌ C：オブジェクトバージョニングは GCS の削除/上書き復元機能であり、ジョブ失敗の原因切り分けには関係しない。
- ❌ D：タイムトラベルは BigQuery の誤削除/誤更新からの復旧機能で、ジョブ失敗の原因究明とは無関係。
📖 関連：02_応用.md の「5.4 クォータ・課金・エラーの切り分け」
Q12 📘 単一選択
本番の Cloud SQL インスタンスが、データセンターの ゾーン障害 で一度停止しました。同様の障害時に自動的に切り替わり、ダウンタイムを最小化したいと考えています。最も適切な構成はどれですか。
- A. リードレプリカを同一リージョンに追加する
- B. HA（高可用性）構成にし、同一リージョンの別ゾーンにスタンバイを置く
- C. 自動バックアップの頻度を上げる
- D. インスタンスのマシンタイプを大きくする
▶ 正解と解説
正解：B
解説： ゾーン障害 に自動で耐えるには、Cloud SQL の HA 構成（同一リージョンの別ゾーンにスタンバイを配置し、障害時に自動フェイルオーバー）が適切です。HA は「可用性（止まらない）」を目的とした仕組みです。
- ❌ A：リードレプリカは読み取りスケール/DR が目的で、自動フェイルオーバーしない（手動で昇格が必要）。可用性の自動確保には不向き。
- ❌ C：バックアップ頻度を上げてもゾーン障害時の自動切り替えにはならない。
- ❌ D：マシンタイプの拡大は性能向上であり、ゾーン障害への冗長性は得られない。
📖 関連：02_応用.md の「5.5 Cloud SQL：HA とリードレプリカの違い」
Q13 🎯 単一選択
金融系のサービスで、リージョン全体の災害 が発生しても本番 Cloud SQL データベースを別リージョンで復旧できる構成を求められています。最も適切な対策はどれですか。
- A. 同一リージョンの別ゾーンに HA スタンバイを置く
- B. クロスリージョンのリードレプリカを別リージョンに配置し、災害時に昇格（promote）する
- C. 同一リージョン内にリードレプリカを複数置く
- D. 自動バックアップを同一リージョンの Cloud Storage に保存する
▶ 正解と解説
正解：B
解説： リージョン障害 に備えるには、別リージョンにクロスリージョンのリードレプリカ を配置し、災害時にそれを昇格（promote）してプライマリにします。HA 構成は同一リージョン内のゾーン障害までしか守れない点がひっかけです。
- ❌ A：HA は同一リージョン内（別ゾーン）の冗長。リージョン全体の障害には耐えられない。
- ❌ C：同一リージョン内のレプリカでは、そのリージョンが落ちると全滅する。
- ❌ D：同一リージョンの Storage にバックアップしてもリージョン障害で同時に失われる恐れがあり、冗長性のレベルが不足。
📖 関連：02_応用.md の「5.5 冗長レベルの選び方 / クロスリージョンリードレプリカ」
Q14 🎯 複数選択（3つ選べ）
複数の運用課題への対処を検討しています。それぞれの課題に対する 正しいサービス機能の組み合わせを3つ 選んでください。
- A. BigQuery テーブルを誤って上書きした → タイムトラベル（過去7日間）で上書き前の状態を復元する
- B. Pub/Sub で取りこぼしたメッセージを再処理したい → シーク（Seek）で過去のタイムスタンプ/スナップショットへ巻き戻して再配信する
- C. Dataflow のストリーミングパイプラインの状態を保存し復元・移行したい → Dataflow スナップショットを使う
- D. BigQuery テーブルを誤って上書きした → Pub/Sub のシークで復元する
▶ 正解と解説
正解：A と B と C
解説： サービス別の復旧カードはそのまま暗記対象です。BigQuery の誤上書き/誤削除 → タイムトラベル（7日）、Pub/Sub の取りこぼし再処理 → シーク、Dataflow のストリーミング状態の保存・復元/移行 → スナップショット が正しい対応です。
- ❌ D：BigQuery テーブルの復元に Pub/Sub のシークは使えない（サービスが異なる）。シークは Pub/Sub のメッセージ再配信用。BigQuery の誤上書きはタイムトラベルやテーブルスナップショットで復旧する。
📖 関連：03_要点と暗記.md の「データ破損・欠損の復旧カード」
Q15 🎯 単一選択
分析者が誤って本番 BigQuery テーブルを上書きしてしまいました。組織のポリシーでは 過去30日間 はいつでも復元できる状態を求められています。タイムトラベルだけでは要件を満たせません。30日超の保護を実現する最も適切な追加策はどれですか。
- A. タイムトラベルの保持期間を30日に延長する
- B. テーブルスナップショット（およびエクスポート）を併用し、7日を超える期間を保護する
- C. Pub/Sub のシークでテーブルを巻き戻す
- D. Cloud SQL の PITR でテーブルを復元する
▶ 正解と解説
正解：B
解説： BigQuery の タイムトラベルは7日固定 で、それ以上の保護はできません。30日のような長期保護が要件なら、テーブルスナップショット や定期的な エクスポート を併用して7日超をカバーします。
- ❌ A：タイムトラベルは7日固定で延長できない（ここがひっかけ）。
- ❌ C：Pub/Sub のシークはメッセージ再配信用で、BigQuery テーブルの復元には使えない。
- ❌ D：PITR は Cloud SQL の機能で、BigQuery テーブルの復元手段ではない。
📖 関連：02_応用.md の「5.5 データ破損・欠損への備え（BigQueryタイムトラベルは7日固定）」
Q16 🎯 単一選択
あるアプリのキャッシュ層に Memorystore for Redis を使っています。現在は Basic Tier で運用していますが、プライマリ障害時に自動でフェイルオーバーし、キャッシュの可用性を高める要件が新たに加わりました。最も適切な対応はどれですか。
- A. Basic Tier のままメモリ容量を増やす
- B. Standard Tier に変更する（または Redis クラスタを採用する）ことでレプリカによる自動フェイルオーバーを得る
- C. Cloud SQL の HA 構成に置き換える
- D. Basic Tier のインスタンスを2つ並べて手動で切り替える
▶ 正解と解説
正解：B
解説： Memorystore for Redis で 可用性（自動フェイルオーバー） を得るには、レプリカを持つ Standard Tier、または大容量・高スループット向けの Redis クラスタ を使います。Basic Tier はレプリカがなく冗長性がない 点がポイントです。
- ❌ A：Basic Tier は容量を増やしてもレプリカがなく、自動フェイルオーバーは得られない。
- ❌ C：キャッシュ層の要件に対してリレーショナル DB（Cloud SQL）へ置き換えるのは設計として不適切。
- ❌ D：Basic を2つ並べて手動切り替えは「自動フェイルオーバー」要件を満たさず、運用も煩雑。
📖 関連：02_応用.md の「5.5 Memorystore (Redis) の冗長」
自己採点
| 設問 | 難易度 | 主テーマ | あなたの正誤 |
|---|---|---|---|
| Q1 | 📘 基礎 | ephemeral Dataproc + GCS | ⬜ |
| Q2 | 📘 基礎 | Spot VM はセカンダリワーカー | ⬜ |
| Q3 | 🔧 応用 | 容量ベース（Editions+コミットメント）への移行 | ⬜ |
| Q4 | 📘 基礎 | 散発利用はオンデマンド | ⬜ |
| Q5 | 🔧 応用 | 複雑な依存・バックフィルは Composer | ⬜ |
| Q6 | 🔧 応用 | 軽量API連携は Workflows | ⬜ |
| Q7 | 🔧 応用（複数選択） | 冪等性（WRITE_TRUNCATE / MERGE） | ⬜ |
| Q8 | 🔧 応用 | 予約の用途別分離 | ⬜ |
| Q9 | 🔧 応用 | 急がない大量処理はバッチクエリ | ⬜ |
| Q10 | 🔧 応用 | INFORMATION_SCHEMA.JOBS で分析 | ⬜ |
| Q11 | 🔧 応用（複数選択） | ジョブ失敗は Logging + クォータ | ⬜ |
| Q12 | 📘 基礎 | ゾーン障害は Cloud SQL HA | ⬜ |
| Q13 | 🎯 発展 | リージョン障害はクロスリージョンレプリカ | ⬜ |
| Q14 | 🎯 発展（複数選択） | 復旧カード（タイムトラベル/シーク/スナップショット） | ⬜ |
| Q15 | 🎯 発展 | タイムトラベル7日固定 + スナップショット | ⬜ |
| Q16 | 🎯 発展 | Memorystore は Standard Tier / クラスタ | ⬜ |
スコア： ／16（目標：13／16 = 約80%）
復習の優先度
- 12点以下：01_基礎.md と 03_要点と暗記.md の暗記テーブルを白紙再現できるまで戻る。
- 13〜14点：間違えたテーマの 02_応用.md のひっかけポイントを重点確認。
- 15点以上：合格圏。本番では「コスト最適化・自動化・キャパシティ・監視・DR」のどのカードに割り当てる問題かを瞬時に判断する練習を。
特に注意すべきひっかけ（本問題集で扱った頻出パターン）
- Dataproc コスト = ephemeral + GCS が第一手（永続クラスタ最適化に誘導されない）
- Spot/プリエンプティブルは セカンダリワーカーのみ
- オンデマンド ⇔ 容量ベース は使用量の予測可能性で決める
- Composer ⇔ Workflows ⇔ Scheduler のオーバー/アンダースペック
- HA ⇔ リードレプリカ（可用性 vs 読み取りスケール）、マルチゾーン ⇔ マルチリージョン（ゾーン障害 vs リージョン障害）
- BigQuery タイムトラベルは7日固定（30日要件はスナップショット/エクスポート併用）
- 「メッセージ再処理」= Pub/Sub シーク、「ストリーミング状態」= Dataflow スナップショット（取り違え注意）