模擬問題集一覧

GCP-ADP 模擬問題集(練習問題)

Associate Data Practitioner 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-ADP(Associate Data Practitioner)の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード/演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問+全解説が受け放題

模試プラン(¥980/月)なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-ADP の出題範囲(カバーしている分野)

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-ADP の学習ガイドにまとめています。

GCP-ADP の無料練習問題(15 問・解説つき)

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1サービス アカウントにどの事前定義 IAM ロールを適用すべきですか。データ管理
問題
複数の BigQuery データセットとやり取りするアプリケーションを設計しています。アプリケーションのサービス アカウントに、データセット内のテーブルに対するクエリの実行と更新、およびアプリケーション内でプロジェクトのすべてのデータセットを一覧表示することを許可する権限を付与する必要があります。最小権限の原則に従いたいと考えています。サービス アカウントにどの事前定義 IAM ロールを適用すべきですか。

選択肢と解説

  • ✓
    roles/bigquery.jobUser と roles/bigquery.dataOwner
  • 2
    roles/bigquery.connectionUser と roles/bigquery.dataViewer
  • 3
    roles/bigquery.admin
  • 4
    roles/bigquery.studioUser と roles/bigquery.filtereddataViewer

解説

【正解】A

【0からの解説】
①前提知識:BigQuery の IAM では「ジョブ(クエリなど)を実行する権限」と「データ(データセット・テーブル)にアクセスする権限」が別々のロールに分かれています。
・roles/bigquery.jobUser(BigQuery ジョブユーザー):プロジェクト内でジョブを作成・実行する権限(bigquery.jobs.create)を持ちます。クエリはジョブとして実行されるため、SQL を実行するにはこの権限が必要です。データそのものへのアクセス権は含みません。
・roles/bigquery.dataOwner(BigQuery データオーナー):データセットとテーブルの読み取り・作成・更新・削除(bigquery.tables.updateData など)や、データセットの情報取得(bigquery.datasets.get)を含みます。データセットの一覧表示には bigquery.datasets.get 権限が必要で、プロジェクト レベルで付与すればプロジェクト内のデータセットを列挙できます。

②要件と制約語の整理:(a) テーブルに対してクエリを実行する → ジョブ実行権限、(b) テーブルを更新する → データの書き込み権限、(c) プロジェクト内のすべてのデータセットを一覧表示する → bigquery.datasets.get、(d)「最小権限の原則に従う(least privilege)」→ 必要な権限をカバーする組み合わせのうち、余計な権限が最も少ないもの。

③正解の理由:jobUser でクエリ ジョブを実行し、dataOwner でテーブルの読み書きとデータセットの一覧表示を行えるため、A はすべての要件を満たします。厳密には dataOwner はデータセットのアクセス制御(IAM ポリシー)の変更やデータセットの削除まで含むため、選択肢にない roles/bigquery.dataEditor の方がさらに絞り込まれたロールです。しかし提示された選択肢の中で、要件をすべて満たしつつ管理者ロールほど広くないのは A だけです。試験では「要件を満たす最小の組み合わせ」を選択肢の中から比較して選びます。

【誤りの選択肢】
B:roles/bigquery.connectionUser は外部データソースへの接続(BigQuery 接続)を使用する権限、roles/bigquery.dataViewer はデータの読み取り専用権限です。テーブルの更新ができず、またジョブ実行権限(bigquery.jobs.create)も含まれないためクエリも実行できません。要件を満たしません。
C:roles/bigquery.admin は BigQuery のすべてのリソースに対する完全な管理権限で、要件はすべて満たしますが、予約の管理や他ユーザーのジョブの取り消し、全データセットの削除など不要な権限まで付与してしまいます。最小権限の原則に反します。
D:roles/bigquery.studioUser は BigQuery Studio(ノートブックや保存したクエリなど)を利用するためのロールで、テーブルの更新権限は含みません。roles/bigquery.filteredDataViewer は行レベルのアクセス ポリシーによってフィルタされた行だけを閲覧できる読み取り専用ロールで、通常は行アクセス ポリシーを通じて付与されるものです。テーブル更新の要件を満たしません。

【参考】
データセットの一覧表示
ロールと権限 | Identity and Access Management (IAM)
この問題のページを開く →
問題 2Cloud Storage へのオンライン移行を行う必要があります。データの準備と取り込み
問題
あなたの会社には、Google Cloud に移行する必要がある 5 TB のデータを持つオンプレミスのファイル サーバーがあります。ネットワーク運用チームは、移行に使用できるのは利用可能な帯域幅全体のうち最大 250 Mbps までと定めています。Cloud Storage へのオンライン移行を行う必要があります。どうすればよいですか。

選択肢と解説

  • 1
    gcloud storage cp コマンドで --daisy-chain オプションを使用し、オンプレミスから Cloud Storage にすべてのファイルをコピーする。
  • ✓
    Storage Transfer Service を使用してエージェント ベースの転送を構成する。エージェント プールに適切な帯域幅の上限を設定する。
  • 3
    Transfer Appliance をリクエストし、データをアプライアンスにコピーして Google Cloud に返送する。
  • 4
    gcloud storage cp コマンドで --no-clobber オプションを使用し、オンプレミスから Cloud Storage にすべてのファイルをコピーする。

解説

【正解】B

【0からの解説】
①前提知識:Storage Transfer Service(STS)は、他クラウドやオンプレミスから Cloud Storage へ大量のデータを転送するマネージド サービスです。オンプレミスのファイル システム(POSIX ファイル システムや NFS など)から転送する場合は「エージェント ベースの転送」を使い、オンプレミス側のマシンに転送エージェント(Docker コンテナ)をインストールします。エージェントは「エージェント プール」という単位でまとめて管理され、エージェント プールには帯域幅の上限(bandwidth limit)を設定できます。上限はプール内のすべてのエージェントで共有され、転送に使うネットワーク帯域を一定以下に抑えられます。また、転送の再試行・整合性チェック・ログ記録・スケジュール実行などを STS が管理します。

②要件と制約語の整理:(a) オンプレミスのファイル サーバー上の 5 TB、(b) 使用帯域は最大 250 Mbps まで(ネットワーク運用チームの必須要件)、(c)「オンライン移行」(ネットワーク経由。物理デバイスの配送ではない)。なお 250 Mbps で 5 TB を転送すると約 2 日弱で完了するため、オンラインで十分現実的な量です。

③正解の理由:STS のエージェント ベース転送はオンプレミスのファイル サーバーからのオンライン転送に対応しており、エージェント プールの帯域幅上限を 250 Mbps 相当(コンソールでは MB/s で指定するため約 31 MB/s)に設定すれば、運用チームの制約を確実に守りながら移行できます。大量データの転送を再試行や検証込みでマネージドに行えるため、Google が推奨する方法です。

