Google Cloud Platform Professional Data Engineer 試験 - 練習セット #02-2

25問 • 5ヶ月前

問題一覧

質問26：シナリオ:組織にはプロジェクト A とプロジェクト B という 2 つの Google Cloud プロジェクトがあります。プロジェクト A には、機密性の高いソースからデータを受信する Pub/Sub トピックがあります。このトピックのデータにアクセスできるのはプロジェクト A のリソースのみにする必要があります。プロジェクト B、そして将来のプロジェクトがプロジェクト A のトピックにアクセスできないようにする必要があります。質問：プロジェクト B や将来のプロジェクトからのアクセスを防ぎながら、プロジェクト A のリソースだけが Pub/Sub トピックにアクセスできるようにするにはどうすればよいでしょうか。

プロジェクト A の周囲に境界を持つ組織内で VPC Service Controls を構成します。

質問27：シナリオ：本番環境にStandard Tier Memorystore for Redisインスタンスをデプロイしています。災害復旧テストのために、本番環境データに影響を与えないようにRedisインスタンスのフェイルオーバーをシミュレートする必要があります。質問：実稼働データに影響を与えないようにしながら、Redis インスタンスのフェイルオーバーを正確にシミュレートするには、どうすればよいでしょうか。

開発環境でStandard Tier Memorystore for Redisインスタンスを作成します。force-data-lossデータ保護モードを使用して、手動フェイルオーバーを開始します。

質問28：シナリオ:顧客管理暗号鍵（CMEK）を使用する BigQuery データセットを管理しています。CMEK にアクセスできないパートナー組織とデータセットを共有する必要があります。質問：CMEK へのアクセス権がないパートナー組織とデータセットを共有するにはどうすればよいでしょうか。

共有する必要があるテーブルを CMEK のないデータセットにコピーします。このデータセットの Analytics Hub リストを作成します。

質問29：シナリオ：JdbcIO を使用して Cloud SQL インスタンスからデータを抽出する Apache Beam パイプラインを開発しています。パイプラインはプロジェクト A の Dataflow 上で実行され、Cloud SQL インスタンスはパブリック IP アドレスを持たないプロジェクト B にあります。デプロイ後、接続エラーによりパイプラインがデータを抽出できませんでした。VPC Service Controls と共有 VPC が使用されていないことを確認しました。データがパブリックインターネットを経由しないようにしながら、このエラーを解決したいと考えています。質問：データがパブリックインターネットを通過しないようにしながら接続の問題を解決するには、どうすればよいでしょうか?

プロジェクト A とプロジェクト B の間に VPC ネットワークピアリングを設定します。ピアリングされたサブネット上のプロジェクト B に外部 IP アドレスのない Compute Engine インスタンスを作成し、Cloud SQL データベースへのプロキシサーバーとして機能します。

質問30：シナリオ：リージョン1にCloud SQL for PostgreSQLインスタンスがあり、リージョン2とリージョン3にそれぞれリードレプリカが1つずつあります。リージョン1で予期せぬイベントが発生したため、リージョン2のリードレプリカを昇格させて障害復旧を行う必要があります。接続を切り替える前に、アプリケーションで同じデータベース容量が利用可能であることを確認する必要があります。質問：Region2 で読み取りレプリカを昇格した後、接続を切り替える前に、アプリケーションが同じデータベース容量を持つようにするには、どうすればよいですか。

新しいプライマリインスタンスから 2 つの新しい読み取りレプリカを作成します。1 つは Region3 に、もう 1 つは新しいリージョンに作成します。

質問31：シナリオ:Cloud Composer を使用して ETL パイプラインをオーケストレートします。Apache Airflow の有向非巡回グラフ（DAG）内の 1 つのタスクはサードパーティのサービスに依存しています。タスクが失敗した場合に通知を受け取りたいと考えています。質問：タスクが成功しなかった場合に通知を受け取るには、DAG 内のタスクの通知をどのように構成すればよいですか?

リスクのあるタスクを担当するオペレーターの on_failure_callback パラメータに通知ロジックを含む関数を割り当てます。

質問32：シナリオ：オンプレミスのデータウェアハウスをBigQueryに移行しています。上流のデータソースの一つは、オンプレミスのデータセンターでホストされているMySQLデータベースで、パブリックIPアドレスがありません。パブリックインターネットを使用せずに、BigQueryへの安全なデータ取り込みを実現したいと考えています。質問：パブリックインターネットを経由せずに、オンプレミスの MySQL データベースから BigQuery にデータを安全に取り込むには、どうすればよいでしょうか。

