18日間で5つのAWS認定資格を取得して得たもの
SAPの認定を皮切りに短期間で5つのAWS認定資格をとることができました。
今回はそれぞれの認定の取得状況、所感、取得することで得たもの等をまとめていきたいと思います。
ちなみにSAP認定の話は以下の記事で紹介しているので、ぜひ参考にしてみてください。
- SAP認定の記事
目次
取得状況と個人的な難易度
こんな感じです。
- 3月はとにかく詰め込みました。笑
- 「難易度」はあくまで個人的な観測で、経験と前提知識によって変わってくると思います
| # | AWS認定資格(※1) | 点数 | 取得日 | 難易度 |
|---|---|---|---|---|
| 1 | SAA | 848 | 2018/07/28 | ★★☆☆☆ |
| 2 | SAP | 873 | 2021/03/13 | ★★★★★ |
| 3 | CLF | 905 | 2021/03/21 | ★☆☆☆☆ |
| 4 | SCS | 891 | 2021/03/22 | ★★★★☆ |
| 5 | DVA | 914 | 2021/03/26 | ★★★☆☆ |
| 6 | SOA | 959 | 2021/03/30 | ★★☆☆☆ |
※1
SAA: AWS Certified Solutions Architect - Associate (SAA-C01)
SAP: AWS Certified Solutions Architect - Professional (SAP-C01)
CLF: AWS Certified Cloud Practitioner (CLF-C01)
SCS: AWS Certified Security - Specialty (SCS-C01)
DVA: AWS Certified Developer - Associate (DVA-C01)
SOA: AWS Certified SysOps Administrator - Associate (SOA-C01)
取得経緯
元々、SAAは3年ほど前に取得していたのですが、実務にありつけず悶々とした日々を過ごしていました。 それからしばらくしてAWSのお仕事が舞い込み、EC2、S3、Lambdaなどの基本的なサービスを触ることができました。 そんな中でキャリア上、資格取得が必要になったことと、ちゃんと身になっているか証明したいと思っていたことを踏まえて、上位の認定資格に挑むことに決めました。
タイトルの18日はSAPの認定日を起点にカウントしているため若干、盛っています。笑
実際にはその前にSAPの勉強期間が1ヶ月ほどあるので、トータルで1ヶ月半ほどです。
各認定資格の所感と得たもの
SAA
所感
得たもの
SAP
所感
得たもの
CLF
所感
得たもの
SCS
所感
- SAPよりももう少し深いセキュリティ系のサービス全般の知識が問われます
- 初めてのSpecialityでしたが、最後にボタンを押すまで合格した自信はありませんでした
- SAPの知識でカバーできる部分もそれなりにありますが、苦手な範囲があればBlackBeltや書籍で補完してから臨むのがオススメです
得たもの
- セキュリティは全体的に苦手意識が高かったので、受かることで自信がつきました
- 取得後にたまたま業務でセキュリティ系のAWSサービスの運用を検討する機会があり、知識を活かして検討を推進することができました
DVA
所感
得たもの
- 業務上、「この設定って入ってないけど大丈夫かな？」という点検ができました
- 個々のサービスに関してはアーキテクトよりも深い知識がつくため、実行上イメージが湧いていなかった構成提案等も自信をもって提案できるようになりました
SOA
所感
- 主に運用者目線でどう設定して上手く安定稼働させていくかという知識が問われます
- 他のアソシエイトやSAPのベースメントがあれば、その応用で答えを導き出せる問題の割合が多い気がします
得たもの
- 基本的にはDVAとほぼ同じですが、トラブル時の挙動と対処が分かるようになり対応力があがります
- 運用とセットで、どのような構成や設定にしておくべきか初期段階で考えられるようになることは非常に役に立つと思います
さて、次はDOPの取得を目指して勉強していきます！
もし取れたら、同じく取得を目指している方々の参考になるようにまた記事を書きたいと思います。
以上。
【AWSの呼吸 陸ノ型】AWS WAF V2での複合条件ルールの実現方法の例
AWS WAFは手軽にWAFを導入できて便利ですよね。
一方で複合条件の実現方法に悩むことがあったので、その辺のTIPS的なものを書きたいと思います。
基本的なことはすっ飛ばすので、WAFをまだ使ったことなくてよく分からないよ、という方は以下の記事が参考になるかと思います。
前提
さて、今回の話の前提ですが、デフォルトアクションがAllowで、明示的に拒否したいものはBlockルールを入れて拒否したいような場合を想定します。
例えばこんな場合にどうルールを作る？
接続元のIPアドレスがA、Bの場合は許可したいが、それ以外は拒否したいというような場合を例に挙げてみます。
ルールとしては「AまたはB以外だったら拒否」というような組み方が考えられると思います。
「Rule Visual Editor」では実現できないルールがある
上記のルールをRule Visual Editorで入れようとしても実現できません。
Rule Visual Editorでは先述したようなORをまとめてNOTする複合的な条件はサポートしていないためです。
例えば、下図のようにNOTを指定した場合は単一のIP Setしか指定できません。
じゃあIP Setに全部書いちゃえば？
IP SetにAもBも書いちゃえ！というのも一つの手です。 しかし、単一のIP Setに多くのIPアドレスを詰め込むと以下のような管理上の問題が出てくる可能性があります。
- IPアドレスの数が増えると何のIPアドレスなのか把握しにくくなる
- IPアドレスを意味のある単位（例えば拠点A、拠点B）などで分割したくなった時に困る
- 仮に部分的に分割して、ある程度の塊を複合条件用のIP Setに突っ込んだとしても同じIPアドレスを二重管理することになりメンテナンスが大変
また、IPアドレスに加えてリクエストパスに基づく制御がしたい場合も条件がネストするので、Visual Editorでは対応できなくなります。
ではどうするか？
「Rule JSON Editor」を使って、JSONで複合条件を書けば実現できます。
例えば、今回の例だと以下のように書けます。
IPアドレスA,BをそれぞれIP Setで定義しておいて、そのARNをJSON側から指定します。
{ "Name": "[your-rule-name]", "Priority": 0, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "[your-metoric-name" }, "Statement": { "NotStatement": { "Statement": { "OrStatement": { "Statements": [ { "IPSetReferenceStatement": { "ARN": "[ARN of IP Set A]" } }, { "IPSetReferenceStatement": { "ARN": "[ARN of IP Set B]" } } ] } } } } }
まとめ
- 例で挙げたような複合条件を実現したい場合は「Rule JSON Editor」が使える
- 接続元のIPアドレスに基づいて制御する場合、IP Setを意味のある単位で分割しつつ、Rule側でOR/NOT条件を使って指定可能
- 単一のIP Setに許可したいIPを全部書くやり方もある
以上。
【AWSの呼吸 伍ノ型】VPC Traffic Mirroringの注意点をまとめました
VPC Traffic Mirroringは使用上の制約がいくつかありますが、日本語の記事が少ない気がしたので書いておこうと思います。
目次
VPC Traffic Mirroringとは？
VPC内のネットワークトラフィックを任意のターゲットにミラーリングできるAWSマネージドサービスです。
どんなユースケースで使えるの？
ネットワークフォレンジックのようなセキュリティ要件でパケットデータを一か所に集約して保管・解析したい時などに活用できます。 例えば、以下の記事の中でミラーリングを構成している部分をAWSマネージドで代替することができます。
「SORACOM Air SIMのトラフィックをSORACOM Junction + Moloch + Amazon ESで可視化する | DevelopersIO」
構成イメージ
下図のような構成がとれます。
必要に応じて、Mirror Target側に3rd Party製のパケット解析ツールを入れることでパケットデータを管理できます。
Mirror Source：パケットの送信元
Mirror Filter：パケットミラーリングのフィルター
Mirror Target：パケットの送信先
- EC2インスタンスのENIまたはELBを指定可能
Mirror Session：実際にパケットを送信するためのセッション
詳細はこちらを参照してみてください。
「最新 – VPC トラフィックミラーリング – ネットワークトラフィックを捉えて検査する | Amazon Web Services ブログ」
注意点
Mirror Sourceはインスタンスタイプに制約あり
サポート対象はAWSのNitroインスタンス(A1, C5. M5, T3等)または一部の非Nitroインスタンスのみです。
サポート対象の非Nitroインスタンスはこちらをご参照ください。
「一部の非 Nitro インスタンスタイプでの Amazon VPC Traffic Mirroring のサポートを開始」
Mirror Sessionはインスタンスごとに作成する必要がある
特にAutoScalingを用いて水平スケーリングを実施しているような環境ではインスタンスの起動とともにMirror Sessionを作成する必要があります。 例えば、ユーザデータやLambdaを用いてインスタンス起動を契機に自動作成する方法などが考えられるかと思います。
なお、スケールイン時はインスタンスがTerminateされてENIが削除されるタイミングでMirror Sessionを勝手に削除してくれるため、削除処理を別途用意する必要はありません。
全てのプロトコルをミラーリングできるわけではない
以下はミラーリングできないようです。
トラフィックのMTUを考慮する必要あり
Mirror SourceとなるENIのMTUをMirror TargetとなるENIのMTUより54byte小さくする必要があります。 これはVPC Traffic MirroringではパケットがVXLANでカプセル化されて送信されていて、その分のオーバヘッドとして54byteが必要になるためです。 例えば、Mirror SourceのMTUが9001だった場合、54byteを差し引いた8,947byteにMTUを設定します。
出典
今回ご紹介したような考慮点はこちらに書かれていますので、参考にしてみてください。
Traffic Mirroring quotas and considerations - Amazon Virtual Private Cloud
以上。
【とはメモ#4】AWSサービス名の頭に付く"Amazon"と"AWS"の違いとは？
AWSのサービスって、例えばAmazon S3とAWS Lambdaのように頭にAmazon”が付くサービスと""AWS"が付くサービスで分かれていますよね。
AWSサービスを使われてる方は一度は疑問を持たれたことがあったりするのではないしょうか？ 私の場合はお仕事でドキュメントに正しい名前を書きたいと思った時にAmazonだっけ？それともAWSだっけ？と気になることが稀に訪れます。 （結局、普段呼び慣れている略称で定義して書いちゃうことが多いのですが・・）
ということで、今回はその違いを調査してレポートしたいと思います。
目次
秒で答えが見つかる
調査を開始して5秒で辿り着いてしまいました。。
まずは何はともあれGoogle検索！ということで「aws amazon 違い」でググったら、速攻で出てきました。
こちらの方が既にブログで書いてくれています！
「AWSのサービス名がAWS始まりとAmazon始まりの謎【解決】」
これで終わってもいいのですが・・わざわざ「記事を書く」ボタンを押して書き始めてしまったので、一応私なりにまとめておこうと思います・・泣
で、違いとは？
違いは「そのサービス単独で機能を提供できるかどうか」ということのようです。
ただし、後述するように概ねこんな感じというだけで、例外もあるとのこと。
| Amazon | AWS |
|---|---|
| 単独で機能する | 他のサービスとの組み合わせで機能する |
原文はこんな感じ
このルールっぽいものが書かれているのは、みんな大好きstackoverflowの一コマです。
John Rotensteinさんという方が質問者の回答にこう答えています。
（以下、原文の抜粋）
質問：
I notice that some Amazon Web Services are called "AWS XXX" (for example AWS Lambda) and others are called "Amazon XXX" (for example Amazon RedShift). Why? There is any differences?
回答：
The pattern is that utility services are prefixed with AWS, while standalone services are prefixed by "Amazon".
Mind you, this doesn't apply to everything. For example, Amazon EBS can only be used with Amazon EC2, yet it has an "Amazon" prefix.
超テキトーに翻訳した版
質問：
"AWS XXX"と"Amazon XXX"で呼ばれ方が違うっちゅーことに気付いてもうたんやけど、なんでなん？ 何か違いあるん？
回答：
他の役に立てるもんは"AWS"、単独で動けるもんは"Amazon"っちゅーことや。 ほんでも、"Amazon EBS"みたいに例外はあるでー
John Rotensteinさんは何者？
stackoverflowのプロフィールを拝見したところ・・・なんとAWSの中の人っぽい！！
AWSで「Senior Technical Trainer and Curriculum Developer」と書いてあるので、教える立場にいる方みたいです。
ということで、AWS公式ページでの発信ではないものの、信ぴょう性は高そうですね。
(※このプロフィール自体は一般公開されいているものなので、誰でもみれます。）
"Amazon"と"AWS"でそれぞれどのくらいの数があるの？
気になり始めたので集計してみました！
結果、だいたい4割は"Amazon"で、6割は"AWS"でした！[2021/03/29時点]
インプットは「AWS Documentation」です。
（"Amazon"も"AWS"も付いてないサービスがいくつかありましたが、除外してます。）
以上。
【AWS SAP認定試験】約1ヶ月で一発合格！合格のコツとは！？ ～後編～
前回までの記事ではAWS SAPに合格した際の勉強方法を紹介しました。
今回の記事で受験までの大まかな流れや試験当日のお話を書いて完結編とします。
- 前回までの記事
目次
受験までの流れ
ざっくりとは2021年2月初旬に勉強を開始して、2021年3月13日に受験するという流れでした。 以降、その中身をご紹介します。
(1) 試験内容を知る
AWS認定資格の公式ページで、試験のイメージを膨らませました。
あとAWS公式のサンプル問題集を景気づけにやりました。（結果はボロボロでしたが・・）
(2) 勉強戦略を練る
ググって先人たちの合格体験記をもとに勉強方法を考えました。 内容は前編の記事でも書いた通りです。
実際に参考にさせてもらった記事はこちらです。 (他にもいくつかあったのですが、忘れちゃいました・・)
- 未経験からのAWS SAP合格記 - Qiita
- AWSソリューションアーキテクトプロフェッショナル合格までの全記録（後編）｜いただきなべべ｜note
- 【AWS認定試験】アソシエイト3冠 + SAP を取ったので振り返ってみる | DevelopersIO
- AWS 認定試験のプロフェッショナルレベルに合格したので何やったかをまとめる
(3) 教材を準備する
こちらも前編の記事に書きましたが、私の場合はWeb問題集とBlackBeltの2本でいきました。
| # | 教材名 | 金額(税込) |
|---|---|---|
| ① | aws WEB問題集で学習しよう(プロフェッショナルプラン) | 6,028円 / 90日 |
| ② | AWS Black Belt Online Seminar | 無料 |
①について
②について
良いところ
- 信頼できる公式ソースで、無料で利用可能
- オンラインでスライド形式、PDF形式、動画形式の3種類が選べて使い勝手がいい
- 試験でも問われるベストプラクティスや設定ポイント等がまとめられているので効率的に勉強できる
悪いところ
- 1テーマのボリュームがそこそこ多い (動画だと約50分もある)
- サービスカットで公開されているので、ピンポイントで自分が知りたい知識に辿り着けないことがある
あと今回は使いませんでしたが、先人たちの記事をみていると、以下の教材は評判が良さそうでした。
| # | 教材名 | 金額(税込) |
|---|---|---|
| ③ | Udemy - AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集（全5回分375問） | 3,600円 |
| ④ | AWS認定ソリューションアーキテクト -プロフェッショナル 試験特性導き出した演習問題と詳細解説 | 2,970円 |
(4) 早めに受験日を決めて予約する
これ割りと重要です！
私の場合はキャリア上、どうしても3月いっぱいには資格を取りたいという目標があったので、勉強を始めてすぐに受験日を決めてテストセンターを予約しました。 受験日を決めずにダラダラやっているとどうしても間延びしちゃうのが人の常。 この日に受けなければいけないという既成事実をつくることで、モチベーションを維持していきましょう。
受験日から逆算してどこまでに何の勉強をするか計画を練りやすいという利点もあります。 また、いざ直前でテストセンターを予約しようとしても良い時間帯が空いてないという可能性もあります。 なので、早め早めに動けるように準備しましょう。
もちろん人によっては勉強を積み上げて自信をつけてから予約をしたいという人もいると思うので、最後はあくまで自分に合うスタイルで組み立てていけばよいと思います。
(5) あとはひたすら学習サイクルを回すのみ！
こちらも前編の記事で書いた通りですが、問題を解く⇒弱点を把握する⇒弱点を克服するのサイクルを回していきました。
最終的に584問を解き、23本のBlackBeltを参照しました。
- 参照したBlackBelt
試験当日
当日の実績
私の場合は115分で一通り解き終わり、残りの65分で見直しを行いました。 自信がなかった問題は27/75問で、見直しで2、3問は解答を変更し、14問くらいは答えの確度を高めることができました。
確度高が当たっていれば63/75問で80%は超えているであろうという見立てで、最後に「見直しの終了」ボタンを押したら、無事に合格していました！
（実際はその前にアンケートを挟むので、ドキドキしながらアンケートに答えるわけですが・・）
見直しフラグを活用しよう！
試験では問題に見直しフラグを立てることができます。自信のない問題等に付けておいて後で必ず見直しましょう。
長文との連戦になりますから、ピンとこない問題や時間をかけ過ぎてしまった問題は見直しフラグを立てておき、ひとまず割り切って選択肢を選んで先に進みましょう。最初はとにかく時間内に一通り解答し切ることに注力するのが精神衛生上よいかと思います。 そして、見直しタイムに入ったら、残り時間を見直しフラグを付けた問題数で割って、1問あたり何分くらいかけられそうか計算してから見直しを進めていきましょう。
後から冷静になって問題文を読んでみたら見落としていた要件などが案外見つかったりして、選択肢を絞り込めるようになったりします。
体調は万全に！
180分というタフな試験なので、体調は万全で臨みたいところです。 あと普段あまり活発に活動してない時間帯に試験を受けるという方はその時間帯で模擬試験をこなして、慣らしておくというのも手かもしれません。
トラブルはつきもの
私の場合は試験中に30問解いたあたりで、画面の「次へ」を押してもローディング画面で進まなくなってしまいました。 結局、2分くらい待ってから試験スタッフを呼んだのですが、スタッフが駆け付けたところで、ちょうど画面が進んだので無事に試験を続行できました。
このようなトラブルはわりとあるので、焦らずにスタッフの人を呼ぶようにしましょう。
会場選びも大切
他の試験で良く行っていて、やり慣れている会場があれば、そこをおさえましょう。 やはり初めての場所だと人間少なからずそわそわしてしまうので、少しでも心理的な安定は得たいものです。
私の場合はたまたま行った会場でスタッフの方の走る音がドタバタとうるさく、試験中に何回も聞こえてくるということがありました。 多少なりとも集中力をそがれてしまった感はあるので、次の試験からはその会場は選ばないようにしてます。
画面の解像度が合ってないようにみえる
これは個人差があるかもしれませんが、私の場合は問題文や選択肢が横に伸びているような感じがして少し気持ち悪かったです。
おそらく当日すぐに慣れますが、心の準備はしておいた方がよいかもしれません。
日本語が変
問題文、選択肢ともに直訳したような表現にけっこー惑わされます。 「English」ボタンを押すと英語モードに切り替えられるので、変な表現に出くわしたら落ち着いて英語の方も参照してみましょう。
問題文が頭に入ってこないとき
そんな問題が何問かは出てくると思います。 そんな時は無理して問題文を何回も読み返すより先に選択肢の方に目をやるというのも一つの手です。
そうすると結局どの範囲で何を問いたいのか認識できるので、その上で問題文に戻ることで、読むべき観点や集中力が養えます。
似たような選択肢は並行して読もう
以下のような手順で選択肢を選ぶと効率的なケースがあります。
- 似ている選択肢をグルーピングする
- そのグループを同時並行的に少しずつ読み進める
- そのうち差分が出てくるので、差分にフォーカスして問題文の要件やベストプラクティスと照らし合わせて、よりマッチするものを選ぶ
以上。
AKIBA.AWS ONLINE #01に参加した件
クラスメソッドさんの勉強会に参加させていただきました。 日頃、AWSで困ったときはクラスメソッドさんの記事に良くお世話になってます。
実は日曜に1本、月曜に1本のAWS認定試験の受験を控えており、とても良い刺激をもらえたので、参加レポートを書こうと思います。
- 開催概要
- 感想
- ハイライト
- パネルディスカッションの内容
- (Q1) どの認定資格が1番難しかった？
- (Q2) 資格1つあたりの勉強時間は？
- (Q3) 社内では勉強会してる？
- (Q4) 12種類とる中で確立した勉強方法は？
- (Q5) オススメの教材は？
- (Q6) 資格は業務上、役に立っている？
- (Q7) 12種類、全制覇するモチベーションは？
- (Q8) 最も業務にいきているなーと感じる資格は？
- (Q9) 社内に12冠はどのくらいいる？
- (Q10) 短期間でとると更新が大変なのでは？
- (Q11) 12冠とるまでにAWS以外の資格取得を挟んだ？
- (Q12) クラスメソッドで日々AWSの仕事をこなしていたら12冠取れるもの？
- (Q13) どうやって受かる確信が持てるところまでもっていってるか？
- (Q14) 12冠とって良かったこと、意外だったこと、ぶっちゃけ話を教えて！
- (Q15) 2ヶ月で6個とったコツは？
- (Q16) みなさんにとってAWSの魅力とは？
- 次回
開催概要
今回のテーマは「AWS認定資格制覇への道」で、AWS認定資格の保有者がパネルディスカッション形式で、取得のコツや裏話を話してくれました。 まさにAWS認定資格を絶賛勉強中の私にとっては打って付けでした。
開催内容の詳細はこちらをご参照ください。 www.wantedly.com
感想
終始、和気あいあいとした雰囲気でとても楽しく聴かせてもらいました。
みなさん、認定資格をベースにそれぞれの想いや嗜好に沿って、日々AWSの業務に励まれているようで、同じ技術者として良い刺激を受けました。
また、社内に認定資格の取得を応援するムードがあるとのことで、技術を軸に高め合える社風が整っていることは素敵だなーと感じました。
ハイライト
「資格取得は興奮する」
登壇者の中の1人の方の言葉です。
試験でパソコンの画面に「合格」という文字が映し出される瞬間が興奮するそうで、それが超ハイペース取得を支えたとのことです。笑
でも私も3月で3つ、あわよくば4つのAWS認定を目指しているので、何となくランナーズハイみたいな気持ちは分かります。
(ちなみにAzureも取ったので、上手くいくと1月で合計5つ認定達成できるかもしれません。頑張らねば・・）
パネルディスカッションの内容
登壇者の方々がそれぞれの立場や境遇をもとに色んな質問に答えてくれました。
質問内容は予め開催者側で用意した質問と、その場で視聴者から出た質問でした。
覚えている範囲で書いていきたいと思います。
(Q1) どの認定資格が1番難しかった？
(A1) SAPは1番苦戦した。
(A2) 1番はSAPだが、他の人も話すと思うので、別でいく。
(A3) SAPは業務に近いところがあるので、難しいがその延長ではあった。
- MLは一からだったので、学生時代の勉強を思い出すくらいでモチベーション維持が大変だった。
(A4) 同じくMLが難しかった。。
(Q2) 資格1つあたりの勉強時間は？
(A1) SAPは9月に開始して12月に受けたので、3ヶ月くらい
- 2回落ちた。。
- AWSの試験は一度落ちたら、2週間は受けられない。
- SAP受かってからは、仕事終わりと土日で2週間、短期決戦で全部一発合格！
(A2) 1問でも2時間かけるくらいじっくりと理解して進める
(A3) 2週間後に申し込んで業務後に勉強して受けてる
(Q3) 社内では勉強会してる？
(A1) 会社としてやっているものはないが、有志が集まってやっている。
(A2) 営業、バックオフィスの人、色んな部署の人が共通言語的に取っている。
- 資格取得の合否を報告するslackチャンネルがあって、合格するとみんなが褒めてくれる
- 非エンジニアの方が合格しているのをみると、励みになる。
(Q4) 12種類とる中で確立した勉強方法は？
(A1) 最初に模擬試験を受ける。だいたい最初はボロボロ。
(A2) 最初に試験ガイドをみて、何が問われるかを把握する。
- どのサービスが範囲なのかのあたりをつけてからスタート。
- 触ったことがないサービスはBlackBeltをみる。
- その次にAWSコンソールで設定項目を一通り眺める。
(A3) 12冠になるための勉強方法を主眼においた。
- 9月から受かり始めて、試験を受けるのが快感になってきた。
- 全集中で試験を受けて、パソコンの画面に「合格」の画面が出る興奮が気持ちよくてしょうがない。
- その気持ちにのせてガッと勢いでいく！
(A4) 社内にとりあえず申し込もうぜ！みたいな風潮がある。
(Q5) オススメの教材は？
-
- MLの時は大活躍した。あとはBlackBelt
- ネットにたくさん転がっているので、それらをフル活用するのがオススメ
(A2) サービスのよくある質問ページがオススメ
- BlackBeltにはない細かい仕様が載っている。
- 業務でもめっちゃみる。
(Q6) 資格は業務上、役に立っている？
(A1) コンサルティング部としてはまさにお客様の困りごとや解決方法をソリューションアーキテクトとして対応する場面がある。
(A2) テクニカルサポートTmとしてはAWSの試験問題のような要望がお客さまから毎日あがってくるので、ソリューションアーキテクトが役に立っている
- 要件のヒアリング能力が鍛えられている気がする。
(A3) SOAやSAAを取っていて、すごく良かった。
- 全体的なベースメント知識があるとないとで、業務の取り組みレベルが違ったと思う。
- データアナリティクスを取ってよかった。
- 例えば、ETLというキーワードで、何のサービスを使えばよいのかがパっと浮かぶので早い。
(Q7) 12種類、全制覇するモチベーションは？
- (A1) 取ったことを自慢したい！
- 社内の他の人の自己紹介スライドにバッチが12個並んでて憧れていた。
(Q8) 最も業務にいきているなーと感じる資格は？
(A1) ソリューションアーキテクト x 2人
(A2) データベーススペシャリティ x 1人
(A3) どうしても絞れない！全部！ x 1人
- 自分に足りてない知識拡充と普段みれていない業務への幅出しができる
(Q9) 社内に12冠はどのくらいいる？
- (A1) 31、32くらいのはず (レア感はなくなってきた？笑）
(Q10) 短期間でとると更新が大変なのでは？
(A1) 更新時期がきたら、その時に考える。
- 更新ラッシュの人は大変そう。
(A2) 特に考えてないけど、その時がくるのが怖い。。
(Q11) 12冠とるまでにAWS以外の資格取得を挟んだ？
(A1) 12冠とるまでは一途にやった。
- 12冠とった後は他の資格をとった。
(A2) AzureとIPAをちょこちょこ勉強している。
(A3) 12冠とるまでは浮気してない！
(Q12) クラスメソッドで日々AWSの仕事をこなしていたら12冠取れるもの？
- (A)1 答えはNO。業務に偏って取れるものではない。
(Q13) どうやって受かる確信が持てるところまでもっていってるか？
(A1) おそらくみんな確信は持てずに行ってる人ばかり。
- 自分の場合は目次をつくって全部こなして自分で納得できてから受験するようにする
(A2) 自信をもって、パソコンの終了ボタンを押しても落ちているときもある。
- こんなけやったら受かるだろうと思ってから受験予約してない。
- 試験に落ちても受けたこと自体を褒めてくれる社風があるので、次また頑張ろうと思える！
(Q14) 12冠とって良かったこと、意外だったこと、ぶっちゃけ話を教えて！
(A1) Alexaで変なゲームつくって子どもに遊んでもらえたので、良かった
(A2) 資格試験で興奮できることを発見した(爆)
- 社長にマウントとれる！(爆)
(A3) 12冠とることで部下に背中をみせることができる
- マネージャが率先してとっている、そしてそれを押し付ける感じではなく寄り添う感じで接してくれることは部下としては励みになる！
(Q15) 2ヶ月で6個とったコツは？
- (A1) 受け続けること。ずっと勉強してても受けないと何も始まらない。（あと興奮すること）
(Q16) みなさんにとってAWSの魅力とは？
(A1) 掘っても掘りきれない宝の山
(A2) 追いかけても追いかけても振り向いてくれない片思いの相手
- (日々アップデートあるので、いつまでも分かったとは言えない)
(A3) アジリティをもって一人で何でもできる、お客さんに価値を提供できる
(A4) 何よりも触るのが楽しい。とにかく触ってみよう！
次回
「4/21(水) 19:00～21:00」とのことです。
AWSでこの手の勉強会は始めてでしたが、楽しかったので、次回も参加したいと思います。
その前に、3月もうひと頑張りで、合格に向けて頑張るぞー！！
【AWS SAP認定試験】約1ヶ月で一発合格！合格のコツとは！？ ～中編～
前回の記事では、AWS SAPの受験にあたり実践した学習サイクルの3ステップをご紹介しました。 今回はその3ステップの中身をもう少しお伝えしていきたいと思います。
※釈迦に説法ですが、これをやったら絶対に受かるというわけではありません。悪しからず。
目次
前回のおさらい
以下のような3ステップで学習サイクルをまわして試験に挑みました。
問題を解き、解けなかった問題に対してはなぜその答えなのか、なぜ他の答えではダメなのかを理解し、その問題を解けるようになるまで頭に叩き込みます。
以降では各ステップでどんなことを実践したのか、もう少し具体的にお話しします。
①問題を解く
Web問題集の有料オプションを申し込んで、ひたすら問題を解きました。
まーまーいいお値段します。 が、背に腹は代えられないということで、お支払いしました。
とにかく問題に慣れる
本番ではビジネス的なユースケースを題材にした長文の問題がたくさん出てきます。そのため、問題文そのものに慣れておくことは必須です。
また、多くの方が日本語で受験するかと思いますが、英語を直訳したような不自然な表現が多く、頭に入ってこないため、事前に慣れておくことが大切です。
Web問題集では本番と類似の形式で問題が解けるので、ひたすら練習しましょう。
模擬試験モードで時間配分をつかむ
Web問題集には模擬試験モードがあります。 ある程度、学習サイクルがまわって自信がついてきたら、まとまった時間をとって本番形式で問題を解きましょう。
試験では1問あたりにかけられる時間は平均で2分半くらいです。 見直しの時間を確保しようと思うともう少し早いペースで解く必要があります。 自分がどの程度の時間を残して見直しに当てられそうかなど、あらかじめ把握しておきましょう。 時間を余らせて解くことができるようになっておくことで、当日、心理的に優位に立てると思います。
※この模擬試験モードですが、間違えた問題が何かまでは教えてくれません。そのため、後でその問題を見直せるようにスクショしておくことをお勧めします。
解説は最高の先生
Web問題集の解説はAWS公式ドキュメントから説明を持ってきてくれていますので、信頼できる内容をもとに理解を深めることができます。（サイト自体はなんだか胡散臭いのですが・・・笑）
私の場合は以下のような自己ルールを設定して、解説を頭に入れることで応用力がつきました。
- とにかく正解してもしなくても解説は必須で読む
- 答えそのものを覚えるのではなく、なぜその選択肢が間違いなのか、どうやったらその選択肢に辿り着けるのか、考え方を理解する
- その考え方が合っている＆正解した場合のみ次から解説は見なくてOK
ただ、日本語がたまに何の事を言ってるのか理解に苦しむことがあるので、どうしてもピンとこないときはググってある程度信頼のおける企業等の記事を参考にしましょう。
解説を読むタイミングですが、7問1セットとして1セットを解き終わってから、解説読み込みタイムを設けるようにしていました。 その際、間違えた問題は必ずメモに残し、再チャレンジしやすいように準備しておきましょう。 （どんな風にメモしていたかは後述します。）
ちなみに私の場合は間違えた問題にすぐに再チャレンジするのではなく、ある程度時間をおいてから実施してました。 弱点を克服してから再チャレンジする方が効率的ですし、自信に繋がるように思います。
試験当日までの問題数と正答率
あくまで私のケースですが、試験当日までに434問を解きました。
実は最終的にはWeb問題集の全ての問題を解き切るまでには至りませんでしたが、それまでに解いた問題の中では2週しました。 2週目のトータル正解率は86%でした。
また、通常の問題とは別に模擬試験モードを2回実施しました。 1回目が78%、2回目が77%だったため、2回目で正解率が上がりませんでした。 ですが、最低ラインの75%は超えていたため、そこまで不安になることはありませんでした。（あくまで楽観的な観測ですが、スピード優先なので） あとは通常問題の2週目が十分に走りにきってなかった、2回目の問題をきちんと復習して理解しきれた、という点もありました。
時間配分に関しては、2回目の模擬試験で60分ほど時間が余るようになっていたので、この時点でプレッシャーはそんなに感じなくなりました。 とはいえ、本番は初見の問題ばかりのはずですから、そこは確実にスピードが落ちるだろうなーという心の準備はしておくようにしました。
②弱点を認識する
「①問題を解く」で問題をこなす際は、間違えた問題や知らなかったサービスを必ずメモするようにしていました。
Windowsのメモ帳でもLINE KeepでもGoogleドライブのメモでも何でもいいのですが、自分が一番アクセスしやすいツールですぐに思い出せるようにしておきましょう。
弱点メモをつくる
試験ではソリューションアーキテクトとして幅広い知識が求められます。 今や150以上あるAWSサービスの全てを満遍なくおさえておくことは時間的も体力的にも中々難しいものがあると思います。
そのため、間違えた問題はもちろんのこと、知らなかったサービスやピンときていない構成や設定などを中心にピックアップしておきましょう。
とはいえ、その数自体が積み重なると勉強コストが膨れ上がりますから、メモを取るタイミングで自分にとっての優先度（＝弱点度合い）を付けておきましょう。 弱点度合いはあまり厳密に考えず感覚的なものでいいと思います。 問題で遭遇した時点での何となく認識している自身の理解度でもいいですし、いくつか問題を解いてみてからの正答率ベースでもいいです。
また、このメモを取ること自体に時間がかかっていては本末転倒なので、あくまでキーワードレベルで自分がどんな弱点を克服したかったか思い出せるレベルのものにしておくのがオススメです。 例えば、私の場合はこんな感じのメモをGoogleスプレッドシートで作っていました。 (後でトータルの正解率も出したかったため。）
| 問題番号 | 正解数 | 弱点(★は弱点度合い） |
|---|---|---|
| SAP#21 | 3 | OpsWorks★★★ |
| SAP#22 | 5 | Organizations★★, ECS ★ |
| SAP#23 | 6 | |
| SAP#24 | 6 | S3のストレージクラス★ |
時間に余裕がある方は間違えた問題をAWS公式の試験ガイドの分野別に分析して、分野カットで足りていないところを一通り勉強するという方法もありかなと思います。
現状の習熟度を把握する
正解率を算出しておくことで結局いまの自分がどの程度問題が解けるようになっているのか認識しながら勉強を進めるようにしましょう。 学習サイクルをあとどのくらい回せばよいか、そもそも受験に踏み切るかどうか、他の問題や参考書に手を広げるかなど、一つの判断基準になると思います。
私の場合は先に受験予約をして排水の陣としていたのですが、模擬試験の正解率が振るわなければ(75%超えていなければ)、スケジュール変更も視野に入れて動こうと考えていました。（だって3万円が・・）
また、Web問題集とBlackBeltの2本だけで！みたいな内容で書いておりますが、結果論的なニュアンスも多分に含んでいまして、あまりにも正解率が上がらなければ、良質な記事や参考書を探して座学から出直すようなことも頭の片隅にはおいていました。
ちなみに、解説を読んでもそもそも何を言ってるのかピンとこないことが大半で、一向に腹落ちしないという方は、ベースメント知識が不足して非効率になっている可能性があるので、基礎からの出直しも視野に入れて戦略を練り直してみた方がよいかもしれません。
③弱点を克服する
「②弱点を認識する」で作ったメモの弱点をAWS BlackBeltを使って補完していきます。 AWSのウェビナーの内容をSlideShare、PDF、Youtubeの3つの形式で、何度でもタダで参照できちゃいます。（サービスによっては用意がないものもあります。）
「あ、ここ練習問題で問われてたなー」という箇所がたくさん出てくるはずです。
Youtube 1.5倍速がオススメ
恥ずかしながら私の場合はスライドベースで視覚Onlyだとすぐ眠くなってしまうため、YoutubeがあるものはYoutubeを使って聴覚も刺激しながら勉強に励みました。。
とはいえ、1本50分以上ありますから、スピード重視の今回の戦略上、まったりと垂れ流しているわけにもいきません。
そこで1.5倍速で視聴する＆既に理解しているところはひたすらスキップして、1本だいたい20～40分で消化できるようにしました。
BlackBeltを1回見るだけで安心してはダメ
見終わるとそれなりに分かった気になるし、達成感もあるのですが、そこがゴールではありません。
「①問題に解く」に戻って、解けるようになっているか再チャレンジしましょう。 スムーズに再チャレンジできるように前述したメモを使って該当する問題は控えておきましょう。
また、せっかく学んでも時間経過とともに忘れていくことがあるため、特に不安要素があったり、間があいてしまったものは、もう一度BlackBeltに戻るようにしましょう。 もちろんこれは残された勉強時間と、優先度が高い他の弱点への対応との天秤です。
次回
学習の3ステップの中身をお話してきましたが、いかがだったでしょうか。 人によってハマるハマらないはあると思いますが、合格の一例として参考にしていただければ幸甚でございます。
さて、実は今回を「後編」として記事はいったん切ろうと思っていたのですが、書いているうちに試験当日の注意点なども自分のための備忘録として残したくなってきてしまいました。。 なので、次回を「後編」として、また拙い記事の続編を書こうと思います。
以上。