【誤りの選択肢】
A:--daisy-chain は、クラウド間(例:別プロバイダのバケットから Cloud Storage)でコピーする際にデータをローカル経由で中継するためのオプションで、帯域幅を制限する機能ではありません。250 Mbps の上限を守る仕組みがなく、要件を満たしません。
C:Transfer Appliance は物理的なストレージ デバイスにデータをコピーして Google に配送する「オフライン」移行の手段です。問題文は「オンライン移行」を求めており、5 TB 程度であれば 250 Mbps でも数日で転送できるため、アプライアンスを使う理由もありません。
D:--no-clobber は、宛先に同名のオブジェクトがすでに存在する場合に上書きしない(スキップする)ためのオプションで、帯域幅の制限とは無関係です。250 Mbps の上限を守れないため要件を満たしません。

【参考】
ファイル システムから Cloud Storage へ転送する | Storage Transfer Service
データ転送オプション | Storage Transfer Service
この問題のページを開く →
問題 3最小の労力で、これらのパイプラインを Google Cloud のマネージド サービスに移行する必要があります。データ パイプラインのオーケストレーション
問題
最近の企業買収に伴い、Google Cloud に移行する必要があるオンプレミスのデータ基盤を引き継ぎました。買収したシステムには、データ パイプラインをオーケストレーションする 250 個の Apache Airflow の有向非巡回グラフ(DAG)があります。最小の労力で、これらのパイプラインを Google Cloud のマネージド サービスに移行する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Google Kubernetes Engine(GKE)Standard クラスタを作成し、Airflow をワークロードとしてデプロイする。すべての DAG を新しい Airflow 環境に移行する。
  • 2
    Cloud Data Fusion インスタンスを作成する。DAG ごとに Cloud Data Fusion パイプラインを作成する。
  • ✓
    新しい Cloud Composer 環境を作成し、DAG を Cloud Composer の dags/ フォルダにコピーする。
  • 4
    各 DAG を Cloud Workflow に変換し、Cloud Scheduler で実行を自動化する。

解説

【正解】C

【0からの解説】
①前提知識:Apache Airflow は、処理の依存関係を Python コードの DAG(有向非巡回グラフ)として記述し、スケジュール実行・再試行・監視を行うオープンソースのワークフロー オーケストレーション ツールです。Cloud Composer(現 Managed Service for Apache Airflow)は、この Airflow を Google Cloud がフルマネージドで提供するサービスで、Airflow のスケジューラ・ワーカー・Web サーバー・データベースなどの構築・運用・アップグレードを Google 側が担います。Cloud Composer の環境には専用の Cloud Storage バケットが紐づいており、その dags/ フォルダに DAG ファイル(.py)を置くだけで Airflow が自動的に読み込み、スケジュールに従って実行します。

②要件と制約語の整理:(a) 既存資産は 250 個の Airflow DAG、(b) 移行先は Google Cloud の「マネージド サービス」、(c)「最小の労力で(minimal effort)」。つまり、DAG を書き直さずにそのまま動かせ、かつ基盤の運用を自分で持たない選択肢が求められています。

③正解の理由:Cloud Composer は Airflow そのものをマネージドで動かすため、既存の DAG コードを基本的にそのまま dags/ フォルダにコピーするだけで移行できます(接続情報や変数、必要な PyPI パッケージの設定は必要に応じて行います)。250 個の DAG を別の製品向けに作り直す必要がなく、Airflow 基盤の運用も Google に任せられるため、「マネージド」と「最小の労力」の両方を満たします。

【誤りの選択肢】
A:GKE 上に Airflow を自前でデプロイすれば DAG はそのまま動きますが、Airflow のインストール・スケーリング・アップグレード・メタデータ DB の管理などを自分で運用する必要があり、GKE Standard ではノード管理も自分の責任です。「Google Cloud のマネージド サービス」に移行するという要件を満たさず、労力も Cloud Composer より大きくなります。
B:Cloud Data Fusion は GUI でデータ統合(ETL/ELT)パイプラインを構築するサービスで、Airflow DAG をそのまま取り込む機能はありません。250 個の DAG をすべて Data Fusion のパイプラインとして作り直すのは膨大な作業で、「最小の労力」に反します。
D:Workflows(選択肢の Cloud Workflow)はサービスや API の呼び出しを YAML/JSON で順序立てて実行するマネージド オーケストレーション サービスで、Airflow の DAG(Python)とは記述形式がまったく異なります。250 個の DAG を Workflows の定義に書き換える必要があり、Cloud Scheduler の設定も別途必要になるため、労力が大きくなります。

【参考】
Managed Airflow の概要 | Managed Service for Apache Airflow
環境のアーキテクチャ | Managed Service for Apache Airflow
この問題のページを開く →
問題 4今後 3 か月間、月間売上が最も高い上位 3 地域を特定するソリューションを作成する必要があります。データの分析と提示
問題
あなたの組織では、地域別の売上指標を分析しています。各地域の営業チームのデータは BigQuery の個別のテーブルとして保存され、毎月更新されます。今後 3 か月間、月間売上が最も高い上位 3 地域を特定するソリューションを作成する必要があります。ソリューションが最新の結果を自動的に提供するようにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    すべての地域別売上テーブルに対して UNION を実行する BigQuery テーブルを作成する。ROW_NUMBER() ウィンドウ関数を使用して新しいテーブルをクエリする。
  • 2
    すべての地域別売上テーブルに対して CROSS JOIN を実行する BigQuery テーブルを作成する。RANK() ウィンドウ関数を使用して新しいテーブルをクエリする。
  • ✓
    すべての地域別売上テーブルに対して UNION を実行する BigQuery マテリアライズド ビューを作成する。RANK() ウィンドウ関数を使用して新しいマテリアライズド ビューをクエリする。
  • 4
    すべての地域別売上テーブルに対して CROSS JOIN を実行する BigQuery マテリアライズド ビューを作成する。ROW_NUMBER() ウィンドウ関数を使用して新しいマテリアライズド ビューをクエリする。

解説

【正解】C

【0からの解説】
①前提知識:
・UNION(UNION ALL / UNION DISTINCT)は、同じ列構成の複数のテーブルの行を縦に積み重ねて 1 つの結果にまとめる演算です。地域ごとに分かれた同じ構造の売上テーブルを 1 つにまとめるのに適しています。一方 CROSS JOIN はテーブル同士のすべての行の組み合わせ(直積)を作る演算で、行数が掛け算で増え、売上の集計には使えません。
・マテリアライズド ビュー(実体化ビュー)は、クエリ結果を事前に計算して保存し、ベーステーブルが変更されると BigQuery が自動的に再計算(リフレッシュ)するビューです。通常のテーブルは作成時点のスナップショットにすぎず、元テーブルが更新されても自動では変わりません。UNION を含む定義は「非増分マテリアライズド ビュー」(allow_non_incremental_definition オプションと max_staleness オプションを指定)として作成できます。
・RANK() と ROW_NUMBER() はどちらもウィンドウ関数(分析関数)です。ROW_NUMBER() は同順位があっても必ず 1, 2, 3… と一意の番号を振るため、売上が同額の地域があると任意にどちらかが落ちます。RANK() は同じ値に同じ順位を付ける(1, 2, 2, 4…)ため、同額の地域を公平に扱えます。

