AWS認定 SysOpsアドミニストレーター アソシエイトに合格してアソシエイト3冠になったので勉強方法や振り返りについてまとめる

AWS認定 SysOpsアドミニストレーター アソシエイト に先日合格しました。
合格時のスコアは 794/1000 で、合格者の中では高くないほうだと思います。


分野的には「モニタリング」と「ネットワーク」が特に点数が低かったみたいで、その領域については別途改めてまとまった量の勉強を行っていった方がよさそうです。

学習内容について

学習方針は基本的にソリューションアーキテクトの時やデベロッパーの時と同じです。

学習方針

  1. AWSが公式に提供している模擬試験を受ける
  2. 模擬試験の問題をすべてスクリーンショットを撮る
  3. スクリーンショットを見返して特にわかってなさそうなサービスや技術領域（監視系、サーバレス系、DB系　など）を特定する
  4. その分かっていないサービスや技術領域に関するドキュメントを読みまくる
  5. サードパーティーの有料教材は買わない

これまでとSysOpsでの勉強方法や内容の違い

Developer アソシエイトの場合は海外ブログ等を発掘してどのサービスを重点的に勉強すればよいかを洗い出していったのですが（これ勉強しとけよ！って書いてくれてる英語ブログとかあった）、SysOps アドミニストレーター アソシエイトの場合はとにかく先人のブログが少ないです。
それで今回は基本に忠実？に、スクリーンショットを見返してそこから自分が勉強すべき内容についてリストアップしました。

その結果以下のようになりました。
上から勉強した方がいい順です。
  • System Manager
  • AWS Service Catalog
  • Snowball
  • Storage Gateway
  • AutoScaling Group
  • Egress-Only Internet Gateway
  • SAMLフェデレーション
  • VPN(Direct Connect?)
  • NAT Gateway
  • VPC
  • Route53
  • CloudFormation
  • S3 低頻度アクセス