Datastream を使用して、オンプレミスの MySQL データベースから BigQuery にデータを複製します。オンプレミスのデータセンターと Google Cloud の間に Cloud Interconnect を設定します。接続方法としてプライベート接続を使用し、VPC ネットワーク内の IP アドレス範囲を Datastream の接続構成に割り当てます。Datastream で接続プロファイルを設定する際は、暗号化タイプとしてサーバーのみを使用します。

質問33：シナリオ：米国リージョン内のGoogle CloudのBigQueryにリレーショナルデータを保存しています。さらに、同じく米国リージョン内のMicrosoft AzureとAmazon Web Services（AWS）にオブジェクトストレージを管理しています。これらのデータすべてをBigQueryで毎日クエリし、データ移動を最小限に抑えたいと考えています。質問：データの移動を最小限に抑えながら、BigQuery 内のすべてのデータを毎日クエリするにはどうすればよいでしょうか。

BigQuery Omni 機能と BigLake テーブルを使用して、Azure および AWS 内のファイルをクエリします。

質問34：シナリオ：データサイエンスチームは、モデル作成のためにCloud Storage内の様々なファイルを利用する必要があります。しかし、現状ではデータの探索、クレンジング、検証を行う手段が不足しています。そこで、Cloud Storage内のデータを迅速に準備・探索できるローコードソリューションを提供したいと考えています。質問：データサイエンスチームが最小限のコーディングで Cloud Storage 内のデータをクレンジング、検証、探索できるようにするには、どうすればよいでしょうか。

データサイエンスチームに Dataprep へのアクセス権を提供し、Cloud Storage 内のデータを準備、検証、探索できるようにします。

質問35：シナリオ：Dataformを使用してBigQueryにELTソリューションを実装しています。最終的なテーブルが一意性とnull値のチェックに合格することを確認する必要があり、これらのチェックをパイプラインに効率的に統合したいと考えています。質問：一意性と null 値のチェックを Dataform パイプラインにどのように組み込む必要がありますか?

コードに Dataform アサーションを組み込みます。

質問36：シナリオ：ウェブサーバーはクリックイベントをPub/Subトピックにメッセージとして送信します。各メッセージには、クリックが発生した時刻を示すeventTimestamp属性が含まれています。Dataflowストリーミングジョブは、このPub/Subトピックからデータを読み取り、変換を適用し、その結果を別のPub/Subトピックに書き込み、広告部門で使用します。広告部門は、対応するクリックから30秒以内に各メッセージを受信する必要がありますが、メッセージの受信が遅れていると報告されています。Dataflowジョブのシステムラグは約5秒、データの鮮度は約40秒です。いくつかのメッセージを調べたところ、eventTimestampとpublishTimeの間のラグは1秒以内であることがわかりました。質問：メッセージの配信が遅れる原因は何ですか? また、この問題をどのように解決できますか?

Dataflow ジョブ内のメッセージは 30 秒未満で処理されますが、Pub/Sub サブスクリプションのバックログに追いつくことができません。ジョブを最適化するか、ワーカー数を増やすことでこの問題を解決できます。

質問37：シナリオ：組織では、顧客データをオンプレミスのApache HadoopクラスタにApache Parquet形式で保存しています。Apache Sparkジョブは、このクラスタ上で毎日データを処理しています。ParquetデータとSparkジョブをGoogle Cloudに移行する予定です。将来の変換パイプラインではBigQueryを使用するため、BigQueryからデータにアクセスできるようにする必要があります。マネージドサービスを利用しながら、ETL処理の変更を最小限に抑え、オーバーヘッドコストを削減したいと考えています。質問：要件を満たすために、データと Spark パイプラインをどのように移行および管理する必要がありますか?

データを BigQuery に移行します。Spark パイプラインをリファクタリングして BigQuery でデータの書き込みと読み取りを行い、Dataproc Serverless で実行します。

質問38：シナリオ：BigQueryのcustomer_orderテーブルには、1,000万人の顧客の注文履歴が保存されており、合計10PBのデータになります。サポートチームがこの注文履歴を閲覧するためのダッシュボードを作成する必要があります。ダッシュボードには、country_nameとusernameという2つのフィルタが含まれています。どちらもBigQueryテーブルの文字列データ型です。ユーザーがフィルタを適用すると、ダッシュボードはクエリを実行し、フィルタリングされた注文履歴を取得します。しかし、クエリ結果がダッシュボードに表示されるまでに時間がかかります。質問：クエリのパフォーマンスを向上させ、ダッシュボードを高速化するには、BigQuery テーブルをどのように再設計すればよいでしょうか。

国とユーザー名のフィールドごとにテーブルをクラスター化します。

