16問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース(無料)に登録してください。
まず、次の操作を完了する必要があります:
正解数 0/問題数16
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SAA-14】ある企業は、開発部門や運用部門からの要望に応えて、AWS アカウント内で多数のAmazon EC2 インスタンスを立ち上げ、新しいワークロードを次々と稼働させ始めました。これまではオンプレミス環境でジャンプサーバー経由のSSH接続や共有管理用キーペアでサーバーにログインしていましたが、鍵の配布・回収や踏み台サーバーの運用負荷が問題になっていました。同社は、AWSネイティブの仕組みと連携しながら、クラウド設計のベストプラクティスに沿った形で、繰り返し利用できる安全なリモート運用プロセスを構築したいと考えています。
運用上のオーバーヘッドを最小限に抑えつつ、EC2 インスタンスへの安全なリモートアクセスを実現するソリューションとして、最も適切なものはどれですか。
踏み台やSSH鍵に依存せず、AWSの管理プレーンからインスタンスへシェルを開ける仕組みがないかを思い出す。Systems Manager の機能の中から探してみる。
【SAA-38】ある企業は、複数のAWS アカウントとVPC にまたがる多層アプリケーションをAWS 上で運用しています。社内のコンプライアンスおよびセキュリティポリシーでは、「どのAWS リソースにいつどのような構成変更が行われたか」と「どのユーザーやロールがどのAPI を実行したか」の両方を、監査証跡として継続的に記録・追跡しておくことが求められています。ソリューションアーキテクトは、この要件を満たすための標準的な仕組みを設計する必要があります。
これらの要件を満たすために、ソリューションアーキテクトが取るべき構成はどれですか。
Config は「構成の変化(リソースの設定がどう変わったか)」、CloudTrail は「誰が何を呼び出したか(APIコール履歴)」、CloudWatch は「リソースの状態を数値で監視(CPU使用率などのメトリクス)」を記録するサービスという役割分担を思い出してみてください。問題文のキーワードが「監査・構成変更・APIコール」なのか「パフォーマンス監視・アラーム・閾値」なのかで判別できます。
【SAA-47】ある企業は、セキュリティと運用ガバナンスの観点から、自社アカウント内でAmazon Machine Image(AMI)がいつ・誰によって作成されたかを把握し、必要に応じて担当者にアラートを送信したいと考えています。現在、この企業は同じリージョン内でのみAMI のコピー運用を行っていますが、将来的には作成イベントも監査対象としたいと考えています。ソリューションアーキテクトは、`CreateImage` API オペレーションが呼び出されたタイミングで自動的に検出し、運用チームへ通知する仕組みを、できるだけ少ない運用オーバーヘッドで実装する必要があります。
この要件を満たすソリューションとして最も適切なものはどれですか。
API コールを「その場で」検知して通知したいときに、CloudTrail の管理イベントをイベントソースとして扱えるサービスと、その通知先として適切なサービスの組み合わせをイメージしてみてください。
【SAA-65】ある医療系企業が、検査結果レポートや診療記録といった機密データをAmazon S3 バケットに保存しようとしています。コンプライアンス要件により、保管中のデータは必ず暗号化されていなければならず、監査時には「どの暗号化キーがいつ・誰によって使用されたか」を示す詳細なログを提出する必要があります。また、暗号化キー自体は年に1回自動的にローテーションされることが求められています。
運用負荷を最小限に抑えつつ、これらの要件を満たすにはどうすればよいですか。
暗号鍵の生成・保管・ローテーション・監査を自前で頑張るか、それともマネージドなキー管理サービスに任せるか、という観点で比較する。年次ローテーションとキー使用ログを自動で面倒見てくれる仕組みがないかを思い出す。
【DVA-104】ある開発者は、自社のアプリケーションを複数の AWS リージョンで稼働させるために、最新状態を反映した Amazon Machine Image(AMI)を他リージョンへ展開したいと考えています。
セキュリティポリシーでは「すべてのリージョンで使用する AMI は暗号化されていなければならない」と定められていますが、現在運用中の AMI の中には暗号化されていないものも含まれています。
暗号化要件を満たしつつ、他リージョンでアプリケーションを拡張する方法として、最も適切なものはどれでしょうか。
AMI は「メタデータ+ EBS スナップショットへの参照」で構成されており、AMI の暗号化とは紐づく EBS スナップショットがすべて暗号化されていることを意味します。EC2(サーバー)の中身は EBS ボリュームに保存されているため、AMI の暗号化には EBS の知識が不可欠です。非暗号化の AMI やスナップショットを後から「その場で」暗号化に変換する機能は存在しません。暗号化済み AMI を得るには、暗号化されたボリュームを持つインスタンスから新規に AMI を作成する必要があります。
重要:ここでの「新規に AMI を作成する」とは、中身(OS・アプリ構成)を変えるという意味ではありません。同じ構成のまま「暗号化」という属性を付与した AMI を作り直すということです。AWS には既存の非暗号化 AMI をそのまま暗号化に変換する機能がないため、このような手順が必要になります。
また、問題文のポリシーは「すべてのリージョンで暗号化された AMI を使用する」ことを求めています。宛先リージョンだけでなく元のリージョンも対象なので、元リージョンの非暗号化 AMI も削除する必要がある点に注意しましょう。
なお、AMI をリージョン間コピーすると、宛先リージョンでは新しい AMI-ID が割り当てられますが、中身(構成・暗号化状態)は同一のコピーとして利用可能です。
補足:AMI は一度作成したら永久に使い続けるものではなく、OS パッチ適用・アプリ更新・セキュリティ要件の変更などに合わせて定期的に新しい AMI を作成し直し、古い AMI は登録解除(deregister)して廃棄するのが一般的な運用です。本問でも、暗号化要件に合わせて新しい AMI を作成し、旧 AMI を削除するという更新サイクルが前提となっています。
【MLA-68】
ある運用チームは、Amazon SageMaker エンドポイントへのすべての API 呼び出しイベントを監査目的で保存するとともに、一定時間内の呼び出し回数がしきい値を超えた場合にアラート通知を受け取りたいと考えています。これらの要件を、AWS のマネージドサービスを用いて実現する適切な構成はどれでしょうか。
「監査ログを残すこと」と「メトリクスにしてアラートすること」の 2 つの要件を同時に満たせるサービスの組み合わせを意識してみてください。「監査」とは単にリクエスト数を記録することではなく、誰が・いつ・どの API を呼び出したかを追跡できることを意味します。また、メトリクス化の方法として「メトリクスフィルターによる自動化」と「Lambda 等によるカスタムメトリクスの手動送信」の違いにも注目してみてください。
【MLA-75】
ある企業では、Amazon Redshift を唯一の分析データベースとして利用しており、その中には個人情報などの機密データも含まれています。データサイエンティストは、機密列を含むテーブルに対してクエリを実行したいものの、元のテーブルを書き換えたり、匿名化済みデータを別テーブルとして永続保存することは避けたいと考えています。実装作業を最小限に抑えつつ、クエリ実行時だけ機密列の値をマスクして見せるには、どのように構成すべきでしょうか。
『元の Redshift テーブルを変えずに、クエリ結果だけをマスクしたい』という要件にピッタリ対応している機能がどれかを思い出してみてください。
【MLA-76】
あるアプリケーションでは、複数の外部テキスト埋め込み API を呼び出してベクトルを生成しており、それぞれ異なる API トークンを使用しています。セキュリティ要件として、これらのトークンを 3 か月ごとに自動でローテーションし、アプリケーション側からは常に最新のトークンだけを参照したいと求められています。最小限の実装工数で、このローテーション要件を満たす方法はどれでしょうか。
『シークレットを保存して自動ローテーションできる専用サービス』がどれかを思い出し、そのサービスと Lambda を組み合わせる構成を探してみてください。
【DEA-7】ある企業は、取引ログを Amazon S3 バケットに保存しており、このバケットに対するすべての書き込み操作を、同一リージョン内の別の S3 バケットに自動的に記録したいと考えています。これらの記録は、S3 バケットに対する PutObject などの API コールを含む監査ログとして CloudTrail 形式で保存したい。アプリケーション側の実装変更は極力避け、運用作業も最小限に抑えたいという要件があります。どのソリューションを採用すべきでしょうか。
「S3 への書き込みを別バケットに記録したい」という要件に加え、「PutObject などの API コールを含む監査ログを CloudTrail 形式で残したい」とある点に注目してください。データのコピーではなく、API レベルの監査イベントをどう記録するかを考えましょう。
【SAP-24】ある EC サイト運営会社は、顧客がブラウザやモバイルアプリから商品を検索・購入できる Web アプリケーションを Amazon EC2 上で公開している。
機能追加を高速に繰り返しながらも責任共有を明確にするため、開発環境と本番環境をそれぞれ独立した AWS アカウントに分離して運用している。
経営陣は PCI-DSS 監査コストと人的ミスによる障害リスクを最小化する目的で「自動化された構成管理ツールのみが本番アカウントへアクセスできる」というポリシーを新設した。
一方、インシデント対応の初動を加速させるため、本番アカウントまたは EC2 インスタンスへの手動アクセス(AWS マネジメントコンソールへのサインインや SSH/RDP など)が試行または成功した時点で、セキュリティチームへ即時通知が届く監視体制も必須とされている。
かかるビジネス背景を踏まえ、ソリューションアーキテクトは本番アカウント内でどのアクションを組み合わせて実装すべきか。
最適な組み合わせを3つ選択しなさい。
本番アカウントへの人手アクセスを検知したいとき、CloudTrail の AwsConsoleSignin と EC2 ログインイベントを CloudWatch+SNS で監視するパターンを押さえておく。「自動化ツールのみアクセス可」というポリシーが出たら、キーペアなし起動で SSH/RDP を封じ、メンテナンスは SSM Session Manager や SSM Run Command で行う設計を想起しよう。
【SAP-32】ある小売 EC 企業では、24 時間稼働の受注処理システムをオンプレミスの Windows サーバー群上で運用し、顧客にはリアルタイム在庫表示と注文 API を提供している。
今後の販促強化に合わせ、リフト&シフトで us-east-1 の Amazon EC2 へ環境を移行する計画だ。
セキュリティ部門はエージェント型ツールの導入を認めているが、移行データは転送中・保存時の双方で必ず暗号化することが必須となっている。
さらに取締役会は販売停止リスクを嫌い、カットオーバーを数分程度に抑えるよう厳命している。
運用チームは移行前後を通じて Amazon CloudWatch と AWS CloudTrail でメトリクスと監査ログを一元管理し、追加の保守作業を増やさない方針だ。
ソリューションアーキテクトは、これらのビジネス上の要請と技術的制約を同時に満たす移行方式をインフラレベルで選定する必要がある。
採用すべき最も適切なサービスはどれか?
Windows サーバーのリフト&シフトで『暗号化された継続レプリケーション+短いカットオーバー』を実現したい場合は、MGN(Application Migration Service)を第一候補とする。カットオーバーとは旧環境から新環境へ本番を切り替える作業のことで、その間のダウンタイムを最小化することが移行計画の重要ポイントとなる。
【SAP-94】グローバルに EC プラットフォームを展開するある会社では、ユーザーが商品画像や取引レポートを閲覧・ダウンロードできる仕組みを Amazon S3 上に構築している。
新たな内部統制の強化により、S3 からのすべてのオブジェクト取得・書き込みを監査証跡として残し、インシデント時に即時追跡できるようにすることが必須となった。
監査ログは改ざん防止の観点から、集中ロギング専用 AWS アカウントの監査用 S3 バケットに集約し、同バケットにはクロスアカウントで書き込みのみ許可するポリシーが設定済みである。
運用部門は少人数のため、現在のバケットだけでなく将来作成されるすべてのバケットに対しても追加設定なしでオブジェクトレベルのアクセスログが自動収集されるスケーラブルな仕組みが求められる。
ソリューションアーキテクトは、コンプライアンス要件を満たしつつ運用負荷を最小化するインフラ設計として、どのアプローチを採用すべきか?
『S3 のオブジェクトレベル監査を全バケットに自動適用したい』なら、Organizations トレイル+CloudTrail データイベントを第一候補とする。CloudTrail の管理イベント(バケット作成・削除など)はデフォルトで記録されるが、データイベント(GetObject / PutObject などオブジェクトの読み書き)はデフォルトで無効なので、明示的な有効化が必要という点を押さえておこう。
【SAP-114】あるSaaS企業はタスク管理プラットフォームを法人顧客向けに提供しており、AWS上でマイクロサービスを本番用アカウントとテスト用アカウントに分けて運用しています。
開発者やCI/CDパイプラインが随時IAMユーザーを追加できる運用が長く続いた結果、認証情報の散在と誤用リスクが顕在化しました。
近くSOC 2監査を控えたセキュリティチームは「認証情報を一元管理し、環境間のアクセス権を厳格に分離して本番データ汚染を防止せよ」と運用チームに指示しています。
運用要員は少数のため、設定変更の自動化が可能で、かつ将来的にアカウント数が増えても運用負荷が増大しない拡張性が求められます。
ビジネス目的は監査対応と人的コスト削減、技術目的は環境間の信頼境界の明確化と認証情報ライフサイクルの集中制御です。
ソリューションアーキテクトはこれらの制約と目的を踏まえ、インフラレベルでどの構成を採用すべきか。
最も適切な選択肢はどれか?
マルチアカウントの IAM ガバナンスでは、『ID 専用アカウント+各アカウントのロールを AssumeRole』というセントラル ID パターンをまず検討する。ここで言う「ID(Identity)」とは「誰がアクセスするか」という身元情報のことで、ID 専用アカウントはユーザー管理だけを行う専用の AWS アカウントである(踏み台サーバーのようなネットワーク中継用のサーバーではない)。AssumeRole とは「自分のユーザー資格情報を使って別のロールの一時的な権限を借り受ける」仕組みで、長期認証情報を各アカウントに配置せずに済むのが最大の利点である。
【SAP-126】あるゲノム創薬ベンチャーの研究所Aは、複数の病院・大学と約2 PBのヒトゲノムデータを共同解析するプロジェクトを進めている。
当該データは研究所Aの AWS アカウントにある Amazon S3 バケットに保管され、研究者は各種分析ジョブから直接読み取っている。
今後、連携先が自前の AWS アカウントで解析パイプラインを実行できるよう、同じバケットへの読み取り権限を安全に開放したい。
一方で助成金中心の運営という事情から、研究所Aは S3 API リクエスト料やデータ転送料を自組織で負担し続けることを避ける必要がある。
データを複製せず、IAM ポリシーによる細粒度アクセス制御を維持しつつ、実際に取得した側に課金を帰属させる構成が求められている。
ソリューションアーキテクトは、この要件を満たすために S3 バケットでどの機能を有効化すべきと判断するか?
巨大な共有データセットを複数アカウントから読むときに、Requester Pays とバケットポリシーで『どこに課金するか』を制御できることを思い出す。Requester Pays の課金先は「リクエストに使われた認証情報がどのアカウントに属するか」で決まる点がカギ。研究所アカウントのロールを AssumeRole して得た一時クレデンシャルは研究所アカウントのものとして扱われるため、取得側に課金を帰属させたいなら各組織が自分のアカウントの認証情報で直接アクセスする必要がある。
【SAP-177】ある会社はオンライン小売事業を展開しており、顧客向けダッシュボードでパーソナライズされたキャンペーンを提供しています。
マーケティング部門は、Amazon S3 に保管されている数百個の CSV ファイルから SQL でセグメントを抽出し、その結果を即座に施策へ反映しています。
今回、個人情報保護法への対応強化を背景に「転送中・保存時とも暗号化を徹底し、実行されたクエリをすべて監査し、不適切な問い合わせがあれば管理者へ自動通知する」という新たなガバナンス要件が追加されました。
運用チームは小規模で、スケールアウトやメンテナンス作業を極力最小化したいと考えています。
管理基盤は AWS Organizations で整備済みで、新設した管理アカウントにはフル権限 IAM ユーザーがいます。
ビジネス上の狙いは「分析リードタイムの短縮」と「内部統制の強化」であり、技術的には(1)Amazon S3 上のファイルを直接高速に読み取れるサービスを利用すること、(2)TLS と AWS KMS により通信と保存の双方を暗号化すること、(3)SQL クエリ履歴を集中ログとして残し、イベント駆動で Amazon SNS へ通知を行うことが必須条件です。
ソリューションアーキテクトはこれらの要件を踏まえ、インフラ設計レベルでどのサービス構成を採用すべきか?
「S3 を直接 SQL でクエリできること」「Athena のクエリ実行を CloudTrail で追跡し、EventBridge などを経由して Amazon SNS で通知できること」の 2 点を同時に満たせているかに注目してください。Athena+S3+CloudTrail+SNS を許可する SCP 構成が、ガバナンスと分析要件の両方に素直に対応します。
【SAP-284】オンライン決済サービスを展開するある企業では、単一リージョン内で 決済本番/分析用/監査用 の 3 つの AWS アカウントを使い分け、利用者に24時間稼働の決済APIと管理ポータルを提供している。
セキュリティ監査強化方針により、各アカウントの Elastic Load Balancer が出力するアクセスログを一元的に保管し、事後分析や不正取引調査に即座に活用できる体制を整える必要が生じた。
ログは中央管理専用アカウントの既存 S3 バケット sample-s3-bucket に集約し、保存データは必ず暗号化状態で保持することが経営層から求められている。
中央アカウントでは ELB を運用せず、他のワークロードも置かないため、最小限の権限で運用負荷を抑える構成が望ましい。
各アカウントにおける運用担当者はスケーラビリティを損なわず自動でログが転送される仕組みを維持しつつ、暗号化やアクセス制御の設定ミスが発生しないよう Infrastructure as Code で共通設定を適用しようと考えている。
ソリューションアーキテクトは、これらの技術的要件(保存時暗号化、マルチアカウント集約)とビジネス上の狙い(監査対応迅速化、運用コスト削減)を同時に満たすため、インフラ設計レベルでどの手順の組み合わせを選択すべきか。
最適な2つの選択肢はどれか?
【前提】ELB(ALB・NLB・CLB)のアクセスログ機能を有効化すると、ELBサービス自身が自動的に指定S3バケットへログファイルをPutObjectする。手動転送は不要。この自動転送を成立させるにはバケットポリシーでPutObjectの許可が必要。
各アカウント個別バケット案は集約と運用コスト削減の狙いと矛盾する。中央アカウント単一バケット+書き込み専用クロスアカウント権限+SSE-S3 デフォルト暗号化、という組み合わせになっているかどうかを確認してください。
⚠️ こちらは教材の操作/UIなど全般に対するリクエストフォームではございません。
個別の問題についての改善リクエストです。
教材全般についての改善リクエストはお問い合わせフォームよりご連絡ください。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
