ACE#03

ACE#02 – ACE#03 – ACE#04
R – F

お疲れ様でした!ACE#03のクイズ終了しました。

解答スコアは %%SCORE%% / %%TOTAL%% 問正解です。

%%RATING%%


あなたの選択した答えは強調表示されています。
問題1
Cloud Shell の gcloud コマンドラインを使用して、GCP プロジェクトで有効な Google Cloud Platform API のリストを作成する必要があります。プロジェクト名は my-project です。どのように対応しますか。
A
gcloud projects list を実行して project ID を取得し、gcloud services list --project を実行します。
B
gcloud info を実行してアカウントの値を表示してから、gcloud services list --account を実行します。
C
gcloud init を実行して現在のプロジェクトを my-project に設定してから、gcloud services list --available を実行します。
D
gcloud projects describe を実行してプロジェクトの値を確認してから、gcloud services list --available を実行します。
問題 1 の説明および補足 
gcloud services list
project ID を gcloud services list --project に渡して、有効なサービスを一覧表示できます。デフォルトのフラグは enabled です。
参考URL:gcloud services list

■以下は間違いです。
・gcloud projects describe を実行してプロジェクトの値を確認してから、gcloud services list --available を実行します。
→使用可能なすべての API を一覧表示するため間違いです。

・gcloud info を実行してアカウントの値を表示してから、gcloud services list --account を実行します。
→有効になっている API をプロジェクトに合わせて確認する必要があるため間違いです。

・gcloud init を実行して現在のプロジェクトを my-project に設定してから、gcloud services list --available を実行します。
→有効な API ではなく、使用可能なすべての API を一覧表示するため間違いです。
問題2
開発チームは、新しい概念実証アプリケーションのために、ポイントインタイム リカバリを備えたリージョンの MySQL データベースを必要としています。ポイントインタイム リカバリを有効にする最も安価な方法は何ですか?
A
1 時間ごとのバックアップを作成します。
B
Cloud Spanner データベースに複製します。
C
バイナリ ロギングを有効にします。
D
同じリージョンにリードレプリカを作成します。
問題 2 の説明および補足 
ポイントインタイム リカバリを実行する
・バイナリ ロギングを有効にします。
→バイナリ ロギングはポイントインタイム リカバリに役立つため正解です。

※ポイントインタイム リカバリを実行する
ポイントインタイム リカバリを実行するには、事前にバイナリログ ファイル名とインスタンスを復元するポイントインタイムに対応する位置を確認する必要があります。
参考URL:ポイントインタイム リカバリを実行する

■以下は間違いです。
・1 時間ごとのバックアップを作成します。
→1 時間ごとのバックアップがポイントインタイムの要件を満たしていないため間違いです。

・Cloud Spanner データベースに複製します。
・同じリージョンにリードレプリカを作成します。
→リードレプリカと Cloud Spanner は費用効果の高いオプションではないため間違いです。
参考URL:Cloud Spanner
問題3
複数の Google Cloud Platform (GCP) プロジェクトを管理しており、過去 60 日間のすべてのログにアクセスする必要があります。ログの内容を調査してすばやく分析できるようにする必要があります。Google が推奨する方法で、すべてのプロジェクトのログをまとめて取得したいと考えています。どのように対応しますか。
A
Stackdriver Logging Export を作成し、シンクの宛先を Cloud Storage に設定します。60 日後にオブジェクトを削除するライフサイクル ルールを作成します。
B
Cloud Scheduler ジョブを構成して Stackdriver から読み取り、ログを BigQuery に保存します。テーブルの有効期限を 60 日間に設定します。
C
Stackdriver Logging に移動し、resource.labels.project_id="*" を選択します。
D
BigQuery のデータセットへのシンクの宛先を持つ Stackdriver Logging Export を作成します。テーブルの有効期限を 60 日間に設定します。
問題 3 の説明および補足 
ロギングデータのエクスポートのシナリオ: セキュリティとアクセス分析
・BigQuery のデータセットへのシンクの宛先を持つ Stackdriver Logging Export を作成します。テーブルの有効期限を 60 日間に設定します。
→Stackdriver シンクは分析用の BigQuery にデータをプッシュするように設定でき、有効期限を設定できるため正解です。

