AWS Certified CloudOps Engineer - Associate (SOA-C03)

完全学習ガイド

試験概要

対象者

• AWS環境の日常運用・監視・障害対応を担うSRE・インフラエンジニア
• デプロイメント自動化・IaCを実装するCloudOpsエンジニア
• AWS環境のセキュリティ・コンプライアンス管理を担当するエンジニア

SOA-C02からの主な変更点

ドメイン別出題割合

┌───────────────────────────────────────────────────────────────────┐
│  Domain 1: 監視・ログ・分析・修復              22%  ███████████    │
│  Domain 2: 信頼性とビジネス継続性              22%  ███████████    │
│  Domain 3: デプロイ・プロビジョニング・自動化  22%  ███████████    │
│  Domain 4: セキュリティとコンプライアンス      16%  ████████       │
│  Domain 5: ネットワークとコンテンツ配信        18%  █████████      │
└───────────────────────────────────────────────────────────────────┘

Domain 1〜3 がそれぞれ22%で合計66%。運用・自動化・信頼性が中核。

Domain 1: 監視・ログ・分析・修復・パフォーマンス最適化（22%）

1.1 Amazon CloudWatch

import boto3

cloudwatch = boto3.client('cloudwatch')

# カスタムメトリクスの送信
cloudwatch.put_metric_data(
    Namespace='MyApp/Performance',
    MetricData=[{
        'MetricName': 'RequestLatency',
        'Value': 150.0,
        'Unit': 'Milliseconds',
        'Dimensions': [{'Name': 'Environment', 'Value': 'Production'}]
    }]
)

# アラーム作成（CPU使用率 > 80% で通知）
cloudwatch.put_metric_alarm(
    AlarmName='HighCPUUtilization',
    MetricName='CPUUtilization',
    Namespace='AWS/EC2',
    Statistic='Average',
    Period=300,          # 5分間の平均
    EvaluationPeriods=2, # 2回連続で閾値超え
    Threshold=80.0,
    ComparisonOperator='GreaterThanThreshold',
    Dimensions=[{'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}],
    AlarmActions=['arn:aws:sns:ap-northeast-1:123456789:ops-alert'],
    TreatMissingData='breaching'
)

CloudWatch の主要機能

1.2 AWS CloudTrail

# CloudTrailでAPI呼び出し履歴を確認
cloudtrail = boto3.client('cloudtrail')

response = cloudtrail.lookup_events(
    LookupAttributes=[
        {'AttributeKey': 'EventName', 'AttributeValue': 'DeleteBucket'},
        {'AttributeKey': 'Username', 'AttributeValue': 'john.doe'}
    ],
    StartTime='2025-01-01T00:00:00Z',
    EndTime='2025-12-31T23:59:59Z',
    MaxResults=50
)

1.3 AWS Config

# AWS Config: リソース設定の継続的評価
config = boto3.client('config')

# セキュリティグループが0.0.0.0/0を許可しているか確認するルール
config.put_config_rule(
    ConfigRule={
        'ConfigRuleName': 'restricted-ssh',
        'Source': {
            'Owner': 'AWS',
            'SourceIdentifier': 'INCOMING_SSH_DISABLED'
        }
    }
)

Domain 2: 信頼性とビジネス継続性（22%）

2.1 高可用性設計

マルチAZ構成（標準）:
                    Route 53 (フェイルオーバー)
                         ↓
              ┌──────────────────────┐
              │   Application LB      │
              └──────────────────────┘
              ↓              ↓
        AZ-a (ap-ne-1a)  AZ-b (ap-ne-1c)
        EC2 Auto Scaling  EC2 Auto Scaling
              ↓              ↓
        RDS Primary     RDS Standby (Multi-AZ)

2.2 Auto Scaling

autoscaling = boto3.client('autoscaling')

# スケーリングポリシー（ターゲット追跡）
autoscaling.put_scaling_policy(
    AutoScalingGroupName='my-asg',
    PolicyName='cpu-target-tracking',
    PolicyType='TargetTrackingScaling',
    TargetTrackingConfiguration={
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'ASGAverageCPUUtilization'
        },
        'TargetValue': 60.0,   # CPU 60%を維持
        'ScaleInCooldown': 300,
        'ScaleOutCooldown': 60
    }
)

2.3 バックアップと災害対策

# AWS Backup: 一元的なバックアップ管理
backup = boto3.client('backup')

backup.create_backup_plan(
    BackupPlan={
        'BackupPlanName': 'daily-backup',
        'Rules': [{
            'RuleName': 'daily',
            'TargetBackupVaultName': 'my-vault',
            'ScheduleExpression': 'cron(0 2 * * ? *)',  # 毎日02:00
            'Lifecycle': {
                'DeleteAfterDays': 35,         # 35日後に削除
                'MoveToColdStorageAfterDays': 7 # 7日後にコールドストレージへ
            }
        }]
    }
)

Domain 3: デプロイ・プロビジョニング・自動化（22%）

3.1 AWS CloudFormation

# CloudFormation テンプレート例
AWSTemplateFormatVersion: '2010-09-09'
Description: Web Application Stack

Parameters:
  EnvironmentType:
    Type: String
    AllowedValues: [dev, staging, prod]
    Default: dev

Conditions:
  IsProduction: !Equals [!Ref EnvironmentType, prod]

Resources:
  WebServerInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !If [IsProduction, m5.xlarge, t3.medium]
      ImageId: !Sub '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2}}'
      SecurityGroupIds:
        - !Ref WebSecurityGroup
      Tags:
        - Key: Environment
          Value: !Ref EnvironmentType

  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Web server security group
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

Outputs:
  InstanceId:
    Value: !Ref WebServerInstance
    Export:
      Name: !Sub '${AWS::StackName}-InstanceId'

3.2 AWS Systems Manager

ssm = boto3.client('ssm')

# Run Command: 複数インスタンスへの一括実行
response = ssm.send_command(
    Targets=[{'Key': 'tag:Environment', 'Values': ['Production']}],
    DocumentName='AWS-RunShellScript',
    Parameters={'commands': ['yum update -y', 'systemctl restart nginx']},
    TimeoutSeconds=600
)

# Parameter Store: 設定値取得（SecureString対応）
param = ssm.get_parameter(
    Name='/myapp/prod/db-password',
    WithDecryption=True  # KMSで復号
)

3.3 AWS OpsWorks / Elastic Beanstalk

3.4 コンテナ運用（SOA-C03 新規スコープ）

ecs = boto3.client('ecs')

# ECSサービスのデプロイ（ローリングアップデート）
ecs.update_service(
    cluster='production-cluster',
    service='web-service',
    taskDefinition='web-task:5',
    deploymentConfiguration={
        'maximumPercent': 200,
        'minimumHealthyPercent': 100,
        'deploymentCircuitBreaker': {
            'enable': True,
            'rollback': True  # デプロイ失敗時に自動ロールバック
        }
    }
)

Domain 4: セキュリティとコンプライアンス（16%）

4.1 IAMのベストプラクティス

iam = boto3.client('iam')

# パスワードポリシー設定
iam.update_account_password_policy(
    MinimumPasswordLength=14,
    RequireSymbols=True,
    RequireNumbers=True,
    RequireUppercaseCharacters=True,
    RequireLowercaseCharacters=True,
    MaxPasswordAge=90,
    PasswordReusePrevention=12,
    HardExpiry=False
)

# MFA強制ポリシー（MFAなしはパスワード変更のみ許可）
mfa_policy = {
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                      "iam:GetUser", "iam:ChangePassword"],
        "Resource": "*",
        "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }]
}

4.2 AWS Security Hub / GuardDuty

Domain 5: ネットワークとコンテンツ配信（18%）

5.1 VPCトラブルシューティング

疎通確認フロー:
EC2 → ENI → セキュリティグループ（ステートフル）
          → サブネットのルートテーブル
          → NACL（ステートレス・インバウンド＋アウトバウンド両方必要）
          → インターネットゲートウェイ / NAT Gateway

ec2 = boto3.client('ec2')

# VPC Flow Logsの有効化（トラブルシューティングに必須）
ec2.create_flow_logs(
    ResourceIds=['vpc-xxxxxxxx'],
    ResourceType='VPC',
    TrafficType='ALL',
    LogDestinationType='cloud-watch-logs',
    LogGroupName='/aws/vpc/flowlogs',
    DeliverLogsPermissionArn='arn:aws:iam::123456789:role/flowlogs-role'
)

5.2 Route 53 ルーティングポリシー

5.3 CloudFront

cloudfront = boto3.client('cloudfront')

# CloudFront Distributionの無効化（キャッシュパージ）
cloudfront.create_invalidation(
    DistributionId='EDFDVBD6EXAMPLE',
    InvalidationBatch={
        'Paths': {'Quantity': 1, 'Items': ['/images/*']},
        'CallerReference': 'invalidation-001'
    }
)

試験頻出パターン

Q1: CloudWatch vs CloudTrail vs Config

問題: 本番EC2インスタンスのセキュリティグループが誰によっていつ変更されたかを調査したい。

解答: AWS CloudTrail。APIコール（誰が・何を・いつ）の履歴を記録。CloudWatchはメトリクス・パフォーマンス監視、ConfigはリソースのBefore/After設定変更の追跡。

Q2: 障害切り替え

問題: プライマリリージョン障害時に自動でDRサイトへ切り替えたい。RPOは15分以内。

解答: Route 53 フェイルオーバールーティング + RDS クロスリージョンリードレプリカの昇格。ヘルスチェックがプライマリの異常を検知すると自動でDNSをセカンダリに切り替え。

Q3: Systems Manager活用

問題: 踏み台サーバーなしでプライベートサブネットのEC2にアクセスし、パッチを適用したい。

解答: SSM Session Manager（SSH不要・パブリックIPなしで接続）+ Patch Manager（パッチ自動適用スケジュール）。セキュリティグループでポート22を開ける必要なし。

Q4: Auto Scalingの動作

問題: Auto Scalingグループでスケールイン時に特定のインスタンスを先に終了させたくない（ステートを持つインスタンス）。

解答: Instance Scale-In Protection をそのインスタンスに設定。Auto Scalingのスケールイン対象から除外される。

Q5: コンテナ運用

問題: ECSサービスの新バージョンデプロイで、問題があった場合に自動でロールバックしたい。

解答: Deployment Circuit Breaker を有効化し rollback: true を設定。デプロイ失敗率が閾値を超えると自動で以前のタスク定義にロールバック。

試験重要数値

8週間学習プラン

Week 1-2: 監視・ログ基盤

• [ ] CloudWatch メトリクス・アラーム・ダッシュボード構築
• [ ] CloudWatch Logs + Log Insights クエリ実践
• [ ] CloudTrail + AWS Config 設定・確認
• [ ] AWS Health Dashboard の活用

Week 3-4: 信頼性・DR

• [ ] Auto Scaling（ターゲット追跡・スケジュール）実践
• [ ] RDS Multi-AZ・リードレプリカ設定
• [ ] AWS Backup でのバックアップポリシー設定
• [ ] Route 53 フェイルオーバー構成ハンズオン

Week 5-6: デプロイ・自動化

• [ ] CloudFormation スタック作成・更新・ロールバック
• [ ] Systems Manager（Session Manager・Patch Manager・Run Command）
• [ ] ECS / EKS 基本運用（SOA-C03新規スコープ）
• [ ] Elastic Beanstalk デプロイポリシー

Week 7-8: セキュリティ + 試験対策

• [ ] GuardDuty・Security Hub・Inspector 設定
• [ ] VPC Flow Logs・ネットワークトラブルシューティング
• [ ] AWS公式模擬試験
• [ ] 苦手ドメイン集中復習

SOA-C03 追加詳解・模擬問題集

CloudWatch 深掘り

CloudWatch メトリクスの詳細

メトリクスの種類:
  標準メトリクス（Standard Metrics）:
    → AWSサービスが自動的に送信する組み込みメトリクス
    → EC2: CPUUtilization, NetworkIn, NetworkOut, StatusCheckFailed等
    → 無料で利用可能

  カスタムメトリクス（Custom Metrics）:
    → アプリケーションが PutMetricData APIで送信するメトリクス
    → 例: ビジネスKPI、アプリエラー数、メモリ使用率（EC2は標準では提供されない）
    → 高解像度カスタムメトリクス: 1秒解像度まで可能（追加料金）

EC2で標準収集されない（カスタムが必要な）メトリクス:
  → メモリ使用率（Memory）
  → ディスク使用率（Disk Utilization）
  → CloudWatch Agentのインストールが必要

CloudWatch Logs Insights

用途: 大量のログデータを高速にクエリ・分析

クエリ例:
  fields @timestamp, @message
  | filter @logStream like /prod/
  | filter @message like /ERROR/
  | stats count(*) as errorCount by bin(5m)
  | sort errorCount desc

主な機能:
  → 複数ロググループをまたいだクエリ
  → 統計集計（count/sum/avg/min/max）
  → 時系列グラフの生成
  → CloudWatch Dashboardに埋め込み可能

CloudWatch Alarmのベストプラクティス

アラーム設定のポイント:
  評価期間（Evaluation Periods）:
    → 閾値を何回連続で超えたらアラームにするか
    → 瞬間的なスパイクでアラームしないようにする

  欠損データの扱い（Missing Data）:
    → breaching: データ欠損をアラーム状態として扱う
    → notBreaching: 正常として扱う（推奨：停止を検知）
    → ignore: 現在の状態を維持
    → missing: 状態をINSUFFICIENT_DATAに変更

Composite Alarm:
  → 複数のアラームをAND/OR条件で組み合わせ
  → アラームストーム防止（複数の個別アラームが同時に鳴るのを抑制）
  例: CPUHighAlarm AND NetworkHighAlarm → 本番インシデント通知

AWS Config 詳細

Config の主要機能:
  1. リソースの設定記録（Configuration Recording）
     → AWSリソースの設定変更を継続的に記録
     → 「このS3バケットの暗号化設定はいつ変更されたか？」
  
  2. Config Rules（コンプライアンスルール）
     → 設定が組織のルールに準拠しているか評価
     → AWS管理ルール（130以上）またはカスタムルール
     → 例: ec2-instances-in-vpc, s3-bucket-public-read-prohibited
  
  3. 変更履歴（Configuration History）
     → リソースの設定変更の全履歴
     → セキュリティ調査・コンプライアンス監査に使用
  
  4. コンフォーマンスパック（Conformance Packs）
     → 複数のConfig Rulesをパッケージ化
     → PCI DSS, HIPAA等のコンプライアンスパック

CloudTrail vs Config vs CloudWatch の違い（試験最頻出）:
  CloudTrail: 「誰が何のAPIを呼んだか」（操作の監査ログ）
  Config: 「リソースの設定がどう変わったか」（設定変更履歴）
  CloudWatch: 「システムのパフォーマンス・メトリクス」（監視・アラーム）

Systems Manager 詳細

SSM Session Manager

機能:
  → SSH/RDPなしでEC2インスタンスにブラウザベースでアクセス
  → SSMエージェントがインストールされていれば利用可能
  → セッションは CloudTrail に記録される
  → キーペア（SSH鍵）が不要

メリット:
  → インバウンドポート22/3389を開放不要（セキュリティ向上）
  → SSH鍵の管理が不要
  → セッションログをS3/CloudWatch Logsに保存（監査）
  → VPCエンドポイント経由でプライベートアクセス可能

SSM Patch Manager

機能:
  → EC2インスタンスのOSパッチを自動適用・管理

パッチベースライン（Patch Baseline）:
  → どのパッチを承認するかのルール定義
  → 重大度・分類でフィルタリング
  → 承認遅延（パッチリリースから何日後に適用するか）

メンテナンスウィンドウ（Maintenance Window）:
  → パッチ適用のスケジュール設定
  → 例: 毎週日曜日2-4時にパッチ適用
  → ターゲット: インスタンスタグで指定

SSM Parameter Store vs Secrets Manager

CloudFormation 詳細

スタック更新戦略:
  変更セット（Change Set）:
    → 実際に更新する前に変更内容をプレビュー
    → 「この更新でRDSが置き換えられる」ことを事前に確認

  スタックポリシー（Stack Policy）:
    → 特定リソースの更新・削除を保護
    → 本番RDSやDynamoDBの誤削除を防止

  ドリフト検出（Drift Detection）:
    → スタックとデプロイ済みリソースの差分を検出
    → 手動変更が加えられたリソースを特定

ネストされたスタック（Nested Stacks）:
  → 大型テンプレートを分割して再利用性を高める
  → VPCスタック + EC2スタック + RDSスタック を組み合わせる
  
クロススタック参照（Cross-Stack References）:
  → スタック間でOutputsを参照
  → ExportsでVPC IDを公開 → 別スタックでImportValueで参照

模擬問題（SOA-C03本番形式 65問相当）

問題 SOA-01

EC2インスタンスのメモリ使用率を CloudWatch でモニタリングしたい。最も適切な方法はどれですか？

• A. EC2の標準メトリクスからMemoryUtilizationを選択する
• B. CloudWatch Agentをインストールしてカスタムメトリクスを送信する
• C. CloudTrailを使ってメモリ使用率を記録する
• D. AWS Configでメモリルールを定義する

問題 SOA-02

「S3バケットのパブリックアクセスが有効化されていないか」を継続的に監視し、非準拠を検知したい。最も適切なサービスはどれですか？

• A. AWS CloudTrail
• B. Amazon GuardDuty
• C. AWS Config（s3-bucket-public-read-prohibited ルール）
• D. Amazon Inspector

問題 SOA-03

SSM Session Managerの主なメリットとして正しいものはどれですか？（2つ選択）

• A. SSH鍵（キーペア）なしでEC2インスタンスにアクセスできる
• B. インバウンドポート22を開放する必要がなくなる
• C. EC2インスタンスのOSパッチを自動適用する
• D. CloudTrailへのAPI記録を無効化できる
• E. Auto Scalingを自動的に設定する

問題 SOA-04

CloudWatch、CloudTrail、AWS Configのそれぞれの主な用途として正しい組み合わせはどれですか？

• A. CloudWatch=設定変更履歴、CloudTrail=メトリクス、Config=API監査
• B. CloudWatch=メトリクス・ログ・アラーム、CloudTrail=API操作監査、Config=リソース設定変更履歴
• C. CloudWatch=API監査、CloudTrail=設定変更、Config=メトリクス
• D. 3つのサービスは全て同じ目的で使用する

問題 SOA-05

CloudFormationスタックを更新する前に「この更新でRDSインスタンスが置き換えられるか確認したい」場合、最も適切なアプローチはどれですか？

• A. スタックを直接更新して結果を確認する
• B. 変更セット（Change Set）を作成して変更内容をプレビューする
• C. AWS Configのドリフト検出を実行する
• D. CloudTrailで変更履歴を確認する

問題 SOA-06

Elastic Beanstalkで「デプロイ中もキャパシティを100%維持し、問題があれば最速でロールバックしたい」場合、最も適切なデプロイポリシーはどれですか？

• A. All at once
• B. Rolling
• C. Immutable
• D. Blue/Green

問題 SOA-07

SSM Patch Managerで「本番環境のEC2インスタンスに毎週日曜日の深夜2時にパッチを適用したい」場合に必要な設定はどれですか？

