AWS認定ソリューションアーキテクト – プロフェッショナルレベル 試験に合格しました。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

 こんにちは。hafoc と申します。

 掲題のとおり、昨日 AWS認定試験のソリューションアーキテクト – プロフェッショナルレベルにギリギリで合格しました。

トピックレベルのスコア

総合スコア: 65%
トピックレベルのスコア:
1.0 High Availability and Business Continuity: 41%
2.0 Costing: 50%
3.0 Deployment Management: 87%
4.0 Network Design: 75%
5.0 Data Storage: 66%
6.0 Security: 68%
7.0 Scalability & Elasticity: 61%
8.0 Cloud Migration & Hybrid Architecture: 71%

 
 合格ラインは65%といわれているようなので、ほんとうにスレスレです。あと 1 問間違ってたらアウトでしたね…。
 こんな成績の自分が言うのも気がはばかられるのですが、受験にあたってやったことや出題内容で印象に残った点などを下記まとめておこうと思います。

試験前にやったこと

 下記に列挙したとおり、すでにAWS認定試験に合格された方々のブログエントリやQiitaの記事が多数あります。

 上記の各記事にもあるとおり、ドキュメントを読むことや実際に自分で手を動かしてみることがメインとなります。ただ今回の場合は自分はあんまり手を動かせておらず、ほとんど資料を読んで済ますだけになってしまっていました。

模擬試験は必須

 模擬試験は必ずやりましょう。AWS認定試験については今のところ対策問題集などは存在しません(数問のサンプル問題がある程度)。なので、実際にどんな問題が出るのか、その手ごたえを事前に実感するためには模擬試験を受けるほかに手立てはないのです。

「うっわこれ想像以上に難しくね? 手も足も出ねえよ!」
「けっこう自信持って解いたつもりなのに採点みたらボロボロだった」
「こんなサービス使ったこと無いけどそれを問う問題が次から次へと…」

といったふうに、出題内容と自分のスキルレベルの間の落差や、自分にどの分野の知識が足りていないのかなど、本試験に向けて補うべきものが見えてくると思います。

 ただ、模擬試験は時間・問題数が本試験の半分程度なので、本番での時間配分の参考にはならない点には注意したほうがよいかもしれません。本番は170分=2時間50分もの長丁場で問題数も多く、集中力の維持に苦労します。

トラブルシューティングを読む

 読むべきドキュメントはほかの合格者の方々のブログエントリに多数記載がありますが、私の場合は、各サービスごとの「よくある質問」「トラブルシューティング」をよく読み込みました。
 AWSの公式ドキュメントのなかにある「よくある質問」「トラブルシューティング」のページに記載されている内容は、つまるところ「ユーザーがよくハマるところ」だと思います。ですがそれは裏返せば、試験の出題者にとっては「ハメどころ」でもあるとも言えるわけです。
 なので私は「出題者が問うとしたらどのあたり狙ってくるかなー」という邪な下心をもってトラブルシューティングの各項目を読んでいました。

 これはとても個人的な意見なのですが、「これがベストプラクティスです!」というキレイな設計を多く見せられるよりは、そうでない設計を見せられて「この設計はここがダメでこうしてハマりました」という失敗事例にたくさんあたるほうが、私個人としては得るものが大きいように思います。単に私がひねくれた人間だからかもしれませんが…。

試験中に意識したこと

 本試験では問題数が多いうえに設問も選択肢もとにかく文章が長く、読んで内容を理解するだけでもたいへんですが、下記のようなことを意識しました。小手先のテクニックっぽくてアレですけど。

除外できる選択肢を見つける

 模擬試験を事前にやっている際に見かけることがあったかと思うのですが、選択肢中に「明らかにおかしい」ものがある場合があります。たとえば

「ELB を EIP で設定する。~(中略)~そのEIPをポイントする Route53 A レコードを設定する」

とかいう記述があれば、設問を読む前であっても「あれそんなことできたっけ?」と思うわけです。
 ざっと見渡してみて、こういう選択肢を早期に考慮から除外できれば楽になります。

選択肢間の差分を見つけて違いの意味を考える

 複数の選択肢がほとんど同じ文言で一か所だけ違う、という場合があります。たとえば

 「ELB の背後にそれぞれ 3 台の EC2 が複数の AZ にデプロイされているウェブ階層、~(中略)~、およびMulti-AZ RDS。」
 「ELB の背後にそれぞれ 3 台の EC2 が複数の AZ にデプロイされているウェブ階層、~(中略)~、および別のAZにリードレプリカでデプロイされたRDS。」

