AWS資格

AWS SAPに挑戦｜SAA持ちが過去問を見て絶望。そこから立てた攻略プラン【挑戦中】

「AWS SAA（アソシエイト）に受かったから、次はプロフェッショナル（SAP）へ」——そう決めて挑戦を始めた私は、いきなり出鼻をくじかれました。試しに過去問・サンプル問題を見てみたら、その難しさに圧倒されてしまったのです。

正直に言います。この記事を書いている時点で、私はまだSAPに合格していません。それどころか、本格的な勉強もこれからです。今いるのは「敵の手強さを知って、攻略プランを立てた」スタート地点です。

でも、だからこそ書けることがあります。「SAA持ちがSAPに挑むと、最初に何に圧倒されるのか」「そこからどう攻略を組み立てるのか」——合格自慢ではない、これから挑む人と同じ目線の、リアルタイムの記録です。
実際にやってみた結果は、このページに追記していきます。

1. なぜ、SAAの次にSAPを選んだのか

私がSAPに挑戦する理由は3つです。

  • クラウドの設計力をもっと深めたい——アソシエイトの一歩先へ
  • SAAに受かった流れで、自然な次のステップとして
  • 業務で、より高度な知識が求められる場面が増えてきた

特に大きいのは「業務で必要」という実感です。現場でアーキテクチャの判断を求められるほど、SAAの知識だけでは足りないと感じる場面が出てきました。その穴を埋めたい——それがSAPを選んだ一番の動機です。

2. SAA持ちでも、SAPは「全方位的に」難しい

正直、SAAの感覚で過去問に臨んで、面食らいました。SAPは難しさの「種類」が違います。私が見て実感した壁は4つです。

  • 問題文がとにかく長い。一問あたりの文章量が多く、読解するだけで疲れます。「何を聞かれているのか」を掴むだけで集中力を持っていかれる。
  • 出題範囲が広く、深い。SAAより扱うサービス・設計パターンの幅が格段に広く、しかも一つひとつが深い。
  • 実務寄りの複雑なシナリオ。複数アカウント・移行・大規模設計など、現実的で込み入った状況を前提とした問題が多い。
  • とにかく量が多く、合格ラインが高い。覚えること・理解することが膨大で、「これで足りるのか」という不安がついて回る。

そして個人的に一番きついと感じたのが、問題文と選択肢の「長さ」と「ひっかけ」です。長い問題文を読み解いた先に、選択肢までどれも長い。しかも技術的にはどれも「できそう」に見えて、その中から要件に最も合う一つを選ばせる——明確なひっかけが仕込まれています。

SAAが「地図と共通言語」を得る試験だとすれば、SAPは「その地図を使って、複雑な現実をどう設計するか」を、長文とひっかけの中で問われる試験——というのが、過去問を見た今の私の実感です。

3. そこで立てた、SAPの攻略プラン

圧倒されたままでは前に進めないので、攻略プランを立てました。これから、この方針で挑みます。

使う教材（演習＋公式を中心に）

SAPは書籍が少なく、演習（アウトプット）と公式資料が中心になります。私が候補として選んだのは次のラインナップです。

  • AWS公式 Skill Builder（SAP Exam Prep）＋ 公式模擬試験……出題傾向を公式で掴む
  • Udemyの SAP-C02 模擬試験問題集……本番形式で大量に演習する（SAPは演習量が命）
  • AWS WEB問題集（CloudLicense 等）……隙間時間の反復演習に
  • AWS Black Belt／ホワイトペーパー……範囲が広く深いので、サービス別の公式資料で穴を埋める

（実際に使った感想は、進めながらこのページに追記していきます）

「長文・ひっかけ・長い選択肢」をどう攻略するか

最大の壁である読解とひっかけには、こう挑むことにしました。

  1. 設問（最後の問い）を先に読む。「何を聞かれているか」を把握してから本文を読み、読解の迷子を防ぐ。
  2. 要件キーワードに着目する。「コスト最小」「運用負荷最小」「可用性最高」「最小の変更で」など。正解はこの要件に最も合うもの。技術的に可能でも要件に合わなければ不正解——これがひっかけの正体だと考えています。
  3. 消去法で削る。要件に反する一語を見つけて、長い選択肢を切っていく。
  4. とにかく演習量で慣れる。長文への耐性は、模試を繰り返して体に染み込ませるしかない部分が大きい。

4. 学習ログ：まず「ネットワーク領域」から（随時更新）

攻略プランに沿って、まずは出題範囲の中でも実務に直結し、私が一番不安だった「ネットワーク領域」から手をつけました。最初の1週間で痛感したのは——単体では分かっていたつもりの知識が、複数サービスが絡む統合問題になると崩れるということです。特に派手につまずいた3つを、それぞれ独立した記事に深掘りしてまとめました。

3つに共通していた失点は、「知識の穴」ではなく「設問の読解事故」でした。向き・対象・数を、答える前に数える——この1点がW1（1週目）の最大の学びです。そして同じ「読解事故」の癖は、この後に進んだマルチアカウント、そして移行の各領域でも形を変えて現れました（下記）。

5. 学習ログ：マルチアカウント領域（随時更新）

ネットワークの次は、大規模設計の前提になる「マルチアカウント（複数アカウント統制）」領域です。1つのアカウントに何もかも詰め込む発想から抜け出し、「なぜ分けるのか」「どう権限を効かせるのか」でつまずきました。ここも独立した記事に深掘りしています。

6. 学習ログ：移行（マイグレーション）領域（随時更新）

ネットワークの次に着手したのが、出題比率の大きい「移行（マイグレーション）」領域です。ここは自己診断が最も低かった最弱分野で、サービスの選び分けと公式用語の定着に苦しみました。つまずいた点を、独立した記事に深掘りしてまとめています。

まとめ：これは「挑戦のスタート地点」の記録

正直に言えば、私はまだSAPの入り口に立ったばかりで、合格の保証はどこにもありません。でも、敵の手強さを知り、攻略プランを立てたこの瞬間を、同じようにこれからSAPに挑む人と共有したいと思いました。

この先、実際に勉強を進めて分かったこと・つまずいたこと・合否は、このページに追記していきます。一緒に「シフト」していきましょう。

※そもそもAWS資格の難易度がどれくらい違うのかは、実スコアで比較した記事にまとめました。CLF 740／SAA 698→743／DVA 752／SOA 609——5資格6回ぶんのスコアレポートを全部公開しています。SAPに挑む前に、アソシエイトがどう割れたかを見ておくと目安になるはずです。

※その前段にあたるSAA（アソシエイト）の合格体験記はこちらにまとめています。

※そもそも私がオンプレミス環境からクラウド（AWS）インフラエンジニアへ転職した経緯はこちらにまとめています。

-AWS資格