10問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SAP-1】グローバルで 4K 映画を配信する動画サブスクリプション企業は、1 本あたり 50 GB の動画ファイルを毎週 2,000 本追加している。公開後 48 時間は非常に高頻度でストリーミングされるが、その後はアクセスが急減する。ただし「加入者はいつでもダウンロード待ち時間ゼロで視聴できる」ことが SLA で定義されている。
ファイル数は今後も増え続けるため、ストレージコストを最小化しつつ世界各地への配信パフォーマンスも維持するアーキテクチャを設計する必要がある。どの構成が最も要件を満たすか。
公開直後は高頻度アクセスだが二日後に急減するというアクセス特性と、視聴時の待ち時間ゼロを同時に満たすストレージ階層を思い出してください。自動でアクセス頻度を判定し即時取り出しが可能な階層化サービスはどれでしょうか。取り出しに分単位以上かかるアーカイブや手動移行、リージョンごとのファイルサーバー配置は費用や運用負荷、転送レイテンシを押し上げます。世界中への配信ではエッジキャッシュとの組み合わせを前提に総所有コストとSLAの両面から総合的に比べてください。また、頻度が変わるたびに人手でクラス変更する運用は毎週2000本追加という規模で現実的かを検討すると判断がしやすくなります。
【SAP-2】あるフィンテック企業は東京リージョン (ap-northeast-1) の VPC 内プライベートサブネットで多数の Linux EC2 インスタンスを運用している。
現行はインターネット公開された Bastion ホスト (TCP/22) 経由で運用アクセスしているが、セキュリティ部門から次の必須要件が提示された。
1. インターネットからの TCP/22 を完全に排除し、Bastion ホストも不要にすること
2. オペレータが対話シェルに加えてローカルポート 8080 → インスタンス上の 3306 へトンネリングしてデバッグできること
3. すべての操作ログを KMS で暗号化した状態で CloudWatch Logs と S3 に 7 年間保管すること
4. EC2 はプライベートサブネットに留め、AWS API とは VPC エンドポイント経由のみで通信させること
5. 現行 Bastion 運用より運用負荷を削減すること
これら全要件を最も効率的に満たす解決策はどれか。
22番ポートを完全に閉じたいなら、SSHではなくHTTPSで通信しエージェント経由でEC2に接続できるマネージドサービスを検討してください。対話シェルだけでなくポートフォワーディング API も備え、運用者は IAM 権限 ssm:StartSession と類似の最小セットだけで利用できます。セッションの入出力は CloudWatch Logs と S3 に同時書き込みができ、KMS キーを指定すれば暗号化と 7 年間の保管も容易です。インスタンスはプライベートに留め、SSM など三つのインターフェイス VPC エンドポイントを立てれば NAT や公開 IP は不要となります。踏み台ホストの構築・監視・パッチ作業が消えることで運用負荷も大幅に減るため、五つの要件を一括で満たせる案を総合的に選択しましょう。
【SAP-3】製造業のお客様は、自社データセンターの vSphere 仮想マシンを災害対策目的で AWS に複製したいと考えている。
‐ 目標復旧時点 (RPO) は 15 分以内
‐ 通常時はできる限りコストを抑え、災害宣言時のみ EC2 を起動して業務を継続したい
‐ 復旧後はワークロードを短時間でオンプレミスへ戻す必要がある
‐ アプリケーションはブロックデバイスのフォーマット変更が許されない
これらの要件を最も効率的に満たす DR ソリューションはどれか。
RPO を 15 分以内に抑えるには、秒〜分単位でのブロックレプリケーションが必須です。平常時のコスト削減を重視するなら、待機中はスナップショットだけ保持し EC2 を停止させ、災害宣言時にワンクリックでインスタンスと EBS を生成できる仕組みが理想です。復旧後にオンプレミスへ短時間で自動逆同期できる機能も不可欠です。ファイル転送中心の仕組みや 1 日 1 回のバックアップ、常時稼働のウォームスタンバイは要件と合いにくい点を意識しましょう。vSphere VM のディスク形式を変えずエージェントで直接ブロックを取り込めるかも判断材料になります。RPO、平常時コスト、フェイルバック自動化、フォーマット非変更の四要件を同時に満たせる選択肢を総合的に見比べてください。
【SAP-4】あなたはグローバル製造企業のソリューションアーキテクトとして、オンプレミスで稼働する三層業務システム(総ユーザー 3,000 人、PostgreSQL 11、Java アプリ)を AWS へ移行する計画を立てている。要件は次のとおりである。
1) システム全体の可用性を年間 99.95% 以上にする。
2) 世界 5 拠点からの画面操作体感を 100 ms 未満に改善し、高遅延の苦情を解消する。
3) コード改修はライブラリ更新程度に留める(リフト&シフト重視)。
4) 現行 12 台分をオンデマンド EC2 に単純移行した場合より総所有コスト (TCO) を下げる。
次のうち、これらの要件をすべて満たす最も適切なアーキテクチャを選択せよ。
高可用性を99.95%以上に保つには、サービスSLAがこれを超えるマルチAZ構成のマネージドDBと自動フェイルオーバーを検討しましょう。世界5拠点のレイテンシ改善は、各リージョンにアプリを再構築するより、画面転送型マネージドサービスを分散配置する方が改修を抑えつつ応答を短縮できます。アプリ層は既存AMIをそのままAuto Scalingさせ、負荷に応じて増減させればコストも抑制できます。TCO削減には台数固定のオンデマンドより、Savings Planなど稼働に比例して課金される仕組みが有効です。可用性、遅延、改修工数、コストの四条件を並べて評価し、すべてを同時に満たせる案を総合的に判断してみてください。
【SAP-5】オンプレミスで稼働している 3 層構成の OSS Web アプリケーション(Apache/Tomcat/MySQL)を AWS へリフト&シフトする計画が進んでいる。移行後に想定されるリスクは以下のとおりである。
• 数百 Gbps 規模の大規模 DDoS 攻撃
• Web レイヤでの SQL Injection などのアプリケーション攻撃
• EC2 インスタンスへの辞書攻撃(SSH Brute-force)
現状、運用チームはオンプレミス同様に SSH で直接ログインしてパッチを適用しているが、移行を機に可用性を落とさずリスクを低減したい。
以下の追加施策から最も適切な構成を 1 つ選択せよ。コスト効率・運用負荷も考慮すること。
大容量DDoSを数百Gbpsまで想定するなら、エッジネットワークでの吸収と専用サポート付きの防御サービスが必要です。さらにWeb層のSQLi対策はマネージドWAFで網羅し、SSH辞書攻撃はポート自体を閉じてSystems Manager経由で運用すれば根本原因を排除できます。DBの高可用性は自前複製よりRDSのMulti-AZが低運用コストで確実です。これらを同一アカウントで組み合わせ、余計なアプライアンスや踏み台を残さない案が最も要件をバランス良く満たします。オートスケーリングと従量課金を活かせばピーク時もコスト効率を保てる点にも注目しましょう。最後に全体の可用性,セキュリティ,運用負荷のバランスを比較して選択してください。
【SAP-6】製造業SaaSの海外顧客が10GBファームウェアをモバイル回線経由で東京リージョンの単一S3バケットへ直接PUTしている。高レイテンシーのため転送に2時間以上かかり途中切断も発生。リージョン移設は不可。追加コストは許容するがアプリ改修は最小限としたい。
前提:
– 単一ファイルは5GBを超過
– 90分以内にアップロードを完了させたい
転送時間と再送を最も効率的に削減できる組み合わせはどれか。(2つ選択)
海外利用者がモバイル回線で10GBを東京の単一バケットに入れるシナリオでは、①ファイルサイズが5GBを超えるため単一PUTは非推奨で、途中切断時に全体を再送するリスクがあります。パート単位で並列送信・途中再開ができる仕組みを使えば転送途中の失敗コストを大幅に削減できます。②高レイテンシー区間そのものを短くするには、クライアントが最寄りのエッジに対してPUTし、そこからAWSが内部ネットワークで東京へ運ぶ方式を検討しましょう。DNSポリシーやキー名の工夫は経路品質を変えず、別リージョン経由の二段転送は全体の完了時間を伸ばします。改修は送信先URLの変更やAPI呼び出しを置き換える程度に留め、追加転送料やサービス利用料は許容できるかを勘案し、速度・再送・工数のバランスを総合判断してください。
【SAP-7】国際的なスポーツ配信プラットフォームでは、試合開始直前に視聴登録リクエストが数分間で数十万件急増する。
システム要件は以下の通りである。
1. リクエストをバースト的に受信しても取りこぼしなくバッファし、処理は非同期で行うこと
2. 登録結果はミリ秒レイテンシで NoSQL データストアに永続化すること
3. アプリケーションサーバーやコンテナのキャパシティ計画・パッチ適用を運用チームが行わないこと
4. 単一障害点を排除し、需要に応じて自動的に水平方向へスケールすること
5. 重複メッセージは許容できるが、順序保証は不要とする
これらの要件を最も効率的に満たすアーキテクチャの組み合わせはどれか。
急激なリクエスト増に備えるには、まず受信と処理を切り離す弾力的なバッファが重要です。無制限に伸び、少なくとも1回は配送されるフルマネージドのキューを使えば、重複は生じても順序要件がない今回の条件に合います。次に、そのキューの深さに応じて自動で並列起動し、管理作業を不要にするサーバーレス関数を組み合わせれば、キャパシティ計画やパッチ適用から解放され、多 AZ で高可用性も担保されます。バッファ後はミリ秒レイテンシの NoSQL に非同期書き込みし、入口の API からデータストアまで全てフルマネージドで統一されている案が、ストリームでシャード管理や EC2 コンシューマを持つ案、同期呼び出しのみの案、ワークフロー指向でバッファ不足の案と比べ、最も要件全体をバランス良く満たします。
【SAP-8】ある大手メディア企業は、毎日 2 TB ずつ追加され最終的に 200 TB 以上となるログデータを解析し、月次およびアドホックの業務報告書を作成している。
現在は複数の Amazon EC2 インスタンスに OSS の Hadoop/Spark クラスタをセルフホストしているが、下記の課題が顕在化している。
• ノード障害対応やパッチ適用に多くの運用工数を要する
• 夜間や週末は利用率が 10 % 未満にもかかわらず常時インスタンス料金が発生している
• 既存の PySpark/Hive スクリプトや HDFS API を大幅に書き換える余裕はない
経営層は「互換性を保ったままマネージド分析サービスへ移行し、総所有コスト (TCO) と運用負荷を最小化できるか」を調査するよう求めている。
要件は次のとおりである。
1. 既存の Hadoop/Spark 処理ロジックをほぼそのまま移行できること
2. 計算リソースはオンデマンドに自動スケールし、アイドル時のコストを抑制できること
3. データは計算リソースと分離し、耐久性とコスト効率に優れたストレージへ格納すること
4. ノード管理・パッチ適用など日常運用をサービス側に委譲できること
最もコスト効果の高いソリューションはどれか。
移行の鍵は「コード互換」「アイドルコスト削減」「運用委譲」の3点です。まず既存 PySpark や Hive がほぼ手を入れずに動くかを確認しましょう。サービス固有の SQL へ書き直す案や Glue ジョブ再実装が必要な案は要件1に注意です。次に計算リソースとデータが分離され、ジョブ実行時だけ伸縮できれば夜間のコストを抑えられます。常時 EC2 や EBS が残る構成では期待ほど削減できません。最後にパッチ適用やノード障害対応を誰が担うかを比較します。マネージド Hadoop を採用するか、完全サーバーレスに振り切るかで運用範囲が変わります。各案をこの3軸で採点し、最もバランスが良いものを選びましょう。
【SAP-9】自社のオンプレミス SAML 2.0 IdP と AWS をフェデレーションしている。社内ポータル経由で AWS コンソールへサインインした場合のみ認証が失敗し、CLI から直接 AssumeRoleWithSAML を実行した場合は成功する。アーキテクトは原因を特定するため設定を点検することにした。最初に確認すべき項目を 3 つ選びなさい。
CLI では成功しポータル経由だけが失敗する場合、まず疑うべきはネットワークや IAM ユーザー権限ではなく、SAML アサーションの内容とロール側の信頼関係です。ロールの信頼ポリシーに SAML プロバイダと AssumeRoleWithSAML が含まれているか、アサーションの Role 属性にロール ARN とプロバイダ ARN が正しい順序で対になっているか、さらに IdP で設定したユーザー/グループとロールの対応がそのままアサーションへ反映されているかを確認しましょう。ポータルはブラウザ経由で属性が欠落しやすいので、生成直後のアサーションをキャプチャして比較すると原因を絞り込みやすくなります。AWS 側と IdP 側の設定を突き合わせ、要求される前提条件が一貫して満たされているかを総合的に判断してください。
【SAP-10】TechStream 社では 50 以上の AWS アカウントを AWS Organizations で一元管理している。
タグガバナンスの方針として、下記の要件を満たす設計を検討している。
• 各リソースには必須タグ key = “CostCenter” を付与させ、値は “FIN”, “MKT”, “DEV” のいずれかに限定したい
• タグ非準拠であってもリソース作成自体は拒否せず許可する
• 非準拠が発生したら即時に運用チームへ通知する
• 追加の AWS Lambda や手動チェックは行わず、サービスネイティブ機能のみで実装する
この要件を最も効率的に満たすアーキテクチャはどれか。
リソース作成自体は認めつつタグの値だけをチェックしたいとき、リクエスト段階で拒否を返す IAM 条件や SCP は役割が合いません。コードを持たせる Config のカスタムルールも「Lambda なし」の条件に反します。Organizations には許可タグ値を一括管理し、準拠状況を継続的に評価する仕組みがあり、その結果は EventBridge に自動で通知イベントとして流せます。ここから SNS へルーティングすれば即時アラートまで追加開発なく完結できます。ブロック型と監査型の違い、サービスネイティブかどうかを軸に、全要件を俯瞰して最もシンプルな構成を選びましょう。