②要件と制約語の整理:(a) 地域ごとに個別のテーブル(毎月更新)、(b) 月ごとの売上上位 3 地域を特定、(c) 今後 3 か月間、「最新の結果を自動的に提供」する。

③正解の理由:UNION で全地域のテーブルを 1 つにまとめたマテリアライズド ビューを作れば、毎月元テーブルが更新されるたびに結果が自動的にリフレッシュされます。そのビューに対して月ごとに PARTITION BY した RANK() で順位を付け、上位 3 を抽出すれば、同額の地域も正しく扱いながら常に最新のランキングを得られます。

【誤りの選択肢】
A:UNION による統合は正しいものの、通常の「テーブル」として作成すると作成時点のデータで固定され、元の地域別テーブルが毎月更新されても反映されません。「最新の結果を自動的に提供」という要件を満たさず、毎月作り直す手作業が必要になります。また ROW_NUMBER() は同順位を区別して一意に番号を振るため、売上が同額の地域があると上位 3 の判定が不公平になります。
B:CROSS JOIN は全行の組み合わせ(直積)を作るため、地域ごとの売上を 1 列にまとめることができず、行数が爆発的に増えて正しい集計になりません。さらに通常のテーブルなので自動更新もされません。
D:マテリアライズド ビューで自動更新はできますが、CROSS JOIN では地域別テーブルを正しく統合できず、売上ランキングの元データとして成立しません。ROW_NUMBER() も同順位を扱えない点で RANK() に劣ります。

【参考】
マテリアライズド ビューを作成する
マテリアライズド(実体化)ビューの概要
この問題のページを開く →
問題 5すべてのデータが少なくとも 3 年間バケットに保存されるようにする必要があります。データ管理
問題
あなたの会社は履歴データを Cloud Storage に保存しています。すべてのデータが少なくとも 3 年間バケットに保存されるようにする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    一時的なオブジェクト保持(temporary hold)を設定する。
  • ✓
    バケットの保持ポリシーを設定する。
  • 3
    バケットのストレージ クラスを Archive に変更する。
  • 4
    オブジェクトのバージョニングを有効にする。

解説

【正解】B

【0からの解説】
①前提知識:Cloud Storage のバケットの保持ポリシー(retention policy)は、バケット内のすべてのオブジェクトについて「作成から指定期間が経過するまで削除・上書きできない」ようにする機能です。期間は秒・日・月・年単位で指定でき、ポリシーを設定するとバケット内の既存および新規のオブジェクトすべてに適用されます。さらに保持ポリシーをロック(バケットロック)すると、ポリシーの削除や期間の短縮もできなくなり、規制対応(WORM:Write Once Read Many)にも使えます。

②要件と制約語の整理:(a) 「すべてのデータ」が対象、(b) 「少なくとも 3 年間」保存されることを保証する。つまり個々のオブジェクトへの手作業ではなく、バケット全体に一律で最低保持期間を強制する仕組みが必要です。

③正解の理由:バケットに保持期間 3 年の保持ポリシーを設定すれば、すべてのオブジェクトが作成から 3 年経過するまで削除・置換できなくなり、要件を直接満たします。確実に変更できないようにする必要があれば、ポリシーをロックします。

【誤りの選択肢】
A:一時的な保持(temporary hold)はオブジェクト単位で設定するフラグで、解除するまで削除を防ぎますが、期間の概念がなく「3 年間」という最低保持期間を表現できません。すべてのオブジェクトに個別に設定・管理する必要もあり、調査や訴訟対応などで一時的に削除を止める用途向けです。
C:ストレージ クラスはデータの保存料金とアクセス料金の体系を決めるもので、Archive クラスは長期保存向けに保存料金が安い代わりに取り出し料金がかかり、最低保存期間 365 日の早期削除料金が設定されています。しかし早期削除料金は削除を「禁止」するものではなく、料金を払えばいつでも削除できるため、3 年間の保存を保証できません。
D:オブジェクトのバージョニングは、上書きや削除の際に以前の世代を非現行バージョンとして残す機能で、誤操作からの復元に役立ちます。しかし非現行バージョンも含めて削除は可能で、保存期間を強制する仕組みではないため、3 年間の保存を保証できません。

【参考】
バケットロック | Cloud Storage
保持ポリシーの使用とロック | Cloud Storage
この問題のページを開く →
問題 6ソリューションは可能な限りコストを最小限に抑える必要があります。データの準備と取り込み
問題
Amazon S3 から Google Cloud の Nearline の Cloud Storage バケットへの、毎週実行される既存の Storage Transfer Service 転送ジョブがあります。このジョブは毎週、比較的小さなファイルを大量に移動します。毎週転送するファイルの数が時間とともに増加したため、割り当てられた時間枠内で転送を完了できなくなるおそれがあります。このプロセスを置き換えて、合計転送時間を短縮する必要があります。ソリューションは可能な限りコストを最小限に抑える必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    包含(include)プレフィックスと除外(exclude)プレフィックスを使用して、並列の転送ジョブを作成する。
  • 2
    Google Cloud CLI を使用して転送ジョブを作成し、--custom-storage-class フラグで Standard ストレージ クラスを指定する。
  • 3
    Amazon S3 から Cloud Storage にデータを移行する、毎週スケジュールされたバッチ Dataflow ジョブを作成する。
  • 4
    Compute Engine インスタンス上の複数の転送エージェントを利用するエージェント ベースの転送ジョブを作成する。

解説

【正解】A

【0からの解説】
①前提知識:Storage Transfer Service(STS)は Amazon S3 などから Cloud Storage へデータを転送するマネージド サービスで、S3 からの転送はエージェント不要(エージェントレス)で実行できます。STS には「転送ジョブあたりの 1 秒あたりのクエリ数(QPS)」に上限があり、ファイル 1 つごとに一覧取得・読み取り・書き込みなどのリクエストが発生するため、比較的小さなファイルが大量にあるジョブでは、データ量ではなくこの QPS 上限が転送速度のボトルネックになります。公式ドキュメント(転送速度の改善)では、この場合は転送を複数のジョブに分割し、include / exclude プレフィックスで各ジョブが扱うファイルの範囲を分けることが推奨されています(例:先頭が a〜e のパスだけを含むジョブ、f〜j のジョブ…)。

②要件と制約語の整理:(a) S3 → Cloud Storage(Nearline)の週次ジョブ、(b) 小さなファイルが大量で数が増え続けている、(c) 合計転送時間を短縮したい、(d)「可能な限りコストを最小限に(minimize costs)」。

③正解の理由:プレフィックスでデータを分割した複数の転送ジョブを並列に実行すると、ジョブごとの QPS 上限が並行して使えるため、多数の小さなファイルの転送が速くなります。STS のマネージドな仕組みをそのまま使い、追加のコンピューティング リソース(VM や Dataflow ワーカー)を用意しないため、コストも最小限に抑えられます。

