WEB問題集
ある SaaS 企業では 4 つの AWS Account (dev / stg / prod / shared-tooling) で CI/CD を構築しています。要件として、パイプライン本体は shared-tooling のみに配置し、各環境への CFn デプロイは対応 Account で実行する必要があります。長期 Access Key は使用せず、本番前に Manual Approval を入れたうえで Source は CodeCommit を採用したいです。もっとも適切な構成はどれですか。
正解：A
正解の根拠
マルチアカウント CI/CD のベストプラクティスは、Tooling Account にパイプラインを集約しつつ Cross-Account IAM Role を介して各環境に委譲する構成です。Well-Architected の Operational Excellence と Security ピラーで推奨される標準パターンであり、長期 Access Key を排除しながら集中管理を実現できます。
典型構成
| Account | 役割 |
|---|---|
| shared-tooling | Pipeline 集約 |
| 各環境 | Execution Role を Trust |
不正解の理由
- B: Account ごとの独立 Pipeline は中央管理要件と相反するうえ、Artifact 同期も自前運用となり状態管理が破綻しやすい構成です。
- C: 長期 Access Key の共有はベストプラクティス違反であり、漏洩リスクとローテーション負荷が継続的に発生する設計です。
- D: 単一 Account 集約はアカウント分離要件に違反し、本番への誤操作による爆発半径が最大化する副作用があります。
ある E コマースサイトでは ECS Fargate 本番アプリで「稼働中リクエストを中断せず、5xx エラー率の急増で自動ロールバック」する仕組みを CodeDeploy で実装したいと考えています。検証期間として新版に 10% トラフィックを 15 分流してから 100% に切替える運用です。正しい記述を 2 つ選んでください。
（2つ選択）
正解：A, C
正解の根拠
CodeDeploy ECS Blue/Green はゼロダウンタイムと自動ロールバックを実現する標準パターンです。Hook 失敗と CloudWatch Alarm の双方を Auto-Rollback のトリガーに設定でき、本問の「5xx 急増で自動ロールバック」要件にも合致します。ECSCanary10Percent15Minutes 設定で本問の 10%/15 分要件も満たせます。
主要 Configuration
| 名称 | 動作 |
|---|---|
| Canary10Percent15Minutes | 10%→15 分→90% |
| Linear10PercentEvery3Min | 段階増分 |
不正解の理由
- B: Linear / Canary には複数バリエーションが存在し、カスタム Deployment Configuration を作成することも公式に可能となっています。
- D: ECS Rolling Update にも Deployment Circuit Breaker があり、連続失敗時の自動 Rollback も可能です。
- E: ECS Fargate は CodeDeploy Blue/Green の主要対象であり、Task Set 切替により Blue/Green が標準でサポートされています。
ある DevOps チームでは GitHub Actions から AWS リソース (Lambda / DynamoDB) のデプロイを自動化したいと考えています。GitHub Secrets に長期 IAM Access Key を保存しないアーキテクチャを採用したいですが、もっとも適切な実装はどれですか。
正解：B
正解の根拠
GitHub Actions OIDC Provider を IAM に登録し、Trust Policy で sub claim を厳格に制限することで、長期 Access Key を一切持たずに STS AssumeRoleWithWebIdentity で一時クレデンシャルを取得できます。これは AWS と GitHub の双方が公式推奨する Workload Identity Federation パターンです。
OIDC vs 長期キー比較
| 方式 | クレデンシャル | セキュリティ |
|---|---|---|
| OIDC + AssumeRole | 一時 (1 時間) | 高 |
| 長期 Access Key | 永続 | 低 |
| Self-hosted Runner | 一時 | 中 |
不正解の理由
- A: GitHub Secrets に長期 Access Key を保存する方式は漏洩リスクが残る副作用があり、ローテーション運用の負荷も継続的に発生する構成です。
- C: Self-hosted Runner は EC2 管理が必要となる副作用があり、運用負荷が GitHub-hosted Runner と比べ大幅に増加する構成となります。
- D: Cognito Identity Pool は GitHub Actions の認証連携用ではなく、設計目的が異なる副作用があり要件に整合しない組合せとなります。
ある CodeBuild プロジェクトでは Java アプリのビルドに毎回 5 分かかっており、そのうち ~/.m2 配下の Maven 依存解決が 3 分を占めています。月 100 ビルド × 複数ブランチで合計時間を削減したいと考えていますが、もっとも適切なキャッシュ戦略はどれですか。
正解：C
正解の根拠
S3 Cache を有効化し buildspec.yml の cache.paths に Maven のローカルリポジトリ (/root/.m2/**/*) を指定することで、Build Worker のインスタンスが破棄されても依存解決結果が永続化されます。複数ブランチや並列ビルドからもキャッシュを共有でき、3 分の依存解決時間を 30 秒程度まで短縮できます。
比較
| 種別 | 共有範囲 |
|---|---|
| S3 | 全 Worker |
| LOCAL | 同 Worker のみ |
不正解の理由
- A: SOURCE_CACHE は .git 履歴のみ保持する仕組みであり、Maven 依存ダウンロードの高速化には寄与しない機能です。
- B: DOCKER_LAYER_CACHE は Docker レイヤ専用で、Maven の ~/.m2 配下を自動キャッシュする機能は持たない設計です。
- D: Reserved Capacity は起動待ち時間の削減策にすぎず、ビルド本体 5 分のうち 3 分を占める依存解決には効果がありません。
ある SaaS では GitHub に置いた Source を CodePipeline で CI/CD 連携したいと考えています。長期 PAT を Pipeline 設定に保存することは禁止されており、長期 Webhook URL の運用負担も避けたいですが、もっとも適切な実装はどれですか。
正解：A
正解の根拠
AWS CodeStar Connections は GitHub OAuth App を一度承認するだけで、以降の Pipeline 起動時に短期トークンが自動委譲される仕組みです。長期 PAT を Pipeline 設定や Secrets に保存する必要がなく、Webhook URL の手動管理も不要となります。Connection ARN を Pipeline Source Action に指定するだけで、コミット検知から実行までを自動化できる現行の AWS 推奨方式です。
Source 連携方式比較
| 方式 | 長期キー | Webhook 管理 | 推奨度 |
|---|---|---|---|
| CodeStar Connections | 不要 | 自動 | AWS 推奨 |
| GitHub PAT (旧) | 必要 | 手動 | 非推奨 |
| EventBridge Polling | API Token 必要 | 不要だが遅延あり | 非効率 |
| GitHub Actions のみ | OIDC 可 | 不要 | CodePipeline 不使用シナリオ |
Connection 作成例
aws codestar-connections create-connection --provider-type GitHub --connection-name my-github-conn
# 返却された ARN を Pipeline Source の ConnectionArn に指定不正解の理由
- B: Actions 単独運用は CodePipeline の他機能 (Manual Approval / 多段 Stage / Cross-Account) を使えず、要件に対する後退となります。
- C: Polling 方式は変更検知に最大 5 分の遅延が生じ、API レート制限の課題もあります。
- D: PAT を Secrets Manager に置く方式は長期キーを完全には排除できず、Webhook 自動更新の自前実装も保守負荷が高くなります。