表示モード
画像位置
文字位置
理解度の自動記録
Q1Google Associate Data Practitioner
Q1. あなたはBigQuery上に市場トレンドを整理したキュレーション済みデータセットを準備し、複数の社外パートナーへ共有しようとしています。
パートナーごとにアクセスできる行と列を制御したいと考えています。
Googleの推奨プラクティスに沿って実装したいと考えています。
どのように対応すればよいですか。
解答を見る
正解：A. Analytics Hubでデータセットをリスティングとして公開する。サブスクリプション機能を使って各パートナーにデータセット単位のアクセス権を付与する。
Analytics Hubは、外部パートナーとデータを共有しながら提供側がアクセス制御を維持できるサービスです。サブスクリプション経由で配信すれば、データをコピーさせずクエリ実行のみを許可でき、共有範囲を細かく管理できます。
Bは、Cloud Storageはファイル保管が目的で、BigQueryデータセットの共有手段としては適していません。
Cは、IAMロールだけでは行・列単位の細かな制御はできません。
Dは、パートナーごとにプロジェクトを作りコピーする方式は手間が大きく拡張性に欠けます。
よって、Analytics Hubによる共有が最適です。
Analytics Hub の概要 | BigQuery
Q2Google Associate Data Practitioner
Q2. 自分の手元にあるデータを用いて、組織の経営陣にBigQueryの機能をデモしようとしています。
ローカルマシンに保存されたファイルを、できる限り少ない手間で一度だけBigQueryへ読み込む必要があります。
どのように対応すればよいですか。
解答を見る
正解：C. ローカルマシン上で bq load コマンドを実行する。
一度きりの読み込みを最小限の手間で済ませるには、すぐに使えるツールが適しています。bq loadコマンドはGoogle Cloud SDKに含まれるCLIツールで、ローカルのCSVやJSONファイルを一つのコマンドでBigQueryへ直接アップロードできます。
追加のコーディングが不要で、既存のSDKをそのまま活用できます。
Aは、Storage Write APIを使うPythonスクリプトには認証やライブラリ設定、デバッグが必要で過剰です。
Bは、Dataprocクラスタの作成やファイル転送が伴い複雑すぎます。
Dは、Dataflowジョブの構築も一度きりの読み込みには手間がかかりすぎます。
bq コマンドライン ツールの使用 | BigQuery
Q3Google Associate Data Practitioner
Q3. チームがBigQuery上の大規模データセットを分析し、ユーザー行動の傾向を把握する必要があります。
分析には高度な統計計算、Pythonパッケージ、可視化が伴います。
分析を開発・共有できるマネージドな共同作業環境を提案する必要があります。
何を推奨すべきですか。
解答を見る
正解：A. Colab Enterpriseノートブックを作成しBigQueryへ接続する。ノートブックをチームと共有し、Colab Enterprise上でデータ分析と可視化を行う。
BigQueryに接続したColab Enterpriseノートブックは、高度な統計計算やPythonパッケージ、可視化に適したマネージドな共同作業環境を提供します。高度な分析向けPythonライブラリをサポートし、大規模データへのクエリでBigQueryとシームレスに連携します。
チームでの共同開発と共有も容易で、可視化機能も備えています。
B・Cは可視化中心のツールで、複雑なPython計算には不向きです。
Dは、Connected Sheetsはスプレッドシート分析向けであり、高度な統計処理やカスタム可視化には適しません。
Colab Enterprise の概要 | Vertex AI
Q4Google Associate Data Practitioner
Q4. あなたは地域別の販売取引データをBigQueryテーブルで管理するデータベース管理者です。
各営業担当者が、自分が担当する地域の取引だけを閲覧できるようにする必要があります。
どのように対応すればよいですか。
解答を見る
正解：C. 行レベルアクセスポリシーを作成する。
行レベルアクセスポリシーは、担当地域などの条件に基づき行を絞り込み、ユーザーごとに閲覧できる行を制限できます。これにより別テーブルやビューを作らずに細かなアクセス制御が実現でき、最小権限の原則にも合致します。
Aは、IAM権限はデータセット単位の制御であり行レベルには対応しません。
Bのデータマスキングは列の値を隠す機能で、行の絞り込みには使えません。
Dのポリシータグは列レベルのアクセス制御に用いるものです。
よって行レベルアクセスポリシーが最適です。
行レベルのセキュリティの概要 | BigQuery
Q5Google Associate Data Practitioner
Q5. 組織はPub/Subに毎秒数千件届くイベントに対し、ニアリアルタイム分析を導入する必要があります。
受信するメッセージには変換処理が必要です。
開発期間を最小限に抑えつつ、データを処理・変換してBigQueryへ読み込むパイプラインを組む必要があります。
どのように対応すればよいですか。
解答を見る
正解：A. Googleが提供するDataflowテンプレートを利用してPub/Subメッセージを処理し、変換を行ったうえでBigQueryへ書き込む。
Googleが提供するDataflowテンプレートは、ストリーミングデータ処理向けにあらかじめ構築・最適化されており、最小限の開発でパイプラインを展開できます。Pub/Subからの取り込み、変換、BigQueryへの書き込みを一括で担い、スケーラビリティと低レイテンシを確保します。
Bは、Cloud Data Fusionの構築は開発期間の最小化という要件に対して手間がかかります。
Cは、Dataprocクラスタを介する方式は複雑でレイテンシも増えます。
Dは、Cloud Run関数は継続的なストリーム処理には不向きです。
Google 提供のテンプレート | Dataflow
Q6Google Associate Data Practitioner
Q6. Cloud Storage上で、生データ、加工済みデータ、バックアップを含む大量のデータを運用管理しています。
組織は特定のデータ種別についてデータの不変性を義務付ける厳格なコンプライアンス規制の対象になっています。
保持要件を満たしながら、効率的な方法でストレージコストを抑えたいと考えています。
どのように対応すればよいですか。
解答を見る
正解：D. 特定のオブジェクトにオブジェクトの保持を設定して不変性を強制し、経過期間とアクセスパターンに応じてオブジェクトを適切なストレージクラスへ移行するライフサイクル管理ルールを構成する。
オブジェクトの保持（オブジェクトホールド）はオブジェクトの削除や上書きを防いで不変性を確保し、ライフサイクル管理ルールは経過期間に応じて低コストのストレージクラスへ自動移行します。この組み合わせでコンプライアンス遵守とコスト削減を両立できます。
Aのバージョニングは不変性を保証しません。
BのCMEKは暗号化であり不変性の手段ではありません。
CはCloud Run関数による手動管理が不要な手間を生みます。
オブジェクトの保持 | Cloud Storage
Q7Google Associate Data Practitioner
Q7. Cloud Storageバケットに保存された機密性の高い顧客データを扱うデータパイプラインを構築しています。
単一ゾーンで障害が発生した場合でも、このデータへアクセスできる状態を維持する必要があります。
どのように対応すればよいですか。
解答を見る
正解：C. データをマルチリージョンバケットに保存する。
マルチリージョンバケットは複数のロケーションにデータを複製するため、単一ゾーンの障害が発生してもデータへのアクセスを維持できます。高い可用性と耐久性が求められる機密データに適しています。
Aは、Cloud CDNは配信性能の向上が目的で、元データの可用性は保護しません。
Bは、オブジェクトのバージョニングは上書きや削除に備える機能で、ゾーン障害時の可用性は確保しません。
Dは、Nearlineはストレージクラスの選択であり、ゾーン障害への冗長性とは無関係です。
バケットのロケーション | Cloud Storage
Q8Google Associate Data Practitioner
Q8. 組織はIoTのイベントデータをPub/Subトピックへ送信しています。
サブスクライバーアプリケーションはメッセージを読み取り、変換したうえでデータウェアハウスに保存します。
トピックへの書き込みが特に多い繁忙時間帯に、サブスクライバーアプリケーションが期限内にメッセージを確認応答（ack）できていないことが判明しました。
こうした負荷の急増に対応しつつメッセージ処理を継続できるよう、パイプラインを見直す必要があります。
どのように対応すればよいですか。
解答を見る
正解：B. サブスクライバー側でフロー制御を実装する。
サブスクライバー側でフロー制御を実装すると、メッセージを取得・処理する速度を調整でき、負荷急増時でもサブスクライバーが過負荷にならず期限内に確認応答できます。これにより繁忙時間帯でもパイプラインの安定性を保ち、メッセージを不必要に破棄・遅延させずに済みます。
Aの再試行のみでは過負荷は解消しません。
Cのデッドレタートピックは処理失敗の退避先で、スパイク対策ではありません。
Dのシークは再処理の手段で、急増への対応にはなりません。
フロー制御によるバックログの処理 | Pub/Sub
Q9Google Associate Data Practitioner
Q9. Cloud SQLデータベースへデータを保存するWebアプリケーションを運用しています。
プライマリデータベースインスタンスから読み取りトラフィックをオフロードし、アプリケーションの読み取り性能を高める必要があります。
手間とコストを最小限に抑えた形で実装したいと考えています。
どのように対応すればよいですか。
解答を見る
正解：D. 自動バックアップを有効にし、Cloud SQLインスタンスのリードレプリカを作成する。
リードレプリカを作成すると、プライマリインスタンスから読み取りトラフィックをオフロードでき、負荷を分散して読み取り性能を向上できます。Cloud SQL内で容易に実装でき、コスト効率にも優れます。
プライマリは書き込みに専念し、レプリカが読み取りクエリを処理するため、最小限の労力で性能を改善できます。
Aは、Cloud CDNは静的Webコンテンツ向けでデータベースには不適切です。
Bは、Memorystoreは追加のキャッシュ層で実装の手間が増えます。
Cの大型化はコストが高く、読み取り負荷の分散にはなりません。
レプリケーションについて | Cloud SQL
Q10Google Associate Data Practitioner
Q10. 組織は既存のエンタープライズデータウェアハウスをBigQueryへ移行することを決めました。
現在使用しているデータパイプラインツールは、すでにBigQuery向けのコネクタに対応しています。
移行のスピードを最適化するアプローチを見極める必要があります。
どのように対応すればよいですか。
解答を見る
正解：C. 既存のデータパイプラインツールのBigQueryコネクタを利用してデータマッピングを再構成する。
既存のツールがすでにBigQueryコネクタをサポートしているため、そのコネクタでデータマッピングを再構成するのが最も効率的です。現行ツールを活かすことで移行の複雑さとセットアップ時間を削減でき、移行速度を最適化できます。
追加サービスや中間ステップを介さず、データをBigQueryへ直接流し込めます。
A・Dは新たなサービスやパイプラインの再作成が必要で手間が増えます。
Bは、Cloud Data Fusionでの再構築は不要な複雑さを招きます。
データ ウェアハウスの移行の概要 | BigQuery