当ブログには広告が含まれています。

(AWS認定)SysOpsアドミニストレーターアソシエイト(SOA-C01)合格への対策3つ

aws

AWS認定の1つであるSysOpsアドミニストレーターアソシエイト(SOA-C01)に合格しましたのでその記録になります。
巷ではSAAを持っていればSOAは楽勝、などと言われていますが果たしてその真実は!?

受験時点の状態(スペック)

SAA-C02(ソリューションアーキテクトアソシエイト)に2020年9月合格。そのあと、SCS-C01(セキュリティ専門)に2021年3月合格していました。プラクティショナーも持っているので、今回の試験が4つ目の認定試験でした。
実際にAWSを使って業務をすることはなく、趣味程度にEC2などを触ってみたりしていた程度です。

試験対策

①模擬試験

SOAを受けようと決めたときに、まずは自分のスキルレベルを知るために公式の模擬試験を受けてみました(税別2000円掛かりますが、他のAWS認定に合格していれば特典で無料になります)。
結果は以下の通り。

総合スコア: 65%

トピックレベルスコア:
1.0 Monitoring and Reporting: 80%
2.0 High Availability: 50%
3.0 Deployment and Provisioning: 100%
4.0 Storage and Data Management: 50%
5.0 Security and Compliance: 75%
6.0 Networking: 66%
7.0 Automation and Optimization: 0%

本番の試験では1000点満点中720点が合格ラインなので、意外といいライン行ってますね(笑)
ただ、模擬試験は本番の試験よりも難易度が易しく設定されているように感じますので、あまり信用し過ぎるのは避けるべきですね。模擬試験で見るべきは不足している知識領域がどこかを知ることです。

私の場合、「高可用性」、「ストレージおよびデータの管理」、「自動化と最適化」が弱い、ということが分かります。

②AWSサービス別資料で知識補完

知識が足りないところは「AWSサービス別資料」から補完しました。

私の場合はAuto ScalingやConfigなどにおいて、活用しました。

サービスによっては古い資料のままのものもあるので、いつ公開されたものかはチェックした上で使ったほうが良いですね。

③Udemyの試験対策

Udemyに「AWS 認定SysOpsアドミニストレーター アソシエイト模擬試験問題集(全4回分260問)」というコースがあり、それを利用していました。

本番同等形式なので65問を解かないと回答を見れないというのはなかなか大変でしたが、不正解のところは②のサービス別資料やググってj地道に知識を深めていきました。

ただ、ボリュームが多いため、結局用意されている4回分のうち2回分しかできませんでした(本番試験形式ではなくてよいので、問題解いたらすぐ回答が見れる方がうれしいですね)。

キーワードメモ

役に立つかどうかわかりませんが、私がSOAの勉強をしてた時のメモを公開します。
AWSはサービスが多様なので、このような感じに覚えないといけないサービスや用語をメモっておいていつでも振り返れるようにしておくとよいでしょう。

あくまで私が試験対策としてメモっていたものになるので、間違いや古くなっている情報があるかもしれません。また、実際に試験に出たかどうかは配慮していませんのでご留意ください。

AWS CodePipeline
AWS CodeCommit、AWS CodeBuild、AWS CodeDeployなどと連携して継続的デリバリーを実現するフルマネージドサービス

AWS Elastic Beanstalk
お手軽にアプリケーションを構築(Cloudformationで定型的なシステム構築を自動で実施)

CloudFormation
 - cfn-get-metadata ヘルパースクリプト:CloudFormation からメタデータブロックを取得して、標準出力に印字
 - cfn-init ヘルパースクリプト:テンプレートメタデータを読み取りCloudFormation のメタデータの取得と解析や、サービスの有効化/無効化と開始/停止などを行う

ELB
 - Connection Draining:ELBから切り離してもリクエスト中のインスタンスへ指定秒数の間は通信は切れない。最大3,600秒(1時間)。
 - スティッキーセッション:HTTPレスポンスにELBでCookieを埋め込んで、そのCookieを基にバインド先のインスタンスを固定するもの。送信先のEC2が障害によってダウンした場合は、セッションが途切れる問題が発生する。セッション情報は別データベース(DynamoDBやElastiCache)やキャッシュサーバなどに持たせることが推奨されている。

オンプレとVPCの間に静的VPN接続を確立
 - 仮想プライベートゲートウェイ:VPN接続でVPC側に設置。VPCあたり1つのみ設置可能。10個までVPN接続を行える。
 - カスタマゲートウェイ:VPN接続でユーザ(オンプレ)側に設置

VPC
 - ルートテーブル内のルートの状態は「active | blackhole」になる。ブラックホール(blackhole)状態はルートのターゲットが利用できないことを示す(指定されたゲートウェイがVPCに接続されていない、指定されたNATインスタンスが終了したなど)。
 - データセンターとリージョンを相互接続するAWSグローバルネットワークを流れる全てのデータは、安全性が保証された施設から通信される際に物理レイヤーで自動的に暗号化される。VPC内やVPC間は自動的には暗号化されない。
 - Egress-Onlyインターネットゲートウェイ:IPv6で、外からの通信は受け入れたくないが、内側からインターネットにつなげたい 場合に使用(IPv4の場合はNATゲートウェイ)