• A. CloudWatch EventsでEC2再起動をスケジュールする
• B. メンテナンスウィンドウ（Maintenance Window）を毎週日曜2時に設定する
• C. Lambda関数で毎週日曜2時にSSM SendCommandを実行する
• D. Auto Scalingのスケジュールでパッチ適用を設定する

問題 SOA-08

「誰かが本番S3バケットの暗号化設定を無効にした。いつ、誰が変更したかを調査したい」場合、最初に確認するサービスはどれですか？

• A. Amazon CloudWatch Metrics
• B. AWS CloudTrail の Event History
• C. AWS Config の設定変更履歴
• D. Amazon GuardDuty

問題 SOA-09

AWS Auto Scalingグループで「CPUが70%以上になったら2分以内にスケールアウトし、50%以下が続いたら5分後にスケールインしたい」場合、最も適切なスケーリングポリシーはどれですか？

• A. シンプルスケーリング（独立した2つのポリシー）
• B. ステップスケーリング
• C. ターゲット追跡スケーリング（CPU使用率60%目標）
• D. スケジュールドスケーリング

問題 SOA-10

「RDSインスタンスのディスク容量が90%を超えたらSlack通知を送りたい」最も適切なアーキテクチャはどれですか？

• A. CloudWatch Alarm → SNS → Lambda（Slack通知）
• B. CloudTrail → S3 → Lambda（Slack通知）
• C. AWS Config → EventBridge → Slack
• D. GuardDuty → CloudWatch → Slack

SOA-C03 試験合格のための学習戦略

試験直前チェックリスト（SOA）

監視・ログ（Domain 1）

• [ ] CloudWatch vs CloudTrail vs Config の使い分け
• [ ] EC2の標準メトリクスに含まれないものとCW Agentの必要性
• [ ] CloudWatch Logs Insights のクエリ構文
• [ ] CloudWatch Alarmのステート（OK/ALARM/INSUFFICIENT_DATA）

信頼性・DR（Domain 2）

• [ ] RDS Multi-AZ フェイルオーバーの仕組み
• [ ] バックアップと PITR の違い
• [ ] Auto Scaling スケーリングポリシー3種の違い

デプロイ・自動化（Domain 3）

• [ ] CloudFormation変更セット・スタックポリシーの用途
• [ ] Systems Manager Session Manager のメリット
• [ ] SSM Patch Manager のメンテナンスウィンドウ設定
• [ ] Elastic Beanstalk デプロイポリシー5種

セキュリティ（Domain 4）

• [ ] SSM Parameter Store vs Secrets Manager の使い分け
• [ ] AWS Config Rules でのコンプライアンス評価

付録: SOA-C03 頻出サービス一覧

CloudWatch 高度な機能

CloudWatch Container Insights

対応サービス: Amazon ECS、Amazon EKS、Kubernetes on EC2

収集されるメトリクス:
  ECS: CPU使用率、メモリ使用率（タスク/サービス/クラスター）
  EKS: Pod、Node、Namespace レベルのメトリクス
  
セットアップ:
  ECS: CloudWatch エージェントをサイドカーコンテナとして起動
  EKS: CloudWatch エージェントを DaemonSet としてデプロイ

Container Insights のログ:
  コンテナの stdout/stderr を CloudWatch Logs に自動収集
  構造化ログ（JSON）は Logs Insights で分析可能

CloudWatch Synthetics（カナリア）

Synthetics の仕組み:
  スケジュールで自動的に HTTP エンドポイントをテスト
  Node.js または Python で書かれたスクリプトを実行
  結果を S3（スクリーンショット/HAR）と CloudWatch メトリクスに保存

カナリアタイプ:
  API Canary: REST API のエンドポイントを監視
  Broken Link Checker: ウェブページのリンク切れを検出
  Heartbeat Monitor: URL の可用性を定期チェック
  GUI Workflow: ユーザー操作のシミュレーション
  Canary Recorder: Chrome 拡張で録画したワークフローを再生

メリット:
  本番ユーザーが影響を受ける前に問題を検出
  E2E テストの自動実行
  SLA 監視

CloudWatch Application Insights

Application Insights の機能:
  .NET および SQL Server アプリの自動監視設定
  リソース間の関係を自動検出
  問題発生時の根本原因分析を支援

サポートされるリソースグループ:
  EC2 上の .NET アプリ
  RDS（SQL Server/MySQL/PostgreSQL）
  ELB、Auto Scaling グループ
  ECS on EC2

異常検出:
  ML ベースの異常検知で通常のパターンから逸脱を検出
  CloudWatch Alarms の動的しきい値

AWS Config 高度な機能

Config Rules 詳細リファレンス

よく出る AWS マネージドルール:

IAM関連:
  iam-root-access-key-check: ルートアカウントのアクセスキー禁止
  iam-user-mfa-enabled: 全 IAM ユーザーに MFA を要求
  iam-password-policy: パスワードポリシーの設定確認
  access-keys-rotated: アクセスキーのローテーション確認

S3関連:
  s3-bucket-public-read-prohibited: パブリック読み取り禁止
  s3-bucket-server-side-encryption-enabled: サーバー側暗号化必須
  s3-bucket-logging-enabled: アクセスログの有効化確認
  s3-bucket-versioning-enabled: バージョニングの有効化確認

EC2関連:
  ec2-instance-no-public-ip: パブリック IP 禁止
  ec2-encrypted-volumes: EBS 暗号化を要求
  ec2-imdsv2-check: IMDSv2 の強制確認
  restricted-ssh: SSH（22番ポート）のパブリックアクセス禁止

RDS関連:
  rds-instance-public-access-check: パブリックアクセス禁止
  rds-storage-encrypted: ストレージ暗号化を要求
  rds-multi-az-support: Multi-AZ 有効化確認
  rds-automatic-minor-version-upgrade-enabled: マイナーバージョン自動更新

Config コンフォーマンスパック

コンフォーマンスパックとは:
  複数の Config ルールと修復アクションをひとまとめにしたパッケージ
  
AWS 提供のサンプルテンプレート:
  Operational Best Practices for S3
  Operational Best Practices for EC2
  Operational Best Practices for IAM
  Operational Best Practices for PCI-DSS
  AWS Control Tower Detective Guardrails
  
Organizations 全体への展開:
  StackSets または Organizations のコンフォーマンスパックで
  全アカウントに一括展開

Systems Manager 高度な機能

SSM Distributor

Distributor の機能:
  カスタムソフトウェアパッケージを作成・管理・配布
  AWS が提供するパッケージも利用可能（CloudWatch Agent等）
  
パッケージの配布:
  対象: SSM エージェントが動作する EC2/オンプレミス
  方法: Run Command または State Manager
  スケジュール: State Manager で定期的に最新版を確認
  
ユースケース:
  - 社内セキュリティエージェントの配布・更新
  - 監視エージェント（Datadog/Splunk）の自動インストール
  - カスタムスクリプト/設定ファイルの配布

SSM Inventory 詳細

収集できる情報:
  Applications: インストールされたアプリケーション一覧
  Files: 指定したファイルのメタデータ
  Network Config: ネットワーク設定
  Windows Registry: レジストリキーの値
  Windows Updates: Windows Update の適用状況
  Services: Windows サービスの一覧・状態
  Custom Inventory: 独自のインベントリデータ（JSON）

資産管理での活用:
  インベントリデータを S3 に保存 → Athena でクエリ
  AWS Config との連携でコンプライアンス確認
  サードパーティ CMDB（資産管理）システムへのエクスポート

EventBridge 詳細

EventBridge Pipes

Pipes の概念:
  単一のルートでデータを一方向に変換・転送
  
  Source（ポーリング対象）:
    SQS / DynamoDB Streams / Kinesis Streams / Kafka / MQ
  
  Filter（省略可）:
    特定の条件のメッセージのみを処理
    
  Enrichment（省略可）:
    データ変換/外部APIコール
    Lambda / Step Functions / API Gateway / EventBridge API Destination
    
  Target（転送先）:
    60以上のサービス（Lambda/ECS/SQS/SNS/Step Functions等）

ユースケース:
  DynamoDB Streams → Pipes → OpenSearch（変更内容をリアルタイムインデックス）
  SQS → Pipes（フィルタリング） → Lambda（該当メッセージのみ処理）

EventBridge Scheduler

スケジューラーの種類:
  One-time: 指定した1回だけ実行
  Rate: 一定間隔（例: 5分ごと）
  Cron: 特定の時刻（例: 毎週月曜 09:00 JST）

特徴:
  クロスアカウント/クロスリージョンのターゲット実行
  タイムゾーンサポート（日本時間など）
  失敗時のリトライ設定
  DLQ サポート
  
vs CloudWatch Events/EventBridge ルール:
  EventBridge Scheduler: より多くのターゲット、柔軟なスケジュール
  CloudWatch Events/EventBridge ルール: AWS サービスイベントとの統合が強力

模擬試験追加問題（40問）

問題 8

CloudWatch のカスタムメトリクスを使って、アプリケーションのビジネスメトリクス（注文数/エラー数等）を監視しています。コストを最小化しながら最大の粒度を確保する設定はどれですか？

• A. 1秒間隔の高解像度メトリクスを使用する
• B. 1分間隔のカスタムメトリクスを使用する
• C. 5分間隔のカスタムメトリクスを使用する
• D. CloudWatch Synthetics を使用する

問題 9

EC2 Auto Scaling グループで「インスタンスのウォームアップ」設定が重要な理由はどれですか？

• A. インスタンスのセキュリティパッチを適用するため
• B. 新しいインスタンスが完全に準備完了になる前にスケーリングメトリクスに影響を与えないようにするため
• C. インスタンスの料金を節約するため
• D. コールドスタートを防ぐため

問題 10

AWS Systems Manager Session Manager を使用するメリットとして正しいものはすべて選んでください。（3つ選択）

• A. SSH/RDP ポートを開放する必要がない
• B. すべてのセッションが CloudTrail と CloudWatch Logs に記録される
• C. 踏み台サーバーが不要になる
• D. IAM ポリシーは不要になる
• E. インスタンスが VPC 外部にある場合のみ使用できる

問題 11

CloudFormation スタックが UPDATE_ROLLBACK_FAILED 状態になっています。次に取るべきアクションは何ですか？

• A. スタックを削除して再作成する
• B. ContinueUpdateRollback API を呼び出してロールバックを再試行する
• C. CloudFormation サポートに連絡する
• D. スタックをそのまま使い続ける

aws cloudformation continue-update-rollback     --stack-name MyStack     --resources-to-skip MyProblematicResource

問題 12

AWS Config の「評価モード」について、「Detective（検出）」と「Proactive（プロアクティブ）」の違いはどれですか？

• A. Detective はリアルタイムで検出し、Proactive は毎時間バッチで検出する
• B. Detective はデプロイ後のリソースを評価し、Proactive は CloudFormation デプロイ前にリソースを評価する
• C. Detective は本番環境用、Proactive はテスト環境用
• D. 機能的な違いはない

問題 13〜47（ショート形式）

問題 13: CloudWatch の「複合アラーム（Composite Alarm）」の用途は？ → 正解: 複数のアラームを AND/OR で組み合わせた複合条件を作成。例: 「CPU高 AND ネットワーク高 AND 営業時間外」の場合のみアラーム。アラームの「ノイズ」を削減し、真に重要な状態のみ通知

問題 14: SSM Parameter Store の advanced tier パラメータと standard tier の違いは？ → 正解: Standard: 無料（10,000 パラメータ、4KB/パラメータ）。Advanced: 有料（$0.05/パラメータ/月、100,000 パラメータ、8KB/パラメータ、パラメータポリシー/通知が使用可能）

問題 15: CloudWatch Logs の「サブスクリプションフィルター」の用途は？ → 正解: ロールグループのログをリアルタイムで別サービスに転送。転送先: Lambda（処理/変換）、Kinesis Streams（大量ログの収集）、Kinesis Firehose（S3/OpenSearch への転送）。セキュリティ分析や中央ログ集約に使用

問題 16: Systems Manager の「アソシエーション（Association）」の設定で重要なポイントは？ → 正解: State Manager の「アソシエーション」はドキュメントとターゲットを結びつけて実行スケジュールを定義。compliance-severity を設定すると Config/Security Hub にコンプライアンス結果を報告。最大同時実行数/エラー許容率を設定

問題 17: EventBridge の「スキーマレジストリ」の用途は？ → 正解: イベントの構造（スキーマ）を自動検出・保存するサービス。サービスからのイベントスキーマを自動的に発見し、SDK/コードバインディングを自動生成。型安全なイベント処理コードを生成できる

問題 18: CloudFormation の「スタックセット」でデプロイが一部のアカウントで失敗した場合の動作は？ → 正解: フォールトトレランス設定（--fault-tolerance-count または --fault-tolerance-percentage）に基づいて動作。許容範囲内なら失敗したアカウントをスキップして他を継続。許容範囲を超えると全体をロールバック

問題 19: AWS OpsWorks と Systems Manager の使い分けは？ → 正解: OpsWorks: Chef/Puppet ベースの設定管理（既存の Chef/Puppet 資産を活用したい場合）。Systems Manager: AWS ネイティブの運用自動化（AWS 環境専用、SSM Agent ベース、より多くの AWS サービス統合）

問題 20: CloudWatch の「メトリクス数学（Metric Math）」の活用例は？ → 正解: 複数のメトリクスを演算して新しいメトリクスを作成。例: エラー率 = (エラー数 / 総リクエスト数) × 100。スループット = SUM(リクエスト) / PERIOD。グラフや アラームに数式メトリクスを使用可能

問題 21: AWS Systems Manager の「カスタムインベントリ」を使用する目的は？ → 正解: AWS 標準のインベントリ項目以外の独自データを収集。例: アプリケーションのバージョン情報、カスタム設定、ライセンス情報。EC2 インスタンス上の /aws/ssm/inventory/ にJSON ファイルを配置して SSM が収集

問題 22: CloudTrail の「Organization Trail」を作成するメリットは？ → 正解: Organizations の全メンバーアカウントのイベントを自動収集。メンバーアカウントから無効化不可（変更不可）。中央の S3 バケットにログを集約。新しいメンバーアカウント追加時に自動的に適用

問題 23: CloudWatch Alarm の「OK_ACTIONS」の用途は？ → 正解: アラームが ALARM 状態から OK 状態に戻ったときに実行するアクション。例: Slack 通知「問題が解決しました」。Auto Scaling でスケールインアクション。EC2 インスタンスの再起動から復旧した場合の通知

問題 24: AWS Config の「自動修復（Automatic Remediation）」で失敗した場合の再試行設定は？ → 正解: 修復設定で MaximumAutomaticAttempts（最大 25 回）と RetryAttemptSeconds（再試行間隔）を設定。失敗が続く場合は SNS で通知。過剰な実行を防ぐためにしきい値を適切に設定

問題 25: Systems Manager の「Maintenance Window」で設定できる「Targets」の種類は？ → 正解: (1) インスタンス ID を直接指定、(2) タグで動的指定（例: Env=Production）、(3) リソースグループ。ターゲット選択により動的に変化する環境にも対応

問題 26: CloudWatch Logs Insights の parse コマンドの用途は？ → 正解: ログメッセージから特定のパターンに一致するフィールドを抽出。例: parse @message "user=* action=* duration=*ms" as user, action, duration で非構造化ログを構造化データとして分析

問題 27: EventBridge の「デッドレターキュー（DLQ）」はどのような場合に使用しますか？ → 正解: イベントのデリバリーが失敗した場合（ターゲットが応答しない、権限エラー等）に失敗したイベントを SQS に保存。後から分析・再処理が可能。DLQ なしでは失敗したイベントが失われる

問題 28: CloudFormation スタックの「出力値（Output）」をエクスポートしない場合とFn::ImportValueの関係は？ → 正解: Export セクションで名前をつけてエクスポートしないと Fn::ImportValue では参照できない。エクスポートした値はリージョン内で一意でなければならない。エクスポートを削除するには参照しているスタックを先に削除

問題 29: CloudWatch の「埋め込みメトリクスフォーマット（EMF）」を Lambda で使用するメリットは？ → 正解: ログにメトリクスデータを埋め込んで、ログとメトリクスを同時に生成。aws-embedded-metrics SDK を使用。PutMetricData API を別途コールする必要なく、コストを削減しながらカスタムメトリクスを収集

問題 30: AWS Systems Manager の「ハイブリッドアクティベーション（Hybrid Activation）」の目的は？ → 正解: オンプレミスサーバーや他クラウドの VM を Systems Manager で管理するための登録プロセス。アクティベーションコードと ID を発行 → オンプレミスサーバーに SSM Agent をインストール → SSM に登録。EC2 と同様の管理が可能

問題 31: EC2 Auto Scaling の「インスタンスリフレッシュ（Instance Refresh）」の動作は？ → 正解: 指定した最小正常率を維持しながら古いインスタンスを新しい Launch Template/Configuration で置き換え。AMI の更新やセキュリティパッチ適用に使用。CheckpointPercentages でウェーブ的に更新可能

問題 32: CloudWatch の「リアルタイム処理ログ（Kinesis Data Streams へのサブスクリプション）」が必要なシナリオは？ → 正解: セキュリティイベントのリアルタイム処理（GuardDuty/CloudTrail ログ）、大規模ログの集約分析（複数アカウントのログを中央に集約）、Splunk/SIEM へのリアルタイム転送

問題 33: Systems Manager の「コンプライアンス（Compliance）」ダッシュボードで確認できる情報は？ → 正解: パッチコンプライアンス（Patch Manager）、アソシエーションコンプライアンス（State Manager）、カスタムコンプライアンスアイテム。インスタンスごとの準拠/非準拠状態。セキュリティ監査レポートに活用

問題 34: CloudFormation の cfn-hup デーモンの役割は？ → 正解: EC2 インスタンス上で CloudFormation スタック更新を検知して自動的に cfn-init を再実行するデーモン。設定変更をインスタンスに自動適用するために使用。/etc/cfn/cfn-hup.conf で設定

問題 35: AWS Config の「リソースタイムライン」の用途は？ → 正解: 特定リソースの設定変更履歴を時系列で表示。いつ、誰が（CloudTrail で確認）、どのように変更したかを追跡。コンプライアンス監査や障害調査（「この変更の前は正常だった」）に活用

問題 36: CloudWatch のカスタムメトリクスの「名前空間（Namespace）」のベストプラクティスは？ → 正解: 会社名/サービス名を含む一意の名前空間を使用（例: MyCompany/WebApp）。AWS/ プレフィックスは AWS が予約済みで使用不可。メトリクスをサービス/環境ごとに分類して管理しやすくする

問題 37: Systems Manager の「OpsCenter」の「OpsItem」に自動的に関連情報を付与する方法は？ → 正解: OpsItem 作成時に RelatedOpsItems、Notifications（SNS）、OperationalData を設定。自動的に関連する CloudWatch アラーム、CloudTrail イベント、CloudFormation スタック情報を関連付け

問題 38: AWS CloudFormation のドリフト検出で「MODIFIED」と「DELETED」と「NOT_CHECKED」の意味は？ → 正解: MODIFIED: テンプレートと現在のリソース設定が異なる（手動変更あり）。DELETED: テンプレートにあるリソースが実際には削除されている。NOT_CHECKED: まだドリフト検出を実行していない（またはサポート外のリソースタイプ）

