AWS SOA サンプル問題

正解：B

A　詳細モニタリングは既定メトリクスの取得間隔を5分から1分へ短縮するだけで、メモリやディスク空き容量は取得できない

B（正解）　正解。ハイパーバイザーから見えないOS内部の値は、インスタンス上のエージェントが収集してカスタムメトリクスとして発行する必要がある

C　メトリクス数式は既存メトリクスの演算しかできず、そもそもCPU使用率からメモリ使用量は導出できない

D　フローログはネットワークトラフィックのメタデータのみを記録し、OS内部のリソース使用状況とは無関係

正解：B

A　同じトピックにまとめても各アラームは独立して発報するため、片方だけの呼び出しは止まらない

B（正解）　正解。複合アラーム(Composite Alarm)は子アラームの状態をANDやORで組み合わせて評価でき、子側の通知を外せば呼び出しノイズを大きく削減できる

C　発報が遅れるだけで片方だけの通知はなくならず、本当の障害の検知も遅くなる

D　単位の異なるメトリクスの加算に意味はなく、どちらか一方が大きいだけでもしきい値を超えてしまう

正解：C

A　データ不足はデータポイントが存在しないことが原因で、しきい値をいくら変えても状態は変わらない

B　誤検知は消えるが手作業が増え、運用効率を重視する要件に反する。CloudWatchの標準機能で解決できる

C（正解）　正解。欠落データの扱いは missing/notBreaching/breaching/ignore から選べ、notBreachingならデータがない期間はOK状態として扱われる

D　取得間隔を短くしても停止中はメトリクス自体が発行されないため、データ不足は解消しない

正解：A

A（正解）　正解。復旧アクションはインスタンスIDやプライベートIP、EBSボリュームを保持したまま別のハードウェアへ移して再起動するため、手動対応なしで復旧できる

B　インスタンスステータスチェックはOSやネットワーク設定などインスタンス側の問題を示すもので、今回のハードウェア障害の検知には対応しない

C　終了させても代替は起動せず、EBSの設定によってはデータも失われる。復旧策になっていない

D　障害と無関係に毎時再起動する構成は正常稼働時のサービス断を招き、ハードウェア障害からの復旧も保証しない

正解：B・E

A　保持期間は古いログを削除する条件にすぎず、新しいログの受信を妨げることはない

B（正解）　正解。エージェントはインスタンスプロファイルの認証情報でPutLogEventsなどを呼び出すため、権限が欠けていると送信が失敗し続ける

C　CloudWatch Agentは必要なログストリームを自動で作成するため、事前作成は不要

D　Insightsは蓄積済みのログを検索するための機能で、ログの取り込みとは無関係

E（正解）　正解。プライベートサブネットではNAT Gatewayかインターフェース型VPCエンドポイントのいずれかがないと、エージェントはサービスのエンドポイントに接続できない

正解：A・D・F

A（正解）　正解。アラーム自体は状態遷移するが、アクションが無効の間はSNSへの発行が行われないため通知だけが届かなくなる

B　CloudWatchのメトリクスは15か月で自動的に期限切れになるが、直近のデータ点の評価と通知には影響しない

C　メトリクスアラーム単独でもアクションは実行できる。複合アラームは複数のアラームの状態を組み合わせて評価するための任意の仕組みで、通知の前提条件ではない

D（正解）　正解。メールのサブスクリプションは受信者が確認リンクを開くまでPendingConfirmationのままで、その間はメッセージが配信されない

E　暗号化の有無は配信の成否とは無関係で、未設定でも通知は送信される

F（正解）　正解。アラームアクションは状態が変化した瞬間にのみ実行される。すでにALARM状態が継続している間は追加の通知が発生しない

正解：B

A　Multi-AZのスタンバイには接続用のエンドポイントが公開されず、そもそも追記できない

B（正解）　正解。エンドポイント名は変わらずDNSが指す先だけが切り替わるため、アプリケーションはDNSキャッシュのTTLが切れた後に再接続するだけでよい

C　物理的に別インスタンスへ切り替わるためIPは変わり、既存の接続は切断される。再接続の実装は必要

D　Multi-AZのスタンバイとリードレプリカは別の機能で、フェイルオーバーでレプリカのエンドポイントが使われることはない

正解：C

A　Multi-AZ配置(インスタンス)のスタンバイは可用性のための待機系で接続用エンドポイントも公開されず、読み取りに使うことはできない。よくあるひっかけ(読み取り可能なスタンバイを持つのはMulti-AZ DBクラスター配置)

B　一時的な緩和にはなるがコストが上がり続け、参照負荷と更新負荷を分離するという本質的な解決にならない

C（正解）　正解。リードレプリカは非同期レプリケーションでわずかな遅延を許容する代わりに参照負荷を分離でき、本番の更新性能への影響を避けられる

D　接続管理の効率化とフェイルオーバー時間の短縮には有効だが、クエリ負荷そのものは同じインスタンスにかかり続ける

正解：D

A　実現はできるがサービスごとにコードを書いて維持する必要があり、一元管理という要件から遠い

B　DLMが対象とするのはEBSスナップショットとEBS-backed AMIで、RDSやEFSは扱えない

