AWS 認定デベロッパー –アソシエイトとは?傾向は?過去問は役に立つ?AIに予想問題を作らせてみた

AWS 認定デベロッパー –アソシエイトとは?傾向は?過去問は役に立つ?AIに予想問題を作らせてみた

AWS認定デベロッパー – アソシエイト(AWS Certified Developer – Associate)は、世界的なクラウドサービスプロバイダーであるAmazon Web Services社が主催している、AWSに関する専門知識とスキルを評価し、証明するための国際的な認定資格です。この試験は、単にAWSの各サービスを知っているかだけでなく、クラウド環境でのアプリケーション開発、デプロイ、そしてデバッグといった、開発者としての基礎的なスキルを客観的に測ることに重点を置いています。

この資格を取得することで、ご自身のAWS開発者としてのスキルが国際的な基準を満たしていることを証明できます。履歴書に記載して就職活動や転職活動でアピールしたり、企業内でのスキル評価に利用されたりすることがあります。特に、多くの企業がクラウド移行を進めている現代において、この資格は世界中で高い評価を受けています。


 

資格の位置づけと他のAWS認定資格との関係

AWS認定資格は、スキルレベルに応じてFoundationalAssociateProfessionalSpecialtyの4つのカテゴリに分かれています。AWS認定デベロッパー – アソシエイトは、その中でも中級レベルであるAssociateに位置づけられています。

  • AWS認定クラウドプラクティショナー:AWSの基本的な概念を理解しているかを問う入門レベルの資格です。
  • AWS認定デベロッパー – アソシエイト:クラウドプラクティショナーの知識を土台として、AWSの環境でアプリケーションを開発する専門的なスキルを証明する中級レベルの資格です。
  • AWS認定ソリューションアーキテクト – プロフェッショナル:デベロッパー – アソシエイトの知識を前提として、より高度なクラウドソリューションを設計する専門家向けの最高峰の資格です。

AWS認定デベロッパー – アソシエイトは、AWSの基礎知識がある方を対象に、より実践的な開発スキルを問う資格です。まずはクラウドプラクティショナーで土台を築き、次にこの資格を目指すのが一般的な流れとなります。


 

試験の傾向と出題形式はどうなっていますか?

試験の傾向を知ることは、効率的な学習を進める上で非常に重要です。AWS認定デベロッパー – アソシエイト試験は、出題範囲が非常に広く、現実のシナリオに基づいた問題が出題されるのが特徴です。

 

出題形式の特徴

AWS認定デベロッパー – アソシエイト試験は、選択式の問題が中心となりますが、単に4択から選ぶだけでなく、以下のような形式の問題も出題されます。

  • 複数選択問題:複数の選択肢から、正解をすべて選ぶ形式の問題です。単純な知識の暗記だけでなく、それぞれの選択肢がなぜ正解(または不正解)なのかを正確に理解していないと、正解にたどり着くのが難しい場合があります。
  • シナリオ問題:試験では、架空の企業のビジネス要件や技術的な制約が詳細に記された「シナリオ」が提示されます。そのシナリオに基づいて、最適なAWSサービスや設定を提案する問題が複数出題されます。これは、単なる知識の暗記だけでなく、それを現実の課題に適用する能力を測るためのものです。

これらの問題形式に慣れておくことが、合格のためには非常に重要です。

 

試験の主要な出題範囲

AWS認定デベロッパー – アソシエイトの試験範囲は、以下のようなカテゴリに分かれています。

  1. AWS開発の基礎:AWSのコアサービス(EC2、S3、Lambda、RDSなど)の基本的な機能や、APIを使った操作方法に関する知識が問われます。
  2. AWSサービスのデプロイ:AWS CloudFormationやElastic Beanstalkといったサービスを使って、アプリケーションをAWSにデプロイするスキルが求められます。
  3. セキュリティ:IAM(Identity and Access Management)によるアクセス制御、暗号化、そしてAWS WAF(Web Application Firewall)といった、アプリケーションを安全に運用するための知識が問われます。
  4. ストレージとデータベース:Amazon S3, Amazon EBS, Amazon RDS, DynamoDBといった、様々なストレージ・データベースサービスの種類と、それぞれの特性を理解し、適切なサービスを選定する能力が出題されます。
  5. モニタリングとトラブルシューティング:CloudWatch, CloudTrail, X-Rayといったサービスを使って、アプリケーションのパフォーマンスを監視し、問題を特定・解決する能力が求められます。

このように、AWS認定デベロッパー – アソシエイトは、クラウド環境での開発・デプロイ・運用といった、開発者の仕事で必要となる、まさに「かゆいところに手が届く」知識を網羅しているのが特徴です。


 

過去問は役に立ちますか?具体的な対策方法も教えてください

過去問や問題集は学習において非常に有効なツールです。特に、AWS認定デベロッパー – アソシエイトのような広範囲にわたる資格では、過去問を活用することで効率的に学習を進めることができます。しかし、ただ過去問を解くだけでなく、どのように活用するかが大切です。

過去問の活用法

過去問や問題集を解くことには、主に二つの大きなメリットがあります。

  1. 出題形式や傾向を把握できる:過去問を解くことで、どのような形式で問題が出されるのか、どの分野から頻繁に出題されるのかといった傾向を掴むことができます。これにより、効率的に学習する分野を絞り込むことが可能になります。特に、シナリオ問題の形式に慣れておくことは、本番での戸惑いをなくす上で非常に重要です。
  2. 自分の弱点を見つけられる:過去問を解いてみて、間違えた問題や理解に時間がかかった問題を分析することで、自分自身がどの分野を苦手としているのかを明確にできます。例えば、特定のAWSサービスの特性が曖昧、セキュリティの設定がよくわからないなど、具体的な弱点を見つけたら、そこを重点的に復習することで、より確実に実力を伸ばすことができます。

過去問は、ただ答えを丸暗記するのではなく、「なぜこのサービスを選ぶのが最適なのか」「なぜこの設定が必要なのか」を深く考えることが重要ですです。間違えた問題については、解説を読み込むだけでなく、実際にAWS環境でサービスを触ってみるなど、能動的に学習を進めていくことをおすすめします。

 

AWS認定デベロッパー – アソシエイト試験の具体的な対策

対策のポイント
  1. 公式教材や認定トレーニングを活用する:AWSが提供している公式の学習教材や、認定パートナーが開催するトレーニングコースを利用することは、試験範囲を効率的に網羅する上で非常に有効です。
  2. ハンズオンで実践経験を積む:アソシエイトレベルの試験では、実践的なスキルが問われます。AWSの無料枠を活用したり、Qwiklabsのようなハンズオンラボサービスを利用したりして、実際にAWSの各サービスを触ってみることが大切です。
  3. コマンドラインツールの使い方に慣れる:AWSの操作は、Webコンソールだけでなく、AWS CLIAWS PowerShellといったコマンドラインツールでも行えます。コマンドラインを使った操作は、試験でも出題される可能性があるため、普段から触っておくことが大切です。
  4. ベストプラクティスを学ぶ:AWSの公式サイトやブログには、各サービスのベストプラクティス(最善の方法)が多数公開されています。これらの情報をこまめにチェックして、AWSの思想や開発の考え方を深く理解しておくことが大切ですです。
  5. AWS認定クラウドプラクティショナー認定資格を取得しておく:デベロッパー – アソシエイトは、クラウドプラクティショナーの知識を前提としています。まずはクラウドプラクティショナーを取得して、AWSの基礎知識を固めておくことが、合格への近道となります。

 

この資格はどのような仕事に役立ちますか?

AWS認定デベロッパー – アソシエイトの資格は、クラウドに関連する多岐にわたる仕事で役立ちます。この資格は、ITインフラの根幹をなすクラウドの基礎知識を証明するものです。

  • Web開発者:Webアプリケーションをクラウド環境にデプロイする際、AWSの知識は不可欠です。Web開発者として働く上でも、クラウドの基礎知識を持つことは大きな強みとなります。
  • クラウドエンジニア:AWS環境の設計、構築、運用、そしてトラブルシューティングを行う専門職です。この資格は、クラウドエンジニアとして働く上での土台となります。
  • システム管理者:企業のサーバーをオンプレミスからクラウドに移行する際、クラウドの知識は必須です。この資格は、クラウド環境の運用・管理を行う上で役立ちます。
  • DevOpsエンジニア:開発チームと運用チームが協力して、開発からリリースまでのプロセスを自動化し、効率化する専門職です。DevOpsの知識は、クラウドの運用を最適化する上で不可欠です。
  • データアナリスト:AWSのデータサービス(Amazon Redshiftなど)を使ってデータを分析する際、クラウドの基礎知識を持つことで、より効率的に作業を進められます。

この資格は、これらの分野で働く上で、ご自身の知識やスキルを証明する有効な手段となります。


 

転職時には有利になりますか?

AWS認定デベロッパー – アソシエイトの資格は、転職活動において、ご自身のクラウドスキルを客観的に示すための非常に強力な武器となり得ます。