AWS Artifact
ISOやPCIなど第三者による監査レポートのダウンロードサービス

Amazon Inspector
AWSのEC2 インスタンスにおいて脆弱性診断を自動で行ってくれるサービス

AWS Trusted Advisor
「コスト最適化」「パフォーマンス」「セキュリティ」「フォールトトレーランス」の4つの観点で精査し、推奨設定を通知するサービス

Amazon GuardDuty
AWS環境やAWSアカウントのセキュリティ状況をモニタリングおよび通知してくれるサービス

WAF
 - WAFはファイアーウォールでありルールを設定してアクセスを遮断する。監視するには不正侵入検知(IDS)、不正侵入防御(IPS)を使う。

Snowball Edge
m4.4xlarge相当の性能を持つストレージ最適化(利用可能領域は80 TB)のSnowball Edge Storage Optimizedとエッジ処理性能が強化されたSnowball Edge Compute Optimizedがある

AWS Service Catalog
 - TagOption ライブラリを利用して、タグを簡単に管理できるようになる

Cloud Watch Logs
 - EC2のメモリは標準メトリクスで取れない(RDSのメモリは取れる)。

Cloud Watch Alarm
 - 既存のアラーム名の変更は不可
 - アラームの評価期間数に各評価期間の長さを掛けた値が1日を超えてはいけない
 - 複数のメトリクスを監視するアラームは作成できない
 - アラーム履歴の保存期間は2週間

Route53
 - Aレコード:ドメインをIPアドレスに置き換えるレコード(Address)
 - MXレコード:メールサーバのホスト名を記載するレコード(Mail Exchange)
 - CNAMEレコード:ドメインを別のドメインに置き換えるレコード(Canonical NAME)
 - トラフィックフロー:GUI(ビジュアルエディター)でDNSルーティング方法を定義

S3
 - クロスオリジンリソース共有(CORS)オプション:オリジン(htmlファイル)が異なるドメインに置かれている場合、S3資源がクロスドメインとなっていても取得可能とするもの
 - S3インベントリ:バケット内のオブジェクト一覧情報、メタデータなどを定期的にCSVなどで出力する機能
 - HTTP 503 Slow Down:バージョニングを有効にしたバケットに数百万のバージョンが存在するオブジェクトがあると頻発する。インベントリを使用すると確認できる。
 - 1putで送信できるオブジェクトの最大容量は5GB(Multipart Uploaderを使えば1オブジェクト5TBまで格納できる)。Glacierの場合は40TB。

EC2
 - Mインスタンスタイプが全てのインスタンスのベースとなっている(Mタイプはバースト性能なし)
 - 拡張ネットワーキング:高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現する
 - Amazon Data Lifecycle Manager (DLM):EBS ボリュームのスナップショットの生成 → 保存 → 削除のライフサイクルを自動化できる
 - メトリクス
  - Spillover Count – ELBからのhttp/tcpリスナーのリクエスト失敗状況
  - Request Count – 1分or5分間に完了したリクエスト/接続の数
  - UnHealthyHostCount – ロードバランサ―に登録された異常インスタンス
  - Surge Queue Length – 正常なインスタンスへの保留中リクエスト(http)または接続(ftp)の合計数
  - ELBではリクエストに関する詳細情報をアクセスログで取得できる
  - Auto ScalingはMulti AZで利用される(Multi Regionでは利用できない)

Dynamo DB
 - Auto Scalingによりループット性能を動的に調整することができる(Auto Scaling Groupの設定はできない)
 - DynamoDB Accelerator(DAX)により高速化が可能だが、インメモリDBを利用するため高コストになる

AWS Systems Manager
 - Systems Manager Automationを使うことで一般的なメンテナンスとデプロイに関する運用タスクを自動化できる(パッチ適用など)。
 - Systems Managerエージェントから取得した情報はCloudWatch Eventを使用してイベント通知が可能(Cloud Watch Logsではない)。
 - SSMエージェントよりもCloudWatchエージェントの方がEC2のメトリクスを多くとれる(CloudWatchエージェントはオンプレでも利用可でシステムメトリクスとログファイルを取れる)。
 - ステップファンクション機能やタスクスクリプト定義は利用できない。

まとめ

私の場合、実際の試験では30分くらい時間が余りました
他の方のブログを見ても、時間は余裕があったという人ばかりでしたので、じっくりと問題を解いていくのが良いと思います。

ちなみに、私はテストセンターを間違ってしまってかなり焦りました。
いつも受けているテストセンターで申し込んでいたつもりだったのですが、新しいテストセンターが近場で開設されていて誤ってそちらに申し込んでいたのです。

歩いて10分くらいで着ける場所だったので事なきを得ましたが、申し込みは慎重にしましょう。

さて、冒頭に記載した「SAA持っていればSOA楽勝か?」ですが、Noだと思います。確かにSAAの知識と被るところは多くあるのでSAA持っていた方が有利であることは確かですが、SysOpsとしての実務的な問題がでるので、それなりに時間を割いて対策をしないと合格ラインに到達できないのではないでしょうか。

公式の模擬試験を受けて、苦手分野を集中的に勉強するのが効率的かと思いますので、是非ご参考にしてください。

この記事が皆様の合格の一助となれば幸いです!

コメント

タイトルとURLをコピーしました