あなたの選択した答えは強調表示されています。
問題1 |
Google Cloud Platform のサービス アカウントが特定の時間に作成されたことを確認する必要があります。どのように対応しますか。
アクティビティログをフィルタリングして、[データアクセス] カテゴリを表示します。リソースタイプを Google プロジェクトにフィルタリングします。 | |
アクティビティログをフィルタリングして、構成カテゴリを表示します。リソースタイプを Google プロジェクトにフィルタリングします。 | |
アクティビティログをフィルタリングして、構成カテゴリを表示します。リソースタイプをサービス アカウントにフィルタリングします。 | |
アクティビティログをフィルタリングして、[データアクセス] カテゴリを表示します。リソースタイプをサービス アカウントにフィルタリングします。 |
問題 1 の説明および補足
アクティビティログの確認
リソースタイプをサービス アカウントにフィルタリングすることにより、アクティビティログを使用して構成カテゴリを表示できます。問題2 |
gcloud に複数の構成を使用しています。非アクティブな構成の Kubernetes Engine クラスタの構成を、できるだけ少ない手順で見直したいと考えています。どのように対応しますか。
kubectl config use-context と kubectl config view を使用して、出力を確認します。 | |
gcloud config configurations describe を使用して、出力を確認します。 | |
gcloud config configurations activate と gcloud config list を使用して、出力を確認します。 | |
kubectl config get-contexts を使用して、出力を確認します。 |
問題 2 の説明および補足
kubectl のアクセス先(コンテキスト)を切り替える方法
kubectl config use-context を使用して正しいコンテキストを選択し、kubectl config view を使用して構成を表示できます。 参考URL：kubectl のアクセス先(コンテキスト)を切り替える方法 参考URL：kubectl の接続設定ファイル（kubeconfig）の概要 ■以下は間違いです。 ・gcloud config configurations describe を使用して、出力を確認します。 ・gcloud config configurations activate と gcloud config list を使用して、出力を確認します。 →kubernetes クラスタの設定に gcloud ではなく kubectl コマンドを使用する必要があるため間違いです。 ・kubectl config get-contexts を使用して、出力を確認します。 →kubectl config get-contexts では設定を見ることができず、コンテキストをリストアップするだけなので間違いです。問題3 |
Cloud Spanner インスタンスでテーブルデータを表示および編集できるように、3 人のユーザーにアクセスを許可する必要があります。どのように対応しますか。
gcloud iam roles describe roles/spanner.databaseUser を実行します。ユーザーをロールに追加します。 | |
gcloud iam roles describe roles/spanner.viewer --project my-project を実行します。ユーザーをロールに追加します。 | |
gcloud iam roles describe roles/spanner.databaseUser を実行します。ユーザーを新しいグループに追加します。そのグループをロールに追加します。 | |
gcloud iam roles describe roles/spanner.viewer --project my-project を実行します。ユーザーを新しいグループに追加します。そのグループをロールに追加します。 |
問題 3 の説明および補足
roles/spanner.databaseUser
roles/spanner.databaseUser は、データベースへの読み書き能力を提供するため正解です。また、個々のユーザーにアクセス権を与えるのではなく、グループを使用することをお勧めします。 ※roles/spanner.databaseUser データベースレベルでの付与を推奨します。このロールを持つメンバーは次のことができます。 ・Cloud Spanner データベースに読み取り / 書き込みを行う。 ・データベースに SQL クエリを実行する（DML、パーティション化された DML を含む）。 ・データベースのスキーマを表示 / 更新する。 参考URL：roles/spanner.databaseUser ■以下は間違いです。 ・gcloud iam roles describe roles/spanner.viewer --project my-project を実行します。ユーザーをロールに追加します。 ・gcloud iam roles describe roles/spanner.viewer --project my-project を実行します。ユーザーを新しいグループに追加します。そのグループをロールに追加します。 →読み取り権限しか与えられていないため間違いです。 ・gcloud iam roles describe roles/spanner.databaseUser を実行します。ユーザーをロールに追加します。 →ユーザーを含むグループを作成し、そのグループにロールを割り当てることが推奨されるため間違いです。問題4 |
Compute Engine 上に VM をプロビジョニングする動的な方法が必要です。具体的な仕様は、専用の設定ファイルに記述します。Google のベストプラクティスに従いたいと考えています。どの方法を使用する必要がありますか？
非マネージド インスタンス グループ | |
マネージド インスタンス グループ | |
Deployment Manager | |
Cloud Composer |
問題 4 の説明および補足
Google Cloud Deployment Manager
Google Cloud Deployment Manager は、Google Cloud リソースの作成と管理を自動化するインフラストラクチャ デプロイ サービスです。柔軟なテンプレート ファイルと構成ファイルを作成し、それらを使用して、Cloud Storage、Compute Engine、Cloud SQL などのさまざまな Google Cloud サービスを連携させるように構成されたデプロイを作成します。 参考URL：Google Cloud Deployment Manager ■以下は間違いです。 ・Cloud Composer →Cloud Composer はフルマネージド サービスであり、Apache Airflow は互換性に優れ、リソースのプロビジョニングに気をとられず、ワークフローの作成、スケジューリング、モニタリングするサービスのため間違いです。 参考URL：Cloud Composer ・マネージド インスタンス グループ ・非マネージド インスタンス グループ →インスタンス グループは、単一のエンティティとして管理できる VM インスタンスの集まりであるため間違いです。 ※インスタンス グループ ・マネージド インスタンス グループ (MIG)では、複数の同一 VM でのアプリケーション操作が可能です。自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイメント、自動更新などの自動化 MIG サービスを活用することで、スケーラブルで可用性に優れたワークロード処理を実現します。 ・非マネージド インスタンス グループでは、ユーザー自身が管理する一連の VM 間での負荷分散が可能です。 参考URL：インスタンス グループ問題5 |
SysOps 管理者は、オブジェクトのバージョニングが有効なマルチリージョンのバケットにライフサイクル ルールを設定しました。次のステートメントの効果は、次のライフサイクルの構成を反映しているものを選択してください。
{
"rule":
[
{
"action": {"type": "Delete"},
"condition": {"age": 30, "isLive": false}
},
{
"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
"condition": {"age": 365, "matchesStorageClass": "MULTI_REGIONAL"}
}
]
}ストレージ クラスが「Multi-Regional」の場合、30 日以上前のアーカイブオブジェクトを削除し、365 日後にオブジェクトを Coldline Storage に移動します。 | |
ストレージ クラスが「Multi-Regional」の場合、30 日以上前のオブジェクトをアーカイブし、365 日後にオブジェクトを Coldline Storage に移動します。 | |
ストレージ クラスが「Multi-Regional」の場合、365 日後にオブジェクトを Coldline Storage に移動し、最初のルールはバケットに影響を与えません。 | |
ストレージ クラスが「Multi-Regional」の場合、30 日以上前のオブジェクトを削除し、365 日後にオブジェクトを Coldline Storage に移動します。 |
問題 5 の説明および補足
ライフサイクルの条件
最初のルールは、オブジェクトの経過時間が 30 日を超えており、ライブではない（最新バージョンではない）場合、すべてのオブジェクトを削除します。2 番目のルールは、365 日以上経過したオブジェクトについて、ライブオブジェクトのストレージ クラスを Multi-Regional から Coldline に変更します。 ※ライフサイクルの条件 ライフサイクル ルールでは、次の条件がサポートされています。 ・Age Age 条件は、オブジェクトの作成後に指定した日数を経過すると満たされます。Age は、オブジェクトが作成された時点から測定されます。たとえば、オブジェクトの作成時点が 2019/01/10 10:00 UTC で、Age 条件が 10 日であれば、2019/01/20 10:00 UTC の時点でオブジェクトの条件が満たされたことになります。これは、オブジェクトの作成後にバージョニングでオブジェクトが非現行バージョンになる場合にも当てはまります。 ・CreatedBefore CreatedBefore 条件は、オブジェクトが UTC の指定された日付の午前 0 時より前に作成されていると満たされます。 ・MatchesStorageClass MatchesStorageClass 条件は、バケット内のオブジェクトが、指定されたストレージ クラスとして保存されると満たされます。MatchesStorageClass には、STANDARD、NEARLINE、COLDLINE、ARCHIVE、MULTI_REGIONAL、REGIONAL、DURABLE_REDUCED_AVAILABILITY の値を使用できます。 参考URL：ライフサイクルの条件 ■以下は間違いです。 ・ストレージ クラスが「Multi-Regional」の場合、365 日後にオブジェクトを Coldline Storage に移動し、最初のルールはバケットに影響を与えません。 →最初のルールがアーカイブされたオブジェクトにも、ライブオブジェクトにも適用されるため間違いです。 ・ストレージ クラスが「Multi-Regional」の場合、30 日以上前のオブジェクトを削除し、365 日後にオブジェクトを Coldline Storage に移動します。 →最初のルールはライブオブジェクトを削除せず、オブジェクトをアーカイブするだけなので間違いです。 ・ストレージ クラスが「Multi-Regional」の場合、30 日以上前のオブジェクトをアーカイブし、365 日後にオブジェクトを Coldline Storage に移動します。 →最初のルールはアーカイブせず、アーカイブされたオブジェクトを削除するため間違いです。問題6 |
BigQuery に保存されている大量のデータに対してクエリを実行する必要があります。このクエリは大量のデータを返すことが予想されます。このクエリのコストをどのように見積もりますか？
コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、所要時間を決定し、料金計算ツールを使用してコストを決定します。 | |
コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、返されたバイト数を決定し、料金計算ツールを使用してコストを決定します。 | |
コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、フルスキャンとなるテーブルデータの総量をバイト単位で決定し、料金計算ツールを使用してコストを決定します。 | |
コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、読み取ったバイト数を決定し、料金計算ツールを使用してコストを決定します。 |
問題 6 の説明および補足
クエリを実行する前に料金を見積もる
--dry_run オプションは、実際にクエリを実行する前に、クエリの価格を決定するために使用できます。クエリは読み取ったバイト数を返し、それを料金計算ツールで使用してクエリのコストを見積もることができます。 ※クエリを実行する前に料金を見積もる おすすめの方法: クエリを実行する前に、プレビューして費用を見積もります。クエリは、読み取られたバイト数に基づいて課金されます。クエリを実行する前に費用を見積もるには: ・Cloud Console でクエリ検証ツールを表示する ・Google Cloud Platform 料金計算ツールを使用する ・以下を使用して、ドライランを実行する bq コマンドライン ツールの --dry_run フラグ dryRun パラメータ（API を使用してクエリジョブを送信する場合） 参考URL：クエリを実行する前に料金を見積もる 参考URL：料金計算ツール ■以下は間違いです。 ・コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、フルスキャンとなるテーブルデータの総量をバイト単位で決定し、料金計算ツールを使用してコストを決定します。 →読み取られるバイト数がクエリに依存し、常にフルテーブルスキャンとは限らないため間違いです。 ・コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、返されたバイト数を決定し、料金計算ツールを使用してコストを決定します。 ・コマンドラインを使用して、BigQuery の --dry_run オプションを使用して、所要時間を決定し、料金計算ツールを使用してコストを決定します。 →返されたバイト数や所要時間ではなく、クエリが読み込んだバイト数で推定する必要があるため間違いです。問題7 |
Cloud Shell を使用していて、数週間後に使用するカスタムユーティリティをインストールする必要があります。ファイルをデフォルトの実行パスに保存し、セッション間で保持できるようにするには、どこに保存すればよいでしょうか？
Cloud Storage | |
/google/scripts | |
~/bin | |
/usr/local/bin |
問題 7 の説明および補足
永続ディスク ストレージ
HOME ディレクトリのみがセッション間で永続化されるため、~/bin が正解です。 ※永続ディスク ストレージ Cloud Shell は、仮想マシン インスタンスの $HOME ディレクトリとしてマウントされた 5 GB の無料の永続ディスク ストレージをプロビジョニングします。このストレージは、ユーザーごとに割り当てられ、複数のプロジェクトを横断して使用することができます。インスタンスとは異なり、このストレージは非アクティブな状態であっても、タイムアウトすることはありません。インストールされたソフトウェア、スクリプト、.bashrc や .vimrc のようなユーザー構成ファイルなど、ホーム ディレクトリに保存されているファイルはすべて、セッションを横断して維持されます。$HOME ディレクトリはプライベート ディレクトリであるため、他のユーザーはアクセスできません。 参考URL：永続ディスク ストレージ ■以下は間違いです。 他の選択肢は、セッション間で永続的ではないため間違いです。
問題は全部で 7 問。全て答えられるように頑張りましょう！
|
リスト |