有利になる点

  1. 世界的な権威性の証明:AWS認定資格は世界中で広く認知されており、この資格を持っていることは、クラウド開発者としての基礎スキルを持っていることの証明になります。
  2. 学習意欲のアピール:IT業界は常に新しい技術が登場するため、継続的な学習が不可欠です。この資格取得に向けて努力したことは、企業に対して「この人は自ら学ぶ意欲が高い」という良い印象を与えます。
  3. 選考の最初のステップを突破しやすくなる:多くの応募者がいる中で、履歴書に記載された資格は、選考担当者の目に留まりやすくなります。特にクラウドを重視する企業では、この資格を持っていることが、面接に進むためのきっかけとなる可能性が高まります。
  4. 未経験者でもアピールしやすい:IT業界未経験者でも、この資格を取得することで、クラウドに関する基礎知識があることを証明できます。これは、他の未経験者との差別化を図る上で、非常に有効な手段となります。

 

資格だけで全てが決まるわけではありません

AWS認定デベロッパー – アソシエイトは、クラウドの基礎知識を証明する資格であり、合格している時点で、かなりの実践経験を持っているとみなされます。しかし、資格はあくまでスキルを証明する「きっかけ」であり、面接では、これまでの実務経験や、どのような課題を解決してきたかといった、具体的な話が求められます。

そのため、これまでのプロジェクトでどのような役割を担い、どのような貢献をしてきたのかを、この資格の知識と結びつけて具体的に説明できるように準備しておくことが非常に重要です。


 

AIに奪われる可能性は?これからも必要とされますか?

現代において、AI技術は驚くべき速さで進化しています。AIがアプリケーションのコード生成やデプロイの一部を自動化する時代が到来しつつある中で、「クラウド開発者の仕事はAIに奪われるのでは?」と心配される方もいらっしゃるかもしれません。

しかし、結論から申し上げますと、クラウド開発者の需要は今後もなくなることはなく、AWS認定デベロッパー – アソシエイトのような基礎知識は、今後も変わらず必要とされると考えられています。

デベロッパー – アソシエイトの知識がこれからも必要とされる理由

  1. AIは開発者の「ツール」:AIは、コードのテストや、デプロイの一部を自動化してくれる強力なツールとなり得ます。しかし、そのAIを開発プロセスに組み込み、運用・管理し、AIが生成したコードをレビューして修正するのは、依然として人間の専門家の仕事です。AIが進化すればするほど、そのAIをより良く活用するための、クラウド開発者である人間の役割はますます重要になります。
  2. システムの「設計者」としての役割:AIは単純なコード生成を自動化してくれるかもしれませんが、顧客の複雑なビジネス要件を深く理解し、最適なクラウドアーキテクチャを考えたり、予期せぬトラブルが発生した際に原因を特定して解決したりする「思考力」は、人間の専門家の役割です。
  3. 新しい技術への対応:クラウド技術や開発ツールは日々進化しており、新しいサービスや機能が常に登場します。そうした新しい技術に対し、柔軟に対応し、最適なアプリケーションを設計・構築するのは、人間の専門家であるクラウド開発者の役割です。
  4. AIの限界:AIは、あくまで過去のデータやベストプラクティスに基づいて学習します。そのため、予期せぬトラブルや、新しいタイプのビジネス要件に対して、AIが完璧に対応するのは難しい場合があります。そうした状況で、最終的な判断を下すのは人間の専門家です。

このように、AWS認定デベロッパー – アソシエイトの知識は、AI時代においても、ITインフラを支える上で不可欠な役割を担い続けるでしょう。AIの進化は、クラウドの仕事を奪うのではなく、むしろ私たちがより高度で創造的な仕事に集中できるような「強力なツール」として、私たちの仕事の仕方をより良いものに変えていくと考えられます。


 

まとめ

AWS認定デベロッパー – アソシエイトは、クラウドの分野でキャリアを築きたい方にとって、非常に価値のある国際的な資格です。

  • どのような資格?:AWS環境でアプリケーションを開発するスキルを証明する中級レベルの国際的な資格です。
  • 傾向は?:選択式の問題と、現実のビジネスシナリオに基づいた問題が組み合わされて出題されます。
  • 対策は?:公式教材や認定トレーニングを活用し、実際にAWS環境を触って、実践力を高めることが大切です。
  • 転職に有利?:はい、未経験者にとってはスキルをアピールする強力な武器となりますが、資格取得と合わせて実践的な経験を積むことも重要です。
  • 将来性は?:AI時代においても、クラウド開発者はITインフラを支える上で不可欠な存在であり、その需要は今後も安定していると考えられます。

もし、クラウドの世界に興味を持っていただけたのでしたら、ぜひこの資格を目標にしてみてください。ご自身の努力が形となり、自信となって、未来のキャリアを切り拓く力になるはずです。

AWS 認定デベロッパー –アソシエイト試験:予想問題(AI作成)

問題1

静的Webサイトを安全に配信し、独自ドメインでHTTPSを有効化したい。最小構成として最適なのはどれか。
A. S3静的ウェブサイト機能のみ
B. S3+ACM証明書をS3に直接適用
C. CloudFront+S3(バケットは非公開、OAC/OAI)+ACM+Route 53エイリアス
D. ALB+S3

回答

C

解説

S3単体ではHTTPSの独自ドメイン終端やWAF・キャッシュ最適化が不十分です。CloudFrontにACM証明書をアタッチし、オリジンにS3を設定、OAC/OAIでS3を非公開にします。Route 53のエイリアスで独自ドメインをCloudFrontに向けると、HTTPS・キャッシュ・セキュアなオリジン保護を同時に満たせます。


問題2

Lambda関数から同一VPC内のAmazon RDS(MySQL)に接続するとタイムアウトする。最も基本的な対処はどれか。
A. Lambdaのタイムアウト値だけ延長
B. LambdaをVPCに接続し、プライベートサブネットとRDSのSGを適切に設定
C. RDSをパブリックサブネットへ移動
D. Lambdaのメモリを増やす

回答

B

解説

RDSがプライベートサブネットにある場合、LambdaをVPCにアタッチしてENIを作成し、同一VPCのプライベートサブネットから接続させます。セキュリティグループでRDSのポート(例:3306)をLambdaのSGから許可することが必須です。タイムアウト延長やメモリ増加だけではネットワーク未接続問題は解決しません。


問題3

DynamoDBのホットパーティションが発生し、書き込みが偏っている。推奨される設計はどれか。
A. テーブルを複製してラウンドロビン
B. ソートキーのみを変更
C. パーティションキーの高カーディナリティ化やシャーディング(接尾辞付与)
D. RCU/WCUを無制限に増やす

回答

C

解説

DynamoDBはパーティションキーで分散します。アクセスが特定キーに集中するとスループットが頭打ちになります。キー設計を見直し、高カーディナリティなパーティションキーや書き込みシャーディング(ランダム接尾辞)で均等化します。単純なスループット増強では偏りは解消されません。


問題4

メッセージの順序保証と重複排除が必要なキュー処理に最適なのはどれか。
A. SQS Standard
B. SQS FIFO(Content-Based Dedup+MessageGroupId)
C. SNSトピック
D. Kinesis Data Firehose

回答

B

解説

順序保証と重複排除はSQS FIFOキューが提供します。MessageGroupIdでグループ内順序を保証し、内容ベース重複排除で一定時間の重複を抑止できます。Standardは少量の重複や順不同が起き得るため要件に合致しません。SNSやFirehoseは別用途です。


問題5

API利用者ごとにスロットルやクォータを設定したい。最適な構成はどれか(Amazon API Gateway)。
A. ステージレベルの一律スロットルのみ
B. WAFでレート制限
C. Usage Plan+APIキーで利用者単位のレート・クォータ管理
D. Lambda側でsleepして調整

回答

C

解説

API GatewayのUsage PlanとAPIキーを使うと、クライアントごとにRate/Burstや月次クォータを分離して管理できます。ステージスロットルは全体制御のみ、WAFはIP単位中心で利用者識別には不向きです。アプリ側のsleepは不正確で全体最適になりません。


問題6

S3イベントで非同期起動されるLambdaが失敗した場合、失敗イベントを確実に保管したい。最適な方法はどれか。
A. Lambdaを同期呼び出しに変更
B. LambdaのDLQまたは非同期Destination(On-Failure)にSQS/SNSを設定
C. CloudWatch Logsだけ確認
D. リトライ回数を増やす

回答

B

解説

非同期実行の失敗を後で再処理するには、LambdaのDLQまたは非同期Destinationを設定して失敗イベントをSQSやSNSへ退避します。ログ出力のみではイベント内容を安全に保管できません。同期化はS3通知では想定外で、リトライ増加だけでは恒久的な保全になりません。


問題7

本番CloudFormationスタックの変更を適用前に差分を安全に確認したい。どれか。
A. drift検出
B. 変更セット(Change Set)
C. stack policyの削除
D. テンプレートのYAML→JSON変換

回答

B

解説

Change Setは適用予定の差分(作成・更新・削除)を事前に確認できる仕組みです。drift検出は実リソースとテンプレートの乖離検出であり、更新差分の事前プレビューには使いません。stack policy削除は危険で、形式変換は影響を示しません。


問題8

Gitプッシュで自動的にビルド、テスト、デプロイ(EC2/ASG)を行いたい。最もAWSネイティブな構成はどれか。
A. CodeCommit→CodeBuild→CodeDeploy→CodePipeline
B. GitHub→Jenkinsのみ
C. CloudFormationのみ
D. Elastic Beanstalk単体

回答

A

解説

継続的デリバリの王道はCodePipelineでのステージ連携です。ソースにCodeCommit、ビルドにCodeBuild、デプロイにCodeDeployを組み合わせると、イベント駆動で一連の自動化が実現します。Jenkinsなど外部でも可能ですが、AWS運用の統合性はAが高いです。