問題 39: EventBridge のカスタムイベントバスを作成するメリットは？ → 正解: アプリケーション固有のイベントを Default バスと分離して管理。クロスアカウントのイベント共有（パートナーイベントバスも活用可能）。イベントのアーカイブ/リプレイ機能を活用。異なるポリシーで管理

問題 40: AWS Config の「スナップショット配信」の設定と用途は？ → 正解: 設定した間隔（1時間〜24時間）で全リソースの設定スナップショットを S3 に保存。コンプライアンス監査（特定時点のインフラ状態の記録）や変更履歴の保全に使用。Athena でスナップショットをクエリ可能

問題 41: CloudWatch エージェントで「procstat プラグイン」が提供する情報は？ → 正解: 特定のプロセスのCPU使用率/メモリ使用量/ファイルディスクリプタ数等を収集。例: mysqld, nginx などのプロセス別のリソース使用量を CloudWatch に送信してプロセスレベルの監視を実現

問題 42: AWS Systems Manager の「パラメータストア」と「シークレットマネージャー」の使い分けで「データベースのマスターパスワードで自動ローテーション」が必要な場合は？ → 正解: AWS Secrets Manager を使用。Secrets Manager は RDS/Aurora/Redshift/DocumentDB のパスワードを自動的にローテーションする Lambda 関数を提供。Parameter Store には自動ローテーション機能がない

問題 43: CloudFormation の「Rollback Triggers」の設定はどのような場面で役立ちますか？ → 正解: スタック更新後に指定した CloudWatch アラームの状態をモニタリングして、アラームが発火した場合に自動ロールバックする。デプロイ後のアプリのヘルスチェックに基づく自動ロールバック実現

問題 44: AWS CloudWatch の「Anomaly Detection（異常検知）」の仕組みは？ → 正解: 機械学習を使ってメトリクスの通常パターン（時刻/曜日別のバンド）を自動学習。通常のバンドを逸脱した場合にアラームを発火。しきい値を手動設定しなくても良い。季節性・トレンドを自動考慮

問題 45: Systems Manager の「チェンジカレンダー（Change Calendar）」の用途は？ → 正解: 変更禁止期間や変更許可期間を定義するカレンダー。Automation/Maintenance Window と統合して、指定期間中は変更を自動ブロック。本番環境の「凍結期間」（年末年始/決算期等）の管理に使用

問題 46: CloudWatch の「ロゲループ集約」（Log Groups のアグリゲーション）を実現する方法は？ → 正解: CloudWatch Logs のサブスクリプションフィルターで複数のロループから Kinesis Data Streams に送信 → 中央の Lambda または Kinesis Firehose で集約。Organizations 全体の集約には CloudWatch クロスアカウント観測性を使用

問題 47: AWS Config の「マルチアカウント・マルチリージョン集約（アグリゲーター）」の前提条件は？ → 正解: (1) 各ソースアカウント/リージョンで Config を有効化していること。(2) ソースアカウントが集約アカウントへのデータ共有を承認（Organizations の場合は自動）。(3) 集約アカウントのロールに適切な権限

学習戦略（SOA-C03）

試験の特徴

SOA-C03 の重点分野:
  - 自動化（Systems Manager/CloudFormation/EventBridge）
  - 監視と可観測性（CloudWatch 詳細）
  - コスト管理と最適化
  - コンプライアンスとガバナンス（Config/CloudTrail）

30日学習プラン

Week 1: 監視・ログ
  Day 1-3:  CloudWatch（メトリクス/ログ/アラーム/Insights/Synthetics）
  Day 4-5:  CloudTrail（証跡設定/ログ分析/Insights）
  Day 6-7:  AWS Config（ルール/自動修復/コンフォーマンスパック）

Week 2: 自動化
  Day 8-10: Systems Manager（全機能/パッチ/Session Manager）
  Day 11-12: CloudFormation（スタック操作/StackSets/カスタムリソース）
  Day 13-14: EventBridge（Pipes/Scheduler/ルール設計）

Week 3: インフラ管理
  Day 15-16: Auto Scaling（ポリシー/ライフサイクルフック/インスタンスリフレッシュ）
  Day 17-18: EC2（トラブルシューティング/EBS/ネットワーク）
  Day 19-20: セキュリティ（IAM/KMS/GuardDuty/Inspector）
  Day 21:   コスト管理（Budgets/Cost Explorer/Compute Optimizer）

Week 4: 仕上げ
  Day 22-24: 模擬試験
  Day 25-27: 弱点補強
  Day 28-30: 直前チェックリスト

試験直前チェックリスト（SOA-C03）

監視・自動化

• [ ] CloudWatch Agent でカスタムメトリクス/ログを送信できる
• [ ] CloudWatch Logs Insights でログを分析できる
• [ ] SSM Patch Manager でパッチを自動化できる
• [ ] SSM Session Manager でポートを開放せずに接続できる
• [ ] CloudFormation StackSets でマルチアカウント展開できる
• [ ] Config ルールと自動修復アクションを設定できる

インフラ運用

• [ ] Auto Scaling のライフサイクルフックで処理を挟める
• [ ] RDS/EC2 の自動スナップショット設定ができる
• [ ] EBS ボリュームの暗号化を後から有効化できる
• [ ] Route 53 フェイルオーバーを設定できる

コスト最適化

• [ ] EC2 購入オプションを適切に選択できる
• [ ] S3 ライフサイクルポリシーでコストを最適化できる
• [ ] Compute Optimizer の推奨事項を適用できる
• [ ] AWS Budgets でアラートを設定できる

SOA-C03 クラウドオペレーションエンジニアアソシエイト完全ガイド追加セクション完了

高度な監視・運用管理

CloudWatch 高度な機能

import boto3
import json

cw = boto3.client('cloudwatch', region_name='us-east-1')
logs = boto3.client('logs', region_name='us-east-1')

# CloudWatch Composite Alarm
def create_composite_alarm(
    alarm_name: str,
    child_alarm_arns: list
) -> None:
    """複数アラームを組み合わせた複合アラーム"""
    
    # AND条件: すべてのアラームがALARM状態のときのみ発火
    alarm_rule = ' AND '.join([f'ALARM("{arn}")' for arn in child_alarm_arns])
    
    cw.put_composite_alarm(
        AlarmName=alarm_name,
        AlarmRule=alarm_rule,
        AlarmActions=['arn:aws:sns:us-east-1:123456789:production-alerts'],
        AlarmDescription='Production service is fully degraded'
    )

# Anomaly Detection (ML異常検知)
def create_anomaly_detection_alarm(
    metric_name: str,
    namespace: str,
    alarm_name: str
) -> None:
    """機械学習ベースの異常検知アラーム"""
    
    cw.put_anomaly_detector(
        Namespace=namespace,
        MetricName=metric_name,
        Stat='Average',
        Configuration={
            'ExcludedTimeRanges': [],  # 除外時間帯
            'MetricTimezone': 'Asia/Tokyo'
        }
    )
    
    cw.put_metric_alarm(
        AlarmName=alarm_name,
        ComparisonOperator='GreaterThanUpperThreshold',
        EvaluationPeriods=3,
        Metrics=[
            {
                'Id': 'ad1',
                'Expression': 'ANOMALY_DETECTION_BAND(m1, 2)',  # 2σ
                'Label': 'Expected Range'
            },
            {
                'Id': 'm1',
                'MetricStat': {
                    'Metric': {
                        'Namespace': namespace,
                        'MetricName': metric_name
                    },
                    'Period': 300,
                    'Stat': 'Average'
                }
            }
        ],
        ThresholdMetricId='ad1',
        AlarmActions=['arn:aws:sns:us-east-1:123456789:anomaly-alerts'],
        TreatMissingData='breaching'
    )

# CloudWatch Logs Insights クエリ
def run_log_query(log_group: str, query: str, start_time: int, end_time: int) -> list:
    
    response = logs.start_query(
        logGroupName=log_group,
        startTime=start_time,
        endTime=end_time,
        queryString=query
    )
    
    query_id = response['queryId']
    
    import time
    while True:
        result = logs.get_query_results(queryId=query_id)
        if result['status'] == 'Complete':
            return result['results']
        elif result['status'] in ['Failed', 'Cancelled']:
            raise Exception(f"Query {result['status']}")
        time.sleep(1)

# 有用なCloudWatch Logsクエリ集
USEFUL_CW_QUERIES = {
    'error_rate': """
        fields @timestamp, @message
        | filter @message like /ERROR/
        | stats count() as errorCount by bin(5m)
        | sort @timestamp desc
    """,
    'lambda_cold_starts': """
        filter @type = "REPORT"
        | filter @initDuration > 0
        | stats count() as coldStarts, avg(@initDuration) as avgInitDuration by bin(1h)
    """,
    'api_gateway_errors': """
        filter status >= 400
        | stats count() by status, resourcePath
        | sort count desc
        | limit 20
    """,
    'rds_slow_queries': """
        filter @message like /Query_time/
        | parse @message "Query_time: * Lock_time: * Rows_sent: *" as queryTime, lockTime, rowsSent
        | filter queryTime > 1
        | stats count(), avg(queryTime), max(queryTime) by @logStream
    """
}

AWS Systems Manager 完全ガイド

SSM サービス一覧:
┌─────────────────────────────────────────────────────────────┐
│                  AWS Systems Manager                        │
├──────────────────┬──────────────────────────────────────────┤
│ 機能              │ 説明                                     │
├──────────────────┼──────────────────────────────────────────┤
│ Session Manager  │ SSHなしのセキュアなシェルアクセス          │
│ Run Command      │ EC2インスタンスへのリモートコマンド実行    │
│ Patch Manager    │ OSパッチの自動適用                        │
│ State Manager    │ 設定ドリフトの防止・修復                  │
│ Inventory        │ インスタンス構成の収集・管理              │
│ Parameter Store  │ 設定値・シークレットの安全な保存          │
│ Secrets Manager  │ シークレットの自動ローテーション          │
│ OpsCenter        │ 運用イシューの集中管理                   │
│ Change Manager   │ 変更管理ワークフロー                     │
│ Automation       │ 運用タスクの自動化ランブック              │
│ Maintenance Win. │ 定期メンテナンスウィンドウの管理          │
│ Fleet Manager    │ EC2フリートの可視化・管理                │
│ Explorer         │ AWS環境の統合ダッシュボード               │
└──────────────────┴──────────────────────────────────────────┘

import boto3

ssm = boto3.client('ssm', region_name='us-east-1')

# SSM Automation ドキュメントの実行
def run_ssm_automation(
    document_name: str,
    parameters: dict,
    targets: list = None
) -> str:
    
    kwargs = {
        'DocumentName': document_name,
        'Parameters': parameters
    }
    
    if targets:
        kwargs['TargetParameterName'] = 'InstanceId'
        kwargs['Targets'] = targets
        kwargs['MaxConcurrency'] = '10%'
        kwargs['MaxErrors'] = '1'
    
    response = ssm.start_automation_execution(**kwargs)
    return response['AutomationExecutionId']

# カスタム Automation ドキュメントの作成
CUSTOM_AUTOMATION_DOC = {
    "schemaVersion": "0.3",
    "description": "EC2インスタンスのメモリ使用率チェックと自動リサイズ",
    "parameters": {
        "InstanceId": {"type": "String"},
        "MemoryThreshold": {"type": "Integer", "default": 85}
    },
    "mainSteps": [
        {
            "name": "getInstanceDetails",
            "action": "aws:executeAwsApi",
            "inputs": {
                "Service": "ec2",
                "Api": "DescribeInstances",
                "InstanceIds": ["{{ InstanceId }}"]
            }
        },
        {
            "name": "checkApproval",
            "action": "aws:approve",
            "inputs": {
                "Approvers": ["arn:aws:iam::123456789:role/OpsApprover"],
                "Message": "Instance {{ InstanceId }} needs resize. Approve?",
                "MinRequiredApprovals": 1
            }
        },
        {
            "name": "stopInstance",
            "action": "aws:changeInstanceState",
            "inputs": {
                "InstanceIds": ["{{ InstanceId }}"],
                "DesiredState": "stopped"
            }
        },
        {
            "name": "resizeInstance",
            "action": "aws:executeAwsApi",
            "inputs": {
                "Service": "ec2",
                "Api": "ModifyInstanceAttribute",
                "InstanceId": "{{ InstanceId }}",
                "InstanceType": {"Value": "t3.xlarge"}
            }
        },
        {
            "name": "startInstance",
            "action": "aws:changeInstanceState",
            "inputs": {
                "InstanceIds": ["{{ InstanceId }}"],
                "DesiredState": "running"
            }
        }
    ]
}

# Patch Manager のカスタムパッチベースライン
def create_patch_baseline(name: str) -> dict:
    
    return ssm.create_patch_baseline(
        Name=name,
        OperatingSystem='AMAZON_LINUX_2',
        ApprovalRules={
            'PatchRules': [
                {
                    'PatchFilterGroup': {
                        'PatchFilters': [
                            {'Key': 'SEVERITY', 'Values': ['Critical', 'High']},
                            {'Key': 'CLASSIFICATION', 'Values': ['Security', 'Bugfix']}
                        ]
                    },
                    'ComplianceLevel': 'CRITICAL',
                    'ApproveAfterDays': 0,    # 即時承認
                    'EnableNonSecurity': False
                },
                {
                    'PatchFilterGroup': {
                        'PatchFilters': [
                            {'Key': 'SEVERITY', 'Values': ['Medium']},
                        ]
                    },
                    'ComplianceLevel': 'MEDIUM',
                    'ApproveAfterDays': 7,    # 7日後に自動承認
                }
            ]
        },
        RejectedPatches=['kernel-*'],  # カーネルパッチは除外
        ApprovedPatches=['amazon-ssm-agent'],
        Description=f'Production patch baseline: {name}'
    )

# Maintenance Window の設定
def create_maintenance_window(
    name: str,
    schedule_cron: str = 'cron(0 2 ? * SUN *)'  # 毎週日曜2時
) -> dict:
    
    window = ssm.create_maintenance_window(
        Name=name,
        Schedule=schedule_cron,
        Duration=4,       # 4時間
        Cutoff=1,         # 終了1時間前に新タスク開始停止
        AllowUnassociatedTargets=False,
        Description='Weekly maintenance window for patching'
    )
    
    window_id = window['WindowId']
    
    # ターゲット登録
    target = ssm.register_target_with_maintenance_window(
        WindowId=window_id,
        ResourceType='INSTANCE',
        Targets=[
            {
                'Key': 'tag:Environment',
                'Values': ['production']
            }
        ]
    )
    
    # タスク登録 (パッチ適用)
    ssm.register_task_with_maintenance_window(
        WindowId=window_id,
        WindowTargetIds=[target['WindowTargetId']],
        TaskType='RUN_COMMAND',
        TaskArn='AWS-RunPatchBaseline',
        ServiceRoleArn='arn:aws:iam::123456789:role/MaintenanceWindowRole',
        TaskInvocationParameters={
            'RunCommand': {
                'Parameters': {
                    'Operation': ['Install']
                },
                'TimeoutSeconds': 600,
                'MaxConcurrency': '20%',
                'MaxErrors': '5%'
            }
        },
        MaxConcurrency='20%',
        MaxErrors='5%',
        Priority=1
    )
    
    return window_id

AWS Config 高度な設定

import boto3
import json

config = boto3.client('config', region_name='us-east-1')

# カスタム Config ルールの作成 (Lambda評価)
def create_custom_config_rule(
    rule_name: str,
    lambda_arn: str,
    trigger_type: str = 'ConfigurationItemChangeNotification'
) -> dict:
    
    return config.put_config_rule(
        ConfigRule={
            'ConfigRuleName': rule_name,
            'Description': f'Custom rule: {rule_name}',
            'Scope': {
                'ComplianceResourceTypes': ['AWS::EC2::Instance']
            },
            'Source': {
                'Owner': 'CUSTOM_LAMBDA',
                'SourceIdentifier': lambda_arn,
                'SourceDetails': [
                    {
                        'EventSource': 'aws.config',
                        'MessageType': trigger_type
                    }
                ]
            }
        }
    )

# Lambda評価関数 (カスタムConfigルール)
def config_rule_evaluator(event, context):
    """EBSボリュームが暗号化されているかチェック"""
    
    configuration_item = json.loads(event['invokingEvent'])['configurationItem']
    
    if configuration_item['resourceType'] != 'AWS::EC2::Volume':
        return
    
    config_service = boto3.client('config')
    
    # 暗号化チェック
    is_encrypted = configuration_item['configuration'].get('encrypted', False)
    
    compliance = 'COMPLIANT' if is_encrypted else 'NON_COMPLIANT'
    annotation = 'Volume is encrypted' if is_encrypted else 'Volume is NOT encrypted - must enable encryption'
    
    config_service.put_evaluations(
        Evaluations=[
            {
                'ComplianceResourceType': configuration_item['resourceType'],
                'ComplianceResourceId': configuration_item['resourceId'],
                'ComplianceType': compliance,
                'Annotation': annotation,
                'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
            }
        ],
        ResultToken=event['resultToken']
    )

# Conformance Pack のデプロイ
def deploy_conformance_pack(pack_name: str, template_s3_uri: str) -> dict:
    
    return config.put_conformance_pack(
        ConformancePackName=pack_name,
        TemplateS3Uri=template_s3_uri,
        DeliveryS3Bucket='config-conformance-pack-results',
        ConformancePackInputParameters=[
            {
                'ParameterName': 'RequiredTagKey',
                'ParameterValue': 'Environment'
            }
        ]
    )

# Auto Remediation の設定
def configure_auto_remediation(
    rule_name: str,
    ssm_document: str,
    target_role_arn: str
) -> dict:
    
    return config.put_remediation_configurations(
        RemediationConfigurations=[
            {
                'ConfigRuleName': rule_name,
                'TargetType': 'SSM_DOCUMENT',
                'TargetId': ssm_document,
                'Parameters': {
                    'AutomationAssumeRole': {
                        'StaticValue': {
                            'Values': [target_role_arn]
                        }
                    },
                    'ResourceId': {
                        'ResourceValue': {
                            'Value': 'RESOURCE_ID'
                        }
                    }
                },
                'Automatic': True,
                'MaximumAutomaticAttempts': 3,
                'RetryAttemptSeconds': 60
            }
        ]
    )

Auto Scaling 高度な設定

import boto3

asg = boto3.client('autoscaling', region_name='us-east-1')
app_scaling = boto3.client('application-autoscaling', region_name='us-east-1')

# 予測スケーリングの設定
def configure_predictive_scaling(asg_name: str) -> None:
    
    asg.put_scaling_policy(
        AutoScalingGroupName=asg_name,
        PolicyName='predictive-scaling-policy',
        PolicyType='PredictiveScaling',
        PredictiveScalingConfiguration={
            'MetricSpecifications': [
                {
                    'TargetValue': 70.0,  # CPU使用率70%を目標
                    'PredefinedMetricPairSpecification': {
                        'PredefinedMetricType': 'ASGCPUUtilization'
                    }
                }
            ],
            'Mode': 'ForecastAndScale',         # 予測してスケール
            'SchedulingBufferTime': 300,          # 5分前にスケールアップ
            'MaxCapacityBreachBehavior': 'HonorMaxCapacity',
            'MaxCapacityBuffer': 10               # 10%のバッファ
        }
    )

