Browse Certification Practice Tests by Exam Family

AI-200: Develop AI Solutions by Using Azure Data Management Services

Try 10 focused AI-200 questions on Develop AI Solutions by Using Azure Data Management Services, with explanations, then continue with IT Mastery.

Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.

Try AI-200 on Web View full AI-200 practice page

Topic snapshot

FieldDetail
Exam routeAI-200
Topic areaDevelop AI Solutions by Using Azure Data Management Services
Blueprint weight29%
Page purposeFocused sample questions before returning to mixed practice

How to use this topic drill

Use this page to isolate Develop AI Solutions by Using Azure Data Management Services for AI-200. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.

PassWhat to doWhat to record
First attemptAnswer without checking the explanation first.The fact, rule, calculation, or judgment point that controlled your answer.
ReviewRead the explanation even when you were correct.Why the best answer is stronger than the closest distractor.
RepairRepeat only missed or uncertain items after a short break.The pattern behind misses, not the answer letter.
TransferReturn to mixed practice once the topic feels stable.Whether the same skill holds up when the topic is no longer obvious.

Blueprint context: 29% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Develop AI Solutions by Using Azure Data Management Services

An AI search API runs in Azure Container Apps and queries Azure Database for PostgreSQL for vector similarity search. During traffic spikes, users see intermittent 503 responses. The requirement is to keep search available for all tenants without disabling vector retrieval.

EvidenceObservation
CPU38% peak
Memory54% peak
Storage latencyNormal; IOPS below limit
PostgreSQL connections940/1,000; many short-lived
Query planUses the vector index

Which next change should the team make?

Options:

  • A. Scale PostgreSQL to a larger vCore tier.

  • B. Configure connection pooling for PostgreSQL access.

  • C. Increase provisioned storage IOPS.

  • D. Increase PostgreSQL memory allocation.

Best answer: B

Explanation: The performance evidence indicates an application access problem, not a compute, memory, or storage bottleneck. CPU and memory have headroom, storage latency is normal, and the vector index is being used. The risky condition is the high number of short-lived PostgreSQL connections approaching the connection limit. Connection pooling and client reuse reduce connection churn while preserving tenant access to vector search. Scaling compute, memory, or storage would add capacity in areas that are not currently constrained.

  • More vCores misses the main signal because CPU usage is low during the incident.
  • More memory is not supported because memory pressure or cache eviction is not shown.
  • More storage IOPS does not address the issue because storage latency and IOPS headroom are normal.

Question 2

Topic: Develop AI Solutions by Using Azure Data Management Services

A Python RAG API uses Azure Database for PostgreSQL to store document embeddings and metadata. Users report that generated answers sometimes include claims not present in the approved documents.

Trace excerpt:

embed(question) -> ok
postgres.semantic_match(filter tenant='contoso') -> 3 rows
row snippets: "Retention is 90 days", "Archive after 90 days"
build_context -> 3 snippets added
chat_completion -> "Retention is 180 days..."

What is the best next diagnostic step?

Options:

  • A. Change the tenant metadata filter

  • B. Inspect the answer-generation prompt and model call

  • C. Increase PostgreSQL connection pool size

  • D. Rebuild the PostgreSQL vector index

Best answer: B

Explanation: In this RAG flow, Azure Database for PostgreSQL is acting as the vector store: it stores embeddings and metadata, runs semantic similarity search, and returns matching source snippets. The trace shows PostgreSQL returned snippets that say “90 days,” while the final unsupported “180 days” claim appears only after the chat completion step. That points the diagnostic effort toward prompt construction, context injection, grounding instructions, or the model response handling path, not the PostgreSQL retrieval layer. PostgreSQL can affect which chunks are retrieved, but it does not generate the natural-language answer in this architecture.

  • Vector index tuning would address retrieval quality or latency, but the returned snippets already contradict the bad answer.
  • Connection pooling relates to throughput or connection failures, not unsupported generated content.
  • Tenant filtering would be suspect if wrong-tenant rows appeared, but the trace shows the intended tenant filter was applied.

Question 3

Topic: Develop AI Solutions by Using Azure Data Management Services

A team is building a RAG API with Azure Cosmos DB for NoSQL vector similarity search. Documents are already chunked and embedded. The API must retrieve relevant passages, show the source title and URL, and filter by tenant and document version during retrieval. What should the team implement next?