問題9

各開発者が自分のS3プレフィックス(例: user-name/)のみに書き込めるようにしたい。最適なIAMポリシー条件はどれか。
A. s3:ListAllMyBucketsのみ許可
B. リソースを*にしてPutObject許可
C. プレフィックスに${aws:username}を用いた条件付き許可
D. deny無しで全員にバケット完全権限

回答

C

解説

IAMのポリシー変数${aws:username}を使えば、オブジェクトキーの先頭がそのユーザー名に一致する場合のみPut/Getを許可できます。これにより一つのバケットを安全に共有し、フォルダ(擬似)単位で最小権限を実現できます。他の選択肢は権限過多か制御不能です。


問題10

アプリにユーザー認証(ソーシャルログイン含む)と、認証後に各ユーザー専用のS3アクセスを与えたい。適切な構成はどれか。
A. Cognito User Poolのみ
B. Cognito Identity Poolのみ
C. Cognito User Pool+Identity PoolでIAMロール連携
D. IAMユーザーを全員に発行

回答

C

解説

User Poolは認証・トークン発行を担い、Identity Poolは認証済みユーザーに一時的AWS認証情報を払い出します。これにIAMロールを紐づけ、S3アクセス権限をきめ細かく付与します。どちらか片方だけでは要件が不十分で、IAMユーザー発行は運用負荷とセキュリティ面で不適切です。


問題11

不安定な回線から大容量ファイルをS3へアップロードし、途中から再開したい。最適な方法はどれか。
A. 単一PUT
B. マルチパートアップロード(SDK)
C. S3転送アクセラレーションを無効化
D. S3イベント通知を無効化

回答

B

解説

マルチパートアップロードは大容量ファイルを分割して送信でき、途中で失敗しても一部だけ再送可能です。SDKが自動再試行や並列化を提供します。単一PUTは途中失敗時の再開ができません。転送アクセラレーションは高速化手段で再開性の要件とは別です。


問題12

Lambdaが生成する大容量ファイル(数百MB)をクライアントへダウンロードさせたい。API Gatewayのペイロード制限を回避する最適解はどれか。
A. API Gatewayから直接ストリーミング
B. Lambdaレスポンスでファイル本体を返す
C. S3に保存し、署名付きURLを返す
D. CloudWatch Logsに書いて取得

回答

C

解説

API GatewayやLambdaのペイロード制限を超える大容量配布は、S3へ出力した後に有効期限付きの署名付きURLを返すのが定石です。クライアントはS3から直接安全にダウンロードでき、スケーラブルです。ログ経由は用途外です。


問題13

有効期限切れセッションデータを自動的に削除したい(DynamoDB)。最適な機能はどれか。
A. TTL属性
B. DAX
C. Streams
D. Global Table

回答

A

解説

DynamoDBのTTLは指定時刻を過ぎたアイテムをバックグラウンドで自動削除します。セッション管理などに適し、コスト最適化にも寄与します。DAXはキャッシュ、Streamsは変更イベント、Global Tableは多リージョン複製で、要件とは異なります。


問題14

Lambdaのエラー発生を検知して通知したい。最小構成はどれか。
A. CloudWatch Logsに出力のみ
B. CloudWatchメトリクス(Errors)にアラームを設定しSNS通知
C. X-Rayのアノテーションだけ
D. EventBridgeのスケジュールで毎時確認

回答

B

解説

Lambdaは自動でErrorsメトリクスを出します。CloudWatchアラームをErrorsへ設定し、SNSへ通知すれば即座に検知できます。ログ閲覧や定期確認は遅延・運用負荷が大きく、X-Rayはトレース解析向けで通知用途ではありません。


問題15

分岐や再試行、バックオフを含む長時間のバッチ処理をノーサーバーで組みたい。最適なサービスはどれか。
A. Amazon MQ
B. Step Functions(Standard)
C. AWS Batchのみ
D. Lambda関数単体の再帰呼び出し

回答

B

解説

Step Functionsは状態遷移、条件分岐、エラーハンドリング、指数バックオフなどを定義可能です。Standardは長時間実行に向き、可視化や再実行もしやすいです。Batchはジョブ実行基盤、再帰Lambdaは監視・制御が難しく、MQはメッセージブローカです。


問題16

S3バケットにKMSで暗号化されたオブジェクトのみを許可したい。最適な方法はどれか。
A. バケットをパブリックにする
B. バケットポリシーでx-amz-server-side-encryption:aws:kmsを強制
C. IAMユーザーを全拒否
D. S3 Versioningを無効化

回答

B

解説

バケットポリシーで条件(aws:SecureTransportやs3:x-amz-server-side-encryption)を使い、SSE-KMSでの保存を強制します。これによりSSE-S3や暗号化なしのPutObjectを拒否できます。公開設定やバージョニングは暗号化強制の手段ではありません。


問題17

VPC内からインターネットに出ずにS3へアクセスし、帯域とセキュリティを最適化したい。最適な選択はどれか。
A. NAT Gateway経由
B. VPCエンドポイント(Gateway型 for S3)+バケットポリシーでvpce制限
C. インターネットゲートウェイ
D. パブリックサブネットにEC2を配置

回答

B

解説

S3にはGateway型のVPCエンドポイントを用い、通信をAWSネットワーク内に閉じます。バケットポリシーで特定VPCエンドポイントのみ許可するとセキュリティが向上します。NATは課金・経路面で非効率です。IGWやパブリック化は要件に反します。


問題18

複数テーブルに跨る書き込みをアトミックに実行したい(DynamoDB)。どれか。
A. BatchWriteItem
B. TransactWriteItems
C. PartiQLのINSERT
D. Streamsで後追い調整

回答

B

解説

TransactWriteItemsは最大25項目までの原子的な書き込みを提供し、全成功か全失敗を保証します。BatchWriteItemは部分失敗があり得ます。Streamsは整合調整の別解で、アトミック性は担保しません。PartiQLはクエリ表現であり、機能自体はトランザクションに依存します。


問題19

SQSで処理時間が長いワーカーがメッセージを処理中に他ワーカーへ渡ってしまう。主因と対策はどれか。
A. メッセージ保持期間が短い
B. 可視性タイムアウトが短い。処理時間に合わせて延長/変更する
C. 最大メッセージサイズ超過
D. 送信遅延が長い

回答

B

解説

SQSは可視性タイムアウト中に同一メッセージを他コンシューマへ渡しません。処理がタイムアウトを超えると再配信され重複処理の原因となります。ジョブ時間に応じて可視性を設定し、必要に応じChangeMessageVisibilityで動的に延長します。


問題20

S3の非公開コンテンツをCloudFront経由で限定公開したい。最適な仕組みはどれか。
A. バケットを公開しSigned URL
B. CloudFrontのSigned URL/Cookie+OAC/OAIでS3を非公開
C. S3静的ウェブサイトエンドポイントを公開
D. プレフィックスにACLを設定

回答

B

解説

配布制御はCloudFrontの署名付きURLまたはCookieを用い、オリジンはOAC/OAIでS3への直接アクセスを遮断します。これによりCloudFront経由でのみ認可配布できます。S3公開や古いACL運用はリスクが高く、要件に適しません。


問題21

LambdaからRDSへの接続数が急増し、DBが飽和する。推奨される対策はどれか。
A. Lambdaのタイムアウトを短縮
B. RDS Proxyを導入し、Lambdaの同時実行数を制御
C. RDSをパブリック化
D. CloudWatch Logsを削除

回答

B

解説

RDS Proxyは接続プールでDB接続を効率化し、スパイク時のコネクション枯渇を抑えます。加えてLambdaに予約/同時実行上限を設定してバックエンドを保護します。パブリック化は不要なリスク、ログ削除は根本対策になりません。タイムアウト短縮も症状悪化の恐れがあります。


問題22

API Gatewayで全体とメソッド個別のスロットリングを設定したい。どうするべきか。
A. ステージ設定とメソッド設定の両方でRate/Burstを設定
B. Lambdaで制御
C. VPC NACLで制限
D. S3バケットポリシーで制限

回答

A

解説

API Gatewayはステージとメソッド単位でスロットリングが可能です。ステージで全体枠を定義し、メソッドでより厳格な設定を上書きできます。バックエンドやネットワークACLでの制御はAPI呼び出し粒度の制御には適しません。


問題23

後から別属性での検索が必要になった。DynamoDBで最適なのはどれか。
A. LSI(作成後に追加可能)
B. GSI(後から追加可能、パーティションキー自由)
C. テーブルのフルスキャンのみ
D. テーブルをコピー

回答

B

解説

GSIはテーブル作成後でも追加でき、元テーブルと異なるパーティションキー・ソートキーを定義できます。LSIはテーブル作成時のみ定義可能です。フルスキャンはコスト高、テーブルコピーは運用負荷が増します。


問題24

Cognito User Poolを使うAPIで、バックエンドが受け取ったJWTを検証したい。適切な方法はどれか。
A. 毎回AdminGetUserで確認
B. JWT署名をCognitoのJWKで検証し、iss/aud/exp等のクレームも検査
C. 秘密鍵をCognitoから取得
D. 一切検証せず信頼

回答

B

解説