※ロギングデータのエクスポートのシナリオ: セキュリティとアクセス分析
組織のクラウド インフラストラクチャ環境のセキュリティと分析の要件を満たすために、Cloud Logging から BigQuery にログをエクスポートする方法を示します。多くの場合、組織では分析ツールを使用して、未承認の構成変更やデータへの不適切なアクセスを特定します。Cloud Logging は、セキュリティと分析の要件を満たすために、管理者アクティビティ ログとデータアクセス ログの 2 種類の監査ログをキャプチャできます。
このシナリオでは、エクスポートの一環として、エクスポートしたログが構成された BigQuery のデータセットに配信されます。必要に応じて、ログへのアクセスを制限する権限を付与します。エクスポートされたデータを日付パーティション分割テーブルに整理することで、データの管理と照会が簡単になります。この手法により、クエリの一部としてスキャンされるデータ量を減らして、クエリのコストを削減できます。パーティショニングの利点の 1 つは、パーティションの有効期限を設定することで、役立つと思われる期間、ロギングデータを維持できることです。
参考URL:ロギングデータのエクスポートのシナリオ: セキュリティとアクセス分析

■以下は間違いです。
・Cloud Scheduler ジョブを構成して Stackdriver から読み取り、ログを BigQuery に保存します。テーブルの有効期限を 60 日間に設定します。
→シンク が Cloud Scheduler と同じジョブを実行するため必要ありません。
参考URL:Cloud Scheduler の概要

・Stackdriver Logging Export を作成し、シンクの宛先を Cloud Storage に設定します。60 日後にオブジェクトを削除するライフサイクル ルールを作成します。
→Cloud Storage に保存することはコンプライアンスには適していますが、分析機能がないため間違いです。

・Stackdriver Logging に移動し、resource.labels.project_id="*" を選択します。
→StackDriver のデータアクセス監査ログの最小保持期間は 30 日であるため間違いです。
問題4
あなたは、Storage バケットに保存されているオブジェクトのために、オブジェクトのライフサイクル管理を設定するように求められています。オブジェクトは 1 回書き込まれ、30 日間頻繁にアクセスされます。30 日後、特別な必要性がない限り、オブジェクトは再び読み込まれることはありません。オブジェクトは 3 年間保管する必要があり、コストを最小限に抑える必要があります。どのように対応しますか。
A
Standard Storage を 30 日間使用した後、Coldline に 1 年間移動し、その後 Archive Storage に 2 年間移動するポリシーを設定します。
B
Nearline Storage を 30 日間使用し、その後 3 年間は、Archive Storage に移動するポリシーを設定します。
C
Nearline Storage を 30 日間使用した後、Coldline に 1 年間移動し、その後 Archive Storage に 2 年間移動するポリシーを設定します。
D
Standard Storage を 30 日間使用し、その後 3 年間は、Archive Storage に移動するポリシーを設定します。
問題 4 の説明および補足 
ストレージ クラス
オブジェクトは最初の 30 日間は頻繁にアクセスされるため、Standard Storage クラスに保存し、その後 3 年間は Archive Storage に保存することでコストを最小限に抑えることができます。

※ストレージ クラス
・Standard Storage
Standard Storage は、頻繁にアクセスされるデータ(「ホット」データ)や、短時間だけ保存されるデータに最適です。

・ Archive Storage
Archive Storage は、データ アーカイブ、オンライン バックアップ、障害復旧のための最も低コストで、耐久性に優れたストレージ サービスです。他の Cloud プロバイダによって提供されている「最もコールドな」ストレージ サービスと異なり、データに迅速にアクセスできます。必要なデータの取得に数時間あるいは数日かかることはありません。
その他の Cloud Storage ストレージ クラスとは異なり、Archive Storage には可用性 SLA はありませんが、一般的な可用性は Nearline Storage や Coldline Storage と同等です。また、Archive Storage はデータアクセスと操作に関する費用が高く、365 日間という最小保存期間もあります。Archive Storage は、1 年間に 1 回未満しかアクセスしないデータに最適です。
例:
・コールドデータ ストレージ : 法的または規制上の理由で保存されているデータなど、アーカイブされたデータを Archive Storage として低コストで保存でき、必要な場合は使用できます。

・障害復旧 : 障害復旧イベントでは、復旧にかかる時間が重要です。Cloud Storage では、Archive Storage として保存されているデータに低レイテンシでアクセスできます。

・Nearline Storage
Nearline Storage は、頻繁にアクセスされるデータを保存するための低コストで耐久性に優れたストレージ サービスです。可用性が若干低く、最小保存期間が 30 日で、データアクセスで費用が発生しても、保存時のストレージ コストを抑えたい場合には、Standard Storage よりも Nearline Storage のほうが最適な選択肢となります。

参考 URL:ストレージ クラス

■以下は間違いです。
・Standard Storage を 30 日間使用した後、Coldline に 1 年間移動し、その後 Archive Storage に 2 年間移動するポリシーを設定します。
→特別な必要性がある場合にのみ必要とされるデータであるため、Archive Storage に移動することは理にかなっていると考えられるため間違いです。