【誤りの選択肢】
B:保存先のストレージ クラスを Nearline から Standard に変えても、ファイルの転送速度(QPS のボトルネック)は改善しません。むしろ Standard はストレージ料金が Nearline より高く、データをあまり参照しない用途ならコスト増になります。転送時間短縮にもコスト最小化にもつながりません。
C:Dataflow で S3 から読み出して Cloud Storage に書き込むパイプラインを自作することは可能ですが、コードの開発・保守が必要で、ワーカー VM の料金も発生します。STS はファイル転送のために用意されたマネージド サービスであり、それを自前実装に置き換えるのは運用負荷とコストの両面で不利です。
D:エージェント ベースの転送は主にオンプレミスのファイル システムや S3 互換ストレージ向けの方式で、Amazon S3 からはエージェントレスで転送できます。わざわざ Compute Engine インスタンスを複数立ててエージェントを動かすと VM の料金や運用が増え、「コストを最小限に抑える」要件に反します。

【参考】
ソース オブジェクトを前方一致でフィルタする | Storage Transfer Service
Amazon S3 から Cloud Storage への転送 | Storage Transfer Service
この問題のページを開く →
問題 7パイプラインのパフォーマンスをモニタリングし、エラーが発生した場合にアラートを受け取る必要があります。データ パイプラインのオーケストレーション
問題
あなたは e コマース企業でデータを管理しています。Pub/Sub から注文データを処理し、Bigtable の商品情報でデータを拡充(エンリッチ)し、処理済みデータを分析用に BigQuery に書き込む Dataflow パイプラインがあります。パイプラインは継続的に稼働し、1 分間に数千件の注文を処理しています。パイプラインのパフォーマンスをモニタリングし、エラーが発生した場合にアラートを受け取る必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Logging を使用してパイプラインのログを表示し、エラーを確認する。ログ内の特定のキーワードに基づいてアラートを設定する。
  • 2
    Dataflow ジョブ モニタリング インターフェースを使用してパイプライン グラフを目視で確認し、エラーをチェックして、重大なエラーが発生したときの通知を構成する。
  • ✓
    Cloud Monitoring を使用して主要な指標を追跡する。指標がしきい値を超えたとき、またはエラーが発生したときに通知をトリガーするアラート ポリシーを Cloud Monitoring で作成する。
  • 4
    BigQuery を使用して Cloud Storage 内の処理済みデータを分析し、異常や不整合を特定する。異常や不整合が発生したときのスケジュールされたアラートを設定する。

解説

【正解】C

【0からの解説】
①前提知識:Dataflow は Apache Beam のパイプラインを実行するフルマネージドのデータ処理サービスで、ストリーミング処理にもバッチ処理にも使えます。Dataflow はジョブの指標(システム レイテンシ、データの鮮度(data freshness)、バックログ、スループット、エラー数、CPU 使用率など)を自動的に Cloud Monitoring に送信します。Cloud Monitoring は Google Cloud の指標を収集・可視化し、「アラート ポリシー」で条件(しきい値など)を定義すると、条件を満たしたときにメール・SMS・Slack・PagerDuty・Pub/Sub などの通知チャネルへ自動的に通知できます。

②要件と制約語の整理:(a) 継続稼働のストリーミング パイプライン(1 分間に数千件)、(b)「パフォーマンス」をモニタリングする、(c) エラー発生時に「アラート」を受け取る。つまり性能指標の継続的な追跡と、自動通知の両方が必要です。

③正解の理由:Cloud Monitoring で Dataflow のジョブ指標(システム レイテンシ、データの鮮度、バックログ、要素数、エラーなど)を追跡し、しきい値やエラー条件に基づくアラート ポリシーを作成すれば、パフォーマンスの劣化とエラーの両方を自動的に検知して通知できます。人手による監視が不要で、Google が推奨する標準的な運用監視のやり方です。

【誤りの選択肢】
A:Cloud Logging のログ ベースのアラートでエラー文字列を検知することはできますが、ログのキーワードだけではレイテンシやスループット、バックログといった「パフォーマンス」を継続的に追跡できません。要件の半分(性能監視)を満たさず、キーワードの漏れによる検知漏れも起こりやすい方法です。
B:Dataflow ジョブ モニタリング インターフェースはジョブ グラフや指標を確認できる便利な画面ですが、「目視で確認する」ことが前提で、24 時間継続稼働するパイプラインを人が見張り続けるのは現実的ではありません。アラートはこの画面から Cloud Monitoring のアラート ポリシーを作成する形で実現されるものであり、通知の仕組みの本体は Cloud Monitoring です。
D:処理済みデータを事後に分析してデータの異常を見つける方法で、パイプラインの性能やエラーをリアルタイムに監視するものではありません。また、このパイプラインの出力先は BigQuery であり、Cloud Storage 内の処理済みデータを分析するという前提自体が問題文と一致しません。

【参考】
Dataflow ジョブの指標
Dataflow ジョブ モニタリング インターフェースを使用する
この問題のページを開く →
問題 8各日の予算と実際のコストの差額を計算するソリューションを作成する必要があります。データの分析と提示
問題
あなたのチームは、毎日更新される予算データを Google スプレッドシートで管理しています。チームは予算データを、BigQuery テーブルに保存されている実際のコスト データと比較したいと考えています。各日の予算と実際のコストの差額を計算するソリューションを作成する必要があります。チームが Google スプレッドシートで毎日更新される結果にアクセスできるようにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    予算データを CSV ファイルとしてダウンロードし、その CSV ファイルを Cloud Storage バケットにアップロードする。Cloud Storage から新しい BigQuery テーブルを作成し、実際のコストのテーブルと結合する。結合した BigQuery テーブルを Connected Sheets(コネクテッド シート)で開く。
  • ✓
    Google スプレッドシートのドライブ URI を使用して BigQuery 外部テーブルを作成し、実際のコストのテーブルと結合する。結合したテーブルを保存し、Connected Sheets(コネクテッド シート)で開く。
  • 3
    予算データを CSV ファイルとしてダウンロードし、その CSV ファイルをアップロードして新しい BigQuery テーブルを作成する。実際のコストのテーブルを新しい BigQuery テーブルと結合し、結果を CSV ファイルとして保存する。その CSV ファイルを Google スプレッドシートで開く。
  • 4
    Google スプレッドシートのドライブ URI を使用して BigQuery 外部テーブルを作成し、実際のコストのテーブルと結合する。結合したテーブルを CSV ファイルとして保存し、そのファイルを Google スプレッドシートで開く。

解説

【正解】B

【0からの解説】
①前提知識:
・BigQuery の外部テーブルは、データを BigQuery に取り込まずに、外部のデータソースを直接クエリできるテーブルです。Google ドライブ上の Google スプレッドシートもソースにでき、スプレッドシートの URI を指定して作成します。クエリのたびに最新のスプレッドシートの内容が読み込まれるため、スプレッドシートが毎日更新されても、手作業でデータを移す必要がありません。
・Connected Sheets(コネクテッド シート)は、Google スプレッドシートから BigQuery のデータに直接接続し、ピボット テーブル・グラフ・数式などで分析できる機能です。データの更新を手動または定期的なスケジュールで行えるため、BigQuery 側の最新の結果をスプレッドシート上で参照し続けられます。

