Associate Cloud Engineer（Google Cloud） 無料問題 1 / 10 ・ 分野4: アクセスとセキュリティの構成
サービス アカウントを1つの専用プロジェクトにまとめて作り、ほかのプロジェクトの VM に付けたい。サービス アカウントをリソースに付けるページに照らして、組織のポリシーの設定として正しいものはどれか。
- 組織のノードで iam.disableCrossProjectServiceAccountUsage を強制せず、各プロジェクトに継承させる
- VM を作るプロジェクトで、iam.disableCrossProjectServiceAccountUsage を強制する
- サービス アカウントのあるプロジェクトで、iam.disableCrossProjectServiceAccountUsage を強制しない
- VM を作るプロジェクトで、iam.disableCrossProjectServiceAccountUsage を強制しない
正解と解説を見る
正解: C
正解の理由
ページは、あるプロジェクトのサービス アカウントを別のプロジェクトのリソースに付けられるようにするには、サービス アカウントを含むプロジェクトの組織のポリシーを直す必要がある、と書く。確かめる制約の1つが iam.disableCrossProjectServiceAccountUsage で、これが強制されていないことを確かめる。この制約はプロジェクトをまたいでの付与を制御するもので、既定で強制されており、プロジェクトのレベルでしか設定できない。
違う選択肢
「組織のノードで iam.disableCrossProjectServiceAccountUsage を強制せず、各プロジェクトに継承させる」… この制約はプロジェクトのレベルでしか設定できず、フォルダや組織のレベルでは設定できない、とページは書く。
「VM を作るプロジェクトで、iam.disableCrossProjectServiceAccountUsage を強制しない」… 組織のポリシーを直すのは、サービス アカウントの入っているプロジェクトの側である。リソースを作る側のプロジェクトではない。
「VM を作るプロジェクトで、iam.disableCrossProjectServiceAccountUsage を強制する」… ページが直すよう書くのは、サービス アカウントの入っているプロジェクトの組織のポリシーである。しかもこの制約は、強制されていると別のプロジェクトのリソースにサービス アカウントを付けられなくするもので、強制する向きの設定は目的と逆になる。
補足
プロジェクトをまたぐ場合は、リソースを持つサービスのサービス エージェントに、そのサービス アカウントで Service Account Token Creator を付与する手順もある。いったん有効にした後で元に戻すことは、リソースが正しく動かなくなるおそれがあるとして、特に本番では強く勧めていない。