はじめに
最近、マルチクラウド案件が増えてきたのと、Azureの開発系サービスを体系的に押さえておきたかったのでAZ-204を受けることにしました。
実は今年の2月に受験していて、一回落ちているんです。
前回はあんまり時間をとって勉強しなかったので、今回はMicorosoft公式のAZ-204やUdemyの模擬問題を何周か解いて、苦手な部分や頻出パターンを整理したのがこの記事です。自分用のメモだけど、同じようにAWSからAzureに手を広げようとしている人の参考になれば。
⚠️ AZ-204は2026年7月31日で廃止。 後継はAI-200（Azure AI Cloud Developer Associate）。受けるなら急いだほうがいいです。4月ぐらいに気づきました。
参考：Study guide for Exam AZ-204 - Microsoft Learn
あくまで自分用なので、間違っている内容あればそっと指摘してください・・・
1. Azure ↔ AWS サービス対応表
AZ-204は「どのサービスを使うか」「どの設定で有効になるか」が頻出。AWSとの対応を頭に入れておくと理解が早い。
| Azureサービス | 役割 | AWSで近いもの | 一言メモ |
|---|---|---|---|
| App Service | Web/APIホスティング | Elastic Beanstalk / App Runner | マネージドWebアプリ基盤 |
| Azure Functions | サーバーレス関数 | Lambda | イベント駆動 |
| Container Apps | コンテナのサーバーレス実行 | App Runner / ECS on Fargate | コンテナ版Lambda的な |
| Container Instances | 単発コンテナ実行 | ECS Fargate RunTask | クラスター不要 |
| Storage Blob | オブジェクトストレージ | S3 | ファイル・大容量データ |
| Storage Queue | 軽量キュー | SQS | 軽量メッセージ |
| Service Bus | エンタープライズメッセージング | SNS+SQS / SQS FIFO | 順序・重複検出・DLQ |
| Event Hubs | イベントストリーミング | Kinesis / MSK | 高スループット |
| Event Grid | イベント通知 | EventBridge | pub/sub通知 |
| Cosmos DB | グローバル分散DB | DynamoDB | マルチリージョンNoSQL |
| Key Vault | Secret/Key/Cert管理 | Secrets Manager / KMS | 秘密情報の保管庫 |
| API Management | APIゲートウェイ | API Gateway | API公開・認可 |
| Monitor / App Insights | 監視・APM | CloudWatch / X-Ray | ログ・メトリクス・トレース |
| RBAC | アクセス制御 | IAM | 権限管理 |
| Microsoft Entra ID | ID基盤 | IAM Identity Center / Cognito | 認証基盤 |
2. 頻出度ランキング
🔴 最頻出（よく問題で見るやつ）
Azure Functions
- トリガー使い分け：BlobTrigger / QueueTrigger / HTTP Trigger / Timer Trigger
- Blobが追加されたら処理 → BlobTrigger、Queueにメッセージが来たら → QueueTrigger、定期実行 → TimerTrigger（CRON式）
- Managed Identity：Functionから他サービスへアクセスする際、接続文字列をコードに書かずにIDベースで認証する
-
AzureWebJobsStorage：Functions実行に必須のストレージ接続。これがないとFunctionが起動しない - Key Vault参照：App Settingsに
@Microsoft.KeyVault(SecretUri=...)形式で書くとsecretを直接参照できる - App Insights連携：分散トレーシング、失敗率の監視。
APPINSIGHTS_INSTRUMENTATIONKEYの設定
App Service
- Deployment Slots：本番とステージングを入れ替えてゼロダウンタイムデプロイ。slot swap時にapp settingsの「スロット固定」設定に注意
- Autoscale：CPU/メモリ/HTTPキュー長などのメトリクスに基づいてインスタンス数を自動増減。Standard以上でのみ利用可
- App Service Plan SKU：Basic→slots/autoscale不可、Standard→一通り使える、Premium→ゾーン冗長・高性能
- HTTPS only / TLS 1.2+：設定で強制。試験では「セキュリティ要件を満たす最小変更」として出る
- VNet Integration：App Serviceからプライベートサブネット内のリソースにアクセスする。Standard以上
- Managed Identity + App settings / Key Vault reference：secretをコードに書かない構成の定番パターン
Storage（Blob / Queue）
- Blob metadata / properties / tags の違い：metadata=カスタムKV、properties=Content-TypeなどHTTPヘッダ、tags=検索用インデックス。それぞれ更新APIが異なる
-
SetHttpHeadersAsync：Content-TypeやCache-Controlを変更する時に使う。再アップロード不要 - ETag / If-Match：楽観的排他制御。他の人が同時に更新していたら412エラーで弾く
- Queueの
MessageId+PopReceipt：メッセージ削除にはこの2つが必要。片方だけでは消せない - claim-check pattern：200KB超のペイロードはBlobに置いて、QueueにはBlobのURIだけ入れる
- poison message：5回処理失敗したメッセージは自動的にpoison queueに隔離される
Managed Identity / Entra ID / RBAC
- 認証と認可の違い：Managed Identity=「自分は誰か」を証明、RBAC=「何ができるか」を許可。両方セットで初めてアクセスできる
- system-assigned vs user-assigned：system=リソースと一蓮托生で管理が楽、user=複数リソースで共有したい時
- ロール例：
AcrPull（コンテナイメージ取得）、Storage Blob Data Contributor（Blob読み書き）、Service Bus Data Sender/Receiver（メッセージ送受信） - Key Vaultアクセス：Managed Identity +
Key Vault Secrets Userロールの組み合わせ
Cosmos DB
- 一貫性レベル（5段階）：Strong > Bounded Staleness > Session > Consistent Prefix > Eventual の順で強い
- Session：自分が書いたデータを自分がすぐ読める。一般的なWebアプリの既定候補
- Bounded Staleness：複数書き込みリージョンで陳腐化に上限を設けたい時。監査系で出る
- multi-region writes：Strongとは両立しない。これが罠として頻出
- Change Feed + lease container：Cosmos DBの変更をリアルタイムに検知して処理する仕組み。lease containerで処理済み位置を管理
🟠 頻出
API Management
- Product / Subscription / Developer Portal：Productがアクセス制御の単位。APIをProductに紐づけ、Subscriptionキーでアクセスさせる。Developer Portalで外部開発者にAPIを公開
-
validate-jwt：インバウンドポリシーでJWTトークンを検証。audience/issuerの指定が問われる - subscription key header変更：デフォルトは
Ocp-Apim-Subscription-Keyだが、カスタムヘッダ名に変更可能 - mTLS / OpenAPI import：クライアント証明書による相互認証、OpenAPI(Swagger)からAPIを一括インポート
Container Apps / ACI / ACR
- Managed IdentityでACR pull：Container AppsやACIからACRのイメージを取得するには
AcrPullロールが必要。これがないとUnauthorizedエラー - private networking / restricted egress：外部通信を制限する構成。Private Endpoint + NSGの組み合わせ
- ingress port mismatch：Container Appsのingress設定とコンテナのLISTENポートが合っていないと接続できない
- ACI subnet delegation：ACIをVNetに配置するにはサブネットの委任（delegation）が必要。忘れるとデプロイ失敗
- Container Apps revisions / traffic split：新旧リビジョンにトラフィックを%で振り分け。カナリアデプロイ的な使い方
Monitor / Application Insights
- request / dependency / trace の相関：分散トレーシングでリクエストの流れを追跡。operation_idで紐づく
- availability test：外部からURLを定期的に叩いて死活監視
- Action Group：アラート発火時の通知先（メール、SMS、Webhook等）をグループ化
- Log Analytics：KQLでログを検索・分析。App Insightsのバックエンド
- RBAC read-only access：監視データの閲覧権限を最小限に絞る時に使う
メッセージング使い分け
| サービス | 役割 | 選択基準 |
|---|---|---|
| Queue Storage | 軽量な仕事待ち | 単純な非同期ジョブ、64KB以下のメッセージ |
| Service Bus | 企業向けメッセージング | 順序保証 / DLQ / 重複検出 / セッション |
| Event Hubs | 大量イベント流し込み | 秒間数百万イベント、パーティション分散 |
| Event Grid | イベント通知 | リソース変更の通知、pub/subルーティング |
3. 苦手分野まとめ
A. 認証・認可（Managed Identity）
- Managed Identity = 認証（誰か）
- RBAC = 認可（何ができるか）
- ID有効化だけではアクセスできない。ロール付与が必須
ロール付与パターン
| 対象 | ロール |
|---|---|
| ACRからイメージpull | AcrPull |
| Blob読み書き | Storage Blob Data Contributor |
| Blob読み取りのみ | Storage Blob Data Reader |
| Queue処理 | Storage Queue Data Contributor |
| Service Bus送信 | Azure Service Bus Data Sender |
| Service Bus受信 | Azure Service Bus Data Receiver |
| Key Vault secret読み取り | Key Vault Secrets User |
| Event Hubs送信 | Azure Event Hubs Data Sender |
| Event Hubs受信 | Azure Event Hubs Data Receiver |
system-assigned vs user-assigned
| 種類 | 特徴 | 使いどころ |
|---|---|---|
| system-assigned | シンプル、リソースと一蓮托生 | dev/testで再作成が多い |
| user-assigned | 複数リソースで共有、独立ライフサイクル | 本番で複数サービスから共用 |
このキーワードが出たら → Managed Identity
no secrets/avoid key rotation/auditable/without code changes/RBAC/platform-managed identity
B. App Service Plan
SKU別機能
| 機能 | Basic | Standard | Premium |
|---|---|---|---|
| Autoscale | ❌ | ✅ | ✅ |
| Deployment Slots | ❌ | ✅ | ✅ |
| VNet Integration | ❌ | ✅ | ✅ |
| コスト | 低 | 中 | 高 |
- Basicでは足りないことが多い（slots / autoscale / VNet は Standard以上）
- 最小コストで要件満たすなら → Standard
- ゾーン冗長・高性能 → Premium
罠
- ❌ Basicでautoscaleできる → 無理
- ❌ slotがあるからBasicでOK → slotはStandard以上
C. Blob Service
3分類
| 機能 | 用途 | 例 |
|---|---|---|
| Metadata | 補足情報（カスタムKV） |
tenantId, class
|
| Properties / HTTP headers | 配信制御 |
Content-Type, Cache-Control
|
| Index Tags | 検索・フィルタ | Class=Claim |
ポイント
- Content-Type変更 →
SetHttpHeadersAsync - metadata変更 →
SetMetadataAsync - 再アップロード不要で更新可能
- metadata keyにスペース不可
- ETag + If-Match で楽観的排他制御
監査・コスト系
| 機能 | 用途 |
|---|---|
| Lifecycle Management | Hot → Cool → Archive → 削除 |
| Immutable Storage | WORM（保持期間中は削除不可） |
| Blob Index Tags | 条件で対象を絞る |
Queueとの使い分け
- Queue = 軽量メッセージ（通知・ジョブ指示）
- Blob = 大きな本体データ
- 200KB超 → Blob + Queue参照（claim-check pattern）
Queue必須暗記
- 削除には
MessageId+PopReceiptが必要 DeleteMessageAsync(messageId, popReceipt)- Visibility Timeoutで再取り出し制御
- poison messageは隔離
D. Cosmos DB 一貫性レベル
5段階
| レベル | 特徴 | 場面 |
|---|---|---|
| Strong | 最強整合性、最重 | 厳密な最新性が必要 |
| Bounded Staleness | 陳腐化に上限 | 複数書き込みリージョン + 監査 |
| Session | read-your-writes | 一般的なWebアプリ |
| Consistent Prefix | 順序は保つが弱め | 順序重視のイベント |
| Eventual | 最弱、最軽 | 非クリティカル、安い |
出題パターン
| 要件 | 答え |
|---|---|
| 自分の更新をすぐ見たい | Session |
| 複数リージョン + 陳腐化上限 | Bounded Staleness |
| 順序保証、session token不要 | Consistent Prefix |
| 一番安く | Eventual |
罠
- Strong + multi-write → 失敗する
- Session token継続が前提でないならSession以外も候補
- RU節約だけで選ばない
4. サービス使い分け早見表
メッセージング / イベント
- 順序 / DLQ / 重複検出 → Service Bus
- 大量流し込み → Event Hubs
- イベント通知 → Event Grid
- 軽い非同期ジョブ → Queue Storage
コンテナ
| サービス | 用途 |
|---|---|
| App Service for Containers | Webアプリのコンテナ実行 |
| Container Apps | サーバーレスコンテナ |
| Container Instances | 単発・一時コンテナ |
| ACR | イメージ保管 |
コンテナ系の罠
-
exec format error→ ARM64/AMD64不一致 -
Image pull failed: Unauthorized→AcrPull不足 -
subnet not delegated→ ACI用サブネット委任不足
5. 問題タイプ別攻略
並べ替え問題
典型：
- identity作成 → RBAC付与 → app作成
- App Service Plan → Web App → identity/slot
- Key Vault → reference → app startup
- APIM: API作成 → OpenAPI import → Product追加 → Portal公開
→ 先に土台、次に権限、最後にアプリ
言い換え問題
| キーワード | 答え |
|---|---|
| no secrets | Managed Identity |
| zero downtime | Deployment Slot |
| content-type | SetHttpHeadersAsync |
| audience | JWT validation |
| private endpoint | DNS / VNet |
6.直前暗記リスト(一口メモ)
| キーワード | 選ぶもの |
|---|---|
| secret | Managed Identity / Key Vault |
| ゼロダウンタイム | Deployment Slots |
| 大きいデータ | Blob |
| 小さい通知 | Queue |
| 順序・DLQ | Service Bus |
| 大量イベント | Event Hubs |
| イベント通知 | Event Grid |
| read-your-writes | Session |
| 複数write + 陳腐化上限 | Bounded Staleness |
| API公開 + 認証制御 | APIM + JWT |
| private network | Private Endpoint + DNS + RBAC |
おわりに
この記事自体は試験の数日前にメモを取るついでに作って、試験前に下書き状態のページを見直しながら確認しました。
試験自体は無事合格しました。
追記
以下、試験の簡単な感想です。
- AWS試験と違ってあるシナリオに沿って、連続した問題が出題されるので試験時間がカツカツ
-
Service Bus、Event Hubs、Event Gridの違いを雰囲気で理解していたので、今回の表に整理することでようやく違いをしっかりと理解できた - 同一サービスでも
Service Planによって使える機能が異なってくるのがAzure特有と感じる - 結局プログラム問題は自分で実際にコードを書くことはなかったですが、何回か問題を解いているうちにパターンがわかってきたので本番も問題なく回答できた
勉強した時間: 20時間
点数: 792
参考にしたサイト:
- Microsoft-learn AZ-204
- udemy: AZ-204 Practice Tests 2026 Azure Developer Associate
- udemy: 【日本語対応！！】AZ-204: Microsoft Azure Developer Associate 対策問題集
注意事項
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。