②要件と制約語の整理:(a) 予算データは Google スプレッドシートで毎日更新される、(b) 実際のコストは BigQuery テーブル、(c) 日ごとの差額を計算する、(d) チームが Google スプレッドシートで「毎日更新される結果」にアクセスできる。

③正解の理由:スプレッドシートを外部テーブルとして BigQuery から参照すれば、予算データの最新版を手作業なしで実コストのテーブルと結合できます。その結果を Connected Sheets でスプレッドシートから開けば、チームは使い慣れた Google スプレッドシート上で BigQuery の結果を参照し、更新(スケジュール更新)によって毎日の最新結果を得られます。なお実務では、結合結果を「ビュー」として保存するか、スケジュールされたクエリで結合テーブルを毎日再作成すると、外部テーブルの最新データが確実に反映されます。手作業のエクスポートが一切ない点で、選択肢の中では B が要件に最も適しています。

【誤りの選択肢】
A:毎日 CSV をダウンロードして Cloud Storage にアップロードし、BigQuery テーブルを作り直すという手作業が必要で、予算データが毎日更新されるたびにこの作業を繰り返さなければなりません。外部テーブルを使えば不要な余計なデータ移動と手作業があり、「毎日更新される結果」を自動で提供できません。
C:CSV のダウンロード・アップロードという手作業に加えて、結合結果も CSV として保存しスプレッドシートで開くため、どちらの段階でも日次の自動更新ができません。毎日すべてを手で繰り返す必要があり、要件を満たしません。
D:外部テーブルによる結合までは適切ですが、結果を CSV ファイルとして保存して開くと、その時点の静的なコピーになり、BigQuery の結果が更新されてもスプレッドシートには反映されません。毎日 CSV を出力し直す手作業が必要になり、Connected Sheets のように最新結果へ接続し続けることができません。

【参考】
Google ドライブの外部テーブルを作成する
コネクテッド シートの使用
この問題のページを開く →
問題 9データ管理データ管理
問題
あなたは BigQuery に市場動向の厳選されたデータセットを作成しており、これを複数の外部パートナーと共有したいと考えています。各パートナーがアクセスできる行と列を制御したいと考えています。Google が推奨するプラクティスに従いたいと考えています。どうすればよいですか。

選択肢と解説

  • ✓
    データセットを Analytics Hub で公開する。サブスクリプションを使用して、各パートナーにデータセット レベルのアクセス権を付与する。
  • 2
    IAM ロールを使用して、各パートナーに BigQuery データセットへの読み取りアクセス権を付与する。
  • 3
    パートナーごとに個別の Cloud Storage バケットを作成する。データセットを各バケットにエクスポートし、各パートナーをそれぞれのバケットに割り当てる。IAM ロールを使用してバケットレベルのアクセス権を付与する。
  • 4
    パートナーごとに個別のプロジェクトを作成し、データセットを各プロジェクトにコピーする。各データセットを Analytics Hub で公開する。サブスクリプションを使用して、各パートナーにデータセット レベルのアクセス権を付与する。

解説

【正解】A

【0からの解説】
①前提知識:Analytics Hub(現在のドキュメントでは BigQuery sharing とも呼ばれます)は、BigQuery のデータを組織の内外と安全に共有するためのサービスです。パブリッシャー(共有する側)は共有データセットを「リスティング」としてデータ エクスチェンジに公開し、サブスクライバー(受け取る側)がリスティングをサブスクライブすると、自分のプロジェクトに読み取り専用の「リンクされたデータセット」が作成されます。データはコピーされないため、常に最新のデータを参照でき、ストレージの二重管理も発生しません。公式ドキュメントには、共有データセットは列レベルのセキュリティと行レベルのセキュリティをサポートすると記載されており、承認済みビューの共有や、エクスポート・コピーを禁止するデータ流出(エグレス)制御も設定できます。サブスクリプションの状況はパブリッシャー側で把握・取り消しできます。
②要件の整理:「複数の外部パートナーと共有」「パートナーごとにアクセスできる行と列を制御」「Google 推奨のプラクティス」です。
③正解の理由:A の Analytics Hub での公開とサブスクリプションによるアクセス付与は、外部組織とのデータ共有のために Google が提供・推奨する仕組みです。共有データセットに行レベルのアクセス ポリシーや列レベルのセキュリティ(ポリシータグ、データ マスキング)を設定することで、データをコピーせずにパートナーごとに見える行と列を制御できます。

【誤りの選択肢】
B:データセットへの読み取りロールを付与するだけでは、データセット内のすべてのテーブルのすべての行と列が見えてしまい、パートナーごとの制御ができません。また外部組織のユーザーに直接 IAM を付与していく方法は、利用状況の管理や取り消しの面でも Analytics Hub より劣ります。
C:Cloud Storage へのエクスポートはデータのコピーを作成するため、データが古くなる、ストレージ費用が増える、パートナーごとにエクスポート処理を管理する必要がある、といった問題があります。BigQuery 上での分析もできなくなり、行・列単位のきめ細かな制御も実現しにくい方法です。
D:パートナーごとにプロジェクトとデータセットのコピーを作る方法は、データの重複・同期の手間・費用が増えるうえ、Analytics Hub の「コピーせずに共有できる」という利点を打ち消してしまいます。行と列の制御は 1 つの共有データセットに行・列レベルのセキュリティを設定すれば実現できるため、不要な運用負荷です。

【参考】
BigQuery Sharing の概要
定期購入を管理
リスティングを管理する
この問題のページを開く →
問題 10インターネットの帯域幅は 100 Mbps で、転送はできるだけ早く完了する必要があります。データの準備と取り込み
問題
会社のオンプレミスのデータセンターから Cloud Storage に、約 300 TB のデータを転送する必要があります。インターネットの帯域幅は 100 Mbps で、転送はできるだけ早く完了する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud クライアント ライブラリを使用して、インターネット経由でデータを転送する。
  • 2
    データを圧縮して複数のクラウド ストレージ プロバイダにアップロードし、その後データを Cloud Storage に転送する。
  • ✓
    Transfer Appliance をリクエストし、データをアプライアンスにコピーして Google に返送する。
  • 4
    gcloud storage コマンドを使用して、インターネット経由でデータを転送する。

解説

【正解】C

【0からの解説】
①前提知識:Transfer Appliance は、Google が貸し出す大容量の物理ストレージ デバイスです。自社のデータセンターでデバイスにデータをコピーし、Google に配送すると、Google がそのデータを Cloud Storage にアップロードします。ネットワーク帯域に依存しない「オフライン転送」で、データ量が大きく帯域が細い場合に推奨されます。データはデバイス上で暗号化されて輸送されます。

②要件と制約語の整理:(a) 約 300 TB、(b) インターネット帯域は 100 Mbps、(c)「できるだけ早く(as quickly as possible)」。まず所要時間を計算します。300 TB = 300 × 10^12 バイト = 2.4 × 10^15 ビット。100 Mbps(10^8 ビット/秒)で割ると 2.4 × 10^7 秒 ≒ 約 278 日(約 9 か月)かかります。しかもこれは帯域を 100% 使い続けた理想値で、実際にはさらに長くなります。