JWTは公開鍵で署名検証できます。CognitoのJWKセットをキャッシュして署名検証し、発行者(iss)、クライアントID(aud)、有効期限(exp)などのクレームを確認します。APIコールで都度確認する必要はなく、秘密鍵は取得できません。


問題25

SQSで一定回数処理に失敗したメッセージを隔離したい。どう設定するか。
A. メッセージ保持期間を延長
B. Redrive policyでDLQとmaxReceiveCountを設定
C. VisibilityTimeoutを0に
D. DelaySecondsを最大化

回答

B

解説

Redrive policyで再受信回数が閾値を超えたメッセージをDLQへ移動できます。これにより壊れたメッセージを本流から切り離し、後で検査・修正が可能です。保持期間や遅延は隔離とは無関係、可視性を0にすると直ちに再配信され逆効果です。


問題26

分散トレーシングでサービス間遅延のボトルネックを特定したい(Lambda+API Gateway+DynamoDB)。最適なのはどれか。
A. CloudWatch Logsのみ
B. AWS X-Rayのアクティブトレーシングを有効化
C. S3アクセスログ
D. VPC Flow Logs

回答

B

解説

X-Rayは分散トレースを可視化し、各区間のレイテンシやエラーをセグメントとして確認できます。Lambda・API Gateway・DynamoDB SDKを統合して、末端までの経路を把握します。ログ単体やVPCフローではアプリ層の因果は見えにくいです。


問題27

アプリがDB資格情報をコードにハードコードしている。改善として最適なのはどれか。
A. 環境変数に平文配置
B. AWS Secrets Managerで保管し、自動ローテーション
C. S3に暗号化して保存
D. Parameter Storeのプレーンテキスト

回答

B

解説

Secrets Managerはシークレット管理と自動ローテーションを提供し、RDS等はテンプレートで容易に回転できます。アプリは取得時にのみ参照し、平文保持を避けます。S3や平文Parameter Storeは秘匿性・回転運用に不向きです。


問題28

アプリの設定値(非機密)を構成管理したい。コストを抑えたい場合の適切な選択はどれか。
A. Secrets Manager
B. Systems Manager Parameter Store(標準パラメータ)
C. DynamoDB
D. CloudHSM

回答

B

解説

非機密の設定はParameter Storeの標準パラメータで十分です。階層化やバージョン管理が可能で、コスト効率も良好です。Secrets Managerは機密向け、DynamoDBは用途過剰、CloudHSMは鍵管理ハードウェアで要件外です。


問題29

Fargateタスクを毎日0時に1回だけ実行したい。最適な方法はどれか。
A. Lambdaからrun-taskを手動実行
B. EventBridgeスケジュールでECS RunTaskターゲット
C. CodeDeployでスケジュール
D. Auto Scalingでスケジュール

回答

B

解説

EventBridgeのスケジュールルールでcronを設定し、ターゲットにECS RunTaskを指定するとFargateタスクを定期起動できます。Lambda経由は不要な中継です。CodeDeployやASGは別目的です。


問題30

大量のログから「ERROR」行の件数を即席で可視化したい(短時間)。適切な機能はどれか。
A. CloudWatch Logs Insightsのクエリ
B. S3へエクスポート後Athena
C. ElastiCacheへ送る
D. CloudTrailで検索

回答

A

解説

Logs InsightsはCloudWatch Logs上のデータに対して即時クエリが可能で、集計・集約・可視化が行えます。S3へ出してAthenaで解析も可能ですが即席用途では冗長です。CloudTrailは監査ログで範囲が異なります。


問題31

API Gatewayを独自ドメインで公開し、ステージ毎に異なるバックエンドへルーティングしたい。適切な方法はどれか。
A. ステージURLのみ使用
B. カスタムドメイン+ベースパスマッピング
C. ELB経由で転送
D. Route 53でCNAMEをLambdaへ

回答

B

解説

API Gatewayのカスタムドメインに対し、ベースパスマッピングで/dev、/prodなどを各ステージやAPIに割り当てます。ELBやLambda直参照は不適切です。ステージURLのみではドメイン統一ができません。


問題32

複数スタックで共有する値(例: VPCのID)を安全に参照したい。CloudFormationの推奨手段はどれか。
A. パラメータを手入力
B. スタック出力をExportし、ImportValueで参照
C. S3に書いて読み込み
D. cfn-initで環境変数に出力

回答

B

解説

CloudFormationのExport/ImportValueを使うと、プロデューサースタックの出力を他スタックが参照できます。人手入力やS3ファイルは誤りの原因となり、cfn-initはEC2内設定でスタック間共有には向きません。


問題33

複数のLambdaで共通ライブラリ(SDK拡張)を使う。最適な配布方法はどれか。
A. すべての関数ZIPに個別バンドル
B. Lambdaレイヤーにして共有
C. S3に置いて実行時ダウンロード
D. EFSに置く

回答

B

解説

Lambdaレイヤーは共通コードや依存を複数関数で共有でき、デプロイ効率・一貫性を向上します。個別バンドルは重複とサイズ増を招きます。実行時ダウンロードはコールドスタートや可用性の懸念、EFSは継続読み書き用途で過剰です。


問題34

Lambdaの環境変数に機密値を保存したい。最も安全な設定はどれか。
A. 平文のまま設定
B. KMSカスタマー管理キーで暗号化を有効化
C. Base64で符号化
D. CloudWatch Logsに出力

回答

B

解説

Lambda環境変数はKMSで暗号化できます。カスタマー管理キー(CMK)を指定し、必要最小限の復号権限を実行ロールへ付与します。Base64は暗号ではなく、平文やログ出力は漏えいリスクです。


問題35

DynamoDB StreamsからLambdaで書き込み処理を行う。重複実行に備えた設計はどれか。
A. 重複は起こらない前提
B. アイドポテンシーキー(例:イベントID)で条件付き書き込み
C. 可視性タイムアウトを調整
D. TTLで防ぐ

回答

B

解説

StreamsのLambdaは少なくとも1回配信(at-least-once)で重複があり得ます。処理側で一意キーを用いた条件付き書き込みや、処理済みトラッキングを実装して冪等性を担保します。TTLや可視性は別機能です。


問題36

ブラウザからAPI Gatewayを呼ぶ際にCORSエラーが出る。基本対処はどれか。
A. CloudFrontを外す
B. OPTIONSメソッドとCORSレスポンスヘッダを有効化
C. APIをプライベート化
D. Lambdaメモリを増やす

回答

B

解説

CORSではプリフライト(OPTIONS)応答にAccess-Control-Allow-*ヘッダが必須です。API GatewayのCORS有効化またはカスタム統合で適切なヘッダを返す設定を行います。他の選択肢はCORS問題の解決になりません。


問題37

APIの5XXエラー率が増えたら通知したい(API Gateway)。最適な手段はどれか。
A. CloudTrailで検出
B. API Gatewayメトリクスの5XXErrorにCloudWatchアラーム
C. LambdaのErrorsメトリクス
D. S3イベント通知

回答

B

解説

API Gatewayは5XXErrorや4XXErrorなどのメトリクスを出力します。CloudWatchアラームを5XXErrorや整形した割合(アナリティクス活用)に設定してSNS通知すれば早期検知が可能です。CloudTrailはAPI操作監査で用途が違います。


問題38

Lambdaをコンテナイメージで配布したい。正しい手順はどれか。
A. Docker Hubへpushすれば自動検出
B. ECRにイメージをpushし、Lambdaで「コンテナイメージ」を選択
C. S3にzipでアップロード
D. CodeDeployでEC2に配布

回答

B

解説

Lambdaは最大10GBのコンテナイメージをECRから取得できます。Dockerでビルド→ECRへpush→Lambda関数でコンテナイメージ指定、という流れです。Docker Hubは直接参照できません。S3はZIPパッケージ用です。


問題39

別アカウントのアプリから自アカウントのS3バケットへ書き込みさせたい。適切な設計はどれか。
A. バケットを公開
B. 相手アカウントのロールに権限を付け、バケットポリシーでそのロールを許可
C. ACLで全員書き込み
D. 署名付きURLを常時発行

回答

B

解説

クロスアカウントでは、相手側にAssumeRoleで取得するロールを用意し、こちらのバケットポリシーでそのロールのプリンシパルを許可します。公開やACL全許可は危険です。署名付きURLは一時的配布には有効ですが恒常運用には不向きです。


問題40

APIで独自の認証ロジック(社内既存トークン)を使いたい。API Gatewayの適切な選択はどれか。
A. IAM認証のみ
B. Cognito Authorizerのみ
C. Lambda Authorizer
D. 認証なし

回答

C

解説

CognitoはOpenID Connect/社外IdP連携に最適ですが、独自トークン検証や複雑なヘッダ認可はLambda Authorizerが適しています。Authorizer関数でトークン検証し、IAMポリシーを返してAPIアクセスを制御します。


問題41

トラフィックが読めないが、DynamoDBでスループット管理を簡素化したい。最適な課金モードはどれか。
A. プロビジョンド+Auto Scalingなし
B. プロビジョンド+Auto Scaling
C. オンデマンド(Pay-Per-Request)
D. 手動で都度変更

回答

C

解説

オンデマンドモードはトラフィックに応じ自動でスループットを調整し、予測が難しいワークロードに向きます。プロビジョンドは安定パターンに適しますが、急なスパイクには追従しにくい場合があります。手動変更は運用負荷が高いです。


問題42

