AWS認定ソリューションアーキテクトアソシエイトのサンプル問題

AWS認定ソリューションアーキテクトアソシエイトのサンプル問題の解説を会社のブログに書こうと思いまして、せっかくなので個人のブログを休日に書いて、それをベースに会社のブログにも反映したいと思います。

(2019年3月22日現在の掲載情報です。)

AWS認定ソリューションアーキテクトアソシエイトとは

検索するときば、「aws saa」で検索するとたどり着きやすいので、詳しくは公式サイトをご確認ください。

• 顧客の要件に基づき、アーキテクチャ設計原則に沿ってソリューションを定義できること
• プロジェクトのライフサイクルを通して、ベストプラクティスに基づく実装ガイダンスを組織に提供できること

公式サイトによると上記を証明できる認定です。
ですのでビジネス要件をベストプラクティスを用いて実現することができる、ってことですね。

では、さっそくサンプル問題を見ていきます。

AWS認定ソリューションアーキテクトアソシエイト サンプル問題

第1問

Q1. ある企業が、カスタム AMI 上のテキストファイルにアクセスキー (アクセスキーID およびシークレットアクセスキー) を格納しようとしています。その企業は、アクセスキーを使用して、AMI から作成されたインスタンスから DynamoDB テーブルにアクセスします。セキュリティチームは、よりセキュアなソリューションを要求しています。セキュリティチームの要求に応えるソリューションはどれですか。

A. アクセスキーをAmazonS3バケットに格納し、起動時にインスタンスからアクセスキーを取得する。
B. インスタンスユーザーデータを介してアクセスキーをインスタンスに渡す。
C. プライベートサブネット内で起動されたキーサーバーからアクセスキーを取得する
D. そのテーブルにアクセスする権限を持つIAMロールを作成し、そのロールを使用してすべてのインスタンスを起動する。
答え： D

解説:

この問題では、EC2上のテキストファイルにアクセスキー情報を書きこんで、そのインスタンスを元にAMIを作成しようとしている人たちに対して、セキュリティチームがちょっと待ったをかけてます。
セキュリティチームの要求に応えて、セキュアな設計にしなければなりません。
それぞれの選択肢を見てみます。

A. はS3にアクセスキー情報を格納してEC2のユーザーデータなどで起動時に取得する、としています。
「これならAMIにはキー情報を持たないから安心！」とはなりません。
そもそもEC2がS3にアクセスするための権限はどのように設定するつもりでしょうか。
B. もA.と同じようにEC2の外部にあるアクセスキー情報をEC2外に置いてユーザーデータで取得する方法です。
どこから渡すつもりでしょうか。
C. はプライベートサブネットでEC2を起動する、としてもやっぱりアクセスキーを使います。
アクセスキーID、シークレットアクセスキーを使うということは、漏れると不正アクセスのリスクがあるということです。
そして人が管理する静的な文字列情報は漏れます。

ですので正解はDのIAMロールを使った安全な権限付与です。
今回の要件では特定のDynamoDBテーブルを操作できる権限のIAMポリシーをアタッチしたIAMロールをEC2に設定します。

第2問

Q2. ある企業が、ステートレスWebサーバーを使用する高可用性Webアプリケーションを開発しています。セッション状態データを保持するのに適したサービスはどれですか (2つ選択してください)。

A. CloudWatch
B. DynamoDB
C. Elastic Load Balancing
D. ElastiCache
E. Storage Gateway
答え: B、D

解説:

ステート(状態)レス(持たない)なWebサーバーです。
セッション状態をWebサーバーに持たない「セッションステートレス」な設計です。
B.のDynamoDBとE.のElastiCacheがセッション情報を保持するのに適しています。
A.のCloudWatchはモニタリングサービス、C.のELBはトラフィックを分散するロードバランサー、E.のStorage GatewayはオンプレミスのデータをAWSに保管するのに適しています。

C.のELBにスティッキーセッション(セッションの維持)という機能がありますので、複数のWebサーバーで高可用性を構成したときのセッション情報の解決が出来るという意味で、混同しそうですが、「ステートレス」がポイントです。
スティッキーセッションは、セッションを維持するのみで、Webサーバーにセッション状態データを保持します。
この状態は「ステートフル」といえます。

