当サイトはアフィリエイト広告(PR)を利用しています。
一度落とした分野に、学習ゼロの状態で模擬問題を当てたら36%でした。落ち込む前に誤答16問を1問ずつ分類したら、穴は3つしかありませんでした。私はAWS SOA-C03(CloudOps Engineer – Associate)に609点で落ちています。5分野のうち「満たしている」と評価されたのは1分野だけで、配点22%で最も重い分野1「モニタリング、ロギング、分析、修復、パフォーマンス最適化」は「改善が必要」でした。
本記事は、その分野1に再受験学習の最初の一手として市販の分野別模擬問題集を当てた記録です。点数そのものより、誤答16問をどう束ねたかと、36%という数字をどう受け取ると決めていたかを書きます。CloudWatchの「詳細モニタリング」と「エージェント」を取り違えていた人には、そのまま使える内容です。
1. まず結論:誤答16問は「3つの穴」に束ねられた
分野1の模擬問題を25問解いて、正解は9問でした。誤答16問を「①そのサービスや機能を知らなかった」「②知っていたが取り違えた」で分けると、①が9問、②が7問。ここまでは数を数えただけです。
次に、16問を「同じ知識で解けたはずの問題」ごとに束ねました。結果がこの表です。
| 穴 | 該当 | 1行で埋まること |
|---|---|---|
| A. 詳細モニタリング vs CloudWatchエージェント | 4問 | 詳細モニタリングは同じメトリクスが1分間隔になるだけ。メモリ・ディスク容量・プロセスは、エージェントを入れないと出ない |
| B. カスタムメトリクスの入れ方 | 2問 | 入れるのは put-metric-data(CLI/API)。CloudTrailでは送れず、put-dashboardは箱を作るだけ |
| C. 名前を知らなかった | 7問 | RDS拡張モニタリング、SSMパブリックパラメータなど、1個1行で覚える名前。深追いしない |
| 取り違えの残り | 3問 | SCPと許可セット/VPCフローログ/Auto ScalingのAZ設定 |
16問がバラバラに見えていたのに、穴Aの1行だけで3〜4問が戻り、穴Bの1行で2問が戻る。36%から40%台までは、この2行で届く距離でした。「誤答は数えるものではなく、束ねるもの」というのが、この日いちばん大きな学びです。
2. なぜ学習ゼロの状態で、先に模擬問題を解いたのか
一度目の受験で私がやったのは、2週間で範囲を詰め込み、演習で同じ間違いを繰り返したまま本番に入ることでした。詰め込んだ量に対して定着が追いつかず、どこが弱いのかを知らないまま試験を受けたのが敗因だと、落ちてから分かりました。
だから今回は順番を変えました。まず「今の実力の写真」を撮る。学習を始める前に、落とした分野の模擬問題を解いて、誤答から弱点の場所を特定してから投下する。範囲の変更点は公式ガイドで先に洗い直してあったので、次は自分の側の穴を確かめる番でした。
もうひとつ、事前に決めておいたことがあります。点数の受け取り方です。模擬問題はAWS本番より難しめに作られているものが多く、学習ゼロの素点は低く出ます。その場で見てから解釈すると、落ち込むか、逆に言い訳を始めるかのどちらかになる。だから解く前に、点数ごとに計画をどう変えるかを表にして固定しました。
| 素点 | 意味 | 計画の変更 |
|---|---|---|
| 60%以上 | 想定より良い | 新規学習より穴埋めに振り、問題集の周回を前倒しする |
| 40〜59% | 想定どおり | 変更なし |
| 40%未満 | 想定より悪い。ただし学習ゼロの素点であり、一度目の敗因そのまま | 範囲をCloudWatch中核に絞り、周辺スキルは後半に送る。欲張らない |
結果は36%。「40%未満」の枝でした。
3. 穴A:「詳細モニタリング」は時計を速くするだけ。センサーを増やすのは「エージェント」
16問のうち4問を落とした、いちばん大きな穴です。私はこの2つを「どちらも監視を強化する機能」として、ぼんやり同じ引き出しに入れていました。
EC2には、AWSが外側から計測している標準メトリクスがあります。CPU使用率、ネットワークの入出力、ディスクI/Oの回数。詳細モニタリングを有効にしても、この「見える種類」は1つも増えません。更新間隔が5分から1分になるだけです。
一方で、メモリ使用量、ディスクの「空き容量」、動いているプロセスは、インスタンスの内側を見ないと分かりません。外からは見えない。だからCloudWatchエージェントをインスタンスに入れるしかない。この線引きを持っていなかったので、次の3問を同じ理由で落としました。
- 「EC2のメモリ使用量を監視したい」という状況で、私はX-Rayを選びました。X-Rayはリクエストがどこで詰まったかを追うトレースの道具で、メモリは測れません。正解はCloudWatchエージェントでした。
- 「ディスク容量が上限に達してアプリが止まる。事前に検知したい」という状況で、私は詳細モニタリングとSNS通知を選びました。詳細モニタリングにしても、ディスク容量のメトリクスは増えません。正解はSSMでエージェントを配布し、ディスクメトリクスを取ってアラームを組む構成でした。
- 「1分間隔で更新されるダッシュボードが欲しい(2つ選ぶ)」という状況で、私は基本モニタリングと詳細モニタリングの両方を選びました。基本は5分、詳細は1分。両方選ぶのは「5分と1分を両方」と言っているのと同じで、矛盾しています。正解はCloudWatchダッシュボードと詳細モニタリングでした。選択肢を並べて比べる前に答えていた、典型的な取り違えです。
エージェントには、もう2つ「お作法」が付いてきます。ここも1問落としました。
- 権限はインスタンスのIAMロール。「エージェントを入れたのにログが上がってこない」という状況で、私はVPCエンドポイントを疑いました。正解はインスタンスプロファイルに付けるIAMロールの不足でした。エージェントの権限は人の権限ではなく、インスタンスに付けるロールで決まります。
- 配布はSSM Run Command。台数が多いときにエージェントを1台ずつ入れて回るのではなく、Systems Managerから配布します。
まとめると1行です。「詳細」は時計を速くする。「エージェント」はセンサーを増やす。メモリ・ディスク容量・プロセスは中の話だからエージェント。この1行を持っていれば、4問とも解けていました。
4. 穴B:カスタムメトリクスを「入れる」のは put-metric-data
2問を、同じ理由で落としました。どちらも「自前の値をCloudWatchに送りたい」という状況です。
- 「センサーから独自のメトリクスをCloudWatchに送りたい」という状況で、私はCloudTrailを選びました。CloudTrailは「誰がどのAPIを叩いたか」を記録する監査の仕組みで、メトリクスを送る機能はありません。
- 「CloudWatchエージェントの構成でカスタムメトリクスを公開したい」という状況で、私はput-dashboardを選びました。put-dashboardはダッシュボードという「箱」を作るAPIで、値は入りません。
正解はどちらもput-metric-data。CLIやAPIでCloudWatchに値を書き込む、それだけの話です。1問目を落とした時点でこの名前を知っていれば、2問目は落としていません。「同じ穴で2回落ちる」は、本番でも起きます。模擬で起きてよかった、と思うことにしました。
5. 穴C:名前を知らなかった7つは、1個1行で覚えて深追いしない
残りの7問は、正解のサービス名や機能名をそもそも知らなかった問題です。知らないものは推論では出てこないので、ここは「名前と1行」を覚える以外にありません。逆に言えば、それ以上やる必要もない。深追いすると時間が溶けるので、表にして終わりにしました。
| 状況の合図 | 私が選んだ | 正解の名前 | 1行 |
|---|---|---|---|
| RDSのプロセスやスレッド単位のCPUを見たい | カスタムメトリクスのスクリプト | RDS拡張モニタリング | OSレベル・プロセス単位は拡張モニタリング。Performance InsightsはSQL単位 |
| CloudFormationで常に最新のAMIを使いたい | テンプレートを手で更新 | SSMパブリックパラメータ | 最新AMI IDはParameter Storeの公開パラメータを参照する |
| Route 53ヘルスチェックの種類(2つ) | エンドポイント+EC2のCPU | エンドポイント+CloudWatchアラーム | 3種=エンドポイント/他のヘルスチェック(計算済み)/CloudWatchアラーム |
| サービス制限に近づいたら通知したい | 拡張モニタリング+SNS | Quota Monitor(Trusted Advisor起点) | クォータの追跡はTrusted Advisorが出発点 |
| CloudFrontで上位のリファラーを見たい | キャッシュ統計 | 人気オブジェクト/トップリファラー | キャッシュ統計はHTTPステータス別。レポートの名前で決まる |
| 1台だけCPUが95%に偏る | 接続ドレインを無効化 | スティッキーセッションの解除 | 1台だけ偏る=Cookieで固定されている。Cookieを切れば分散する |
| ロードバランサーが全AZに均等に振り分けない | 複数リージョンのLB | クロスゾーン負荷分散 | 「すべてのAZのターゲットへ」はクロスゾーン |
7つのうち、手元のチートシートに載っていたのは2つだけでした。残り5つは追記しました。「知らなかった」は恥ずかしいことではなく、学習ゼロで解いた模擬問題がまさに炙り出してくれるべきものです。本番で初めて出会うより、はるかにいい。
6. 取り違えの残り3問:どれも「言葉の指し先」を間違えていた
穴A〜Cに入らなかった3問は、知っていたのに指し先を間違えた問題です。
- SCPと許可セット。「IAM Identity Centerで組織のユーザーに権限を配りたい」という状況で、私はSCPを選びました。SCPは「アカウントでできることの上限」を決める枠で、人に権限を配るものではありません。人に配るのは許可セットです。
- 「トラフィックがインスタンスに届いているか」はVPCフローログ。私はCloudWatch Logsを選びました。「届いているか」はネットワークの出入りの話なので、見るのはフローログです。
- Auto Scalingが3つのAZのうち2つにしか置かない。私は「ランダムに分散するから」と考えましたが、Auto Scalingは設定したAZに均等に配置します。偏るのはAZの設定が漏れているからでした。
3問とも、正解を見た瞬間に「知っていた」と思いました。知っていることと、設問の合図から引き出せることは別で、後者は問題を解かないと鍛えられません。
7. 36%をどう受け取ったか:事前に決めた枝を、淡々と適用した
結果は「40%未満」の枝でした。境界まで1問という際どさでしたが、事前に決めたとおり、範囲を絞る側に倒しました。理由は点数ではなく、誤答の中身です。16問中11問がCloudWatch本体(穴A・B・Cの大半)に集中していたので、ここに投下量を集める判断は、点数がどちらに転んでいても正しかったからです。
具体的には、この先2週間の学習範囲を「CloudWatchエージェント、カスタムメトリクス、アラーム、ダッシュボード、Logs」の中核と、C03で新しく明記されたECS/EKSへのエージェント導入に限定しました。EBS、S3のライフサイクル、EFS/FSx、RDS Proxy、プレイスメントグループといった周辺のスキルは、後半に送りました。埋める順番は、穴A→穴B→穴C→取り違え3問。1行で3〜4問戻るところから埋めます。
一度目の私は、点数を見てからその場で計画を考えていました。二度目は、点数で計画をどう変えるかを、解く前に決めておくようにしました。これは試験の知識ではありませんが、落ちた人間が二度目に持ち込める、いちばん確かな改善だと思っています。
まとめ:誤答は数えるものではなく、束ねるもの
一度落とした分野1(モニタリング)に、学習ゼロで模擬問題25問を当てた結果は9問正解の36%でした。誤答16問を束ねると、「詳細モニタリングとエージェントの線引き」「put-metric-data」「知らなかった名前7つ」の3つの穴に収まり、最初の2つは1行ずつで埋まります。
点数だけを見ていたら、「やっぱり分野1は苦手だ」で終わっていたはずです。1問ずつ分類したから、埋める場所と順番が見えました。落ちた分野の模擬問題は、点数を取るためではなく、穴の地図を描くために解く。一度目に持っていなかった考え方です。再受験は秋を予定しています。分野1の学習が進んだら、次の分野の誤答ログを同じ形で書きます。一緒に「シフト」していきましょう。
この記事は、SOA-C03の再受験に向けた学習記録の2本目です。落ちた経緯と、そこから何を変えたかは、以下からどうぞ。