③正解の理由:Transfer Appliance なら、デバイスへのコピーと配送・取り込みを含めても通常は数週間程度で Cloud Storage にデータを届けられ、インターネット経由の約 9 か月以上と比べて大幅に早く完了します。Google の転送オプションの指針でも、帯域に対してデータ量が大きく、オンライン転送に長期間かかる場合は Transfer Appliance を検討するよう推奨されています。

【誤りの選択肢】
A:Cloud クライアント ライブラリでもアップロードは可能ですが、ボトルネックは 100 Mbps の回線そのものなので、どのツールを使っても約 9 か月以上かかります。加えて大量ファイルの再試行や並列化を自分で実装する必要があり、「できるだけ早く」の要件を満たしません。
B:一度ほかのクラウド ストレージ プロバイダにアップロードしても、そこへの転送も同じ 100 Mbps の回線を通るため速くなりません。さらに他社クラウドのストレージ料金や下り(egress)料金が余計に発生し、手順も複雑になるだけです。
D:gcloud storage コマンドは並列転送などに対応した便利なツールですが、A と同様に 100 Mbps の帯域が上限であり、約 300 TB の転送には 9 か月以上かかります。オンライン転送では「できるだけ早く」を満たせません。

【参考】
Transfer Appliance
データ転送オプション | Storage Transfer Service
この問題のページを開く →
問題 11データ パイプラインのオーケストレーションデータ パイプラインのオーケストレーション
問題
あなたはヘルスケア企業で働いています。レガシー システムから患者データを抽出し、変換して、分析用に BigQuery に読み込む日次の ETL パイプラインがあります。このパイプラインは現在、シェル スクリプトを使用して手動で実行されています。このプロセスを自動化し、パイプラインの可観測性とトラブルシューティングのための分析情報を確保するモニタリングを追加したいと考えています。ETL コードを書き直すことなく、オープンソースのツールを使用した 1 つの一元化されたソリューションを求めています。どうすればよいですか。

選択肢と解説

  • 1
    パイプラインを毎日実行する Cloud Run 関数を作成する。Cloud Monitoring を使用して関数の実行をモニタリングする。
  • 2
    Cloud Dataflow を構成して ETL パイプラインを実装し、Cloud Scheduler を使用して Dataflow パイプラインを毎日トリガーする。Dataflow ジョブ モニタリング インターフェースと Cloud Monitoring を使用してパイプラインの実行をモニタリングする。
  • 3
    Cloud Scheduler を使用して Dataproc ジョブをトリガーし、パイプラインを毎日実行する。Dataproc ジョブの Web インターフェースと Cloud Monitoring を使用してジョブの進行状況をモニタリングする。
  • ✓
    Cloud Composer で有向非巡回グラフ(DAG)を作成し、パイプラインのトリガーを毎日オーケストレーションする。Apache Airflow の Web インターフェースと Cloud Monitoring を使用してパイプラインの実行をモニタリングする。

解説

【正解】D

【0からの解説】
①前提知識:Cloud Composer(現 Managed Service for Apache Airflow)は、オープンソースのワークフロー オーケストレーション ツール Apache Airflow をフルマネージドで提供するサービスです。Airflow では処理の流れを DAG(有向非巡回グラフ)として Python で定義し、スケジュール実行・依存関係の管理・失敗時の再試行・通知を一元的に行えます。BashOperator を使えば既存のシェル スクリプトをそのままタスクとして実行でき、Airflow の Web インターフェース(UI)でタスクごとの実行状況・所要時間・ログを確認できます。さらに Cloud Composer の環境は指標やログを Cloud Monitoring / Cloud Logging に送信するため、アラート設定も可能です。

②要件と制約語の整理:(a) 日次の手動実行(シェル スクリプト)を自動化、(b) 可観測性とトラブルシューティングのためのモニタリング、(c)「1 つの一元化されたソリューション」、(d)「オープンソースのツールを使用」、(e)「ETL コードを書き直さない」。

③正解の理由:Cloud Composer の DAG で既存スクリプトを(BashOperator などで)毎日実行すれば、コードを書き直さずに自動化できます。スケジューリング・再試行・依存関係・実行履歴・ログが Airflow に一元化され、Airflow UI と Cloud Monitoring で可観測性とトラブルシューティングの情報も得られます。Airflow はオープンソースなので、すべての条件を満たすのは D です。

【誤りの選択肢】
A:Cloud Run 関数(旧 Cloud Functions)は短時間のイベント駆動処理向けで、実行時間の上限があり、長時間かかる ETL やシェル スクリプトの実行には向きません。また毎日の起動には別途 Cloud Scheduler が必要で、タスク単位の依存関係・再試行・実行履歴を一元管理するオーケストレーション機能もありません。オープンソースのツールを使うという条件も満たしません。
B:Dataflow でパイプラインを「実装する」ということは、既存の ETL を Apache Beam のコードとして書き直すことを意味し、「ETL コードを書き直さない」という条件に反します。さらにスケジュールは Cloud Scheduler、監視は Dataflow の UI と複数のサービスに分かれ、一元化されていません。
C:Dataproc(現 Managed Service for Apache Spark)は Spark / Hadoop の処理基盤で、シェル スクリプトの ETL をそのまま実行する用途ではなく、Spark ジョブとして作り直す必要が生じます。スケジューラ(Cloud Scheduler)と実行基盤(Dataproc)が分かれ、パイプライン全体の再試行や依存関係を一元管理する仕組みもありません。

【参考】
Managed Airflow の概要 | Managed Service for Apache Airflow
Airflow DAG のスケジュール設定とトリガー | Managed Service for Apache Airflow
この問題のページを開く →
問題 12データ管理データ管理
問題
あなたは Cloud Storage で、未加工データ、処理済みデータ、バックアップを含む大量のデータを管理しています。あなたの組織は、特定の種類のデータに対してデータの不変性(変更できないこと)を義務付ける厳格なコンプライアンス規制の対象となっています。保持要件を満たすストレージ戦略を確保しつつ、効率的なプロセスでストレージ コストを削減したいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    アクセス パターンに基づいてオブジェクトを適切なストレージ クラスに移行するライフサイクル管理ルールを構成する。不変性の要件を満たすために、すべてのオブジェクトに対してオブジェクトのバージョニングを設定する。
  • 2
    経過期間とアクセス パターンに基づいて、オブジェクトを異なるストレージ クラスに移動する。不変性の要件を満たすために、Cloud Key Management Service(Cloud KMS)を使用して、特定のオブジェクトを顧客管理の暗号鍵(CMEK)で暗号化する。
  • 3
    Cloud Run 関数を作成してオブジェクトのメタデータを定期的にチェックし、経過期間とアクセス パターンに基づいてオブジェクトを適切なストレージ クラスに移動する。オブジェクト ホールドを使用して、特定のオブジェクトに不変性を強制する。
  • ✓
    オブジェクト ホールドを使用して特定のオブジェクトに不変性を強制し、経過期間とアクセス パターンに基づいてオブジェクトを適切なストレージ クラスに移行するライフサイクル管理ルールを構成する。

解説

【正解】D