第3問

Q3. ある企業において、販売担当者が売上ドキュメントを毎日アップロードしています。ソリューションアーキテクトは、それらのドキュメントを格納するため、重要ドキュメントの誤削除防止機能を備えた高耐久性ストレージソリューションを必要としています。ユーザーによる誤削除を防ぐには、どうすればよいですか。

A. データをEBSボリュームに格納し、週1回スナップショットを作成する。
B. データをAmazonS3バケットに格納し、バージョニングを有効化する。
C. データを別々のAWSリージョンにある2つのAmazonS3バケットに格納する。
D. データをEC2インスタンスストレージに格納する。
答え: B

解説:

売上ドキュメントが誤って削除されないようにしたい、そして高耐久性が必要とのことです。
単純に削除させない、であればポリシーで制御できますが、そうではなく「誤った削除」を防止したいのですね。
これは、「誤って削除しても元に戻せればいい」と考えられます。
そして選択肢の中から最も高耐久性を持っている方法を選択します。

A.はEC2経由でEBSに格納します。EBSはアベイラビリティゾーン内にしか存在しないのでアベイラビリティゾーン単位での障害時にデータが失われる可能性があります。最も高耐久性ストレージではありません。
B.イレブンナインの耐久性を持っているS3が選択肢となります。
ですが、「誤削除を防止する」=「誤って削除しても元に戻す」と考えるとデフォルトで使うのではなく、バージョニングを有効にしてロールバックができるようにします。
C.はマルチリージョンでS3を使用します。複数リージョンのS3バケットを同期させるクロスリージョンレプリケーションの機能もあります。
ですが、同期であれば誤削除防止にはなりませんし、一方を書き込みだけにしてバックアップとして使用したとしても2つのバケットを管理しなければなりませんのでシンプルではありません。また、削除だけではなく上書きの場合の管理を考えても面倒です。
この場合はバージョニングの方がシンプルで要件を満たせる機能となります。
D.はA.のEBSよりもさらに耐久性の低いEC2インスタンスストレージですので違います。EC2インスタンスストレージはEC2がランニングの間しかデータを保持しません。

第4問

Q4. あるアプリケーションに対して、初期ストレージ容量が8TBの高可用性リレーショナルデータベースが必要です。データベースのサイズは、毎日8GBずつ増加する見込みです。予想されるトラフィック量に対応するため、読み取り処理用として8個以上のリードレプリカが必要です。これらの要件を満たす手段はどれですか。

A. DynamoDB
B. Amazon S3
C. Amazon Aurora
D. Amazon Redshift
答え: C

解説:

「高可用性リレーショナルデータベース」というキーワードがあります。
選択肢の中で該当するのは、C.のAmazon Auroraのみです。Amazon AuroraはRDS(リレーショナルデータベースサービス)のデータベースエンジンの１つです。
そして複数のアベイラビリティゾーン上でリードレプリカを作成して、マスターからのフェイルオーバーにも対応しています。
A.DynamoDBはNoSQL(非リレーショナル)です。
B.S3はストレージサービスです。
D.Redshiftは列集計型のデータウェアハウスサービスです。
「毎日8GBづつ増加する」はAuroraのストレージ容量自動増加機能で対応でき、「8個以上のリードレプリカ」もAuroraは対応しています。

第5問

Q5. あるソリューションアーキテクトが、EC2インスタンス上で動作する基幹業務アプリケーションを設計しています。このアプリケーションではリレーショナルデータベースが使用され、最大16,000IOPSのEBS ボリュームが1個必要です。このアプリケーションのパフォーマンス要件を満たすAmazon EBSボリュームタイプはどれですか。

A. EBS プロビジョンドIOPS SSD
B. EBS スループット最適化HDD
C. EBS 汎用SSD
D. EBS コールドHDD
答え：A

解説:

