AWS Certified Solutions Architect (Assosiate) 合格記

AWSを仕事で使うようになって2年経ちました。腕試しとイベントで認定者専用ラウンジに入ってみたかったので認定試験を受けてみることにしました。

試験対策

公式の事前トレーニングや模擬試験、市販の問題集等は特に解かず、サンプル問題だけ解きました。今となっては模擬試験くらいは受けておいても良かったのではと思います。

確認した資料はこちらです。

ホワイトペーパーやFAQはテキストベースなので、初めはBlackbeltの図解を見ていくのがよいと感じました。

資料を見ていくときには、Trusted Advisorのチェックカテゴリ(コスト・パフォーマンス・セキュリティ・耐障害性)や運用工数の軽減を意識して、どんなアーキテクチャ、サービスを選べばよいかを意識するとよいと思います。実際のTrusted Advisorのチェック結果も、全項目をチェックするには上位のサポートプランに加入しているアカウントが必要ですが、見られるなら見ましょう。

公式FAQに新機能はGAから6ヶ月は出題されないとあるので、EKS(2018年6月GA)等は(試験対策としては)スキップしました。

会場について

都内には会場はいくつもありますが、銀座CBTS歌舞伎テストセンター | CBT-Solutionsにしました。

  • 会場の椅子やPC等は公式サイトに載っている写真の通りです
  • 隣は土産物売り場でしたが、特に客の声等は聞こえてきませんでした
  • トイレがきれいで良かったです
  • 使えるもの
    • イヤーマフや耳栓、毛布の貸し出しをしているそうです
    • 試験中に使用できる紙一枚とペンが渡されます
    • それ以外は持ち込み不可。試験前にスマートウォッチ以外の時計を探しましたが、時計も持ち込み不可でした
  • 地下にコンビニがあります
  • 他の会場での受験者がブログに書いているような「英語でのテキストチャットが必要」や「Webカメラでやたら監視される」、「PCの調子が悪い」というような不都合、不具合は何もありませんでした
  • 本人確認書類はパスポートと運転免許証にしました
  • 注意点
    • 地下から来る場合、5階に止まるエレベータの台数が限られているので時間に余裕を持たせましょう
    • 地上の入口は歌舞伎座の劇場側とは別で、北西側(銀座駅側)のオフィスっぽい入口です

試験そのもの

PCを使ったCBTなので、他の人を待たずに開始でき、終了画面まで進めば退席することができます。

最初の注意事項(試験でよくある不正行為の禁止等)を確認すると、「次から試験が始まります」のような確認は特に出ず、いきなり一問目が出ます。日本語で登録しても注意事項だけは英文で表示されます。 時計は持ち込みできませんが、右上に残り時間はカウントダウン形式で表示されます。 画面構成を知っておく意味でも模擬試験は受けておくべきだと感じました。

後で戻ってくることも出来るので、迷ったらとりあえずフラグを立てつつ適当な選択肢を選んで、次に進めてしまうのもありでしょう。 試験時間は130分と言うことになっていますが、1時間強で見直しも終わったので退室することにしました。 全部の問題を解き終わって解答を送信すると、続いてアンケートが数問あり、それを送信するとその場で結果が表示されます。 受験後に送られてくるメールは単に「AWS試験を完了しました」という件名で、合否については書かれておらず若干不安になりますが、数日後に詳細な結果が来るのを待ちましょう。

結果

月曜受験で、メールはまだ届いていないものの火曜の夜に認定サイトを見てみると「これまでの受験履歴」ページに結果が反映されていて、デジタルバッジも見られるようになっていました。 100 - 1000点のレンジで906点でした(合格ラインは720点)。 その後、水曜の4時頃にメールも来ていました。

おまけ

認定試験の案内サイト AWS 認定ソリューションアーキテクト – アソシエイト | AWS にあるサンプル問題の考え方をメモしておきます。 サンプル問題自体は公式サイトのPDFを参照してください。

Q1. DynamoDBの認証情報について

正解のDとA, B, Cの大きな違いは固定のシークレットを使用するか、IAMロールとSTSを使って一時的な認証情報を自動的に取得するか。

  • 選択肢A, B, C共通: シークレットが固定なので、一度漏洩するとキーを無効にするまで不正に利用される、人為的な不正により公開される可能性がある(GitHubに誤って公開する事故も起こりうる)
  • A, C: S3やキーサーバの認証情報を別途保存する必要が発生する
  • B: ユーザーデータは暗号化されず、メタデータサーバ 169.254.169.254 から取得できるので機密情報を保管するには適していない

Q2. Webアプリのセッション保存に使うストレージ

A: CloudWatchはメトリクスの取得やロギング (Logs) には使用できるが、セッション情報を読み書きすることはできない。 C: ELBにはセッション情報等、アプリから任意の情報は書き込めない E: オンプレからファイルまたはテープデバイスとしてAWSのストレージサービスを使用するGWなので適さない。

Q3. ストレージの誤削除対策

  • A: スナップショットの取得時点以降のデータは復元できないから。
  • C: S3のリージョンを増やしても、データを誤って消してしまう可能性はなくせない(リージョンレベルの災害対策にはなっている)
  • D: インスタンスストレージは一時領域として使うことを意図しており、EC2の障害、停止等で消えるので不適当

Q4. 大規模なRDB

正解以外はRDBのサービスではないので外せる。なお、サンプルにはRDBをサポートするサービスとしてAuroraのみが載っているが、RDSのリードレプリカをサポートするDBエンジン(MySQL等)ではレプリカ数の上限は5つなので、やはりAuroraが必須である。

Q5. EBSの種類

gp2は一般用途のSSDで、大容量にしたりバースト機能を使ったとしても設問のような高いIOPSは出ない。 SSDはIOPS重視、HDDはスループット重視でさらに各2種類あるので、その使い分けを確認する。magneticは旧世代扱いされているのでスルーしてもよいのでは。

Q6. トラフィック増のボトルネックの特定

いくつかのサービスを組み合わせた問題。EC2以外は自動的、または設定によりスケールアウトできるのに対し、EC2で動くアプリはスケールアウトできるように作られている必要があり最も見直す必要があると推定できる。

Q7. S3の保存期間の設定

セキュリティ関連のキーワードが並んでいるが、正解以外は下記のように要件とは関係ない。Webセキュリティの知識としてCORSを知っていればDは即外せる。 * A, C: アクセス制限は掛かるが自動では消去されない * D: クライアントからのクロスオリジンのAPIアクセスを許可するための設定なので異なる

Q8. インターネットを介さないS3アクセス

  • A, C: インターネットを通したくないという要件を満たさない
  • B: EC2やVPCとマネージドサービスとの間にVPNを張ることはできないし、やはりVPNはインターネットを経由するので不適当

Q9. Redshiftのネットワーク制限

  • A: VPCピアリングでVPC間を接続することはできるが、他のネットワークからの制限をそれで禁止できるわけではない
  • Bはユーザの認証であり、ネットワーク単位のアクセス制御になっていない。

Q10. インターネットからのアクセスを防ぎつつ、パッチの取得は可能にするVPC設計 * A: インターネットからDBにアクセスできないようにする要件を満たさない * B: DBサーバがパッチを取れない * D: NATGWはパブリックサブネットに置くものなので、プライベートサブネットには置けない。プライベートサブネットからのデフォルトルートはパブリックサブネットのNATGWに向かうように設定する。