まえがき
さっきAWS 認定ソリューションアーキテクト – アソシエイト(以下AWS SAA)に合格しました。
https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/
まだメールが届いていないので正式ではないかもしれませんが
試験終了時の合否判定に「合格」って書いてあったので見間違いでない限りは合格です。
試験を受けながら思ったことや、合格した喜びが冷めないうちに
文章を書いた方がいいな、と思ってこうして当日中にQiita初投稿をしようとしています。
「Rust楽しい」っていう下書きをしてましたが、そんなもんそっちのけです。
あとがき
思うがまま、合格した喜びに任せて文章を書いたら全くまとまらなくなってしまいました。
ただ、他のAWS SAAに合格した人の記事で散々語り尽くされている内容はあまり書かないようにしてます。
(もちろん被ってる内容もあると思いますが、それは被らせるくらい本当に重要だと思った内容のはずです)
なのでAWS SAAに合格した人の記事を漁っていて既に他の人の記事を読み尽くしているときに初めて読んで意味がある記事かもしれません。
本当に「その温度感であれば読んでください」ぐらいの駄文長文なので興味がない人は読まなくていいです、時間の無駄になると思います。
...とはいえこんな駄文長文を本当に投稿していいのか、と悩んでいたところ日付が変わってしまいました。
メールはまだ届いていません。ﾎﾝﾄｳﾆｺﾞｳｶｸｼﾀﾝﾀﾞﾛｳｶ
せっかく3500文字近く書いたのに投稿しないのも勿体ない気がしてきたので投稿しちゃいます、えい！
何をこの記事に書くか
- 試験を実際に受けて感じた「これから受ける人に伝えたいこと」
- どんな人が受かったかの参考になるか分からないけれど「自己紹介」
これから受ける人に伝えたいこと
AWSコンソールをたくさん触ろう
まず前提としてAWS SAAは問題文があって、それに対して選択肢から回答を選びます。
そしてこの回答、比率としては少ないのですが「AWSにはできないこと」が書かれていることがあります。
中途半端な知識でこの選択肢を読んでしまうと「え、そんなことできるの？ それが一番ベストだよね？」みたいになるのですが
実は「AWSにはできないこと」だからそれを選んではいけなかった、みたいなことがあります。
なので普段からAWSコンソールに触れて何ができるのか、何はできないのか実感として知っておいた方がかなり安心して回答を選べると思います。
僕はS3の暗号化をほとんどしたことがなかったので、「バケットに対してデフォルト暗号化という機能があるのか」「バケットポリシーに暗号化について記載するのか」分からず回答できませんでした。
一応、本番では多分前者だろうと思って選んだのですが合ってそうですね。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/bucket-policy-encryption-s3/
英語は読んだ方がいい
「自分は英語苦手だし・・・」とか思って読まないつもりでいたのですが
意外と日本語が読みにくいので "Englishボタン" を押す心算でいた方がいいです。
例えば「ネットワークファイルシステム」みたいなカタカナが大量に出てくるのですが
「Network File System」のことだと気付くのに時間がかかるんですよね、カタカナだと。ただの直訳なのに。
でも英語で読めば「あー、NFSか」ってなってすぐに回答の選択肢に入っているAWS EFSが答えだと分かったりするので
日本語の意味が捉えにくいな、と思ったらすぐに英語を一度読んでみることをオススメします。
フラグ大事
(僕が一番伝えたいことはこれなのですが、小手先のテクニックなので重要ではないです)
問題にフラグを付けることができるのですが、後から「フラグが付いている問題だけを読み直す機能」があります。
ここら辺は模試で一度使い方に慣れておいた方がいいと思います。
そしてフラグの何が一番大事かというと「どういう問題にフラグを立てるか」という作戦を用意しておいた方がいいです。
僕の場合、問題には三種類ありました。
- 即答できる問題(10%)
- 前提知識不足で全く分からない問題(10%)
- 考えれば分かるけど自信がない問題(80%)
「後から見直す問題にフラグを立てる」という方針でフラグを立てていった結果、90%の問題にフラグが立ってしまいました。
まぁその90%をもう一度見直して合格したので結果的には正解だったのかもしれませんが、
もう少し効率のいいやり方があったのかなぁ、とは思います。
なので「絶対に分からない問題にはフラグを立てない」とか「ある程度自信がある問題はフラグを立てない」とか
各々自分にあったフラグの立て方の作戦を用意した方がいいんじゃないかな、と思います。
自己紹介
AWS SAAに合格した自分のスペックについて書きます。
スペック
- 大学院卒
- 社会人経験5年目
- Atcoder青色(メイン言語はJava)
- 資格0(囲碁は初段、ピアノも資格あり、Web/情報系の資格はAWS SAAが初)
- 最近の業務はshell芸がメイン、残り90%はディレクションやクライアントとの折衝、社内基盤の整備
- 趣味で一時期Vueを触ってた(着せ替えゲームを作った)
ってところでしょうか。資格をとるお金や時間が勿体無い人間だったので説明できるスペックが全然ないです。
ちょっと長くなりますが、どれくらいの能力があるのかの指標としてスペックの代わりに経歴を書いてみます。
経歴
大学/大学院は情報科学系の学科に通学していました。
一応、授業で基礎的なところはさらえるはずなのですが
身についたのは数学的な知識とC言語少しと研究室でガリガリ書いたMatlabぐらいだと思います。
就職するまではWeb系はからっきしでしたしサーバすら立てれない、linuxコマンドもmvやcdなどのファイル操作しか分からない感じでした。
Javaも授業で軽く知っただけなのでほとんど入社してから覚えました。
入社1年目で先輩に教えてもらいながらEC2をAMIから立てたりELB作ったり、
あとは「Jmeterによる負荷試験の環境をCloud Formationから構築して別VPCの検証環境とVPCピアリングして〜」みたいなことを
インターン生がやっているところを横から見ていた りはしました。
入社2年目になると案件が変わってオンプレミスになったのでAWSに触るのは開発環境ぐらいでしたが
相変わらずEC2をAMIから立てたりセキュリティグループを変更したりはしていました(むしろ1年目より内容は減った)。
入社3年目になって案件をかけ持ちすることになってがっつりAWSで動いている案件に入って
CloudFront触ったりWAF触ったりS3触ったりとやることはだいぶ増えたのですが
この3年間に共通して言えるのが 既に誰かが構築した環境をいじるだけ で
なんだかAWSコンソールは触っているけれどAWSについてはあまり理解できてないなぁ・・・という感じでした。
4年目になって新しい要件にも触れるようになって
Athena 使ってみたりWAFのルールをAWS APIで動的に変更したりとちょっとトリッキーなことをやり始めたのですが
相変わらず「VPC？ サブネット？ ACL？ 可用性？」って感じで一番知っておくべきというか
基礎的で重要な部分についてはあまりちゃんと理解しないままでした。
ちなみに入社5年目になりましたが、いまだに自分で環境を1から構築したことはないです。
今ならやろうと思えばできる気がしますが耳年増(使い方が間違ってる？)になっている感じ。
つい先月か2ヶ月前に会社の方針でAWSの資格保有者を増やそう、という話になって
自分が立候補したので3日間で行われるAWS SAA試験対策講座を受けてきました。
今までなんとなく人から聞いていた話が体系立てられて話されるので「ほーんそういうことかー」みたいな感じでした。
新しく得られた知識はほとんどなかったのですが
「こういう観点でサービスを選択した方がいい」とか知識をどう扱うかの部分について学べたのがよかったです。
で、試験を無料で受けれるバウチャーをもらったので早速今日受けてみて合格した、というのがここまでの経歴です。
おわりに
とりあえず伝えたかったのは「こんな人でもトレーニングを受けたらあまり勉強せずに受かったよ」ということです。
「資格取るぞー！」って意気込んでるけどAWSほとんど触ったことない、って人にはあまり役に立たない記事かもしれませんが
「業務ではAWS使ったことあるけど、資格なんてまだ自分には早いかも・・・」と思ってる人にはそんなことないよ、って言いたいです。
特に弊社は資格に無頓着な人が多くてAWS SAAの資格を持ってるのは僕が二人目になると思うのですが
本当は10人20人くらいほとんど勉強しなくても取れる人がいるはず・・・！
いかがでしたでしょうか。何かお役に立てる情報はあったでしょうか。ではでは。