DVA-1.1AWS でホストされているアプリケーション用のコードの開発
採点する
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)
カテゴリー
- DVA-1.1AWS でホストされているアプリケーション用のコードの開発 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 10
1. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-1】金融系スタートアップは、オンプレミスの発注システム（HTTPS,XML）をAWS上の取引管理マイクロサービスへ段階的に移行中である。
要件:
①Amazon API Gateway経由でLambda関数へルーティング
②リクエストXMLをJSONへ、レスポンスJSONをHTTP 201/400などに変換
③今後エンドポイントを追加してもLambda側のコード変更を最小化する。
最も運用負荷が低く、要件を満たす統合方法はどれか。正解不正解ヒントボタン
金融機関のようにフォーマットが固定された XML が飛んでくるケースでは Amazon API Gateway のリクエスト／レスポンス変換機能が大きな助けになり、REST API タイプは Velocity Template Language を用いて XML⇔JSON 変換や 201,400 といったステータスコードマッピングをメソッド単位で柔軟に設定できる一方、HTTP API タイプは現時点で同等の変換機能を備えていないためその差が AWS Lambda の実装量と運用コストに直結します。
同じ REST API を選んだとしても Lambda プロキシ統合とカスタム統合では責任分界が変わり、プロキシ統合は API Gateway が受け取ったボディをそのまま AWS Lambda に渡すだけなので XML 解析やステータスコード付け替えを関数内に書く必要がありますが、カスタム統合なら VTL テンプレートでペイロードやヘッダーを組み替えたうえでバックエンドに送れるためロジックを共通化して再利用しやすく将来エンドポイントを増やしてもコードの肥大化を抑えられます。
要件のルーティングを Amazon API Gateway で実現しつつ XML⇔JSON と HTTP 201/400 などの変換をエッジ側で完結させ今後の拡張でも AWS Lambda のコード変更を最小に抑えるという複数条件を全体俯瞰すると、REST API と Velocity Template Language を組み合わせたカスタム統合こそが保守性・運用負荷・セキュリティのバランスを最も満たす選択肢と判断できます。 -
質問 2 of 10
2. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-2】旅行予約サイトを運営する企業は、ECS Fargate 上で稼働する Go 製マイクロサービス（ALB 経由で /v1/* を受け付ける）を外部公開したい。
要件は次のとおり：
①最大 1 秒あたり 5,000 リクエストを処理
②HTTP ヘッダー・クエリストリング・ステータスコードを変換せず透過
③VTL や Lambda など追加コードは作成しない
④API Gateway のキャッシュとスロットリング機能は利用する。
これらを満たす統合タイプとして最も適切なものはどれか。正解不正解ヒントボタン
API Gateway には REST API と HTTP API の 2 つの系統がありますが、ステージレベルキャッシュと使用量プランによるスロットリングは REST API にしか備わっていません。HTTP API は現時点でキャッシュ非対応のため「API Gateway のキャッシュとスロットリング機能を利用する」という要件を満たすには REST API が前提となります。さらに REST API はデフォルトでリージョン当たり約 10,000 RPS が許容され、5,000 RPS 程度のトラフィック目標とも整合します。
REST API から Application Load Balancer へ透過的に流したい場合、統合タイプを HTTP_PROXY に設定すると受信した HTTP ヘッダー・クエリストリング・ステータスコードを変換せずそのままバックエンドへ転送できます。AWS_PROXY 統合では Lambda などに合わせたイベント形式へ変換されるため追加のハンドラー実装が必要になり「コードを書かない」という条件に合いません。MOCK 統合は固定レスポンス用であり ALB にリクエストを送らないため今回の用途には適さない点も合わせて整理しておきましょう。
以上を踏まえると、1 秒あたり 5,000 リクエストの性能要件、ECS Fargate ＋ ALB への透過ルーティング、追加プログラムなし、そして REST API のキャッシュとスロットリングを同時に実現する設計は、REST API を前提に HTTP_PROXY 統合で ANY メソッドを ALB に直接マッピングする構成が AWS 公式ドキュメントでも推奨されるシンプルな解となり、複数要件を総合的に満たす最適解と判断できます。
-
質問 3 of 10
3. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-3】フィンテック企業は Auto Scaling グループで稼働する Amazon EC2 Linux インスタンス上の Go アプリケーションに、起動直後 1 秒以内で自インスタンスのプライベート IPv4 を取得し初期化ログへ記録する機能を追加したい。
要件は
①外部 API や追加 IAM 権限を使用しない
②IMDSv1 無効化方針を見据えた最新のベストプラクティスに準拠
③インスタンス内完結で待ち時間 10 ms 未満を維持する。
最も適切な実装方法はどれか。正解不正解ヒントボタン
EC2 インスタンス内からプライベート IP を取得する方法のうち、Instance Metadata Service の IMDSv2 は 169.254.169.254 へのローカルアクセスとトークン認証で SSRF を抑止でき、AWS が公式に推奨する最新ベストプラクティスです。IMDSv1 を無効にしても機能し、curl でトークン取得後に local-ipv4 を読むだけの 2 ステップで完結します。往復はカーネル内ルートなので数ミリ秒で済み、Go アプリに組み込んでも 10 ms 未満の要件を容易に満たせます。
AWS SDK for Go から ec2:DescribeInstances を呼ぶ方法は制御プレーン API を外部に発行するため IAM ポリシーが必須で、VPC エンドポイントや NAT Gateway 経由の通信が発生します。ネットワーク越しに数百ミリ秒かかることも多く、Auto Scaling 直後 1 秒以内かつ 10 ms 未満という厳しいレイテンシには不利です。設問の「外部 API や追加 IAM 権限を使用しない」という要請と両立しない点を整理しましょう。
起動テンプレートの user data で hostname -I をファイルへ保存する方法は cloud-init のフェーズやネットワーク初期化タイミングに依存し、毎回 1 秒内で確実に取れる保証がありません。後で ENI を付け替えた場合にファイル内容が古くなる恐れもあります。インスタンス内完結で常に最新情報を得るには IMDSv2 へ直接問い合わせる方式が権限追加なし・高速・将来互換の三要件を満たせるため、セキュリティ・パフォーマンス・運用性を俯瞰した総合判断で選んでください。
-
質問 4 of 10
4. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-4】FinTech 企業 X 社は、株価をブラウザとモバイルアプリにリアルタイム配信し、ユーザが注文リクエストを即座に送信できる双方向機能を開発している。
要件は同時 50,000 接続、1 メッセージ ≤1 KB、往復レイテンシ 100 ms 未満、アイドル時はコストを最小化し、サーバのパッチ適用作業をなくすこと、接続ごとに Cognito JWT を検証し、切断後 5 分以内に接続情報をクリーンアップすることである。
最適なアーキテクチャはどれか。正解不正解 -
質問 5 of 10
5. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-5】フィンテック企業は検索補助 API を API Gateway REST API と AWS Lambda で構築している。
エンドポイント /suggest は毎秒最大 300 リクエストに対応し、必須のクエリ文字列 q と limit をそのまま Lambda に渡すこと、未指定時は 400 を返すこと、追加の変換ロジックを記述しないことが求められる。
最も適切な構成はどれか。正解不正解ヒントボタン
API Gateway の REST API で Lambda プロキシ統合を選択すると、受信した queryString がそのまま JSON で AWS Lambda に転送されます。メソッドリクエストで q と limit を「必須」に設定すると欠落時は自動で 400 を返せるため、1 秒 300 リクエスト規模でも追加コードやマッピングテンプレートなしでスケーラブルに要件を満たせます。
HTTP API は低レイテンシで魅力的ですが、現状は必須クエリパラメータのバリデーション機能がなく、ステージ変数は静的値注入に使う仕組みです。そのため q や limit を動的に渡したり未指定時に自動で 400 を返したりするにはマッピングテンプレートや Lambda 側ロジックが必要となり、「変換ロジックを記述しない」という前提と齟齬が生じやすい点に注意してください。
API Gateway が動的クエリをそのまま Lambda に渡しつつ欠落時は 400 を返し、毎秒 300 リクエストを無理なく処理する―この複数の要件を俯瞰すると、REST API のメソッドリクエストバリデーションと Lambda プロキシ統合を組み合わせた構成が機能面・運用面ともに最も自然でバランスの取れた選択肢となります。 -
質問 6 of 10
6. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-6】金融系スタートアップは、ECS Fargate 上のプライベート ALB で稼働する社内 REST サービスをパートナー企業へ公開したい。
パートナーから届く JSON リクエストを XML に変換してサービスへ渡し、応答 XML を JSON に再変換しつつ、HTTP 4xx/5xx を独自コードに置換する必要がある。
アプリケーション側は改修不可で、追加レイテンシは 50 ms 未満としたい。
最小の運用負荷で要件を満たすアプローチはどれか。正解不正解ヒントボタン
プライベートサブネットの Application Load Balancer を外部パートナーへ安全に公開するには、Amazon API Gateway の VPC Link が効果的です。VPC Link は ENI 経由で内部 ALB に直接接続できるため、ALB をインターネット向けに変更したり別途 NLB を用意したりする作業が不要です。ECS Fargate のセキュリティグループも最小限の調整で済み、ネットワーク設計と運用負荷を大きく増やさずに済みます。
受信した JSON を XML に変換し、応答の XML を再び JSON に戻す要件は、API Gateway REST API の Velocity Template Language でノーコード実装が可能です。マッピングテンプレートでは本文だけでなくヘッダーや HTTP ステータスも自在に書き換えられるため、4xx／5xx を独自コードへ置換する処理まで同じテンプレート内で完結します。追加コンピュートリソースが発生しない点が運用効率につながります。
レイテンシを 50 ミリ秒未満に抑えるには、Lambda を介在させる構成だとコールドスタートや実行時間の揺らぎがボトルネックになり得ます。API Gateway のマッピング処理はランタイム不要で数十ミリ秒で応答でき、マネージドサービスゆえパッチ適用も不要です。通信経路の単純化、データ変換機能、遅延許容値という複数要件を俯瞰すると、ネットワークと変換を一箇所でまとめて担える手段が最も合理的であると判断できます。
-
質問 7 of 10
7. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-7】フィンテック企業の CI/CD ジョブ (AWS CodeBuild) では、毎晩 1 回、東京リージョンに存在する t3.micro で稼働中の EC2 インスタンス ID を改行区切りのプレーンテキストで取得し、最大 50 台分をそのまま後続の自動停止スクリプトにパイプする必要がある。
環境変数 AWS_DEFAULT_REGION は未設定で、追加の API 呼び出しは避けたい。
要件を最小変更で満たす AWS CLI コマンドはどれか。正解不正解ヒントボタン
EC2 インスタンスを絞り込むときは AWS CLI で aws ec2 describe-instances を呼び出し、–filters に Name=instance-type,Values=t3.micro と Name=instance-state-name,Values=running を並べれば、1 回の DescribeInstances API で t3.micro かつ稼働中だけを取得でき、CodeBuild の追加呼び出しが増えません。Filters は論理 AND になるため jq などの後処理も不要で、50 台以内という要件にも安全に収まります。
AWS_DEFAULT_REGION が空でも CLI は –region を優先しますので ap-northeast-1 を明示すれば東京リージョンに限定でき、他リージョンへの余計な呼び出しが回避できます。さらに –output text を指定すると InstanceId が改行区切りのプレーンテキストで返り、そのまま stop-instances スクリプトへパイプできるので、CodePipeline や CloudWatch Events での自動化にも支障がありません。オプション名のスペルミスは Unknown options エラーの原因になる点に注意してください。
describe-instances と –filters で条件を絞り、JMESPath の –query “Reservations[].Instances[].InstanceId” で ID のみに整形し、–region ap-northeast-1 と –output text を組み合わせたワンライナーは、API 回数を最小化し CLI の正式なサブコマンドとオプションだけで構成できます。存在しない list 系コマンドや非公式オプションが混ざっていないか、リージョン設定方法、そして出力形式という三つの観点を総合的に確認すると最適解を選びやすくなります。
-
質問 8 of 10
8. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-8】金融 SaaS 企業の開発チームは、Auto Scaling Group 内の Amazon Linux 2023 EC2 (最大50台、平均同時500リクエスト/秒) 上で稼働する Python マイクロサービスから、実行時に IAM ロール ARN と稼働 AZ を取得したい。
セキュリティ部門は「IMDSv1 禁止」「トークン TTL 2 時間以内」「失敗時は指数バックオフで再試行」の遵守を必須としている。
最も適切な実装方法はどれか。正解不正解ヒントボタン
EC2 Instance Metadata Service をセキュアに使うなら Launch Template で HttpTokens=required と HttpEndpoint=enabled を宣言し IMDSv2 を強制するのが鉄則です。これにより Amazon Linux 2023 上のプロセスが IMDSv1 へ接続しようとしても OS レベルで拒否されるため、金融 SaaS で厳格に求められる「IMDSv1 禁止」ポリシーを追加コードなしで満たせます。
IMDSv2 では最初に PUT 169.254.169.254/latest/api/token を送信し X-aws-ec2-metadata-token-ttl-seconds で 7200 秒を設定できます。Python アプリで約 1 時間 55 分メモリキャッシュすると「トークン TTL 2 時間以内」を守りつつ呼び出し回数を抑え、Auto Scaling により最大 50 台へ増えてもメタデータ通信が爆発せずネットワークと CPU の負荷を軽減できます。
AWS Well-Architected Framework 推奨の指数バックオフを AWS SDK か自前ロジックで組み込み、トークン再取得や iam/security-credentials・placement/availability-zone 取得が一時失敗した際に 100ms から 2 倍ずつ遅延して再試行すれば、高トラフィック Auto Scaling Group でも IAM ロール ARN と AZ を安全かつ効率的に取得でき、全要件を総合的に充足できます。
-
質問 9 of 10
9. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-9】ある EC サイトでは顧客がアップロードする商品画像を Amazon S3 バケット image-raw に保存している。
要件は次のとおり:
1) 1 分あたり最大 5,000 PUT に耐え、画像アップロードから 30 秒以内にリサイズ処理を実行する。
2) 同タイミングで運用チームにメール通知を送る。
3) コード変更なしで将来さらに複数の処理系を追加できる。
4) ポーリングや不要な結合を避け、最新の AWS ベストプラクティスに従う。
最も適切な設計はどれか。正解不正解ヒントボタン
Amazon S3 はオブジェクト作成イベントを直接いくつかのサービスへプッシュできますが、1 分あたり 5,000 PUT のバーストを受け止めながら画像リサイズや監査ログなど複数処理へ同時配信したい場合、ファンアウトと再試行を備えた Amazon SNS を間に置き、Lambda や SQS さらに将来の EventBridge 連携を購読追加するだけで拡張できる設計パターンを思い出してください。
1 つの Lambda で画像リサイズと Amazon SES 通知をまとめると実装は短く見えますが、要件にある「コード変更なしで処理系を増やす」観点ではロジック肥大と失敗ドメイン共有につながりますので、イベントを Amazon SNS や EventBridge に発行し、それぞれ独立したサブスクライバーが責務ごとに並列実行される疎結合アーキテクチャがベストプラクティスとなります。
ポーリングが必要な Amazon SQS や定期実行主体の CloudWatch Events だけではアップロード完了から 30 秒以内というリアルタイム性を担保しにくく、Step Functions を画像 1 枚ごとに起動するとコストやオーバーヘッドも増大しがちですので、S3 からのプッシュ通知で高並列に Lambda を起動しつつメールも即時配信できる Amazon SNS 連携がスループット・通知・拡張性の複数要件を総合的に満たす構成になります。 -
質問 10 of 10
10. 質問
カテゴリ: DVA-1.1AWS でホストされているアプリケーション用のコードの開発【DVA-10】あるフィンテック企業は、申込書をリアルタイムで審査するサーバーレス API を開発している。
ワークフローは
①身元確認 Lambda (平均100 ms)→
②外部クレジット API 呼び出し(最大10 秒、HTTP 429/500 が10%発生)→
③結果を DynamoDB へ保存の順で実行する必要がある。
クレジット API は指数バックオフ付きで最大3回再試行し、それでも失敗した場合は手動調査用の SQS DLQ にメッセージを送信し、残りのステップを中断することが要件である。
またワークフローはコードを改修せずに可視化・バージョン管理でき、今後 EventBridge からの呼び出しにも再利用したい。
運用負荷を最小化し、AWS の最新ベストプラクティスに合致する実装はどれか。正解不正解ヒントボタン
リアルタイム審査の一連フローを Lambda→外部クレジット API→DynamoDB と進める場合、処理順序や分岐をアプリケーションコードから切り離し、JSON／YAML で宣言的に書いて Git でバージョン管理し、Workflow Studio と Execution History で可視化できる Step Functions 標準ワークフローが最もシンプルです。さらに EventBridge ルールから同じ定義を再利用して呼び出せるため、新たなチャネル追加時も呼び出し元の変更は最小で済み、疎結合な構成を保てます。IAM ポリシーで各タスクの権限を細かく限定できるのでセキュリティレビューも容易になり、エラーハンドリングの調整も定義ファイルを更新するだけで完結します。
外部サービスは HTTP 429 や 500 が散発するため、Step Functions の Task に Retry を設定すれば MaxAttempts、IntervalSeconds、BackoffRate を宣言的に指定でき、指数バックオフで 3 回試行後に Catch で分岐し SQS に SendMessage して Fail ステートへ遷移し残りの Lambda や DynamoDB 書き込みをスキップできます。コードを改修せずに再試行と異常分岐を追加できるので運用が一元化され、スロットリング対策とコスト抑制も両立します。DLQ 用 SQS は CloudWatch Metrics で監視でき、手動調査が必要なメッセージだけを運用チームが確認できるため、可視化と障害対応の手順が統合的に整備できます。
サーバーレス設計の原則として、オーケストレーションを Step Functions、ビジネスロジックを Lambda、状態保存を DynamoDB、失敗イベント保管を SQS に分離し、Retry／Catch や可視化といった横断要件をコード外で集中管理できるかが鍵です。EventBridge 連携や JSON 定義のバージョン管理、DLQ 送信とワークフロー停止を一式で実装できるサービスがどれかを比較すると、開発・運用の両視点で最小コストかつ高拡張性を実現できる選択肢が自ずと浮かび上がるはずです。
改善リクエスト