要件として「最大16,000IOPSのEBS ボリュームが1個必要」を満たすボリュームタイプを選択する問題です。
現在、C.の汎用SSDも最大は16,000IOPSの性能がありますが、AWS認定ソリューションアーキテクトアソシエイトは2018年2月現在の内容です。その当時の汎用SSDは10,000IOPSでした。
仮に当時から汎用SSDの最大IOPSが16,000であったとしても、AWS公式のページには以下の記述があります。
ちなみにgp2は汎用SSD、io1がプロビジョンドIOPS SSDです。

「gp2のIOPSより高いIOPSが必要な場合、ワークロードで低レイテンシーが重要である場合、または、パフォーマンスの一貫性を高める必要がある場合は、io1の使用をお勧めします。」

問題には「基幹業務アプリケーションのパフォーマンス要件を満たす」とあるので、一貫性のあるIOPSを提供するA.のプロビジョンドIOPS SSDが選択肢となります。
HDDはSSDよりも性能を低くしてコスト効率をよくする追加のボリュームタイプです。

第6問

Q6. 顧客は、あるWebアプリケーションを使用して、AmazonS3バケットに注文データをアップロードすることができます。すると、AmazonS3イベントが発生し、Lambda関数がトリガされ、メッセージがSQSキューに挿入されます。1つのEC2インスタンスによって、キューからメッセージが読み取られて処理され、一意の注文番号で分割されたDynamoDBテーブルに格納されます。来月のトラフィック量は10倍に増える見込みです。ソリューションアーキテクトは、スケーリングに関する問題がアーキテクチャに発生する可能性を調べています。増加するトラフィックを処理するためにスケーリングできるようにする際、設計の見直しが最も必要であると思われるコンポーネントはどれですか。

A. Lambda 関数
B. SQS キュー
C. EC2 インスタンス
D. DynamoDB テーブル
答え: C

解説:

S3をトリガーにLambda関数が実行され、メッセージをSQSに格納します。
ここまではトラフィックが10倍に増えても、Lambda関数は並列で同時にS3のアップロードイベントを受け付けることができますし、SQSもFIFOキューを指定していなければ制限はありませんので、何の問題もありません。
データが格納されるDynamoDBも書き込みキャパシティユニットを増やすことで問題なく対応できます。
SQSキューからメッセージを受け取って処理をするのが「1つのEC2インスタンス」ですので、ここが問題です。
「1つの」となっているのでスケールしません。また単一障害点(SPOF)にもなっています。

ちなみに、設計の見直し方法としては、EC2をオートスケーリングにする、Ec2の処理をLambdaにおきかえる、などが考えられます。

第7問

Q7. アプリケーションによってログが AmazonS3バケットに格納されています。あるユーザーが、トラブルシューティングのため、このログを1か月間保持し、その後消去したいと考えています。この要件を満たすには、どの機能を使用すればよいですか。

A. AmazonS3バケットに対するバケットポリシーを追加する。
B. AmazonS3バケットに対するライフサイクル構成ルールを構成する。
C. AmazonS3バケットに対するIAMポリシーを作成する。
D. AmazonS3バケットに対してCORSを有効化する。
答え: B

解説:

A.とC.はS3バケットに対してのセキュリティ設定ですので、ログデータの保存期間についてはコントロールできません。
D.は他のウェブサイトからS3のオブジェクトに対してクロスオリジンリクエストを許可するために設定します。
ログデータの保存期間はB.のライフサイクルによって自動化できます。

「ライフサイクル構成ルール」と問題にはありますが、ドキュメントによっては「ライフサイクルポリシー」と書かれていることもあります。
表記ゆれについては気にしてはいけません。意味としてどれが最も適切に指しているかを考えましょう。

第8問

Q8. EC2インスタンス上で動作するアプリケーションによって、AmazonS3に格納されている機密情報が処理されています。その機密情報は、インターネットからアクセスされるため、セキュリティチームは、AmazonS3に対するインターネット接続におけるセキュリティリスクを懸念しています。このセキュリティ上の懸念を解消するソリューションはどれですか。

A. インターネットゲートウェイ経由でデータにアクセスする。
B. VPN接続を使用してデータにアクセスする。
C. NATゲートウェイ経由でデータにアクセスする。
D. AmazonS3に対するVPCエンドポイントを経由してデータにアクセスする。
答え: D

