Q1.下の表に示す 4 つの Azure 仮想ネットワークが同一サブスクリプション内に構成されています。
VNet1 を起点として、ピアリング接続を確立できる仮想ネットワークはどれですか。
| 名前 | アドレス空間 | サブネット | リソースグループのAzure リージョン |
|---|---|---|---|
| VNet1 | 10.11.0.0/16 | 10.11.0.0/17 | 米国西部 |
| VNet2 | 10.11.0.0/17 | 10.11.0.0/25 | 米国西部 |
| VNet3 | 10.10.0.0/22 | 10.10.1.0/24 | 米国東部 |
| VNet4 | 192.168.16.0/22 | 192.168.16.0/24 | 北ヨーロッパ |
解答を見る
Azure 仮想ネットワークピアリングでは、接続する仮想ネットワーク間でアドレス空間が重複していないことが必須条件です。
VNet1(10.11.0.0/16)と VNet2(10.11.0.0/17)はアドレス範囲が重複しているため、ピアリングを作成できません。
一方、VNet3(10.10.0.0/22)および VNet4(192.168.16.0/22)は VNet1 とアドレス空間が重複していないため、リージョンが異なってもグローバル仮想ネットワークピアリングで接続可能です。
したがって、接続できるのは VNet3 と VNet4 のみとなります。
Azure 仮想ネットワーク ピアリング
Q2.ある Azure サブスクリプションを管理しています。
サブスクリプション内のいずれかのリソースからリソース ロックが削除された際に、電子メール アラートを受け取る必要があります。
Azure Monitor でこのアクティビティ ログ アラートを作成するには、どの構成要素を使用すればよいですか。
解答を見る
Azure Monitor のアクティビティ ログ アラートは、「対象リソース(スコープ)」「条件」「アクション グループ」の3要素で構成されます。
リソース ロックの削除はアクティビティ ログに記録される管理操作であり、そのイベントを条件として定義し、通知先としてアクション グループ(電子メールなど)を指定します。
Log Analytics ワークスペースやデータ収集エンドポイントはログ収集や分析用途であり、アクティビティ ログ アラートの必須構成要素ではありません。
また、Microsoft 365 グループも直接の構成要素ではありません。
アクティビティ ログ、サービス正常性、またはリソース正常性の警告ルールを作成または編集する
Q3.ユーザーへライセンスを再度割り当てる前に、発生しているライセンスの問題を解消する必要があります。
どの操作を行うべきですか。
解答を見る
Azure Active Directory(現在は Microsoft Entra ID に名称変更)では、ユーザーにライセンスを割り当てる前に「使用場所(Usage location)」を設定する必要があります。
使用場所が未設定の場合、「ライセンス契約に失敗しました」などのエラーが発生し、ライセンスを割り当てられません。
これは各国の法規制やサービス提供可否に基づく要件です。
したがって、ユーザーの[プロファイル]から使用場所を正しく設定した後に、再度ライセンスを割り当てます。
グループ追加やディレクトリ ロール変更ではこの問題は解決しません。
Microsoft 365 管理ポータルでグループのライセンス割り当ての問題を特定して解決する
Q4.VM1 という名前の Azure 仮想マシンを運用しています。
VM1 は、ARMIjson という名前のカスタム Azure Resource Manager テンプレートを用いてデプロイされました。
ある日、VM1 がメンテナンスの影響を受けるという通知が届きます。
VM1 を直ちに別のホストへ移動する必要があります。
解決策として、VM1 の「再デプロイ + 再適用」ブレードから再デプロイを選択します。
この方法は目標を満たしていますか。
解答を見る
Azure 仮想マシンの「再デプロイ」は、VM を停止してから新しい物理ホストへ再配置する機能です。
これにより、基盤ホストのメンテナンスやハードウェア障害の影響を回避できます。
再デプロイを実行すると、VM は別のホストに移動され、一時ディスクの内容は失われますが、OS ディスクやデータ ディスクは保持されます。
したがって、メンテナンスの影響を受ける前に別ホストへ移動するという要件を満たしています。
なお、Azure Resource Manager は現在も正式名称であり、旧称はありません。
仮想マシンを新しい Azure ノードに再デプロイする
Q5.Azure サブスクリプションに storage1 という名前のストレージ アカウントが含まれています。
storage1 アカウントには container1 という名前のコンテナーが含まれています。
この container1 へのアクセスを構成する必要があり、ソリューションは次の要件を満たす必要があります。
読み取りアクセスのみを許可すること。
HTTP と HTTPS の両方のプロトコルを許可すること。
コンテナー内のすべてのコンテンツにアクセス権限を適用すること。
何を使用すべきですか。
解答を見る
共有アクセス署名(SAS)は、Azure Storage リソースに対して制限付きアクセスを委任するための仕組みです。
SAS を使用すると、読み取り専用などのアクセス許可を細かく指定でき、さらに許可するプロトコルとして HTTP および HTTPS を選択できます。
また、コンテナー単位で発行することで、そのコンテナー内のすべての BLOB に対して指定したアクセス権を適用できます。
アクセス キーはアカウント全体への完全アクセスを許可するため要件を満たしません。
CDN は配信最適化のサービスであり、アクセス制御の仕組みではありません。
Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する
Q6.Subscription1 という名前の Azure サブスクリプションを使用しています。
contosostorage という名前の Azure ストレージ アカウントを作成し、続いて data という名前のファイル共有を作成します。
この data ファイル共有内のファイルを参照するスクリプトには、どの UNC パスを指定すべきですか。
選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます(同じ選択肢は複数回使用可)。
blob.core.windows.net
contosostorage
data
file
file.core.windows.net
portal.azure.com
subscription1
解答を見る
Azure Files のファイル共有へアクセスする場合、UNC パスは「\\ストレージアカウント名.file.core.windows.net\ファイル共有名」という形式になります。
これは Azure Files が SMB プロトコルを利用したネットワーク共有として提供されるためです。
本問題ではストレージアカウント名が contosostorage、作成したファイル共有が data であるため、正しい UNC パスは \\contosostorage.file.core.windows.net\data になります。
blob.core.windows.net は Azure Blob Storage のエンドポイントであり、Azure Files では使用されません。
また subscription1 や portal.azure.com も UNC パスの構成には含まれません。
Azure Files とは
Q7.下の表に示すストレージ アカウントを含む Azure サブスクリプションがあります。
ホット アクセス層の BLOB ストレージを必要とする App1 というアプリケーションをデプロイする必要があります。
App1 に使用できるストレージ アカウントはどれですか。
| 名前 | パフォーマンス | Premium アカウントの種類 |
|---|---|---|
| storage1 | 標準 | 該当なし |
| storage2 | プレミアム | ブロック BLOB |
| storage3 | プレミアム | ファイル共有 |
| storage4 | プレミアム | ページ BLOB |
解答を見る
Azure Blob Storage のアクセス層(Hot、Cool、Archive)は、Standard ストレージアカウント、または Block Blob をサポートする Premium ストレージで使用できます。
storage1 は Standard アカウントのため Blob Storage のホット層を利用できます。
storage2 は Premium の Block blobs 用アカウントであり、Blob データを扱えるため利用可能です。
storage3 は Premium の File shares(Azure Files 用)であり Blob Storage ではないため使用できません。
storage4 は Premium の Page blobs(主に仮想マシンディスク用)ですが Blob Storage として利用可能です。
したがって App1 で使用できるのは storage1、storage2、storage4 の 3 つです。
BLOB データに関するアクセス層
Q8.オンプレミスの Active Directory に関する問題を解決する必要があります。
どの操作を行うべきですか。
解答を見る
オンプレミスの Active Directory を Azure Active Directory(現在の正式名称は Microsoft Entra ID)と同期する場合、ユーザー属性に Azure 側でサポートされない値や文字が含まれていると同期エラーが発生します。
IdFix ツールは、Azure AD Connect によるディレクトリ同期の前に、Active Directory 内の属性(UPN、ProxyAddress など)に存在する無効な文字や重複値を検出し、修正するための Microsoft 公式ツールです。
UPN に特殊文字が含まれている可能性がある場合、IdFix を実行して検出された問題を編集(Edit)アクションで修正するのが適切です。
ユーザー属性の直接編集やサフィックス変更、同期規則の変更では、無効値の検出・是正が確実に行えません。
IdFix ツールを使用してディレクトリ同期のための属性を準備する
Q9.下の表に示すリソースが含まれる Sub1 という名前の Azure サブスクリプションがあります。
Sub1 には次のアラート ルールが構成されています。
名前: アラート1。
スコープ: Sub1 内のすべてのリソース グループ(将来のすべてのリソースを含める)。
条件: すべての管理操作。
アクション: アクション1。
さらに Sub1 には次のアラート処理ルールが構成されています。
名前: ルール1。
範囲: Sub1。
ルールの種類: 通知を抑制する。
ルールの適用: 特定の時間帯(開始日 2022年8月10日、終了日 2022年8月13日)。
以下の各記述について、正しい場合は「はい」を、そうでない場合は「いいえ」を選択してください。
| 名前 | 説明 |
|---|---|
| RG1 | リソースグループ |
| Action1 | admin1@contoso.comに電子メール メッセージを送信するアクション グループ |
| 問題文 | はい | いいえ | |
|---|---|---|---|
| 2022年8月11日に Sub1 内でリソース グループを新規作成すると、Azure ポータル上に Alert1 が表示される。 | |||
| 2022年8月12日に Sub1 内でリソース グループを新規作成すると、admin1@contoso.com 宛に電子メールが送信される。 | |||
| 2022年8月15日に RG1 へタグを追加すると、admin1@contoso.com 宛に電子メールが送信される。 |
解答を見る
Azure Monitor のアラート処理ルール(Alert Processing Rule)は、指定した期間にアラート通知を抑制したり変更したりする機能です。
この問題では 2022年8月10日から8月13日まで通知が抑制されています。
ただしアラート自体は生成されるため、Azure ポータルにはアラートが表示されます。
したがって 8月11日にリソース グループを作成した場合、アラートは表示されますが通知は送信されません。
8月12日は抑制期間内のためメールは送信されません。
一方、8月15日は抑制期間外なので、管理操作(タグ追加)が発生するとアクション グループが実行され、admin1@contoso.com にメールが送信されます。
アラート処理ルール
Q10.WebApp1 という新しい Azure App Service アプリを構成する必要があります。
ソリューションは次の要件を満たす必要があります。
WebApp1 は app.contoso.com のカスタム ドメイン名を検証できること。
WebApp1 は最大 8 つのインスタンスまで自動的にスケールできること。
コストと管理の手間を最小限に抑えること。
どの料金プランを選択し、ドメインの検証にはどのタイプのレコードを使用すべきですか。
回答するには、回答エリアで適切なオプションを選択してください。
解答を見る
Azure App Service の自動スケール機能(Auto scale)は Standard プラン以上で利用できます。
Basic、Free、Shared プランでは自動スケールがサポートされないため、最大 8 インスタンスまで自動的にスケールするという要件を満たすには Standard プランが必要です。
また、App Service でカスタム ドメインを安全に検証する場合は、DNS の TXT レコードを使用する方法が推奨されています。
TXT レコードはドメイン所有権の検証に使用され、A レコードなどより安全にドメインを確認できます。
要件を満たしつつ最小コストで実現できるのは、Standard プランと TXT レコードの組み合わせです。
Azure App Service で既存のカスタム ドメインを設定する
Azure App Service でアプリをスケールアップする