読み取りが非常に多いレイテンシ重視のワークロード(書き込みは少量)。DynamoDBの最適化はどれか。
A. DAXを導入(最終的整合性でキャッシュ)
B. LSIを追加
C. Streamsで複製
D. TTLを設定

回答

A

解説

DAXはDynamoDB専用のインメモリキャッシュで、マイクロ秒オーダーの読み取りを提供します。書き込みはDynamoDBへ流れます。強整合が必須なら要検討ですが、レイテンシ重視・読み取り多のパターンで効果が高いです。他選択肢は要件に直結しません。


問題43

古いログをコスト最適化のため自動でアーカイブしたい(S3)。最適な方法はどれか。
A. 手動でコピー
B. ライフサイクルルールでIAやGlacierへ移行
C. バージョニング無効化
D. ACL変更

回答

B

解説

S3ライフサイクルルールを設定すれば、オブジェクトの経過日数に応じてStandard-IAやGlacier系ストレージへ自動移行・削除が行えます。手動運用はミスと工数の元です。バージョニングやACLはアーカイブ方針と直接関係しません。


問題44

大量のファイル一括配信で、個別URLを発行せずに特定ユーザーだけに期間限定で閲覧を許可したい(CloudFront)。適切な手段はどれか。
A. 署名付きURL
B. 署名付きCookie
C. S3の公開URL
D. API Gateway経由

回答

B

解説

署名付きCookieは複数オブジェクトへの一括アクセス制御に向き、ユーザーのブラウザへCookieを配布するだけで広範なパスに対する期限付きアクセスを付与できます。署名付きURLは単一オブジェクト向けで大量配布に不向きです。


問題45

Lambdaに最低限必要なログ出力権限を与えたい。もっとも適切なマネージドポリシーはどれか。
A. AmazonS3FullAccess
B. AWSLambdaBasicExecutionRole
C. AWSLambdaReadOnlyAccess
D. CloudWatchFullAccess

回答

B

解説

AWSLambdaBasicExecutionRoleはCloudWatch Logsへのログ作成・出力権限を含む最小セットです。S3フルやCloudWatchフルは過剰で、ReadOnlyはログ作成ができません。最小権限の原則に合致します。


問題46

S3アクセスログを集計して、どのオブジェクトが最も読まれているかを分析したい。最も簡便な方法はどれか。
A. アクセスログをAthenaでクエリ
B. CloudTrailで閲覧回数を確認
C. DynamoDBへ取り込み
D. Lambdaで都度パースして出力

回答

A

解説

S3サーバーアクセスログやCloudFrontログはAthenaでスキーマ定義するだけでクエリ可能です。SQLで集計・ランキングを手早く実現できます。CloudTrailはAPI操作監査で粒度が異なり、都度Lambdaは運用が重くなります。


問題47

EC2にデプロイするWebアプリでダウンタイム最小のデプロイ方式を選びたい(CodeDeploy)。どれか。
A. In-place
B. Blue/Green(別Auto Scalingグループ)
C. 手動コピー
D. 単一EC2へ上書き

回答

B

解説

Blue/Greenは新環境を別途用意し、ヘルス検査後にトラフィックを切り替えるため、ロールバックも迅速でダウンタイムを最小化できます。In-placeは同一インスタンス更新で停止が発生しやすいです。手動はリスクが高いです。


問題48

新旧Lambdaバージョンへのトラフィックを段階的に切り替えたい。適切な仕組みはどれか。
A. 関数名を毎回変える
B. エイリアスのWeighted Routingで割合を調整
C. API Gatewayのステージを削除
D. Route 53でAレコードを分割

回答

B

解説

Lambdaのエイリアスは特定バージョンへ名前を固定し、ウェイト付きで複数バージョンへ振り分け可能です。段階的リリースや自動ロールバックと相性が良いです。関数名変更やDNS分割は運用が煩雑です。


問題49

AWS SDKで外部API呼び出しの失敗に耐性を持たせたい。基本原則として正しいのはどれか。
A. リトライしない
B. 一定間隔で固定リトライ
C. エクスポネンシャルバックオフ+ジッタで再試行
D. 無限リトライ

回答

C

解説

指数バックオフとジッタ(揺らぎ)は同時に多数が再試行する「スロースタート問題」を緩和します。SDKは多くがデフォルトで実装しており、適切な最大試行回数・タイムアウトと組み合わせて堅牢化します。固定間隔や無限リトライは輻輳や待機時間の問題を招きます。


問題50

SNSでメール通知とモバイルプッシュ通知を同時に届けたい。最小構成はどれか。
A. 2つのトピックを作る
B. 1つのトピックに複数サブスクリプション(Email、モバイルエンドポイント)
C. SQS経由のみ
D. CloudWatch Eventsのみ

回答

B

解説

SNSは単一トピックに対して複数のサブスクリプションを設定できます。メール、HTTP、SQS、モバイルプッシュなどを同時に紐付ければ、同一Publishで複数チャネルへ配信されます。トピック分割は必須ではありません。


問題51

同一パーティションキーにアクセスが集中するワークロードで、読み取りだけ高速化したい。最も簡便な対策はどれか。
A. GSI追加
B. DAX導入
C. テーブル分割
D. TTL設定

回答

B

解説

ホットパーティションに対してもDAXはキャッシュのヒット率が高ければレイテンシを大幅に下げられます。GSIは別のアクセスパターン用で同じ偏りなら同様の問題が残ります。TTLは削除用、テーブル分割は運用が重いです。


問題52

Lambdaのコールドスタートを低減したい。最適な設定はどれか。
A. タイムアウトを増やす
B. プロビジョンドコンカレンシーを有効化
C. メモリを減らす
D. リージョンを頻繁に変える

回答

B

解説

プロビジョンドコンカレンシーはあらかじめ実行環境を起動しておくため、呼び出し時のコールドスタートを削減できます。メモリ削減は逆効果のことが多く、タイムアウトやリージョン変更は根本対策になりません。


問題53

API GatewayからのLambda統合で、バックエンドの過負荷を防ぎたい。推奨の組み合わせはどれか。
A. スロットリングなし
B. API Gatewayのスロットリング+Lambda同時実行上限
C. VPC NACL調整
D. SDKのリトライ無効化

回答

B

解説

入口でのレート制御(API Gateway)とバックエンドの処理並列数制御(Lambda同時実行)を併用するのが効果的です。NACLはIP/ポートレベルでアプリ負荷制御には不向きです。リトライ無効化は可用性を下げます。


問題54

S3へ直接書き込ませずに、アプリサーバーを介さずクライアントから安全にアップロードしたい。最適な方法はどれか。
A. バケットを公開
B. 署名付きURL(PUT)を発行
C. IAMユーザー鍵を配布
D. CloudFront経由でPOST

回答

B

解説

署名付きURLを使えば、限定時間・限定権限でクライアントがS3へ直接アップロードできます。アプリは署名発行のみ行うためスケールし、鍵の配布不要です。公開は危険、CloudFrontは通常アップロードに向きません。


問題55

EventBridgeのcron式の時刻基準はどれか。
A. ローカルタイムゾーン
B. UTC
C. JST固定
D. ACMの設定による

回答

B

解説

EventBridge(旧CloudWatch Events)のスケジュール式はUTC基準です。日本時間で指定したい場合はUTCへの換算が必要です。タイムゾーン指定はルール側で直接はできないため、計算を誤ると意図せぬ時刻に実行されます。


問題56

API GatewayのバックエンドとしてLambda以外のHTTPエンドポイントを接続したい。適切な統合タイプはどれか。
A. MOCK
B. HTTP/HTTP Proxy統合
C. AWS統合
D. VPCリンク不要

回答

B

解説

外部も含むHTTPエンドポイントにはHTTP統合(またはProxy)を使います。VPC内のALB/NLBに繋ぐ場合はVPCリンクを併用します。MOCKはバックエンドなしの固定応答用、AWS統合は他AWSサービスAPI用です。


問題57

Step Functionsで一部のステップだけ並列に実行したい。適切なステートはどれか。
A. Wait
B. Choice
C. Parallel
D. Pass

回答

C

解説

Parallelステートはブランチを並列実行し、全ブランチ完了を待って次へ進めます。Choiceは条件分岐、Waitは待機、Passはデータ加工やテスト用です。並列化は可観測性と失敗時のロールバック設計にも関係するため、可視化が重要です。


問題58

API Gatewayでリクエスト/レスポンスの変換を行いたい(ヘッダや本文のマッピング)。適切な機能はどれか。
A. ステージ変数
B. マッピングテンプレート(VTL)
C. Usage Plan
D. CloudFrontレスポンスヘッダー

回答

B

解説

REST APIではVelocity Template Language(VTL)によるマッピングテンプレートで、入力検証やヘッダ・ペイロード変換が可能です。ステージ変数はエンドポイントや設定の切替用、Usage Planは課金・スロットル、CloudFront設定は配信側です。


問題59

Lambdaが外部APIへアクセスするたびにDNS解決コストが高い。改善策として適切なのはどれか。
A. 関数を毎回終了
B. コネクション/クライアントをグローバルスコープにキャッシュ
C. タイムアウトを短縮
D. メモリを最小

回答

B

解説

Lambdaの実行環境は再利用されるため、HTTPクライアントやDBコネクションをグローバルに保持するとDNS解決やTLS確立のオーバーヘッドを削減できます。毎回初期化するとレイテンシが増えます。タイムアウトやメモリだけでは根本解決しません。


