AWS認定DevOpsエンジニアとは?傾向は?過去問は役に立つ?AIに予想問題を作らせてみた
AWS認定DevOpsエンジニア(AWS Certified DevOps Engineer)は、世界的なクラウドサービスプロバイダーであるAmazon Web Services社が主催している、AWS環境でのDevOps実践スキルを評価し、証明するための国際的な認定資格です。この試験は、単にAWSの各サービスを知っているかだけでなく、DevOpsの文化と実践(継続的インテグレーション、継続的デリバリー、モニタリングなど)をAWS上で実現するための専門的な知識とスキルを客観的に測ることに重点を置いています。
この資格を取得することで、ご自身のDevOpsエンジニアとしてのスキルが国際的な最高水準を満たしていることを証明できます。履歴書に記載して就職活動や転職活動で強力にアピールしたり、企業内でのスキル評価に利用されたりすることがあります。特に、開発の効率化と品質向上を目指す多くの企業でDevOpsが導入されている現代において、この資格は世界中で非常に高い評価を受けています。
資格の位置づけと取得の流れ
AWS認定資格は、スキルレベルに応じてFoundational、Associate、Professional、Specialtyの4つのカテゴリに分かれています。AWS認定DevOpsエンジニアは、その中でも最も専門性が高いProfessionalレベルに位置づけられています。
この資格を取得するには、以下の知識と経験が推奨されています。
- AWS認定ソリューションアーキテクト – アソシエイトまたはAWS認定SysOpsアドミニストレーター – アソシエイトの取得経験:DevOpsエンジニアの資格は、アソシエイトレベルの知識を土台としています。まずはこれらの資格を取得して、AWSの基礎知識を固めておくことが推奨されています。
- AWS環境でのDevOps実践経験:この資格は、単なる知識だけでなく、AWS環境で実際にDevOpsを実践した経験が問われます。継続的デリバリーと自動化ツール(CodeCommit, CodeBuild, CodeDeploy, CodePipelineなど)の使用経験が特に重要です。
このように、AWS認定DevOpsエンジニアは、AWSの基礎知識がある方を対象に、より高度なDevOpsの実践スキルを問う資格です。アソシエイトレベルの資格を取得して、AWSの基礎を固めてから挑戦するのが一般的な流れとなります。
試験の傾向と出題形式はどうなっていますか?
試験の傾向を知ることは、効率的な学習を進める上で非常に重要ですです。AWS認定DevOpsエンジニア試験は、出題範囲が非常に広く、現実のビジネスシナリオに基づいた問題が出題されるのが特徴です。
出題形式の特徴
AWS認定DevOpsエンジニア試験は、選択式の問題が中心となりますが、単に4択から選ぶだけでなく、以下のような形式の問題も出題されます。
- 複数選択問題:複数の選択肢から、正解をすべて選ぶ形式の問題です。単純な知識の暗記だけでなく、それぞれの選択肢がなぜ正解(または不正解)なのかを正確に理解していないと、正解にたどり着くのが難しい場合があります。
- シナリオ問題:試験では、架空の企業のビジネス要件や技術的な制約が詳細に記された「シナリオ」が提示されます。そのシナリオに基づいて、最適なAWSサービスや設定を提案する問題が複数出題されます。これは、単なる知識の暗記だけでなく、それを現実のビジネス課題に適用する能力を測るためのものです。
これらの問題形式に慣れておくことが、合格のためには非常に重要ですです。
試験の主要な出題範囲
AWS認定DevOpsエンジニアの試験範囲は、以下のようなカテゴリに分かれています。
- 継続的インテグレーション(CI)と継続的デリバリー(CD):CodeCommit, CodeBuild, CodeDeploy, CodePipelineといったAWSのDevOpsサービスを使って、CI/CDパイプラインを構築・運用するスキルが問われます。
- モニタリングとロギング:CloudWatch, CloudTrail, X-Rayといったサービスを使って、アプリケーションやインフラのパフォーマンスを監視し、問題を特定・解決する能力が求められます。
- セキュリティ、コンプライアンス、ガバナンス:IAM, AWS WAF, Security Hubといったサービスを使って、AWS環境のセキュリティを確保し、コンプライアンス要件を満たすための知識が問われます。
- 自動化とインフラストラクチャ管理:CloudFormation, AWS CDK, AWS Systems Managerといったサービスを使って、インフラストラクチャの自動化と管理を行うスキルが出題されます。
- 高可用性(HA)と障害復旧(DR):Auto Scaling, Elastic Load Balancing, Amazon Route 53といったサービスを使って、高可用性で信頼性の高いシステムを設計・運用する能力が問われます。
このように、AWS認定DevOpsエンジニアは、DevOpsの文化と、それをAWS上で実現するための技術的な知識が幅広く問われるのが特徴です。
過去問は役に立ちますか?具体的な対策方法も教えてください
過去問や問題集は学習において非常に有効なツールです。特に、AWS認定DevOpsエンジニアのような広範囲にわたる資格では、過去問を活用することで、出題傾向を掴み、効率的に学習を進めることができます。しかし、ただ過去問を解くだけなく、どのように活用するかが大切です。
過去問の活用法
過去問や問題集を解くことには、主に二つの大きなメリットがあります。
- 出題形式や傾向を把握できる:過去問を解くことで、どのような形式で問題が出されるのか、どの分野から頻繁に出題されるのかといった傾向を掴むことができます。これにより、効率的に学習する分野を絞り込むことが可能になります。特に、シナリオ問題の形式に慣れておくことは、本番での戸惑いをなくす上で非常に重要です。
- 自分の弱点を見つけられる:過去問を解いてみて、間違えた問題や理解に時間がかかった問題を分析することで、自分自身がどの分野を苦手としているのかを明確にできます。例えば、特定のAWSサービスの特性が曖昧、CI/CDパイプラインの設計がよくわからないなど、具体的な弱点を見つけたら、そこを重点的に復習することで、より確実に実力を伸ばすことができます。
過去問は、ただ答えを丸暗記するのではなく、「なぜこのサービスを選ぶのが最適なのか」「なぜこのアーキテクチャがこのビジネス要件を満たすのか」を深く考えることが重要です。間違えた問題については、解説を読み込むだけでなく、実際にAWS環境でサービスを触ってみるなど、能動的に学習を進めていくことをおすすめします。
AWS認定DevOpsエンジニア試験の具体的な対策
対策のポイント
- 公式教材や認定トレーニングを活用する:AWSが提供している公式の学習教材や、認定パートナーが開催するトレーニングコースを利用することは、試験範囲を効率的に網羅する上で非常に有効です。
- ハンズオンで実践経験を積む:Professionalレベルの試験では、実践的なスキルが問われます。AWSの無料枠を活用したり、Qwiklabsのようなハンズオンラボサービスを利用したりして、実際にAWSの各サービスを触ってみることが大切ですです。
- DevOpsの文化と原則を理解する:この資格は、単なる技術的な知識だけでなく、DevOpsという開発手法の文化と原則を深く理解しているかが問われます。なぜDevOpsが必要なのか、どのようなメリットがあるのかといった、根本的な部分を理解しておくことが大切です。
- 各AWSサービスの連携を学ぶ:試験では、複数のAWSサービスを組み合わせて使う問題が多数出題されます。例えば、CodePipeline, CodeBuild, CodeDeployを組み合わせてCI/CDパイプラインを構築する方法など、サービス間の連携を深く理解しておくことが重要です。
- ホワイトペーパーを読み込む:AWSの公式サイトには、DevOpsに関するホワイトペーパーが多数公開されています。これらのドキュメントを読み込むことで、AWSが推奨するDevOpsのベストプラクティスを深く理解できます。
この資格はどのような仕事に役立ちますか?
AWS認定DevOpsエンジニアの資格は、DevOpsやクラウドに関連する多岐にわたる、非常に高度な仕事で役立ちます。この資格は、AWS環境でDevOpsを実践する、まさに「エキスパート」であることを証明します。
- DevOpsエンジニア:開発チームと運用チームが協力して、開発からリリースまでのプロセスを自動化し、効率化する専門職です。この資格は、DevOpsエンジニアとして働く上で、最も重要な証明となります。
- 上級クラウドエンジニア:大規模なクラウド環境の構築、運用、そして高度なトラブルシューティングを行う専門職です。DevOpsの知識は、クラウドの運用を最適化する上で不可欠です。
- ITコンサルタント:企業のDevOps導入を支援する際、この資格の知識を持っていることで、より信頼性の高い提案が可能になります。
- ソフトウェア開発者:開発したアプリケーションを効率的にデプロイ・運用するために、DevOpsの知識は不可欠です。
この資格は、これらの分野で働く上で、ご自身の知識やスキルを証明する、最も強力な手段となります。
転職時には有利になりますか?
AWS認定DevOpsエンジニアの資格は、転職活動において、ご自身のDevOpsスキルを客観的に示すための、非常に強力で決定的な武器となり得ます。
有利になる点
- 世界的な権威性の証明:AWS認定資格は世界中で広く認知されており、その中でもProfessionalレベルは、DevOpsに関するエキスパートレベルの知識とスキルを持っていることの証明になります。
- 年収アップにつながる可能性が高い:AWS認定DevOpsエンジニアの資格は、市場価値が非常に高く、他のITエンジニアと比べて高い年収を得られる可能性が高いです。
- 選考の最初のステップを突破しやすくなる:履歴書にこの資格の記載があれば、選考担当者の目に必ず留まります。多くの企業が、DevOpsエンジニアを喉から手が出るほど欲しがっているため、面接に進むためのハードルが大幅に下がります。
- 専門分野でのキャリアチェンジ:クラウドの運用からDevOpsへと、より高度なキャリアパスに進む際の強力な後押しとなります。
資格だけで全てが決まるわけではありません
AWS認定DevOpsエンジニアは、取得が非常に難しいため、合格している時点で、かなりの実践経験を持っているとみなされます。しかし、資格はあくまでスキルを証明する「きっかけ」であり、面接では、これまでの実務経験や、どのような課題を解決してきたかといった、具体的な話が求められます。
そのため、これまでのプロジェクトでどのような役割を担い、どのような貢献をしてきたのかを、この資格の知識と結びつけて具体的に説明できるように準備しておくことが非常に重要ですです。
AIに奪われる可能性は?これからも必要とされますか?
現代において、AI技術は驚くべき速さで進化しています。AIがCI/CDパイプラインの構築や、監視・ログ分析の一部を自動化する時代が到来しつつある中で、「DevOpsエンジニアの仕事はAIに奪われるのでは?」と心配される方もいらっしゃるかもしれません。
しかし、結論から申し上げますと、DevOpsエンジニアのような専門家の需要は今後もなくなることはなく、プロフェッショナルとしての役割もAIに完全に取って代わられることはないと考えられています。
AWS認定DevOpsエンジニアがこれからも必要とされる理由
- AIはDevOpsの「ツール」:AIは、コードのテストや、ログの分析を自動化してくれる強力なツールとなり得ます。しかし、そのAIをCI/CDパイプラインに組み込み、運用・管理し、AIが発したアラートを分析して対応策を考えるのは、依然として人間の専門家の仕事です。AIが進化すればするほど、そのAIをより良く活用するための、DevOpsの専門家である人間の役割はますます重要になります。
- システムの「設計者」としての役割:AIは単純なパイプラインの構築を自動化してくれるかもしれませんが、顧客の複雑なビジネス要件を深く理解し、最適なDevOpsアーキテクチャを考えたり、予期せぬトラブルが発生した際に原因を特定して解決したりする「思考力」は、人間の専門家の役割です。
- 新しい技術への対応:クラウド技術やDevOpsのツールは日々進化しており、新しいサービスや機能が常に登場します。そうした新しい技術に対し、柔軟に対応し、最適なDevOpsプロセスを設計・構築するのは、人間の専門家であるDevOpsエンジニアの役割です。
- AIの限界:AIは、あくまで過去のデータやベストプラクティスに基づいて学習します。そのため、予期せぬトラブルや、新しいタイプのビジネス要件に対して、AIが完璧に対応するのは難しい場合があります。そうした状況で、最終的な判断を下すのは人間の専門家です。
このように、AWS認定DevOpsエンジニアの知識は、AI時代においても、ITインフラを支える上で不可欠な役割を担い続けるでしょう。AIの進化は、DevOpsの仕事を奪うのではなく、むしろ私たちがより高度で創造的な仕事に集中できるような「強力なツール」として、私たちの仕事の仕方をより良いものに変えていくと考えられます。
まとめ
AWS認定DevOpsエンジニアは、DevOpsの分野でキャリアを築きたい方にとって、非常に価値のある、そして挑戦しがいのある国際的な資格です。
- どのような資格?:AWS環境でDevOpsを実践するための専門的な知識とスキルを証明する国際的な資格です。
- 傾向は?:選択式の問題と、現実のビジネスシナリオに基づいた問題が組み合わされて出題されます。
- 対策は?:アソシエイトレベルの知識を土台に、公式教材や認定トレーニングを活用し、実際にAWS環境を触って、実践力を高めることが大切です。
- 転職に有利?:はい、DevOpsの専門家として、世界中で高く評価されます。取得することで、年収アップやキャリアアップにつながる可能性が非常に高いです。
- 将来性は?:AI時代においても、DevOpsの専門家はITインフラを支える上で不可欠な存在であり、その需要は今後も安定していると考えられます。
もし、DevOpsの世界でエキスパートを目指したいとお考えでしたら、ぜひこの資格を目標にしてみてください。ご自身の努力が形となり、大きな自信となって、未来のキャリアを切り拓く力になるはずです。
AWS認定DevOpsエンジニア試験:予想問題(AI作成)
問題1
会社はEC2上のMonolithアプリをECS(Fargate)へ移行中。デプロイ中のダウンタイムを最小化し、段階的にトラフィックを移す必要がある。最適な方法はどれか。
A. ECSのローリング更新
B. CodeDeployのECS Blue/Greenデプロイ(ターゲットグループ2つ)
C. 手動でECSサービスを複製しRoute 53でAレコードを切替
D. Auto Scalingでタスク数を倍にしてから減らす
回答
B
解説
ECSで段階的な切替と自動ロールバックを行うにはCodeDeployのBlue/Greenが最適。ALBの2つのターゲットグループを使い、テスト後にトラフィックを割合で移行できる。失敗時は元環境へ即時復帰可能。ローリング更新は影響を抑えにくく、手動切替や単純スケールでは統合的な判定・自動戻しが難しい。
問題2
複数アカウントにまたがる本番/検証へのデプロイを一本のCodePipelineで実現したい。最も安全な認証方法はどれか。
A. 各アカウントに長期アクセスキーを保存
B. 各アカウントに同一IAMユーザーを作成
C. STS AssumeRoleを使ったクロスアカウントロール委任
D. 各アカウントのルートユーザーで承認
回答
C
解説
クロスアカウントデプロイは、パイプライン実行アカウントから対象アカウントのデプロイロールをAssumeRoleする。STS一時認証情報により鍵の長期保管を避け、権限を最小化できる。長期キーや共通ユーザーは漏えい・棚卸しの観点で不適切。ルートユーザー利用は厳禁。
問題3
CodeBuildでビルド時にDBパスワードを安全に参照したい。最適な保管場所はどれか。
A. S3の公開バケット
B. buildspec.ymlに平文で記述
C. Systems Manager Parameter Store(暗号化)またはSecrets Manager
D. 環境変数に直接設定
回答
C
解説
資格情報はKMSで暗号化されたParameter StoreのSecureStringまたはSecrets Managerで管理する。CodeBuildのサービスロールに対して参照権限のみ付与し、ログや設定ファイルへの平文露出を避ける。公開S3や平文、直接環境変数化は漏えいリスクが高い。
問題4
CloudFormationで毎回同じVPCを新規作成せず、既存VPCに安全にデプロイしたい。適切な設計はどれか。
A. VPCも常に再作成
B. 既存リソースをハードコードIDで参照
C. パラメータとしてVPC/Subnetを受け取り、ImportValueやSSMパラメータで解決
D. 手動でテンプレートを書換
回答
C
解説
既存ネットワークは分離スタックで管理し、Export/ImportValueやSSMパラメータにより安定参照する。パラメータ化で環境差分にも対応しやすい。ハードコードは脆く、手動書換は再現性が低い。常時再作成はCIDRや依存関係で破壊的。
問題5
EKSで本番にCanaryデプロイを実施し、問題時は自動で元に戻したい。最適な手法はどれか。
A. 手動でkubectl rollout undo
B. ALBの重み付けを手作業調整
C. Argo Rollouts等のカナリアコントローラ+ヘルス判定連携
D. ノード数を増減して吸収
回答
C
解説
EKSでの段階配信はArgo Rolloutsなどのコントローラが最適。Service/Ingressのトラフィック割合を制御し、Prometheus等のメトリクスで自動判定と自動ロールバックを行える。手動操作は人為ミスや復帰遅延を招く。ノード増減は品質判定や切替制御にならない。
問題6
本番へのリリースは手動承認を必須としたい。CodePipelineで適切な構成はどれか。
A. Testステージ後にManual approvalアクション
B. Source直後に承認
C. デプロイ後に承認
D. CloudWatchアラームで代替
回答
A
解説
CodePipelineはManual approvalアクションをステージに挿入可能。一般に自動テスト合格後、デプロイ前に承認を置くことで品質を担保する。Source直後は意味が薄く、デプロイ後承認では事故防止にならない。アラームは承認機構の代替ではない。
問題7
S3へ成果物を保存するパイプラインで、アーティファクトの完全性改ざん検知を強化したい。適切な対応はどれか。
A. サーバー側暗号化のみ
B. バージョニングとMFA Delete、有効なIAM条件、KMS CMK使用
C. パブリック読み取り
D. ライフサイクルで即削除
回答
B
解説
改ざん対策は複合的に行う。S3 VersioningとMFA Deleteで破壊的変更を抑止し、KMS CMKで暗号化しアクセスをKeyポリシーで制限。さらにIAM条件やブロックパブリックアクセスを有効化する。暗号化だけでは完全性は担保できず、公開や即削除は不適切。
問題8
EC2アプリのBlue/GreenをALBで行いたい。正しい構成はどれか。
A. 1つのターゲットグループの重み付けを変更
B. 2つのターゲットグループを作り、リスナールールで重み付け切替
C. 2つのALBを用意しRoute 53で切替
D. セキュリティグループを切替
回答
B
解説
ALBはリスナールールで複数ターゲットグループへ重み付けルーティングが可能。Blue/Greenでは旧環境と新環境を別ターゲットグループに紐付け、割合移行とヘルスチェック、失敗時の即時戻しを行う。単一TGでは共存が難しく、DNS切替は伝播遅延が課題。
問題9
Lambdaベースの小規模APIを段階リリースしたい。適切な機能はどれか。
A. API Gatewayのステージ変数のみ
B. Lambdaエイリアスと加重トラフィックシフト、CodeDeploy統合
C. 別リージョンへ複製
D. エッジで手動A/B
回答
B
解説
Lambdaはエイリアスごとにバージョンを指し、トラフィックを割合で分配可能。CodeDeployと連携すれば自動判定とロールバックを伴うカナリアや線形シフトを構成できる。ステージ変数のみでは自動ロールバック等が不足。地域複製や手動A/Bは目的とずれる。
問題10
CloudWatchメトリクス異常時に自動でデプロイを止めたい。最適な実装はどれか。
A. アラームをSlack通知のみ
B. CodeDeployのデプロイ設定にCloudWatch alarmsを関連付け
C. CodePipelineを停止してから手動復旧
D. デプロイスクリプトでsleep
回答
B
解説
CodeDeployはCloudWatch Alarmsをデプロイに紐付け可能。アラームがALARM状態になれば自動で失敗とみなしロールバックできる。通知だけでは自動停止にならない。手動停止や待機は遅く、確実性に欠ける。
問題11
ECS(Fargate)でシークレットを安全にコンテナへ渡す最適解はどれか。
A. イメージに.envを同梱
B. タスク定義のsecretsでSecrets Manager/SSMから取得
C. ユーザーデータに平文で書く
D. コンテナ起動引数で渡す
回答
B
解説
ECSタスク定義のsecretsはSecrets ManagerやSSMのSecureStringを安全に注入する。実行ロールに最小権限を付与。イメージ埋め込みや平文引数は漏えいリスクが高い。ユーザーデータはログ等に残る可能性がある。
問題12
インフラ変更のレビュー性と再現性を高めたい。適切な選択はどれか。
A. AWS CLIで都度手作業
B. CloudFormationまたはCDKでIaC化し、PRレビューとパイプライン適用
C. マニュアルドキュメントのみ
D. コンソール操作を録画
回答
B
解説
IaCは差分をコードとしてレビューでき、スタックの再現性やロールバックが容易。CDK/CloudFormationをCI/CDに組み込み、検証→承認→適用の流れを自動化する。手作業や手順書はドリフトと属人化を招く。録画では追跡・差分管理が困難。
問題13
RDS/Auroraの本番スキーマ変更を安全に段階適用したい。適切なアプローチはどれか。
A. 本番で直接ALTER
B. ブルーグリーンデプロイ(Aurora Blue/Green)で新クラスターに適用後切替
C. スナップショットから復元して上書き
D. リードレプリカで書込みテスト
回答
B
解説
Aurora Blue/Greenは複製環境でスキーマや設定を先に適用し、短時間の切替でリスクを抑える。直接ALTERは失敗時の戻しが難しい。スナップショット上書きはダウンタイムが大きい。レプリカは書き込み不可で検証に適さない。
問題14
S3静的サイトの新バージョンを無停止で配信したい。最も適切な方法はどれか。
A. 直接上書き
B. バージョン別プレフィックスに配置しCloudFrontのオリジンパス切替
C. 旧バケット削除後に新規作成
D. TTLを極端に長くする
回答
B
解説
S3にバージョンを並行配置し、CloudFrontのオリジンパスやビヘイビアを切替えて段階反映とロールバックを実現できる。直接上書きは瞬間的な不整合が起こる。バケット再作成はDNS/ポリシー面でリスク。TTL長期化は最新反映を阻害する。
問題15
運用時の設定値を環境ごとに管理し、監査証跡も残したい。適切なサービスはどれか。
A. DynamoDBに平文保存
B. Parameter Store(階層化)またはSecrets Manager+CloudTrail
C. ローカルファイル
D. S3公開
回答
B
解説
SSM Parameter StoreやSecrets Managerは階層化・バージョニング・KMS暗号化と審査ログ(CloudTrail)を備え、環境毎の設定管理に適する。DynamoDBやローカル、公開S3は暗号化・権限制御・監査の面で劣る。
問題16
デプロイ後に特定メトリクスが劣化したら自動で前バージョンへ戻したい。適切な仕組みはどれか。
A. CodeBuildでメトリクス監視
B. CodeDeployの自動ロールバックとCloudWatchアラーム連携
C. EventBridgeで定期的にLambdaが戻す
D. 手動手順書
回答
B
解説
CodeDeployはアラーム連携によりデプロイ中・直後のヘルス劣化を検出して自動ロールバックできる。独自Lambda定期監視は遅延や判定漏れを招く。CodeBuildはビルド工程用。手順書は自動化に該当しない。
問題17
ECRへのプライベートイメージ配布で脆弱性スキャンと署名を利用したい。適切な選択はどれか。
A. スキャン無効で高速化
B. ECRスキャン有効+イメージ署名(Signature/Notary or ECR署名機能)
C. 手動でmd5管理
D. S3にtarを置く
回答
B
解説
ECRはプッシュ時/スケジュールで脆弱性スキャンを提供し、イメージ署名で信頼性を高められる。これにより供給チェーンの安全性を担保できる。チェックサムの手動管理やS3配布は一貫性や検証が弱い。スキャン無効化はリスク増。
問題18
CloudWatch Logsのログ保持とコスト最適化を自動で行いたい。最適な方法はどれか。
A. ずっと保持
B. 保持期間を設定し、Export to S3+Athena分析
C. ログを都度手動削除
D. すべてメトリクス化
回答
B
解説
必要期間のみLogsで保持し、その後はS3にエクスポートして低コストに長期保管、Athenaで分析する。ログは保持コストが増大しやすく、手動削除は漏れの原因。すべてメトリクス化は費用対効果が悪い。
問題19
オンプレGitHubからのソースを安全にCodePipelineへ取り込みたい。適切な設計はどれか。
A. インターネット経由SSHのみ
B. AWS CodeStar Connections(コネクション)でOIDC連携
C. S3へ手動アップロード
D. メール添付
回答
B
解説
CodeStar ConnectionsはVCSと安全に統合し、Webhookイベント駆動でパイプラインを起動できる。OIDCによりトークン管理を簡素化し安全性を高める。手動アップロードやメールは自動化・監査の面で不十分。単純SSHも運用負荷が高い。
問題20
インフラのドリフトを検出し自動修復したい。適切な組合せはどれか。
A. CloudFormation Drift検出+StackSets自動更新
B. Config無効化
C. コンソールで日次確認
D. Excelで管理
回答
A
解説
CloudFormationのドリフト検出で差分を把握し、複数アカウントやリージョンはStackSetsで是正更新を配布する。AWS Configのルールも合わせて遵守状況を監視すると効果的。手作業やExcelは信頼性・拡張性に欠ける。
問題21
デプロイ承認時にセキュリティ担当からの二段階承認を必須にしたい。最適な方法はどれか。
A. 1人の承認者のみ
B. CodePipelineのManual approvalを2連続配置し、SNS通知で関係者に送付
C. メールで口頭承認
D. Gitのマージ承認だけ
回答
B
解説
Manual approvalは複数段に配置可能で、SNS連携で関係者へ通知できる。段階承認を明確にし、監査証跡を残す。単一承認や口頭承認では統制が弱く、Git承認のみでは運用段の統制要件を満たさないことが多い。
問題22
EKSで秘密情報のローテーションを自動化したい。適切な構成はどれか。
A. ConfigMapに平文保存
B. Secrets Managerの自動ローテーション+外部シークレット連携(External Secrets等)
C. Podに環境変数固定
D. Dockerfileに埋め込む
回答
B
解説
Secrets Managerのローテーション機能で定期的に値を更新し、コントローラ(External Secrets等)がKubernetes Secretを同期する。Podは再展開で最新値を取得。平文や埋め込みは漏えいリスク。固定環境変数はローテーションに不向き。
問題23
CloudFrontのキャッシュがデプロイ後も古いまま。即時反映を最小コストで行いたい方法はどれか。
A. 全オブジェクト無制限無効化
B. 変更ファイルのパスのみに無効化を限定し、自動で差分リスト生成
C. TTLを0に固定
D. 毎回ディストリビューション再作成
回答
B
解説
無効化は差分パスに絞るのがコスト効率と速度の両面で最適。CIで変更差分を検出して自動生成すると運用が安定する。全無効化やTTLゼロはコスト・性能に悪影響。再作成はDNS伝播やWAF設定の再適用で重い。
問題24
CodeBuildで並列ユニットテストと統合テストを分離し、全成功時のみ次へ進めたい。適切な方法はどれか。
A. 単一ビルドで順次実行
B. CodePipelineの並列アクションと条件分岐(成功時連結)
C. どちらか片方のみ
D. 人手で確認
回答
B
解説
CodePipelineは同一ステージ内で並列アクションを配置でき、両方成功した場合のみ次ステージへ進める。これにより全体時間短縮と品質担保を両立。単一ジョブ順次は時間が長く、片方省略や手動確認は品質・再現性が下がる。
問題25
EC2の設定ドリフトを継続監視し自動修復したい。最適なツールはどれか。
A. CloudWatchのみ
B. Systems Manager State Manager/Automation+Inventory/Compliance
C. SSHでcron
D. カスタムスクリプトのみ
回答
B
解説
SSM State Managerで所望状態を定義し、Automationで修復、Inventory/Complianceで準拠状況を可視化する。エージェントベースでスケールしやすい。CloudWatch単体は設定準拠を示せない。SSHや自作は運用負荷が大きい。
問題26
サーバレスCIでビルド時間が長くコスト高。最適化の第一歩はどれか。
A. 常に最大コンピュートタイプ
B. CodeBuildのキャッシュ活用(ローカル/リモート)と依存アーティファクト化
C. ログ無効化
D. ビルドを日中のみ
回答
B
解説
依存のキャッシュ化やビルド層のアーティファクト分離はビルド時間とコストを大幅に削減する。コンピュート増強は費用増に直結。ログ無効化は分析性低下。時間制限は根本解決にならない。
問題27
マイクロサービス間のデプロイ順序依存を解決したい。適切な設計はどれか。
A. 人が順番にボタンを押す
B. Step Functionsで依存関係を表現し、サービスごとのデプロイをタスク化
C. 1つの巨大サービスに統合
D. デプロイ順序を無視
回答
B
解説
複数サービスの順序や条件分岐はStep Functionsでワークフロー化し、各デプロイをAPI呼び出しやCodePipelineトリガでタスク化するのが堅牢。手動はミスが起きやすい。モノリス化や無視はアーキテクチャ原則に反する。
問題28
本番障害時に直近安定版へ迅速に戻すためのベストプラクティスはどれか。
A. 直前のコミットを推測
B. パイプラインで前回成功アーティファクトをプロモートする明示手順
C. 手動でサーバにscp
D. すぐ再起動
回答
B
解説
直前に成功したアーティファクトを追跡し、パイプラインで「ロールバック」ジョブとして即時再デプロイできるようにする。手動コピーや再起動は再現性がなく根本回復にならない。推測は誤適用の原因。
問題29
開発者がローカルから一時的にAWSにアクセスする際、長期キー配布を避けたい。最適解はどれか。
A. IAMユーザーにアクセスキー配布
B. SSO/IdC+短期クレデンシャル(フェデレーション/OIDC)
C. 共有アカウントの鍵
D. ルートキー
回答
B
解説
AWS IAM Identity Center(SSO)やIdC統合により、短期の一時資格情報を払い出すのが安全。ローテーション不要で監査も容易。長期キーや共有鍵、ルートキーはリスクが高く推奨されない。
問題30
ECSサービス更新がピーク時間に実行され、ユーザー影響が出た。対策はどれか。
A. 24時間禁止
B. デプロイウィンドウを定義し、EventBridgeでパイプライン実行を制御
C. 開発者の裁量
D. タスク定義を小さく
回答
B
解説
業務時間外のみ実行する時間帯制御をEventBridgeで実装し、承認も合わせて運用すると影響を抑えられる。無制限禁止や裁量任せは現実的でない。タスク定義のサイズ変更は根本解決ではない。
問題31
アプリ設定の「機能フラグ」を用いて段階的リリースを行いたい。AWSの適切なサービスはどれか。
A. AppConfig
B. CloudTrail
C. Inspector
D. Macie
回答
A
解説
AWS AppConfigは機能フラグや設定の配布・検証・ロールバックを提供し、環境やユーザー割合ごとに有効化できる。監査・脆弱性・DLPは目的が異なる。AppConfigはCI/CDと補完的に段階リリースを実現する。
問題32
コンテナイメージのベースとなるOS脆弱性に迅速対応したい。適切な運用はどれか。
A. 半年ごとに更新
B. 定期的なリビルドとベースイメージの自動追従、スキャン結果でパイプラインをゲート
C. 更新しない
D. 手動確認のみ
回答
B
解説
ベースイメージの更新をトリガにリビルドを自動化し、ECRスキャンやInspector結果で閾値を超えた場合にパイプラインを停止するのが効果的。更新放置や手動のみは遅延と漏れを生む。
問題33
Blue/Greenでデータマイグレーションが必要。安全な進め方はどれか。
A. 一括移行のみ
B. 先にスキーマを後方互換にし、双方向/前方互換を確保してから段階的切替
C. 旧DBを停止
D. 本番で直接DDL/データ更新
回答
B
解説
互換性を確保する拡張的なスキーマ変更(拡張→コード切替→縮退)と、段階的データ移行が安全。双方向同期やキューで整合性を保ち、切替時のリスクを低減。一括や直更新は失敗時の復帰が難しい。
問題34
パイプラインのアーティファクトをS3に保管。リージョン障害時の継続性を高めたい。方法はどれか。
A. 何もしない
B. クロスリージョンレプリケーション+KMSキーは複数リージョンに用意
C. 別アカウントに手動コピー
D. SNSに送信
回答
B
解説
CRRで別リージョンに自動複製し、KMSは各リージョンのキーを用意する。これによりDR時にもアーティファクトにアクセスできる。手動は漏れの原因。SNSは通知であり保管ではない。
問題35
EKSでPodの構成逸脱(特権コンテナ等)を防ぎたい。最適な機能はどれか。
A. 任意運用
B. Kyverno/OPA Gatekeeper等のポリシーエンジン
C. CloudWatchのみ
D. Podの名前で判定
回答
B
解説
ポリシーエンジンでAdmissionコントロールによりPod仕様を強制できる。特権やホストPath等を禁止し、CIでも検出可能。監視のみでは防止できず、命名規則では逸脱を防げない。
問題36
マルチアカウントの統制を強化したい。適切な組み合わせはどれか。
A. すべて1アカウント
B. Organizations+SCP+Control Tower
C. 口頭ルール
D. Excel台帳
回答
B
解説
OrganizationsとSCPで許可境界を中央管理し、Control Towerでベストプラクティスに沿うガードレールとアカウントプロビジョニングを行う。単一アカウントや口頭、台帳は拡張性と統制に欠ける。
問題37
ECSタスクのデプロイで一時的に失敗が増加。デプロイ手法の改善点はどれか。
A. 最小ヘルシーパーセントを0に
B. 最小ヘルシーパーセントを高め、最大パーセントを調整して容量を確保
C. タスク定義を巨大化
D. ログを無効化
回答
B
解説
デプロイ時の余剰容量を確保することで、新旧タスクの重なり期間に負荷を吸収し、失敗を抑えられる。最小0はダウンタイムの恐れ。巨大化やログ無効化は無関係。適切なデプロイ設定とオートスケール連携が重要。
問題38
パイプラインの変更を監査可能にしたい。最適な方法はどれか。
A. 口頭連絡
B. CodePipeline/CodeBuildのCloudTrailログと設定をIaCで管理
C. スクリーンショット
D. 変更禁止
回答
B
解説
CloudTrailでAPI変更を記録し、パイプライン定義をIaCでバージョン管理することで、誰が何を変更したか追跡できる。口頭や画像では完全な監査にならない。変更禁止は現実的ではない。
問題39
本番前に負荷試験を自動で実施し、基準未達ならリリースを止めたい。設計はどれか。
A. 手動で実施
B. CodeBuildで負荷ツールを実行し、結果を解析して失敗にするゲートを実装
C. 本番で試す
D. ログのみ確認
回答
B
解説
負荷試験をCIに組み込み、閾値判定でパイプラインをゲートする。結果はS3に保存し、しきい値超過時は失敗にして進行を止める。手動や本番テストはリスクが高い。ログ確認だけでは自動判定にならない。
問題40
IaC変更の安全性を高めるために、本番前プラン評価を必須化したい。適切な手段はどれか。
A. 直接apply
B. CloudFormation Change Set/Terraform planを承認ゲートに連携
C. 仕様書だけ確認
D. 口頭合意
回答
B
解説
変更セットやplanを生成して差分をレビューし、Manual approvalを通過した場合のみ適用する。これにより意図しない削除や置換を防ぎやすい。直接適用や口頭合意はリスクが高い。
問題41
Lambdaで依存パッケージが大きくコールドスタートが増えた。対策はどれか。
A. 依存を増やす
B. レイヤー分離、アーキテクチャ選択(Arm64)、プロビジョンドコンカレンシーの適用
C. 何もしない
D. タイムアウト延長
回答
B
解説
共通依存をレイヤー化し、Arm64でサイズと起動時間を削減、重要関数はプロビジョンドコンカレンシーで待ち時間を低減する。タイムアウト延長は根本対策でない。依存増は悪化要因。
問題42
CloudWatch Syntheticsで外形監視を導入。失敗時は自動でIssueを起票したい。方法はどれか。
A. メールのみ
B. アラーム→EventBridge→LambdaでチケットAPI連携
C. 監視を無効
D. 定時に人が確認
回答
B
解説
アラームをEventBridge経由でLambdaに連携し、Jira等のAPIで自動起票する。通知のみでは対応が遅れる。監視無効や人手確認はスケールしない。自動化でMTTA/MTTRを短縮できる。
問題43
デプロイ時にDBマイグレーションを自動で順序制御したい。適切な設計はどれか。
A. アプリ起動時に勝手に実行
B. CodeDeployのライフサイクルフックでスクリプトを実行し、失敗時はロールバック
C. 別手順書
D. 本番で直接SQL
回答
B
解説
CodeDeployはBeforeInstall/AfterInstall等のフックでスクリプト実行や検証を行い、失敗時は自動ロールバックできる。起動時任せや手順書・直接SQLは一貫性と復旧性に欠ける。
問題44
長期的に運用メトリクスを可視化し、複数アカウントを横断して分析したい。適切なサービスはどれか。
A. 個別ダッシュボードのみ
B. CloudWatch Cross-Account/RegionダッシュボードまたはCloudWatch Metrics Stream+Firehose→S3→Athena/QuickSight
C. ログだけ保存
D. すべてCSV
回答
B
解説
CloudWatchのクロスアカウント機能やMetrics Streamでメトリクスを集中集約し、S3/Athena/QuickSightで横断分析する。個別管理やCSV依存は運用負荷が高く、分析が困難。
問題45
ECS on EC2でホストにパッチを適用したい。適切な方法はどれか。
A. 放置
B. Systems Manager Patch Managerでメンテナンスウィンドウ中に適用し、Capacity Providerで置換
C. 手動SSH
D. サービス停止
回答
B
解説
Patch Managerで自動適用し、Capacity ProviderとAuto Scalingで順次置換することで、停止時間を最小化できる。手動SSHや停止はスケールしない。放置はセキュリティリスク。
問題46
機微ログを誤って外部へ送出したくない。最適な対策はどれか。
A. すべて出力
B. Kinesis Data Firehoseで動的マスキング/Lambda変換を行い、安全な宛先へ配信
C. ログ無効
D. 手動で消す
回答
B
解説
Firehoseの変換でPII等をマスキング・フィルタし、安全なS3やOpenSearchへ送る。ログ無効は運用に支障。全出力は漏えいの危険。手動削除は後追いで根本解決にならない。
問題47
本番と同等のテスト環境コストが高い。最適化はどれか。
A. 常時起動
B. IaCで環境をオンデマンド作成し、EventBridgeで自動停止、スポット/小さめサイズを活用
C. 共有本番を使う
D. テストを削減
回答
B
解説
再現性とコストの両立には、テンポラリ環境を自動作成・削除し、停止スケジュールと適切なインスタンスタイプを用いる。本番共有やテスト削減は品質低下。常時起動は費用増。
問題48
アプリの構成変更が特定の国だけで問題を起こす。段階展開で地域ごとに有効化したい。適切な手段はどれか。
A. 一括有効化
B. AppConfigのターゲティングで地理条件を使い、段階ロールアウト
C. DNSを停止
D. ログのみ
回答
B
解説
AppConfigはセグメント対象指定が可能で、地域や属性で機能を段階的に有効化し、問題時は即ロールバックできる。一括適用はリスクが高い。DNS停止やログ確認だけでは制御にならない。
問題49
パイプラインで脆弱性の重大度が高い場合は自動的に停止したい。適切な設計はどれか。
A. レポートをメール
B. CodeBuildでスキャナを実行し、重大度閾値でexit 1にしてゲート
C. 手動で判断
D. 本番だけ通過
回答
B
解説
ビルドステージで依存・イメージ等のスキャンを実施し、重大度しきい値越えでジョブを失敗させる。これにより以降のステージを自動停止できる。通知や手動判断は漏れの原因。本番だけ通過は逆効果。
問題50
Route 53でBlue/GreenをDNSレベルで行いたい。適切なレコード設定はどれか。
A. Aレコード単一
B. 加重ルーティングで2つのエイリアスを設定し、重みを段階的に変更
C. フェイルオーバーのみ
D. すべて地理的ルーティング
回答
B
解説
加重ルーティングにより、Blue/Greenのエイリアス先へトラフィック割合を制御できる。段階変更と巻き戻しが容易。ただしDNSキャッシュの影響を考慮する必要がある。単一Aやフェイルオーバー、地理ルーティングは目的と一致しない。
問題51
本番ECSサービスに新環境を投入する際、先に負荷をかけず動作確認だけ行いたい。適切な方法はどれか。
A. 本番ターゲットグループに少量だけ登録
B. 別ターゲットグループ+ステージングALBでヘルス確認
C. 直接本番ALBへ全量登録
D. DNSを一時停止
回答
B
解説
Blue/Greenの原則として本番とは独立した経路で新環境のヘルスと基本機能を検証するのが安全。別ターゲットグループとステージングALBを用いれば、ユーザー流入前に健全性と監視連携を確認できる。本番TGへ少量登録は影響を完全に隔離できない。
問題52
開発者が手元から一時的にAWSへデプロイするが、監査証跡を残したい。最適解はどれか。
A. 共有IAMユーザーのキー配布
B. IAM Identity Center経由でAssumeRole、CloudTrailを有効
C. ルートユーザーで作業
D. VPC Flow Logsだけで代替
回答
B
解説
IAM Identity Centerの一時認証情報とSTS AssumeRoleで最小権限を払い出し、CloudTrailのAPI証跡で監査可能にするのが標準。共有キーやルート利用は追跡不能・高リスク。ネットワークログだけでは誰が何を変更したかは分からない。
問題53
CodeBuildでテスト結果をパイプライン上で可視化したい。適切な設定はどれか。
A. 何もしない
B. reportsセクションでJUnit等を指定しレポートを出力
C. CloudWatch Logsのみ
D. 成功時にS3へzip保存
回答
B
解説
buildspecのreportsでJUnit等のフォーマットを指定すると、CodeBuild/CodePipeline上でテスト可視化・失敗箇所の把握ができる。ログや単純S3保存では合否や失敗詳細の集計が困難。レポート連携が最適である。
問題54
EKSでリリースごとにマイグレーションJobを確実に一度だけ実行したい。最適な手法はどれか。
A. デプロイ前に手動SQL
B. Helmのpre-install/pre-upgrade hookでJob実行、失敗時はロールバック
C. Pod起動時に毎回実行
D. CronJobに任せる
回答
B
解説
HelmのフックでマイグレーションJobを一度だけ実行し、失敗時にリリースを止められる。これにより順序保証と自動ロールバックが可能。起動時実行は多重実行の恐れ。手動やCron任せは再現性に欠ける。
問題55
CloudFormationで安全に論理ID置換が発生する変更を適用したい。適切な対応はどれか。
A. 直接更新
B. Change Setで差分確認し、必要ならStack更新を分割
C. 失敗したら放置
D. テンプレートを削除して再作成
回答
B
解説
Change Setで置換対象を把握し、依存関係が大きい場合は小分けにして更新する。停止許容度に応じてBlue/Greenや並走を検討。直接更新や再作成はダウンタイム・データ喪失の危険がある。放置は改善にならない。
問題56
Lambda関数の機密設定値をステージングと本番で切り替えたい。最適な設計はどれか。
A. 環境変数に直書き
B. AppConfig/Parameter Storeから取得しエイリアスで切替
C. コード内にif文で分岐
D. S3に平文保存
回答
B
解説
設定の分離はAppConfigやParameter Storeを使い、関数はエイリアスやstage変数で参照先を切り替えると安全で再現性が高い。直書きや平文保存は漏えいリスク。コード分岐は運用が煩雑でレビュー性が低下する。
問題57
ECSサービスのオートスケーリングでスパイクに弱い。改善策はどれか。
A. タスク数を固定
B. ステップスケーリング+ターゲット追従を併用、予測/スケジュールも検討
C. メトリクスを無効化
D. 平均CPUだけを見る
回答
B
解説
急増対策にはターゲット追従で平常時を保ち、スパイク時はステップスケーリングを重ねて一気に増やす。繁忙時間はスケジュールや予測を加える。単一CPU指標や固定運用は過不足を招きやすい。
問題58
マイクロサービスの共通ライブラリ更新が各サービスのCIを頻繁に壊す。対策はどれか。
A. 依存固定で更新禁止
B. 消費側を契約テスト(Consumer-Driven Contract)でゲート
C. 全サービスを同時デプロイ
D. 口頭連絡
回答
B
解説
契約テストにより公開API/契約の後方互換性を自動検証し、破壊的変更が流入するのをCIで防ぐ。全面更新や同時デプロイはリスクと運用負荷が高い。更新禁止は改善が止まる。口頭連絡は自動化にならない。
問題59
OpenSearchへのログ投入でスロットリングが頻発。最適な改善はどれか。
A. 送信リトライ無効
B. Kinesis Data Firehoseでバッファ/圧縮しバックオフ設定
C. 送信を同期化
D. ログを捨てる
回答
B
解説
Firehoseはバッファと再試行制御、圧縮でスループットとコストを最適化でき、OpenSearchの負荷を平準化する。同期送信やリトライ無効は失敗増加に直結。ログ破棄は監査・解析に支障をきたす。
問題60
CloudWatchアラームの誤検知が多い。適切な設定はどれか。
A. 単一データ点で評価
B. M out of N評価とアノマリーディテクタの活用
C. しきい値を極端に高く
D. 通知を無効化
回答
B
解説
M/N評価でノイズを低減し、アノマリー検知で季節性やトレンドを考慮すると誤検知を抑えやすい。単一点や極端なしきい値は感度/特異度のバランスが悪化。通知無効化は監視の目的を損なう。
問題61
CodePipelineのステージ間で動的に変数を受け渡したい。適切な手段はどれか。
A. メールで伝達
B. CodeBuildのexported variablesとパイプライン変数を利用
C. すべてハードコード
D. S3にメモ書き
回答
B
解説
CodeBuildはexported-variablesで出力をアーティファクト外に渡せ、CodePipeline変数で後続アクションが参照できる。ハードコードや手動伝達は再現性がない。S3メモは脆く、権限・整合の課題がある。
問題62
モノレポで一部ディレクトリのみ変更時に対象サービスだけをビルドしたい。方法はどれか。
A. すべて再ビルド
B. 変更差分を検知してパスごとに並列ジョブを起動
C. 人が目視
D. 週1だけ実行
回答
B
解説
差分検出で影響範囲のサービスのみをビルド・テストし、並列化してリードタイムを短縮するのが効率的。全面再ビルドは無駄が多い。目視や定期実行は遅延と漏れの原因になる。
問題63
RDSのメジャーバージョンアップを安全に行いたい。最適なアプローチはどれか。
A. 直接本番で適用
B. スナップショット/ステージングで検証→メンテナンスウィンドウで適用
C. 何もしない
D. リードレプリカに自動反映
回答
B
解説
互換性検証をステージングで実施し、バックアップを確保したうえでメンテナンスウィンドウ中に適用するのが定石。直接適用は戻しが難しい。放置は脆弱性やサポート切れのリスク。レプリカ反映だけでは検証にならない。
問題64
S3静的サイトで国別にコンテンツを切替えたい。適切な構成はどれか。
A. 単一バケットで上書き
B. CloudFrontの地理的制御+ビヘイビア/オリジンルールで国別パス
C. Route 53のみ
D. NACLで制御
回答
B
解説
CloudFrontはGeo制御により国別のビヘイビアやオリジンへ振り分けできる。オブジェクトを上書きする方式は競合とロールバックの問題がある。DNSやNACLではコンテンツ切替ロジックを持てない。
問題65
Auroraで読み取り負荷が高い。書き込み遅延は増やしたくない。対策はどれか。
A. ライターへ集約
B. リーダーエンドポイント/リーダーインスタンスをスケール
C. ストレージを縮小
D. タイムアウトを短縮
回答
B
解説
Auroraはリーダーインスタンスを水平増設し、リーダーエンドポイントで自動分散できる。書き込みはライターに残し、読み取りを分離するのが基本。集約は悪化要因。ストレージ縮小やタイムアウト変更は根本対策ではない。
問題66
ECRイメージの不要タグでストレージが圧迫。最適な運用はどれか。
A. 放置
B. ライフサイクルポリシーで未参照/古いタグを自動削除
C. 毎回手動削除
D. 常に最新だけ残す
回答
B
解説
ライフサイクルポリシーで保持数や日数を定義し自動削除すれば、必要な復旧用の履歴を残しつつコストを抑えられる。手動は漏れや工数増。最新のみはロールバック不能のリスクがある。
問題67
複数アカウントで統一されたタグ付けを強制したい。方法はどれか。
A. ルールなし
B. OrganizationsのタグポリシーとConfigルールで準拠判定
C. 各自の判断
D. 毎月点検のみ
回答
B
解説
タグポリシーで許可キー/値の標準化を行い、Configルールで逸脱を検出・修正する。運用者の裁量や目視点検はスケールせず、準拠率が上がらない。ルールなしはコスト配賦や運用自動化を阻害する。
問題68
API Gateway+Lambdaの遅延が増大。ボトルネック特定の第一歩はどれか。
A. 直感で修正
B. X-Rayトレースを有効化しセグメント別に遅延分析
C. ログを停止
D. タイムアウトを延長
回答
B
解説
X-Rayを有効化するとAPI Gateway、Lambda、外部依存の各セグメントの遅延やエラーを可視化でき、根因特定が容易。闇雲な修正やタイムアウト延長は無駄が多い。ログ停止は調査性を損なう。
問題69
CodePipelineの手動承認で、承認理由と証跡を必ず残したい。適切な設定はどれか。
A. コメント不要
B. Manual approvalでコメント必須化し、SNSで監査チャンネルへ通知
C. 口頭許可
D. 別スプレッドシートに記入
回答
B
解説
承認アクションはコメントを残せ、SNS連携で監査向けの通知・保存が可能。口頭や外部スプレッドシートは紐付けが弱く、後追い調査が困難。コメント必須化で統制を強められる。
問題70
EKSのPodが断続的にOOMKill。運用改善はどれか。
A. limitsを無制限
B. requests/limitsを適切化し、VPA/HPAで自動調整、OOM時にPodDisruptionを考慮
C. 監視を外す
D. ノードを倍増のみ
回答
B
解説
正しいrequests/limits設定でノードスケジューリングを安定させ、VPA/HPAで需要に応じて調整する。OOM時の挙動やPDBも設計する。無制限や監視停止は悪化要因。ノード増だけでは根本解決にならない。
問題71
Gitのブランチ戦略でリードタイムを短縮し継続デリバリーを促進したい。選択はどれか。
A. 長期リリースブランチ中心
B. Trunk-Based Development+小さなPRとFeature Flag
C. 巨大PRの一括マージ
D. 隔月で統合
回答
B
解説
Trunkベースで小さい変更を高頻度に統合し、未完成機能はフラグで隠すと、衝突減少とフィードバック高速化が実現する。長期分岐や巨大PRは統合コストと品質低下を招きやすい。
問題72
CloudFrontのWAFルール更新を安全に展開したい。方法はどれか。
A. 本番に直接適用
B. ステージングディストリビューションで検証→Rule groupのバージョンをプロモート
C. すべて無効化
D. ルールを1つに統合
回答
B
解説
WAFのルールはステージングで誤検知やパフォーマンス影響を確認し、マネージドルールや自作ルールをバージョン管理して段階適用する。本番直適用は影響範囲が大きい。無効化や無理な統合は防御力を下げる。
問題73
Lambdaの同時実行が上限に達し、他関数へ影響。対策はどれか。
A. 上限を放置
B. 関数別Reserved concurrencyやスロットリング制御を設定
C. すべて最大に設定
D. タイムアウトを延長
回答
B
解説
Reserved concurrencyで重要関数に枠を確保し、不要な関数は制限する。必要に応じてアカウント上限も申請。無計画な最大化は枯渇と費用増の原因。タイムアウト延長は同時実行圧迫を悪化させる。
問題74
S3アーティファクトの整合性をビルドからデプロイまで担保したい。適切な施策はどれか。
A. 何もしない
B. 署名付きハッシュ(チェックサム)を生成し、以降のステージで検証
C. メールで確認
D. S3キー名だけ一致
回答
B
解説
ビルド時にチェックサムを生成・署名してアーティファクトと一緒に渡し、デプロイ前に検証すれば改ざんや取り違えを検出できる。キー名一致や口頭確認は不十分。未対策はサプライチェーンリスクとなる。
問題75
EventBridgeで「本番デプロイ中は別ジョブを抑止」したい。方法はどれか。
A. 何もしない
B. イベントバスのルールにConditionとしてSSMパラメータ/タグの状態を参照
C. CloudWatchだけ
D. 手動で一時停止
回答
B
解説
EventBridgeは入力変換やパターンで条件マッチを制御でき、SSMパラメータやDynamoDB状態を見て実行可否を判定する設計が可能。手動や監視のみでは自動抑止にならない。未対策は競合実行の恐れ。
問題76
CloudFormation StackSetsで本番と検証の差異を意図的に持たせたい。適切な方法はどれか。
A. 同一パラメータ固定
B. 部署/アカウント別にパラメータオーバーライドを設定
C. 別テンプレートを乱立
D. 手動で後編集
回答
B
解説
StackSetsはターゲットごとにパラメータオーバーライドが可能で、同一テンプレートの統一性を保ちながら環境差分を管理できる。乱立や後編集はドリフトを招く。固定化は柔軟性がない。
問題77
EKSのイメージプルでたびたび失敗。ベストプラクティスはどれか。
A. パブリックのみ使用
B. ノード/PodのIAMロールにECR権限付与、プルスルーキャッシュ/レプリカを活用
C. 私設レジストリへコピー
D. 再試行しない
回答
B
解説
IRSAやノードロールで最小権限を付与し、ECRのレプリケーションやプルスルーキャッシュで近接性と可用性を高める。再試行なしは脆弱。無計画な私設レジストリは管理負荷とセキュリティ課題を増やす。
問題78
データ保護のため、バックアップからの演習復旧を定期的に自動化したい。方法はどれか。
A. 本番だけバックアップ
B. AWS Backupのジョブと起動テスト/復旧テストプランを定期実行
C. 必要時にだけ復旧
D. スナップショット名を記録
回答
B
解説
AWS Backupは復旧テストを計画でき、定期的に自動復元と検証を行うことで実効性を確認できる。記録や突発対応のみではDRの信頼性が担保できない。本番だけの保護も不十分。
問題79
カナリアリリースで品質判定に用いる指標の選定で最も適切なのはどれか。
A. CPUのみ
B. ユーザー中心KPI(エラーレート/レイテンシ/SLO)とビジネスメトリクス
C. デプロイ時間
D. ログ行数
回答
B
解説
段階配信の判定はユーザー体験に直結するエラーレートやp95遅延、SLO違反、さらにCVR等のビジネス指標を用いる。CPU等の低次指標だけでは判断を誤る。デプロイ時間やログ行数は適切な品質尺度ではない。
問題80
CloudTrailの改ざん耐性を高めたい。適切な手段はどれか。
A. 同一アカウント単一バケット
B. 別アカウントのS3バケットに配信し、バージョニング+MFA Delete+S3 Object Lock
C. ローカル保存
D. 権限は全員に付与
回答
B
解説
セキュリティアカウント等の分離バケットへ配信し、バージョニングとObject Lockで不変性を確保すると改ざん耐性が向上する。単一アカウントや広範権限は危険。ローカル保存は可用性と監査性に欠ける。
問題81
デプロイ後すぐにエラー急増。根因がアプリかインフラか判別したい。第一対応はどれか。
A. ログを削除
B. ダッシュボードで変更前後のメトリクス/ログ/トレースを比較
C. すぐスケールアウト
D. DNSを切替
回答
B
解説
変更前後の同一KPIを時系列で比較し、アプリメトリクスと基盤指標、APMトレースを突き合わせるのが最短。闇雲なスケールやDNS変更は状況を悪化させる。ログ削除は分析不能にする。
問題82
SSM Automationでローリング再起動を安全に行う際に重要な設計はどれか。
A. 一括再起動
B. MaxConcurrency/MaxErrorsの設定とヘルスチェック連携
C. タイムアウト無制限
D. ログを出さない
回答
B
解説
Automationのパラメータで同時実行数と許容エラー率を制御し、ALB/ASGヘルスと連携してドレイン→再起動→復帰確認を行う。無制限や一括は停止リスクが高い。ログ非出力は追跡性を損なう。
問題83
EKSでIngressのロールバックを迅速にしたい。戦略はどれか。
A. 現地編集
B. GitOps(Argo CD)で宣言的に管理しリビジョン固定で戻す
C. 手順書で再作成
D. 変更を覚えておく
回答
B
解説
GitOpsでマニフェストをソースオブトゥルースとして管理すれば、過去コミットに即時リバートでき、環境と宣言の整合も自動で回復する。現地編集や記憶頼みは誤設定の温床となる。
問題84
ECSのRolling更新で一時的に503が出る。改善策はどれか。
A. ヘルスチェックを甘くする
B. Deregistration delayとConnection draining、preStopで待機を適切化
C. 一気にタスクを落とす
D. 監視を外す
回答
B
解説
切替時の接続を安全に捌くには、ターゲットのDeregistration delayやコンテナのpreStop処理で既存リクエスト完了を待つ。ヘルスを甘くすると悪化。急な停止や監視無効化は信頼性を下げる。
問題85
CodeBuildのキャッシュが効かない。原因として適切なのはどれか。
A. キャッシュタイプ未設定やパス不一致
B. ログが多い
C. バージョン固定
D. VPC内実行
回答
A
解説
ローカル/リモートキャッシュを定義し、復元/保存のパスが一致していないとキャッシュは無効になる。依存のキャッシュキー(lockファイル)戦略も重要。ログ量やVPC実行は直接原因ではない。
問題86
デプロイ成果物のSBOMを管理し、脆弱性検出をパイプラインで自動化したい。選択はどれか。
A. 何もしない
B. ビルド時にSBOM生成(SPDX/CycloneDX)→スキャン→重大度でゲート
C. 後で手動調査
D. 本番でのみ確認
回答
B
解説
SBOMを生成して依存関係を明示し、既知脆弱性DBと突合して重大度閾値でパイプラインを停止するのが供給網対策の基本。手動や本番限定は遅すぎる。未対策はリスクを見逃す。
問題87
EKSで機密コンテナイメージのpullをポッド単位で制御したい。方法はどれか。
A. 全ノードに広範権限
B. IRSAでServiceAccountにECR読取権限を最小付与
C. kube-systemに付与
D. 誰でもpull可
回答
B
解説
IAM Roles for Service AccountsによりPod単位で最小権限を与えられ、ノード全体に広範権限を与える必要がない。広範権限や全許可は漏えいリスクが高い。kube-system付与は不要な権限拡大。
問題88
AppConfigで設定を配布する際、展開失敗を自動検知して戻したい。構成はどれか。
A. 検証なしで即配布
B. バリデータとCloudWatchアラームのモニタリングを設定し自動ロールバック
C. メール通知のみ
D. 手動で確認
回答
B
解説
AppConfigは事前/事後のバリデータ、メトリクス監視と自動ロールバックを提供する。これにより誤設定でも迅速に復旧できる。通知や手動確認だけでは遅延と人為ミスの可能性が高い。
問題89
データプレーンは安定だがコントロールプレーン(API)が断続的に失敗。耐障害性を上げるには。
A. API依存の起動順序を厳格化
B. 冪等なリトライとバックオフ、サーキットブレーカーの実装
C. 失敗時に停止
D. すべて同期処理
回答
B
解説
一時的なAPI失敗に対しては冪等性を保ったリトライ・指数バックオフ・回路遮断を組合せて影響を局所化する。同期前提や即停止は可用性を下げる。起動順序の厳格化だけでは根本対策にならない。
問題90
DynamoDBのスキーマ変更を安全に進めたい。適切な方法はどれか。
A. 直接置換
B. 新テーブルを並走させ、ストリーム/双方向でデータ移行し段階切替
C. エクスポートして上書き
D. TTLを無効
回答
B
解説
DynamoDBはテーブル定義の変更が限定的なため、新旧を並走させてデータを同期し、読取/書込経路を段階的に切替えるのが安全。一括置換や上書きは停止・データ喪失のリスクが高い。
問題91
CloudWatch LogsでPIIを含む可能性がある。最適な対処はどれか。
A. そのまま保存
B. サブスクリプションフィルター→Lambdaでマスキング→安全な宛先へ配信
C. すべて削除
D. 暗号化のみ
回答
B
解説
サブスクリプションでリアルタイムにログを加工しPIIをマスキングして保存すれば、分析性を保ちつつ漏えいリスクを下げられる。削除は可観測性の喪失。暗号化だけでは閲覧時の露出を防げない。
問題92
Route 53のフェイルオーバー設定で、ヘルスチェックの誤検知が問題。改善はどれか。
A. 1リージョンのみ
B. 連続失敗閾値/測定間隔を調整し、複数エンドポイントの健全性を集約
C. すぐ切替
D. 監視停止
回答
B
解説
ヘルスチェックのしきい値や間隔を適切化し、複数リージョン・複数チェックの集約結果でフェイルオーバー判定すると誤検知を低減できる。即時切替や監視停止は信頼性を損なう。
問題93
Kinesis Data Streamsで遅延が増大。最初に確認すべきはどれか。
A. シャード数不足やホットシャード
B. IAMロール
C. CloudTrail
D. DNS
回答
A
解説
遅延の主要因はシャード不足やパーティションキー偏りによるスループット飽和。メトリクスのWriteProvisionedThroughputExceeded/IteratorAge等を確認し、リシャードやキー分散を検討する。
問題94
OpenSearchクラスターの配置で可用性を高めたい。設計はどれか。
A. 単一AZ
B. マルチAZ配置+専用マスター、レプリカ設定
C. ストレージを最小
D. スナップショットなし
回答
B
解説
マルチAZでデータノードと専用マスターを配置し、インデックスレプリカを設定してAZ障害に耐える。単一AZやスナップショット無効化はリスクが大きい。ストレージ極小は圧縮・マージで窮屈になる。
問題95
CodeDeployのAppSpecで環境変数がリーク。対策はどれか。
A. 平文で記載
B. Secrets Manager/Parameter Store参照に変更し、ログ出力を抑制
C. Gitに残す
D. 共有ドライブ
回答
B
解説
シークレットは安全なストアから取得し、CodeDeployフックで注入・使用後は痕跡を残さない。平文やGit保管は漏えいに直結する。共有ドライブも監査・アクセス制御が弱い。
問題96
EKSのノードアップグレードを無停止に近づけたい。適切な流れはどれか。
A. 一括停止
B. 新ノードグループ作成→Pod Drain/移行→旧ノード廃止、PDB考慮
C. 直接OS上書き
D. 監視無効
回答
B
解説
新ノードへ段階移行し、Pod Disruption Budgetで可用性を保ちつつドレインするのが安全。直接上書きや一括停止はダウンタイムを招く。監視無効化は検知遅延に繋がる。
問題97
CodePipelineで手動承認をSlackから実行したい。方法はどれか。
A. 不可
B. SNS→Lambda→Slackインタラクティブ→Approve/Reject API呼出
C. メールだけ
D. CLIのみ
回答
B
解説
承認イベントをSNSで受け、LambdaがSlackのボタン操作を受け付けてCodePipelineの承認APIを呼び出す統合が可能。メールやCLIだけでは即応性と記録性に劣る。不可ではない。
問題98
CloudFrontで巨大ファイル配信のスループットを上げたい。設定はどれか。
A. 何もしない
B. HTTP/2, Rangeリクエスト許可、最適なキャッシュ/圧縮設定
C. 圧縮を常に無効
D. TTLを無限
回答
B
解説
Rangeリクエスト対応やHTTP/2で効率を向上し、適切な圧縮・キャッシュを施すと大容量配信の体感が改善する。圧縮無効やTTL無限は回転率や鮮度に悪影響。未設定は性能機会を逃す。
問題99
ECSでSidecarにEnvoyを導入しトラフィックを制御したい。適切な利点はどれか。
A. レイテンシ増だけ
B. リトライ/タイムアウト/サーキットブレーカー等をアプリ外で一元管理
C. 監視不可
D. ステートフルにする
回答
B
解説
サービスメッシュ的にEnvoyをSidecar配置すると、通信制御・観測のポリシーをアプリから分離し、一貫したリトライやCB設定を適用できる。監視統合も容易。欠点はオーバーヘッドだが利点が大きい。
問題100
リリース判定にSLOを導入したい。最初に行うべきことはどれか。
A. 直感で目標設定
B. ユーザー中心のSLIを定義し、エラーバジェットに基づくゲーティングを設計
C. CPU使用率をSLO
D. 失敗時は常にロールバック禁止
回答
B
解説
まずSLI(可用性・遅延・正確性等)をユーザー視点で定義し、SLOを設定。エラーバジェットを運用判断に組み込み、リリースの自動可否やロールバック基準に反映する。CPUは間接指標で不適切。極端な禁止は非現実的。