# ウォームプールの設定 (コールドスタート削減)
def configure_warm_pool(asg_name: str) -> None:
    
    asg.put_warm_pool(
        AutoScalingGroupName=asg_name,
        MinSize=2,                      # 常に2台をウォーム状態に維持
        MaxGroupPreparedCapacity=5,     # 最大5台まで事前準備
        PoolState='Stopped',            # Stopped または Running
        InstanceReusePolicy={
            'ReuseOnScaleIn': True      # スケールイン時にウォームプールに戻す
        }
    )

# ライフサイクルフックの設定
def setup_lifecycle_hooks(asg_name: str, sns_topic_arn: str) -> None:
    
    # 起動フック: アプリケーション初期化
    asg.put_lifecycle_hook(
        LifecycleHookName='app-init-hook',
        AutoScalingGroupName=asg_name,
        LifecycleTransition='autoscaling:EC2_INSTANCE_LAUNCHING',
        HeartbeatTimeout=300,  # 5分以内に処理完了
        DefaultResult='ABANDON',  # タイムアウト時はインスタンス破棄
        NotificationTargetARN=sns_topic_arn,
        RoleARN='arn:aws:iam::123456789:role/AutoScalingRole'
    )
    
    # 終了フック: ドレイニング処理
    asg.put_lifecycle_hook(
        LifecycleHookName='draining-hook',
        AutoScalingGroupName=asg_name,
        LifecycleTransition='autoscaling:EC2_INSTANCE_TERMINATING',
        HeartbeatTimeout=120,  # 2分以内にドレイン完了
        DefaultResult='CONTINUE',  # タイムアウト時は終了継続
        NotificationTargetARN=sns_topic_arn,
        RoleARN='arn:aws:iam::123456789:role/AutoScalingRole'
    )

# ライフサイクルフック処理Lambda
def lifecycle_hook_handler(event, context):
    """ライフサイクルフックのイベント処理"""
    
    message = json.loads(event['Records'][0]['Sns']['Message'])
    
    lifecycle_action = message['LifecycleTransition']
    instance_id = message['EC2InstanceId']
    asg_name = message['AutoScalingGroupName']
    lifecycle_hook_name = message['LifecycleHookName']
    lifecycle_action_token = message['LifecycleActionToken']
    
    try:
        if lifecycle_action == 'autoscaling:EC2_INSTANCE_LAUNCHING':
            # アプリケーション初期化処理
            initialize_application(instance_id)
        elif lifecycle_action == 'autoscaling:EC2_INSTANCE_TERMINATING':
            # ドレイニング処理
            drain_connections(instance_id)
        
        # 処理完了を通知
        asg_client = boto3.client('autoscaling')
        asg_client.complete_lifecycle_action(
            LifecycleHookName=lifecycle_hook_name,
            AutoScalingGroupName=asg_name,
            LifecycleActionToken=lifecycle_action_token,
            LifecycleActionResult='CONTINUE'
        )
    
    except Exception as e:
        asg_client = boto3.client('autoscaling')
        asg_client.complete_lifecycle_action(
            LifecycleHookName=lifecycle_hook_name,
            AutoScalingGroupName=asg_name,
            LifecycleActionToken=lifecycle_action_token,
            LifecycleActionResult='ABANDON'
        )
        raise

def initialize_application(instance_id: str) -> None:
    """アプリケーション初期化 (ELBへの登録確認等)"""
    pass

def drain_connections(instance_id: str) -> None:
    """接続ドレイニング"""
    pass

CloudFormation 高度なパターン

カスタムリソース

# CloudFormation Custom Resource Lambda

import boto3
import json
import urllib.request
import urllib.parse

def lambda_handler(event, context):
    """CloudFormationカスタムリソースハンドラー"""
    
    print(f"Event: {json.dumps(event)}")
    
    request_type = event['RequestType']
    physical_id = event.get('PhysicalResourceId', 'custom-resource')
    
    try:
        if request_type == 'Create':
            result = handle_create(event)
            physical_id = result.get('PhysicalResourceId', physical_id)
        elif request_type == 'Update':
            result = handle_update(event)
        elif request_type == 'Delete':
            result = handle_delete(event)
            return send_response(event, context, 'SUCCESS', {}, physical_id)
        
        return send_response(
            event, context, 'SUCCESS',
            result.get('Data', {}),
            physical_id
        )
    
    except Exception as e:
        print(f"Error: {e}")
        return send_response(event, context, 'FAILED', {'Error': str(e)}, physical_id)

def handle_create(event) -> dict:
    props = event['ResourceProperties']
    
    # カスタム処理: 例) SESドメイン検証
    ses = boto3.client('ses')
    
    domain = props['Domain']
    response = ses.verify_domain_identity(Domain=domain)
    
    return {
        'PhysicalResourceId': f'ses-domain-{domain}',
        'Data': {
            'VerificationToken': response['VerificationToken']
        }
    }

def handle_update(event) -> dict:
    # 更新処理
    return {'Data': {}}

def handle_delete(event) -> dict:
    props = event['ResourceProperties']
    domain = props['Domain']
    
    ses = boto3.client('ses')
    ses.delete_identity(Identity=domain)
    
    return {}

def send_response(event, context, status, data, physical_id):
    response_body = json.dumps({
        'Status': status,
        'Reason': f'See CloudWatch Logs: {context.log_stream_name}',
        'PhysicalResourceId': physical_id,
        'StackId': event['StackId'],
        'RequestId': event['RequestId'],
        'LogicalResourceId': event['LogicalResourceId'],
        'Data': data
    })
    
    url = event['ResponseURL']
    headers = {
        'Content-Type': '',
        'Content-Length': len(response_body)
    }
    
    req = urllib.request.Request(url, data=response_body.encode(), headers=headers, method='PUT')
    urllib.request.urlopen(req)

# CloudFormation テンプレート例: カスタムリソース
AWSTemplateFormatVersion: '2010-09-09'

Parameters:
  Domain:
    Type: String
    Default: example.com

Resources:
  SESVerifyLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: ses-verify-custom-resource
      Runtime: python3.12
      Handler: index.lambda_handler
      Role: !GetAtt LambdaRole.Arn
      Timeout: 300
      Code:
        ZipFile: |
          # Lambda code here

  SESVerifyLambdaPermission:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt SESVerifyLambda.Arn
      Action: lambda:InvokeFunction
      Principal: cloudformation.amazonaws.com

  # カスタムリソースの使用
  SESVerification:
    Type: Custom::SESVerification
    Properties:
      ServiceToken: !GetAtt SESVerifyLambda.Arn
      Domain: !Ref Domain

Outputs:
  VerificationToken:
    Value: !GetAtt SESVerification.VerificationToken

StackSets での展開

import boto3

cf = boto3.client('cloudformation', region_name='us-east-1')

# StackSets の作成とデプロイ
def deploy_stackset(
    stack_set_name: str,
    template_body: str,
    target_org_ids: list,
    target_regions: list
) -> dict:
    
    # StackSet の作成
    cf.create_stack_set(
        StackSetName=stack_set_name,
        Description='Security baseline for all accounts',
        TemplateBody=template_body,
        PermissionModel='SERVICE_MANAGED',  # Organizations統合
        AutoDeployment={
            'Enabled': True,   # 新しいアカウントに自動デプロイ
            'RetainStacksOnAccountRemoval': True
        },
        Capabilities=['CAPABILITY_NAMED_IAM']
    )
    
    # スタックインスタンスの作成 (組織単位(OU)にデプロイ)
    response = cf.create_stack_instances(
        StackSetName=stack_set_name,
        DeploymentTargets={
            'OrganizationalUnitIds': target_org_ids
        },
        Regions=target_regions,
        OperationPreferences={
            'MaxConcurrentPercentage': 20,  # 20%ずつ並列デプロイ
            'FailureTolerancePercentage': 10,
            'ConcurrencyMode': 'SOFT_FAILURE_TOLERANCE'
        }
    )
    
    return response

# StackSet ドリフト検出
def detect_stackset_drift(stack_set_name: str) -> str:
    response = cf.detect_stack_set_drift(
        StackSetName=stack_set_name,
        OperationPreferences={
            'MaxConcurrentPercentage': 100,
            'FailureTolerancePercentage': 100
        }
    )
    return response['OperationId']

模擬試験 第1回 (65問)

Part 1: 監視・運用 (問1-20)

問1: CloudWatch Alarm の「INSUFFICIENT_DATA」状態の意味は？

A) アラームが正常 B) メトリクスデータが不足しており、アラームの状態が評価できない C) エラーが発生した D) アラームが無効化されている

正解: B 解説: INSUFFICIENT_DATAはCloudWatchがメトリクスデータを受信していない場合や、データポイント数が評価期間を満たしていない場合に発生。TreatMissingDataパラメータで欠損データをbreaching/notBreaching/ignore/missingとして扱うか設定できる。

問2: SSM Session Manager を使用するためにEC2インスタンスに必要な設定は？

A) SSHポート(22)を開放 B) SSM AgentのインストールとAmazonSSMManagedInstanceCore IAMポリシーの付与 C) Systems Managerへの手動登録 D) VPNの設定

正解: B 解説: Session Manager要件: (1)SSM Agent(Amazon Linux 2等はプリインストール) (2)インスタンスロールにAmazonSSMManagedInstanceCoreポリシー (3)SSM エンドポイントへの通信(VPCエンドポイントまたはインターネット)。SSH/RDP不要でセキュアアクセス可能。

問3: AWS Config でEC2インスタンスが特定のインスタンスタイプでなければならないというルールを設定するには？

A) CloudWatchメトリクスを使用 B) マネージドルール desired-instance-type を使用し、許可するインスタンスタイプを指定 C) Lambda関数でチェック D) IAMポリシーで制限

正解: B 解説: desired-instance-type は指定したインスタンスタイプ以外のEC2インスタンスをNON_COMPLIANTとするAWSマネージドConfigルール。instanceTypeパラメータにカンマ区切りで許可タイプを指定。

問4: CloudFormation のドリフト検出で「ドリフト」とは何を意味するか？

A) スタックの作成に失敗 B) スタックの実際のリソース設定がCloudFormationテンプレートから逸脱している状態 C) テンプレートの構文エラー D) リソースの削除

正解: B 解説: ドリフトはAWSコンソールやCLI等でリソースを直接変更した場合に発生。ドリフト検出で変更されたリソースと具体的な差分を特定し、テンプレートを更新するか手動で元に戻すかを判断できる。

問5: AWS CloudTrail でAPI呼び出しのログを有効にするために必要な最小構成は？

A) CloudWatchメトリクスとの統合が必須 B) S3バケットを指定してTrailを作成し、有効化するだけ C) KMSの設定が必須 D) CloudWatch Logsへの転送が必須

正解: B 解説: CloudTrailの基本設定はS3バケットへのAPI呼び出しログ保存のみ。KMS暗号化、CloudWatch Logs統合、Insight Events (異常な活動検出)はオプション。Multi-Region Trailを1つ作成すれば全リージョンをカバー。

問6: EC2インスタンスのパッチ適用後にコンプライアンス状態を確認するAWSサービスは？

A) CloudWatch B) AWS Config C) SSM Patch Manager の Compliance 機能 D) AWS Inspector

正解: C 解説: SSM Patch Managerのコンプライアンスレポートはインスタンスのパッチ適用状態(準拠/非準拠、不足パッチの一覧)を提供。SSM Explorerや SSM Dashboardで組織全体のパッチコンプライアンス状況を可視化できる。

問7: Auto Scaling のスケールイン時に特定のインスタンスを保護する方法は？

A) 保護は不可能 B) インスタンスの「スケールイン保護」を有効化、またはLifecycle Hookで処理を挟む C) Auto Scalingグループを削除 D) ELBからのみ切り離す

正解: B 解説: スケールイン保護: set-instance-protectionでインスタンスをASGのスケールインから保護。重要な処理実行中のインスタンスを守る。完了後に保護解除。Lifecycle Hookのterminating hookで処理完了まで待機する方法も使用。

問8: AWS Trusted Advisor でコスト最適化の推奨事項として表示されるのはどれか？

A) セキュリティの設定ミス B) 低使用率のEC2インスタンスやアイドル状態のリソース C) 可用性の設定問題 D) パフォーマンスの問題

正解: B 解説: Trusted Advisorのコスト最適化チェック: 低使用率EC2インスタンス(CPU<10%), アイドルRDSインスタンス, 未接続EIPとEBSボリューム, リザーブドインスタンス最適化, S3バケットのライフサイクルなど。

問9: Amazon Inspector 2 の主な機能は？

A) ネットワークトラフィックの監視 B) EC2インスタンスとコンテナイメージの脆弱性スキャン(CVE)とネットワーク到達可能性の継続的評価 C) ログの収集と分析 D) パッチ適用の自動化

正解: B 解説: Inspector 2は継続的なスキャンでEC2 OS脆弱性、ECRコンテナイメージの脆弱性(CVE)、Lambda関数のコード脆弱性を検出。リスクスコアを付けて重要度を評価し、Security HubやEventBridgeと統合。

問10: EventBridge でEC2インスタンスが停止したときにSlackに通知する設計は？

A) CloudWatch Logsからトリガー B) EventBridge Rule(EC2 State Change→Stopped)→Lambda→Slack API C) SNSのみで対応 D) CloudFormationで設定

正解: B 解説: EventBridge Rule: source=aws.ec2, detail-type=EC2 Instance State-change Notification, detail.state=stopped→Lambda→Slack Incoming Webhook。または EventBridge→SNS→Lambda→Slackの構成。

問11: Amazon GuardDuty を有効化したとき自動的に監視されるデータソースは？

A) CloudTrailのみ B) CloudTrail管理/データイベント、VPC Flow Logs、DNS Logs(EC2)、EKS Audit Logs C) アプリケーションログのみ D) S3バケットポリシーのみ

正解: B 解説: GuardDutyはCloudTrail(管理イベント)、VPC Flow Logs、DNS Logsを自動収集・分析。オプション機能: S3データイベント(S3 Protection)、EKS Audit Logs(EKS Protection)、Lambda(Lambda Protection)、RDS(RDS Protection)。

問12: AWS Health Dashboard でサービス障害を検知した際の自動対応を設定するには？

A) 手動確認のみ B) EventBridge → ‘aws.health’ イベントソースで通知・自動対応 C) CloudWatchアラームと連携 D) SNSのみ対応

正解: B 解説: AWS Health Eventsは EventBridgeのaws.healthイベントソースとして発生する。リソース特定の健全性イベント(特定EC2インスタンスに影響するイベント等)をフィルタリングして自動対応Lambdaをトリガーできる。

問13: CloudFormation のネスティッド スタック (Nested Stacks) を使用する主な利点は？

A) 高速なデプロイ B) 再利用可能なテンプレートコンポーネントとして管理し、テンプレートサイズの上限(1MB)を回避 C) セキュリティの向上 D) コストの削減

正解: B 解説: Nested StacksはAWS::CloudFormation::Stackリソースタイプで別スタックを子として参照する。VPC、セキュリティ、アプリなどをモジュール化して再利用可能にする。テンプレートのサイズ制限(200KB/1MB)回避にも有効。

問14: SSM Parameter Store と Secrets Manager の主な違いは？

A) 機能は同じ B) Parameter Store: 設定値・非機密情報の保存(無料Tier)。Secrets Manager: シークレットの自動ローテーション機能あり(コストが発生) C) Parameter Storeは暗号化不可 D) Secrets Managerのみ高可用性

正解: B 解説: Parameter Store Standard: 無料, 4KB制限, 暗号化オプション。Parameter Store Advanced: 有料, 8KB。Secrets Manager: シークレット自動ローテーション(Lambda連携), RDS/Redshift/DocumentDB自動統合, クロスアカウント共有。データベース認証情報には Secrets Manager が推奨。

問15: AWS Cost Explorer でコスト異常を検知するための機能は？

A) コスト予算(Budgets)のみ B) Cost Anomaly Detection で機械学習ベースの異常検知と SNS アラート C) CloudWatchメトリクスのみ D) 手動でのコスト分析のみ

正解: B 解説: Cost Anomaly DetectionはML/AIで通常のコストパターンを学習し、異常なコストスパイクを検出してSNS/Email通知する。モニター種類: AWS Service別、Linked Account別、Cost Category別、コストアロケーションタグ別。

問16: AWS OpsCenter のアイテム(OpsItem)の作成をトリガーするサービスは？

A) CloudTrailのみ B) EventBridge, CloudWatch Alarms, Config Rules, Systems Manager, GuardDuty 等多数 C) SSMのみ D) Cost Explorerのみ

正解: B 解説: OpsItemはEventBridgeルール、CloudWatchアラーム、AWS ConfigルールのNON_COMPLIANT検出、Security Hub Finding、GuardDuty等から自動作成できる。運用上の問題を一元管理してインシデント管理に使用。

問17: Elastic Load Balancer の Access Logs を有効にした場合、ログはどこに保存されるか？

A) CloudWatch Logsに自動保存 B) 指定したS3バケットに保存(5〜60分ごとにエクスポート) C) EC2インスタンスのローカルに保存 D) DynamoDBに保存

正解: B 解説: ELB Access Logsは指定したS3バケットに保存される。ALBは最大5分ごと、NLBは最大5分ごと。ログにはクライアントIP、リクエスト時刻、URL、ステータスコード、処理時間などが含まれる。Athenaでの分析が推奨。

問18: AWS Compute Optimizer が最適化の推奨を提供するリソースタイプは？

A) EC2とRDSのみ B) EC2インスタンス、Auto Scalingグループ、EBSボリューム、Lambda関数、ECS on Fargateタスク定義 C) Lambda関数のみ D) 全AWSリソース

正解: B 解説: Compute Optimizerは機械学習でCloudWatchメトリクスを分析し、適切なインスタンスタイプ/サイズへの変更推奨、EBSのボリュームタイプ最適化、Lambda メモリ設定の最適化を提供する。過去14日間のデータを使用。

問19: AWS Well-Architected FrameworkのOperational Excellence 柱で「変更を小さくし、可逆的にする」原則に対応するAWSサービスは？

A) Amazon S3 B) AWS CodePipeline + CloudFormation Blue/Green デプロイメント C) Amazon RDS D) Amazon EC2 Auto Scaling

正解: B 解説: 小さく可逆的な変更: (1)CodePipelineでCI/CDパイプライン (2)CloudFormation Changesets で変更のプレビュー (3)CodeDeploy Blue/Greenで無停止デプロイと即時ロールバック (4)Feature Flagsで段階的なリリース。

問20: Amazon CloudWatch Application Insights の主な機能は？

A) コストの監視のみ B) .NET/Java/.NodeアプリケーションのリソースKPIを自動検出し、問題の根本原因を機械学習で特定 C) インフラのみ監視 D) セキュリティ監視専用

正解: B 解説: CloudWatch Application Insightsはアプリケーションのリソース(EC2, ELB, RDS等)を自動検出してダッシュボード作成、異常なメトリクスとログをML分析して問題の根本原因分析(RCA)を提供する。.NET/SQL Serverに特に有効。

Part 2: インフラ管理 (問21-45)