・Nearline Storage を 30 日間使用し、その後 3 年間は、Archive Storage に移動するポリシーを設定します。
・Nearline Storage を 30 日間使用した後、Coldline に 1 年間移動し、その後 Archive Storage に 2 年間移動するポリシーを設定します。
→Nearline Storage は頻繁にアクセスされるデータには理想的ではないため間違いです。
問題5
Google Kubernetes Engine (GKE) でクラスタの自動スケーリングを有効にしてアプリケーションを実行しています。このアプリケーションは、TCP エンドポイントを公開しています。このアプリケーションには複数のレプリカがあります。同じリージョンにある Compute Engine インスタンスが、最初の VPC とIP 範囲が重複しない gce-network という別の Virtual Private Cloud (VPC) にあります。このインスタンスは、GKE 上のアプリケーションに接続する必要があります。労力を最小限に抑えたいと思います。あなたはどのように対応しますか。
A
1.GKE で、アプリケーションの Pod をバックエンドとして使用する NodePort タイプの Service を作成します。
2.各 VPC に 1 つずつ、2 つのネットワークインターフェイスを持つ proxy という名前の Compute Engine インスタンスを作成します。
3.このインスタンスで iptables を使用して、gce-network から GKE ノードにトラフィックを転送します。
4.gce-network 内の proxy のアドレスをエンドポイントとして使用するよう、Compute Engine インスタンスを設定します。
B
1.GKE で、アプリケーションの Pod をバックエンドとして使用する LoadBalancer タイプの Service を作成します。
2.この Service に アノテーション cloud.google.com/load-balancer-type: "Internal" を追加します。
3.2 つの VPC をピアリングします。
4.作成されたロードバランサのアドレスを使用するように Compute Engine インスタンスを設定します。
C
1.GKE で、アプリケーションの Pod をバックエンドとして使用する LoadBalancer タイプの Service を作成します。
2.ロードバランサに Cloud Armor セキュリティ ポリシーを追加して、MIG のインスタンスの内部 IP をホワイトリスト化します。
3.作成されたロードバランサのアドレスを使用するように Compute Engine インスタンスを設定します。
D
1.GKE で、アプリケーションの Pod をバックエンドとして使用する LoadBalancer タイプの Service を作成します。
2.この Service の externalTrafficPolicy を Cluster に設定します。
3.Compute Engine インスタンスに、作成したロードバランサのアドレスを使用するように設定します。
問題 5 の説明および補足 
内部 TCP / UDP ロードバランサの使用
GKE デプロイ/ Pod は内部ロードバランササービスを使用して公開することができ、2 つの VPC は Compute Engine がクラスタエンドポイントに内部通信できるように重複しない CIDR を持っているのでピアリングすることができます。

※内部 TCP / UDP ロードバランサの使用
内部 TCP / UDP 負荷分散を使用すると、同じ VPC ネットワークを使用し、同じ Google Cloud リージョンに配置されているクラスタ外のアプリケーションに、クラスタのサービスがアクセスできるようになります。たとえば、us-west1 リージョンにクラスタを配置している場合、そのクラスタのサービスの 1 つが、同じ VPC ネットワークを使用し、このリージョンで実行されている Compute Engine VM インスタンスにアクセスできるようになります。

内部 TCP / UDP ロードバランサを作成するには、type: LoadBalancer 仕様とアノテーションを含む Service リソースを作成します。アノテーションは、GKE クラスタのバージョンによって異なります。

GKE バージョン 1.17 以降の場合は、アノテーション networking.gke.io/load-balancer-type: "Internal" を使用します。

それよりも前のバージョンでは、アノテーション cloud.google.com/load-balancer-type: "Internal" を使用します。
参考URL:内部 TCP / UDP ロードバランサの使用


■以下は間違いです。
1.GKE で、アプリケーションの Pod をバックエンドとして使用する LoadBalancer タイプの Service を作成します。
2.ロードバランサに Cloud Armor セキュリティ ポリシーを追加して、MIG のインスタンスの内部 IP をホワイトリスト化します。
3.作成されたロードバランサのアドレスを使用するように Compute Engine インスタンスを設定します。
→内部 IP は外部ロードバランサで機能するため間違いです。

1.GKE で、アプリケーションの Pod をバックエンドとして使用する NodePort タイプの Service を作成します。
2.各 VPC に 1 つずつ、2 つのネットワークインターフェイスを持つ proxy という名前の Compute Engine インスタンスを作成します。
3.このインスタンスで iptables を使用して、gce-network から GKE ノードにトラフィックを転送します。
4.gce-network 内の proxy のアドレスをエンドポイントとして使用するよう、Compute Engine インスタンスを設定します。
→NodePort は、クラスタの自動スケーリングが有効になっているデプロイまたはアプリケーションを公開するための理想的な方法ではないため間違いです。また、このソリューションは最小の労力ではありません。