質問39：シナリオ:Dataflow パイプラインを介して注文データをストリーミングし、集計結果を Memorystore for Redis インスタンスに保存します。現在のインスタンスはベーシック階層で 4 GB の容量がプロビジョニングされており、40 台の読み取り専用クライアントにサービスを提供しています。読み取り専用クライアントの数は今後数百台に増加すると予想されます。パフォーマンスを低下させることなく、読み取りおよび書き込みアクセスの高可用性とスケーラビリティを確保する必要があります。実装する変更はすべて、迅速にデプロイできる必要があります。質問：高可用性と迅速な展開を維持しながら、読み取り専用アクセスの需要の増加に対処するにはどうすればよいでしょうか。

スタンダードティアで新しいMemorystore for Redisインスタンスを作成します。容量を5GBに設定し、複数のリードレプリカを作成します。古いインスタンスを削除します。

質問40：シナリオ：Pub/Subからデータを取り込む本番環境のストリーミングパイプラインがあります。このパイプラインをビジネスロジックの改善に合わせて更新し、過去2日間のPub/Subメッセージを確実に再処理できるようにする必要があります。質問：ストリーミングパイプラインを更新した後、過去 2 日間に配信された Pub/Sub メッセージを再処理するにはどうすればよいですか? (2 つ選択してください。)

Pub/Sub サブスクリプションの retain-acked-messages フラグを使用します。, タイムスタンプ付きの Pub/Sub Seek を使用します。

質問41：シナリオ：SQLベースのツールを使用して、BigQueryに保存されているデータを視覚化します。視覚化には、外部結合と分析関数を使用する必要があります。視覚化は、少なくとも4時間前のデータに基づいて行う必要があります。ビジネスユーザーから、視覚化の生成に時間がかかりすぎるという報告を受けています。データ準備パイプラインのメンテナンスオーバーヘッドを最小限に抑えながら、クエリのパフォーマンスを改善したいと考えています。質問：視覚化クエリのパフォーマンスを向上させ、データ準備パイプラインのメンテナンスオーバーヘッドを削減するにはどうすればよいでしょうか。

可視化クエリのallow_non_incremental_definitionオプションをtrueに設定し、マテリアライズド・ビューを作成します。max_stalenessパラメータを4時間、enable_refreshパラメータをtrueに設定します。データ可視化ツールでマテリアライズド・ビューを参照します。

質問42：シナリオ：組織は既存のオンプレミスデータ戦略を最新化したいと考えています。現在の構成には以下が含まれます。データ複製用のオンプレミス HDFS を含む、複数の大規模データセットを処理するための Apache Hadoop クラスター。Apache Airflow は、数千のジョブステップで数百の ETL パイプラインをオーケストレーションします。既存のオーケストレーションプロセスへの変更を最小限に抑えながら、Hadoop ワークロードを処理できる新しいアーキテクチャを Google Cloud にセットアップする必要があります。質問：既存の Hadoop ワークロードを移行し、最小限の変更でオーケストレーションプロセスを統合するには、どうすればよいでしょうか。

Dataproc を使用して Hadoop クラスタを Google Cloud に移行し、Cloud Storage を使用して HDFS のあらゆるユースケースに対応します。Cloud Composer を使用してパイプラインをオーケストレートします。

質問43：シナリオ：最近、Cloud Composer 2 環境に複数のデータ処理ジョブをデプロイしました。Apache Airflow で一部のタスクが失敗しています。モニタリングダッシュボードで、ワーカーの合計メモリ使用量とワーカーポッドのエビクションが増加していることがわかります。これらのエラーを解決する必要があります。質問：Cloud Composer 2 のメモリ関連エラーを解決するには、どのようなアクションを実行する必要がありますか? (2 つ選択してください)

ワーカーの最大数を増やし、ワーカーの同時実行性を減らします。, Airflow ワーカーが使用できるメモリを増やします。

質問44：シナリオ：あなたはデータガバナンスチームに所属しており、リソースをデプロイするためのセキュリティ要件を実装し、すべてのリソースが europe-west3 リージョンに限定されるようにする必要があります。Google が推奨するプラクティスに従う必要があります。質問：Google Cloud のベストプラクティスに従って、リソースを europe-west3 リージョンに制限するポリシーをどのように適用すればよいですか。

組織ポリシーの制約constraints/gcp.resourceLocationsをin:europe-west3-locationsに設定します。