問21: AWS CloudFormation の DependsOn 属性を使用する場面は？

A) リソース間の暗黙的な依存関係のみ B) CloudFormationが自動検出できない明示的な依存関係(例: IGW作成後にサブネットのRoute設定)が必要な場合 C) 全リソースに必須 D) Lambda関数のみ

正解: B 解説: CloudFormationはRef/!GetAttで参照されたリソース間の依存関係を自動検出。しかし論理的な依存関係(例: VPCアタッチメント後にRoute作成)はDependsOnで明示的に指定が必要。誤った順序でのデプロイを防ぐ。

問22: AWS Backup の主な機能は？

A) S3のみのバックアップ B) EC2/EBS/RDS/DynamoDB/EFS/FSx/Aurora等の統合バックアップ管理(スケジュール, 保持, クロスリージョン, クロスアカウント) C) データベースのみ D) 手動バックアップのみ

正解: B 解説: AWS Backupは複数サービスのバックアップを一元管理。バックアッププランでスケジュール・保持期間を設定し、クロスリージョン/クロスアカウントコピーでDR対応。Backup Vaultロックでバックアップの改ざん防止も可能。

問23: EBS ボリュームの暗号化を後から有効にするには？

A) 直接暗号化の有効化が可能 B) スナップショットを作成→暗号化して新スナップショットからボリュームを作成→インスタンスに付け替え C) 暗号化はボリューム作成時のみ設定可能 D) KMSキーを後から適用

正解: B 解説: 既存EBSボリュームの暗号化: (1)スナップショット作成 (2)スナップショットのコピー時に暗号化有効化 (3)暗号化スナップショットから新ボリューム作成 (4)インスタンスを停止して旧ボリュームをデタッチ・新ボリュームをアタッチ。

問24: EC2 の「Placement Group」種類と使い分けは？

A) 1種類のみ B) Cluster(低レイテンシ・高帯域), Spread(個別ハードウェア, 最大7インスタンス/AZ), Partition(大規模分散, 各パーティションが独立したラック) C) Spread のみ存在 D) Placement Groupは廃止済み

正解: B 解説: Cluster PG: 同一AZの近いハードウェア配置でHPC/MLに最適。Spread PG: 各インスタンスを異なるハードウェアに配置して障害の影響を最小化(最大7/AZ)。Partition PG: 大規模分散システム(Kafka, Cassandra等)でパーティション単位の障害分離。

問25: AWS Service Catalog の主な用途は？

A) AWSサービスの一覧表示 B) 承認済みのCloudFormationテンプレートをセルフサービスポータルとして提供し、ガバナンスを維持 C) マーケットプレイス D) コスト管理

正解: B 解説: Service Catalogは管理者が承認したテンプレート(製品)をポートフォリオとして整理し、開発者がガバナンスに準拠した形でセルフサービスでリソースをデプロイできる。IT標準の強制、コンプライアンス維持、デプロイの民主化を実現。

問26: AWS Systems Manager Automation Runbookの aws:approve ステップを使用する目的は？

A) 自動承認 B) 人間の承認ゲートを挿入し、危険な操作を安全に実行(変更管理プロセスの自動化) C) IAM権限のチェック D) テストの実行

正解: B 解説: aws:approveステップはSNS通知とともに指定した承認者にメールを送り、承認/拒否を待機する。本番環境へのデプロイ、DBの変更、重要インスタンスの再起動などに変更管理プロセスを自動化できる。

問27: Amazon EventBridge Scheduler の主な用途は？

A) EventBridgeのルール管理 B) cronまたはrateスケジュールでワンタイムまたは定期的にAWSサービスやLambdaを呼び出す C) イベントのフィルタリング D) コストのスケジューリング

正解: B 解説: EventBridge Schedulerはcron式またはrateで定期的にLambda/SQS/SNS/ECS等を呼び出す。CloudWatch Events/EventBridge Rulesのスケジュール機能より高度で、1回限りのスケジュール、タイムゾーン指定、フレキシブルウィンドウをサポート。

問28: CloudWatch Container Insights でECS/EKSのメトリクスを収集するには？

A) 手動でのメトリクス設定が必要 B) Container Insights を有効化するだけで、CPU/メモリ/ネットワーク/ディスクのメトリクスを自動収集 C) CloudWatch AgentをECSタスクに追加 D) Prometheus との統合が必須

正解: B 解説: ECSではクラスターまたはタスク定義でContainer Insightsを有効化するだけでメトリクスを収集。EKSではCloudWatch Agentのデーモンセットを配備。コンテナ、タスク/Pod、サービス/デプロイメントレベルのメトリクスが利用可能。

問29: EC2 のステータスチェックが失敗した場合の自動回復設定は？

A) 手動での再起動が必要 B) CloudWatchアラームのStatusCheckFailed_SystemにEC2リカバリーアクションを設定 C) Auto Scalingの設定が必要 D) EC2のステータスチェックは自動回復不可

正解: B 解説: CloudWatchアラームでStatusCheckFailed_SystemメトリクスがALARMになったとき、アクションとしてec2:RecoverInstanceを設定できる。システム障害(ホストの問題)時にEC2インスタンスを別のホストに移動して自動回復。

問30: AWS Systems Manager Session Managerのセッションログをどこに記録するか？

A) EC2インスタンスのローカルのみ B) S3バケット、CloudWatch Logs、またはその両方に記録可能 C) CloudTrailのみ D) ログは記録されない

正解: B 解説: Session ManagerのSession Preferences(SSMのコンソール設定)でS3とCloudWatch Logsへのセッションログ記録を設定。監査・コンプライアンス要件に対応。CloudTrailにはセッション開始/終了のAPIイベントも記録される。

問31: Amazon EC2 Image Builder の主な機能は？

A) EC2インスタンスのイメージ変換 B) AMIの構築パイプライン(ベースAMI→コンポーネント適用→テスト→配布)の自動化 C) AMIのコスト分析 D) EC2インスタンスの仮想化

正解: B 解説: EC2 Image Builderはパイプラインで(1)ベースイメージ選択 (2)カスタムコンポーネント適用(パッケージインストール、設定等) (3)自動テスト (4)AMI配布を自動化。OS/セキュリティパッチが含まれた最新AMIを定期的に生成し、コンプライアンスを維持。

問32: CloudFormation で既存リソースをスタックにインポートする方法は？

A) 不可能 B) CloudFormation import resources を使用し、既存リソースIDをマッピング C) リソースを削除して再作成 D) Terraform で移行してからCFnに変換

正解: B 解説: CloudFormation Resource Importで既存リソース(リソースIDを指定)をスタックに取り込み、以後はCFnで管理できる。インポートの前提: テンプレートにリソース定義が必要、Deletion Policyの設定推奨。

問33: AWS Organizations の Service Control Policy (SCP) が適用されるエンティティは？

A) IAMユーザーとロールのみ B) OUとアカウントに対して適用され、そのアカウントのすべてのIAMエンティティ(ルートを含む)に影響 C) CloudFormationスタックのみ D) リソースポリシーを持つリソースのみ

正解: B 解説: SCPはOUまたは個別アカウントに適用し、アカウント内の全IAMエンティティ(ルートユーザー、IAMユーザー、ロール)が実行できる最大権限を制限する。SCPはデフォルト全拒否、許可は明示的に設定。管理アカウントには適用されない。

問34: AWS Control Tower で新しいアカウントをプロビジョニングする最も推奨される方法は？

A) 手動でAWSアカウントを作成 B) Account Factory(自動化されたアカウント作成プロセス)またはAFT(Account Factory for Terraform) C) CloudFormationでアカウントを作成 D) Organizations APIを直接使用

正解: B 解説: Account Factoryはネットワーク設定、セキュリティ設定、タグ付けが事前設定されたアカウントを自動的にプロビジョニング。AFT(Account Factory for Terraform)はTerraformでAccount Factoryをカスタマイズしたコードベースのアカウント作成を実現。

問35: EBS の gp2 から gp3 にオンラインで変更する方法は？

A) ボリュームを削除して再作成 B) EC2コンソールまたはAPIでVolume Modification(オンライン変更)を実行 C) インスタンスを停止してから変更 D) AMIを作成してから変更

正解: B 解説: EBS Volume Modification (modify_volume API)によりインスタンスの停止なしにgp2→gp3への変更が可能。gp3はgp2より20%安価でIOPSとスループットを独立して設定できる。変更後の最適化には最大24時間かかる場合がある。

問36: EC2 インスタンスメタデータを取得する際のIMDSv2の特徴は？

A) セッショントークンなしで直接取得 B) 事前にSessionトークンを取得し、全リクエストにTokenヘッダーを含める必要があり、SSRFリスクを軽減 C) IMDSv1と完全に互換 D) Lambda関数でのみ使用可能

正解: B 解説: IMDSv2(インスタンスメタデータサービスv2)はセッション指向でPUT→GET 2ステップを要求し、SSRFによる不正なメタデータアクセスを防止。HttpTokens: requiredでIMDSv1を無効化するのが推奨。

問37: CloudFormation の ChangeSets を使用する主な目的は？

A) テンプレートの検証のみ B) スタックへの変更を実際の適用前にプレビューし、予期しないリソース削除・置換を確認 C) ロールバックの設定 D) デプロイのスケジューリング

正解: B 解説: ChangeSetsはスタック更新の影響(追加/変更/削除するリソースと実行する操作)を事前にプレビュー。特にReplacement: Trueのリソースは削除・再作成されるため注意が必要。承認フロー組み込みも可能。

問38: AWS Cost Allocation Tags を使用してコスト分析を行うには？

A) タグを付けるだけで自動的にコスト分析される B) AWSコストアロケーションタグとして有効化(Cost Explorerで有効化)してから最大24時間後にコストデータにタグが反映 C) タグはコスト分析に使用できない D) IAMポリシーで設定

正解: B 解説: コストアロケーションタグ設定手順: (1)リソースにタグを付ける (2)Billing ConsoleでAWSタグまたはユーザー定義タグを「Activate」 (3)24時間後からCost ExplorerでタグによるコストフィルタリングとグループCが可能。

問39: AWS Systems Manager Inventory でインベントリデータを収集する設定は？

A) インベントリは自動的に収集される B) State Managerアソシエーション(AWS-GatherSoftwareInventory)を作成してターゲットインスタンスとスケジュールを設定 C) CloudWatchメトリクスから自動取得 D) Lambda関数での実装が必要

正解: B 解説: SSM InventoryはState Managerのアソシエーション(AWS-GatherSoftwareInventory)で設定。収集対象: アプリケーション、AWSコンポーネント、ネットワーク設定、インスタンスの詳細情報。30分〜24時間のスケジュールで収集。

問40: EC2の「Enhanced Networking」を有効にする条件は？

A) 全EC2インスタンスで自動有効 B) Enhanced Networkingをサポートするインスタンスタイプ + ENAドライバーがAMIに含まれていること C) 別途料金が必要 D) VPCのみで使用可能

正解: B 解説: Enhanced Networking(ENA: Elastic Network Adapter)はC5/M5/R5等の最新インスタンスファミリーでデフォルト有効(Amazon Linux 2等のAMIにENAドライバー含む)。最大100Gbpsの帯域、低レイテンシを実現。

問41: S3 Lifecycle ポリシーでオブジェクトを Glacier に移動する際の最小保存日数は？

A) 7日 B) 30日(Standard-IA/One Zone-IA), 90日(Glacier Instant/Flexible), 180日(Glacier Deep Archive) C) 1日 D) 365日

正解: B 解説: ライフサイクル移行の最小日数: Standard→Standard-IA: 30日, Standard→One Zone-IA: 30日, Standard→Glacier Instant: 90日, Standard→Glacier Flexible: 90日, Standard→Glacier Deep Archive: 180日。最小保存期間以下では移行不可。

問42: RDS Multi-AZ 配置のフェイルオーバー時間は？

A) 数分から30分 B) 通常60〜120秒(ただし大量の未コミットトランザクションがある場合は長くなる) C) 1〜5秒 D) フェイルオーバーは手動のみ

正解: B 解説: RDS Multi-AZのフェイルオーバー: (1)プライマリインスタンスの障害検出 (2)DNS TTL(60-120秒)の更新 (3)スタンバイへの切り替え。アプリの接続文字列はRDSのEndpoint(DNS名)を使用することで自動フェイルオーバーに対応。

問43: CloudFormation の Rollback Triggers を設定する目的は？

A) 自動バックアップ B) スタック作成/更新中にCloudWatchアラームが発火した場合にロールバックをトリガー C) コスト管理 D) セキュリティ強化

正解: B 解説: Rollback Triggerはスタック操作中のモニタリング期間(0〜180分)にCloudWatchアラームがALARM状態になった場合に自動ロールバック。デプロイ後のエラー率上昇や5xxエラーを検知してロールバックするに使用。

問44: AWS Config でサポートされていないリソースタイプのコンプライアンスを評価するには？

A) 不可能 B) Custom Config Rule (Lambda評価) を作成して任意のリソースタイプを評価 C) CloudTrailと組み合わせて対応 D) AWS Configの代わりにTerraformを使用

正解: B 解説: AWS ConfigのカスタムLambdaルールではput_evaluations APIで任意のリソースに対してCompliant/Non-Compliantを報告できる。LambdaからAWS APIを呼び出してリソースの状態をチェックし、Config Serviceに評価結果を送信する。

問45: Amazon CloudWatch Contributor Insights の主な用途は？

A) コスト分析 B) 高カーディナリティデータ(DynamoDBのHot Key、APIのTop User等)のリアルタイム分析 C) セキュリティの監視 D) ML予測

正解: B 解説: Contributor Insightsはログデータ(CloudWatch Logs)または DynamoDB/API Gatewayの組み込みメトリクスから、最も多く貢献している上位N項目(例: 最多リクエストのIPアドレス、最も頻繁にアクセスされるDynamoDBキー)をリアルタイムで特定する。

Part 3: セキュリティ・コスト (問46-65)

問46: AWS Security Hub の主な機能は？

A) 脆弱性スキャンのみ B) 複数セキュリティサービス(GuardDuty/Inspector/Macie等)のセキュリティ findings を一元集約・管理・優先付け C) ネットワーク監視のみ D) コンプライアンスレポートのみ

正解: B 解説: Security Hubは(1)GuardDuty/Inspector/Macie/Config/IAM Access Analyzer等からfindingsを集約 (2)CSPM(クラウドセキュリティポスチャ管理)のベストプラクティスチェック (3)ASFF形式での標準化 (4)EventBridgeとの統合で自動修復。

問47: EC2インスタンスへの不必要なSSHアクセスを防ぐためのAWSベストプラクティスは？

A) パスワード認証を使用 B) セキュリティグループでポート22をブロック + SSM Session Managerでシェルアクセス C) ポート22を変更 D) IPアドレスで制限

正解: B 解説: Session Managerで22/3389ポート不要。セキュリティグループからSSH/RDPのインバウンドルールを削除してアタックサーフェスを削減。Session Managerのログ記録で監査証跡も確保。AWS Systems Manager Fleet ManagerでGUI接続も可能。

問48: Amazon CloudWatch の高解像度メトリクスとは？

A) グラフの解像度 B) 1秒間隔でデータポイントを記録できるカスタムメトリクス(標準は60秒) C) HD画質のダッシュボード D) リアルタイムのメトリクス

正解: B 解説: 標準メトリクスは1分粒度。High-Resolutionカスタムメトリクスは1/5/10/30秒粒度で記録可能。put_metric_dataでStorageResolution=1を指定。高解像度メトリクスに対するアラームも1/5/10/30/60秒の評価が可能。

問49: AWS Trusted Advisor のすべてのチェックへのアクセスに必要なサポートプランは？

A) Basic B) Business または Enterprise サポートプラン C) Developer D) 全プランで利用可能

正解: B 解説: Trusted Advisorのチェックカテゴリ別アクセス: Basic/Developerはセキュリティ(7チェック)とサービス制限のみ。Business/EnterpriseはCore Checksを含む全チェック(200+)にアクセス可能。API アクセスもBusiness以上が必要。

問50: CloudFormation StackSets で FAILED ステータスのスタックインスタンスを再デプロイするには？

A) 失敗したインスタンスを削除して再作成 B) update-stack-instances または create-stack-instances で対象インスタンスを指定して再デプロイ C) StackSetを削除して最初からやり直し D) 手動でCloudFormationを実行

正解: B 解説: StackSet Instancesの状態確認後、update-stack-instancesコマンドで特定のアカウント/リージョンを指定して再デプロイ。OperationがFAILEDのインスタンスのみを対象にすることでリトライが可能。

問51: EC2 のSavings Plans と Reserved Instances の主な違いは？

A) 機能は同じ B) Savings Plansはインスタンスタイプ/リージョンを問わずコンピュート使用量に割引適用、RIは特定インスタンスタイプ/リージョンに紐づく C) Savings PlansはEC2のみ対応 D) RIのみ1年/3年選択可能

正解: B 解説: Compute Savings Plans: EC2/Fargate/Lambdaの使用量に適用、インスタンスファミリー/リージョン/OS変更に柔軟対応。EC2 Instance Savings Plans: 特定ファミリー+リージョンで最大72%割引。RIは特定インスタンスタイプに紐づきSavings Plansより複雑だが割引率が同等以上の場合もある。

問52: AWS の「Shared Responsibility Model」でお客様の責任範囲は？

A) AWSが全ての責任を負う B) クラウド内のセキュリティ: OS設定、アプリケーション、データ、アクセス管理 C) ハードウェアのみ D) データセンターのみ

正解: B 解説: 責任共有モデル: AWS責任(クラウドのセキュリティ): ハードウェア、ネットワーク、施設、ハイパーバイザー。顧客責任(クラウド内のセキュリティ): OS、パッチ適用、アプリケーション、データ暗号化、アクセス管理、ネットワーク設定。

問53: CloudWatch Logs でログデータの保持期間を設定するには？

A) デフォルトで5年 B) ロググループのRetention Settingで1日〜10年の保持期間、またはNever Expire(無期限)を設定 C) S3のライフサイクルポリシーのみで管理 D) 保持期間の変更は不可能

正解: B 解説: ロググループのRetention Policyは1、3、5、7、14、30、60、90、120、150、180、365、400、545、731、1096、1827、2192、2557、2922、3288日またはNever Expireから選択。コスト削減のため適切な保持期間の設定が重要。

問54: AWS WAF の Rate-based ルールの用途は？

A) すべてのルールはRate-based B) 特定IPアドレスから一定時間内に指定リクエスト数を超えた場合に自動ブロック(DDoS/ブルートフォース対策) C) ホワイトリストのみ D) 帯域幅の制限

正解: B 解説: Rate-based Ruleは例えば「同一IPから5分間に100リクエスト以上」の条件でそのIPを自動的にブロック/カウントする。ブルートフォース攻撃、スクレイピング、DDoS軽減に使用。追加のMatch Conditionsと組み合わせることもできる。

問55: EC2のステータスチェックがStatusCheckFailed_Instance(インスタンスステータスチェック失敗)の場合の対処法は？

A) AWS Supportに連絡 B) インスタンスを再起動(Stop→Start)でデータを保持しながら別のホストに移動 C) AMIを再作成 D) Auto Scalingで代替インスタンスを起動