解説:

VPC内のEC2インスタンスとS3の接続方法は2通りのルートがあります。

1つはインターネットゲートウェイ経由でEC2インスタンスからS3バケットにアクセスします。
もう1つはS3のVPCエンドポイント経由でEC2インスタンスからS3バケットにアクセスします。

「インターネット接続におけるセキュリティリスクを懸念」しているので後者のVPCエンドポイント経由が正解です。

B.のVPN接続はVPCとオンプレミスを接続するときに使用します。
C.のNATゲートウェイはプライベートサブネット内のEC2インスタンスがインターネットに接続する際に必要です。
プライベートサブネット内のEC2インスタンスがインターネットゲートウェイ経由でS3にアクセスする場合はNATゲートウェイ、インターネットゲートウェイを経由します。

第9問

Q9. ある組織が、共有サービスVPC内にAmazon Redshiftクラスターを構築しようとしています。そのクラスター上で機密データがホストされる予定です。そのクラスターにアクセスできるネットワークを制御するには、どうすればよいですか。

A. クラスターを別のVPC内で実行し、VPCピアリング機能を使用して接続する。
B. Amazon Redshiftクラスター内に、特定のネットワーク上のユーザーに対応するデータベースユーザーを作成する。
C. クラスターセキュリティグループを作成し、特定のネットワークからのアクセスを許可する。
D. VPN経由で共有サービスネットワークに接続するネットワークにのみ、アクセスを許可する。
答え: C

解説:

「Redshiftクラスターにアクセスできるネットワークの制御」なので、VPC内の制御はこの選択肢ではセキュリティグループが正解です。
VPCピアリング、VPN経由の場合でも、VPC内のクラスターやインスタンスに対するネットワーク制御はセキュリティグループで許可するポートと送信元だけを設定します。

第10問

Q10. あるソリューションアーキテクトが、オンラインショッピングアプリケーションを設計しています。このアプリケーションは、ELB Application Load Balancerの内側にあるEC2インスタンス上のVPC内で動作します。EC2 インスタンスは、複数のアベイラビリティーゾーンにまたがるAuto Scalingグループ内で動作します。アプリケーション層では、顧客の管理下にあるデータベースクラスター内のデータに対する読み取りと書き込みを実行する必要があります。インターネットからデータベースにアクセスできないようにする必要がありますが、クラスターはインターネットからソフトウェア更新プログラムを取得できる必要があります。これらの要件を満たす VPC 設計はどれですか。

A. アプリケーション層とデータベースクラスターの両方をパブリックサブネット内に配置する。
B. アプリケーション層をパブリックサブネット内に配置し、データベースクラスターをプライベートサブネット内に配置する。
C. アプリケーション層と NAT ゲートウェイをパブリックサブネット内に配置し、データベースクラスターをプライベートサブネット内に配置する。
D. アプリケーション層をパブリックサブネット内に配置し、データベースクラスターとNAT ゲートウェイをプライベートサブネット内に配置する。
答え: C

解説:

A.はパブリックサブネットにデータベースクラスターを配置しているので、「インターネットからデータベースにアクセスできないようにする」要件を満たしていません。
B.はデータベースクラスターをプライベートサブネットに配置しているので、「インターネットからデータベースにアクセスできないようにする」要件を満たしていますが、「クラスターはインターネットからソフトウェア更新プログラムを取得できる必要があります。」を満たしていません。
C.はパブリックサブネットにNATゲートウェイが配置されているので、データベースクラスターはNATゲートウェイ経由でインターネットからソフトウェア更新プログラムを取得できます。
D.はNATゲートウェイをプライベートサブネットに配置してしまっています。この構成ではデータベースクラスターからNATゲートウェイにルートがあったとしても、その先のインターネットへのルートがありません。

ちなみに特別な理由がなければ、アプリケーション層のAuto Scalingグループもプライベートサブネットに配置して、外部の攻撃から保護できます。

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第2版」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト ［DVA-C02対応］ 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。