Options:

  • A. Create one item per chunk with text, embedding, and metadata fields.

  • B. Add more compute before defining the container item shape.

  • C. Store one item per full document with a single embedding.

  • D. Store only embeddings in Cosmos DB and text in separate blobs.

Best answer: A

Explanation: For a RAG pattern, the retrievable unit should normally be the content chunk, not the whole document or a vector alone. In Cosmos DB for NoSQL, each item can carry the chunk text, the embedding vector, and retrieval metadata such as tenant, document ID, version, source URL, title, and chunk order. This lets vector similarity search return the passage needed for grounding while ordinary properties remain available for filtering and citation. Keeping the vector separate from the source text or metadata adds extra lookups and can make authorization or version filtering harder to apply consistently. The key design step is to model the item shape before tuning indexes or scaling resources.

  • Embedding-only storage fails because the RAG response still needs passage text and citation metadata at retrieval time.
  • Full-document items reduce retrieval precision because similarity search returns an entire document instead of the relevant chunk.
  • More compute first is premature because resource scaling does not fix an unusable retrieval data shape.

Question 4

Topic: Develop AI Solutions by Using Azure Data Management Services

A Python RAG API stores chat memory in Azure Cosmos DB for NoSQL. Each memory is a JSON item with id, tenantId, sessionId, text, and embedding; the container partition key is /tenantId. The API must write new or updated memories and later fetch a known memory by tenantId and id without cross-partition scans. Which TWO SDK access patterns should you implement? Select TWO.

Options:

  • A. Create one container for each chat session

  • B. Query by id across all partitions

  • C. Append all tenant memories to one document

  • D. Use read_item with both id and tenantId

  • E. Instantiate CosmosClient for each SDK call

  • F. Use upsert_item with tenantId set on each item

Correct answers: D and F

Explanation: Cosmos DB for NoSQL SDK access should align writes and reads to item identity and the partition key. In this workload, each AI memory is a JSON item in a container partitioned by tenantId. The service can create or replace records with an upsert operation and include the partition key value in the item. When retrieval already has tenantId and id, a point read is the most efficient known-item access pattern because it targets the logical partition directly. Queries are useful for discovery, filters, or vector retrieval, but they are not the best pattern for fetching a known item.

  • Querying by id only wastes RUs and can be ambiguous because item identity is partition-aware.
  • Session-level containers add management overhead instead of using items in a partitioned container.
  • One large tenant document risks hot or oversized records and weakens item-level updates.
  • Per-call client creation adds connection overhead rather than reusing SDK client instances.

Question 5

Topic: Develop AI Solutions by Using Azure Data Management Services

A containerized Python API uses the Azure Cosmos DB for NoSQL SDK to fetch RAG chunks. The request fails before the SQL query reaches the container. Which configuration change fixes the missing link?

Trace:

GET /chunks?tenantId=contoso
App settings:
  COSMOS_ACCOUNT=rag-prod
  COSMOS_DATABASE=ragdb
  COSMOS_CONTAINER=chunks
  COSMOS_KEY=<from Key Vault>

Code path:
  CosmosClient(COSMOS_ACCOUNT, credential=COSMOS_KEY)
  get_database_client(COSMOS_DATABASE)
  get_container_client(COSMOS_CONTAINER)
  query_items: SELECT * FROM c WHERE c.tenantId = @tenantId
Failure:
  account URL is not a valid Cosmos DB endpoint URI

Options:

  • A. Append the database and container names to the endpoint.

  • B. Use the tenant partition key value as the credential.

  • C. Enable change feed processing before running the query.

  • D. Configure the account endpoint URI with the key credential.

Best answer: D

Explanation: Azure Cosmos DB for NoSQL SDK clients are created at the account scope. The client needs a valid account endpoint URI, such as https://rag-prod.documents.azure.com:443/, and an authentication credential such as an account key or token credential. The database ID and container ID are then used to get the target container client. In the trace, the app passes only rag-prod as the account URL, so the SDK cannot build a valid request path to the account. After the client is initialized with the endpoint and credential, the query can target ragdb and chunks. The failure is in connection configuration, not the SQL query body.

  • Appending database and container names fails because the SDK endpoint is the account URI; database and container IDs are selected separately.
  • Using a partition key as a credential fails because partition keys route data but do not authenticate requests.
  • Enabling change feed processing is unrelated to an SDK SQL query executed against a container.

