変更要約: Associate Cloud Engineer 第5章を新規作成（ドメイン5「アクセスとセキュリティ」: IAM ポリシーとロール＝基本/事前定義/カスタムロール・最小権限、サービスアカウント＝作成/最小権限/リソースへの割り当て/権限借用(impersonation)/短期間の認証情報）。
5.2サービスアカウント
アプリやワークロードが使うアイデンティティであるサービスアカウントの作成、最小権限での IAM ポリシーへの利用、リソースへの割り当て、サービスアカウントの権限借用（impersonation）、そして鍵を持たずに済む短期間の認証情報の発行を理解します。
人ではなくアプリやワークロードが使うアイデンティティが サービスアカウント です。VM や Cloud Run などがほかの Google Cloud サービスへアクセスする際に使います。サービスアカウントの安全な扱いが、運用セキュリティの要です。
5.2.1サービスアカウントの利用
サービスアカウントを作成し、IAM ポリシーで 最小権限 のロールを付与してから、VM や Cloud Run などの リソースに割り当て ます。割り当てられたワークロードは、その権限の範囲でほかのサービスにアクセスできます。重要なのは、人がサービスアカウントの権限を一時的に借りる 権限借用（impersonation） を使えば、強い権限を常時持たずに必要なときだけ実行できる点です。
5.2.2鍵と短期間の認証情報
サービスアカウントには長期間有効な 鍵（キー） を発行できますが、鍵は漏えいリスクがあり、できるだけ作らない・配らないのが安全です。代わりに、必要なときだけ発行する 短期間の認証情報（short-lived credentials） や、リソースに割り当てたサービスアカウントの自動認証を使います。「長期鍵を避け、リソースへの割り当て＋短期間の認証情報＋最小権限」が安全運用の定石です。
「要件 → 操作」が頻出。例：「アプリ/VM が他サービスにアクセス」＝サービスアカウントを割り当て、「人が一時的に強い権限で実行」＝権限借用（impersonation）、「長期鍵の漏えいを避けたい」＝短期間の認証情報、「サービスアカウントにも」＝最小権限。
混同に注意：
①サービスアカウント＝アプリ/ワークロードの ID（人ではない）。
②長期鍵は避け、割り当て＋短期間の認証情報を使う。
③サービスアカウントにも最小権限を適用（強すぎる権限を持たせない）。
④権限借用で常時の強権限を避ける。
5.2.3この節のまとめ
- サービスアカウント＝アプリ/ワークロードの ID。最小権限を付与しリソースに割り当てる
- 権限借用（impersonation）で、常時の強権限を避け必要時だけ実行
- 長期鍵は漏えいリスク＝避け、短期間の認証情報やリソース割り当ての自動認証を使う
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. VM 上のアプリが、人の認証情報を使わずに他の Google Cloud サービスへアクセスするために使うアイデンティティはどれですか？
Q2. サービスアカウントの長期鍵を作りたくない。漏えいリスクを下げる安全な方法はどれですか？
Q3. 人が強い権限を常時持たず、必要なときだけサービスアカウントの権限を一時的に借りて実行したい。使うのはどれですか？
Q4. サービスアカウントに権限を付与する際の原則として正しいものはどれですか？
Q5. Cloud Run のサービスが BigQuery にアクセスできるようにする適切な方法はどれですか？
Q6. サービスアカウントについて正しい説明はどれですか？