SAP-C02-069 · 理解確認
Patch ManagementとCompliance
12問 · 1問ずつ確認
AWS Organizations配下に30アカウントがあり、複数リージョンでEC2を運用している。対象リージョンはパッチポリシー対応で、重大なセキュリティパッチの適用基準と毎日の状態確認を中央管理したい。最も適切な基本設計はどれか。
B. 各EC2のOS更新機能を共通設定にし、Systems Manager コンプライアンスで適用結果だけを中央集約する
C. AWS Security Hubの検出結果を起点に各アカウントで実行 コマンドを実行し、適用履歴を中央集約する
D. Quick Setupのパッチポリシーで対象OU / リージョン、OS別パッチベースライン、スキャン / インストールのスケジュールを中央管理する
答えと解説
答え:D
対応リージョンで組織規模の中央管理を新規設計するなら、Quick Setupのパッチポリシーを優先的に評価します。
RHELのパッチベースラインで重大なパッチをリリース7日後に承認する方針がある。既知の障害がある特定パッケージは依存関係としてもPatch Managerから適用させたくない。最も適切な設計はどれか。
B. 自動承認を7日にし、問題パッケージを拒否へ追加したうえで拒否済みパッチのアクションをBLOCKにする
C. 自動承認を無効化し、すべてのパッチを手動承認へ変更して依存関係の判定はOSに任せる
D. インストールスケジュールを7日後に設定し、パッチベースラインでは問題パッケージを承認済みのまま維持する
答えと解説
答え:B
承認対象から外すだけでなく依存関係としてもPatch Managerから入れたくないLinuxパッケージでは、拒否に加えてBLOCKを使います。
本番環境では未適用パッチの状態を毎日把握したいが、実際のパッチ適用による変更は日曜日の許可時間帯だけに限定する必要がある。Systems Managerを利用する最も適切な運用はどれか。
B. 日曜日だけスキャンしてインストールし、その結果を翌週まで最新のコンプライアンスとして扱う
C. 毎日Patch Managerでスキャンし、日曜日のMaintenance Windowでインストールする
D. 毎日コンプライアンスデータだけを集約し、パッチスキャンを行わず月末に一度だけインストールする
答えと解説
答え:C
状態把握と変更実施の頻度を分離します。毎日のスキャンでコンプライアンスを把握し、実際のインストールは許可された日曜日のMaintenance Windowへ配置することで、可視性と変更統制を両立できます。
単一のAWSアカウント・リージョンで、毎月第2日曜日の保守時間にパッチ適用と後続の運用タスクを順番に実行したい。組織全体への中央展開は不要である。最も適切な候補はどれか。
B. Quick Setupのパッチポリシーを組織全体へ展開し、対象外アカウントを個別除外する
C. Patch nowを月次スケジュールの唯一の実行基盤とし、後続タスクは別日に手動で実行する
D. メンテナンスウィンドウを使用し、保守時間内にAWS-RunPatchBaselineと必要な後続タスクを実行する
答えと解説
答え:D
単一アカウント / リージョンで明確な保守時間と複数タスクを扱う要件ではメンテナンスウィンドウが候補になります。
昨日のスキャンでは全ノードが準拠だったが、今日新しいセキュリティパッチが公開された。現在の準拠状態について最も適切な判断はどれか。
B. 一度準拠になったノードは、パッチベースラインが同じなら新しいパッチ公開後も自動的に準拠を維持する
C. 新しいパッチが公開されるとPatch Managerが自動的に各ノードへインストールするためスキャンは不要である
D. コンプライアンスはパッチ状態ではなくノードの稼働状態を示すため、新しいパッチの公開とは無関係である
答えと解説
答え:A
コンプライアンスは評価時点の情報です。現在状態を知るには要求される頻度で再評価します。
新規のパッチポリシー設計で、既存資料を根拠に「まず全EC2へパッチグループタグを付ける必要がある」と提案された。最も適切な評価はどれか。
B. パッチポリシーではパッチグループを前提にせず、対象範囲・OS別ベースライン・スケジュールをポリシーで設計する
C. パッチグループはAWS OrganizationsのOUを自動作成する仕組みなので、複数アカウントでは必須である
D. パッチグループはコンプライアンスデータの保存先を決めるため、スキャンのみのポリシーでも必須である
答えと解説
答え:B
パッチグループは従来方式で使われますが、Quick Setupのパッチポリシーでは前提にしません。
開発では先にパッチを適用し、3日間の確認後に本番へ適用する標準がある。Ubuntu Serverを含むため「リリース後3日の自動承認」を全OS共通で使う案が出た。最も適切な設計はどれか。
B. 本番だけ自動承認を3日にし、開発はすべてのパッチを即時に手動インストールする
C. OSごとの自動承認対応を確認し、利用できないOSでは開発と本番の適用スケジュールを分けて検証期間を実現する
D. Ubuntu Serverではパッチベースラインを利用できないため、Patch Manager対象から完全に除外する
答えと解説
答え:C
組織標準の検証期間は同じでも、OSが承認待機日数に対応しない場合は段階スケジュールなど別の手段で実現します。
セキュリティチームは現在の未適用パッチ一覧を確認したいが、変更凍結期間中のためインストールは禁止されている。最も適切な操作はどれか。
B. インストールを実行し、変更が拒否されたパッチを失敗として収集して未適用一覧の代わりにする
C. パッチベースラインを一時的に空へ変更してコンプライアンス画面を更新し、終了後に元へ戻す
D. メンテナンスウィンドウを削除し、各OSのパッケージ管理コマンドだけで中央コンプライアンスを更新する
答えと解説
答え:A
スキャンならパッチをインストールせず、パッチベースラインに対する不足状態を評価できます。
AWS Organizations全体へ1つのパッチポリシーを展開した。運用担当者が「ポリシーが1つなのでパッチコンプライアンスも組織全体で1つの状態として管理される」と説明している。最も適切な評価はどれか。
B. 誤り。ポリシーは中央展開できるが、パッチコンプライアンスデータはアカウント・リージョンなどの単位で追跡する
C. 正しい。メンバーアカウントではパッチコンプライアンスを参照できないため、組織全体の1件だけが正式な状態になる
D. 誤り。Quick Setupのパッチポリシーではコンプライアンスデータそのものを生成できず、別サービスだけで確認する
答えと解説
答え:B
中央設定の単位と各ノードのパッチコンプライアンスデータの報告単位は同じではありません。
パッチコンプライアンスとパッチ操作について適切な説明を4つ選択してください。
B. スキャンではパッチベースラインに照らして不足している承認済みパッチを不足として把握できる
C. インストールでは承認済みの不足パッチを適用し、失敗したパッチが失敗として報告される場合がある
D. 複数のスキャン方式を使うと、後に実行されたスキャンによって以前のパッチコンプライアンスデータが更新され得る
E. 現在の不足状態を適用後に確認したい場合、必要に応じて再スキャンする設計を取れる
F. インストールのコンプライアンスデータでは、適用前に存在した不足状態のパッチが必ずそのまま不足一覧として残る
答えと解説
答え:B / C / D / E
スキャンは不足把握、インストールは適用と実行結果、再スキャンは適用後の現在状態確認という役割で分けます。
Quick Setupのパッチポリシーを使って、新たに複数リージョンへ同じパッチ標準を展開したい。対象の1リージョンがパッチポリシーの対応リージョンか不明である。最も適切な判断はどれか。
B. 非対応リージョンでもパッチグループを追加すればパッチポリシーの機能を有効化できるため、タグを先に配布する
C. 対象リージョンのパッチポリシー対応状況を確認し、非対応ならそのリージョンで利用可能な別のPatch Manager実行方式を設計する
D. メンテナンスウィンドウはパッチポリシー対応リージョンでしか利用できないため、非対応ならPatch Manager自体を利用しない
答えと解説
答え:C
中央管理方式を採用する前に、対象リージョンでその方式がサポートされているか確認します。
LinuxのパッチベースラインでPackageXを拒否し、拒否済みパッチのアクションは既定のALLOW_AS_DEPENDENCYのままである。PackageXが承認済みPackageYの依存関係として必要になった。現在の設定について最も適切な理解はどれか。
B. 依存関係として必要なら、拒否済みのPackageXでもインストールされ得る
C. PackageYの承認状態に関係なく、PackageXは通常パッチとして自動承認される
D. 拒否済みパッチはスキャン対象から除外され、依存関係としても評価されない
答えと解説
答え:B
ALLOW_AS_DEPENDENCYでは、拒否済みパッチでも承認済みパッチの依存関係として必要な場合にインストールされることがあります。拒否済みパッチを依存関係としても適用させない要件ならBLOCKを検討します。