1.GKE で、アプリケーションの Pod をバックエンドとして使用する LoadBalancer タイプの Service を作成します。
2.この Service の externalTrafficPolicy を Cluster に設定します。
3.Compute Engine インスタンスに、作成したロードバランサのアドレスを使用するように設定します。
→Service を外部に公開することになるため間違いです。
問題6
単一のプリエンプティブル ノードプールを持つ Google Kubernetes Engine (GKE) クラスタに 2 つのレプリカを使用してデプロイを作成します。数分後、kubectl を使用して Pod のステータスを調べ、そのうちの 1 つがまだ Pending (保留中) のステータスになっていることを確認します。
$ kubectl get pods -1 app=myapp
NAME                               READY STATUS    RESTART  AGE
myapp-deployment-58ddbbb995-lp86m  0/1   Pending   0        9m
myapp-deployment-58ddbbb995-qjpkg  1/1   Running   0        9m
最も可能性の高い原因は何ですか?
A
Pending (保留中) の Pod は、元々、デプロイの作成と Pod のステータスを確認するまでの間にプリエンプトされたノードでスケジュールされていました。それは現在、新しいノードで再スケジュールされています。
B
Pending (保留中) の Pod のリソース要求が大きすぎて、クラスタの単一ノードに収まりません。
C
クラスタで実行されている Pod が多すぎて、Pending (保留中) の Pod をスケジュールするのに十分なリソースが残っていません。
D
ノードプールには、Pending (保留中) の Pod が使用するコンテナイメージを引き出す権限を持たないサービス アカウントが構成されています。
問題 6 の説明および補足 
My pod stays pending
Pending (保留中) の Pod の理由は通常、リソース不足であるため、正解は 「クラスタで実行されている Pod が多すぎて、Pending (保留中) の Pod をスケジュールするのに十分なリソースが残っていません。」 になります。

※My pod stays pending
Pod が Pending (保留中) でスタックしている場合は、ノードにスケジュールできないことを意味します。一般に、これは、スケジューリングを妨げる、あるタイプまたは別のタイプのリソースが不十分であるためです。
参考 URL:My pod stays pending

■以下は間違いです。
・Pending (保留中) の Pod は、元々、デプロイの作成と Pod のステータスを確認するまでの間にプリエンプトされたノードでスケジュールされていました。それは現在、新しいノードで再スケジュールされています。
→Pod が利用可能なノードでスケジュールされるため間違いです。

・Pending (保留中) の Pod のリソース要求が大きすぎて、クラスタの単一ノードに収まりません。
・ノードプールには、Pending (保留中) の Pod が使用するコンテナイメージを引き出す権限を持たないサービス アカウントが構成されています。
→デプロイであり、レプリカ Pod がすでにスケジュールされて実行されているため間違いです。
問題7
新しい IAM メンバーを追加し、BigQuery でいくつかのクエリを実行するためのアクセスを許可するように求められました。最小特権の原則を考慮して、どのロールを割り当てる必要がありますか?
A
roles/bigquery.dataViewer および roles/bigquery.jobUser
B
roles/bigquery.dataOwner および roles/bigquery.jobUser
C
roles/bigquery.dataViewer および roles/bigquery.user
D
roles/bigquery.dataEditor および roles/bigquery.jobUser
問題 7 の説明および補足 
BigQuery の IAM 事前定義された IAM ロール
ユーザーはデータをクエリするだけなので、データセットを表示したり、データセットをクエリするためのアクセス権を持つ必要があります。これは、最小特権の原則に沿って roles/bigquery.dataViewer と roles/bigquery.jobUser によって提供されます。
参考URL:BigQuery の IAM 事前定義された IAM ロール


■以下は間違いです。
・roles/bigquery.dataOwner および roles/bigquery.jobUser
→roles/bigquery.dataOwner は必要以上の権限を提供するため間違いです。

・roles/bigquery.dataViewer および roles/bigquery.user
→roles/bigquery.user は必要以上の権限を提供するため間違いです。

・roles/bigquery.dataEditor および roles/bigquery.jobUser
→roles/bigquery.dataEditor は必要以上の権限を提供するため間違いです。
お疲れさまでした。 クイズが完了したら、「クイズの結果を見る」ボタンをクリックしてください。あなたが完了していないアイテムは、間違いのマークがされます。 クイズの結果を見る
問題は全部で 7 問。全て答えられるように頑張りましょう!
リスト
戻る
網掛け部分は完了した項目です。
12345
67ゴール
戻る
error: コンテンツの複製・転用は禁止されております。