受けたあとについでに学習したほうがいいと思ったのは、以下のようなサービスです。

  • AWS Config
  • IAM
  • Route53(優先度上げたほうが良かったかも）


ちなみに今回は時間がなかった（取り掛かり始めるのが遅すぎた）ので、あんまりたくさん勉強することができませんでした…。

当日までの学習結果


試験内容について

そのように準備不足が否めない状況でしたが、これまでの業務利用の経験やほかのアソシエイト試験での勉強が効いていたおかげで、なんとか合格することができました。
試験内容としてはトラブルシューティングが多かったイメージです。
ソリューションアーキテクトが上司に「ねぇ～こんどこういうシステム作ってほしいんやけど、AWSの何を使えばいいのん？」と言われるような出題内容が多いのに対して、SysOpsアドミニストレーターは「ねぇ～なんかこういうシステムが今動いてないんやけど、どこが悪いんやろ？」みたいに問われるような問題が多かったです。
問題の難易度（トラブルの複雑度）は実際の業務の現場だとわりと「あるある」レベルであり、「うーんこのトラブルはAWS知ってる人からすると初歩的だな…」みたいな問題も少なくありませんでした。
ただし、まったく知識がない人には解けないと思いますので、やはりアソシエイトレベルの試験という意味では有効なのだなと思いました。

アソシエイト3冠になってみて

自分の資格のページは一般公開されている（非公開にもできた気がする）のですが、それを見るとなんだか頑張ったなぁという気持ちになります。
巷では未経験でも〇〇時間で合格！みたいな記事が流行っている中で、私はマイペースに勉強しつつあとはいままでの業務で得た知識と、業務のためにオフタイムに学習した知識の下積みがあったことで、無事合格できたかな…という感じです。
なんというか嬉しいという気持ちもありますが、ホッと胸をなでおろしています。
いままでの自主学習や仕事のための知識のインプットは間違ってなかったんだなって証明されたということなので…。
そういう意味で、AWS経験4年程度のいまのこの時期に、AWS経験1年程度の実力を証明すると書かれているアソシエイトを半年で3個無事取得できたのはほんとに良かったです。

次は

もちろんプロフェッショナルレベルの2個の認定をゲットして5冠になりたいです。
また、スペシャリティレベルの資格にも挑戦してみたいです。
ただ、それは今すぐではないかなと考えています。
たとえば私はスペシャリティの領域だとBigDataやAlexaに興味がありますが、直近ではたとえば実際にAlexaアプリを作ってみるとか、そういうアウトプット活動の時間を確保できるといいなぁと考えています。
アソシエイトの有効期限は取得日から3年なので、少しゆったりめに、来年の今頃とかから半年かけてプロフェッショナルの2個に挑戦して5冠を目指すとかでもいいかもしれないです。
もちろん、先に資格をババーっと取ってしまうほうが都合がいい方もいると思いますので、参考にはしないでください。
ご自身の能力開発プランの青写真を描いて、それと実情とを照らし合わせながら相談して決めるのがよいと思います。

コメント

コメントを投稿

このブログの人気の投稿

一部のユーザだけ NET::ERR_CERT_REVOKED でサイトにアクセスできない

イメージ
一部のユーザから、HTTPSのURLにアクセスできなくなったという連絡を受けました。 なんでも攻撃される恐れのあるサイトですとかなんとか…。 ブラウザのスクリーンショットをもらってみたら、こんな表示が。 Google Chromeでも同じ感じのエラーメッセージが表示されていました。（サイト名が出るので省略…） Chromeの方のエラーメッセージをよく見ると、 NET::ERR_CERT_REVOKED と書かれています。ファッ！？証明書が失効している…！？ そんな馬鹿なと思い手元でアクセスしてみたら普通に繋がる…HTTPSできてるよ？なんで？何が起こってるんだろう…。 結論を言うと、 SSL証明書業者が手違いで中間CA証明書を失効させてしまった ことにより、私たちが購入して使っている証明書が一時的に利用不可能になり、そのネガティブキャッシュをユーザが参照している 、というお話でした。 解消のための新しい中間CA証明書が公開されていたので、そちらを使って更新してみると、問題は解消されました。 ただ、自社が買っていたのはクイックSSL証明書だとばかり思っていたので、更新に失敗しまくって時間がかかりました。違うやつだった…。 SSL証明書とかドメインの周りのメンテナンスは多くても年に数回とかっていう頻度なので、いろいろ思い出すのに苦労しますね。 ていうか、そういうことあるんですね、中間証明書間違って消しちゃった！とか。 レジストラのDNSサーバダウンと合わせて、「 うちのせいじゃないんだけどご迷惑をおかけしてごめんなさい案件 」って感じで覚えておきたい…。
続きを読む

[AWS] WAF を自分で組み立てるなら SAM でテンプレート書いた方が楽だよ

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に
続きを読む

[#CentOS][#Apache] CentOS6 でApacheが起動できない

CentOS 6 で httpd を起動させようとした時のこと $ sudo /etc/init.d/httpd start httpd を起動中: httpd: bad user name apache    [ 失敗 ] なんじゃこりゃ。 ■問題 Apacheが起動できない。問題はapacheユーザ ■原因 httpd.confには ユーザ：apache グループ：apache　でhttpdを起動するようになっている。 ユーザとグループを確認してみよう… $ cat /etc/passwd | grep apache $ ユーザが居ない… $ cat /etc/group | grep apache apache:x:48: グループはある。なんでこうなってんだ？ ■対処 ユーザ「apache」を作ってグループ「apache」に入れてあげよう。 # useradd -g apache apache useradd: /etc/passwd をロックできません。後でもう一度試してください。 は？(#ﾟДﾟ) # ll /etc/*.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/passwd.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/shadow.lock これを消すか # rm /etc/passwd.lock rm: remove 通常ファイル `/etc/passwd.lock'? y # rm /etc/shadow.lock rm: remove 通常ファイル `/etc/shadow.lock'? y これでもう一度apacheをuseraddして…あれ、もしかしてロックファイルがApahceをインストール剃る前からあって、もしかしてyumのインストールシーケンスの中でユーザ作成だけ失敗してたりしてるのかな？ ということでApacheをインストールし直す方向で。 # yum remove httpd $ sudo yum install httpd httpd-devel mod_wsgi Pythonの勉強したいからmod_wsgiも入れてます。 で、yum入りました。 Transaction Summary
続きを読む