C　S3オブジェクトの複製機能であり、EBSやRDS、EFSのバックアップ対象にはならない

D（正解）　正解。AWS Backupは対応サービスのバックアップをプランで一元管理し、ルール内でクロスリージョンコピーとライフサイクルをまとめて定義できる

正解：A

A（正解）　正解。コンプライアンスモードのボールトロックは猶予期間の経過後は変更・解除ができなくなり、rootを含む誰も保持期間内のリカバリポイントを削除できない

B　リソースポリシーはアカウントの管理者が編集できるため、権限を持つ利用者による削除を根本的には防げない

C　分離の効果はあるが、コピー先アカウントの管理者は削除できるため要件を完全には満たさない

D　自動削除の時期を先送りするだけで、手動での削除操作は防げない

正解：C

A　実現はできるがコードの保守、エラー処理、対象抽出のロジックをすべて自前で持つ必要がある

B　インスタンスが停止していると取得されず、権限配布と全台のスクリプト保守も負担になる

C（正解）　正解。DLMはタグで対象を選び、取得スケジュールと保持ルールをマネージドに実行するため、コードを書かずに取得と世代管理を自動化できる

D　古いスナップショットの検出はできるが、日次で新規に取得する仕組みが含まれていない

正解：B

A　30回の手作業が必要なうえ、新規アカウントへの適用漏れが必ず発生する

B（正解）　正解。Organizations連携のStackSetsは対象OUに新しいアカウントが追加されたときに自動でスタックインスタンスを展開し、削除時には取り除く

C　実行のタイミングと結果が管理者任せになり、統制も進捗の把握もできない

D　SCPは許可の上限を定める予防的統制で、リソースを作成して設定を行うことはできない

正解：C

A　差異の有無は分かりづらく、意図しない上書きが本番に適用されるリスクがある

B架空　ドリフトを検出したら自動的にテンプレートの状態へ戻すという機能は存在しない。検出と是正は別の操作

C（正解）　正解。ドリフト検出はスタック内のリソースの実際の設定とテンプレート定義を比較し、差異のあるプロパティを一覧で示す

D　誰が何を変更したかは追えるが、現在の設定がテンプレートとどれだけ乖離しているかは直接分からない

正解：A

A（正解）　正解。変更セットは更新を適用せずに追加・変更・削除の一覧と置換の要否(Replacement)を提示するため、影響を事前に把握できる

B　誤った更新の防止には有効だが、何が起きるかを事前に確認する手段ではない

C　現在の設定とテンプレートの差異を見る機能で、これから行う更新の影響は分からない

D　構文やベストプラクティスの検査はできるが、既存スタックへ適用したときの変更内容は分からない

正解：D

A　本番リソースが失われる可能性があり、最終手段としても影響が大きすぎる

B　この状態のスタックは更新操作を受け付けないため、変更セットの実行もできない

C　差異の把握はできるが、スタックの状態遷移そのものを前へ進める手段ではない

D（正解）　正解。ロールバックを妨げているリソースの問題を手動で解消したうえで継続を指示し、必要ならそのリソースをスキップ指定してUPDATE_ROLLBACK_COMPLETEへ進める

正解：B

A　誤削除の抑止にはなるが、スタック削除がその時点で失敗して中途半端な状態になる。テンプレート側での意思表示にはならない

B（正解）　正解。DeletionPolicyをSnapshotにするとスタック削除時に最終スナップショットが作成され、データを保持したままリソースを削除できる

C　スタックポリシーは更新時の保護であり、スタック削除時の挙動には影響しない

D　分離しても、そのスタックを削除すればやはりデータは失われる。根本的な保護になっていない

正解：C

A　IAMのポリシー評価に付与順という概念はなく、時系列で優先度が決まることはない

B　許可が拒否に優先することはない。AdministratorAccessであっても明示的な拒否は上書きできない

C（正解）　正解。IAMの評価論理では明示的Denyが最優先で、他のどのポリシーによる許可よりも強い。原因となる拒否を特定して外すしかない

D　グループのポリシーは所属ユーザーに適用される。継承されないという前提が誤り

正解：A

A（正解）　正解。SCPはメンバーアカウント内で行使できる権限の上限を定めるガードレールで、IAMで許可されていてもSCPで許可されていない操作は実行できない

B　パスワードの複雑さや有効期限に関する設定で、API操作の可否とは無関係

C　クォータ超過の場合はAccessDeniedではなく上限超過のエラーになる

D　証跡は記録の設定であり、操作の許可・拒否には影響しない

正解：B

A　ロールの作成自体ができなくなり、委譲するという要件を満たさない

B（正解）　正解。IAMポリシーの条件で、指定した境界ポリシーを付けたロールしか作れないようにでき、そのロールの実効権限は境界との重なりに制限される

C　作成時点で過剰な権限のロールが生まれてしまい、事後レビューでは防止にならない

D　検出と是正は可能だが、その間は過剰な権限が有効なままで予防的な統制にならない

正解：D

A　長期認証情報を外部に渡すことになり、失効や監査が難しい