Question 6

Topic: Develop AI Solutions by Using Azure Data Management Services

An AI service stores embedding metadata in Azure Database for PostgreSQL. A Python ingestion worker and a .NET API both need to run parameterized SQL and vector queries from server-side code. The team wants supported application client patterns, not management-plane APIs or browser access. Which TWO choices should the team use? Select TWO.

Options:

  • A. Use the Azure Resource Manager SDK to submit SQL queries.

  • B. Use Npgsql with parameterized commands and pooling.

  • C. Use SecretClient to execute SQL after loading secrets.

  • D. Let browser clients connect directly to the PostgreSQL endpoint.

  • E. Use psycopg or asyncpg with a reused connection pool.

  • F. Use the Cosmos DB for NoSQL SDK against PostgreSQL tables.

Correct answers: B and E

Explanation: Azure Database for PostgreSQL is accessed by application code through PostgreSQL-compatible client libraries for the application language. For a Python worker, libraries such as psycopg or asyncpg are appropriate. For a .NET API, Npgsql is the common PostgreSQL client. Production back ends should use parameterized SQL and connection pooling instead of opening unmanaged one-off connections for every operation. Azure management SDKs are for provisioning or configuring resources, while Key Vault can store secrets but does not replace a PostgreSQL data client. The key distinction is data-plane query access through a PostgreSQL driver versus management or secret-retrieval APIs.

  • Management SDK trap fails because Azure Resource Manager APIs manage the server resource; they do not execute application SQL queries.
  • Secret retrieval trap fails because SecretClient can fetch credentials, but a PostgreSQL driver still performs the query.
  • Browser access trap fails because the requirement is server-side application access, not exposing the database to clients.
  • Wrong data SDK fails because the Cosmos DB SDK targets Cosmos DB APIs, not PostgreSQL tables.

Question 7

Topic: Develop AI Solutions by Using Azure Data Management Services

An AI service stores embeddings and metadata in Azure Database for PostgreSQL for vector similarity search. Search latency increased after the corpus grew. The team must remediate capacity by using observed server signals and supported configuration choices, not guessed vector-count limits or pricing assumptions. Select TWO.

Exhibit: Server signals

SignalObservation
CPU and memorySustained high usage during search
Temporary filesSpikes during vector queries
Storage and I/OStorage nearing allocation; read I/O saturated

Options:

  • A. Move embeddings to Azure Managed Redis as the durable source.

  • B. Increase storage capacity and supported provisioned I/O.

  • C. Scale to a compute size with more vCores and memory.

  • D. Disable vector indexes and rely on sequential scans.

  • E. Downgrade to burstable compute and add application retries.

  • F. Set a fixed maximum vector count from community benchmarks.

Correct answers: B and C

Explanation: Capacity remediation for PostgreSQL vector workloads should follow observed bottlenecks and supported Azure Database for PostgreSQL configuration controls. High sustained CPU and memory pressure, plus temporary-file spikes, indicate the workload may need more compute and memory for vector queries, joins, sorting, or concurrent searches. Storage nearing allocation and saturated read I/O indicate the server also needs more storage headroom and I/O capacity where the selected storage configuration supports it. The key is to scale documented capacity dimensions and then validate with workload testing, rather than relying on unofficial vector-count thresholds or assumed pricing behavior.

  • Unofficial limits fail because community benchmarks do not establish a supported Azure service capacity limit for the workload.
  • Redis as source fails because it changes the durable data design instead of remediating the PostgreSQL capacity signals.
  • Burstable downgrade fails because sustained high CPU and memory usage calls for more capacity, not less.
  • Sequential scans fail because removing vector indexes is likely to worsen similarity-search latency as the corpus grows.

Question 8

Topic: Develop AI Solutions by Using Azure Data Management Services

A RAG API stores 1,536-dimension embeddings in Azure Database for PostgreSQL. After loading a larger corpus, p95 vector-search latency rose sharply. Metrics during vector queries and index maintenance show sustained CPU and memory pressure, and the next index rebuild needs more free storage than remains. Connection counts and lock waits are normal; no pricing target or service-limit error is provided. What should you do next?