【0からの解説】
①前提知識:Cloud Storage には、データ保持やコスト最適化のための機能がいくつかあります。オブジェクト ホールドは、個々のオブジェクトに設定するフラグで、ホールドが付いている間はそのオブジェクトを削除・置換できなくなります(イベントベース ホールドと一時ホールドの 2 種類)。バケット単位で最低保持期間を強制する「保持ポリシー(バケットロック)」や、オブジェクト単位の保持期間を設定する「オブジェクト保持ロック」もあり、いずれも不変性(WORM:一度書き込んだら変更できない)の要件に対応する機能です。一方、オブジェクトのライフサイクル管理は、経過日数などの条件に応じてオブジェクトのストレージ クラスを自動的に変更(Standard → Nearline → Coldline → Archive など)したり削除したりするルールで、手作業やコードなしでストレージ コストを削減できます。
②要件の整理:「特定の種類のデータに不変性を強制(コンプライアンス)」「保持要件を満たす」「効率的なプロセスでストレージ コストを削減(=自動化・マネージド機能の活用)」です。
③正解の理由:D は、特定のオブジェクトにオブジェクト ホールドを設定して削除・上書きを防ぎ(不変性)、ライフサイクル管理ルールでストレージ クラスを自動的に移行してコストを削減します。どちらも Cloud Storage の組み込み機能で、コードや手作業を必要としない効率的な方法です。

【誤りの選択肢】
A:オブジェクトのバージョニングは、上書きや削除された古い世代を保持して誤操作から復元できるようにする機能ですが、オブジェクト自体の削除や新しい世代での置き換えを禁止するものではなく、ユーザーが古い世代を削除することもできます。不変性の要件は満たせません。また、すべてのオブジェクトの旧世代を保持するためストレージ コストも増加します。
B:CMEK による暗号化は、暗号鍵を顧客が管理するためのセキュリティ機能で、データを変更や削除から守る不変性とは無関係です。また「オブジェクトを移動する」とだけあり、ライフサイクル ルールによる自動化が含まれていないため、効率的なプロセスとも言えません。
C:オブジェクト ホールドで不変性を確保する点は正しいですが、ストレージ クラスの移行に Cloud Run 関数を自作して定期実行する必要はありません。ライフサイクル管理ルールという組み込み機能で同じことを実現できるため、コードの開発・保守という余計な運用負荷がかかり、「効率的なプロセス」という要件に劣ります。

【参考】
オブジェクト保留 | Cloud Storage
オブジェクトのライフサイクル管理 | Cloud Storage
ストレージ クラス | Cloud Storage
この問題のページを開く →
問題 13季節性と過去のデータを考慮して商品需要を予測する、スケーラブルなソリューションを作成する必要があります。データの分析と提示
問題
あなたは多種多様な商品を扱う e コマース ウェブサイトを管理しています。顧客のニーズを満たし在庫切れを避けるのに十分な在庫を確保するため、将来の商品需要を正確に予測する必要があります。会社の過去の販売データは BigQuery テーブルに保存されています。季節性と過去のデータを考慮して商品需要を予測する、スケーラブルなソリューションを作成する必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    過去の販売データを使用して BigQuery ML の時系列モデルをトレーニングして作成する。ML.FORECAST 関数の呼び出しを使用して、予測結果を新しい BigQuery テーブルに出力する。
  • 2
    Colab Enterprise を使用して Jupyter ノートブックを作成する。過去の販売データを使用して、Python でカスタムの予測モデルをトレーニングする。
  • 3
    過去の販売データを使用して BigQuery ML の線形回帰モデルをトレーニングして作成する。ML.PREDICT 関数の呼び出しを使用して、予測結果を新しい BigQuery テーブルに出力する。
  • 4
    過去の販売データを使用して BigQuery ML のロジスティック回帰モデルをトレーニングして作成する。ML.PREDICT 関数の呼び出しを使用して、予測結果を新しい BigQuery テーブルに出力する。

解説

【正解】A

【0からの解説】
①前提知識:BigQuery ML は、BigQuery 上で SQL(CREATE MODEL 文)だけを使って機械学習モデルを作成・トレーニング・推論できる機能です。データを BigQuery の外に移動する必要がなく、BigQuery のサーバーレスな処理基盤の上で動くため、大量のデータでもスケールします。BigQuery ML には時系列予測専用のモデル(model_type = 'ARIMA_PLUS' や 'ARIMA_PLUS_XREG'。最近は事前学習済みの TimesFM モデルも利用可能)があり、トレンド・季節性(日次・週次・年次など)・祝日効果・異常値などを自動で検出してモデルに反映します。時系列モデルの予測値は ML.FORECAST 関数で、指定した期間(horizon)だけ未来の値として取得でき、信頼区間も同時に出力されます。また、time_series_id_col を指定すると、商品ごとに別々の時系列を 1 つの CREATE MODEL 文でまとめて学習できるため、「多種多様な商品」の需要予測に向いています。
②要件の整理:「将来の需要を予測(=時間軸に沿った未来の値の予測)」「季節性と過去のデータを考慮」「スケーラブル」「データは既に BigQuery にある」の 4 点です。
③正解の理由:A の BigQuery ML の時系列モデルは、季節性を自動で分解・モデル化する時系列予測専用の手法で、データを移動せずに SQL だけで構築でき、ML.FORECAST で将来の予測値を新しいテーブルに書き出せます。すべての要件を最小の労力で満たす、Google が推奨する方法です。

【誤りの選択肢】
B:Colab Enterprise のノートブックで Python のカスタムモデルを作ることは技術的には可能ですが、データの読み出し、季節性を扱う特徴量の設計、モデル実装、スケーリングをすべて自前で行う必要があり、労力と運用負荷が大きくなります。BigQuery ML に時系列予測モデルが用意されている以上、最適な選択ではありません。
C:線形回帰は数値を予測するモデルですが、時系列データの自己相関や季節性、トレンドの変化を自動では扱いません。季節性を反映させるには月や曜日などの特徴量を自分で設計する必要があり、また ML.PREDICT は入力行に対する予測であって、未来の期間を指定して予測値を生成する ML.FORECAST のような時系列予測にはなりません。
D:ロジスティック回帰は「購入する/しない」のようなカテゴリ(クラス)を予測する分類モデルです。需要量という連続的な数値を予測する用途には適しておらず、季節性も考慮しません。

【参考】
予測の概要
時系列予測モデルのエンドツーエンドのユーザー ジャーニー
BigQuery の ML の概要
この問題のページを開く →
問題 14分析のために、このデータを変換して BigQuery に読み込む必要があります。データの準備と取り込み
問題
あなたは日次のソーシャル メディア データを分析する必要があるプロジェクトに取り組んでいます。Cloud Storage に保存された 100 GB の JSON 形式のデータがあり、このデータは増え続けています。分析のために、このデータを変換して BigQuery に読み込む必要があります。Google が推奨するアプローチに従いたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Data Fusion を使用してデータを BigQuery の未加工(raw)テーブルに転送し、SQL を使用して変換する。
  • ✓
    Dataflow を使用してデータを変換し、変換したデータを BigQuery に書き込む。
  • 3
    Cloud Storage からデータを手動でダウンロードする。Python スクリプトを使用してデータを変換し、BigQuery にアップロードする。
  • 4
    Cloud Run functions を使用してデータを変換し、BigQuery に読み込む。