正解: B 解説: Instance Status Check Failure: ゲストOSの問題。Stop→Start (Rebootではなく必ずStop/Startで別物理ホストに移動)で多くのケースが解決。ただしインスタンスストアデータは消える。永続的な問題はカーネルログ確認やAMI再作成が必要。

問56: AWS マルチアカウント環境でのCloudTrailログの集中管理の設計は？

A) 各アカウントで個別管理 B) Organizations Trailで全アカウントのログを管理アカウントのS3に集中収集 C) CloudTrailのみで対応不可 D) 手動でログを転送

正解: B 解説: Organizations CloudTrail Trailを管理アカウントで作成すると、組織内の全アカウントのAPI呼び出しが中央S3バケットに集約される。各アカウントで個別設定不要。S3バケットポリシーで全アカウントからの書き込みを許可。

問57: AWS CloudWatch Logs のサブスクリプションフィルターでリアルタイムにログを処理するパターンは？

A) S3にエクスポートのみ B) CloudWatch Logs → Subscription Filter → Kinesis Data Streams/Firehose/Lambda → 後続処理 C) Athenaでのクエリのみ D) SNSへの直接送信

正解: B 解説: サブスクリプションフィルターでCWLのログをリアルタイムにKinesis Data Streams、Kinesis Data Firehose、または Lambda 関数に転送できる。OpenSearch、S3、サードパーティSIEMへのリアルタイムストリームに使用。

問58: Amazon EC2 Fleet の主な特徴は？

A) 単一インスタンスタイプのみ対応 B) 複数インスタンスタイプ/購入オプション(On-Demand/Spot/RI)の組み合わせを単一リクエストで起動 C) Auto Scalingの一種 D) ECSのみで使用

正解: B 解説: EC2 Fleet(またはSpot Fleet)は複数のインスタンスタイプ/サイズ/AZを指定し、コスト最安またはキャパシティ最大の戦略で自動選択して起動。Spot Instanceの中断に対してOn-Demandへの自動切り替えを設定できる。

問59: CloudFormation でリソースが誤って削除されないようにするには？

A) テンプレートにパスワードを設定 B) DeletionPolicyをRetainまたはSnapshotに設定、TerminationProtectionを有効化 C) リソース削除APIを無効化 D) IAMポリシーで制御のみ

正解: B 解説: DeletionPolicy: Retain: スタック削除後もリソースを残す。DeletionPolicy: Snapshot: RDS/EBS/ElastiCacheスタック削除前にスナップショット作成。TerminationProtection: スタック自体の削除を保護。大切なデータリソースには必ず設定。

問60: AWS Systems Manager のパラメータタイプ SecureString の特徴は？

A) プレーンテキストで保存 B) KMSキーで暗号化して保存され、参照時は自動復号され、パラメータ値はCloudTrailに記録されない C) 暗号化はオプション D) アクセスはIAMでのみ制御

正解: B 解説: SecureStringはSSM Parameter StoreでKMS CMK暗号化。ssm:GetParameter権限に加えてKMSのkms:Decrypt権限が必要。CloudFormationから参照可能({{resolve:ssm-secure:ParameterName:Version}})。Secrets Managerより軽量でAPIキー等の設定値に適する。

問61: Amazon Route 53 Health Check の監視対象として設定できるのは？

A) AWSリソースのみ B) IPアドレスまたはドメイン名(AWS外のオンプレリソースも対象)+ CloudWatchアラームのヘルスチェック C) EC2インスタンスのみ D) ELBのみ

正解: B 解説: Route 53 Health CheckはAWS外のリソース含む任意のHTTP/HTTPS/TCPエンドポイントを監視可能。CloudWatch Alarm Healthcheckにより直接HTTPSチェックができないリソース(Lambda、DynamoDB等)のヘルスも間接的に監視可能。

問62: AWS Config Aggregator を使用する目的は？

A) リソース設定の変更通知 B) 複数アカウント/リージョンのConfig設定とコンプライアンス状態を単一集約アカウントで一元管理 C) コンプライアンスの自動修復 D) IAM権限の管理

正解: B 解説: Config Aggregatorは複数のソースアカウントまたはOrganizations全体のConfigデータを集約し、管理アカウントからのコンプライアンス状態の全体ビューを提供。各アカウントのConfigを個別確認する手間を省く。

問63: AWS Budgets で予算アラートを設定する際に通知できる対象は？

A) メールのみ B) メールアドレス(最大10)とSNSトピック C) SlackのみとSNS D) 通知機能はない

正解: B 解説: AWS Budgetsの通知先: 最大10個のメールアドレス + SNSトピック(1つ)。SNSを経由してLambda、Slack webhook、PagerDutyなどに接続できる。アクションとしてSCP適用、RIの停止、EC2の停止等も設定可能。

問64: S3 Intelligent-Tiering のモニタリング料金が発生するオブジェクトサイズの閾値は？

A) 全オブジェクト B) 128KB以上のオブジェクトにモニタリング料金が発生、128KB未満は無料でFrequent Accessに留まる C) 1MB以上 D) 10MB以上

正解: B 解説: S3 Intelligent-Tieringはオブジェクトごとにモニタリング料金(128KB以上のオブジェクトのみ)が発生。128KB未満は常にFrequent Accessに留まりモニタリング料金なし。128KB未満の小さなオブジェクトを大量に格納する場合はS3 Standardの方が安い場合もある。

問65: マルチAZ構成でのRDSの読み取りスケールアウトをどのように実現するか？

A) Multi-AZスタンバイを読み取り用に使用 B) Multi-AZとは別にRead Replicaを追加で作成(Aurora: 最大15個, RDS: 最大5個) C) プライマリインスタンスのスペックアップのみ D) ElastiCacheのみで対応

正解: B 解説: RDS Multi-AZのスタンバイは読み取りには使用不可(フェイルオーバー専用)。読み取りスケールアウトにはRead Replicaを別途作成。Aurora Replicaはプライマリ障害時のフェイルオーバーにも使用でき、15個まで作成可能。

付録: SOA-C03 重要ポイント総まとめ

【SOA-C03 必須暗記事項】

■ CloudWatch
  高解像度メトリクス: 1/5/10/30秒 (PutMetricData StorageResolution=1)
  Composite Alarm: AND/OR/NOT条件の複合アラーム
  Anomaly Detection: ML異常検知バンド
  Logs Insights: ログ分析クエリ言語
  Contributor Insights: Top N分析

■ Systems Manager
  Session Manager: SSHなしシェルアクセス
  Patch Manager: パッチベースライン, Maintenance Window
  Parameter Store: 設定値保存 (SecureString=KMS暗号化)
  Automation: SSM Runbook, aws:approve承認ゲート
  OpsCenter: 運用イシュー管理
  State Manager: 設定ドリフト防止

■ Auto Scaling
  Predictive Scaling: ML予測スケーリング
  Warm Pool: コールドスタート削減
  Lifecycle Hooks: 起動/終了時の前後処理
  TerminationPolicy: 最も古いインスタンスから削除等

■ CloudFormation
  ChangeSet: 変更プレビュー
  StackSets: マルチアカウント展開
  Custom Resource: Lambda連携でCFn非対応リソース管理
  DeletionPolicy: Retain/Snapshot
  Rollback Triggers: CloudWatchアラームでロールバック
  Resource Import: 既存リソースのスタック取り込み

■ コスト管理
  Cost Anomaly Detection: ML異常検知
  Trusted Advisor: 低使用率リソース検出
  Compute Optimizer: インスタンスサイズ最適化
  Savings Plans: 柔軟な割引(Compute/EC2/SageMaker)

■ セキュリティ
  Security Hub: セキュリティfindingsの集約
  GuardDuty: 脅威検知(CloudTrail/VPCFlow/DNS)
  Inspector: 脆弱性スキャン
  IMDSv2: セッションベースのメタデータアクセス

【試験戦略】
1. 自動化問題: EventBridge + Lambda/SSM Automation
2. 監視問題: CloudWatch(メトリクス/ログ/アラーム)+Config
3. コンプライアンス: Config Rules + Auto Remediation
4. コスト問題: Trusted Advisor + Compute Optimizer + Cost Explorer
5. セキュリティ問題: Security Hub + GuardDuty + Inspector の組み合わせ

SOA-C03 (AWS Certified CloudOps Engineer Associate) 試験対策ガイド完成 作成日: 2026-04

模擬試験 第2回 (追加問題)

問66: EC2インスタンスの「Retirement」通知を受け取った場合のベストプラクティスは？

A) 通知を無視する B) 指定されたリタイア日時前にインスタンスを停止→起動して別のホストに移行 C) インスタンスを再起動する D) AMIを削除して再作成

正解: B 解説: AWS Health Dashboardでインスタンスのリタイア通知を受けた場合、Stop→Startで別の物理ホストに移行することで問題を回避。Rebootでは同一ホストのままなので効果なし。EBSベースのインスタンスならデータは保持される。

問67: AWS Systems Manager Change Manager でどのような変更をオーケストレートできるか？

A) ソフトウェアコードの変更のみ B) インフラ変更のリクエスト、承認、実行、監査サイクルを管理(SSM Automationの実行含む) C) クラウドコストの変更のみ D) ユーザー権限の変更のみ

正解: B 解説: Change ManagerはITIL変更管理プロセスをAWS上で実現。変更テンプレート→変更リクエスト→承認者によるレビュー→SSM Automation実行→監査ログの一連のプロセスを自動化。本番環境変更のガバナンス強化に使用。

問68: EC2 Spot Instanceが中断される前に受け取る通知のリードタイムは？

A) 24時間 B) 2分前にEC2インスタンスメタデータとEventBridgeでSpot Interruption Notice通知 C) 5分前 D) 通知はない

正解: B 解説: Spot Interruption Noticeは中断の2分前に通知。(1)インスタンスメタデータ(http://169.254.169.254/latest/meta-data/spot/interruption-action)からポーリング (2)EventBridge EC2 Spot Instance Interruption Warningイベント でLambda/SQSへ通知可能。

問69: Amazon CloudWatch Synthetics の主な機能は？

A) リアルユーザーの監視 B) Canaryスクリプト(Node.js/Python)でエンドポイントを定期的に監視し、可用性と応答時間をテスト C) ログ分析の自動化 D) コスト最適化

正解: B 解説: CloudWatch Syntheticsは合成監視(Synthetic Monitoring)で実際のユーザーがいなくても定期的にAPIやWebページをテスト。Canaryスクリプトでログイン、商品追加、チェックアウト等のユーザーフローをシミュレート。

問70: AWS Systems Manager OpsCenter でOpsItemのステータスを管理する方法は？

A) ステータス管理は不可能 B) Open/InProgress/Resolvedのステータスで管理し、関連するAWSリソースへのリンクと対応手順を記録 C) 全てAUTOで解決される D) チケットシステムとの連携が必須

正解: B 解説: OpsItemは Open→InProgress→Resolved/Closed のライフサイクルを管理。関連するCloudWatchアラーム、Config変更、CloudTrailイベントを関連リソースとして自動関連付け。SSM Automation Runbookを直接実行してOpsItem内で解決アクションを実行できる。

問71: CloudFormation の WaitCondition と WaitConditionHandle を使用する場面は？

A) タイムアウト設定のみ B) EC2インスタンスのユーザーデータスクリプト等の完了を待機して次のリソース作成を進める C) 承認ゲートとして使用 D) エラーハンドリング

正解: B 解説: WaitConditionでEC2ユーザーデータスクリプトの完了を待機: (1)WaitConditionHandle(URL)をユーザーデータに渡す (2)スクリプト完了後にURLへCURLでシグナル送信 (3)WaitConditionが受信したらCloudFormationが次のリソース作成を開始。

問72: Auto Scaling グループでの Instance Refresh (ローリング更新) の設定は？

A) 手動でインスタンスを1台ずつ更新 B) start-instance-refresh APIで新しいLaunch Templateを使用したローリング更新を自動実行 C) ASGの再作成が必要 D) CodeDeployのみで実行可能

正解: B 解説: Instance RefreshはASGの起動テンプレート変更(AMI更新、インスタンスタイプ変更等)を新しいインスタンスで段階的に置き換える機能。MinHealthyPercentageで同時に更新する最大割合を制御し、ヘルスチェック合格後に次のバッチを更新。

問73: CloudWatch EMF (Embedded Metric Format) の利点は？

A) ログの圧縮 B) アプリケーションログに高次元のメトリクスデータを埋め込み、別途put_metric_data呼び出しなしにCloudWatchメトリクスを作成 C) コストの削減 D) Lambda専用機能

正解: B 解説: EMFはJSONログのフォーマット仕様で、Lambdaや任意のアプリケーションのログにメトリクスデータを構造化して埋め込む。CloudWatch Logsが自動的にメトリクスを抽出・集計。APIレイテンシ、エラー率等のビジネスメトリクスを簡単に収集できる。

問74: SSM Automation の aws:executeScript ステップの特徴は？

A) シェルスクリプトのみ実行可能 B) Python 3またはPowerShellスクリプトをSSM管理下で直接実行できる C) Lambda関数が必要 D) EC2インスタンス上でのみ実行

正解: B 解説: aws:executeScriptはSSM Automationドキュメント内でPython 3またはPowerShellスクリプトを直接実行するステップ。AWS SDKが使用可能で、Lambda関数を別途作成する必要なくAWS APIコールやロジックを実装できる。

問75: EC2 Auto Scaling の target tracking policy で使用できるメトリクスは？

A) CPU使用率のみ B) CPU使用率、ALBリクエスト数/ターゲット、ネットワーク入出力、カスタムメトリクス C) メモリ使用率とCPU使用率のみ D) CloudWatch Logsのメトリクスのみ

正解: B 解説: Target Tracking PolicyのPredefined metrics: ASGAverageCPUUtilization、ASGAverageNetworkIn/Out、ALBRequestCountPerTarget。カスタムメトリクス(CustomizedMetricSpecification)で任意のCloudWatchメトリクスも使用可能。

問76: AWS Config Aggregatorのアグリゲーターソースとして設定できるのは？

A) 単一アカウントのみ B) 個別のAWSアカウント + リージョンのリスト、またはAWS Organization全体 C) AWSリージョンのみ D) Organizationsのみ対応

正解: B 解説: Config Aggregatorはソースとして(1)個別アカウント+リージョンのリスト、または(2)AWS Organizations全体(管理アカウント+全メンバーアカウント+全リージョン)を選択できる。クロスアカウントの認可が必要。

問77: AWS Systems Manager Distributor の主な用途は？

A) S3ファイルの配布 B) ソフトウェアパッケージ(エージェント、ツール、カスタムアプリ)をSSM管理対象インスタンスに展開・更新 C) コードのデプロイ D) 設定ファイルの管理

正解: B 解説: SSM Distributorはパッケージ(zip/zip.tar.gz)をSSM上で管理し、対象インスタンスに自動展開。CloudWatch Agentなどのエージェントの一括インストールや更新に使用。スケジュールによる自動更新も可能。

問78: CloudWatch アラームの treat_missing_data パラメータで breaching を設定するのはどのような場合か？

A) 常にbreachingを設定 B) データが来ない場合も問題があると見なすべき場合(例: ヘルスチェックが停止した場合) C) 正常なデフォルト設定 D) コストを削減したい場合

正解: B 解説: breaching: データなし=アラーム状態。ヘルスチェックや重要な監視で適用(データが来ない=問題)。notBreaching: データなし=正常。変動的なメトリクスに適用。ignore: データなしを無視して現在の状態を維持。missing: データなし=INSUFFICIENT_DATA。

問79: Amazon CloudWatch の GetMetricData vs GetMetricStatistics の違いは？

A) 機能は同じ B) GetMetricDataは複数メトリクスの一括取得と数式計算が可能でコスト効率が高く推奨, GetMetricStatisticsは単一メトリクスのレガシーAPI C) GetMetricStatisticsの方が新しい D) GetMetricDataはカスタムメトリクスのみ

正解: B 解説: GetMetricDataは複数のメトリクスを単一リクエストで取得、メトリクス数式(DIFF/RATE等)の適用、ページネーションがサポートされ、GetMetricStatisticsより効率的。新規実装ではGetMetricDataを使用することが推奨。

問80: AWS Organizations でアカウントをOUに移動した場合のSCPの影響は？

A) SCPはすぐに適用されない B) 移動後すぐに移動先OUのSCPが適用され、元のOUのSCPは解除される C) 手動でSCPを再適用する必要がある D) SCPは1時間後に適用される

正解: B 解説: アカウントをOU間で移動すると、IAM評価はリアルタイムで変更される。移動先OUのSCPが即座に適用される。移動前に新しいOUのSCPが対象アカウントの既存ワークロードに影響しないかを事前に確認することが重要。

付録: 追加チェックリスト

【SOA-C03 最終確認リスト】

□ CloudWatch
  ✓ Logs Insightsの主要クエリ文法 (stats/filter/fields/sort)
  ✓ Metric Math (SUM/RATE/DIFF/ANOMALY_DETECTION_BAND)
  ✓ Composite Alarm (AND/OR/NOT)
  ✓ EMF (Embedded Metric Format)
  ✓ CloudWatch Synthetics (合成監視)
  ✓ Container Insights (ECS/EKS)
  ✓ Application Insights (アプリ問題の根本原因分析)

□ Systems Manager
  ✓ Session Manager (ポート開放不要)
  ✓ Automation (Runbook, aws:approve, aws:executeScript)
  ✓ Patch Manager (Baseline, Maintenance Window, Compliance)
  ✓ Change Manager (変更管理ワークフロー)
  ✓ Distributor (パッケージ展開)
  ✓ OpsCenter + OpsItems
  ✓ Parameter Store vs Secrets Manager の使い分け

□ Auto Scaling
  ✓ Predictive Scaling (ML予測)
  ✓ Warm Pool (コールドスタート削減)
  ✓ Lifecycle Hooks (LAUNCHING/TERMINATING)
  ✓ Instance Refresh (ローリング更新)
  ✓ Target Tracking / Step / Scheduled Policies

□ CloudFormation
  ✓ ChangeSets, WaitCondition, Custom Resource
  ✓ StackSets (SERVICE_MANAGED, SELF_MANAGED)
  ✓ DeletionPolicy (Retain/Snapshot)
  ✓ Rollback Triggers (CloudWatchアラーム連携)
  ✓ cfn-signal, cfn-init, cfn-hup

□ セキュリティ
  ✓ Security Hub (findings集約)
  ✓ GuardDuty (脅威検知)
  ✓ Inspector 2 (脆弱性スキャン)
  ✓ AWS Health Events (EventBridge統合)
  ✓ IMDSv2 (SSRF対策)

□ コスト・ガバナンス
  ✓ Cost Anomaly Detection
  ✓ Compute Optimizer
  ✓ AWS Budgets + Actions
  ✓ Trusted Advisor
  ✓ Organizations SCPs
  ✓ Control Tower + Account Factory

SOA-C03 完全学習ガイド - 全セクション完了

第6章: コスト最適化・タグ管理・請求管理

6.1 AWS Cost Explorer と Budgets

import boto3
import json
from datetime import datetime, timedelta

ce_client = boto3.client('ce', region_name='us-east-1')
budgets_client = boto3.client('budgets', region_name='us-east-1')