Options:

  • A. Increase the application connection pool size for more parallel searches.

  • B. Replace PostgreSQL with Azure Managed Redis for durable vector storage.

  • C. Scale PostgreSQL compute, memory, and storage, then rerun the workload test.

  • D. Reduce embedding dimensions and rebuild the corpus immediately.

Best answer: C

Explanation: Vector search and vector index maintenance in Azure Database for PostgreSQL can be constrained by compute, memory, and storage capacity. The stem provides direct capacity evidence: sustained CPU and memory pressure, plus insufficient free storage for the next index rebuild. Because connection counts and lock waits are normal, the next remediation should target the database resources rather than application concurrency. After scaling, rerun the same workload test to confirm that latency and index maintenance improve without assuming a hidden service limit or price constraint. Changing embedding shape or replacing the data store would be a larger design change before addressing the measured capacity problem.

  • Connection pool expansion can worsen CPU and memory saturation when the database is already resource constrained.
  • Redis replacement solves a different problem; Azure Managed Redis is commonly used for caching, not as the durable PostgreSQL source of truth.
  • Embedding reduction changes retrieval behavior and data design before validating the measured capacity remediation.

Question 9

Topic: Develop AI Solutions by Using Azure Data Management Services

A containerized RAG API uses Azure Database for PostgreSQL to retrieve chunks for prompts. A request is authorized for tenant T-17, document type runbook, scope support_reader, and content published after 2025-01-01.

Trace excerpt:

SELECT chunk_id, content
FROM doc_chunks
WHERE tenant_id = @tenant_id
ORDER BY embedding <=> @query_embedding
LIMIT 5;

The top result is from tenant T-17 but has doc_type = 'pricing', required_scope = 'finance_reader', and published_at = '2024-08-10'. Which failure point does the trace show?

Options:

  • A. The vector query omits required metadata predicates.

  • B. The tenant predicate should run after LIMIT.

  • C. The embedding model generated tenant-specific vectors incorrectly.

  • D. The prompt should discard unauthorized chunks later.

Best answer: A

Explanation: PostgreSQL vector retrieval should constrain the candidate set with exact metadata filters before ranking by vector similarity. In this request, the visible SQL applies only tenant_id, so the database is free to rank any same-tenant chunk, including stale content, the wrong document type, or content requiring a different permission scope. The retrieval query should include predicates such as doc_type = @doc_type, published_at >= @min_published_at, and required_scope = ANY(@allowed_scopes) in the WHERE clause along with the tenant filter. The key takeaway is that semantic similarity ranks eligible rows; it should not decide authorization or business-context eligibility.

  • Post-limit filtering fails because unauthorized or irrelevant rows may already be selected into the top results.
  • Tenant-specific vectors are not the issue; the returned row matches the tenant but violates other metadata constraints.
  • Prompt rejection fails because prompts are not a security or retrieval constraint boundary.

Question 10

Topic: Develop AI Solutions by Using Azure Data Management Services

A containerized Python support API stores help articles in Azure Cosmos DB for NoSQL. Each article already has an embedding vector. The product team wants a user query such as “stop my subscription” to retrieve semantically related articles like “cancel your plan,” even when keywords do not match. Which implementation should you use?

Options:

  • A. Match the query text to stored embedding values exactly.

  • B. Embed the query and run Cosmos DB vector similarity search.

  • C. Run CONTAINS filters against article title and body fields.

  • D. Publish the query to Event Grid and filter by subject.

Best answer: B

Explanation: Semantic retrieval uses embeddings to represent meaning, not just words. Because the articles already contain embedding vectors, the API should generate an embedding for the user’s query with a compatible model and use Azure Cosmos DB for NoSQL vector similarity search to find the nearest stored article vectors. This supports matches such as “stop my subscription” and “cancel your plan” even when the literal terms differ. Keyword predicates can still be useful for metadata filters, but they do not solve the stated semantic-match requirement by themselves.

  • Keyword filtering fails because CONTAINS depends on literal text matches and can miss semantically equivalent wording.
  • Exact vector matching fails because embeddings are compared by similarity distance, not equality to the query text.
  • Event filtering fails because Event Grid routes events; it does not perform semantic retrieval over stored embeddings.

Continue with full practice

Use the AI-200 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AI-200 on Web View AI-200 Practice Test

Free review resource

Read the AI-200 Cheat Sheet for compact concept review before returning to timed practice.

Revised on Monday, May 25, 2026