Summary
- AWS実務経験7年・対策時間ゼロで、2025年12月〜2026年9月にかけてAWS Microcredentials全8種を完全制覇した
- Microcredentialsは「知識を問う」試験ではなく「実際に手を動かして、動くものを作ること・修正することができるかどうか」を問う実践型評価であり、業務熟練度を試すには最適な試験である
- 調べながら受験しても構わない形式だが、作業量が多いため時間切れのリスクが高く、実務で培った即応力こそが合否を分ける
やらないこと
- Microcredentials自体の概要説明（別記事 AWS Microcredentials 受験体験記 を参照されたい）
- AWS認定試験との詳細な難易度比較・合格戦略の解説
本記事における課題
AWSの実務経験を積んだエンジニアが「自分の今の実力はどの程度か」を客観的に測る手段は、これまで選択式の認定試験しか存在しなかった。しかし選択式試験は、「頭ではわかっているが手は動かない」エンジニアでも合格できてしまうという側面がある。
AWS Microcredentialsは、AWSコンソールを実際に操作して課題を解決するハンズオン型の評価であり、「本当に使えるか」を問うという点で従来の認定試験とは一線を画す。
本記事では、AWS認定を全冠していないながらも、対策ゼロでMicrocredentials全8種を制覇した筆者の体験をもとに、この試験の実態・攻略の勘所・落とし穴を赤裸々に伝える。
やったこと
筆者のスペック
まず筆者のバックグラウンドを明示しておく。
| 項目 | 内容 |
|---|---|
| 合格したAWS認定 | Solutions Architect – Professional、Security – Specialty |
| AWS実務経験 | 約7年 |
| 担当工程 | 要件定義〜運用まで一通り |
| その他 | プライベートなAWS GameDayで優勝経験3度 |
いわゆる「認定全冠」は達成していないが、設計から運用まで幅広い実務経験を持つ、現場寄りのエンジニアである。
対策時間
対策は一切していない。今回は、「普段の業務知識が、未知の試験においてどこまで通用するのか」を純粋に検証したかった。
Microcredentialsを受験することにより、「何を知っていて何を知らなかったか」「どこで詰まり、どこは体が動いたか」というプロセスそのものに価値があると考えた。つまり、現在地を確認する目的で受験した。
なお「そもそもMicrocredentialsとは何か」については、以前執筆した AWS Microcredentials 受験体験記 に詳しくまとめているので、初見の方はそちらを先にご参照いただきたい。
受験の経緯と結果
Microcredentialsが公表された2025年12月、まず AWS Serverless Demonstrated と AWS Agentic AI Demonstrated の2つを受験し、いずれも合格した。このときの体験は上記の受験体験記に詳しく記している。
その後、2026年8月から9月にかけて残りの6種（Application Networking、Incident Response、MLOps、Data Lakehouse、Data Streaming、Data Visualization）をすべて受験し、合格をもって全8種完全制覇を達成した。
試験形式の実態
Microcredentialsは、実際のAWSコンソールを操作し、問題の指示に従った状態を作り上げると「検証」ボタンで採点される形式である。いくつかポイントを整理する。
見直しは不要、何度でも再試行できる
選択式試験と違い、「検証」ボタンを押した瞬間に正誤が判明する。不正解なら修正してもう一度検証すればよい。見直しのために時間を残しておく必要はなく、「正解するまでやり切る」スタイルで臨める。筆者はいずれの試験でも30〜40分程度を余らせて全問正解している。
調べながらでも受験できるが、時間切れに注意
試験は特に監視されておらず、Web検索で公式ドキュメントや市中の記事を参照しながら受験することも可能である。しかし、作業量そのものが非常に多い。調べながらだと作業効率が落ち、時間切れになるリスクが高い。「調べれば解ける」のではなく、「即座に手が動く」レベルの熟練度が前提の試験設計になっていると感じた。
筆者は先述の目的があり、意図的に一切Webを参照せずに挑んだが、それでも時間に余裕があった。業務で日常的に操作しているサービスであれば、調べずとも体が動く。
日本語表示でも英語の問題が混在する
日本語で受験を選択しても、問題文が翻訳されていないケースが存在した。ただし、問題文にはサービス名やリソース名が明記されているため、英語が苦手でもサービス名・リソース名から何を求められているか察することはできる。完璧な翻訳を期待せず、技術的な文脈で読み解く姿勢が求められる。
合格に必要な力
ベストプラクティスの設計知識・セキュリティ・ネットワーク知識が問われる
一見「ハンズオンだから実装力さえあれば良い」と思いがちだが、それは半分しか正しくない。AWSのベストプラクティスに則った設計知識がなければ、何と何のサービスを連携させれば良いかが瞬時にわからない。
言い換えれば、普段触れていないサービスであっても、設計・セキュリティ・ネットワークの根本的な知識が十分にあれば、応用が効く場面が少なくなかった。
例えば、「このリソースへのアクセスを制限したい」という要件であれば、IAMポリシーの構造、VPCのセキュリティグループやネットワークACLの役割、最小権限の原則といった横断的な知識が、初見のサービスであっても「おそらくここを操作すれば良い」という仮説を立てる土台になる。
「サービスの操作方法を覚えているかどうか」ではなく、「アーキテクチャの文脈でどこに何があるべきかを理解しているかどうか」が問われる。
データ分析系のMicrocredentialでは普段あまり触れないサービスも多かったが、それでも「ETLパイプラインのどこにボトルネックが生じやすいか」「ガバナンス上どこにアクセス制御を設けるべきか」といった設計の文脈を理解していることが、手を動かす起点になった。
Python・SQLのコーディングも一部必要
ごく一部ではあるが、Pythonコードの記述やSQLクエリの作成が求められる問題が存在した。ヒントは提供されるものの、プログラミングやSQLに不慣れな場合はそこで手が止まる可能性がある。データエンジニアリング系のMicrocredentialでは特に注意が必要となる。
ログ分析の傾向
業務でよく使うCloudWatch Logs Insightsを使ったログ分析の出題は少なかった印象であり、やや残念な点だった。むしろCloudTrailのログ分析やAthena＋S3を使ったログ解析の問題が多かった。
躓いたポイント・コツ
データ分析系は普段触らないサービスが多く難易度が高い
筆者が最も手こずったのはデータ分析系（Data Lakehouse・Data Streaming・Data Visualization）の3つである。AWS GlueのETL設定、Apache Icebergの最適化、QuickSightのML活用など、普段の業務では頻繁に触れないサービスが多く、体感難易度は他より高かった。
これらは、普段データ分析系の業務を担当していないエンジニアには特に注意が必要だ。前述の通り設計知識で補える部分もあるが、それだけでカバーしきれないサービス固有の作法も存在するため、事前に触れておくに越したことはない。
迷ったらまず該当サービスのコンソール画面を開く
「何から手をつければいいかわからない」という状況に陥った際に有効だったのが、問題文に書かれているサービス名やリソース名のコンソール画面をとにかく開いてみることである。
画面を眺めると、設定すべき箇所が視覚的に浮かび上がってくることが多い。手が止まったら、まず画面を開く。これが地味ながら確実な打開策だった。
出題順に従う必要はない
Microcredentialによっては、問題の出題順がランダムであり、かつ後続の問題が前の問題の完了を前提としているケースがあった。つまり、出題順に愚直に解いていくと、依存関係の上流に当たるタスクが未完のまま下流のタスクを解こうとすることになる。
全問を一通り眺め、依存関係を自ら整理してから取り組む順序を決める、というアプローチが功を奏した。これは試験というよりも、実際の業務プロジェクトで構成管理をする能力そのものを問うているとも言える。
時間を無駄せず並行作業をする
AWSにはプロビジョニングや設定の反映に数分を要するリソースが存在する。そうした作業を開始したら完了を待たず、すぐに別の問題へ着手する方が良い。
完了を待ちながら画面を眺めている時間は、そのまま他の問題を進める時間に充てられる。試験の制限時間は思いのほか早く過ぎる。「待ち時間ゼロ」を意識した並行作業の習慣が、余裕ある完走につながる。
手が止まった問題は敢えて放置する
解き方が見えない問題に直面したとき、そこで粘り続けるのは得策ではない。いったん保留にして別の問題を進めると、そちらの作業の中に解決のヒントが潜んでいるケースがある。
Microcredentialの問題は互いに関連したシナリオで構成されているため、別の問題を解くプロセスで「あの問題はこういうことだったのか」と気づく瞬間が訪れることがある。詰まったら離れる。これもまた、限られた時間を有効に使うための戦略である。
まとめ・所感
対策ゼロで全8種を制覇した感想を一言でまとめると、「これは試験ではなく、リアルな模擬戦だ」である。
AWS認定が「知識の幅」を証明するものだとすれば、Microcredentialsは「スキルの深さ」を証明するものである。選択式試験で問われるのは「正しい選択肢を選ぶことができるかどうか」だが、Microcredentialsで問われるのは「実際に動くものを作ること・修正することができるかどうか」だ。
業務経験の豊富なエンジニアこそ、ぜひ対策なしで挑戦してみてほしい。「自分の実力がどこまで通用するか」を確かめる場として、これほど正直な試験はなかなかない。
そして、まだMicrocredentialsに合格していないAWSエンジニアへ。あなたが普段当たり前のようにやっていることが、実は相当なスキルであることをこの試験が証明してくれるかもしれない。