解説

【正解】B

【0からの解説】
①前提知識:Dataflow は Apache Beam をベースにしたフルマネージドのデータ処理サービスで、バッチ処理とストリーミング処理の両方に対応し、データ量に応じてワーカーを自動でスケール(オートスケーリング)します。Cloud Storage からの読み込み、JSON の解析・整形・フィルタなどの変換、BigQuery への書き込みを 1 つのパイプラインで実行でき、Google 提供のテンプレート(例: Cloud Storage Text to BigQuery。UDF で変換を追加可能)も用意されています。Cloud Data Fusion はノーコードの GUI で ETL パイプラインを構築するサービス、Cloud Run functions(旧 Cloud Functions)はイベントをきっかけに短時間の処理を実行するサーバーレス関数です。
②要件の整理:「100 GB 規模の JSON データ」「増え続ける(スケーラビリティが必要)」「変換して BigQuery に読み込む」「Google 推奨のアプローチ」です。
③正解の理由:Dataflow はデータ量の増加に合わせて自動でスケールする分散処理基盤で、変換と BigQuery への書き込みを 1 つのマネージドなパイプラインで完結できます。大量かつ増え続けるデータの変換・読み込み(ETL)として、Google が推奨する代表的な構成です。

【誤りの選択肢】
A:Cloud Data Fusion で未加工テーブルに取り込んでから SQL で変換する ELT 構成も動作はしますが、単にデータを BigQuery に移すだけの用途に Cloud Data Fusion のインスタンス(常時稼働で費用がかかる)を用意するのは過剰で、変換処理も別途 SQL ジョブとして管理する必要があります。変換と読み込みを 1 つのスケーラブルなパイプラインで行える Dataflow と比べて構成が冗長です。
C:手動でダウンロードしてローカルの Python スクリプトで処理する方法は、増え続ける 100 GB 超のデータに対してスケールせず、自動化もされず、ダウンロードによる余計なデータ移動やセキュリティ上のリスクも生じます。Google 推奨のアプローチではありません。
D:Cloud Run functions は短時間で終わる軽量なイベント処理向けで、実行時間やメモリに上限があります。100 GB 規模で増え続けるデータの一括変換のような大規模なデータ処理には向いておらず、分散処理やリトライの仕組みも自前で作り込む必要があります。

【参考】
Dataflow の概要
Google 提供のテンプレート | Cloud Dataflow
Cloud Storage からの JSON データの読み込み
この問題のページを開く →
問題 15Google が推奨するアプローチに従いながら、低レイテンシと高スループットを確保するパイプラインを設計する必要がありま…データ パイプラインのオーケストレーション
問題
あなたはリアルタイムのプレーヤー アクティビティ データを収集するゲーム会社で働いています。このデータは Pub/Sub にストリーミングされ、分析のために処理して BigQuery に読み込む必要があります。処理には、パーティション分割された BigQuery テーブルに読み込む前のデータのフィルタリング、エンリッチメント(情報の付加)、集計が含まれます。Google が推奨するアプローチに従いながら、低レイテンシと高スループットを確保するパイプラインを設計する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud Composer を使用して、Pub/Sub からデータを読み取り、Python スクリプトでデータを処理し、BigQuery に書き込むワークフローをオーケストレートする。
  • ✓
    Dataflow を使用して、Pub/Sub からデータを読み取り、データを処理し、ストリーミング API を使用して BigQuery に書き込むストリーミング パイプラインを作成する。
  • 3
    Dataproc を使用して、Pub/Sub からデータを読み取り、データを処理し、BigQuery に書き込む Apache Spark ストリーミング ジョブを作成する。
  • 4
    Cloud Run functions を使用して Pub/Sub トピックをサブスクライブし、データを処理し、ストリーミング API を使用して BigQuery に書き込む。

解説

【正解】B

【0からの解説】
①前提知識:Pub/Sub はメッセージを非同期にやり取りするフルマネージドのメッセージング サービスで、リアルタイムのイベント データの受け口としてよく使われます。Dataflow(Apache Beam ベースのフルマネージド データ処理サービス)はストリーミング処理に対応しており、Pub/Sub からの読み取り、フィルタリング・エンリッチメント(他データとの結合など)・ウィンドウ集計といった変換、BigQuery への書き込み(Storage Write API などのストリーミング書き込み)を 1 つのパイプラインで実行できます。オートスケーリング、1 回限りの処理(exactly-once)、遅延データの扱いなどの仕組みを備えています。「Pub/Sub → Dataflow → BigQuery」は Google がストリーミング分析の参照構成として推奨する組み合わせです。
②要件の整理:「リアルタイムのストリーミング データ(Pub/Sub)」「フィルタリング・エンリッチメント・集計という変換が必要」「パーティション分割テーブルへの読み込み」「低レイテンシかつ高スループット」「Google 推奨」です。
③正解の理由:Dataflow のストリーミング パイプラインは、変換を含む継続的な処理を低レイテンシで行い、データ量に応じて自動でスケールするため高スループットにも対応できます。サーバー管理も不要で、すべての要件を満たします。なお、変換が不要で Pub/Sub のメッセージをそのまま BigQuery に入れるだけなら BigQuery サブスクリプションも選択肢になりますが、本問のように集計やエンリッチメントが必要な場合は Dataflow が適しています。

【誤りの選択肢】
A:Cloud Composer(現 Managed Service for Apache Airflow)はワークフローのスケジュール実行とオーケストレーション(タスクの順序制御)のためのサービスで、それ自体はストリーミング データを継続的に処理するエンジンではありません。DAG をバッチ的に定期実行する形になるため、低レイテンシの要件を満たせません。
C:Dataproc(現 Managed Service for Apache Spark)の Spark Streaming でも同様の処理は実装できますが、クラスタの作成・サイジング・スケーリング・運用を自分で管理する必要があります。既存の Spark 資産の移行などの理由がない限り、フルマネージドでサーバーレスな Dataflow のほうが Google 推奨の構成です。
D:Cloud Run functions(旧 Cloud Functions)はメッセージ単位でのシンプルな処理には使えますが、複数のメッセージにまたがる集計(ウィンドウ処理)や状態の保持、高スループット時の効率的なバッチ書き込みが苦手で、同時実行数やタイムアウトの制約もあります。集計を含む大量のストリーミング処理には適しません。

【参考】
Pub/Sub から Dataflow に読み取る
ストリーミング パイプライン | Cloud Dataflow
Pub/Sub を BigQuery で使用する
この問題のページを開く →

GCP-ADP 模擬問題集についてよくある質問

GCP-ADP の練習問題は無料で試せますか?

はい。GCP-ADP は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン(月額 ¥980)または Pro プラン(月額 ¥4,980)でご利用ください。

問題は何問ありますか?

GCP-ADP は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか?

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン(出題分野)別の正答率も受験後に確認できます。