問題60

API Gateway+Lambdaで、1リクエストの処理が下流で必ず一度だけ行われることを保証したい。基本方針はどれか。
A. 保障不要
B. クライアントが再送しない前提
C. リクエストIDで冪等性を実装(重複は無害化)
D. Lambdaの同時実行を1に

回答

C

解説

ネットワーク障害などでクライアント再送や重複実行は起こり得ます。アプリ側でリクエストIDを用い、重複登録を避ける条件付き書き込みや処理済み記録を実装して冪等性を確保します。同時実行を1にするのはスケーラビリティを損ないます。

問題61

API GatewayのREST APIでリクエスト本文のスキーマ検証を行い、無効な入力はバックエンドへ到達させたくない。最適な機能はどれか。
A. Usage Plan
B. リクエストバリデーション(モデル+メソッド設定)
C. ステージ変数
D. CloudFrontレスポンスヘッダ

回答

B

解説

REST APIはモデル(JSONスキーマ相当)を定義し、メソッド側で「本文とパラメータの検証」を有効化できます。これにより不正入力はAPI Gateway段階で400系として拒否され、バックエンドは不要な負荷を負いません。Usage Planやステージ変数は検証用途ではありません。


問題62

LambdaでJavaを使用しておりコールドスタートが目立つ。手軽に初期化時間を短縮したい。適切な選択はどれか。
A. メモリを最小にする
B. SnapStartを有効化(対応ランタイム)
C. タイムアウトを短縮
D. 並列実行を減らす

回答

B

解説

Javaランタイムでは初期化が重くなりやすいため、対応ランタイムならSnapStartで初期化後の状態をスナップショット化し、起動を高速化できます。メモリ削減やタイムアウト短縮は性能を悪化させる恐れがあります。並列数の抑制は根本対策になりません。


問題63

S3のオブジェクト更新イベントを順序どおり処理し、かつ重複を抑えたい。要件に最も合致するのはどれか。
A. S3→SQS Standard→Lambda
B. S3→SQS FIFO→Lambda(メッセージグループをキーで分離)
C. S3→SNS→Lambda
D. S3→EventBridge→複数Lambda

回答

B

解説

順序保証と重複抑止にはSQS FIFOが適します。オブジェクトキーやバケット名などでMessageGroupIdを決めると、同一キー系列の順序が守られます。StandardやSNSでは順序が保証されず、EventBridgeで並列に投げると順序要件を満たしにくくなります。


問題64

CodeBuildで環境変数に機密を渡したい。最適な方法はどれか。
A. buildspec.ymlに平文で記載
B. Parameter Store SecureStringやSecrets Managerの参照を使用
C. S3に暗号化せず保存
D. CodePipelineのアーティファクトに含める

回答

B

解説

CodeBuildの環境変数はParameter Store SecureStringやSecrets Managerから安全に参照できます。ビルド時に解決され、平文の露出を避けられます。平文記載や暗号化なしS3は漏えいリスクが高く、アーティファクト同梱も不要な拡散につながります。


問題65

DynamoDBで強い整合性が不要な高スループット読取をグローバルに配布したい。コストと遅延を最適化する選択はどれか。
A. 強整合のGetItemを多リージョンから直接
B. 最終的整合のQueryを採用し、DAXやキャッシュを併用
C. 常にトランザクション読み取り
D. Streamsで常時複製して各地で強整合

回答

B

解説

強整合は同リージョン内でのみ提供され、コストも高くなります。グローバル配布では最終的整合を前提に、DAXやアプリケーションキャッシュでレイテンシを下げるのが定石です。トランザクションは必要時のみで、常時使用は非効率です。


問題66

API GatewayのHTTP APIでJWT認可を簡潔に行いたい。最適な構成はどれか。
A. Lambda Authorizerのみ
B. JWTオーソライザー(OpenID Connect/JWK指定)
C. IAM署名必須
D. 認証なし

回答

B

解説

HTTP APIはネイティブのJWTオーソライザーを提供し、JWKで署名検証を行えます。設定が軽量で遅延も小さいのが利点です。独自検証が必要な場合のみLambda Authorizerを選びます。IAMは用途が異なり、無認証は要件を満たしません。


問題67

長時間実行のECSバッチをStep Functionsから起動し、失敗時に自動リトライとアラートを行いたい。最適な組み合わせはどれか。
A. Step Functions Standard+Retry指定+失敗でSNS通知
B. Lambdaでループ実装
C. EventBridgeのみ
D. CloudWatch Logsのみ

回答

A

解説

Step Functions Standardは長時間のオーケストレーションに向き、RetryやCatchで指数バックオフ、上限回数などを定義できます。失敗ハンドラでSNSやEventBridgeへ送れば通知が可能です。ループ実装は可読性と信頼性に劣ります。


問題68

Cognito User Poolで多要素認証を導入する。ユーザー体験と運用のバランスが良い選択はどれか。
A. 常にMFA必須(SMSのみ)
B. アダプティブMFA(リスクベース)やTOTPを併用
C. 一切MFAなし
D. メール認証をMFA代替とする

回答

B

解説

User PoolはTOTPやSMSのMFAを提供し、リスクベースMFAと組み合わせると利便性とセキュリティを両立できます。常時SMSはコストやUXの課題があり、MFAなしやメールで代替は要件を満たしません。TOTPはコスト効率と安全性の面で有利です。


問題69

CloudFormationで本番リソースの誤削除を防ぎたい。推奨の仕組みはどれか。
A. スタックポリシーを設定し、重要リソースへの更新/削除を保護
B. 変更セットを使わない
C. テンプレートを分割しない
D. すべて手動デプロイ

回答

A

解説

Stack Policyは特定の論理リソースに対する更新や削除をブロックできます。変更セットと併用すれば安全性が高まります。分割や手動運用は保護の仕組みではなく、変更セットを避けるのはリスク増大につながります。


問題70

アプリ設定を動的に切り替えたい。安全に段階展開や自動ロールバックが可能なマネージド機能はどれか。
A. SSM Parameter Storeのみ
B. AWS AppConfig
C. S3プレーンファイル
D. CloudFrontヘッダのみ

回答

B

解説

AppConfigは設定のバージョン管理、バリデーション、段階ロールアウト、メトリクス連動ロールバックなどを提供する設定のデリバリサービスです。Parameter StoreやS3は保管には使えますが、安全な展開制御は自前実装が必要になります。


問題71

API GatewayでWebSocket APIを構築し、接続中のクライアントにサーバーからプッシュしたい。コアとなるサービスはどれか。
A. SNS
B. DynamoDB Streams
C. API Gatewayの管理用エンドポイント(@connections)
D. S3イベント

回答

C

解説

WebSocket APIは接続IDを保持し、管理APIの@connectionsエンドポイントを使ってサーバー側から特定クライアントへプッシュできます。SNS等は通知基盤ですがWebSocketの直接プッシュではありません。接続IDの寿命管理も重要です。


問題72

ECRのイメージを複数アカウントで共有したい。もっとも適切な方法はどれか。
A. イメージをS3へコピー
B. ECRリポジトリポリシーで他アカウントを許可
C. すべてDocker Hubへ公開
D. EC2キーペアを共有

回答

B

解説

ECRはリポジトリポリシーで他アカウントのプル/プッシュを許可できます。必要に応じてリソースベースポリシーとIAMを組み合わせます。S3や外部公開は不要で、キーペア共有は無関係かつ危険です。


問題73

LambdaからVPC内のElastiCache for Redisへ接続したい。基本的な前提はどれか。
A. LambdaはVPC外固定
B. LambdaをVPCに接続し、適切なサブネットとSGを設定
C. Redisをパブリック化
D. NAT Gateway必須

回答

B

解説

VPC内リソースへ到達するには、LambdaをVPCにアタッチし、プライベートサブネットとセキュリティグループを正しく設定します。Redisのパブリック化は不可で、NATは外向き通信が必要な場合のみです。SGで双方向を最小権限にします。


問題74

API GatewayのREST APIでステージごとに環境変数のような値を切り替えたい。適切な仕組みはどれか。
A. ステージ変数
B. マッピングテンプレート
C. Usage Plan
D. Lambdaレイヤー

回答

A

解説

ステージ変数はエンドポイントURLや認証キー、フラグなどをステージ単位で切り替える用途に適します。マッピングテンプレートは変換、Usage Planはスロットルやクォータ、レイヤーはコード共有であり、目的が異なります。


問題75

DynamoDBでアクセスパターン別に項目を分割管理したい。最も適切な設計はどれか。
A. マルチテーブル戦略(アクセスパターンでテーブル分割)
B. 常に単一テーブルに集約
C. LSIを大量追加
D. 手動で日次コピー

回答

A

解説

アクセスパターンが大きく異なり、スキーマやスループット要件が分かれる場合、マルチテーブル戦略が有効です。単一テーブルは設計が複雑化しやすく、LSIの乱立は制約が厳しいです。日次コピーは運用負荷が高く整合も崩れます。


問題76

API GatewayのHTTP APIでCORS対応を最小手間で有効化したい。最適な設定はどれか。
A. 任意のヘッダをLambdaで返す
B. HTTP APIのCORS簡易設定で許可オリジン等を指定
C. CloudFrontのレスポンスヘッダポリシー
D. NACLで許可

回答

B

解説

