2022/09/26

テクノロジー

AWS認定 Solution Architect Professionalに合格した話

この記事の目次

    はじめに

    こんにちは。インフラソリューション部(現デジタルテクノロジー戦略部)のU.Jです。
    今回はAWS認定 Solution Architect Professionalに合格した話をしたいと思います。

    11月に試験内容更新されてしまいますが、今後受ける誰かの参考になれば幸いです!
    ※試験の形式や方向性自体は、現在の内容と同じです。(詳細

    AWS認定 Solution Architect Professionalとは

    https://aws.amazon.com/jp/certification/certified-solutions-architect-professional

    これを読んでいる人にわざわざ説明するまでもないとは思いますが…
    AWSの専門知識やスキルを有していることを認定する、AWS公式資格「AWS認定」のうち、専門領域を絞らず広く全体の知識・経験を問う「Solution Architect」のProfessional版です。
    以下SAPとします。
    (※ERPのアレではない。アレはアレでSAP on AWSという認定試験があるので紛らわしいですが。)

    Solution Architect Associateとの比較

    基礎的な知識・経験の習得証明としてはSolution Architect Associate(略してSAA)が存在しますが、SAPでは

    • SAAより実践的な知識が求められる
      • サービスの選定だけでなく、具体的な細かい設定手順まで言及があるケースも
    • 問題数・1問あたりのボリュームが多い
      • 設問はほぼ全て既存構成や要件の説明で始まり、複数サービスの設定を組み合わせて構成案や改善案を出す内容
    • 公式ではSAAは「スケーラブルな構成の構築経験を1年以上」、SAPは「クラウドアーキテクチャの実務経験を2年以上」としている
      • SAAと比べて、よく見る三層構成ではないパターンがかなり増える

    といった違いがあります。

    Specialityとの関係

    AWS認定のカテゴリにはAssociate, Professionalの他にSpecialityがあり、例えば機械学習、セキュリティ、データベースなど個別領域の深い知識・経験はそれぞれ対応する試験があります。
    Specialityが各領域の専門サービスの利用法を掘り下げるのに対して、SAPはクラウドアプリケーションのアーキテクチャ設計を軸に据えつつ、AWS全体を見てサービスの選定やオプション設定の方針を問う、、、みたいなイメージです。
    パワ〇ロのサクセスと栄冠ナインみたいなもんですかね(わかりにくい喩え)。

    受験した背景

    実は2年ほど前にノリで受けて一回落ちてます。
    2019年夏にSAAに合格して、秋に同僚がSAPの学習集中プログラムを見つけて、ITソリューション部(当時)と商用基盤部(当時)の若手としてそれぞれAWSスキルを先導できるようになっておいて損はないよね、みたいな理由で学習し始めたのがきっかけです。

    で、無事2人とも不合格となり、その後再受験を考えているうちにコロナだのなんだの色々あって機会を逃してモチベも下がっていたのですが、

    • AWSの構成や移行に関して技術部隊として一定水準以上の知識を求められるようになったこと
    • AWS統合PJでOrganizationsによる統制なども手掛けるようになったこと
    • SAAが3年で失効したこと

    等々ありまして、SAAを更新するくらいならSAP受けようということで受験に至りました。

    学習教材

    学習の流れ

    • 学習集中プログラムに沿って出題される領域を把握しておく
      • 他に良い参考書があればそれでいいかもしれない
      • 上記の問題集の前半などでもまとまってはいるが、少々簡潔すぎるきらいがある
    • 領域ごとに知らないサービスの概要を読んで自分の中で整理
    • 一度公式模試を解き、求められる知識の粒度を把握
    • 触れるサービスは直接触る
      • 業務で触れる場合は最大限活用する
    • 触れないものは問題集の解説をベースに、DevelopersIO等の事例記事を読み込む
    • 読み込んだ知識を問題集で整理、補強
      • わからない部分、ちょっとでも疑問に思う部分があればリファレンス読んだり、実際にアカウントの設定画面見てみたり
    • 問題集末尾の模試で仕上げ
      • 3時間かかる模試を受験前日の夜21時から解き始める人間の屑

    1回目の受験時はちょこちょこと4ヶ月くらいやってたんですが、今回は仕事の忙しさもあり、問題集を中心に1ヶ月弱程度の勉強期間でした。

    試験について

    1回目・2回目どちらもテストセンターで受けました。身分証明書が2種類いる点に注意。
    テストセンターは場所によってオンラインカメラのリアルタイム監視があったりなかったりします。
    1回目はありましたが、不具合発生時にカメラの向こう側の人と英語でコミュニケーションを取らなければならず、姿勢なども細かく見られそうなので、無い所の方が良いかなと思いました。
    あとメモ用の筆記具がボールペン+紙だったりホワイトボード+マジックだったり、ばらつきがあるようです。よくわからないので運です。

    試験時はあらゆる私物を没収されるので、サービスのリリース直後など緊急連絡があり得る際に行くのはおススメしません。

    試験中の感想

    • とにかく時間がない
      • 180分で75問なので1問あたり2.4分
        • こう書くとSAA(65問で130分)より余裕はあるんですが、ほとんどが4~6行にわたる長文の上、前後の問題につながりが無いため切り替えが大変で集中力が持たないです。
      • 他所の体験記を読むと「とにかく反射で答えられる問題を増やして2時間ちょっとで一旦解ききれるように~」とか書いてありましたが、そこまで対策できていなかった自分は、解き終わった時点で残り5分切ってました。
    • 時間があったら楽勝とは言ってない
      • 細かいオプション項目を覚えていなかったりすると絞り切れない選択肢がかなりあります。
    • 筆記具は一度書いたら消せないので使うタイミングがよくわからなくなる
      • 結局、データ移行の問題で転送量計算するのに使ったくらいでした。
    • 大体どこのテストセンターにも、周囲の音シャットアウト用のヘッドホンがあるが、1時間もつけてるとこめかみのあたりが痛くなってくる
      • 会場がよっぽどうるさいならともかく、そうでないならつけない方が良いのでは。
        • 自分の頭がでかいだけかもしれない。

    結果

    完全勝利

    試験のポイント(私見)

    自分なりに得た知見をいくつか。

    わからなくても長時間悩んでないで直感を信じる

    時間配分がシビアなので、これがすごく大事。
    BlackBeltでも「(多少わからない所があって直感になっても)ええんやで」って言ってました。
    それを織り込み済みで問題作成や採点をしてるというか、直感でわかるということは考え方が多少なりとも身についてる筈、という考えの様子。

    問題が何を重視しているのか必ず確認する

    機能の実現だけであれば複数の選択肢が当てはまる場合、「最もコスト効率に優れた設計」「最も可用性・信頼性の高い設計」「最も既存のアプリケーションの改修が少ない設計」など重視してるポイントが鍵になります。
    特にRTO, RPOが提示された場合は、(それらを満たした上での)コスト効率を重視していることが多いです。
    RTOに余裕があればホットスタンバイは必要ないし、RPOに余裕があればDBは同期でなくスナップショットからの復旧で充分かもしれません。
    問題文を必ずよく読みましょう。

    各サービスの設定オプションや作業手順まで目を通しておく

    感想の所でも書きましたが、細かいオプション項目を覚えていなかったりすると絞り切れない選択肢がかなりあり、「サービスの概要と基本的なユースケースはわかっている」程度のレベルだとあっさり討ち死にします。。

    また、「VPC内のサブネットのCIDR割当を変更したい場合に直接変更できるか、一度削除する必要があるか」みたいな、構成図だけ覚えていると盲点になるようなことも問われます。

    サービス単体ではなく、他のサービスと組み合わせたユースケースを叩きこんでおく

    「1つのサービスの理解だけを問う問題」と「複数サービスの適切な組み合わせと設定を問う問題」がありますが、割合としては圧倒的に後者が多いです。
    よく見かける組み合わせ(SQS + LambdaとかDirect ConnectとVPNの二重化とか)については構成図だけでなく、どういう理由でその組み合わせになっていて、そのためにどういう設定が必要か、という所まで落とし込んで理解しておく必要があります。

    得意分野を1つ以上作っておく

    1分未満で回答できるような分野があると、多少時間が厳しくても心に余裕ができます。
    自分の場合、Organizations絡みやIAM系は考えずに反射で回答できるようにしてました。

    問題の状況設定に関わらず切り捨てられる選択肢を増やしておく

    例えば以下のような記述の選択肢は、そもそもサービスの仕様に反しているため、前提に関わらず無条件に除外できます。

    • ~のデータを、Kinesis Firehoseを経由してLambdaで加工する
      • →FirehoseはS3、Redshift、ES(OpenSearch)にデータを流し込むためのサービスであって、ストリーミングしながら加工するみたいなことはData Streamsの役目。
    • (CloudFront/ALBなど)に対して、Shield Standardを有効化する
      • Shield StandardはAWS側が対象の全リソースに対して自動で有効化しているものであって、手動で有効化する手順は存在しない。
    • RedshiftのノードをマルチAZに配置して~
      • 2022年7月現在、RedshiftはマルチAZ構成を取れない。
    • SystemsManager Parameter Storeにパラメータを格納し、定期的にローテーションする
      • ローテーションしたかったらSecrets Managerを使う必要がある。

    こういうのを秒で弾けるようになると、他の選択肢の検討をする時間に余裕ができるので、問題集などを解きながら武器を増やしておくのが吉です。

    ややこしい名称は必ず整理しておく

    例えば、

    • 「グローバルテーブル」(DynamoDB)と「グローバルデータベース」(Aurora)
    • 「IAMアクセスアナライザー」と「IAMアクセスアドバイザー」
      • たまにこれにTrusted Advisorも混ぜてくる
    • Transit Gateway、Direct Connect Gateway、Customer Gateway、Virtual Private Gateway

    などなど、「概念や用途は理解しているが名前を正確に覚えてない」という人を狙い撃ちにしてくる場合が結構あります。
    こういうので頭抱えたりすると精神的にもしんどい。

    頻出シチュエーションを押さえておく

    その時々で流行もあると思いますが、マルチリージョンによるDR対策が多いかなという印象。
    それに絡んでDBの選択、Route53のDNSラウンドロビンにおけるルーティングポリシーの設定、CloudFrontなど。

    また、マルチアカウントの話もちょこちょこ出ます。「部門に使わせるサービスを制限したい」みたいな、あからさまに「OrganizationsでSCP使え」って言ってる問題が結構出るので、SCPとIAMポリシーの関係をしっかり押さえておけばボーナス問題です。
    (とか余裕ぶっこいてるとBudget周りで引っかけがあったりしますが)

    まとめ

    落ちた時と合格した時であまり手応えに違いが無く、試験終了時に合格と表示されてもいまいち実感が無かったのですが、結果としては多少余裕のある点数を取れていたようでほっとしました。
    なんだかんだで2年の間の業務経験が活きたかなと思います。
    問題を解く上で「あ、これあの時業務で触ったアレだ!」となったケースも少ないながらありました。

    よく言われることかと思いますが、資格を取ること自体を目的とするのではなく、資格のために学習すること・知識や経験をつけることが大事です。
    その点で言うとSAPは比較的「机上での表面的な学習だけでは点が取り辛い」作りになっており、勉強のために実際にサービスに触れたり事例を漁ったりすることで実践的な力がつきやすいのかなと思います。
    SAPの問題=要件に合わせて構成を考える仮想体験であり、上で挙げたポイントもそのまま実際に構成を考えたりレビューする時の観点に繋がりますので、間違いなく業務に役立ちます。

    受験料が3万円と結構お高いので中々気軽には受けられませんが、試験に向けて資料を読み込んだり問題を解くだけでも充分実入りがあるので、興味のある方は是非トライしてみてください!!

    ※ちなみにマイナビでは、1回までは会社から受験料が出る「資格支援制度」がありますので、自己研鑽としてこの制度を利用する方も多いです

    以上、最後までお読みいただきありがとうございました!

    ※本記事は2022年09月時点の情報です。

    著者:マイナビエンジニアブログ編集部