【小ネタ】AWS Documentation MCP Server を使ってAWS認定試験のサンプル問題を作ってみた

mcp_json=$(cat <<EOF
{
  "command": "uvx",
  "args": ["awslabs.aws-documentation-mcp-server@latest"],
  "env": {
    "FASTMCP_LOG_LEVEL": "ERROR"
  },
  "disabled": false,
  "autoApprove": []
}
EOF
)

claude mcp add-json aws-documentation-mcp-server "${mcp_json}"
# Added stdio MCP server aws-documentation-mcp-server to local config

# AWS Certified DevOps Engineer - Professional サンプル問題の解答

## 質問 01の解答
**正解: D. CodeBuild プロジェクトの特権モードを有効にし、buildspec にて Docker デーモンを起動するコマンドを追加する**

### 解説
この問題は AWS CodeBuild を使用して Docker イメージをビルドする際に発生する一般的な問題に関するものです。
「Cannot connect to the Docker daemon」というエラーメッセージは、Docker デーモンに接続できないことを示しています。

選択肢の分析:

**A. S3 バケットから SSL 証明書をインストールするように CodeBuild プロジェクトを設定する**
- この選択肢は不適切です。SSL 証明書のインストールは、自己署名証明書を使用している
  プライベートリポジトリに接続する際の問題を解決するためのものであり、Docker デーモンの接続問題とは関係ありません。

**B. イメージビルドに使用する環境変数 `HTTP_PROXY` および `HTTPS_PROXY` の設定をクリアする**
- この選択肢も不適切です。プロキシ設定は主にネットワーク接続の問題に関連しており、
  Docker デーモンへの接続問題を解決するものではありません。

**C. CodeBuild プロジェクトを VPC 内に配置し、Docker レジストリにアクセスできるようにネットワーク設定を構成する**
- この選択肢は不適切です。VPC 設定は外部リソースへのアクセスに関する問題を解決するためのものであり、
  Docker デーモンの実行に関する問題とは直接関係ありません。

**D. CodeBuild プロジェクトの特権モードを有効にし、buildspec にて Docker デーモンを起動するコマンドを追加する**
- これが正解です。Docker イメージをビルドするには、CodeBuild プロジェクトで特権モードを有効にする必要があります。
  これにより Docker デーモンの起動と操作が可能になります。
  そして buildspec ファイルの install フェーズで Docker デーモンを起動するコマンドを追加する必要があります。

**E. Amazon ECR にあるカスタムビルドイメージに切り替え、Docker デーモンがプリインストールされたイメージを使用する**
- この選択肢は不適切です。カスタムビルドイメージに Docker デーモンがプリインストールされていても、
  Docker コンテナ内で Docker を実行するには特権モードが必要です。また、デーモンを起動するコマンドも必要となります。

実装手順:
1. CodeBuild コンソールでビルドプロジェクトを編集し、「環境」セクションの「追加設定」から「特権モード」を有効にします。
2. buildspec ファイルの install フェーズに以下のようなコマンドを追加して Docker デーモンを起動します：

```yaml
phases:
  install:
    commands:
      - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
      - timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
```

このアプローチは、CodeBuild 環境内で Docker デーモンを実行し、Docker コンテナのビルドと実行を可能にします。

### 参考ドキュメント
- [AWS CodeBuild のトラブルシューティング - Docker デーモンに接続できない場合のエラー](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html#troubleshooting-cannot-connect-to-docker-daemon)
- [Docker を使用するための CodeBuild のサンプル](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-docker-custom-image.html)

# AWS Certified DevOps Engineer - Professional サンプル問題 解答・解説

## 正解: D

Production OU に、重要なリソースの削除アクションを拒否し、承認された IAM ロールに例外を設ける SCP を適用する。
組織のルートに、IAM ユーザー作成を拒否する SCP を適用する。`FullAWSAccess` ポリシーはすべてのアカウントに対して保持する。

## 解説

この問題は AWS Organizations のサービスコントロールポリシー (SCP) の効果的な使用方法と、OU (組織単位) の階層構造を活用した権限管理に関するものです。
AWS Organizations のベストプラクティスに基づいて各選択肢を評価します。

### 選択肢 A が不正解である理由:

`FullAWSAccess` ポリシーを削除し、明示的に許可されたアクションのみを列挙した単一の SCP を組織のルートに適用するというアプローチは、
「許可リスト」アプローチと呼ばれます。このアプローチには以下の問題があります:

- 組織全体の全サービスに対する許可アクションをすべて列挙する必要があり、管理が非常に複雑になります。
- 新しい AWS サービスが導入された場合、SCP を更新しないとそのサービスにアクセスできなくなります。
- 本番環境と開発環境で異なるポリシーを適用することが困難です。

また、AWS の公式ドキュメントでは、SCP の管理を簡素化するために「拒否リスト」アプローチを推奨しています。

### 選択肢 B が不正解である理由:

この選択肢では SCP の「NotPrincipal」要素を使用していますが、SCP では IAM ポリシーとは異なり、
Principal または NotPrincipal 要素を使用できません。
SCP は IAM ユーザーやロールに直接アクセス権を付与するものではなく、
アカウント内で IAM ポリシーによって付与できる許可の最大範囲を定義するものです。

### 選択肢 C が不正解である理由:

CloudFormation と Service Catalog のみを使用してリソース管理を強制するというアプローチは、
リソース削除の問題に間接的に対処しますが、特定のユースケースでは制限が厳しすぎる可能性があります。
また、この方法では開発環境に制限を適用しないことで IAM ユーザー作成を禁止するという要件が満たされません。

### 選択肢 D が正解である理由:

この選択肢は AWS Organizations のベストプラクティスに沿った最適な解決策です:

1. **階層構造を活用した権限管理**: Production OU レベルで特定のリソース削除アクションを拒否することで、
   その OU 内のすべてのアカウントに制限が適用されます。これはOU構造を基に共通のコントロールを適用するというベストプラクティスに準拠しています。

2. **最小特権の原則の適用**: 承認された IAM ロールのみがリソース削除を実行できるという例外条件を設けることで、必要な権限のみを付与しています。

3. **拒否リストアプローチの採用**: `FullAWSAccess` ポリシーを保持し、特定のアクションのみを拒否することで、管理が容易になります。これは AWS が推奨するアプローチです。

4. **IAM ユーザー作成の禁止**: 組織のルートレベルで IAM ユーザー作成を拒否する SCP を適用することで、すべての OU とアカウントに適用されます。

5. **異なる環境に対する差別化された制御**: Production OU にのみ削除制限を適用し、Development OU には適用しないことで、
   開発者が開発環境で自由にリソースを作成・削除できるようにしています。

AWS Organizations では、複数の SCP がアカウントに適用される場合、アクションが許可されるためにはすべての適用可能な SCP で許可される必要があります。
拒否ステートメントが一つでもあれば、そのアクションは拒否されます。この挙動を理解することで、OU 階層の異なるレベルに SCP を適用する戦略を効果的に立てることができます。

## 参考ドキュメント

- [Best practices for managing organizational units (OUs) with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html)
- [Best practices for a multi-account environment](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html)
- [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)