# コスト分析クエリ
def get_cost_by_service(start_date, end_date):
    response = ce_client.get_cost_and_usage(
        TimePeriod={
            'Start': start_date,
            'End': end_date
        },
        Granularity='MONTHLY',
        Metrics=['BlendedCost', 'UnblendedCost', 'UsageQuantity'],
        GroupBy=[
            {'Type': 'DIMENSION', 'Key': 'SERVICE'},
            {'Type': 'TAG', 'Key': 'Environment'}
        ],
        Filter={
            'Dimensions': {
                'Key': 'SERVICE',
                'Values': ['Amazon EC2', 'Amazon RDS', 'Amazon S3']
            }
        }
    )
    return response['ResultsByTime']

# コスト異常検出設定
def create_cost_anomaly_monitor():
    response = ce_client.create_anomaly_monitor(
        AnomalyMonitor={
            'MonitorName': 'ServiceCostMonitor',
            'MonitorType': 'DIMENSIONAL',
            'MonitorDimension': 'SERVICE'
        }
    )
    monitor_arn = response['MonitorArn']
    
    # アラート設定
    ce_client.create_anomaly_subscription(
        AnomalySubscription={
            'MonitorArnList': [monitor_arn],
            'Subscribers': [
                {
                    'Address': 'arn:aws:sns:ap-northeast-1:123456789012:CostAlerts',
                    'Type': 'SNS'
                }
            ],
            'Threshold': 100.0,  # $100以上の異常
            'Frequency': 'DAILY',
            'SubscriptionName': 'DailyCostAnomalyAlert'
        }
    )
    return monitor_arn

# 予算アラート作成
def create_monthly_budget(account_id, budget_amount, alert_threshold=80):
    budgets_client.create_budget(
        AccountId=account_id,
        Budget={
            'BudgetName': 'MonthlyAWSBudget',
            'BudgetLimit': {
                'Amount': str(budget_amount),
                'Unit': 'USD'
            },
            'TimeUnit': 'MONTHLY',
            'BudgetType': 'COST',
            'CostFilters': {
                'TagKeyValue': ['user:Environment$production']
            }
        },
        NotificationsWithSubscribers=[
            {
                'Notification': {
                    'NotificationType': 'ACTUAL',
                    'ComparisonOperator': 'GREATER_THAN',
                    'Threshold': alert_threshold,
                    'ThresholdType': 'PERCENTAGE'
                },
                'Subscribers': [
                    {
                        'SubscriptionType': 'EMAIL',
                        'Address': 'admin@example.com'
                    },
                    {
                        'SubscriptionType': 'SNS',
                        'Address': 'arn:aws:sns:ap-northeast-1:123456789012:BudgetAlerts'
                    }
                ]
            },
            {
                'Notification': {
                    'NotificationType': 'FORECASTED',
                    'ComparisonOperator': 'GREATER_THAN',
                    'Threshold': 100,
                    'ThresholdType': 'PERCENTAGE'
                },
                'Subscribers': [
                    {
                        'SubscriptionType': 'EMAIL',
                        'Address': 'admin@example.com'
                    }
                ]
            }
        ]
    )

# Savings Plans / Reserved Instance 推薦
def get_savings_plan_recommendations():
    response = ce_client.get_savings_plans_purchase_recommendation(
        SavingsPlansType='COMPUTE_SP',  # or 'EC2_INSTANCE_SP'
        TermInYears='ONE_YEAR',
        PaymentOption='PARTIAL_UPFRONT',
        LookbackPeriodInDays='SIXTY_DAYS'
    )
    return response['SavingsPlansPurchaseRecommendation']

6.2 AWS タグ管理戦略

import boto3

# タグポリシー定義（AWS Organizations）
TAG_POLICY = {
    "tags": {
        "Environment": {
            "tag_value": {
                "@@assign": ["production", "staging", "development"]
            },
            "enforced_for": {
                "@@assign": [
                    "ec2:instance",
                    "rds:db",
                    "s3:bucket"
                ]
            }
        },
        "CostCenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "enforced_for": {
                "@@assign": ["ec2:instance", "rds:db"]
            }
        },
        "Owner": {
            "tag_key": {
                "@@assign": "Owner"
            }
        }
    }
}

# タグコンプライアンスチェック
def check_tag_compliance():
    config_client = boto3.client('config', region_name='ap-northeast-1')
    
    response = config_client.get_compliance_details_by_config_rule(
        ConfigRuleName='required-tags',
        ComplianceTypes=['NON_COMPLIANT']
    )
    
    non_compliant = []
    for result in response['EvaluationResults']:
        non_compliant.append({
            'resource_type': result['EvaluationResultIdentifier']['EvaluationResultQualifier']['ResourceType'],
            'resource_id': result['EvaluationResultIdentifier']['EvaluationResultQualifier']['ResourceId'],
            'annotation': result.get('Annotation', 'Missing required tags')
        })
    
    return non_compliant

# 自動タグ付け Lambda
def auto_tag_handler(event, context):
    """CloudTrailイベントからリソース作成を検出して自動タグ付け"""
    
    ec2_client = boto3.client('ec2')
    
    detail = event['detail']
    event_name = detail['eventName']
    user_identity = detail['userIdentity']
    
    # タグ付け対象イベント
    tag_events = {
        'RunInstances': ('instancesSet', 'instanceId', 'ec2:instance'),
        'CreateVolume': (None, 'volumeId', 'ec2:volume'),
        'CreateBucket': (None, 'name', 's3:bucket')
    }
    
    if event_name not in tag_events:
        return
    
    # 作成者情報
    creator = user_identity.get('userName') or user_identity.get('sessionContext', {}).get('sessionIssuer', {}).get('userName', 'unknown')
    
    tags = [
        {'Key': 'CreatedBy', 'Value': creator},
        {'Key': 'CreatedAt', 'Value': detail['eventTime']},
        {'Key': 'Region', 'Value': detail['awsRegion']}
    ]
    
    # 既存タグに追加
    if event_name == 'RunInstances':
        instances = detail['responseElements']['instancesSet']['items']
        for instance in instances:
            ec2_client.create_tags(
                Resources=[instance['instanceId']],
                Tags=tags
            )
    
    return {'statusCode': 200, 'body': 'Tags applied'}

6.3 AWS Trusted Advisor 自動化

import boto3

support_client = boto3.client('support', region_name='us-east-1')

def get_trusted_advisor_checks():
    """Trusted Advisorチェック一覧取得"""
    response = support_client.describe_trusted_advisor_checks(language='ja')
    
    # カテゴリ別分類
    checks_by_category = {}
    for check in response['checks']:
        category = check['category']
        if category not in checks_by_category:
            checks_by_category[category] = []
        checks_by_category[category].append({
            'id': check['id'],
            'name': check['name'],
            'description': check['description']
        })
    
    return checks_by_category

def get_cost_optimization_recommendations():
    """コスト最適化の推奨事項取得"""
    
    # コスト最適化カテゴリのチェック
    cost_checks = [
        'Qch7DwouX1',   # 低使用率EC2インスタンス
        'hjLMh88uM8',   # アイドルRDSインスタンス
        'DqdJqYeRm5',   # 未使用のEIP
        'Z4AUBRNSmz',   # 不要なEBSスナップショット
    ]
    
    recommendations = []
    for check_id in cost_checks:
        response = support_client.describe_trusted_advisor_check_result(
            checkId=check_id,
            language='ja'
        )
        
        result = response['result']
        if result['status'] in ['warning', 'error']:
            for resource in result.get('flaggedResources', []):
                recommendations.append({
                    'check_id': check_id,
                    'resource_id': resource.get('resourceId'),
                    'metadata': resource.get('metadata', []),
                    'estimated_monthly_savings': resource.get('estimatedMonthlySavings', 0)
                })
    
    return recommendations

第7章: セキュリティ・コンプライアンス自動化

7.1 AWS Security Hub

import boto3
import json

sh_client = boto3.client('securityhub', region_name='ap-northeast-1')

# Security Hub 有効化と標準設定
def enable_security_hub():
    # Security Hub有効化
    sh_client.enable_security_hub(
        EnableDefaultStandards=True
    )
    
    # セキュリティ標準の有効化
    standards = [
        'arn:aws:securityhub:ap-northeast-1::standards/aws-foundational-security-best-practices/v/1.0.0',
        'arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.2.0'
    ]
    
    sh_client.batch_enable_standards(
        StandardsSubscriptionRequests=[
            {'StandardsArn': arn} for arn in standards
        ]
    )

# 重大度HIGH/CRITICAL findings の自動修復
def auto_remediate_findings(event, context):
    """EventBridgeからSecurity Hub findingを受け取り自動修復"""
    
    finding = event['detail']['findings'][0]
    
    finding_type = finding['Types'][0]
    resources = finding['Resources']
    severity = finding['Severity']['Label']
    
    if severity not in ['HIGH', 'CRITICAL']:
        return
    
    for resource in resources:
        resource_type = resource['Type']
        resource_id = resource['Id']
        
        # S3バケットのパブリックアクセスブロック
        if resource_type == 'AwsS3Bucket' and 'S3.2' in finding_type:
            s3_client = boto3.client('s3')
            bucket_name = resource_id.split(':::')[1]
            
            s3_client.put_public_access_block(
                Bucket=bucket_name,
                PublicAccessBlockConfiguration={
                    'BlockPublicAcls': True,
                    'IgnorePublicAcls': True,
                    'BlockPublicPolicy': True,
                    'RestrictPublicBuckets': True
                }
            )
            
            # Findingのステータスを更新
            sh_client.batch_update_findings(
                FindingIdentifiers=[
                    {
                        'Id': finding['Id'],
                        'ProductArn': finding['ProductArn']
                    }
                ],
                Workflow={'Status': 'RESOLVED'},
                Note={
                    'Text': 'Auto-remediated: S3 public access blocked',
                    'UpdatedBy': 'AutoRemediationLambda'
                }
            )
        
        # EC2セキュリティグループの0.0.0.0/0ルール削除
        elif resource_type == 'AwsEc2SecurityGroup':
            ec2_client = boto3.client('ec2')
            sg_id = resource_id.split('/')[1]
            
            sg_info = ec2_client.describe_security_groups(GroupIds=[sg_id])
            sg = sg_info['SecurityGroups'][0]
            
            for rule in sg['IpPermissions']:
                for ip_range in rule.get('IpRanges', []):
                    if ip_range['CidrIp'] == '0.0.0.0/0':
                        ec2_client.revoke_security_group_ingress(
                            GroupId=sg_id,
                            IpPermissions=[rule]
                        )

7.2 AWS GuardDuty

import boto3

gd_client = boto3.client('guardduty', region_name='ap-northeast-1')

# GuardDuty 設定
def enable_guardduty():
    response = gd_client.create_detector(
        Enable=True,
        FindingPublishingFrequency='FIFTEEN_MINUTES',
        DataSources={
            'S3Logs': {'Enable': True},
            'Kubernetes': {
                'AuditLogs': {'Enable': True}
            },
            'MalwareProtection': {
                'ScanEc2InstanceWithFindings': {
                    'EbsVolumes': True
                }
            }
        }
    )
    return response['DetectorId']

# GuardDuty Finding の自動応答
def guardduty_response_handler(event, context):
    """GuardDuty Findingへの自動応答"""
    
    finding = event['detail']
    finding_type = finding['type']
    severity = finding['severity']
    
    # 重大度7以上（HIGH/CRITICAL）のみ対応
    if severity < 7.0:
        return
    
    # EC2インスタンスの侵害が疑われる場合
    if 'EC2' in finding_type and ('CryptoCurrency' in finding_type or 'Trojan' in finding_type):
        ec2_client = boto3.client('ec2')
        instance_id = finding['resource']['instanceDetails']['instanceId']
        
        # インスタンスを隔離（セキュリティグループを変更）
        ec2_client.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=['sg-quarantine123456']  # 隔離用SG（全通信ブロック）
        )
        
        # スナップショット作成（フォレンジック用）
        instance = ec2_client.describe_instances(InstanceIds=[instance_id])
        volumes = instance['Reservations'][0]['Instances'][0]['BlockDeviceMappings']
        
        for vol in volumes:
            ec2_client.create_snapshot(
                VolumeId=vol['Ebs']['VolumeId'],
                Description=f'Forensic snapshot - GuardDuty finding {finding["id"]}',
                TagSpecifications=[{
                    'ResourceType': 'snapshot',
                    'Tags': [
                        {'Key': 'Purpose', 'Value': 'ForensicEvidence'},
                        {'Key': 'FindingId', 'Value': finding['id']}
                    ]
                }]
            )
        
        # 通知
        sns_client = boto3.client('sns')
        sns_client.publish(
            TopicArn='arn:aws:sns:ap-northeast-1:123456789012:SecurityIncidents',
            Subject=f'CRITICAL: Instance {instance_id} may be compromised',
            Message=json.dumps({
                'instance_id': instance_id,
                'finding_type': finding_type,
                'severity': severity,
                'action_taken': 'Instance isolated, forensic snapshot created',
                'finding_id': finding['id']
            }, indent=2)
        )

7.3 AWS Config 高度なルール

import boto3
import json

config_client = boto3.client('config', region_name='ap-northeast-1')

# 組織全体でのConfig Conformance Pack
CONFORMANCE_PACK_TEMPLATE = """
Parameters:
  AccessKeysRotatedParamMaxAccessKeyAge:
    Default: '90'
    Type: String

Resources:
  AccessKeysRotated:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: access-keys-rotated
      Source:
        Owner: AWS
        SourceIdentifier: ACCESS_KEYS_ROTATED
      InputParameters:
        maxAccessKeyAge: !Ref AccessKeysRotatedParamMaxAccessKeyAge

  RootAccountMFAEnabled:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: root-account-mfa-enabled
      Source:
        Owner: AWS
        SourceIdentifier: ROOT_ACCOUNT_MFA_ENABLED

  S3BucketPublicReadProhibited:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-public-read-prohibited
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket

  EC2InstanceNoPublicIP:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: ec2-instance-no-public-ip
      Source:
        Owner: AWS
        SourceIdentifier: EC2_INSTANCE_NO_PUBLIC_IP
"""

def deploy_conformance_pack(pack_name, template):
    response = config_client.put_conformance_pack(
        ConformancePackName=pack_name,
        TemplateBody=template
    )
    return response

# カスタムConfig Rule: 暗号化チェック
CUSTOM_ENCRYPTION_CHECK = """
import boto3
import json

def evaluate_compliance(configuration_item, rule_parameters):
    if configuration_item['resourceType'] != 'AWS::RDS::DBInstance':
        return 'NOT_APPLICABLE'
    
    db_instance = configuration_item['configuration']
    
    # ストレージ暗号化チェック
    if not db_instance.get('storageEncrypted', False):
        return 'NON_COMPLIANT'
    
    # Multi-AZチェック（本番環境のみ）
    tags = {tag['key']: tag['value'] for tag in configuration_item.get('tags', [])}
    if tags.get('Environment') == 'production':
        if not db_instance.get('multiAZ', False):
            return 'NON_COMPLIANT'
    
    return 'COMPLIANT'

def lambda_handler(event, context):
    invoking_event = json.loads(event['invokingEvent'])
    configuration_item = invoking_event['configurationItem']
    
    compliance = evaluate_compliance(configuration_item, event.get('ruleParameters', {}))
    
    config = boto3.client('config')
    config.put_evaluations(
        Evaluations=[
            {
                'ComplianceResourceType': configuration_item['resourceType'],
                'ComplianceResourceId': configuration_item['resourceId'],
                'ComplianceType': compliance,
                'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
            }
        ],
        ResultToken=event['resultToken']
    )
"""

第8章: マルチリージョン・DR設計

8.1 Route 53 フェイルオーバー設定

import boto3

r53_client = boto3.client('route53')

# Route 53 フェイルオーバー設定
def setup_multi_region_failover(hosted_zone_id, domain_name):
    
    # プライマリ（東京）ヘルスチェック
    primary_hc = r53_client.create_health_check(
        CallerReference='primary-hc-001',
        HealthCheckConfig={
            'IPAddress': '10.0.1.100',
            'Port': 443,
            'Type': 'HTTPS',
            'ResourcePath': '/health',
            'FullyQualifiedDomainName': f'primary.{domain_name}',
            'RequestInterval': 10,
            'FailureThreshold': 3,
            'MeasureLatency': True,
            'EnableSNI': True
        }
    )
    hc_id = primary_hc['HealthCheck']['Id']
    
    # タグ設定
    r53_client.change_tags_for_resource(
        ResourceType='healthcheck',
        ResourceId=hc_id,
        AddTags=[
            {'Key': 'Name', 'Value': 'Primary-HealthCheck'},
            {'Key': 'Region', 'Value': 'ap-northeast-1'}
        ]
    )
    
    # DNSレコード設定
    records = [
        # プライマリ（東京）
        {
            'Action': 'CREATE',
            'ResourceRecordSet': {
                'Name': domain_name,
                'Type': 'A',
                'SetIdentifier': 'primary-tokyo',
                'Failover': 'PRIMARY',
                'AliasTarget': {
                    'HostedZoneId': 'Z14GRHDCWA56QT',  # ALB HZI
                    'DNSName': 'primary-alb.ap-northeast-1.elb.amazonaws.com',
                    'EvaluateTargetHealth': True
                },
                'HealthCheckId': hc_id
            }
        },
        # セカンダリ（大阪）
        {
            'Action': 'CREATE',
            'ResourceRecordSet': {
                'Name': domain_name,
                'Type': 'A',
                'SetIdentifier': 'secondary-osaka',
                'Failover': 'SECONDARY',
                'AliasTarget': {
                    'HostedZoneId': 'Z1LQ4NKEG3LYQC',  # Osaka ALB HZI
                    'DNSName': 'secondary-alb.ap-northeast-3.elb.amazonaws.com',
                    'EvaluateTargetHealth': True
                }
            }
        }
    ]
    
    r53_client.change_resource_record_sets(
        HostedZoneId=hosted_zone_id,
        ChangeBatch={
            'Comment': 'Multi-region failover setup',
            'Changes': records
        }
    )
    
    return hc_id

# RTO/RPO目標別DR戦略
DR_STRATEGIES = {
    'backup_restore': {
        'rto': '24時間以上',
        'rpo': '24時間',
        'cost': '最低',
        'aws_services': ['S3 Cross-Region Replication', 'AWS Backup', 'CloudFormation'],
        'description': 'S3にバックアップ、必要時に別リージョンで復元'
    },
    'pilot_light': {
        'rto': '1-4時間',
        'rpo': '数分-1時間',
        'cost': '低',
        'aws_services': ['RDS Read Replica', 'Route 53', 'Auto Scaling', 'AMI'],
        'description': 'コアインフラのみ稼働、災害時にスケールアウト'
    },
    'warm_standby': {
        'rto': '数分-1時間',
        'rpo': '数秒-数分',
        'cost': '中',
        'aws_services': ['RDS Multi-AZ', 'Route 53 Failover', 'ALB', 'Auto Scaling'],
        'description': '縮小スケールで常時稼働、災害時に本番スケールに拡大'
    },
    'active_active': {
        'rto': '0（ゼロ）',
        'rpo': '0（ゼロ）',
        'cost': '最高',
        'aws_services': ['Route 53 Weighted/Latency', 'Global Accelerator', 'DynamoDB Global Tables', 'Aurora Global DB'],
        'description': '複数リージョンで同時稼働、瞬時フェイルオーバー'
    }
}