質問45：シナリオ：あなたはBigQuery管理者として、アドホッククエリやLookerなどのツールを使ったダウンストリームレポートを実行するデータ利用者チームをサポートしています。すべてのデータとユーザーは、1つの組織プロジェクトに統合されています。最近、クエリ結果に遅延が発生していることに気づき、どこで遅延が発生しているかを分析したいと考えています。ユーザーがジョブを実行する際に、ジョブのキューイングやスロットの競合が発生しており、これが結果へのアクセスを遅くしている可能性があると考えられます。クエリジョブ情報を確認し、パフォーマンスに影響を与えている箇所を特定する必要があります。質問：クエリジョブ情報を調査して、速度低下が発生している場所を特定し、パフォーマンスの問題に対処するにはどうすればよいでしょうか?

利用可能な管理リソースチャートを使用して、スロットの使用状況とジョブのパフォーマンスを経時的に把握します。INFORMATION_SCHEMA に対してクエリを実行し、クエリのパフォーマンスを確認します。

質問46：シナリオ：分析用に10PBの製品履歴データを提供するアプリケーションのデータバックエンドを移行しました。このアプリケーションは、製品の最新の状態（約10GBのデータ）をAPI経由で他のアプリケーションに提供する必要があります。APIは、1秒あたり最大1,000クエリ（QPS）を1秒未満のレイテンシで処理する必要があります。分析とAPIの両方のパフォーマンス要件を満たす、費用対効果の高い永続ストレージソリューションが必要です。質問：過去の製品データを保存し、最新の状態データを API に提供するには、どのストレージソリューションを選択する必要がありますか?

1. 分析のために履歴データを BigQuery に保存します。2. Cloud SQL テーブルに、製品が変更されるたびに製品の最新の状態を保存します。3. 最新の状態データを Cloud SQL から直接 API に提供します。

質問47：シナリオ：数百のテーブルに対して、シーケンシャルロードと変換ジョブをスケジュールする必要があります。データファイルは、固定スケジュールなしでCloud Storageバケットに追加されます。データが追加されると、Dataprocジョブが変換を実行し、BigQueryに書き込みます。その後、BigQueryで複数の変換ジョブを実行する必要があり、完了までに数時間かかる場合があります。すべてのテーブルを処理し、エンドユーザーに最新のデータを提供するための、最も効率的でメンテナンス性の高いワークフローを決定する必要があります。質問：データを効率的かつ保守的に処理し、エンドユーザーに最新のデータを提供するための最適なアプローチは何ですか?

1. Dataproc および BigQuery 演算子を使用して、Cloud Composer で順次タスクを含む Apache Airflow 有向非巡回グラフ（DAG）を作成します。2. パイプラインを通過する必要があるテーブルごとに個別の DAG を作成します。3. Cloud Storage オブジェクトトリガーを使用して、DAG をトリガーする Cloud Functions 関数を起動します。

質問48：シナリオ：MySQLデータベースのワークロードをCloud SQLにデプロイします。データベースは、様々な地理的リージョンからの複数のリーダーをサポートできるようスケーリングする必要があります。また、リージョン障害発生時に備えて、高い可用性と低いRTOおよびRPO要件を満たす必要があります。データベースのフェイルオーバー中は、リーダーへの中断を最小限に抑える必要があります。質問：データベースのフェイルオーバー中にリーダーへの中断を最小限に抑えるための最適な方法は何ですか?

リージョン A に高可用性の Cloud SQL インスタンスを作成します。リージョン B に高可用性のリードレプリカを作成します。複数のリージョンにカスケード型のリードレプリカを作成することで、読み取りワークロードをスケールアップします。リージョン A がダウンしている場合は、リージョン B のリードレプリカを昇格します。

質問49：シナリオ：既存のオンプレミスデータの一部をGoogle Cloud上のBigQueryに読み込む予定です。ユースケースに応じて、ストリーミングまたはバッチ処理でデータを読み込みます。また、BigQueryに読み込む前に機密データをマスキングする必要があり、コストを抑えながらプログラムでマスキングを行いたいと考えています。質問：機密データを BigQuery にロードする前にプログラムでロードしてマスクする最も効率的な方法は何ですか?

Apache Beam SDK for Python を介して Dataflow でパイプラインを作成し、ストリーミング、バッチ処理、Cloud DLP のコード内で個別のオプションをカスタマイズします。データシンクとして BigQuery を選択します。

質問50：シナリオ：あるオンライン小売業者は、Google App Engine 上で現在のアプリケーションを開発しており、顧客との直接取引を可能にする必要に迫られています。同社は、ショッピング取引を統合し、ビジネスインテリジェンス（BI）ツールを使用して様々なデータセットから取得したデータを単一のデータベースで分析することを目指しています。質問：このシナリオでは、小売業者は要件を満たすためにどの Google Cloud データベースを選択する必要がありますか?

クラウドSQL

全商情報処理検定1級

全商情報処理検定1級

LPIC305

LPIC305

プロモ豆