本記事はAP Tech Blog Weekのものになります。

こんにちは、クラウド事業部の中根です。

文章が長く難しいことで知られるAWS SAPですが、みなさんはどのように攻略していますか？
私は長文が苦手で、最初は3時間ほとんど使いきらないと間に合わないレベルでした。
そこから試行錯誤して、これから紹介する解き方に落ち着いた結果、2時間程度で合格することができました。

本記事では、私がAWS SAPの問題を解く時のプロセスを言語化してみます！
文章が長めの他の認定試験でも使えると思います。

注意点
解き方のポイント
実際に解いてみた
SAP対策のおすすめリンク集
おわりに
お知らせ

注意点

以下は扱いません。

小技やテクニック
勉強方法やおすすめ教材（最後にリンク集だけつけました）

解き方のポイント

主に２つあります。

①紙に書いて整理

問題文を読みながら、必要な情報を紙に書きだします。
紙に書き出すので、テストセンターでの受験が前提になります。

必要な情報は、主に以下です。

何を聞かれているのか？（コスト、可用性など）
アーキテクチャ図（汚くてもわかれば良い）
制約や条件
- 例：処理にかかる時間、CIDRブロックの重複有無など

なぜやるのか

時間の短縮と凡ミスを防ぐ効果があると考えています。
やらない場合は、上記の情報を頭に詰め込んだ上で、選択肢と向き合う必要があります。
特にSAPの問題は文章量が多く、脳の一時記憶（ワーキングメモリ）では処理しきれない情報量になることが多いです。

問題文の把握をするのは、紙を使う、使わないに限らず同じです。
ただ、問題文の情報を維持したまま、以下のような情報も処理していくのは、非常に困難ではないでしょうか？

選択肢の把握
学習した知識の思い出し
選択肢の正誤判定
判断に迷う選択肢とその理由
時間配分
雑念（この後何しようかな、疲れた、あの問題違ったかも、などなど）

紙に書いていないと、忘れた時点で読み直しによるタイムロスや誤答の可能性が発生します。
紙に書くことによって、忘れてもメモを元にすぐに把握しなおせます。

書き出すので一見時間がかかりそうですが、読み直す頻度が格段に減るので、結果的に書き出したほうが早いことが多いです。

②まずは消去法

紙に書きだしたら、選択肢を順番に見ます。
いきなり正解を選ぼうとはせず、確実に不正解と言えるかを判断することに集中します。

消去する際には、大きく２つのパターンがあると思ってます。

できない事が書かれている
- そのサービスでできない
  - 例：GuardDutyを導入し、悪意のあるアクセスを~~ブロックする~~→監視、検知まで
- 問題の制約にひっかかるのでできない
  - 例：処理に1時間かかる→Lambdaは使えない
  - 例：S3のファイルをすぐに参照したい→Glacier Deep Archiveストレージクラスは使えない
聞かれている事を無視している
- 例：可用性向上の手段を聞かれているのに、パフォーマンス改善だけの選択肢
- 例：障害解決の問題で、接続には問題がないと書かれているのに、接続エラーを修正する選択肢

１周して選択肢が減ったら、その中で比較検討して、最善の選択肢を選びます。
この時は、何を聞かれているのか？の部分を強く意識しています。
一番最後は勘です！

なぜやるのか

消去法自体は王道なのですが、「なぜ選択肢を2周するようなやり方にしているのか？」という点が気になるのではないでしょうか。
これは、選択肢の消去判定に集中できるようになるからと考えています。

消去判定もしながら正解を選ぼうとした場合、「この選択肢は間違いか？」で削除できなかった場合に、脳の負担が増えます。
具体的には「ここの表現微妙だな」「もっといい選択肢ありそう」のような、その選択肢に対する所感を覚えておくことになります。
ワーキングメモリが圧迫された状態だと、後半の選択肢に対しての判断が鈍る気がしています。
少し極端な例だと、以下のイメージです。

別の例として、設計書などの長い文章の見直しを行う時を考えてみましょう。
以下のようなチェック観点を、「全項目を1周で行う」、「1項目1周ずつ行う」、だとどちらの方が脳への負荷は軽そうでしょうか？

誤字・脱字がないか
表現が統一されているか
仕様が正確に表現されているか
書くべき項目が網羅されているか

個人的には、1項目1周ずつ行う方が負荷は軽そうですし、ミスも少ないと考えます。
試験問題は設計書ほど長くないので、全項目を1周もできなくはないし、それで済む場面も確かにあります。
それでも、長丁場かつ正確性が求められる試験なので、脳への負荷をなるべく抑えて温存するやり方をおすすめします！

例外

もちろん例外はあるので、軽く触れておきます。
一時記憶をあまり使わなくて良さそうな場面は、紙に書いたりしないです。

文章量、選択肢の文章量が少ない（文章3行、選択肢1行程度）
文章読んでいる時点でベストプラクティスが頭に浮かんだ
見たことある問題

実際に解いてみた

どのように解いているかを類題で再現してみました。

問題

ある企業は、AWS上にあるアプリケーションを管理しています。
このアプリケーションは、1つのEC2インスタンスで実行され、
データベースに単一の Amazon RDS for MySQLを使用し、
インメモリキャッシュにAmazon ElastiCache for Memcachedを使用しています。
EC2のインスタンスサイズは、m5a.largeを使用しており、CPUやメモリの使用状況に問題はありません。
ソリューションアーキテクトは、アーキテクチャを改善し、障害から最小限の停止時間で自動的に復旧できるようにする必要があります。
移行に伴うコストは許容できますが、運用コストは抑えたいと考えています。
推奨するべきステップはどれですか？（３つ選択）

選択肢

EC2インスタンスを追加で2つ作成する。Elastic Load Balancerを使用して、複数のEC2インスタンスにトラフィックを分散する。
Elastic Load Balancerを使用して、複数のEC2インスタンスにトラフィックを分散する。EC2インスタンスが、最小キャパシティが2のAuto Scalingグループに入っていることを確認する。
MySQL互換のAmazon AuroraをマルチAZ構成で作成し、移行する。
DBインスタンスをマルチAZ配置に変更する。
ElastiCache for Redisに移行し、マルチAZを有効化する。
ElastiCache for MemcachedのマルチAZを有効にする。
STEP1. 紙に書く

文頭から読みながら、必要そうな情報を書き出していきます。
読みながら浮かんでくる主な思考を表現すると、以下の感じです。
浮かんだ思考をメモしておくイメージです。
（上図内のアーキ図引用元：https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-Scalable-2022-reg-event.html?trk=aws_introduction_page）
実際に書き出してみた図がこちらです。

本番ではこれくらい殴り書きです。
何書いてあるかわからないと思いますが、脳内フィルターを通して、このように見えています。

STEP2. 消去法

順番に見ていきます。
1. △。他の選択肢次第では、間違いとも言い切れない。
2. 〇。
3. 〇。
4. 〇。
5. 〇。
6. ×。MemcachedはマルチAZはできない。

STEP3. 最善の選択肢

複数選択の問題にありがちですが、選択肢を見ていく段階で、だいたい比較すべき組み合わせも見えることが多いです。
今回だと、1と2（EC2インスタンス）、3と4（DB）、5と6（ElasticCache）ですね。
（たまに組み合わせではなくて、1選択肢内で完結している正解を2つ選ぶパターンもあるので注意）