Professional Cloud Architect 模擬問題集（2021.02.12）

※ 他の問題集は「タグ：Professional Cloud Architect の模擬問題集」から一覧いただけます。

この模擬問題集は「Professional Cloud Architect Practice Exam (2021.02.12)」の回答・参考リンクを改定した日本語版の模擬問題集です。

Google Cloud 認定資格 – Professional Cloud Architect – 模擬問題集（全 53問）

Question 01

この問題については JencoMart のケーススタディ を参照してください。
JencoMart のセキュリティチームは、すべての GCP インフラストラクチャを本番リソースと開発リソースの間で管理の職務が分離された最小特権モデルを使用してデプロイできることを望んています。
どのような Google ドメインとプロジェクト構造を推奨しますか？

• A. 2 つの G Suite アカウントを作成します。各アカウントにはアプリケーションごとに 1 つのプロジェクトが含まれている必要があります。
• B. 2 つの G Suite アカウントを作成します。1 つはすべての開発アプリケーション用の 1 つのプロジェクト、もう 1 つはすべての本番アプリケーション用の 1 つのプロジェクトです。
• C. 1 つの G Suite アカウントを作成します。各アプリケーションの各ステージのユーザーをそれぞれのプロジェクトで管理します。
• D. 1 つの G Suite アカウントを作成します。開発/テスト/ステージング環境用の 1 つのプロジェクトと本番環境用の 1 つのプロジェクトでユーザーを管理します。

Correct Answer: D

最小特権と職務分離の原則はセキュリティの観点から本質的に関連している概念です。
両方の背後にある目的は人々が実際に必要とするよりも高い特権レベルを持つことを防ぐことです。
-最小特権：ユーザーはジョブを実行するために必要な最小限の特権しか持たず、それ以上の権限は持たないようにします。これにより、許可されていないターゲット、ジョブ、監視テンプレートなどのリソースへのアクセスが制限されるため、許可の悪用が減ります。
– 職務分離：ユーザーの特権レベルを制限するだけでなく、ユーザーの職務、ユーザーが実行できる特定のジョブも制限します。ユーザーには 2つ以上の関連する機能の責任を与えてはなりません。これにより、ユーザーが悪意のあるアクションを実行し、そのアクションを隠蔽する能力が制限されます。

Reference contents:
– 職掌分散 | Cloud KMS ドキュメント | Google Cloud

Question 02

この問題については JencoMart のケーススタディ を参照してください。
JencoMart がユーザー認証情報データベースを Google Cloud Platform に移行し、古いサーバーをシャットダウンしてから数日後、新しいデータベースサーバーはSSH 接続への応答を停止します。
それでも、アプリケーションサーバーへのデータベース要求を正しく処理しています。
問題を診断するためにどのステップを踏むべきでしょうか？ （回答を 3つ選択してください）

• A. 仮想マシンとディスクを削除して新しいものを作成します。
• B. インスタンスを削除し、ディスクを新しいVM に接続して調査します。
• C. ディスクのスナップショットを取り、新しいマシンに接続して調査します。
• D. マシンが接続しているネットワークのインバウンド ファイアウォール ルールを確認します。
• E. マシンを非常に簡単なファイアウォール ルールで別のネットワークに接続して調査します。
• F. トラブルシューティングのためにインスタンスのシリアル コンソール出力を印刷し、インタラクティブ コンソールを起動して調査します。

Correct Answer: C、D、F

D：「ポート22に接続できません」というエラーメッセージを処理する
– ポートでのSSH アクセスを許可するファイアウォール ルールはありません。ポート 22 でのSSH アクセスはデフォルトですべての Google Compute Engine インスタンスに有効です。アクセスを無効にしている場合はブラウザからのSSH は機能しません。ポート 22 以外 のでSSH を実行する場合はカスタム ファイアウォール ルールを使用してそのポートへのアクセスを有効にする必要があります。
– SSH アクセスを許可するファイアウォール ルールは有効になっていますが、Google Cloud Console サービスからの接続を許可するように構成されていません。ブラウザベースのSSH セッションの送信元 IP アドレスは Google Cloud Console によって動的に割り当てられ、セッションごとに異なる可能性があります。
F：「接続できませんでした。再試行しています…」
– シリアル コンソール出力ページに移動し、文字列「accounts-from-metadata」のプレフィックスが付いた出力行を探すことでデーモンが実行されていることを確認できます。標準イメージを使用していてもシリアル コンソール出力にプレフィックスが表示されない場合は、デーモンが停止している可能性があります。インスタンスを再起動してデーモンを再起動します。

Reference contents:
– ブラウザからの SSH | Compute Engine ドキュメント | Google Cloud

Question 03

この問題については JencoMart のケーススタディ を参照してください。
JencoMart はユーザープロファイル ストレージを Google Cloud Datastore に移行し、アプリケーションサーバーを Google Compute Engine（GCE）に移行することを決定した。
移行中、既存のインフラストラクチャはデータをアップロードするために Google Cloud Datastore にアクセスする必要があります。
どのようなサービス アカウントの鍵管理戦略をお勧めしますか？

• A. オンプレミスのインフラストラクチャと GCE VM のサービス アカウント キーをプロビジョニングします。
• B. オンプレミスのインフラストラクチャにユーザー アカウントで認証し、VM に対してサービス アカウント キーをプロビジョニングします。
• C. オンプレミスのインフラストラクチャにサービス アカウント キーをプロビジョニングし、VM に Google が管理する暗号鍵を使用します。
• D. オンプレミスのインフラストラクチャに Google Kubernetes Engine のカスタム認証サービスを導入し、VM に Google が管理する暗号鍵を使用します。