Q1.Microsoft Fabric の SQL データベースに、dbo.Products という名前のテーブルを含む SQL データベースがあります。
dbo.Products には製品カタログ データが含まれています。
ハイブリッド検索を実行するストアド プロシージャを作成する必要があります。
ソリューションは次の要件を満たす必要があります。
近似最近傍 (ANN) を使用して上位 20 件の候補製品を取得します。
フルテキスト クエリにも一致する候補のみを再ランク付けします。
クエリ埋め込みを生成します。
Transact-SQL コードをどのように完成させるべきですか。
回答
- (下記画像参照)
-
クエリ文字列からベクトルを作るため、最初の空欄は AI_GENERATE_EMBEDDINGS です。
近似最近傍で上位 20 件を取得する表値関数は VECTOR_SEARCH で、TABLE、COLUMN、SIMILAR_TO、TOP_N、METRIC の指定に合います。
最後はフルテキスト条件に一致した行だけを RANK 付きで結合するため CONTAINSTABLE を使用します。
なお最新ドキュメントでは新しいベクター インデックス向けに TOP (N) WITH APPROXIMATE 構文も案内されていますが、この設問のコードでは TOP_N を埋める形式です。
VECTOR_SEARCH (Transact-SQL) (プレビュー)
Q2.sales-sql01 という名前の論理サーバー上に SalesDB という名前の Azure SQL データベースがあります。
OrderApi という名前の Azure App Service Web アプリがあり、SQL 認証を使用して SalesDB に接続しています。
OrderApi に対して OrderApi-Id という名前のユーザー割り当てマネージド ID を有効にします。
Microsoft Entra 認証を使用して SalesDB に接続するように OrderApi を構成する必要があります。
マネージド ID には SalesDB に対する読み取りおよび書き込みアクセス許可が必要です。
SalesDB でどの Transact-SQL ステートメントを実行する必要がありますか。
A. CREATE LOGIN [OrderApi-Id] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [OrderApi-Id]; ALTER ROLE db_datawriter ADD MEMBER [OrderApi-Id];
B. CREATE USER [OrderApi-Id] WITH PASSWORD = ‘P@ssw0rd!’; ALTER ROLE db_datareader ADD MEMBER [OrderApi-Id]; ALTER ROLE db_datawriter ADD MEMBER [OrderApi-Id];
C. CREATE USER [OrderApi-Id] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [OrderApi-Id]; ALTER ROLE db_datawriter ADD MEMBER [OrderApi-Id];
D. CREATE LOGIN [OrderApi-Id] WITH PASSWORD = ‘P@ssw0rd!’; ALTER SERVER ROLE sysadmin ADD MEMBER [OrderApi-Id];
回答
- C. CREATE USER [OrderApi-Id] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [OrderApi-Id]; ALTER ROLE db_datawriter ADD MEMBER [OrderApi-Id];
-
Microsoft Entra 認証で Azure SQL Database に接続するマネージド ID は、対象データベース内で CREATE USER FROM EXTERNAL PROVIDER によりユーザーとして作成します。
必要な権限は読み取りと書き込みなので、db_datareader と db_datawriter に追加します。
CREATE LOGIN は論理サーバーのログイン作成であり、この要件の SalesDB 内の権限付与 には適しません。
マネージド ID を使用して .NET アプリを Azure SQL Database に安全に接続する – Azure App Service | Microsoft Learn
Q3.app1-contoso-001 という名前の Azure コンテナー アプリがあり、Azure SQL データベースの前段で Data API builder (DAB) コンテナーをホストしています。
dbo.todos という名前のソースを使用する Todo という名前のエンティティを追加します。
クライアントは Todo REST エンドポイントにアクセスするために、どの URL パターンを使用する必要がありますか。
A. https://app1-contoso-001.azurestaticapps.net/data-api/graphql/Todo
B. https://app1-contoso-001.azurestaticapps.net/api/Todo
C. https://app1-contoso-001.azurestaticapps.net/data-api/Todo
D. https://app1-contoso-001.azurestaticapps.net/data-api/api/Todo
回答
- B. https://app1-contoso-001.azurestaticapps.net/api/Todo
-
Data API builder では、各データベース オブジェクトを構成ファイルのエンティティとして公開し、既定の REST エンドポイントは /api/{entity} です。
今回のエンティティ名は Todo であり、カスタムの REST パスは示されていないため、クライアントは /api/Todo を使用します。
/graphql は GraphQL 用であり、/data-api はこの設問の DAB 既定の REST パス ではありません。
REST エンドポイントを呼び出す方法 – Data API builder
Q4.db1 という名前のデータベースがあります。
スキーマは、SDK スタイルの SQL データベース プロジェクトとして Git リポジトリに保存されています。
リポジトリには次の GitHub Actions ワークフローが含まれています。
次の各ステートメントについて、ステートメントが正しい場合は [はい] を選択します。
それ以外の場合は [いいえ] を選択します。
回答
- (下記画像参照)
-
unit-tests ジョブには github.ref == ‘refs/heads/main’ の条件があるため、main への push では build-and-deploy 後に実行されます。
SQL データベース プロジェクトのビルドは、オブジェクト間の関係と対象プラットフォームの構文を検証して .dacpac を生成します。
一方、Deploy ステップは SqlPackage Publish により成果物を配置する処理であり、設問上のスキーマ検証は Build ステップ と判断します。
SQL プロジェクトを作成して配置する – SQL Server | Microsoft Learn
Q5.DB1 という名前のデータベースがあります。
スキーマは SDK スタイルの SQL データベース プロジェクトとして Git リポジトリに保存されています。
dotnet build を既に実行し、データベース成果物を生成する GitHub Actions ワークフローがあります。
GitHub リポジトリ シークレットに保存されているシークレットを使用して、.dacpac ファイルを Azure SQL データベースに発行するデプロイ手順を追加する必要があります。
ワークフローに何を含める必要がありますか。
A. env: SQL_CONNECTION_STRING: Server=tcp:myserver.database.windows.net; … steps: – name: Publish uses: azure/sql-action@v2 with: action: publish path: bin/Debug/db1.dacpac connection-string: ${{ env.SQL_CONNECTION_STRING }}
B. – name: Publish uses: azure/sql-action@v2 with: action: extract path: bin/Debug/db1.dacpac connection-string: ${{ secrets.SQL_CONNECTION_STRING }}
C. – name: Publish uses: azure/sql-action@v2 with: action: publish path: bin/Debug/db1.dacpac connection-string: ${{ secrets.SQL_CONNECTION_STRING }}
D. – name: Publish run: | dotnet build db1.sqlproj \ /p:TargetConnectionString=”${{ secrets.SQL_CONNECTION_STRING }}”
回答
- C. – name: Publish uses: azure/sql-action@v2 with: action: publish path: bin/Debug/db1.dacpac connection-string: ${{ secrets.SQL_CONNECTION_STRING }}
-
.dacpac を Azure SQL Database に発行するには、GitHub Actions の azure/sql-action@v2 を使用し、with に path と connection-string を指定します。
発行処理なので action は extract ではなく publish です。
また接続情報は設問どおり GitHub リポジトリ シークレットから参照するため、secrets.SQL_CONNECTION_STRING を使う C が適切です。
A は env に直接接続文字列を置き、D はビルドであり発行ではありません。
SQL Projects Automation – SQL Server | Microsoft Learn
Q6.Git リポジトリに保存された SDK スタイルの SQL データベース プロジェクトがあります。
このプロジェクトは Azure SQL データベースを対象としています。
プロジェクトがシステム オブジェクトを参照すると、CI ビルドは未解決の参照エラーで失敗します。
Azure SQL Database の正しいシステム オブジェクトをデータベース モデルに含めることで、dotnet build が正常に検証されるように SQL データベース プロジェクトを更新する必要があります。
ソリューション: Azure SQL Database の master.dacpac ファイルへの成果物参照を追加します。
これは目標を満たしますか。
A. はい
B. いいえ
回答
- B. いいえ
-
SDK スタイルの SQL プロジェクトで Azure SQL Database のシステム オブジェクトを安定して解決するには、通常 Microsoft.SqlServer.Dacpacs.Azure.Master を PackageReference として追加します。
成果物参照はローカルに存在する ビルド エージェント上の master.dacpac に依存し、CI 環境で同じパスに存在しないと dotnet build の検証に失敗する可能性があります。
そのため、このソリューションだけでは目標を満たしません。
SQL プロジェクトのシステム オブジェクト – SQL Server | Microsoft Learn
Q7.ProductsDB という名前の Azure SQL データベースがあります。
mcr.microsoft.com/azure-databases/data-api-builder:latest イメージを使用して、Data API builder (DAB) を Azure Container Apps にデプロイします。
コンテナー アプリには次の構成があります。
シークレット: mssql-connection-string、dab-config-base64。
環境変数: MSSQL_CONNECTION_STRING=secretref:mssql-connection-string、DAB_CONFIG_BASE64=secretref:dab-config-base64。
イングレス: ポート 5000 で外部。
ユーザーから、/health エンドポイントは正常な応答を返すが、Products という名前のエンティティをクエリするすべての要求が失敗し、接続エラーが生成されると報告されています。
接続文字列内の SQL ログインが正しく、データベースが存在することを確認しました。
コンテナー アプリのデプロイ設定または DAB 構成ファイルを変更せずに、コンテナー アプリが Azure SQL 論理サーバーへの接続を確立できるようにする必要があります。
Azure SQL 論理サーバーで何を行う必要がありますか。
A. ProductsDB の自動フェールオーバー グループを作成する
B. ProductsDB で DBCC CHECKDB を実行する
C. 開始 IP アドレスと終了 IP アドレスとして 0.0.0.0 を許可するファイアウォール規則を作成する
D. ProductsDB の FORCE_LAST_GOOD_PLAN 自動チューニングを有効にする
回答
- C. 開始 IP アドレスと終了 IP アドレスとして 0.0.0.0 を許可するファイアウォール規則を作成する
-
/health が正常でも、エンティティ照会だけが接続エラーになる場合、DAB コンテナーから Azure SQL へのネットワーク到達性を確認します。
Azure 内のアプリから Azure SQL Database に接続させるには、論理サーバーで 0.0.0.0 から 0.0.0.0 のファイアウォール規則を作成し、Azure サービスからの接続を許可します。
これは コンテナー設定や DAB 構成を変更しない 対応です。
自動フェールオーバー、DBCC、自動チューニングは 接続許可の問題 を解決しません。
IP ファイアウォール規則 – Azure SQL Database and Azure Synapse Analytics | Microsoft Learn
Q8.Sales.Orders という名前のテーブルを含む Azure SQL データベースがあります。
Sales.Orders には次の列が含まれています。
レポート クエリでは、注文が行われてからの日数を計算するロジックが頻繁に繰り返されています。
@OrderDate の入力値と現在の日付と時刻の間の日数を返すスカラー ユーザー定義関数 (UDF) を作成する必要があります。
Transact-SQL コードをどのように完成させるべきですか。
回答するには、適切な値を正しいターゲットにドラッグしてください。
各値は 1 回、複数回、またはまったく使用しない場合があります。
回答
- (下記画像参照)
-
スカラー UDF は単一値を返すため、関数宣言では RETURNS INT を指定します。
注文日から現在日時までの日数を求めるには、日付を加算する DATEADD ではなく、差分を返す DATEDIFF(day, @OrderDate, GETDATE()) が適切です。
DATEDIFF の戻り値は int なので、DECLARE した @Days に代入して RETURN する構成に合います。
RETURNS TABLE はテーブル値関数用です。
DATEDIFF(Transact-SQL年) – SQL Server
Q9.SQL と LLM を統合する一般的なパターンは何ですか。
A. LLM 内で SQL を直接実行する
B. RAG パイプライン
C. 手動で CSV をエクスポートする
D. バックアップを復元する
回答
- B. RAG パイプライン
-
SQL のデータを LLM と統合する一般的な方法は、データベースなどから関連情報を取得し、その結果をプロンプトに含めて回答を生成する RAG パイプライン です。
LLM が直接 SQL を実行する構成は安全性や制御の面で一般的ではありません。
RAG では検索・取得した根拠データを使うため、回答の正確性と最新性 を高められます。
手動 CSV エクスポートやバックアップ復元は LLM 統合パターン ではありません。
RAG および生成 AI – Azure AI Search | Microsoft Learn
Q10.dbo.ToDo という名前のテーブルを含む ToDo という名前の Azure SQL データベースがあります。
会社は、dbo.ToDo の行が変更されるたびに実行される Azure Functions アプリを開発する予定です。
このアプリは、Azure SQL トリガー バインドを使用して INSERT、UPDATE、DELETE イベントを処理します。
計画されたアプリをサポートするように ToDo を構成する必要があります。
何を行う必要がありますか。
A. ToDo および dbo.ToDo で変更追跡を有効にする
B. dbo.ToDo で、Azure Functions HTTP エンドポイントを呼び出すデータ操作言語 (DML) トリガーを作成する
C. ToDo および dbo.ToDo で変更データ キャプチャ (CDC) を有効にする
D. dbo.ToDo で、Azure Functions HTTP エンドポイントを呼び出すデータ定義言語 (DDL) トリガーを作成する
回答
- A. ToDo および dbo.ToDo で変更追跡を有効にする
-
Azure Functions の Azure SQL トリガーは、SQL テーブルの INSERT、UPDATE、DELETE を監視するために SQL 変更追跡 を使用します。
そのため、対象データベース ToDo と対象テーブル dbo.ToDo の両方で変更追跡を有効にする必要があります。
CDC や DML/DDL トリガーから HTTP エンドポイントを呼び出す方式は、Azure SQL トリガー バインドの前提構成ではありません。
試験では Azure SQL トリガーは変更追跡を使う と覚えるのが重要です。
Functions の Azure SQL トリガー