のように、文言は最後の一節まで内容がほぼ同一で、最後のRDSの部分だけが違っているパターンなどがあります。こういうときはその差分の箇所が大きなカギになっていることが考えられます。

 そこで、長年レガシーなサーバーインフラの面倒を見てきた人なら嫌々ながら身につけているであろう、目diff・目grepスキルの出番です。選択肢をすばやく目で走査して、どこまでが同じことを言っててどこからが違うのか、文言が同じ箇所・異なっている箇所を整理し、その違いがどういう意味を持つのかを考えましょう。

設問文中で何が求められているのかを確認する

 設問文中で、この設問の解答には何が求められているかを明示的に示している場合があります。たとえば、高可用性、耐障害性、コストダウン。あるいは導入までのスピードが求められているかもしれません。
 また設問文中で、

「数日中にまた高負荷がやってくることが予めわかっているので、それまでに対応が必要」
「RTOはx時間以内」

など、満たさなくてはならない制約が付いている場合もあります。その場合は、選択肢がその要求や制約条件に沿っているかどうか、が選択の基準となります。障害時のバックアップからのデータ復旧が2時間以内、という制約があれば、バックアップデータが Glacier に置いてあるような選択肢は外れます。

時間配分

 こればっかりは人それぞれだと思います。上述のとおり、模擬試験は本試験の半分程度の時間・出題数なので、あまり本試験の時間配分の参考にはなりません。
 私の場合は、まず80問全体をざっくり回答し終わった時点で残り50分、ただし「あとで見直す」にチェックを入れた設問が58問あって、その58問を順番に再度検討しおわった時点でちょうどタイムアップとなりました。

出題内容

 受験したのは昨日なのに、すでにだいぶ頭の中から抜けて行ってしまっています。ですが印象に残っている点だけ…

Direct Connect, VPN

 模擬試験と比べ、本試験では Direct Connect や VPN に関する問題が思った以上に多かったと思います。オンプレ環境とAWS環境とを接続し、うまく共存させる能力が求められているようでした。BGPについての知識を問われる設問もあったかと。
 Direct Connect や VPN を用いたオンプレ環境とAWS環境の共存、私はそういう案件やったことないので、いちおう事前に勉強はしていたのですが難しかったです。

DynamoDB, CloudFront

 設問文中に頻出します。ただ、これらのサービスの内容が直接回答に関わってくることはなかったかと思います。むしろ、Auto Scaling、ELB、VPC、EC2、S3 などの基本的な構成要素と同じく DynamoDB も CloudFront も

「こんなのの扱い方は知ってて当然、アソシエイトじゃなくてプロフェッショナルレベルなんだし、いまさらこれらの機能について問う必要もないでしょ」

といった空気をひしひしと感じます。
 ただ、「既存のオンプレ環境を単純にAWS上へ移行するだけ。物理サーバーは同数のEC2へ、DBはRDSへ」といった単純な置き換え案件しかやったことがないようだと、 DynamoDB も Cloudfront もあまりなじみがない、ということはありうるかもしれません(というか、私がそうです)。
 このあたりの知識がないようであれば、実際に手を動かして動作させてみる、などして補っておきましょう。

Kinesis

 模擬試験だと Kinesis の出題ほとんどなかったように思うんですけど、本試験では3~4問くらいは出ましたね…。
 私の場合は Kinesis について概要しか知らなかったので、設問文中に「ストリームを~」「リアルタイムに処理~」とかいう文言があったら「あーはい Kinesis ね」といった感じで Kinesis 使ってる選択肢があればそれを選んでたんですが、もちろんそんないい加減なことで良いはずはなく、ちゃんと勉強して理解しておかねばならなかったと悔やまれるところです。

Simple Workflow Service

 これも模擬試験だと出題なかったように思うんですけど、本試験では2問くらいに出ました。概要だけしか知らなかったので、迷ったあげく自信の無い回答をしてしまいました。

 私からの受験報告は以上となります。

 170分も集中して頭を使ったのは久しぶりなので今日は抜け殻となっています。今後はAWSを用いた案件に関わることも増えてくるはずなので、次の更新時期にはもっと余裕をもってパスしたいところです。ではまた。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

SNSでもご購読できます。

コメントを残す