HTTP APIはCORS専用の簡易設定があり、オリジンやメソッド、ヘッダ、資格情報の扱いを宣言的に構成できます。Lambda実装は柔軟ですが手間が増えます。CloudFrontやNACLはAPIのCORS制御の本質ではありません。


問題77

CodeDeployのBlue/Greenで段階的にトラフィックを新環境へ移したい。利用する機能はどれか。
A. Weighted Routing(トラフィックシフト)
B. すべて一気に切替
C. インプレースで停止
D. Route 53手動更新のみ

回答

A

解説

CodeDeployはALB/NLB連携でトラフィックシフトを提供し、パーセンテージや時間ベースで段階的に切替できます。ヘルスチェックと連動した自動ロールバックも可能です。手動DNS更新や一括切替はリスクが高くなります。


問題78

CloudWatch Logsから特定のエラーパターン検知で自動通知したい。最適な構成はどれか。
A. Logs Insightsで手動
B. メトリクスフィルター+アラーム+SNS
C. S3へエクスポートのみ
D. EventBridgeスケジュールで毎時確認

回答

B

解説

特定文字列や正規表現でメトリクスフィルターを作り、しきい値に基づいてCloudWatchアラームを設定、SNSで通知します。手動確認や定期ポーリングは遅延が大きく、エクスポートだけでは検知ができません。


問題79

AppSyncで複数データソースを統合するGraphQL APIを作成したい。認証はCognito、認可は細粒度に行いたい。適切なアプローチはどれか。
A. APIキーのみ
B. Cognito User Pool認証+ResolverでVTL/パイプラインの権限チェック
C. 認証なし
D. S3署名付きURLだけ

回答

B

解説

AppSyncはCognitoによる認証をサポートし、リゾルバ(VTLやパイプライン)やGraphQLディレクティブで属性ベースの認可を実装可能です。APIキーは開発用途に限定され、認証なしは要件に反します。S3署名URLは別目的です。


問題80

Lambdaで一時的に大容量の中間ファイルを扱う必要がある。適切な保存先はどれか。
A. /tmp(512MB〜10GB範囲、設定に依存)を利用
B. 関数コードに含める
C. CloudWatch Logs
D. 環境変数

回答

A

解説

Lambdaの実行環境には/tmpの一時ストレージがあり、設定で容量を拡張できます。関数コードや環境変数はファイル保存場所ではありません。ログはテキスト出力用であり、バイナリや大容量の中間データ格納には不向きです。


問題81

S3静的サイトで国別に別コンテンツを返したい。最も簡易な構成はどれか。
A. 複数バケットへDNS分割
B. CloudFrontのジオ制御+オリジンリクエストポリシーで国コードを渡しLambda@Edge/Functionsで分岐
C. Route 53の地理的ルーティングのみ
D. ALBでUser-Agent判定

回答

B

解説

CloudFrontはGeo情報を持ち、Lambda@EdgeまたはCloudFront Functionsで国コードに応じたパス書換やオリジン振り分けが可能です。DNSのみでは細かな分岐とキャッシュ制御が難しく、ALBは静的配信に過剰です。


問題82

開発者が誤ってS3に公開権限を付与しないよう、予防と検出の両面で対策したい。適切な組み合わせはどれか。
A. パブリックアクセスブロック+アクセスポイント必須化
B. パブリックアクセスブロック+Configルールで検出
C. ACLで全拒否
D. CloudTrail停止

回答

B

解説

S3のパブリックアクセスブロックで公開設定自体を抑止し、さらにAWS Configのマネージドルール(s3-bucket-public-read-prohibited等)で逸脱検出を行うと二重に安全です。ACL全拒否は管理が煩雑で、監査停止は論外です。


問題83

Kinesis Data Streamsでレコードを順序通り処理しつつスケールさせたい。正しい設計はどれか。
A. シャード数を1に固定
B. パーティションキーを適切に分散し、必要に応じてシャードをスケール
C. 全レコードを同一キーにする
D. レコードサイズを倍増

回答

B

解説

Kinesisはパーティションキーに基づきシャードに分配し、シャード内では順序が保たれます。キー設計で分散を確保し、スループットに応じてシャードを増減します。同一キー集中はスループットの瓶頸となり、サイズ増は関係しません。


問題84

API GatewayからSQSへ直接投入し、バックエンドを疎結合にしたい。最適な統合はどれか。
A. AWSサービス統合(SQS SendMessage)
B. Lambda経由必須
C. HTTP統合
D. SNSへPublishのみ

回答

A

解説

REST APIはAWSサービス統合を用いて、IAMロールで権限付与しつつSQSへの送信を直接実行できます。Lambdaを経由しないため遅延とコストを削減できます。HTTP統合やSNSのみではキュー要件を満たしません。


問題85

ECS Fargateサービスでゼロダウンタイムのデプロイを行いたい。推奨の設定はどれか。
A. Rolling updateで最小/最大健康割合を指定
B. 常にタスク1つのみ
C. 手動で停止→起動
D. ターゲット追跡スケーリングを無効化

回答

A

解説

Fargateのローリング更新は最小健康割合や最大割合を調整して並行起動・切替を制御できます。ALBヘルスチェックと組み合わせると無停止に近いデプロイが可能です。単一タスクや手動停止は可用性低下につながります。


問題86

CodePipelineで手動承認後に本番デプロイしたい。適切なステージ構成はどれか。
A. Source→Deployのみ
B. Source→Build→手動承認→Deploy
C. 手動承認を最初に置く
D. すべて自動

回答

B

解説

ビルド・テスト結果を確認してから本番リリースするため、Buildの後にManual Approvalアクションを置くのが一般的です。承認前に成果物を確定させ、監査ログも残せます。承認なしや順序不適切では統制が弱まります。


問題87

DynamoDBでアイテムが存在する時だけ更新したい。適切な方法はどれか。
A. 無条件UpdateItem
B. 条件式(attribute_exists)付きUpdateItem
C. PutItem上書き
D. Scan後に判断

回答

B

解説

条件式を用いるとアイテム存在時のみ更新を行い、競合時は条件不一致で失敗させられます。これにより外部整合のための余分な読み取りを避け、原子的に制御できます。無条件更新やScanは非効率で競合に弱いです。


問題88

API Gatewayでバックエンドのレスポンスに標準ヘッダを一律付与したい。最適な手段はどれか。
A. レスポンスマッピングテンプレートまたは集約レスポンス設定
B. ステージ変数
C. Usage Plan
D. RDS Proxy

回答

A

解説

REST APIなら統合レスポンスやメソッドレスポンスでマッピングテンプレートを使い、HTTP APIならレスポンスヘッダマッピングで一律付与できます。ステージ変数やUsage Planは用途が異なります。RDS ProxyはDB接続制御です。


問題89

AmplifyでホスティングしたSPAをAPI Gatewayと連携する。APIエンドポイントは環境毎に切り替えたい。簡便な方法はどれか。
A. コードにURLを直書き
B. Amplifyの環境変数やビルド時置換
C. Route 53を毎回更新
D. Lambdaを増設

回答

B

解説

Amplifyのビルド時環境変数や設定ファイル置換で、ステージごとのAPI URLを注入できます。直書きは再ビルドが必要でリスクが高く、DNSやLambda増設は本質的な解決策ではありません。環境毎の自動化が運用に有利です。


問題90

Lambda実行ロールの権限を最小に保ちたい。設計上の基本原則として正しいのはどれか。
A. *で全許可
B. 必要なアクションとリソースを限定し、条件でさらなる絞り込み
C. すべて拒否
D. 管理者権限を付けて速やかに開発

回答

B

解説

最小権限の原則では、必要なアクションと対象リソースを厳密に指定し、可能なら条件(aws:SourceArn、VPCエンドポイント、暗号化コンテキスト等)で絞り込みます。広範許可や管理者付与はリスクが高く、全拒否では機能しません。


問題91

EventBridgeで外部SaaSのイベントを受け取り、内部のStep Functionsを起動したい。適切な設計はどれか。
A. SaaS→SNS→Lambda
B. SaaS統合(パートナーイベントソース)→EventBridgeルール→Step Functionsターゲット
C. CloudTrailのみ
D. Route 53のみ

回答

B

解説

EventBridgeはSaaSパートナー統合に対応し、外部イベントを直接受け取りルールでターゲット(Step Functionsなど)へ振り分けられます。SNSやCloudTrailはこの用途では最適ではなく、DNSは無関係です。


問題92

APIのレイテンシが上昇している。どの区間が遅いかコード変更無しで可視化したい。適切な手段はどれか。
A. X-RayアクティブトレーシングをAPI GatewayとLambdaで有効化
B. CloudTrailのみ
C. NACLログ
D. 監視を止める

回答

A

解説

X-RayをAPI GatewayとLambdaで有効化すると、受け口から関数内部、下流サービス(SDK計測)までのレイテンシ分布を可視化できます。CloudTrailやNACLではアプリ層の遅延箇所特定には不向きです。監視停止は論外です。


問題93

S3でオブジェクトの不変性を担保し、一定期間削除や上書きを禁止したい。最適な機能はどれか。
A. バージョニングのみ
B. オブジェクトロック(コンプライアンス/ガバナンスモード)
C. ライフサイクル移行
D. Glacierへ直送

回答

B

解説