8.2 Aurora Global Database

import boto3
import time

rds_client = boto3.client('rds', region_name='ap-northeast-1')

# Aurora Global Database 作成
def create_aurora_global_db(global_db_id, primary_cluster_id):
    # プライマリクラスター作成
    primary_cluster = rds_client.create_db_cluster(
        DBClusterIdentifier=primary_cluster_id,
        Engine='aurora-mysql',
        EngineVersion='8.0.mysql_aurora.3.04.0',
        MasterUsername='admin',
        MasterUserPassword='SecurePassword123!',
        DatabaseName='myapp',
        StorageEncrypted=True,
        EnableCloudwatchLogsExports=['error', 'general', 'slowquery', 'audit'],
        DeletionProtection=True,
        EnableGlobalWriteForwarding=True  # セカンダリからプライマリへの書き込みフォワード
    )
    
    # Global DB 作成
    global_db = rds_client.create_global_cluster(
        GlobalClusterIdentifier=global_db_id,
        SourceDBClusterIdentifier=f'arn:aws:rds:ap-northeast-1:123456789012:cluster:{primary_cluster_id}'
    )
    
    return global_db

# セカンダリリージョンにクラスター追加
def add_secondary_region(global_db_id, secondary_cluster_id, secondary_region):
    rds_secondary = boto3.client('rds', region_name=secondary_region)
    
    secondary_cluster = rds_secondary.create_db_cluster(
        DBClusterIdentifier=secondary_cluster_id,
        Engine='aurora-mysql',
        GlobalClusterIdentifier=global_db_id,
        StorageEncrypted=True,
        EnableCloudwatchLogsExports=['error', 'general', 'slowquery']
    )
    
    return secondary_cluster

# 計画的フェイルオーバー（RPO=0）
def planned_failover(global_db_id, new_primary_cluster_arn):
    response = rds_client.failover_global_cluster(
        GlobalClusterIdentifier=global_db_id,
        TargetDbClusterIdentifier=new_primary_cluster_arn,
        AllowDataLoss=False  # 計画的フェイルオーバー（データ損失なし）
    )
    return response

# 非計画的フェイルオーバー（RTO優先）
def unplanned_failover(global_db_id, new_primary_cluster_arn):
    response = rds_client.failover_global_cluster(
        GlobalClusterIdentifier=global_db_id,
        TargetDbClusterIdentifier=new_primary_cluster_arn,
        AllowDataLoss=True  # プライマリが応答不能の場合
    )
    return response

模擬試験 セット3（20問）

問題1 AWS Cost ExplorerのSavings Plans購入推薦で、最もコスト削減効果が高い設定は？

A) EC2 Instance Savings Plans、1年、前払いなし B) Compute Savings Plans、3年、全額前払い C) EC2 Instance Savings Plans、3年、全額前払い（特定ファミリー） D) Compute Savings Plans、1年、部分前払い

正解: B 解説: Compute Savings Plans（3年・全額前払い）は最大66%割引。EC2 Instance Savings Plansは特定インスタンスファミリー・リージョン限定だが最大72%割引。コスト削減最大はEC2 Instance（特定）だが、柔軟性重視なら Compute SP。ただし試験では「最もコスト削減効果が高い」= 最長期間・最高前払いが正解。

問題2 GuardDutyでEC2インスタンスにCryptoCurrency:EC2/BitcoinTool.B!DNSが検出された場合の適切な対応順序は？

A) インスタンスを即座に削除する B) GuardDutyアラートを無視してモニタリングを続ける C) インスタンスを隔離SG（全通信ブロック）に変更し、フォレンジックスナップショットを取得後に調査 D) パスワードを変更してインスタンスを再起動する

正解: C 解説: インシデント対応のベストプラクティス: ①封じ込め（隔離SG）→ ②証拠保全（スナップショット）→ ③調査（メモリ・ログ分析）→ ④根本原因特定→ ⑤修復。即座の削除は証拠を失う。GuardDutyのAutomate対応はEventBridge+Lambdaで実装。

問題3 AWS Security Hubで複数アカウントの findings を集約する場合の設定は？

A) 各アカウントで個別にSecurity Hubを設定する B) AWS Organizationsの管理アカウントをSecurity Hub管理者として設定し、メンバーアカウントのfindingsを集約 C) CloudTrailでクロスアカウントログを有効化する D) AWS Config集約機能でfindingsを収集する

正解: B 解説: Security Hub管理者アカウント（Organizationsの委任管理者）を指定すると、メンバーアカウントのfindingsが自動集約。Organizations統合により新しいアカウントの自動オンボーディングも可能。単一ダッシュボードで全アカウントのセキュリティ状況を監視。

問題4 Route 53のLatency-based routingとGeolocation routingの違いは？

A) Latencyベースはユーザーの地理的位置、Geolocationはネットワーク遅延を基準にルーティング B) Latencyベースはネットワーク遅延（測定値）、Geolocationはユーザーの物理的位置を基準にルーティング C) 両方とも同じアルゴリズムで動作する D) Geolocationはマルチリージョン対応不可

正解: B 解説: Latency-based routing: AWSリージョンへの実測レイテンシーでルーティング（例: 東京ユーザーでも大阪の方が低レイテンシーなら大阪へ）。Geolocation routing: ユーザーのIPアドレスから判断した国・大陸・デフォルトでルーティング（法規制・コンテンツ配信規制に有用）。

問題5 Aurora Global Databaseの通常のレプリケーション遅延（クロスリージョン）はどの程度ですか？

A) 1秒未満（典型的に<1秒） B) 5-10秒 C) 30秒-1分 D) 5-15分

正解: A 解説: Aurora Global Databaseは専用インフラストラクチャによるクロスリージョンレプリケーションで通常<1秒の遅延。RPO<1秒、RTO<1分を実現。ストレージレイヤーでのレプリケーションのため、従来のbinlogベースより高速。最大5セカンダリリージョンをサポート。

問題6 AWS Config Conformance Packとは何ですか？

A) AWS Config ルールのコレクションをYAML/JSONテンプレートとしてパッケージ化したもの B) Config変更履歴の圧縮形式 C) マルチアカウントへのConfig同時デプロイツール D) Config評価結果のエクスポート形式

正解: A 解説: Conformance PackはAWS Config RulesとRemediationアクションをCloudFormationテンプレート形式でパッケージ化。CIS Benchmarks、PCI-DSS、NIST等の業界標準に対応した事前定義パックが利用可能。AWS Organizations全体にデプロイ可能でコンプライアンス一括管理に活用。

問題7 EC2インスタンスの定期的なパッチ適用をOperationsチームが手動で行っていますが、自動化する最も適切なAWSサービスは？

A) AWS Lambda + CloudWatch Events B) AWS Systems Manager Patch Manager + Maintenance Windows C) AWS CodeDeploy D) AWS OpsWorks

正解: B 解説: Systems Manager Patch Managerはパッチベースラインとパッチグループを定義し、Maintenance Windowsで定期スケジュールを設定してEC2の自動パッチ適用を実現。パッチコンプライアンスレポートも提供。SSM Agentがインストールされたインスタンスが対象。

問題8 CloudFormation StackSetsでOrganizations全体にリソースをデプロイする際の権限モデルは？

A) 各メンバーアカウントで手動でIAMロールを作成する B) SERVICE_MANAGED モードでOrganizations統合を使用し、自動的に権限を管理 C) 管理アカウントのAdministratorAccessロールを使用する D) AWS Control Towerのみがクロスアカウントデプロイをサポートする

正解: B 解説: StackSetsのSERVICE_MANAGEDモードはAWS Organizationsと統合し、StackSetsがサービスが使用する権限を自動管理。新しいアカウントへの自動デプロイや組織単位（OU）へのデプロイも可能。従来のSELF_MANAGEDモードは手動でIAMロール（AWSCloudFormationStackSetAdministrationRole等）の設定が必要。

問題9 CloudWatch Logs Insightsで過去24時間の5xx エラーを調査するクエリは？

A) SELECT * FROM logs WHERE status_code >= 500 B) fields @timestamp, @message | filter status_code >= 500 | sort @timestamp desc | limit 100 C) GET logs WHERE errorCode > 500 D) SELECT @message FROM cloudwatch_logs WHERE @timestamp > -24h

正解: B 解説: CloudWatch Logs InsightsはAWS独自のクエリ構文を使用。fieldsで表示フィールド指定、filterで条件絞り込み、sortでソート、limitで件数制限。stats count(*) by status_code で集計も可能。@timestampや@messageは自動追加フィールド。

問題10 EC2 Auto ScalingのTarget Tracking Policyで最も推奨されるメトリクスは？

A) ASGAverageCPUUtilization（CPU使用率70%目標） B) ALBRequestCountPerTarget（リクエスト数） C) カスタムCloudWatchメトリクス D) A、B、またはCはユースケースによって異なる（正解）

正解: D 解説: Target Tracking Policyのメトリクス選択はアプリの特性次第。CPU-boundアプリ: CPUUtilization。Web/APIサーバー: ALBRequestCountPerTarget（最も一般的で推奨）。カスタムメトリクス: SQSキュー深度（ワーカープロセス向け）。正しいメトリクス選択がスムーズなスケーリングの鍵。

問題11 AWS Systems Manager Session ManagerがSSHより優れている点は？

A) Session Managerは高速接続を提供する B) SSHキー管理不要、ポート22不要、セッションログをCloudWatchとS3に記録可能 C) Session ManagerはWindowsのみサポートする D) SSHより多くのプロトコルをサポートする

正解: B 解説: Session Managerの利点: ①SSHキーペア不要（IAMで認証）②インバウンドポート（22番等）不要→ セキュリティグループのルールが削減③全セッションをS3/CloudWatch Logsに記録可能→ 監査証跡④VPNやBastion Host不要⑤AWS PrivateLinkでプライベート通信も可能。

問題12 CloudFormation カスタムリソースのLambda関数が実行中にタイムアウトした場合はどうなりますか？

A) CloudFormationスタックが自動的にロールバックする B) CloudFormationは無期限に待機する C) Lambda側でCFNレスポンスURLにSUCCESSまたはFAILEDを返さない場合、CloudFormationは1時間後にタイムアウトしスタックがロールバックされる D) カスタムリソースはスキップされてデプロイが継続される

正解: C 解説: カスタムリソースはLambda関数がResponseURL（Pre-signed S3 URL）にSUCCESS/FAILEDを送信するまでCloudFormationが待機。Lambda最大タイムアウト15分だが、CloudFormationは最大1時間待機。Lambda関数でresponseURLへのHTTP PUT処理は必須。try/exceptでエラー時もFAILEDを返すこと。

問題13 AWS OpsWorks（Stacks）は現在どのような状況ですか？

A) 積極的に開発が続いている主力サービス B) AWS Systems Managerに移行が推奨され、新規機能開発は停止されている C) CloudFormationの代替として推奨されている D) Kubernetes専用サービスに転換されている

正解: B 解説: OpsWorks Stacksは2024年5月26日にサポート終了（EOL）。OpsWorks for Chef AutomateとOpsWorks for Puppet Enterpriseも2024年3月26日にEOL。AWS推奨移行先: AWS Systems Manager（パッチ、設定管理）、AWS CodeDeploy（デプロイ）、AWS CloudFormation（インフラコード化）。試験では「非推奨」として理解。

問題14 EC2インスタンスのEBSボリュームをgp2からgp3に変更する際のダウンタイムは？

A) インスタンスの再起動が必要（5-10分のダウンタイム） B) ボリュームのデタッチが必要 C) ダウンタイムなし（EBS Elastic Volumes機能でオンライン変更可能） D) データ移行が必要でダウンタイムは数時間

正解: C 解説: EBS Elastic Volumes機能により、インスタンス稼働中にボリュームタイプ（gp2→gp3）、サイズ（増加のみ）、IOPSを変更可能。ダウンタイトなしでオンライン変更。変更後の最適化処理は数時間かかる場合があるが、その間もボリュームは使用可能。gp3はgp2より20%安価でIOPS独立設定可能。

問題15 CloudWatch ContributorInsightsの主な用途は？

A) CloudWatchダッシュボードの共有 B) ログデータの上位貢献者（高頻度キー）をリアルタイムで分析（例: トップIPアドレス、遅延クエリ） C) クロスアカウントでのメトリクス集計 D) CloudFormationスタックの変更追跡

正解: B 解説: Contributor Insightsはログデータから上位貢献者をリアルタイム分析。ユースケース: ①DDoS攻撃の検出（上位IPアドレス）②遅いAPIのidentify（上位レイテンシエンドポイント）③コスト分析（上位課金リソース）。VPCフローログ、CloudFrontアクセスログ等と統合して使用。

問題16 AWS Systems Manager AutomationでEC2インスタンスのAMI更新を自動化する最適なアプローチは？

A) Lambda + EventBridgeでAMI作成スクリプトを定期実行 B) SSM Automation RunbookにAWS-UpdateLinuxAmi等のドキュメントを使用し、EventBridgeでスケジュール実行 C) CodePipeline + CodeBuildでAMIビルドパイプラインを構築 D) AWS Image Builderを使用する（正解はDが最適）

正解: D 解説: EC2 Image BuilderはAMI/コンテナイメージの自動ビルド専用サービス。パイプライン定義でベースイメージ・コンポーネント（パッチ・ソフトウェア）・テスト・配布を設定。スケジュール実行、新しいベースAMI自動検出も可能。SSM Automationより高機能でAMIビルド専用設計。

問題17 CloudWatch Anomaly Detection を使用したアラームの利点は？

A) 機械学習で過去のメトリクスパターン学習し動的な閾値でアラームを設定、季節性や曜日変動を考慮 B) 手動で設定した固定閾値より常に精度が高い C) アノマリー検出は追加コストなし D) リアルタイムで閾値を変更できる

正解: A 解説: CloudWatch Anomaly Detectionは機械学習モデルで過去データのパターン（日次・週次変動、季節性）を学習し、動的な「期待値バンド」を生成。このバンドを超えた場合にアラーム発火。固定閾値と異なり、平日/週末のトラフィック差異等に自動適応。モデルトレーニング期間（約2週間）が必要。

問題18 AWS Systems Manager Parameter Storeのセキュアパラメータ（SecureString）とAWS Secrets Managerの主な違いは？

A) 機能的な違いはなく、どちらを使ってもよい B) Parameter Store SecureStringはKMSで暗号化のみ、Secrets Managerは自動ローテーション・クロスアカウント共有・リソースポリシーをサポート C) Secrets Managerはデータベースパスワードのみ対応 D) Parameter Storeの方がコストが高い

正解: B 解説: 使い分け指針: Parameter Store SecureString: アプリ設定、環境変数、APIキー保存。無料枠あり（スタンダード）。Secrets Manager: データベース認証情報、APIキー、自動ローテーションが必要なシークレット。自動ローテーション（Lambda実行）、クロスリージョン複製、リソースポリシー（クロスアカウント共有）対応。コストはSecretsの方が高い。

問題19 Elastic Load Balancer（ALB）のアクセスログをAthenaで分析する場合の最適なセットアップは？

A) CloudWatchのLog Insights を使用する B) ALBアクセスログをS3に保存し、Glue CrawlerでスキーマをData Catalogに登録後、Athenaでクエリ C) Kinesisでリアルタイム分析する D) EMRクラスターに直接転送する

正解: B 解説: ALBアクセスログは自動的にS3に保存可能（バケットポリシーでElastic Load BalancingサービスへのPutObject許可必要）。Glue CrawlerでパーティションをData Catalogに登録しAthenaから標準SQLでクエリ。AWSが提供するALBアクセスログ用のAthenaテーブル作成SQLが公式ドキュメントにある。

問題20 CloudWatchのログの保持期間のデフォルト設定は？

A) 7日間 B) 30日間 C) 無期限（Never Expire） D) 90日間

正解: C 解説: CloudWatch Logsのデフォルト保持期間は「無期限（Never Expire）」。コスト最適化のため、ユースケースに応じて保持期間を設定する必要がある（1日〜10年 or 無期限から選択）。Lambda関数のログ（/aws/lambda/）も同様にデフォルト無期限。本番環境では適切な保持期間設定がコスト管理の重要ポイント。

CloudOps 試験 最終チェックリスト

ドメイン1: モニタリング・レポート (22%)

• [ ] CloudWatch メトリクス（名前空間、ディメンション、統計、周期）
• [ ] カスタムメトリクス（PutMetricData API）
• [ ] CloudWatch Logs（ロググループ、ログストリーム、メトリクスフィルター）
• [ ] Logs Insights クエリ構文（fields, filter, stats, sort, limit）
• [ ] CloudWatch Alarms（複合アラーム、アノマリー検出）
• [ ] CloudWatch Dashboards（クロスアカウント、クロスリージョン）
• [ ] Container Insights、Lambda Insights
• [ ] Contributor Insights

ドメイン2: 高可用性 (8%)

• [ ] ELB（ALB/NLB/GLB の違い）
• [ ] Auto Scaling（Target Tracking、Step Scaling、Scheduled）
• [ ] Route 53 フェイルオーバー、ヘルスチェック
• [ ] Multi-AZ vs Multi-Region の違い

ドメイン3: デプロイ・プロビジョニング・自動化 (20%)

• [ ] CloudFormation（テンプレート構造、ChangeSet、StackSets）
• [ ] CloudFormation カスタムリソース（Lambda、CFN Response）
• [ ] Elastic Beanstalk（デプロイポリシー）
• [ ] AWS OpsWorks（廃止予定、非推奨）
• [ ] EC2 Image Builder（AMIビルドパイプライン）

ドメイン4: セキュリティ・コンプライアンス (16%)

• [ ] IAM（ポリシー、ロール、境界権限）
• [ ] AWS Config（マネージドルール、カスタムルール、Conformance Pack）
• [ ] Security Hub（findings集約、自動修復）
• [ ] GuardDuty（脅威検出、自動応答）
• [ ] AWS Trusted Advisor（チェックカテゴリー）
• [ ] AWS Macie（S3 PII検出）

ドメイン5: ネットワーク・コンテンツ配信 (14%)

• [ ] VPC（サブネット、ルートテーブル、NAT Gateway）
• [ ] セキュリティグループ vs NACL
• [ ] CloudFront（キャッシュポリシー、OAC）
• [ ] Route 53（ルーティングポリシー7種）
• [ ] VPC Endpoints（Interface vs Gateway）

ドメイン6: コスト・パフォーマンス最適化 (20%)

• [ ] Cost Explorer（コスト分析、異常検出）
• [ ] AWS Budgets（コスト、使用量、Savings Plans予算）
• [ ] Savings Plans vs Reserved Instances
• [ ] Trusted Advisor コスト最適化
• [ ] リソースタグ戦略、タグポリシー

試験のポイント

1. SSM の全サービス（Session Manager、Patch Manager、Parameter Store、Automation、Run Command）
2. CloudFormation の変更管理（ChangeSet必須、スタック保護）
3. Auto Scaling のクールダウン期間（300秒デフォルト）
4. CloudWatch Logs保持期間デフォルト = 無期限
5. Trusted Advisor の有料プランでのみ利用可能なチェックを把握