収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
複数の部門がAzureを使い始めます。共通のガバナンスは保ちつつ、各チームにはサブスクリプション単位で権限を委譲したい。最も適切な基盤設計はどれですか？
答え： 管理グループ階層とAzure Policyを使うランディングゾーン
ランディングゾーンでは管理グループとサブスクリプションを整理し、上位スコープのポリシーでガードレールを適用しつつ、ワークロードチームへ権限を委譲します。
同じ管理要件を持つ多数の業務サブスクリプションへ構成ルールを継承させたい。Azure Policyの割り当て先として最も保守しやすいものはどれですか？
答え： 対象サブスクリプションを束ねる管理グループ
共通要件は管理グループへポリシーまたはinitiativeを割り当て、配下へ継承させると重複を減らせます。例外は明示的に管理します。
本番ワークロードで可用性ゾーン障害に耐えたい。ステートレスなアプリ層の基本設計として適切なのはどれですか？
答え： 複数ゾーンへインスタンスを分散し、ゾーン冗長な入口を使う
ゾーン障害への耐性には、計算資源と入口の両方を複数ゾーンへ分散し、状態を外部化して各ゾーンで処理を継続できる設計が必要です。
世界各地のHTTPアプリへ単一の公開エンドポイントを提供し、WAFと高速なグローバルフェイルオーバーを利用したい。適切なサービスはどれですか？
答え： Azure Front Door
Azure Front Doorはグローバルなレイヤー7入口として、Anycast、HTTPルーティング、ヘルスプローブ、WAFを統合できます。
社内VNetからStorage AccountへプライベートIPで接続し、パブリックネットワークアクセスを無効化したい。追加で重要な設計はどれですか？
答え： 非公開エンドポイントと非公開DNSの名前解決を構成する
非公開エンドポイントでは通常のサービスFQDNをプライベートIPへ解決させるDNS設計が不可欠です。オンプレミス接続時はDNS転送経路も検討します。
多数のスポークVNetが共有ファイアウォール、DNS、オンプレミス接続を利用する。責任分離しやすい構成はどれですか？
答え： 接続サブスクリプションのハブとワークロード別スポーク
Hub-Spokeでは共有接続サービスをプラットフォーム側に集約し、ワークロード境界をスポークやサブスクリプションで分離できます。
特権管理者ロールを常時付与せず、承認とMFAを経て必要な時間だけ有効化したい。使うべき機能はどれですか？
答え： Microsoft Entra Privilegedアイデンティティ管理
PIMは対象ロールをeligibleとして管理し、期限、承認、MFA、理由入力などを伴うJust-In-Time有効化を構成できます。
アプリからKey Vaultへアクセスするための資格情報運用を最小化したい。最も望ましい方式はどれですか？
答え： Managed Identityを使い、Key Vaultで最小権限を付与する
Managed Identityならアプリが長期資格情報を保持せずEntra IDトークンを取得できます。データプレーン権限は必要な操作だけに絞ります。
Azure Monitorエージェントで複数のVMからWindowsイベントを収集します。不要なイベントは取り込む前に除外したい。中心となる構成はどれですか？
答え： データコレクションルールと関連付け
DCRは収集対象、変換、送信先を定義し、DCRAで対象リソースへ関連付けます。取り込み前変換により不要データの保存コストも抑えられます。
Azure Monitorのアラートで、一時的な単発のスパイクによる誤通知を減らしたい。その上で、通常の傾向からの逸脱は検出したい。適切な検討はどれですか？
答え： 動的しきい値と評価期間をワークロード特性に合わせる
動的しきい値は履歴傾向を学習し、評価頻度や期間と組み合わせて異常を判定します。実運用データで感度とノイズを調整します。
複数サブスクリプションに散在する、特定タグがないパブリックIP付きリソースを横断検索したい。適切なサービスはどれですか？
答え： Azureリソースグラフ
Azureリソースグラフは多数のサブスクリプションにまたがるリソース構成をKQL系のクエリで高速に棚卸しできます。
Azure SQLデータベースのリージョン障害に備え、別リージョンへ読み取り可能な複製とフェイルオーバー管理を用意したい。適切な機能はどれですか？
答え： フェイルオーバーグループ
Azure SQLのフェイルオーバーグループは複数リージョンのデータベース複製と読み書きリスナーを管理し、計画・自動フェイルオーバーを支援します。
バックアップ管理者アカウントが侵害されても、保護データを即座に削除されにくくしたい。Azureバックアップで優先すべき機能はどれですか？
答え： VaultのimmutabilityとMulti-user authorization
不変vaultは保護データを変更・削除しにくくし、Multi-user authorizationは重要操作へ別担当の承認を要求して単一資格情報侵害の影響を抑えます。
オンプレミスVMをAzureへ災害復旧し、RPO/RTOを定期的に検証したい。中核サービスと運用はどれですか？
答え： Azure Site Recoveryを構成し、非破壊のテストフェイルオーバーを定期実施する
Site Recoveryはレプリケーションと復旧計画を管理します。テストフェイルオーバーで本番へ影響させず、依存関係や手順がRTO内で動くか確認します。
AKSでノード障害や更新時にもアプリを継続しやすくする設計として適切なのはどれですか？
答え： 複数レプリカ、topology spread、PodDisruptionBudgetを要件に合わせて構成する
複数レプリカを障害ドメインへ分散し、PDBで自発的中断時の最低稼働数を守ります。readiness probeで利用可能なPodだけへ送信します。
AKSのアプリPodからAzureサービスへアクセスする際、Kubernetesシークレットに長期クライアントシークレットを保存したくない。推奨方式はどれですか？
答え： Microsoft EntraワークロードIDを使う
ワークロードIDはKubernetes ServiceAccountとEntra IDのフェデレーションを使い、Podが長期シークレットなしでトークンを取得できるようにします。
予約容量を購入する前に、安定稼働中のVM群のコストを下げたい。最初に行うべきことはどれですか？
答え： 利用率、稼働時間、サイズ適正化、将来需要を分析する
まず不要資源と過剰サイズを除き、継続利用が見込めるベースラインを把握します。その後、予約またはSavingsプランの柔軟性と割引を比較します。
各チームに月次予算の超過を知らせたい。ただし、通知を設定しただけでVMが自動停止するとは限りません。この点を踏まえた適切な説明はどれですか？
答え： コスト管理予算で通知し、必要ならアクショングループ等と安全な自動化を連携する
予算は支出実績や予測に応じた通知が中心です。停止等を自動化する場合は業務影響、権限、再実行性を考慮した別処理を設計します。
本番変更の失敗率を下げ、問題発生時に影響範囲を限定したい。Well-Architectedの運用上適切な方法はどれですか？
答え： 段階的ロールアウト、健全性判定、自動停止・ロールバックを設計する
Safe deployment practiceでは小さな範囲から段階展開し、観測した健全性をゲートにして拡大します。失敗時の停止と復旧も自動化します。
可用性目標99.99%の根拠を設計レビューで説明したい。最も適切な進め方はどれですか？
答え： ユーザーフロー、依存関係、複合SLA、冗長化、復旧手順を評価する
ワークロード可用性は依存サービスと構成に左右されます。重要ユーザーフローごとに依存関係を明示し、複合SLAと実測SLI、復旧能力を確認します。
インターネット公開WebアプリでTLS終端、パスベースルーティング、WAFをリージョン内に配置したい。適切なサービスはどれですか？
答え： Azure Application Gateway WAF
Application Gatewayはリージョン内のレイヤー7ロードバランサーで、TLS終端、URLルーティング、WAFを提供します。
DNSベースで複数リージョンの任意プロトコルの公開エンドポイントを振り分けたい。HTTPプロキシ機能は不要です。適切なのはどれですか？
答え： Azure Traffic Manager
Traffic ManagerはDNS応答を使って正常な公開エンドポイントへクライアントを誘導します。プロキシではないため既存接続はDNS TTLの影響を受けます。
強制トンネリング環境でAzure Firewallを経由させたところ、一部PaaSの戻り通信が非対称になった。最初に確認すべき設計要素はどれですか？
答え： UDR、BGP経路伝播、次ホップ、SNATの組み合わせ
非対称経路はルートテーブル、ゲートウェイからの経路伝播、ファイアウォールのSNAT動作が食い違うと発生します。有効な経路と次ホップを確認します。
Log Analyticsへのデータ取り込みとクエリをプライベート経路に限定したい。さらに、許可したワークスペース以外へデータが流れることも防ぎたい。適切な構成はどれですか？
答え： Azure Monitor非公開リンクスコープを非公開Onlyで設計する
AMPLSはAzure Monitorリソースを非公開リンク境界へまとめます。非公開Onlyでは接続VNetからスコープ外の監視リソースへのアクセスを制限できます。
多数のサブスクリプションでDefender for Cloudの推奨事項とセキュリティ基準を一貫適用したい。適切な管理方法はどれですか？
答え： 管理グループ単位のポリシーinitiativeとDefender設定をコード化する
管理グループのポリシーinitiativeとIaCで基準を継承させ、Defenderプランや監視設定のドリフトを検出・修正できるようにします。
Microsoft Sentinelで大量の低品質アラートにSOCが疲弊している。最初の改善として適切なのはどれですか？
答え： 検知ルールをユースケース、エンティティ、重大度で調整し、自動化ルールでトリアージする
脅威モデルに沿って検知ロジックと除外を調整し、関連アラートをインシデントへ集約します。既知の低リスク事象は自動化で分類します。
Azure Policyで非準拠と判定された既存リソースを、Managed Identityを使って自動修復したい。利用する効果はどれですか？
答え： modifyまたはdeployIfNotExists
modifyとdeployIfNotExistsは割り当てのManaged Identityと必要権限を使って構成を変更・追加できます。既存資源にはremediation taskを実行します。
本番リソースの誤削除を防ぎたいが、アプリの通常更新は許可したい。適切なリソースロックはどれですか？
答え： CanNotDeleteを適切なスコープへ付ける
CanNotDeleteは更新を許しつつ削除を拒否します。ロックは権限を持つ利用者にも適用されるため、運用手順と解除権限を管理します。
リージョン障害時のRTOを15分、RPOを5分と定義した。バックアップだけで要件を満たすか判断するため、何を確認すべきですか？
答え： 復元時間、バックアップ頻度、依存サービス、切替手順を実測する
バックアップの存在だけではRTO/RPOを保証できません。実データ量での復元、ネットワーク・ID・DNSを含む依存関係、手順全体を演習します。
Azure App Serviceの新バージョンを無停止に近い形で公開し、事前検証と即時切り戻しを行いたい。適切な機能はどれですか？
答え： Deployment slotsとswap
別slotへデプロイしてウォームアップと検証を行い、swapで本番へ切り替えます。slot固有設定とDB変更の後方互換性も設計します。
アプリの応答時間悪化について、どの依存APIやDB呼び出しが原因か分散トレースで特定したい。中心となる機能はどれですか？
答え： Application Insightsのトランザクション検索と依存関係テレメトリ
Application Insightsは要求、依存関係、例外、トレースを相関IDで結び、エンドツーエンドの処理経路と遅延箇所を追跡できます。
障害対応中、Azureプラットフォーム側で特定リージョンのサービス劣化が発生しているか、組織のリソースへの影響を確認したい。最初に見るべきものはどれですか？
答え： Azureサービスヘルスとリソースヘルス
サービスヘルスは利用中サービスに関係するAzure事象を示し、リソースヘルスは個別リソースの状態を示します。ワークロード指標と併せて切り分けます。
IaCでランディングゾーンを展開するパイプラインに強い権限が必要だが、固定クライアントシークレットを保管したくない。適切な認証方式はどれですか？
答え： OIDCフェデレーションを使うワークロードアイデンティティFederation
ワークロードアイデンティティFederationはCI/CDのOIDCトークンをEntra IDで信頼し、長期シークレットなしで短期アクセストークンを取得できます。
IaC適用前にAzure Policy違反や危険な変更を検出し、承認後に本番反映したい。適切なパイプラインはどれですか？
答え： lint・validate・what-if/plan・ポリシーチェック・承認・applyを段階化する
静的検査、差分予測、ポリシー評価を先に行い、本番環境では承認と環境保護を使います。適用後はドリフトも監視します。
サブスクリプション発行をセルフサービス化しつつ、ネットワーク、ポリシー、予算、ログ設定を毎回同じ品質で適用したい。適切な仕組みはどれですか？
答え： IaCベースのsubscription vendingを承認済みテンプレートで自動化する
Subscription vendingは申請情報から配置先管理グループ、RBAC、接続、ポリシー、予算、診断設定を再現可能に構成します。
大規模なブランチ拠点とVNetをMicrosoft管理のハブで接続し、ルーティングを簡素化したい。検討すべきサービスはどれですか？
答え： Azure Virtual WAN
Virtual WANはMicrosoft管理の仮想ハブを中心に、ブランチ、VPN、ExpressRoute、VNet間の大規模接続と経路制御を提供します。
VMのOS更新を複数サブスクリプションで可視化し、メンテナンス時間を制御したい。適切なサービスはどれですか？
答え： Azure更新Manager
Azure更新ManagerはAzure VMやAzure Arc対応サーバーの更新評価、スケジュール、適用状況を一元管理できます。
Azureストレージのデータをリージョン障害から守り、セカンダリリージョンから読み取りも行いたい。冗長化オプションはどれですか？
答え： RA-GRSまたはRA-GZRSを要件に合わせて選ぶ
RA-GRS/RA-GZRSは別リージョンへ非同期複製し、セカンダリエンドポイントの読み取りを提供します。RPO、整合性、フェイルオーバー条件を理解して選びます。
業務停止を伴う障害演習を避けつつ、ゾーン障害時の自動復旧が本当に機能するか確認したい。適切な方法はどれですか？
答え： 限定スコープ、停止条件、監視、ロールバックを備えたゲームデーを行う
制御されたゲームデーで仮説、影響範囲、安全停止条件、成功指標を定め、復旧自動化と手順を実環境に近い条件で検証します。
Well-Architectedレビューで、可用性向上のための多重化がコストと運用複雑性を増やすことが分かった。最も適切な判断方法はどれですか？
答え： 事業影響、SLO、RTO/RPO、リスク許容度を基に柱間のトレードオフを記録する
Well-Architectedは全てを最大化するチェックリストではありません。事業要件を基準にReliability、コスト、Operational Excellence等のトレードオフを明示します。
中央のネットワークチームが、多数のVNetに対して高リスクポートの拒否を一律に強制したい。一方で、Subnet単位のNSG運用は各チームに任せたい。適切な機能はどれですか？
答え： Azure VirtualネットワークManagerのセキュリティ管理者Rules
セキュリティ管理者Rulesはネットワークグループ内のVNetへ中央ルールを適用し、NSGより先に評価されます。中央ガードレールとワークロード固有NSGを階層的に組み合わせられます。
オンプレミスからAzureのプライベートDNSゾーンを名前解決したい。逆にAzure側からは社内ドメインへ条件付きフォワードも行いたい。DNS用のVMを減らせる構成はどれですか？
答え： Azure DNS非公開Resolverの受信・アウトバウンドエンドポイントとForwarding Ruleset
非公開Resolverは受信エンドポイントでAzure非公開DNSへのクエリを受け、アウトバウンドエンドポイントとRulesetで指定ドメインを外部DNSへForwardできます。
非公開Subnet上の多数のVMが外向きに接続すると、SNATポートが枯渇しました。固定の送信元IPも必要です。中心となる対策はどれですか？
答え： SubnetへAzure NAT Gatewayを関連付け、必要な公開IP容量を用意する
NAT GatewayはSubnetのアウトバウンド接続へManaged SNATと静的公開IPを提供します。メトリクス、接続再利用、宛先ごとの並行性も確認します。
公開IPを持つ複数VNetのワークロードを大規模DDoSから保護し、攻撃時のコスト保護と専門支援も必要です。適切なのはどれですか？
答え： Azure DDoSネットワークProtectionを対象VNetへ適用し、レスポンスプランを整備する
DDoSネットワークProtectionは公開IPリソースへ適応型なレイヤー3/4緩和、テレメトリ、コスト保護、専門支援を提供します。アプリケーション層はWAFも併用します。
管理ポータルでの特権操作には、フィッシング耐性のあるMFA方式だけを許可したい。中心となる制御はどれですか？
答え： Conditionalアクセスで認証Strengthを要求する
Conditionalアクセスの認証Strengthは、対象ユーザー・アプリ・条件に対して許可する認証方式の組合せを制御します。緊急用除外とReport-only検証も設計します。
Key Vaultの権限管理をAzure RBACに統一します。Key Vault自体を管理する権限と、シークレットを読み取るなどデータを扱う権限を分けたい。適切なのはどれですか？
答え： データPlane用Built-inロールを必要なスコープで割り当て、管理ロールと分離する
Key VaultのAzure RBACではリソース管理とVault内データ操作を別ロールで制御します。シークレットユーザー等の最小ロールを必要スコープへ付与します。
Storage Accountのカスタマーマネージドキーを、Key Vaultでローテーションします。ローテーション後の新しいキーバージョンを、ストレージ側が自動で使うようにしたい。適切なのはどれですか？
答え： Managed Identityへ必要権限を与え、VersionlessキーURIを構成する
Managed Identityにキー権限を与えバージョンを固定しないURIを使うと、ローテーション後の新バージョン取得をサービスが追従できます。更新遅延とロールバックも確認します。
マネージドサービスプロバイダーが、複数の顧客テナントにあるAzureサブスクリプションを運用します。自社テナントから、委任された範囲だけを一元的に操作したい。適切なのはどれですか？
答え： Azure LighthouseでCross-tenant管理を委任する
Azure Lighthouseは顧客がSubscriptionまたはリソースグループスコープをプロバイダーテナントのアイデンティティへ委任し、Cross-tenantで管理できる仕組みです。
AKSのPrometheus形式メトリクスをマネージドな仕組みで収集し、複数クラスターをGrafanaダッシュボードで可視化したい。推奨の組合せはどれですか？
答え： Azure Monitor managed service for PrometheusとAzure Managed Grafana
Managed PrometheusはPrometheus互換メトリクスをAzure Monitorで収集・保存し、Managed Grafanaからクエリ・可視化できます。カーディナリティも管理します。
Azureプラットフォームログを外部SIEMへニアリアルタイム転送しつつ、Log Analyticsにも保持したい。中心設定はどれですか？
答え： Diagnostic SettingsでLog Analytics WorkspaceとイベントHubを送信先にする
Diagnostic SettingsはリソースログやプラットフォームメトリクスをLog Analytics、Event Hubs、ストレージ等へ送信します。カテゴリ、保持、配送失敗も監視します。
Azureサービス障害と計画メンテナンスについて、影響を受けるSubscriptionへ自動通知したい。最も適切なのはどれですか？
答え： サービスヘルスアラートをアクショングループへ接続する
サービスヘルスはSubscriptionに関連するサービス課題、計画メンテナンス、ヘルスAdvisory等を提供します。アラートルールとアクショングループで担当チャネルへ通知します。
AKSの自動アップグレードを業務影響の少ない時間帯へ寄せたい。計画メンテナンスについて正しい設計はどれですか？
答え： 希望時間を定め、アップグレード設定とワークロード耐性も別途設計する
計画メンテナンスはクラスター・ノードイメージアップグレード等の実行時間を制御するBest-effort機能です。Auto-upgrade有効化やPod側の可用性設計とは別です。
AKSのキューコンシューマーをメッセージ数に応じて0 Podからスケールアウトしたい。適切な仕組みはどれですか？
答え： KEDA ScaledObjectでキュートリガーを構成する
KEDAはイベントソースのメトリクスを基にKubernetesワークロードをスケールし、対応Scalerでは0レプリカまで縮退できます。認証、ポーリング、Cooldownも調整します。
Azure Container Appsの新リビジョンへ10%だけトラフィックを送り、メトリクス確認後に段階拡大したい。適切なのはどれですか？
答え： MultipleリビジョンModeでリビジョンWeightを設定する
MultipleリビジョンModeでは複数のActiveリビジョンへPercentageでトラフィックを分割できます。不変イメージ、ヘルスシグナル、ロールバック条件も管理します。
同一注文IDのイベントを送信順に1コンシューマーずつ処理し、異なる注文は並行処理したい。Azure Service Busで適切なのはどれですか？
答え： 注文IDをSessionIdにしたService Busセッション
Service Busセッションは同じSessionIdのメッセージをセッションレシーバが排他的に処理し、関連メッセージの順序と状態を扱えます。セッション間は並行化できます。
送信結果のACK消失により同じ業務メッセージをリトライする可能性がある。一定時間内の重複投入をService Bus側でも抑えたい。適切なのはどれですか？
答え： 重複検出を有効化し、業務から再現可能なMessageIdを使う
重複検出は設定ウィンドウ内に同じMessageIdが再送された場合に重複を破棄します。受信側の副作用も別途冪等にします。
Cosmos DBを複数のリージョンから利用します。同じユーザーセッションの中では自分の直前の書き込みを読めるようにしたい。ただし、強い整合性によるレイテンシの増加は避けたい。適切なのはどれですか？
答え： セッションConsistencyとセッショントークンの継承
セッションConsistencyはセッション内でMonotonic読み取り、Monotonic書き込み、Read-your-writes等を提供します。Stateless層をまたぐ場合はトークンを引き継ぎます。
Cosmos DBで一つのテナントだけトラフィックが多く、単一論理パーティションがホットになって429が集中する。中心となる再設計はどれですか？
答え： 高カーディナリティで負荷分散できる合成または階層型パーティションキーを検討する
パーティションキーはデータとRUの分散単位です。テナント内シャードキー等を組み合わせ、主要クエリを保ちながらホットテナントを複数パーティションへ分散します。
監査ログを規制期間中は管理者でも変更・削除できないWORM状態でストレージへ保持したい。適切なのはどれですか？
答え： 不変BlobストレージのTime-based保持ポリシーをロックする
ロック済みTime-based保持は期間中のBlob変更・削除を防ぐWORM制御です。ロック後の短縮・解除制約を理解し、事前に運用検証します。
Bicepで管理するリソース群を1つの単位として追跡したい。定義から外れたリソースをデタッチするか削除するかの方針と、単位外からの変更拒否も管理したい。適切なのはどれですか？
答え： Azure Deployment StacksでactionOnUnmanageとDeny Settingsを設計する
Deployment Stacksはテンプレート管理リソースをスタックとして追跡し、Unmanage時のデタッチ/削除とDeny Assignmentを設定できます。除外アイデンティティも慎重に設計します。
Azure Cosmos DB for NoSQLで、担当者Aが読んだ注文を編集している間に担当者Bが更新しました。Aが古い内容でBの変更を上書きしないための方法はどれですか？
答え： 取得時のETagをIf-Match条件に指定する
ETagは項目の版を識別します。読み取り時のETagを更新条件に付け、既に変更されていればHTTP 412として検出します。その場合は最新データを再取得して変更内容を見直し、条件を外してそのまま上書きしないようにします。
Cosmos DB for NoSQLで、同じコンテナーの同じ論理パーティションにある注文と明細を、両方成功または両方失敗として更新したい。適切な方法はどれですか？
答え： TransactionalBatchで二つの更新をまとめる
TransactionalBatchは同じ論理パーティション内の操作を原子的に扱います。途中の操作が失敗すればバッチ全体がロールバックされます。異なるパーティションにまたがる更新まで同じ保証になるわけではありません。
Service BusのPeekLockで受信した決済依頼を処理し、DBへの記録は成功しましたが、Completeに失敗して同じ依頼が再配信されました。二重決済を防ぐ中心的な対策はどれですか？
答え： 業務IDで処理済み判定と決済の確定を連動させる
PeekLockは再配信され得るため、受信処理を冪等にします。処理済み記録と業務更新を同じトランザクションに含めるなど、記録だけ・決済だけが確定する隙間を防ぎます。外部決済なら決済先の冪等キーも利用します。
Event Gridのイベントで注文状態を更新しています。『発送済み』の後に古い『梱包中』が届いたり、同じイベントが再び届いたりしました。適切な受信側設計はどれですか？
答え： イベントIDと業務の版で重複と状態の逆行を防ぐ
Event Gridは配信順序を保証せず、重複配信も起こり得ます。イベントIDで重複を識別し、発行側が付けた業務上の版や状態遷移規則で古い更新を判定します。受信時刻の新しさを業務状態の新しさと混同しないことが重要です。
App ServiceへPrivate Endpointを追加しました。社内からの接続は成功していますが、公開ネットワークアクセスは有効のままです。外部からの公開経路を閉じるには何を行いますか？
答え： アプリの公開ネットワークアクセスを無効にする
Private Endpointの作成と公開アクセスの停止は別の設定です。プライベート経路の疎通を確認したうえで公開ネットワークアクセスを無効化し、必要な運用経路も含めて検証します。
Azure VMへのSSH許可をNSGで削除しました。新しい接続は拒否されますが、変更前からのSSH接続は続いています。この状況の説明として適切なのはどれですか？
答え： NSGの規則変更は、既に確立した接続を切らない
NSGは状態を保持するフィルターです。変更後の規則は新しい接続に適用されますが、既存フローは継続し得ます。緊急に既存接続も終了させる場合は、ホストやアプリ側での切断・隔離手順も必要です。
多数のインスタンスがHTTP要求のたびに同じシークレットをKey Vaultから読み、429が増えています。ローテーションへの追従も維持する改善はどれですか？
答え： メモリキャッシュと更新方針、待機付き再試行を使う
毎要求での取得を避け、メモリ上のキャッシュを再利用します。秘密情報の更新・失効に対応する再取得条件を決め、429ではバックオフします。キャッシュは無期限の固定化やログへの出力とは異なります。
Azure SQL Databaseのフェールオーバーグループで、プライマリのリージョンが停止しました。未複製データの有無を確認できないまま強制フェールオーバーする場合、適切な判断はどれですか？
答え： 未複製データを失う可能性を承認して切り替える
非同期のリージョン間複製では、成功応答済みでもセカンダリへ届いていない書き込みがあり得ます。強制切替はデータ損失の可能性を伴うため、RTOとRPO、承認権限、復旧後の取引照合を含めて判断します。
ARMテンプレートを増分モードで再デプロイします。既存リソースの定義に一部のプロパティだけ残し、『省略した設定は維持される』と考えています。適切なレビュー指摘はどれですか？
答え： 必要な最終状態を定義し、省略項目の扱いも確認する
増分モードは、テンプレートにないリソースを残すことと、記載したリソースの一部だけを更新することを同じ意味にはしません。再デプロイするリソースではプロパティが再適用され、省略値が既定値へ戻る場合があります。リソース種別の仕様と差分を確認します。
Blobに有効なリースがあり、更新要求を送ったアプリには書き込み権限もあります。しかしリースIDを付けずに書き込むと412になりました。適切な対応はどれですか？
答え： 有効なリースIDを条件に付け、所有を確認して更新する
書き込み権限とリースによる排他制御は別です。有効なリースがあるBlobの書き込みには、そのリースIDを条件として指定します。他の処理が保持するリースを安易に解除せず、所有権や期限切れも扱う設計にします。