S3オブジェクトロックは保持期間やリーガルホールドを設定し、期間中の削除や上書きを禁止できます。バージョニングは履歴保持であり不変性強制ではありません。ライフサイクルやアーカイブは削除抑止の機能ではありません。


問題94

API Gatewayからのレスポンスをブラウザでキャッシュさせたい。適切な対応はどれか。
A. 常にno-store
B. Cache-ControlやETagなどのヘッダを設定
C. CloudTrailで設定
D. IAMロールで制御

回答

B

解説

HTTPキャッシュはCache-Control、ETag、Last-Modified等で制御します。API Gatewayのレスポンスマッピングでヘッダを付与し、適切なTTLや再検証を設計します。CloudTrailやIAMはキャッシュ制御の仕組みではありません。


問題95

DynamoDBでサイズの大きい属性をたまに参照する。読取コストを抑えたい。設計として適切なのはどれか。
A. すべて1アイテムに詰める
B. 大属性を別アイテムに分離し、必要時にのみ取得
C. 圧縮不可
D. スキャンでまとめて取得

回答

B

解説

頻度の低い大属性はキーで参照できる別アイテム(またはS3外出し+URL)に分離すると、通常の読み取りが軽量化できます。常時同梱はRCUを浪費し、スキャンは更にコストが増えます。圧縮も検討余地はありますが設計が先です。


問題96

API GatewayのREST APIでキャッシュを活用し、バックエンド負荷を下げたい。正しい手順はどれか。
A. キャッシュを有効化し、キャッシュキーに必要なクエリ/ヘッダ/本文マッピングを追加
B. 何も設定不要
C. ステージ変数のみ
D. WAFで代替

回答

A

解説

REST APIはステージまたはメソッド単位でキャッシュを有効化でき、キーに含めるクエリやヘッダを指定してバリエーションを制御します。設定なしでは期待通りに動かず、WAFやステージ変数はキャッシュ機能ではありません。


問題97

Lambdaで外部HTTPサービスに接続するが、レイテンシと失敗率が高い。一般的な改善策はどれか。
A. コネクションの使い捨て
B. Keep-Aliveと接続プール、タイムアウトとリトライ(バックオフ+ジッタ)を適切化
C. 無限リトライ
D. 同時実行を最大に

回答

B

解説

HTTPクライアントをグローバルで再利用し、Keep-Aliveや接続プールを設定、短すぎず長すぎないタイムアウトと指数バックオフ+ジッタのリトライを組み合わせます。使い捨てや無限リトライはスローダウンや輻輳を招きます。


問題98

API GatewayのREST APIでバックエンドからの5XXが一定回数続いたら自動でスロットルしたい。推奨はどれか。
A. Usage Planで動的変更
B. WAFのレートベースルールとアラーム連携
C. 内製で監視して都度変更
D. 何もしない

回答

B

解説

WAFのレートベースルールで入口トラフィックを制限し、CloudWatchアラームでエラー上昇を検知して自動調整に組み込む設計が有効です。Usage Planは即応動的制御には向きません。手動運用は反応が遅れ、未対策は危険です。


問題99

SAMを使ってサーバーレスアプリを定義している。ローカルでAPIの動作確認をしたい。適切なコマンドはどれか。
A. sam package
B. sam local start-api
C. sam publish
D. cfn-lint

回答

B

解説

SAMはsam local start-apiでローカル環境にAPIを立ち上げ、Lambdaのエミュレーションと統合して動作確認が可能です。packageやpublishはデプロイ工程で、cfn-lintはテンプレート検証用です。ローカル検証に最適なのはstart-apiです。


問題100

CDKでスタック間参照を行いたい。適切な方法はどれか。
A. 任意の値を環境変数で受け渡し
B. CfnOutputとFn.importValue(自動的にExport/Import)
C. S3に書き込んで読み出し
D. すべて同一スタック

回答

B

解説

CDKはスタック間依存を解決するため、出力をエクスポートしImportValueで参照する構文を提供します。これによりデプロイ順序や依存関係が正しく管理されます。S3や環境変数は非推奨で、人為的ミスの原因になります。


問題101

API GatewayのREST APIでクォータ制限(1日あたりの呼び出し回数など)をユーザーごとに設定したい。どれか。
A. ステージ設定
B. Usage Plan+APIキー
C. WAFのレート制限
D. IAMポリシーのCondition

回答

B

解説

Usage Planはユーザー単位でレート・バースト・クォータを定義でき、APIキーで紐付けます。ステージ設定は全体設定、WAFはIP視点、IAM Conditionはこの用途では直接的ではありません。請求やフェアユース管理に適します。


問題102

SQS FIFOキューでスループットが伸びない。改善策として正しいのはどれか。
A. MessageGroupIdを1つに固定
B. 複数のMessageGroupIdを用いて並列度を上げる
C. DelaySecondsを増やす
D. 可視性タイムアウトを短縮

回答

B

解説

FIFOはグループ単位で順序を保ちます。グループ数を増やせば並列消費が可能になりスループットが向上します。単一グループでは直列処理になり、Delayや可視性は順序並列度には関係しません。


問題103

RDSの接続資格情報をアプリから安全に取得し、定期的に回転させたい。最適な選択はどれか。
A. Parameter Storeのプレーンテキスト
B. Secrets ManagerのRDSローテーション機能
C. S3に暗号化して保管
D. 環境変数固定

回答

B

解説

Secrets ManagerはRDS用の自動ローテーションを提供し、Lambdaテンプレートで手軽に回転できます。アプリは毎回取得し、長期平文の保持を避けます。Parameter StoreやS3は回転の自動化が弱く、環境変数固定は漏えいリスクがあります。


問題104

CloudFrontでAPI応答もキャッシュしたい。動的パラメータでキャッシュキーを制御するにはどれが必要か。
A. 既定のキャッシュポリシーのみ
B. カスタムキャッシュポリシーでクエリ/ヘッダ/クッキーをキーに含める
C. オリジンの変更は不要
D. S3のみ対応

回答

B

解説

CloudFrontはキャッシュポリシーでどのクエリ、ヘッダ、クッキーをキーにするか宣言できます。APIではこれらを適切に選別してバリエーション爆発を防ぎます。S3限定ではなく、任意HTTPオリジンでも機能します。


問題105

EFSをLambdaから利用して大きなライブラリやモデルを共有したい。基本要件はどれか。
A. LambdaをVPC外に置く
B. LambdaをVPCに接続し、マウントターゲットのあるサブネットとSGを設定
C. EFSをパブリック化
D. NAT必須

回答

B

解説

EFSはVPC内で提供されるため、LambdaをVPCに接続してマウントターゲットへの到達性とセキュリティグループの許可が必要です。パブリック化は不可で、外向き通信が不要ならNATは不要です。権限はIAMとPOSIXの両面を考慮します。


問題106

API Gateway+Lambdaで段階的リリースを自動化したい。推奨の仕組みはどれか。
A. Lambdaエイリアスのウェイト付きルーティング+CodeDeploy Canary
B. Route 53で重み付け
C. ステージURLを手で切替
D. すべて本番に直適用

回答

A

解説

Lambdaエイリアスの加重ルーティングとCodeDeployのカナリア/リニアデプロイを組み合わせると、トラフィックを段階的に新バージョンに移し、自動ロールバックとも連携できます。DNSや手動切替は粒度と安全性が劣ります。


問題107

API Gatewayでリクエストサイズを制限したい。基本的な対処はどれか。
A. Lambdaで排除
B. API Gatewayの最大ペイロード制限とWAFのサイズベースルールを併用
C. CloudFrontで制限
D. RDSで制限

回答

B

解説

API Gatewayにはハード上限があり、さらにWAFの「サイズ制限」ルールを併用することで過大なリクエストを入口で遮断できます。Lambdaで捌くと無駄なコストが発生します。CloudFrontやRDSは直接の制限手段ではありません。


問題108

DynamoDBで大量のアイテムを一括で挿入したい。失敗時の再試行を考慮した最適なAPIはどれか。
A. PutItemをループ
B. BatchWriteItem(未処理項目の再試行を実装)
C. TransactWriteItems
D. PartiQLでINSERT

回答

B

解説

BatchWriteItemは一括書き込みを提供しますが、スループット制限で未処理項目が返る場合があります。アプリ側で未処理を再試行する実装が推奨です。トランザクションは原子性が必要な場面で、常用するとコスト増になります。


問題109

API GatewayのREST APIでベーシック認証のような簡易保護が必要。最小手間の方法はどれか。
A. 無認証
B. Lambda Authorizerでヘッダ検証
C. IAM認証のみ
D. Cognito必須

回答

B

解説

独自ヘッダや単純なトークン検証はLambda Authorizerで実装できます。Cognitoはフル機能のユーザ管理が必要な場合に適し、IAMはクライアント側署名が前提です。保護が不要な無認証は要件に反します。


問題110

CodeBuildでキャッシュを使ってビルド時間を短縮したい。適切な選択はどれか。
A. 常に新規環境でキャッシュ無効
B. ローカルキャッシュ(ソース/依存/Dockerレイヤー)やS3キャッシュを有効化
C. CloudFrontでキャッシュ
D. S3署名URL

回答

B

解説

CodeBuildはローカルキャッシュやS3バックエンドキャッシュをサポートし、依存取得やコンパイルなどの時間短縮に有効です。プロジェクト設定やbuildspecで有効化できます。CloudFrontや署名URLはビルドキャッシュの仕組みではありません。