Practice Free DP-800 Exam Online Questions

Explanation:

The first statement is Yes. The query filters on CustomerId, applies a range predicate on OrderDate, and sorts by OrderDate DESC. Microsoft’s index design guidance recommends putting equality predicates first in the key, followed by columns used for ordering/range access, because the order of key columns determines seek and sort support. A nonclustered index on (CustomerId, OrderDate DESC) can support an ordered seek for this query and avoid the explicit sort. Including Status and TotalAmount helps cover the query, and OrderId is already available because the clustered key is stored with nonclustered index rows.

The second statement is No. Adding CustomerId as an included column to IX_Orders_OrderDate does not make it part of the index’s navigational structure. Microsoft states that included columns are nonkey columns used to cover queries; they do not provide the seek and ordering characteristics that key columns do. So an index keyed only on OrderDate still is not the right ordered access path for WHERE CustomerId = @CustomerId … ORDER BY OrderDate DESC.

The third statement is Yes. The described actual plan shows an index seek on the wrong access path for the workload, followed by clustered key lookups and an explicit sort before TOP (50). That is characteristic of a suboptimal query/index plan. Query Store and Query Performance Insight are designed to surface plan-related performance regressions, while locking/blocking problems are typically identified through waits/DMVs and blocking-session indicators, not from a plan shape like seek + lookup + sort alone.

Explanation:

Unit tests run automatically whenever changes are pushed to main. → Yes

Schema validation occurs during the Build step. → Yes

Schema validation occurs during the Deploy step. → No

The first statement is Yes. The workflow is configured to trigger on both push to main and pull_request targeting main. The unit-tests job has this condition:

if: github.ref == ‘refs/heads/main’

On a push to main, GitHub sets github.ref to refs/heads/main, so the condition is true and the unit-tests job runs. GitHub’s workflow syntax documentation confirms that push.branches: [main] triggers on pushes to main, and the github.ref value for branch pushes is the fully qualified ref such as refs/heads/main.

The second statement is Yes. The Build step runs:

dotnet build db1.sqlproj –configuration Release

For an SDK-style SQL database project, the build process produces a .dacpac and validates the database project model as part of compilation/build. Microsoft’s SQL database project documentation describes SDK-style SQL projects as the project format used for SQL Database Projects, and Microsoft’s command-line build documentation is specifically about building a .dacpac from that SQL project. That means schema-level project validation happens during build.

The third statement is No.

The Deploy step uses:

SqlPackage /Action:Publish …

Microsoft documents that SqlPackage Publish incrementally updates the target database schema to match the source .dacpac. That is a deployment operation, not the primary schema-validation stage of the SQL project source itself. In this workflow, the schema is validated when the SQL project is built into the .dacpac; the deploy step applies that built artifact to the target database.

Explanation:

For authentication, the correct choice is Enable a managed identity and use Microsoft Entra authentication. Azure App Service supports managed identity, and Microsoft documents this as the recommended way to connect to Azure SQL Database without passwords or secrets. This minimizes administrative effort because there are no SQL passwords to rotate, store, or manage.

For network access, the correct choice is Create a private endpoint and disable public network access. Microsoft documents that when public network access is disabled, Azure SQL Database only accepts connections through private endpoints. That keeps the database traffic on Azure private networking rather than exposing it through the public endpoint. Microsoft also notes that simply adding a private endpoint does not disable public access by itself, so disabling public network access is part of the correct configuration.

The other options are weaker:

Rotated SQL credentials or storing SQL logins in Key Vault still use passwords and create more admin overhead.

Allowing Azure services, adding outbound IP firewall rules, or database firewall rules still rely on the public endpoint, so they do not best satisfy the requirement that database traffic remain within the subscription.

Explanation:

The correct function is VECTOR_SEARCH because the requirement is to perform approximate nearest neighbor (ANN) queries. Microsoft’s SQL documentation states that VECTOR_SEARCH is the function used for vector similarity search, and that an ANN index is used only with VECTOR_SEARCH when a compatible vector index exists on the target column. By contrast, VECTOR_DISTANCE calculates an exact distance and does not use a vector index for ANN retrieval.

The correct distance metric is cosine distance. Microsoft documents that VECTOR_SEARCH supports cosine, dot, and euclidean metrics, and Microsoft guidance specifically notes that cosine similarity is commonly used for text embeddings. It also states that retrieval of the most similar texts to a given text typically functions better with cosine similarity, and that Azure OpenAI embeddings rely on cosine similarity to compute similarity between a query and documents. Since both NotesEmbeddings and DescriptionEmbeddings are text-derived embeddings and the goal is to minimize the impact of different chunk sizes, cosine is the best choice because it compares direction/angle rather than being as sensitive to vector magnitude as Euclidean distance.