B　S3以外のリソースを読めず、また代理問題への対策も含まれていない

C　外部組織を自社の組織に取り込むのは統制上不適切で、必要な権限委譲の手段としても過剰

D（正解）　正解。ExternalIdを条件にすると、ベンダーが自社専用の値を提示したときだけAssumeRoleが成立し、他の顧客の依頼で誤って自社リソースへアクセスされることを防げる

正解：C

A　通信が遮断されている場合はタイムアウトや接続エラーになり、AccessDeniedにはならない

B　オブジェクトの世代管理に関する設定で、アクセス可否の判定には関与しない

C（正解）　正解。S3ではIDベースのポリシーとリソースベースのポリシーの両方が評価され、バケットポリシーに明示的な拒否があれば失敗する。KMS暗号化時はキーポリシーも確認する

D　配置されるAZはS3の権限評価に影響しない

正解：B

A　自動割り当てのパブリックIPでも通信は可能で、固定IPが必須というわけではない

B（正解）　正解。パブリックサブネットの条件はIGWへのデフォルトルートが関連付けられていることで、これがなければパブリックIPがあっても到達できない

C　AZの選択はインターネットからの到達性に影響しない

D　インスタンスタイプは帯域や性能に関わるもので、疎通の可否を決めるものではない

正解：C

A　サブネットのルートがIGWを向いていなければ通信できず、仮に向ければインターネットからの受信も可能になってしまう

B　そのサブネットがパブリックサブネットになり、インターネットからの接続を許してしまう

C（正解）　正解。NAT Gatewayは内部から開始した通信のみを外部へ中継し、外部から内部への接続開始は許可しない

D　S3とDynamoDBへのプライベート経路を提供するだけで、一般的なインターネット上のリポジトリへは到達できない

正解：A

A（正解）　正解。SGは許可した通信の戻りを自動的に許可するが、NACLは方向ごとに独立して評価するためエフェメラルポートの戻りルールが必要になる

B　適用範囲の違いはあるが(NACLはサブネット単位)、戻り通信の扱いの差を説明する理由にはならない

C　実際は逆で、SGは許可のみ、NACLは許可と拒否の両方を定義できる

D　評価順の話であって、戻り通信を自動的に許可するかどうかの違いとは無関係

正解：D

A　NACLに拒否優先の原則はなく、ルール番号の小さい順に評価して最初に一致したものが適用される

B　一致した時点で評価が終わるため、後続のルールは参照されない

C　評価順は番号の昇順で、大きい番号が優先されるという理解は逆

D（正解）　正解。NACLはルール番号の小さい順に評価し、最初に一致したルールを適用して以降は評価しない

正解：C

A　フィルタでALL、ACCEPT、REJECTを選べるため、設定次第で拒否も記録される

B　集約間隔は1分または10分から選択でき、1時間固定という理解は誤り

C（正解）　正解。169.254.169.254へのメタデータアクセスやAmazon提供DNSへの問い合わせ、DHCPトラフィックなどは仕様上フローログに記録されない

D　VPC、サブネット、ENIのいずれの単位でも有効化でき、ENI単位の記録も可能

正解：B

A　表記の統一は望ましいが、コストの内訳としてタグを使えない直接の原因ではない

B（正解）　正解。タグは有効化して初めてコスト配分に使われるようになり、有効化以降の請求データから分析軸として選べるようになる

C　個別のリソース単位では見られるが、タグ単位で集計するという要件を満たさない

D　予算の追跡もタグの有効化が前提になり、まず有効化を行う必要がある

正解：C

A　費用の内訳や推移の分析が中心で、購入プランの推奨はあってもインスタンスの右サイジング分析が主目的ではない

B　予算の設定と超過時の通知を行うサービスで、リソース構成の推奨は行わない

C（正解）　正解。CloudWatchメトリクスから使用状況を分析し、EC2やAuto Scalingグループ、EBS、Lambdaについて過剰・不足の判定と推奨タイプを提示する

D　低使用率インスタンスの指摘はあるが、推奨タイプまで踏み込んだ分析はCompute Optimizerが担う

正解：D

A　参照されない期間も最も高い保存料金がかかり、コスト効率が悪い

B　最初の30日間の頻繁な参照に対して取り出しに時間と費用がかかり、要件に合わない

C　単一AZ保存となり監査ログの耐久性要件に不安が残るうえ、1年後のさらなる低コスト化も行われない

D（正解）　正解。30日後にStandard-IA、1年後にGlacier Flexible Retrievalへ移行するルールを組めば、アクセス頻度の変化に合わせて保存料金を自動的に下げられる

正解：A

A（正解）　正解。アクセス状況を監視して自動的に階層を移動し、高頻度・低頻度いずれの階層でも取り出し料金がかからないため、予測できないパターンに適する

B　保存料金は安いが取り出しに料金がかかり、頻繁に参照されるオブジェクトが混在すると割高になる

C　取り出し料金がかかるうえ単一AZ保存となり、可用性の観点でも一般的な用途には向かない

D　取り出しは高速だが料金が発生し、四半期に1回程度のアクセスを想定した価格設計のため混在パターンには合わない