Tag: Microsoft Certification

AI-200, Databases, Microsoft Certification, NoSQL August 15, 2026August 15, 2026

Model schemas and implement indexing strategies, including designing tables and choosing appropriate data types (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Database for PostgreSQL
      --> Model schemas and implement indexing strategies, including designing tables and choosing appropriate data types

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Database for PostgreSQL is a fully managed PostgreSQL service that provides the capabilities of the PostgreSQL relational database engine while Azure manages much of the underlying infrastructure.

For the AI-200 exam, developers need to understand how to design an effective PostgreSQL schema and choose appropriate indexing strategies. These decisions directly affect:

Query performance
Storage requirements
Insert and update performance
Data integrity
Scalability
Application responsiveness
Resource consumption
AI and vector-search workloads

Two fundamental decisions are involved:

How should the data be modeled?
How should the database be indexed to efficiently retrieve that data?

A good schema and indexing strategy should be based on the application’s actual workload rather than simply creating an index on every column.

1. Understanding Relational Schema Design

A relational schema defines how information is organized into:

Tables
Columns
Data types
Primary keys
Foreign keys
Constraints
Indexes
Relationships

For example, an AI-powered customer-support application might store information in tables such as:

			
CREATE TABLE customers (
    customer_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

		

And:

			
CREATE TABLE support_tickets (
    ticket_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    subject TEXT NOT NULL,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_ticket_customer
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

		

This design separates customer information from ticket information while establishing a relationship between them.

2. Choose Data Types Carefully

One of the most important schema-design decisions is choosing the appropriate data type for each column.

PostgreSQL provides many native data types, including numeric, character, date/time, Boolean, JSON, UUID, array, and other specialized types. (PostgreSQL)

The general principle is:

Choose the smallest appropriate type that accurately represents the data and its required operations.

Avoid automatically storing everything as TEXT.

2.1 Integer Types

PostgreSQL provides several integer types.

Type	Size	Typical use
`smallint`	2 bytes	Small numeric ranges
`integer`	4 bytes	General-purpose integers
`bigint`	8 bytes	Large identifiers or numeric values

For example:

customer_id BIGINT

may be appropriate when a system could eventually contain billions of records.

An integer may be sufficient when the expected range is much smaller.

Exam consideration

If a value can exceed the range of integer, use bigint.

Don’t select bigint merely because “bigger is better.” Larger types can increase storage requirements and potentially affect index size.

3. Exact Versus Approximate Numeric Values

PostgreSQL provides exact numeric types such as:

			
numeric
decimal

and approximate floating-point types such as:

			
real
double precision

numeric and decimal are appropriate when exact decimal arithmetic is important, such as financial amounts. PostgreSQL documents numeric/decimal as exact numeric types, while real and double precision are approximate floating-point types. (PostgreSQL)

For example:

price NUMERIC(10,2)

is preferable to:

price DOUBLE PRECISION

when representing currency.

Exam tip

If the question involves money, financial calculations, or exact decimal precision, think:

NUMERIC / DECIMAL

If approximate scientific or engineering calculations are acceptable, floating-point types may be appropriate.

4. Character Data Types

Common character types include:

			
text
varchar(n)
char(n)

For most variable-length textual application data, text or appropriately sized varchar is generally suitable.

For example:

description TEXT

could be appropriate for a support-ticket description.

A fixed-width char(n) should generally be reserved for situations where fixed-width semantics are actually useful.

Important distinction

A developer shouldn’t use varchar(100) simply because the database “requires” a length. PostgreSQL’s text type can be used for unrestricted variable-length strings.

If a maximum length is a business rule, however, enforcing that rule through a constraint can be appropriate.

5. Date and Time Types

PostgreSQL supports several date/time types, including:

date
time
timestamp
timestamp with time zone
interval

PostgreSQL uses timestamptz as an abbreviation for timestamp with time zone. (PostgreSQL)

For distributed cloud applications, timestamps frequently need to represent an absolute point in time.

For example:

created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP

is often preferable to:

created_at TIMESTAMP

when the application operates across multiple time zones.

Exam tip

If the requirement is:

“Store the instant an event occurred regardless of the user’s time zone.”

Think:

TIMESTAMPTZ

If the requirement is specifically a calendar date without a time component:

DATE

6. Boolean Values

Use:

BOOLEAN

for true/false information.

Example:

is_active BOOLEAN NOT NULL DEFAULT TRUE

Don’t store values such as:

			
"Y"
"N"

or:

			
"true"
"false"

as text unless there is a specific interoperability requirement.

Native types communicate intent more clearly and allow PostgreSQL to enforce appropriate semantics.

7. UUIDs

PostgreSQL has a native uuid type for universally unique identifiers. A UUID is a 128-bit value and can be useful in distributed applications where identifiers need to be generated independently across systems. (PostgreSQL)

For example:

			
CREATE TABLE documents (
    document_id UUID PRIMARY KEY,
    title TEXT NOT NULL
);

UUIDs can be particularly useful when:

Multiple systems generate identifiers.
Records are created independently by distributed services.
Exposing sequential database IDs externally is undesirable.
Globally unique identifiers are required.

However, UUIDs aren’t automatically better than integer keys. Sequential numeric identifiers can be smaller and may have favorable index characteristics.

8. JSON and JSONB

PostgreSQL supports both:

			
json
jsonb

json stores JSON text, while jsonb stores decomposed binary JSON data and provides indexing capabilities useful for querying JSON content. (PostgreSQL)

For applications that need to frequently query JSON attributes, jsonb is often the more useful choice.

For example:

			
CREATE TABLE documents (
    document_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    metadata JSONB
);

A document might contain:

			
{
    "language": "en",
    "category": "technical",
    "source": "internal"
}

		

This can be useful when an AI application has semi-structured metadata that doesn’t justify creating a separate relational column for every possible attribute.

Important design consideration

Don’t use JSONB as an excuse to abandon relational modeling.

If an attribute is:

frequently queried,
important to business logic,
highly structured,
relational in nature,

a normal relational column may be more appropriate.

9. Primary Keys

Every major entity should generally have a clearly defined primary key.

Example:

			
CREATE TABLE products (
    product_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    product_name TEXT NOT NULL
);

A primary key provides:

Entity identification
Uniqueness
A target for foreign-key relationships
An important access path for queries

PostgreSQL automatically creates a unique index to enforce a primary-key constraint.

Exam tip

Don’t create a separate duplicate index on a primary-key column unless there is a specific reason.

For example, creating:

			
CREATE INDEX idx_products_product_id
ON products(product_id);

after declaring:

product_id BIGINT PRIMARY KEY

would normally be redundant.

10. Foreign Keys and Relationships

Foreign keys maintain relationships between tables.

For example:

			
CREATE TABLE orders (
    order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    order_date TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_orders_customer
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

		

This establishes:

			
Customer
   |
   +----< Orders

A foreign-key constraint protects referential integrity.

However, developers should also consider indexing foreign-key columns when they are frequently used for:

Joins
Filtering
Parent/child lookups
Deletes or updates involving referenced rows

A foreign-key constraint itself does not automatically create an index on the referencing column.

11. What Is an Index?

An index is a separate data structure that allows PostgreSQL to locate rows more efficiently than scanning the entire table.

Without an appropriate index, PostgreSQL may need to perform a sequential scan:

			
Read row 1
Read row 2
Read row 3
...
Read row 1,000,000

		

An index can allow PostgreSQL to locate relevant rows much more efficiently.

For example:

			
CREATE INDEX idx_customers_email
ON customers(email);

Now a query such as:

			
SELECT *
FROM customers
WHERE email = 'user@example.com';

has an index available for locating the matching row.

PostgreSQL emphasizes that indexes can significantly improve retrieval performance but also introduce system overhead, so they should be used sensibly. (PostgreSQL)

12. The Cost of Indexes

Indexes aren’t free.

An index consumes:

Disk space
Memory/cache resources
CPU during maintenance
Time during INSERT
Time during UPDATE
Time during DELETE

When a row changes, PostgreSQL may also need to update associated indexes.

Therefore:

More indexes do not automatically mean better performance.

For example, creating ten indexes on a heavily written table may significantly increase write overhead.

A good indexing strategy balances:

Read performance

against

Write and storage overhead.

13. B-tree Indexes

The default PostgreSQL index type is the B-tree.

For example:

			
CREATE INDEX idx_orders_customer_id
ON orders(customer_id);

B-tree indexes are particularly useful for:

Equality comparisons
Range comparisons
Sorting
ORDER BY
Many common join operations

For example:

WHERE customer_id = 100

or:

WHERE order_date >= '2026-01-01'

or:

ORDER BY order_date

are common candidates for B-tree indexes.

14. Indexing Columns Used in WHERE Clauses

Consider:

			
SELECT *
FROM orders
WHERE customer_id = 12345;

If this query is executed frequently against a large table, an index on customer_id may be beneficial:

			
CREATE INDEX idx_orders_customer_id
ON orders(customer_id);

The key question isn’t:

“Can I index this column?”

Almost any column can be indexed.

The better question is:

“Does an index on this column improve an important query enough to justify its maintenance cost?”

15. Selectivity Matters

Index usefulness depends partly on selectivity.

Selectivity describes how effectively a predicate narrows the number of rows that must be examined.

Suppose a table contains 10 million orders.

A query:

WHERE customer_id = 98765

might return only 20 rows.

That is highly selective.

An index is potentially very useful.

Now consider:

WHERE status = 'Active'

if 9.5 million of the 10 million rows have status = 'Active'.

The predicate is not very selective.

An index might provide little benefit, depending on the workload and query plan.

Exam principle

Don’t assume that every frequently filtered column should automatically have an index.

Consider:

Number of distinct values
Number of rows returned
Query frequency
Table size
Query execution plan

16. Composite Indexes

A composite, or multicolumn, index contains multiple columns.

For example:

			
CREATE INDEX idx_orders_customer_date
ON orders(customer_id, order_date);

This can be useful for queries such as:

			
SELECT *
FROM orders
WHERE customer_id = 100
  AND order_date >= '2026-01-01';

The order of columns in a composite B-tree index matters.

PostgreSQL generally gets the greatest benefit from constraints on the leading/leftmost columns of a multicolumn B-tree index. (PostgreSQL)

Therefore:

(customer_id, order_date)

and:

(order_date, customer_id)

are not interchangeable from an optimization perspective.

17. Choosing Column Order in Composite Indexes

Suppose the application frequently runs:

			
WHERE customer_id = ?
AND order_date >= ?

An index such as:

			
CREATE INDEX idx_orders_customer_date
ON orders(customer_id, order_date);

is a natural candidate.

The equality predicate on customer_id comes first, followed by the range condition on order_date.

A useful general pattern is:

Equality conditions first, followed by range/order columns, when that matches the workload.

But don’t treat this as an absolute rule. The optimizer and actual query workload matter.

18. Indexes for ORDER BY

Indexes can also help eliminate or reduce the cost of sorting.

For example:

			
CREATE INDEX idx_orders_customer_date
ON orders(customer_id, order_date);

can potentially support queries involving:

			
WHERE customer_id = 100
ORDER BY order_date;

PostgreSQL B-tree indexes naturally support ordered scans, and index ordering can also be explicitly configured when specialized ordering requirements exist. (PostgreSQL)

19. Unique Indexes

A unique index ensures that duplicate values aren’t allowed.

For example:

			
CREATE UNIQUE INDEX idx_customers_email
ON customers(email);

This can enforce uniqueness for email addresses.

Alternatively, define the business rule directly through a constraint:

email TEXT UNIQUE

The latter is often clearer when uniqueness is part of the table’s logical model.

20. Partial Indexes

A partial index indexes only rows satisfying a condition.

For example:

			
CREATE INDEX idx_open_tickets
ON support_tickets(customer_id)
WHERE status = 'Open';

This can be particularly useful when:

Only a subset of rows is frequently queried.
The qualifying subset is relatively small.
The predicate is stable and matches important queries.

A query such as:

			
SELECT *
FROM support_tickets
WHERE status = 'Open'
  AND customer_id = 100;

may benefit from the partial index.

Why partial indexes can help

Instead of indexing millions of rows:

10 million total rows

the index may contain only:

500,000 open tickets

That can reduce index size and maintenance overhead.

21. Expression Indexes

PostgreSQL can index the result of an expression rather than simply a column.

For example:

			
CREATE INDEX idx_users_lower_email
ON users (LOWER(email));

This can support queries such as:

			
SELECT *
FROM users
WHERE LOWER(email) = 'user@example.com';

Without a matching expression index, applying a function to the indexed column may prevent PostgreSQL from using an ordinary index on email as effectively.

Exam concept

If a query consistently searches on:

LOWER(column)

consider whether an expression index on:

LOWER(column)

is appropriate.

22. Covering Indexes and INCLUDE

PostgreSQL supports indexes that include additional non-key columns.

For example:

			
CREATE INDEX idx_orders_customer
ON orders(customer_id)
INCLUDE (order_date, total_amount);

The key column is:

customer_id

while:

			
order_date
total_amount

are included payload columns.

This can sometimes allow PostgreSQL to satisfy a query directly from the index through an index-only scan, reducing the need to access the table.

However, this should be used selectively because included columns increase index size.

23. GIN, GiST, and BRIN

Although B-tree is the default and most common index type, PostgreSQL provides several index types.

Important types include:

Index	Typical uses
B-tree	Equality, ranges, ordering
Hash	Equality comparisons
GIN	Multivalued data, JSONB, arrays, full-text-related use cases
GiST	Specialized data types, geometric/search operations
BRIN	Very large tables where values correlate with physical row order

For AI-200, don’t memorize these as isolated facts. Understand why a developer would choose a particular index.

24. BRIN Indexes

A BRIN, or Block Range Index, is useful when column values have a strong correlation with the physical order of rows.

A classic example is a huge table containing time-series data where rows are generally inserted in chronological order.

For example:

			
CREATE INDEX idx_events_created_brin
ON events USING BRIN(created_at);

A BRIN index is much smaller than a traditional B-tree index in suitable scenarios.

However, it is not a universal replacement for B-tree.

Exam clue

If you see:

Extremely large table
Naturally ordered data
Time-series-like workload
Strong correlation between physical order and column values

consider:

BRIN

25. GIN Indexes and JSONB

GIN indexes are commonly associated with data containing multiple values within a row, including JSONB and arrays.

For example:

			
CREATE INDEX idx_documents_metadata
ON documents USING GIN(metadata);

This can support queries that search within JSONB content.

For AI applications, this can be useful when documents contain metadata such as:

			
{
    "department": "finance",
    "language": "en",
    "document_type": "policy"
}

		

and queries need to filter based on those attributes.

26. Schema Design for AI Applications

AI applications frequently combine traditional relational data with:

Documents
Metadata
Embeddings
User information
Conversation history
Processing status
Model information
Timestamps

A relational schema might look like:

			
CREATE TABLE documents (
    document_id UUID PRIMARY KEY,
    title TEXT NOT NULL,
    content TEXT,
    metadata JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

		

For a vector-enabled application, an embedding column may also be added using an appropriate vector extension/type.

For example, conceptually:

			
documents
---------------------------------
document_id
title
content
metadata
embedding
created_at

		

The exact vector implementation and indexing strategy depend on the PostgreSQL extension and AI workload being used.

27. Don’t Confuse Relational Indexes with Vector Indexes

This is particularly important for AI-200.

A traditional B-tree index is designed for operations such as:

WHERE customer_id = 123

or:

ORDER BY created_at

It is not a general-purpose solution for high-dimensional vector similarity searches.

Vector workloads may use specialized vector indexing mechanisms, such as those provided by pgvector or other supported vector extensions.

For example, Azure Database for PostgreSQL supports vector-search technologies and associated specialized indexes for AI workloads.

The important conceptual distinction is:

			
Traditional relational search
        ↓
B-tree / GIN / GiST / BRIN

versus:

			
Vector similarity search
        ↓
Vector-aware indexing

This distinction becomes especially important when studying the AI-200 PostgreSQL vector-search objectives.

28. Don’t Over-Index

One of the most common database design mistakes is creating indexes without considering the workload.

Imagine:

			
CREATE TABLE transactions (
    transaction_id BIGINT PRIMARY KEY,
    customer_id BIGINT,
    merchant_id BIGINT,
    amount NUMERIC(12,2),
    status TEXT,
    transaction_date TIMESTAMPTZ
);

		

It might be tempting to create five indexes:

			
customer_id
merchant_id
amount
status
transaction_date

		

But that may not be optimal.

Suppose the application primarily runs:

			
WHERE customer_id = ?
AND transaction_date >= ?

A composite index might be much more valuable:

			
CREATE INDEX idx_transactions_customer_date
ON transactions(customer_id, transaction_date);

The actual workload should drive the decision.

29. Indexes and Write Performance

Suppose a table has:

			
table
indexes

Every insert potentially requires maintenance of those indexes.

Therefore:

			
More indexes
      ↓
Potentially faster reads
      ↓
But slower writes + more storage

		

The goal is not maximum indexing.

The goal is:

The right indexes for the application’s important queries.

30. Use Query Plans to Validate Indexing Decisions

Don’t create an index and assume it is being used.

Use PostgreSQL query-plan tools such as:

EXPLAIN

and:

EXPLAIN ANALYZE

For example:

			
EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE customer_id = 100;

The query plan can help determine whether PostgreSQL is performing:

Sequential scans
Index scans
Bitmap index scans
Index-only scans
Joins
Sorts
Other operations

The goal is to understand why a query performs the way it does.

31. Statistics Matter

PostgreSQL’s query optimizer relies on statistics about the data distribution.

If statistics are outdated, PostgreSQL may choose a poor execution plan.

For example, the optimizer might estimate:

Expected rows: 100

when the query actually returns:

2,000,000 rows

That can lead to an inappropriate plan.

Keeping table statistics current is therefore an important part of performance tuning.

Azure Database for PostgreSQL’s performance guidance specifically emphasizes examining query plans, query behavior, index usage, and statistics when diagnosing performance problems.

32. Query Store and Indexing

Azure Database for PostgreSQL Flexible Server provides Query Store capabilities for tracking query performance over time.

Query Store can help identify:

Long-running queries
Resource-intensive queries
Query execution frequency
Changes in query performance
Wait statistics
Potential tuning opportunities

Query Store stores its information in the azure_sys database.

This makes Query Store particularly useful when deciding:

“Which queries actually need optimization?”

rather than guessing based on the schema alone.

33. Autonomous Tuning

Azure Database for PostgreSQL Flexible Server also provides autonomous tuning capabilities.

It can analyze workload information and provide recommendations such as:

Creating potentially beneficial indexes
Removing duplicate indexes
Removing unused indexes
Analyzing tables with missing or outdated statistics
Vacuuming bloated tables

The important exam concept is that automated recommendations should still be evaluated in the context of the application’s workload.

34. A Practical Indexing Process

A good indexing workflow looks like this:

Step 1: Understand the workload

Identify:

Frequently executed queries
Important user-facing queries
Expensive queries
Joins
Filters
Sorts
Aggregations

Step 2: Examine query plans

Use:

EXPLAIN

and:

EXPLAIN ANALYZE

Step 3: Identify bottlenecks

Determine whether the problem involves:

Sequential scans
Poor join strategies
Missing indexes
Sorting
Excessive I/O
Outdated statistics
Poor query design

Step 4: Create the appropriate index

Choose among:

B-tree
Composite index
Partial index
Expression index
GIN
GiST
BRIN
Specialized vector indexes

Step 5: Test the change

Compare:

			
Before
   ↓
Query performance
   ↓
Create index
   ↓
Query performance
   ↓
After

		

Step 6: Monitor production behavior

A theoretically useful index may not provide sufficient real-world benefit.

Azure Query Store can be useful for measuring the effect of changes over time.

35. Common AI-200 Exam Traps

Trap 1: “Index every column”

Incorrect.

Indexes consume storage and introduce write-maintenance overhead.

Trap 2: “Use B-tree for everything”

Incorrect.

B-tree is the default and is excellent for many relational queries, but specialized workloads may require other index types.

Trap 3: “A foreign key automatically creates an index”

Incorrect.

A foreign-key constraint maintains referential integrity, but the referencing column does not automatically receive an index simply because the foreign key exists.

Trap 4: “A primary key needs another index”

Usually incorrect.

The primary-key constraint already creates a unique index.

Trap 5: “Composite index column order doesn’t matter”

Incorrect.

For B-tree indexes, leading columns matter significantly. (PostgreSQL)

Trap 6: “More indexes always improve performance”

Incorrect.

Indexes can improve reads but increase storage and write-maintenance costs.

Trap 7: “Use floating point for currency”

Generally incorrect.

Use an exact numeric type such as:

NUMERIC

when exact decimal arithmetic is required.

Trap 8: “Store all structured data as JSON”

Incorrect.

JSONB is valuable for semi-structured data, but strongly structured and frequently queried attributes may belong in relational columns.

Trap 9: “A relational index is automatically a vector index”

Incorrect.

Vector similarity searches require vector-aware approaches.

36. Quick Reference: Data Type Selection

Requirement	Good candidate
Small integer	`smallint`
General integer	`integer`
Very large integer	`bigint`
Exact decimal	`numeric` / `decimal`
Approximate decimal	`real` / `double precision`
Variable text	`text` / `varchar`
Calendar date	`date`
Absolute timestamp	`timestamptz`
True/false	`boolean`
Globally unique identifier	`uuid`
Semi-structured JSON	`jsonb`
Binary data	`bytea`

37. Quick Reference: Index Selection

Requirement	Potential index
Equality/range queries	B-tree
Sorting	B-tree
Composite filtering	Multicolumn B-tree
Frequently queried subset	Partial index
Function-based searches	Expression index
JSONB/array containment	GIN
Specialized data structures	GiST
Very large, physically correlated data	BRIN
Vector similarity	Vector-specific index

The actual choice should always be validated against the workload and execution plan.

38. Key Takeaways for the AI-200 Exam

For this topic, remember these principles:

Choose data types based on the data and required operations.
Use numeric/decimal when exact decimal arithmetic is required.
Use timestamptz when an absolute point in time must be represented across time zones.
Use uuid when globally unique identifiers are useful for a distributed system.
Use jsonb for queryable semi-structured JSON data.
Define primary keys to uniquely identify entities.
Foreign-key columns may need indexes for joins and related access patterns.
B-tree is the default choice for many equality, range, and ordering queries.
Composite-index column order matters.
Partial indexes can efficiently target frequently queried subsets.
Expression indexes can help when queries consistently apply functions to columns.
GIN, GiST, and BRIN serve specialized workloads.
Vector similarity searches require vector-aware indexing.
Every index has a maintenance and storage cost.
Use query plans and workload telemetry to validate indexing decisions.
Query Store can help identify expensive queries and evaluate performance changes.
Don’t optimize based solely on intuition—measure the workload.

10 Practice Exam Questions

Question 1

A financial application stores transaction amounts in Azure Database for PostgreSQL. The application must perform exact calculations involving dollars and cents.

Which data type should you use for the transaction amount?

A. DOUBLE PRECISION
B. NUMERIC(12,2)
C. REAL
D. VARCHAR(20)

Answer: B

Explanation

NUMERIC is an exact numeric type and is appropriate when exact decimal calculations are required, such as financial amounts. REAL and DOUBLE PRECISION are approximate floating-point types and can introduce rounding behavior that is undesirable for financial calculations.

Question 2

An application frequently executes this query:

			
SELECT *
FROM orders
WHERE customer_id = @customer_id
  AND order_date >= @start_date;

The table contains millions of rows.

Which index is the most appropriate starting point?

			
CREATE INDEX idx_orders_customer_date
ON orders(customer_id, order_date);

			
CREATE INDEX idx_orders_date_customer
ON orders(order_date, customer_id);

			
CREATE INDEX idx_orders_customer
ON orders(customer_id);

			
CREATE INDEX idx_orders_date
ON orders(order_date);

Answer: A

Explanation

The query filters by equality on customer_id and then applies a range condition to order_date. A composite B-tree index beginning with customer_id and followed by order_date is a strong candidate for this workload.

The important concept is that the order of columns in a composite index matters.

Question 3

A PostgreSQL table contains 50 million event records. Records are inserted approximately in chronological order. Queries frequently retrieve events based on a range of timestamps.

Which index type could be particularly appropriate if the timestamp values have a strong correlation with physical row order?

A. GIN
B. Hash
C. BRIN
D. Expression B-tree

Answer: C

Explanation

BRIN indexes are designed for very large tables where indexed values have a useful correlation with the physical order of rows. Time-series data that is inserted chronologically is a classic example.

Question 4

A developer creates this table:

			
CREATE TABLE customers (
    customer_id BIGINT PRIMARY KEY,
    name TEXT NOT NULL
);

The developer then proposes creating another standard index on customer_id.

What is the best response?

A. Create the index because primary keys cannot be indexed.
B. Create the index because primary keys only enforce uniqueness.
C. Create the index because primary-key lookups always require two indexes.
D. The additional index is normally unnecessary because the primary key already has a unique index.

Answer: D

Explanation

A PostgreSQL primary-key constraint is backed by a unique index. Creating another identical index on the same column would normally be redundant and would consume additional storage and maintenance resources.

Question 5

An application stores document metadata in a PostgreSQL jsonb column:

metadata JSONB

The application frequently searches within the JSON documents for matching attributes.

Which index type is commonly appropriate for this workload?

A. GIN
B. BRIN
C. Hash
D. B-tree on the table’s primary key

Answer: A

Explanation

GIN indexes are well suited to indexing composite or multivalued data and are commonly used with jsonb data. They can make searches involving JSONB contents much more efficient.

Question 6

An application frequently executes:

			
SELECT *
FROM users
WHERE LOWER(email) = 'user@example.com';

There is a normal B-tree index on:

email

but the query still isn’t benefiting from the index as expected.

Which approach could directly support this search pattern?

A. Create a BRIN index on email.
B. Create a GIN index on the primary key.
C. Create an expression index on LOWER(email).
D. Convert email to BIGINT.

Answer: C

Explanation

The query applies LOWER() to the column. An expression index can index the result of that expression:

			
CREATE INDEX idx_users_lower_email
ON users(LOWER(email));

This allows PostgreSQL to efficiently support queries using the same expression.

Question 7

A developer is designing a global AI application and wants identifiers that can be generated independently by multiple distributed application instances without coordinating a central sequence.

Which data type is the best fit?

A. SMALLINT
B. UUID
C. REAL
D. DATE

Answer: B

Explanation

PostgreSQL’s native UUID type provides 128-bit universally unique identifiers. UUIDs are particularly useful when identifiers need to be generated independently across distributed systems.

Question 8

A developer wants to improve application performance and proposes creating indexes on every column in a frequently updated table.

Which statement best describes the problem with this approach?

A. PostgreSQL supports only one index per table.
B. Indexes cannot be created on columns used in updates.
C. Indexes can improve reads but increase storage and write-maintenance overhead.
D. PostgreSQL automatically deletes indexes that are not used.

Answer: C

Explanation

Indexes can significantly improve read performance, but they aren’t free. Inserts, updates, and deletes may require corresponding index maintenance. Excessive indexing can therefore increase write overhead and storage consumption.

Question 9

A support system has 20 million tickets, but only 200,000 are currently open. Most application queries retrieve open tickets by customer.

Which indexing strategy could reduce index size while targeting the important workload?

A. Create a partial index containing only open tickets.
B. Create an index on every column in the table.
C. Create a BRIN index on the ticket description.
D. Store the ticket status as JSON.

Answer: A

Explanation

A partial index can index only rows satisfying a predicate:

			
CREATE INDEX idx_open_tickets_customer
ON support_tickets(customer_id)
WHERE status = 'Open';

Because the application primarily queries open tickets, this can provide a smaller, workload-focused index.

Question 10

An AI application stores text embeddings in Azure Database for PostgreSQL and needs to perform nearest-neighbor similarity searches.

Which statement is correct?

A. A standard B-tree index is always sufficient for high-dimensional vector similarity searches.
B. A primary-key index automatically provides vector similarity search.
C. A BRIN index should always be used for embeddings.
D. A vector-aware indexing mechanism should be used for vector similarity workloads.

Answer: D

Explanation

Traditional relational indexes such as B-tree are designed for conventional relational operations such as equality, range filtering, and ordering. Vector similarity search requires vector-aware data types, operators, and indexing mechanisms supported by the chosen PostgreSQL vector solution.

Final Exam Perspective

The most important mindset for this AI-200 topic is to think of database design as a workload-driven optimization problem.

When presented with a scenario, ask:

What data am I storing?

Then:

What is the correct data type?

Then:

How will the application access the data?

Then:

What index best supports those access patterns?

And finally:

Does the index actually improve the workload enough to justify its cost?

That sequence is much more valuable for the exam than simply memorizing lists of PostgreSQL data types and index types.

For Azure Database for PostgreSQL specifically, Query Store and related performance tooling can help move that decision from guesswork to evidence by identifying expensive queries and allowing performance to be compared before and after changes.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Databases, Microsoft Certification August 15, 2026

Connect and query Azure Database for PostgreSQL by using SDKs (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Database for PostgreSQL
      --> Connect and query Azure Database for PostgreSQL by using SDKs

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Database for PostgreSQL is a fully managed PostgreSQL service that provides a familiar PostgreSQL database engine while Azure manages much of the underlying infrastructure, availability, maintenance, and scaling.

For AI-200, developers need to understand how applications connect to Azure Database for PostgreSQL and how they use programming-language client libraries to execute SQL statements.

The key idea is:

Your application normally connects to Azure Database for PostgreSQL through a PostgreSQL client library/driver, establishes a secure connection, executes parameterized SQL commands, processes the results, and properly manages connections and transactions.

Azure Database for PostgreSQL supports commonly used PostgreSQL client interfaces including:

Python — psycopg
C#/.NET — Npgsql
Java — JDBC
Node.js — pg
Go — PostgreSQL drivers such as pgx or pq
PHP — php-pgsql
Ruby — pg
C/C++ — PostgreSQL client libraries
ODBC — psqlODBC

These are PostgreSQL client libraries rather than an Azure-specific database SDK. (Microsoft Learn)

1. Understand the Connection Architecture

A typical application architecture looks like this:

			
Application
    |
    | PostgreSQL client library
    | (Npgsql, psycopg, JDBC, pg, etc.)
    v
Secure connection
    |
    | TLS
    v
Azure Database for PostgreSQL
    |
    v
PostgreSQL database
    |
    +-- Tables
    +-- Views
    +-- Indexes
    +-- Functions
    +-- Extensions

		

The application is responsible for using a PostgreSQL-compatible client library. Azure provides the managed PostgreSQL server.

For example:

			
C# application
      |
      v
   Npgsql
      |
      v
Azure Database for PostgreSQL

		

or:

			
Python application
      |
      v
   psycopg
      |
      v
Azure Database for PostgreSQL

		

This distinction is important for the exam.

Azure SDKs are commonly used to manage Azure resources and services.

PostgreSQL client libraries are used to communicate with the PostgreSQL database itself.

2. Obtain the Connection Information

An application generally needs:

Server hostname
Database name
Port
Username
Authentication information
TLS/SSL configuration

The standard PostgreSQL port is:

An Azure Database for PostgreSQL server typically has a hostname similar to:

myserver.postgres.database.azure.com

A connection string might look conceptually like:

			
host=myserver.postgres.database.azure.com
port=5432
dbname=mydatabase
user=myuser
password=<secret>
sslmode=require

		

The exact connection-string syntax varies by client library.

Azure’s current guidance shows PostgreSQL connections using TLS and port 5432. (Microsoft Learn)

3. Secure Connections with TLS

Applications should connect to Azure Database for PostgreSQL using encrypted connections.

Azure Database for PostgreSQL supports TLS 1.2 and TLS 1.3 and rejects TLS 1.0 and 1.1. (Microsoft Learn)

For example, a connection string can include:

sslmode=require

This tells the client to use an encrypted connection.

More stringent certificate validation can be configured using settings such as:

sslmode=verify-ca

or:

sslmode=verify-full

verify-full provides stronger validation because it verifies both the certificate chain and the server hostname.

Exam tip

If a question describes:

“The application must communicate with PostgreSQL securely.”

Look for TLS/SSL configuration rather than simply changing the database port.

Changing the port does not provide encryption.

4. Authentication Options

Applications can authenticate to Azure Database for PostgreSQL in several ways.

Common approaches include:

PostgreSQL authentication

The application supplies a PostgreSQL username and password.

Conceptually:

			
Application
    |
    | username + password
    v
PostgreSQL

		

This is straightforward but requires careful secret management.

Microsoft Entra authentication

Applications can also authenticate using Microsoft Entra identities.

This allows applications to obtain an access token rather than embedding a PostgreSQL password in application code.

Azure supports both system-assigned and user-assigned managed identities for authentication to Azure Database for PostgreSQL. (Microsoft Learn)

A managed-identity architecture can look like:

			
Azure App Service / VM / Function / Container
             |
             | Managed identity
             v
       Microsoft Entra ID
             |
             | Access token
             v
Azure Database for PostgreSQL

		

This can eliminate the need to store a database password in the application.

Exam tip

If a question says:

“The application is hosted in Azure and should access PostgreSQL without storing credentials.”

The likely direction is Microsoft Entra authentication with a managed identity, assuming the relevant service and database configuration support it.

5. Network Connectivity Matters

Successful SDK code does not guarantee a successful connection.

The application must also have network access to the PostgreSQL server.

Azure Database for PostgreSQL Flexible Server supports two primary networking approaches:

Public access, where allowed IP addresses are controlled through firewall rules
Private access, using virtual network integration

(Microsoft Learn)

Therefore, when troubleshooting a connection, consider:

			
Application
   |
   +--> DNS resolution
   |
   +--> Network routing
   |
   +--> Firewall / network rules
   |
   +--> TLS
   |
   +--> Authentication
   |
   +--> Database authorization
   |
   v
PostgreSQL

		

A connection failure does not necessarily mean the SDK code is incorrect.

6. Python and `psycopg`

For Python applications, psycopg is a current PostgreSQL client library.

The basic pattern is:

			
import psycopg
conn = psycopg.connect(
    "host=myserver.postgres.database.azure.com "
    "port=5432 "
    "dbname=mydatabase "
    "user=myuser "
    "password=<password> "
    "sslmode=require"
)
cursor = conn.cursor()
cursor.execute(
    "SELECT id, name FROM products WHERE category = %s",
    ("AI",)
)
rows = cursor.fetchall()
for row in rows:
    print(row)
cursor.close()
conn.close()

		

The important concepts are:

Create a connection.
Create a cursor.
Execute SQL.
Retrieve results.
Commit changes when appropriate.
Close resources.

Microsoft’s current Python guidance uses psycopg and demonstrates parameterized SQL through cursor.execute(). (Microsoft Learn)

7. Parameterized Queries

One of the most important development practices is to avoid constructing SQL by concatenating user input.

Avoid:

			
name = request.args["name"]
sql = "SELECT * FROM products WHERE name = '" + name + "'"
cursor.execute(sql)

This can expose the application to SQL injection.

Instead, use parameters:

			
cursor.execute(
    "SELECT * FROM products WHERE name = %s",
    (name,)
)

The database driver handles the parameter separately from the SQL statement.

Why this matters

Parameterized queries provide:

Better security
Safer handling of user input
Cleaner code
Better separation between SQL and data

Exam clue

If the question says:

“The application accepts user-provided values and must prevent SQL injection.”

The answer should generally involve parameterized queries, not string concatenation.

8. C#/.NET and Npgsql

For .NET applications, Npgsql is the commonly recommended PostgreSQL ADO.NET data provider.

(Microsoft Learn)

Install it using:

dotnet add package Npgsql

A basic example is:

			
using Npgsql;
var connectionString =
    "Host=myserver.postgres.database.azure.com;" +
    "Port=5432;" +
    "Database=mydatabase;" +
    "Username=myuser;" +
    "Password=<password>;" +
    "SSL Mode=Require;";
await using var connection =
    new NpgsqlConnection(connectionString);
await connection.OpenAsync();
await using var command =
    new NpgsqlCommand(
        "SELECT id, name FROM products WHERE category = @category",
        connection);
command.Parameters.AddWithValue("category", "AI");
await using var reader =
    await command.ExecuteReaderAsync();
while (await reader.ReadAsync())
{
    Console.WriteLine(
        $"{reader.GetInt32(0)} - {reader.GetString(1)}");
}

		

Notice the use of:

@category

instead of concatenating a value into the SQL string.

9. JDBC for Java Applications

Java applications commonly use the PostgreSQL JDBC driver.

A conceptual example is:

			
String url =
    "jdbc:postgresql://myserver.postgres.database.azure.com:5432/mydatabase"
    + "?sslmode=require";
Connection connection =
    DriverManager.getConnection(
        url,
        username,
        password);
PreparedStatement statement =
    connection.prepareStatement(
        "SELECT id, name FROM products WHERE category = ?");
statement.setString(1, "AI");
ResultSet results = statement.executeQuery();
while (results.next()) {
    System.out.println(results.getString("name"));
}

		

The important pattern is:

			
Connection
    ↓
PreparedStatement
    ↓
Parameters
    ↓
executeQuery()
    ↓
ResultSet

		

Exam tip

If you see:

PreparedStatement

think:

Parameterized SQL and protection against SQL injection.

10. Node.js and the `pg` Package

Node.js applications can use the PostgreSQL pg package.

Conceptually:

			
const { Client } = require("pg");
const client = new Client({
    host: "myserver.postgres.database.azure.com",
    port: 5432,
    database: "mydatabase",
    user: "myuser",
    password: "<password>",
    ssl: true
});
await client.connect();
const result = await client.query(
    "SELECT id, name FROM products WHERE category = $1",
    ["AI"]
);
console.log(result.rows);
await client.end();

		

Notice that PostgreSQL parameters use placeholders such as:

			
$1
$2
$3

rather than constructing SQL dynamically.

11. Querying Data

Applications can use the client library to execute standard PostgreSQL SQL.

For example:

			
SELECT id, name, price
FROM products
WHERE category = 'AI'
ORDER BY price DESC;

The client library sends the SQL statement to PostgreSQL and returns the results to the application.

A typical workflow is:

			
Build SQL
   ↓
Bind parameters
   ↓
Execute command
   ↓
Database processes query
   ↓
Return rows
   ↓
Application processes rows

		

12. Executing INSERT, UPDATE, and DELETE

SDK/client libraries aren’t limited to SELECT.

They can execute data modification statements.

INSERT

			
INSERT INTO products (name, category, price)
VALUES ($1, $2, $3);

UPDATE

			
UPDATE products
SET price = $1
WHERE id = $2;

DELETE

			
DELETE FROM products
WHERE id = $1;

Applications must properly handle transactions for operations where multiple changes need to succeed or fail together.

13. Transactions

A transaction groups multiple database operations into a logical unit.

For example:

			
BEGIN
   |
   +--> INSERT order
   |
   +--> INSERT order item
   |
   +--> UPDATE inventory
   |
COMMIT

		

If something fails:

			
BEGIN
   |
   +--> INSERT order
   |
   +--> INSERT order item
   |
   +--> ERROR
   |
ROLLBACK

		

This provides atomicity.

Typical transaction pattern

			
with psycopg.connect(connection_string) as conn:
    with conn.cursor() as cursor:
        cursor.execute(
            "INSERT INTO orders(customer_id) VALUES (%s)",
            (customer_id,)
        )
        cursor.execute(
            "UPDATE inventory SET quantity = quantity - %s "
            "WHERE product_id = %s",
            (quantity, product_id)
        )

		

If an exception occurs within the transaction context, the transaction can be rolled back rather than leaving partially applied changes.

14. Connection Pooling

Opening a new database connection for every request can be inefficient.

Consider a web API receiving 1,000 requests:

			
Request 1 → Open connection → Query → Close
Request 2 → Open connection → Query → Close
Request 3 → Open connection → Query → Close
...

This creates unnecessary connection overhead.

A connection pool instead maintains a set of reusable connections:

                Connection Pool
              +------------------+
Request ----->| Connection 1     |
Request ----->| Connection 2     |
Request ----->| Connection 3     |
Request ----->| Connection 4     |
              +------------------+

The application:

Requests a connection.
Uses it.
Returns it to the pool.

Benefits

Connection pooling can:

Reduce connection establishment overhead
Improve application performance
Handle concurrent workloads more efficiently
Reduce unnecessary database connection churn

Important distinction

A connection pool is not the same thing as a database transaction.

A pool manages reusable connections.

A transaction manages the atomicity of database operations.

15. Asynchronous Database Operations

Modern applications often use asynchronous database operations.

For example, .NET applications can use:

await connection.OpenAsync();

and:

await command.ExecuteReaderAsync();

This helps applications avoid blocking a thread while waiting for database I/O.

This can be particularly important for:

Web APIs
Serverless applications
High-concurrency applications
AI applications processing many requests

16. Handling Query Results

A database query may return:

Zero rows
One row
Many rows

Applications should not assume that a result always exists.

For example:

			
SELECT id, name
FROM products
WHERE id = $1;

The application should handle the case where no matching product exists.

For multiple rows, the application generally iterates over a cursor, reader, or result set.

17. Avoid Retrieving More Data Than Necessary

A common application mistake is:

			
SELECT *
FROM products;

when the application only needs two columns.

Prefer:

			
SELECT id, name
FROM products;

Similarly, use filtering:

			
SELECT id, name
FROM products
WHERE category = $1;

rather than retrieving an entire table and filtering the results in application code.

This reduces:

Data transferred over the network
Application memory usage
Database processing in some scenarios
Unnecessary work

18. Use the Database to Perform Database Work

Suppose an application needs the average product price.

Avoid:

			
Retrieve every product
       ↓
Send all products to application
       ↓
Calculate average in application

		

Prefer:

			
SELECT AVG(price)
FROM products;

The database is optimized to perform database operations.

Other useful SQL operations include:

			
COUNT()
SUM()
AVG()
MIN()
MAX()
GROUP BY
ORDER BY
JOIN

		

This is particularly relevant to AI applications because unnecessarily moving large datasets into application memory can become expensive and slow.

19. Stored Procedures and Functions

PostgreSQL supports database-side functions and procedures.

An application can invoke them through its client library.

For example:

SELECT calculate_customer_score($1);

This can be useful when business or database logic is intentionally centralized in PostgreSQL.

However, don’t automatically move all application logic into database functions.

Consider:

Maintainability
Performance
Security
Deployment complexity
Transaction requirements
Whether the logic belongs in the database or application

20. Connection Lifecycle

A reliable application should carefully manage database resources.

The general lifecycle is:

			
Create/acquire connection
          ↓
Open connection
          ↓
Create command/cursor
          ↓
Execute SQL
          ↓
Process results
          ↓
Commit or rollback
          ↓
Close/release resources

		

Using language-supported resource-management features is preferable.

For example, C# uses:

await using

and Python can use:

with

This reduces the chance of leaking connections or other resources.

21. Secrets Should Not Be Hard-Coded

Avoid:

password = "MySuperSecretPassword123!"

inside application source code.

Instead, use a secure configuration mechanism.

For Azure applications, a common architecture is:

			
Application
     |
     v
Managed Identity
     |
     v
Azure Key Vault
     |
     v
Database credentials/secrets

		

Or, when using Microsoft Entra authentication, eliminate the need for a database password where appropriate.

This is especially important in production AI applications because database credentials can provide access to sensitive business information.

22. Common Connection Problems

When an application cannot connect, troubleshoot systematically.

Problem 1: Incorrect hostname

Verify the server’s fully qualified domain name.

For example:

myserver.postgres.database.azure.com

Problem 2: Firewall restriction

With public access, the application’s source IP must be allowed by the server’s firewall configuration.

Problem 3: Private networking

If the server uses private access, the application must have appropriate connectivity to the virtual network.

Problem 4: Authentication failure

Verify:

Username
Password or token
Authentication method
Database permissions

Problem 5: TLS configuration

Verify the client supports the required TLS configuration and that the connection string is configured appropriately.

Problem 6: Wrong database

The server may be reachable, but the requested database may not exist or the user may not have access.

23. Connection Failure vs. Authorization Failure

This distinction is important for troubleshooting questions.

Connection failure

The application cannot establish a connection to PostgreSQL.

Possible causes:

			
DNS
Firewall
Network
Port
TLS
Server availability

		

Authentication failure

The server is reachable, but the credentials or authentication mechanism are invalid.

			
"Who are you?"
       ↓
Authentication

Authorization failure

The user successfully authenticated but doesn’t have permission to perform the requested operation.

			
"Who are you?"
       ↓
Authentication
       ↓
"What are you allowed to do?"
       ↓
Authorization

		

A question that says:

“The application successfully connects but receives a permission-denied error when querying a table.”

should lead you toward database permissions, not firewall configuration.

24. SDK/Client Library Selection

A useful AI-200 mental model is:

Application language	PostgreSQL client
Python	`psycopg`
C#/.NET	Npgsql
Java	JDBC PostgreSQL driver
Node.js	`pg`
Ruby	`pg`
PHP	`php-pgsql`
Go	PostgreSQL driver such as `pgx`
C	`libpq`

Azure’s current connection-library guidance lists these types of client interfaces for Azure Database for PostgreSQL Flexible Server. (Microsoft Learn)

Remember:

The client library communicates with PostgreSQL; it isn’t primarily an Azure resource-management SDK.

25. AI Application Considerations

This topic becomes especially important in AI applications.

A typical AI application might look like:

			
User
  |
  v
AI application
  |
  +--> Azure OpenAI
  |
  +--> Azure Database for PostgreSQL
  |       |
  |       +--> Application data
  |       +--> Embeddings
  |       +--> Vector indexes
  |
  +--> Azure Storage

		

The application may use PostgreSQL for:

Relational application data
Conversation history
User information
AI-generated metadata
Document metadata
Embeddings
Vector search

The SDK/client library provides the application with the database connection needed to execute SQL and, when configured, vector-related PostgreSQL operations.

26. Key Exam Takeaways

For AI-200, remember these relationships:

Connection

			
Application
    ↓
PostgreSQL client library
    ↓
TLS connection
    ↓
Azure Database for PostgreSQL

		

Python

psycopg

.NET

Npgsql

Java

JDBC

Node.js

pg

Security

			
TLS
+
secure credential management
+
Microsoft Entra authentication where appropriate
+
managed identities where appropriate

		

Query security

			
Parameterized queries
        ↓
Avoid SQL injection

Performance

			
Connection pooling
+
asynchronous I/O
+
efficient SQL
+
retrieve only required data

		

Transactions

			
BEGIN
   ↓
Multiple operations
   ↓
COMMIT
or
ROLLBACK

		

Troubleshooting

			
Network
  ↓
TLS
  ↓
Authentication
  ↓
Authorization
  ↓
SQL/query behavior

		

Practice Exam Questions

Question 1

A Python application hosted in Azure must connect to Azure Database for PostgreSQL and execute parameterized SQL queries. Which client library should the developer use?

A. psycopg
B. azure-storage-blob
C. azure-cosmos
D. redis-py

Answer: A

Explanation

psycopg is a PostgreSQL client library for Python. It provides the functionality required to establish PostgreSQL connections and execute SQL statements.

The other libraries target different Azure services or technologies:

azure-storage-blob — Azure Blob Storage
azure-cosmos — Azure Cosmos DB
redis-py — Redis

The important distinction is that Azure Database for PostgreSQL is accessed using a PostgreSQL client library.

Question 2

A web application accepts a product name from users and uses that value in a PostgreSQL query. Which approach provides the best protection against SQL injection?

A. Use a parameterized query and bind the product name as a parameter.

B. Encode the product name using Base64 before concatenating it into the SQL statement.

C. Store the product name in an Azure Storage blob before executing the query.

D. Disable TLS for the database connection.

Answer: A

Explanation

Parameterized queries separate SQL code from user-supplied values.

For example:

			
cursor.execute(
    "SELECT * FROM products WHERE name = %s",
    (product_name,)
)

The value is treated as data rather than executable SQL.

Base64 encoding does not prevent SQL injection, and neither Blob Storage nor TLS configuration solves SQL injection.

Question 3

An application is deployed using Azure Database for PostgreSQL with public network access. The application receives a connection timeout. The database server is running and the connection string contains the correct hostname. What should the developer investigate first?

A. Whether the SQL query uses a parameterized statement

B. Whether the database table has an index

C. Whether the application’s source IP address is allowed by the PostgreSQL firewall rules

D. Whether the application has enough memory to process query results

Answer: C

Explanation

With public access, Azure Database for PostgreSQL uses firewall rules to control allowed client IP addresses.

A timeout before a database connection is established points toward network connectivity rather than SQL query construction or database indexing.

The troubleshooting sequence should include:

			
DNS
→ Network
→ Firewall
→ TLS
→ Authentication
→ Authorization
→ Query

		

Question 4

A .NET application needs to connect to Azure Database for PostgreSQL and execute SQL statements. Which library is the appropriate PostgreSQL client?

A. Azure.Storage.Blobs

B. Azure.Messaging.ServiceBus

C. Microsoft.Data.SqlClient

D. Npgsql

Answer: D

Explanation

Npgsql is the PostgreSQL data provider for .NET and is used to connect to PostgreSQL databases and execute PostgreSQL SQL statements.

Microsoft.Data.SqlClient is designed for SQL Server/Azure SQL rather than PostgreSQL.

Question 5

An application performs five related database operations. If the third operation fails, none of the previous operations should remain committed. Which database capability should the developer use?

A. A transaction

B. A connection string

C. A firewall rule

D. A connection pool

Answer: A

Explanation

A transaction allows multiple operations to be treated as a single logical unit.

For example:

			
BEGIN
  Operation 1
  Operation 2
  Operation 3 ← failure
ROLLBACK

		

The rollback prevents earlier operations in the transaction from remaining committed.

A connection pool manages reusable connections; it does not provide transaction semantics.

Question 6

A high-traffic web API opens a new PostgreSQL connection for every HTTP request and closes it immediately after the query. The application experiences unnecessary connection overhead. What should the developer consider?

A. Disable TLS

B. Use connection pooling

C. Replace PostgreSQL with Blob Storage

D. Increase the database query timeout

Answer: B

Explanation

Connection pooling allows the application to reuse established database connections instead of repeatedly creating and destroying them.

This can reduce connection-establishment overhead and improve performance for applications handling many requests.

Question 7

An Azure-hosted application needs to access Azure Database for PostgreSQL without storing a database password in application source code. Which authentication approach is most appropriate when supported by the application’s hosting environment and database configuration?

A. Hard-code the administrator password in the application

B. Store the password in a source-code configuration file

C. Use Microsoft Entra authentication with a managed identity

D. Disable authentication on the PostgreSQL server

Answer: C

Explanation

Managed identities allow Azure resources to authenticate to supported services without developers embedding credentials in application code.

Azure Database for PostgreSQL supports Microsoft Entra authentication and managed identities. (Microsoft Learn)

Hard-coding credentials is insecure, and disabling authentication is not an appropriate solution.

Question 8

A Java application needs to execute the following query using a user-provided value:

			
SELECT *
FROM documents
WHERE category = ?

Which Java API should the developer use to safely bind the value?

A. PreparedStatement

B. StringBuilder

C. System.out

D. FileOutputStream

Answer: A

Explanation

PreparedStatement is designed for parameterized SQL.

The application can bind the parameter rather than concatenate user input into the SQL string.

For example:

			
PreparedStatement statement =
    connection.prepareStatement(
        "SELECT * FROM documents WHERE category = ?");
statement.setString(1, category);

This is safer than dynamically constructing SQL with user input.

Question 9

An application successfully establishes a connection to Azure Database for PostgreSQL. However, when it attempts to query a table, PostgreSQL returns a permission-denied error. Which area should the developer investigate?

A. DNS resolution

B. Azure Storage firewall rules

C. Database authorization and user permissions

D. PostgreSQL server hostname

Answer: C

Explanation

The application has already successfully connected, so basic network connectivity and server resolution are working.

A permission-denied error after connection generally indicates an authorization problem.

The developer should investigate:

Database user
Role membership
Table permissions
Schema permissions
Required privileges

This is different from authentication, which establishes who the user is.

Question 10

An application retrieves only the name and category of a product. Which query is generally preferable when those are the only required values?

			
SELECT *
FROM products;

			
SELECT *
FROM products
WHERE id = $1;

			
SELECT name, category
FROM products
WHERE id = $1;

			
SELECT *
FROM products
ORDER BY name;

Answer: C

Explanation

The application only needs name and category, so the query should retrieve only those columns and filter to the required row.

			
SELECT name, category
FROM products
WHERE id = $1;

This minimizes unnecessary data retrieval and uses a parameterized value.

The other queries retrieve unnecessary columns or, in some cases, unnecessary rows.

Final AI-200 Study Summary

For this topic, the most important thing to remember is that Azure Database for PostgreSQL is PostgreSQL, so applications generally communicate with it through standard PostgreSQL client libraries.

The core exam concepts can be condensed to:

Concept	Remember
Python	`psycopg`
.NET	Npgsql
Java	JDBC
Node.js	`pg`
Default PostgreSQL port	5432
Transport security	TLS
Query security	Parameterized queries
Multiple related operations	Transactions
High-volume connections	Connection pooling
Azure credential-free authentication	Managed identity + Microsoft Entra authentication
Public networking	Firewall rules / allowed IPs
Private networking	VNet/private connectivity
Authentication	Establishes identity
Authorization	Determines permissions
Query results	Process through cursor/reader/result set
Resource management	Close/release connections and cursors
Performance	Efficient SQL, limited columns/rows, pooling, appropriate async operations

The exam is especially likely to test whether you can distinguish the database client library, authentication, networking, authorization, query security, and connection management. Those concepts are easy to mix together, so keeping those boundaries clear is valuable.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Azure AI, Cloud computing, Databases, Microsoft Certification, NoSQL August 15, 2026August 15, 2026

Store and retrieve embeddings and execute vector similarity search for semantic retrieval (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Cosmos DB for NoSQL
      --> Store and retrieve embeddings and execute vector similarity search for semantic retrieval

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Modern AI applications frequently need to retrieve information based on meaning, rather than simply matching exact words.

For example, suppose a user asks:

“What options are available for taking my dog on vacation?”

A traditional keyword search might look for documents containing the words dog, vacation, or travel. A semantic search system can instead identify documents discussing pet-friendly hotels, even if those documents never use the exact words in the user’s question.

This is accomplished using vector embeddings and vector similarity search.

Azure Cosmos DB for NoSQL provides integrated vector storage, indexing, and search capabilities. Applications can store embeddings directly alongside their source documents and use the VectorDistance() system function to find documents whose vectors are closest to a query vector.

For the AI-200 exam, you should understand:

What embeddings are
How embeddings are generated
How embeddings are stored in Cosmos DB
Vector embedding policies
Vector indexing policies
flat, quantizedFlat, and diskANN
The VectorDistance() function
k-nearest-neighbor (kNN) searches
Semantic retrieval
Filtering vector searches
Why TOP N is important
How vector search fits into RAG applications
Important vector-search limitations

1. What Is a Vector Embedding?

A vector embedding is a numerical representation of information.

An embedding model converts content such as:

Text
Documents
Images
Audio
Other supported data

into an array of numerical values.

For example, a simplified embedding might look like:

[0.12, -0.43, 0.87, 0.21, -0.09]

Real-world embedding models generally produce vectors with many more dimensions.

The important concept is that the position of an embedding in a high-dimensional mathematical space represents characteristics of the original content.

Content with similar meanings tends to have vectors that are close together.

For example:

"How can I travel with my dog?"

might be semantically close to:

"Hotels that allow pets"

even though the two sentences don’t contain the same words.

2. Embeddings Are Generated Outside Cosmos DB

Azure Cosmos DB stores and searches embeddings, but the embedding itself is typically generated by an embedding model.

For example, an application might use an embedding API such as an Azure OpenAI embedding model.

The general workflow is:

			
Source content
      |
      v
Embedding model
      |
      v
Vector embedding
      |
      v
Azure Cosmos DB

		

For a search request:

			
User query
      |
      v
Embedding model
      |
      v
Query embedding
      |
      v
Cosmos DB vector search
      |
      v
Most semantically similar documents

		

The stored document embedding and query embedding need to be compatible. In practice, applications should generate both using the same embedding model or a compatible embedding space.

3. Storing Embeddings in Cosmos DB

One of the major advantages of the integrated vector capabilities in Azure Cosmos DB for NoSQL is that the embedding can be stored alongside the original document.

For example:

			
{
    "id": "doc001",
    "category": "travel",
    "title": "Pet-Friendly Hotels",
    "content": "Hotels that welcome dogs and cats...",
    "embedding": [
        0.123,
        -0.456,
        0.789,
        0.234
    ]
}

		

The application therefore doesn’t need to maintain a completely separate database containing the vector and another database containing the associated document.

The vector and its source data can be colocated.

This is particularly useful for AI applications because the application can retrieve both:

The similarity result
The original content needed to answer the user’s question

from the same Cosmos DB item.

4. What Is Semantic Retrieval?

Semantic retrieval means finding information based on its meaning rather than simply matching keywords.

Consider these two documents:

Document A

“Our resort provides accommodations for guests traveling with pets.”

Document B

“Our resort has a swimming pool and fitness center.”

A user searches:

“Where can I stay with my dog?”

Document A is likely to have a much closer semantic relationship to the query.

A vector search system identifies that relationship by comparing embeddings.

The basic process is:

Generate embeddings for documents.
Store the embeddings with the documents.
Generate an embedding for the user’s query.
Compare the query vector with document vectors.
Rank documents according to similarity.
Return the most relevant documents.

This is the foundation of many retrieval-augmented generation (RAG) applications.

5. Vector Search in Azure Cosmos DB

Azure Cosmos DB for NoSQL provides vector search capabilities through:

Vector embedding policies
Vector indexing policies
The VectorDistance() system function

Vector indexes improve vector-search efficiency by reducing latency and RU consumption compared with an unindexed/full-scan approach.

At a conceptual level:

                  Azure Cosmos DB
              +---------------------+
              |                     |
Document ---> | Original content    |
              |                     |
Embedding --> | Vector embedding    |
              |                     |
              | Vector index        |
              |                     |
              +----------+----------+
                         ^
                         |
                  VectorDistance()
                         |
                  Query embedding

6. Vector Embedding Policies

A vector embedding policy describes the vector properties that Cosmos DB should treat as embeddings.

The policy can specify characteristics such as:

The vector property path
Number of dimensions
Distance function
Data type

The policy establishes how Cosmos DB should interpret the vector data.

A simplified conceptual configuration might look like:

			
{
    "vectorEmbeddings": [
        {
            "path": "/embedding",
            "dataType": "float32",
            "dimensions": 1536,
            "distanceFunction": "cosine"
        }
    ]
}

		

The exact configuration supported depends on the current Cosmos DB capabilities and account configuration, but the important exam concept is:

The vector embedding policy describes the characteristics of the vector data.

Don’t confuse this with the vector indexing policy.

7. Vector Indexing Policies

The vector indexing policy determines how Cosmos DB indexes the vectors for vector search.

Azure Cosmos DB for NoSQL currently provides three primary vector index types:

Index	General purpose
`flat`	Exact/brute-force vector search
`quantizedFlat`	Quantized vector search for smaller/scoped workloads
`diskANN`	Efficient approximate vector search for larger workloads

Choosing the appropriate index is an important architectural decision.

8. The `flat` Vector Index

The flat index performs a brute-force comparison of vectors.

Its major advantage is accuracy.

A flat search can provide exact nearest-neighbor results.

However, it has a maximum vector dimensionality of 505 dimensions, which makes it unsuitable for many modern high-dimensional embedding models.

It can be appropriate for relatively small vector datasets or situations where exact recall is particularly important.

Key exam concept

Flat = exact/brute-force search.

9. The `quantizedFlat` Vector Index

quantizedFlat compresses vectors before storing them in the vector index.

This can provide:

Lower latency
Higher throughput
Lower RU consumption

compared with an ordinary flat index.

The trade-off is that quantization can result in some loss of accuracy.

quantizedFlat supports vectors up to 4,096 dimensions.

Microsoft currently describes quantizedFlat as particularly appropriate for smaller or more narrowly scoped searches, with 50,000 vectors or fewer in the search scope being a useful general guideline—not an absolute limit. Actual workloads should be benchmarked.

Key exam concept

quantizedFlat = compressed/brute-force search with improved efficiency and a possible small accuracy trade-off.

10. The `diskANN` Vector Index

diskANN is designed for efficient approximate vector search, particularly for larger workloads.

It can provide:

Low latency
High throughput
Efficient RU consumption
High retrieval accuracy

It supports vectors up to 4,096 dimensions.

Microsoft describes DiskANN as generally the most performant option when the search scope exceeds approximately 50,000 vectors, although actual workload testing remains important.

Key exam concept

diskANN = approximate vector search optimized for larger datasets/search scopes.

11. Vector Index Comparison

For exam preparation, remember the following:

Characteristic	`flat`	`quantizedFlat`	`diskANN`
Search type	Exact/brute force	Quantized brute force	Approximate
Maximum dimensions	505	4,096	4,096
Accuracy	Exact	Slight possible loss	High, configurable trade-offs
Large datasets	Poor fit	Better for smaller/scoped data	Excellent
Latency at scale	Higher	Moderate	Lower
RU efficiency at scale	Lower	Better	Better
Typical use	Small/exact searches	Smaller/scoped searches	Large-scale vector search

12. Important Requirement: Vector Index Configuration

A vector index must be configured for the vector property that will be searched.

For example:

			
"vectorIndexes": [
    {
        "path": "/embedding",
        "type": "diskANN"
    }
]

		

The vector embedding policy and vector index work together.

A useful way to remember the distinction is:

Embedding policy = What is my vector?

Vector index = How should I search my vector?

13. Performing Vector Similarity Search

The primary Cosmos DB function used for vector similarity search is:

VectorDistance()

A basic query might look like:

			
SELECT TOP 10
    c.title,
    VectorDistance(c.embedding, @queryVector) AS SimilarityScore
FROM c
ORDER BY VectorDistance(c.embedding, @queryVector)

		

This query:

Takes the query vector.
Compares it with c.embedding.
Calculates a vector distance.
Sorts the results.
Returns the top 10 results.

Microsoft specifically recommends using TOP N for vector searches because returning unnecessary results increases RU consumption and latency.

14. Understanding `VectorDistance()`

The function conceptually compares:

			
Document vector
        |
        v
VectorDistance()
        ^
        |
Query vector

		

The result represents the distance between the vectors.

The exact interpretation depends on the configured distance function.

Common distance concepts include:

Cosine
Euclidean
Dot product

The application should use the distance function appropriate for the embedding model and workload.

15. Why Distance Matters

Suppose the query embedding is:

Q = [0.2, 0.3, 0.5]

and the database contains:

			
A = [0.2, 0.3, 0.5]
B = [0.8, 0.1, 0.2]
C = [-0.4, 0.7, 0.1]

The vector closest to the query is likely the most semantically similar.

The search engine can therefore rank results:

			
Document A
Document B
Document C

The application doesn’t have to know the meaning represented by every dimension.

The embedding model and vector-distance calculation handle that mathematical representation.

16. Always Use `TOP N`

A particularly important exam and practical-development point is:

Use TOP N with vector searches.

For example:

			
SELECT TOP 5
    c.id,
    c.title,
    VectorDistance(c.embedding, @queryVector) AS score
FROM c
ORDER BY VectorDistance(c.embedding, @queryVector)

		

If the application only needs the five most relevant documents, there’s little reason to retrieve thousands of results.

Returning unnecessary results can increase:

RU consumption
Latency
Network traffic
Application processing

Microsoft explicitly recommends TOP N for vector searches.

17. Filtering Vector Searches

Vector search can also be combined with traditional query filtering.

For example:

			
SELECT TOP 10
    c.title,
    c.category,
    VectorDistance(c.embedding, @queryVector) AS score
FROM c
WHERE c.category = "travel"
ORDER BY VectorDistance(c.embedding, @queryVector)

		

This means:

Find the most semantically similar documents within the travel category.

This is extremely useful in real applications.

Examples include:

Search products within a specific department.
Search documents belonging to a specific tenant.
Search hotel information within a particular region.
Search only documents that a user is authorized to access.

Azure Cosmos DB supports combining vector search with other query filtering capabilities.

18. Vector Search and Partitioning

Azure Cosmos DB applications should always consider partitioning.

For example, a multi-tenant application might have:

			
{
    "id": "doc123",
    "tenantId": "tenantA",
    "title": "Company policy",
    "embedding": [...]
}

		

A query could restrict retrieval to a particular tenant:

			
SELECT TOP 10
    c.title,
    VectorDistance(c.embedding, @queryVector) AS score
FROM c
WHERE c.tenantId = @tenantId
ORDER BY VectorDistance(c.embedding, @queryVector)

		

This can narrow the search scope and can be important for both performance and data isolation.

19. Semantic Search vs. Keyword Search

It is important to understand the difference.

Keyword search

A keyword search primarily asks:

Does this document contain the requested word or phrase?

For example:

"automobile"

might fail to find a document that only says:

"car"

Semantic search

Semantic search asks:

Which documents are mathematically closest in meaning to this query?

Therefore:

"automobile"

may retrieve documents discussing:

			
cars
vehicles
motor vehicles
transportation

depending on how the embedding model represents the concepts.

20. Hybrid Search

Vector search doesn’t have to replace traditional search.

Many AI applications use hybrid search, combining:

Keyword/full-text search
Vector similarity
Metadata filtering

For example:

			
User query
     |
     +--------------------+
     |                    |
     v                    v
Keyword search       Vector search
     |                    |
     +---------+----------+
               |
               v
       Combined ranking
               |
               v
        Relevant results

		

This can provide better retrieval than relying exclusively on either keyword or vector search.

For example, vector search is good at identifying semantic similarity, while keyword search can be valuable when an exact product ID, name, or technical term matters.

21. Vector Search and RAG

One of the most important practical applications of vector search is Retrieval-Augmented Generation (RAG).

A simplified RAG architecture looks like this:

              DOCUMENT INGESTION
                     |
                     v
             Generate embeddings
                     |
                     v
             Azure Cosmos DB
          +----------------------+
          | Documents            |
          | Embeddings            |
          | Vector index          |
          +----------------------+

                     ^
                     |
              Vector retrieval
                     |
                     |
User question --> Generate embedding
                     |
                     v
             Vector similarity search
                     |
                     v
              Relevant documents
                     |
                     v
                  LLM
                     |
                     v
              Generated answer

The vector database is responsible for retrieving relevant information.

The LLM is responsible for generating the final response using that retrieved information.

This distinction is important.

Vector search retrieves information; the LLM generates the response.

22. Keeping Embeddings Synchronized

Suppose the source document changes:

			
Original document
       |
       v
Embedding A

The document is updated:

			
Updated document
       |
       v
Embedding A  <-- stale!

The embedding may no longer accurately represent the document.

Therefore, applications should have a mechanism to regenerate embeddings when source content changes.

Azure Cosmos DB’s change feed can be used as part of an architecture that detects changes and triggers embedding regeneration. The current AI-200 training material specifically includes change-feed processing for keeping embeddings synchronized.

A common architecture is:

			
Document updated
      |
      v
Cosmos DB change feed
      |
      v
Processing component
      |
      v
Generate new embedding
      |
      v
Update Cosmos DB item

		

23. Vector Index Limitations You Should Know

Several limitations are particularly relevant for the AI-200 exam.

Maximum dimensions

Current limits include:

flat: 505 dimensions
quantizedFlat: 4,096 dimensions
diskANN: 4,096 dimensions

Minimum vectors for quantizedFlat and diskANN

quantizedFlat and diskANN require at least 1,000 vectors for indexed vector searching. If fewer than 1,000 vectors are present, a full scan can be performed instead.

Shared throughput

Vector indexing and search currently aren’t supported on accounts using shared throughput.

Vector policy changes

Vector embedding and vector indexing policy settings aren’t simply modified in place. Depending on the specific configuration, the existing policy/index must be removed and recreated, or a new container may be required.

Vector search cannot simply be disabled

Once vector indexing and search are enabled on a container, it cannot simply be disabled.

24. Common Exam Traps

Trap 1: Confusing embeddings with indexes

An embedding is the numerical representation of content.

An index is the structure used to efficiently search those vectors.

Trap 2: Thinking Cosmos DB generates the embedding

Cosmos DB stores and searches embeddings.

An embedding model, such as an embedding API, generates the embedding.

Trap 3: Assuming `diskANN` is exact

diskANN is an approximate nearest-neighbor approach.

It is designed to provide excellent performance while maintaining high retrieval quality.

Trap 4: Assuming `quantizedFlat` is exact

Quantization can introduce a small loss of accuracy.

Trap 5: Forgetting `TOP N`

A vector search should generally use TOP N to avoid unnecessarily expensive retrieval.

Trap 6: Using `flat` for a 1,536-dimensional embedding

The current flat limit is 505 dimensions.

A 1,536-dimensional embedding requires a vector index type supporting that dimensionality, such as quantizedFlat or diskANN.

Trap 7: Treating vector search as keyword search

Vector search is based on semantic similarity, not exact text matching.

25. Exam-Focused Summary

For AI-200, remember this chain:

			
Source data
     |
     v
Embedding model
     |
     v
Vector embedding
     |
     v
Cosmos DB document
     |
     v
Vector embedding policy
     |
     v
Vector index
     |
     v
VectorDistance()
     |
     v
TOP N results
     |
     v
Semantic retrieval

		

The most important concepts are:

Concept	Remember
Embedding	Numerical representation of content
Vector store	Stores and retrieves embeddings
Vector embedding policy	Defines characteristics of vectors
Vector index	Makes vector searches more efficient
`flat`	Exact/brute-force; max 505 dimensions
`quantizedFlat`	Quantized; max 4,096 dimensions
`diskANN`	Approximate, efficient large-scale search; max 4,096 dimensions
`VectorDistance()`	Performs vector distance calculation
`TOP N`	Limits results and helps control RU/latency
Semantic search	Finds content by meaning
Metadata filtering	Narrows the search space
Hybrid search	Combines lexical and vector retrieval
RAG	Uses retrieved context to augment LLM generation
Change feed	Can trigger embedding refresh when data changes

Practice Exam Questions

Question 1

An AI application stores product descriptions in Azure Cosmos DB for NoSQL. The application needs to find products that are semantically similar to a user’s natural-language query.

What should the application do?

A. Store the product descriptions as strings and use CONTAINS() exclusively.

B. Generate embeddings for the product descriptions and store the vectors with the documents.

C. Convert each product description to a partition key.

D. Store each word as a separate Cosmos DB item.

Answer: B

Explanation:
Semantic retrieval requires converting content into vector embeddings. The embeddings can then be stored alongside the original documents in Cosmos DB and compared with a query embedding. Keyword functions such as CONTAINS() don’t provide semantic similarity.

Question 2

An application uses a 1,536-dimensional embedding model and needs an efficient vector index for a large production dataset.

Which vector index type is the most appropriate choice?

A. flat

B. hash

C. range

D. diskANN

Answer: D

Explanation:
diskANN supports vectors up to 4,096 dimensions and is designed for efficient approximate vector search at larger scales. flat is limited to 505 dimensions and therefore cannot index a 1,536-dimensional vector.

Question 3

An application needs the five most semantically similar documents to a query vector.

Which query pattern should be used?

			
SELECT *
FROM c
ORDER BY VectorDistance(c.embedding, @queryVector)

			
SELECT TOP 5 *
FROM c
ORDER BY c.embedding

			
SELECT TOP 5 *
FROM c
ORDER BY VectorDistance(c.embedding, @queryVector)

			
SELECT *
FROM c
WHERE c.embedding = @queryVector

Answer: C

Explanation:
VectorDistance() calculates the distance between the stored embedding and query vector. TOP 5 limits the results to the five most relevant documents and helps avoid unnecessary RU consumption and latency.

Question 4

Which statement best describes the purpose of a vector embedding?

A. It is a Cosmos DB authentication token.

B. It is the partition key automatically generated by Cosmos DB.

C. It is a numerical representation of the semantic characteristics of content.

D. It is an index containing document metadata.

Answer: C

Explanation:
An embedding is a numerical representation generated by an embedding model. Semantically related content tends to produce vectors that are close together in vector space.

Question 5

A company has a relatively small vector search workload and wants to use a vector index that compresses vectors to improve efficiency while accepting a possible small loss in accuracy.

Which index should it consider?

A. flat

B. quantizedFlat

C. diskANN

D. NoSQL range indexing

Answer: B

Explanation:
quantizedFlat compresses vectors before indexing. This can improve latency, throughput, and RU efficiency compared with flat, at the potential cost of some accuracy. It is particularly suited to smaller or more narrowly scoped searches.

Question 6

An application has documents containing both an embedding and a category property. It needs to find the most semantically similar documents, but only within the "finance" category.

Which approach is appropriate?

A. Perform a vector search without filtering and discard non-finance results afterward.

B. Store each category in a separate Cosmos DB account.

C. Use VectorDistance() together with a WHERE filter for the category.

D. Replace the embeddings with category names.

Answer: C

Explanation:
Vector search can be combined with traditional Cosmos DB query filters. The application can use a WHERE clause to restrict the search to documents matching the required metadata.

Question 7

A developer changes the text of a document but continues using the embedding that was generated from the old version.

What is the primary problem?

A. The partition key automatically changes.

B. The vector index is deleted.

C. The document becomes unreadable.

D. The embedding may no longer accurately represent the document.

Answer: D

Explanation:
An embedding represents the content used to generate it. If the source content changes substantially, the old embedding can become stale. Applications can use mechanisms such as the Cosmos DB change feed to detect changes and trigger embedding regeneration.

Question 8

Which statement correctly describes the flat vector index in Azure Cosmos DB for NoSQL?

A. It performs exact/brute-force vector search and supports vectors up to 505 dimensions.

B. It performs approximate DiskANN search and supports 4,096 dimensions.

C. It compresses vectors and always produces approximate results.

D. It is used only for keyword searches.

Answer: A

Explanation:
The flat index performs brute-force vector search and can provide exact nearest-neighbor results. Its current maximum vector dimensionality is 505.

Question 9

An AI application uses vector search as part of a RAG architecture.

What is the primary purpose of the vector search portion of the architecture?

A. Generate the final natural-language response.

B. Retrieve content that is semantically relevant to the user’s query.

C. Train the large language model.

D. Replace the embedding model.

Answer: B

Explanation:
Vector search retrieves relevant information based on semantic similarity. The retrieved content can then be supplied to an LLM as context for generating the final answer. Vector retrieval and LLM generation are separate responsibilities.

Question 10

A developer creates a vector search query that returns every matching document instead of limiting the result set. The application only needs the top 10 results.

What should the developer change?

A. Remove the vector index.

B. Increase the embedding dimensionality.

C. Add a TOP 10 clause to the query.

D. Replace VectorDistance() with CONTAINS().

Answer: C

Explanation:
Vector searches should generally use TOP N to limit the number of returned results. Returning more results than the application needs can increase RU consumption and latency.

Final Exam Takeaways

If you remember only a handful of things from this topic, remember these:

Embeddings represent the semantic characteristics of content numerically.
An embedding model generates the embedding; Cosmos DB stores and searches it.
Embeddings can be stored alongside the original Cosmos DB document.
VectorDistance() is the key function for vector similarity searches.
Use TOP N when performing vector retrieval.
flat provides exact/brute-force search but is limited to 505 dimensions.
quantizedFlat provides a more efficient quantized approach for smaller/scoped searches.
diskANN is designed for efficient approximate search at larger scales and supports up to 4,096 dimensions.
Vector search can be combined with metadata filters and hybrid search.
Vector retrieval is a fundamental building block for RAG applications.
When source content changes, embeddings may need to be regenerated.
For AI-200 scenario questions, pay close attention to the dataset size, vector dimensionality, accuracy requirements, RU consumption, and latency requirements when selecting a vector index.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Databases, Microsoft Certification, NoSQL August 15, 2026

Optimize query performance and Request Units (RUs) consumption by using indexing policies and consistency levels (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Cosmos DB for NoSQL
      --> Optimize query performance and Request Units (RUs) consumption by using indexing policies and consistency levels

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Cosmos DB for NoSQL is designed to provide globally distributed, low-latency access to JSON data at scale. A key part of developing efficient Cosmos DB solutions is understanding how queries consume Request Units (RUs) and how indexing policies and consistency levels affect query performance, throughput, latency, and cost.

For the AI-200 exam, you should understand how to:

Explain what RUs represent.
Identify factors that increase or decrease RU consumption.
Understand how indexes improve query performance.
Configure indexing policies.
Include or exclude property paths from indexing.
Understand range and composite indexes.
Recognize when a query is likely to require a full scan.
Understand the relationship between partition keys and query performance.
Understand the five Cosmos DB consistency levels.
Choose an appropriate consistency level based on application requirements.
Understand how consistency affects read throughput.
Use query metrics to investigate expensive queries.

A useful way to think about optimization is:

Efficient Cosmos DB queries minimize the amount of data that must be examined and returned while using an indexing and consistency strategy appropriate for the application’s requirements.

1. Understanding Request Units (RUs)

Azure Cosmos DB uses Request Units (RUs) as a normalized measure of the resources required to perform database operations.

Instead of pricing or throttling individual operations according to CPU time, disk operations, memory, and other implementation details, Cosmos DB abstracts those resources into RUs.

For example, operations such as:

Creating an item
Reading an item
Updating an item
Deleting an item
Running a query

consume RUs.

The amount of RU consumption depends on the work required to perform the operation.

Important exam concept

The number of items returned is not the only factor determining RU consumption.

A query can return a small number of items while still consuming significant RUs if Cosmos DB has to examine a large amount of data.

Conversely, an efficiently indexed query may examine a relatively small amount of data and consume fewer RUs.

2. What Determines RU Consumption?

Several factors influence the RU charge of a request.

Common factors include:

Size of the items being read or written
Number of items involved
Number of properties being indexed
Query complexity
Whether indexes can be used efficiently
Whether the query is single-partition or cross-partition
Number of partitions involved
Amount of data returned
Consistency level
Type of operation

For example, consider:

			
SELECT *
FROM c
WHERE c.customerId = "C1001"

If customerId is efficiently indexed and the query can target the appropriate partition, the query can be relatively inexpensive.

A query such as:

			
SELECT *
FROM c
WHERE c.description = "some value"

may be considerably more expensive if the query requires examining many partitions or cannot efficiently use an appropriate index.

3. Why Indexing Matters

Azure Cosmos DB for NoSQL automatically indexes properties by default.

This means developers generally don’t have to create indexes manually before executing common queries.

The default indexing policy indexes every property of every item, using range indexes for string and numeric values.

This default behavior provides good general-purpose query performance.

However, an application may benefit from a custom indexing policy.

For example, suppose documents contain:

			
{
    "id": "1001",
    "customerId": "C1001",
    "name": "Norm",
    "description": "...",
    "largeMetadata": {
        "property1": "...",
        "property2": "...",
        "property3": "..."
    }
}

		

If the application frequently queries:

WHERE c.customerId = "C1001"

but never queries largeMetadata, indexing every property may provide little benefit while increasing index storage and indexing work.

A custom indexing policy can exclude paths that aren’t needed for queries.

4. Indexing and Write Costs

Indexes aren’t free.

When an item is created or modified, Cosmos DB must maintain the indexes associated with that item.

Therefore, extensive indexing can increase:

Write RU consumption
Index storage
Index maintenance work

This creates an important optimization tradeoff:

Strategy	Potential benefit	Potential cost
Index many properties	Better query flexibility	More index storage and write overhead
Index fewer properties	Lower indexing overhead	Some queries may require scans
Use composite indexes	Efficient supported multi-property queries	Additional index maintenance
Use default policy	Simple and broadly effective	May index properties the application never queries

The goal isn’t to minimize indexes at all costs.

The goal is to index the paths required by the application’s query workload.

5. Indexing Modes

Azure Cosmos DB for NoSQL supports indexing modes that determine how indexes are maintained.

The important mode for normal querying is:

Consistent

The index is updated synchronously as items are created, updated, or deleted.

This provides predictable query behavior and is the normal indexing mode for queryable containers.

A container can also have indexing disabled by setting the indexing mode to none.

This can be useful for workloads where secondary indexing isn’t needed, such as certain key-value-style scenarios or some bulk-loading scenarios.

However, queries against a container without the necessary indexes may require scans and can therefore consume significantly more RUs.

6. Included and Excluded Paths

One of the most important ways to customize an indexing policy is through included paths and excluded paths.

An indexing policy can essentially answer:

Which JSON properties should Cosmos DB index?

For example:

			
{
    "indexingMode": "consistent",
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/largeMetadata/*"
        }
    ]
}

		

This approach indexes the document generally while excluding a portion that isn’t queried.

A useful rule is:

Exclude properties that don’t need to participate in queries, especially large or frequently changing properties, when doing so is appropriate for the workload.

The indexing-policy documentation recommends using an include-root/exclude-specific-path strategy when you want new properties added to the data model to be indexed automatically unless explicitly excluded.

7. The Partition Key Is Critical to Query Performance

Indexing alone does not guarantee an inexpensive query.

The partition key is also extremely important.

Consider a container partitioned by:

/customerId

A query such as:

			
SELECT *
FROM c
WHERE c.customerId = "C1001"

can potentially be targeted to a single logical partition.

Compare that with:

			
SELECT *
FROM c
WHERE c.city = "Orlando"

If city isn’t the partition key, Cosmos DB may need to execute the query across multiple partitions.

This is called a cross-partition query.

Cross-partition queries can consume more RUs because multiple partitions may need to participate.

Exam takeaway

When analyzing a query, don’t ask only:

“Is the property indexed?”

Also ask:

“Can the query be directed to the appropriate partition?”

A well-designed partition key and appropriate indexing policy work together.

8. Partition Key Indexing

There is an important detail that can appear in exam questions.

A partition key property isn’t automatically indexed merely because it is the partition key.

If the partition key isn’t /id, it should generally be included in the indexing policy when queries filter on it. Otherwise, queries using that property can be forced into full scans, increasing RU consumption.

For example, if the partition key is:

/customerId

and the application frequently queries:

WHERE c.customerId = "C1001"

the indexing policy should support that path.

9. Types of Indexes

Azure Cosmos DB supports several index types.

For AI-200, you should understand at least the major concepts surrounding:

Range indexes
Composite indexes
Spatial indexes
Vector indexes

The most important indexes for traditional query optimization are range and composite indexes.

10. Range Indexes

Range indexes are based on an ordered structure and can support many common query operations.

They can support operations such as:

>=

<=

as well as certain ORDER BY, JOIN, and string-function scenarios.

For example:

			
SELECT *
FROM c
WHERE c.price > 100

can benefit from an appropriate range index on price.

Similarly:

			
SELECT *
FROM c
ORDER BY c.price

requires a range index on the ordered property.

11. Composite Indexes

A composite index indexes multiple properties together.

Composite indexes are particularly useful for queries involving multiple properties and certain combinations of filtering and sorting.

For example:

			
SELECT *
FROM c
WHERE c.category = "AI"
ORDER BY c.timestamp DESC

may benefit from an appropriate composite index involving:

			
/category
/timestamp

The order of properties in a composite index matters.

For example, these are not necessarily interchangeable:

(category ASC, timestamp DESC)

and:

(timestamp DESC, category ASC)

The appropriate ordering depends on the query workload.

Exam tip

If a question describes a query using multiple properties with filtering and/or ordering, think:

Could a composite index make this query more efficient?

12. Index Utilization

Cosmos DB’s query engine can use indexes in different ways.

The query engine can perform operations ranging from highly efficient index seeks to full scans.

Generally, the progression is:

Index seek
Precise index scan
Expanded index scan
Full index scan
Full scan

An index seek is particularly efficient because the query engine can identify the relevant index entries without examining the entire dataset.

A full scan is considerably more expensive because Cosmos DB must inspect the underlying data rather than efficiently locating matching records through an appropriate index.

13. Why `SELECT *` Can Cost More

The amount of data returned affects RU consumption.

Consider:

			
SELECT *
FROM c
WHERE c.customerId = "C1001"

versus:

			
SELECT c.id, c.name
FROM c
WHERE c.customerId = "C1001"

The second query may consume fewer RUs because it returns less data.

This leads to an important optimization principle:

Return only the properties your application needs.

Avoid retrieving large documents when only a few properties are required.

14. Avoid Unnecessary Cross-Partition Queries

Suppose a container has:

Partition key: /customerId

This query can potentially target a partition:

			
SELECT c.id, c.name
FROM c
WHERE c.customerId = "C1001"

But this query may involve many partitions:

			
SELECT c.id, c.name
FROM c
WHERE c.status = "Active"

If status isn’t the partition key, Cosmos DB may need to query multiple partitions.

Cross-partition queries aren’t inherently bad.

They are sometimes necessary.

The important point is:

Don’t accidentally create expensive cross-partition queries when the application can supply the partition key.

15. Measuring Query RU Consumption

The Cosmos DB SDKs provide information about the RU charge associated with operations.

For example, application code can inspect the response from a query and determine how many RUs were consumed.

This is valuable because optimization should be based on actual workload measurements rather than assumptions.

When troubleshooting an expensive query, examine:

RU charge
Query execution time
Number of returned documents
Index utilization
Number of partitions involved
Query predicates
Requested properties
Partition-key usage

16. Index Transformation

Changing an indexing policy can cause Cosmos DB to perform an index transformation.

For example, adding an indexed path requires Cosmos DB to build the new index for existing data.

Index transformation is asynchronous and consumes RUs. Queries begin using a newly added indexed path after the index transformation has completed.

This is important operationally.

If you replace one index with another, a good strategy is generally:

Add the new index.
Wait for the transformation to complete.
Verify the workload.
Remove the old index if it is no longer required.

Removing an indexed path takes effect immediately, so removing an index before the replacement is ready can temporarily cause queries to fall back to scans.

17. Understanding Consistency Levels

Indexing affects how efficiently data can be located.

Consistency affects what version of the data a read is allowed to return.

Azure Cosmos DB provides five consistency levels, ordered from strongest to weakest:

Strong
Bounded staleness
Session
Consistent prefix
Eventual

Choosing the consistency level is a business and application decision.

You should not automatically select the strongest consistency level.

18. Strong Consistency

Strong consistency guarantees that reads return the latest committed version of the data.

This provides the strongest read guarantee.

The tradeoff is that strong consistency can increase write latency and reduce availability in some globally distributed scenarios because replicas must satisfy the stronger synchronization requirements.

Appropriate scenarios

Strong consistency may be appropriate for scenarios where stale data is unacceptable, such as:

Certain financial transactions
Critical inventory decisions
Applications requiring immediate globally consistent reads

Exam clue

If a question says:

“The application must always read the most recently committed value.”

Think:

Strong consistency.

19. Bounded Staleness

Bounded staleness guarantees that reads aren’t allowed to become older than a configured limit based on:

Time
Number of versions/operations

This is useful when the application can tolerate a controlled amount of replication lag but needs a stronger guarantee than eventual consistency.

For example:

“Data can be up to a few seconds old, but never older than that.”

This points toward bounded staleness.

Bounded staleness is particularly relevant to globally distributed applications that need near-strong consistency without the full cost of strong consistency.

20. Session Consistency

Session consistency is commonly useful for interactive applications.

It provides guarantees such as:

Read-your-writes
Monotonic reads
Monotonic writes

In practical terms, a user who writes data should be able to read that data within the same session.

For example:

User updates their profile.
User immediately refreshes the profile.
The application should see the user’s update.

Session consistency is often a good balance between strong consistency and scalability.

21. Consistent Prefix

Consistent prefix guarantees that reads see writes in the order they occurred, without observing them out of sequence.

The application may not immediately see every write, but it won’t see writes in an inconsistent order.

For example, suppose writes occur in this order:

A → B → C → D

A reader might see:

			
A
A, B
A, B, C
A, B, C, D

but shouldn’t see:

A, C

while missing B.

22. Eventual Consistency

Eventual consistency provides the weakest consistency guarantee.

Different replicas may temporarily return different values, but replicas eventually converge.

The major advantages include:

Lower coordination requirements
High availability
Good performance
Lower latency in many distributed scenarios

Eventual consistency may be appropriate for:

Social feeds
Recommendation systems
Analytics dashboards
Non-critical status information
Content where temporary staleness is acceptable

23. Consistency and Read Throughput

Consistency isn’t simply about correctness.

It can also affect read throughput.

For strong and bounded staleness consistency, reads are performed against two replicas in a four-replica set to satisfy the consistency guarantees.

Session, consistent prefix, and eventual consistency use single-replica reads.

Consequently, for the same number of provisioned RUs, strong and bounded staleness consistency provide approximately half the read throughput of the weaker consistency levels.

This is a very important AI-200 exam concept.

Remember:

Stronger consistency can consume more read capacity.

Therefore, if an application does not require strong consistency, relaxing the consistency requirement can improve read scalability.

24. Consistency Does Not Change Write RU Charges

For the same type of write operation, write RU consumption is generally identical across consistency levels.

However, stronger consistency can have other performance implications, particularly around replication and latency.

Therefore, don’t confuse:

Consistency → read behavior and read throughput

with:

Indexing → query efficiency and index maintenance

Both affect application performance, but in different ways.

25. Choosing the Right Consistency Level

A useful decision framework is:

Requirement	Recommended consideration
Must always see the latest committed value	Strong
Can tolerate a precisely bounded amount of staleness	Bounded staleness
Users need read-your-writes behavior	Session
Writes must appear in order but can be delayed	Consistent prefix
Temporary inconsistency is acceptable	Eventual

The key is to choose the weakest consistency level that still satisfies the application’s requirements.

This can improve scalability and reduce unnecessary coordination.

26. Combining Indexing and Consistency Optimization

Indexing and consistency should be considered separately.

Suppose an application has an expensive query.

You might investigate:

Indexing

Is the filtered property indexed?
Is an appropriate range index available?
Is a composite index appropriate?
Is the partition key included in the indexing policy?
Is the query performing a full scan?
Are unnecessary properties being indexed?

Query design

Is the partition key supplied?
Is the query unnecessarily cross-partition?
Is SELECT * returning unnecessary data?
Can the query be simplified?

Consistency

Does the application actually require strong consistency?
Could session consistency satisfy the requirement?
Could eventual consistency satisfy the requirement?

This distinction is important:

Don’t try to solve every RU problem by changing the indexing policy.

Likewise:

Don’t weaken consistency when the application actually requires stronger guarantees.

27. A Practical Optimization Example

Imagine an AI-powered customer-support application.

The container contains millions of support conversations.

The partition key is:

/customerId

The application runs:

			
SELECT *
FROM c
WHERE c.customerId = "C1001"
AND c.status = "Open"
ORDER BY c.createdDate DESC

		

Several optimization questions should be considered.

Question 1: Can the query target a partition?

Yes.

It specifies:

customerId = C1001

which is the partition key.

Question 2: Are the relevant properties indexed?

The query uses:

			
customerId
status
createdDate

The indexing policy should support the query.

Question 3: Would a composite index help?

Potentially.

The query combines filtering and sorting across multiple properties, so a composite index may be appropriate depending on the exact query workload and index requirements.

Question 4: Does the application need every property?

Perhaps not.

Instead of:

SELECT *

the application could retrieve only:

SELECT c.id, c.status, c.createdDate, c.subject

Question 5: Does the application need strong consistency?

If the support application can tolerate some temporary staleness, a weaker consistency level may provide better read scalability.

This illustrates an important principle:

Query performance is usually the result of several design decisions working together.

28. Common AI-200 Exam Traps

Trap 1: “Indexes always reduce RU consumption.”

Not necessarily.

Indexes can reduce the amount of data that must be examined for queries, but maintaining indexes also adds write and storage overhead.

Trap 2: “The partition key automatically makes the property indexed.”

Not necessarily.

The partition key should be considered separately from the indexing policy. A partition key property should be included in the indexing policy when queries need to efficiently filter on it.

Trap 3: “Strong consistency is always better.”

Strong consistency provides stronger guarantees, but it can reduce read throughput and increase latency/availability tradeoffs.

Choose it only when required.

Trap 4: “Eventual consistency means data is permanently inconsistent.”

No.

Eventual consistency means replicas may temporarily disagree, but they eventually converge.

Trap 5: “A query returning one item must be inexpensive.”

Not necessarily.

Cosmos DB may have to examine many items or partitions to discover that single matching item.

Trap 6: “Cross-partition queries are always wrong.”

No.

Cross-partition queries are sometimes necessary.

The goal is to avoid unnecessary cross-partition queries and design the partition key appropriately for the workload.

Trap 7: “Removing an index is harmless.”

Removing an index can cause queries that depended on it to fall back to less efficient execution, potentially increasing RU consumption.

29. AI-200 Exam Quick Reference

Concept	Remember
RU	Normalized unit of Cosmos DB resource consumption
Index	Helps locate matching data efficiently
Default indexing	Automatically indexes properties by default
Custom indexing	Can include/exclude paths
Range index	Equality, range, ordering, and other supported operations
Composite index	Multiple-property query patterns
Full scan	Potentially expensive; examines underlying data broadly
Partition key	Determines data distribution and can enable targeted queries
Cross-partition query	May require querying multiple partitions
`SELECT *`	Can return more data and increase RU consumption
Strong consistency	Latest committed value
Bounded staleness	Controlled maximum staleness
Session	Read-your-writes and session guarantees
Consistent prefix	Writes observed in order
Eventual	Temporary inconsistency allowed
Strong/bounded read throughput	Lower than weaker levels for same RU allocation
Index transformation	Asynchronous and consumes RUs
Best practice	Choose indexes and consistency based on workload requirements

Practice Exam Questions

Question 1

An application stores customer records in Azure Cosmos DB for NoSQL. The container is partitioned by /customerId. The application frequently executes the following query:

			
SELECT *
FROM c
WHERE c.customerId = "C1005"

The developer wants to minimize RU consumption.

Which approach is most appropriate?

A. Add a spatial index to the customerId property.

B. Disable indexing so the query engine can scan the container faster.

C. Change the consistency level to Strong regardless of the application’s requirements.

D. Ensure the customerId path is appropriately indexed and provide the partition key value when executing the query.

Answer: D

Explanation

The query uses the partition key, allowing Cosmos DB to target the appropriate logical partition. The property should also be appropriately indexed when queries filter on it. This combination can significantly improve query efficiency.

Disabling indexing would generally make query execution less efficient. Spatial indexes are intended for geospatial data, not customer identifiers. Strong consistency does not inherently optimize this query.

Question 2

A globally distributed application displays product recommendations. Recommendations can be temporarily stale as long as replicas eventually converge.

Which consistency level is generally the most appropriate?

A. Strong

B. Bounded staleness

C. Session

D. Eventual

Answer: D

Explanation

The application explicitly permits temporary staleness and does not require read-your-writes or strict ordering guarantees. Eventual consistency is therefore appropriate.

Strong consistency provides stronger guarantees than necessary. Bounded staleness provides a specific staleness guarantee that isn’t required by the scenario. Session consistency would provide stronger session-level guarantees than needed.

Question 3

A Cosmos DB container contains documents with hundreds of properties. An application queries only /customerId, /status, and /createdDate. Many large metadata properties are never queried.

The development team wants to reduce indexing overhead and index storage.

What should they consider?

A. Enable strong consistency.

B. Customize the indexing policy to exclude properties that don’t need to be queried.

C. Remove the partition key.

D. Replace all range indexes with spatial indexes.

Answer: B

Explanation

A custom indexing policy can exclude properties that don’t participate in queries. This can reduce index size and indexing maintenance overhead.

Changing consistency doesn’t address unnecessary indexes. Removing the partition key is not an appropriate optimization, and spatial indexes aren’t appropriate for ordinary scalar properties such as customer IDs and status values.

Question 4

An application requires that a user immediately see an item after the user creates it, but the application does not require globally strong consistency for every user.

Which consistency level is generally the best fit?

A. Eventual

B. Consistent prefix

C. Session

D. Strong

Answer: C

Explanation

Session consistency provides read-your-writes behavior and is well suited to interactive applications where a user expects to see their own changes.

Eventual consistency doesn’t provide the same session guarantees. Consistent prefix guarantees write ordering but doesn’t provide the same read-your-writes behavior. Strong consistency is stronger than necessary for the stated requirement.

Question 5

A query returns only one document but consumes a surprisingly large number of RUs. The query doesn’t specify the partition key and runs against a container with many physical partitions.

What is the most likely explanation?

A. Cosmos DB charges a fixed RU amount for every returned document.

B. The query must always use a spatial index.

C. The query may be executing across multiple partitions and examining significant amounts of data before finding the matching document.

D. Returning one document always requires Strong consistency.

Answer: C

Explanation

The number of returned documents isn’t the only determinant of RU consumption. A cross-partition query can require Cosmos DB to examine multiple partitions, potentially consuming significant RUs even if only one document ultimately matches.

There is no fixed RU charge per returned document, spatial indexing is unrelated, and consistency doesn’t automatically become Strong because one document is returned.

Question 6

A query uses:

			
SELECT *
FROM c
WHERE c.category = "AI"
ORDER BY c.timestamp DESC

The application frequently executes this query and wants to optimize its performance.

Which index type should the developer investigate first?

A. Composite index

B. Spatial index

C. Vector index

D. No index; ORDER BY queries cannot use indexes

Answer: A

Explanation

The query uses multiple properties in filtering and ordering. A composite index can be useful for query patterns involving multiple properties and sorting.

Spatial indexes are designed for geospatial operations. Vector indexes are designed for vector search. Cosmos DB can use indexes for ORDER BY operations.

Question 7

An application currently uses Strong consistency. Performance testing shows that read throughput is insufficient. The application requirements state that users only need read-your-writes behavior within their own sessions.

What should the developer consider?

A. Add a spatial index.

B. Change the partition key to /id without analyzing the workload.

C. Disable all indexes.

D. Use Session consistency if it satisfies the application’s requirements.

Answer: D

Explanation

Session consistency provides read-your-writes behavior and other session-level guarantees while avoiding the stronger coordination requirements of Strong consistency.

Changing the partition key or disabling indexes doesn’t directly address the stated consistency requirement. Spatial indexing is unrelated.

Question 8

A developer removes an indexed path from a Cosmos DB indexing policy because the property is no longer queried. An existing query unexpectedly begins consuming substantially more RUs.

What is the most likely explanation?

A. Removing an indexed path causes all writes to become strongly consistent.

B. The query may no longer be able to use the removed index and may fall back to a less efficient scan.

C. Removing an index automatically converts the container into a different API.

D. Cosmos DB stops supporting partitioning when an index is removed.

Answer: B

Explanation

When an indexed path is removed, queries that relied on that index may no longer be able to use it and can fall back to a full scan or another less efficient execution strategy. This can substantially increase RU consumption.

The other options describe behaviors that don’t occur as a result of removing an indexed path.

Question 9

A company wants to ensure that reads never return a value older than a configured amount of time or number of updates, but it doesn’t require Strong consistency.

Which consistency level should the developer select?

A. Eventual

B. Session

C. Bounded staleness

D. Consistent prefix

Answer: C

Explanation

Bounded staleness is specifically designed for scenarios where the application can tolerate a controlled amount of staleness based on time or the number of versions/operations.

Eventual consistency provides no such bounded staleness guarantee. Session consistency focuses on session-level guarantees, while consistent prefix guarantees write ordering rather than a specific staleness bound.

Question 10

A Cosmos DB account has a workload dominated by read operations. The application doesn’t require Strong or Bounded Staleness consistency. The team wants to maximize read throughput for the same provisioned RU capacity.

Which approach is most appropriate?

A. Use Session, Consistent Prefix, or Eventual consistency according to the application’s requirements.

B. Increase indexing on every possible property.

C. Change every query to SELECT *.

D. Use Strong consistency for all queries.

Answer: A

Explanation

Strong and Bounded Staleness consistency use more replicas for reads and therefore provide approximately half the read throughput of Session, Consistent Prefix, and Eventual consistency for the same RU allocation.

If the application doesn’t require the stronger guarantees, using an appropriate weaker consistency level can improve read scalability.

Increasing indexes can help particular queries but doesn’t address the consistency-related read-throughput issue. SELECT * can actually increase data returned and RU consumption, while Strong consistency would move in the opposite direction from the desired optimization.

Final Exam Takeaways

For AI-200, the most important concepts to remember are:

RUs represent the resources consumed by Cosmos DB operations.
Indexes can make queries substantially more efficient, but maintaining indexes has a cost.
The default indexing policy indexes properties automatically.
Custom indexing policies can include or exclude property paths.
Range indexes support many common equality, range, and ordering operations.
Composite indexes are important for appropriate multi-property query patterns.
A partition-key-aware query is generally more efficient than an unnecessary cross-partition query.
The partition key should be considered separately from indexing.
Returning unnecessary data, such as with SELECT *, can increase RU consumption.
Strong consistency provides the strongest read guarantee but has performance and availability tradeoffs.
Bounded staleness provides a controlled staleness guarantee.
Session consistency provides important read-your-writes behavior for interactive applications.
Consistent prefix preserves write ordering.
Eventual consistency provides the weakest guarantees but can maximize scalability and availability.
Strong and bounded staleness provide lower read throughput for the same RU allocation than Session, Consistent Prefix, and Eventual consistency.
Index transformations consume RUs and occur asynchronously.
When optimizing Cosmos DB, consider the combination of partitioning, indexing, query design, returned data, and consistency—not any one factor in isolation.

Go to the AI-200 Exam Prep Hub main page

azure, Databases, Microsoft Certification August 15, 2026

Connect to Azure Cosmos DB for NoSQL by using the SDK and run queries (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Cosmos DB for NoSQL
      --> Connect to Azure Cosmos DB for NoSQL by using the SDK and run queries

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Cosmos DB for NoSQL is a globally distributed, fully managed NoSQL database service designed for applications that require flexible schemas, low-latency access, and elastic scalability.

For the AI-200 exam, developers should understand how to:

Connect applications to Azure Cosmos DB for NoSQL.
Use the Azure Cosmos DB SDK.
Authenticate securely.
Create and access databases and containers.
Define partition keys.
Insert, read, update, and delete items.
Construct SQL queries for Cosmos DB.
Execute queries through the SDK.
Work with query parameters.
Understand partition-aware querying.
Process query results efficiently.
Recognize common performance considerations.

The key concept is that Azure Cosmos DB for NoSQL exposes a SQL-like query language, while the SDK provides the programming interface through which an application connects to the service and executes those queries.

1. Understanding the Azure Cosmos DB for NoSQL Data Model

Before connecting with an SDK, it is important to understand the hierarchy used by Azure Cosmos DB.

The basic structure is:

Cosmos DB account → Database → Container → Item

Cosmos DB account

The account is the top-level Azure resource. It provides the endpoint through which applications communicate with Cosmos DB.

An account contains one or more databases.

Database

A database provides a logical grouping of containers.

For example:

			
AI200CosmosAccount
    └── CustomerDatabase

Container

A container is where items are stored.

A container is roughly analogous to a table in a relational database, although it is much more flexible because Cosmos DB items can have different structures.

			
CustomerDatabase
    ├── Customers
    ├── Orders
    └── Products

A container also defines the partition key path, which is extremely important for scalability and query performance.

Item

An item is a JSON document.

For example:

			
{
    "id": "customer-1001",
    "customerName": "John Smith",
    "country": "US",
    "email": "john@example.com",
    "loyaltyLevel": "Gold"
}

		

Unlike a relational table, another item in the same container could contain additional properties.

2. Connecting to Azure Cosmos DB

An application needs two primary pieces of information to connect to a Cosmos DB account:

The Cosmos DB account endpoint.
A supported authentication mechanism.

A typical endpoint looks conceptually like:

https://<account-name>.documents.azure.com:443/

The SDK uses this endpoint to communicate with the Cosmos DB service.

3. Authentication

Authentication is an important exam topic because applications should avoid embedding long-lived credentials directly in source code.

Several authentication approaches are available, including:

Microsoft Entra ID-based authentication.
Managed identities.
Account keys.
Connection strings.

For production Azure applications, Microsoft Entra ID with managed identity is generally preferable when supported by the application’s architecture because credentials do not need to be stored in application configuration or source code.

For example, an application running on an Azure service can use its managed identity to authenticate to Cosmos DB.

The conceptual flow is:

			
Application
     │
     │ Managed identity
     ▼
Microsoft Entra ID
     │
     │ Token
     ▼
Azure Cosmos DB

		

Exam point

If a question asks for the most secure way for an Azure-hosted application to authenticate to Cosmos DB without storing credentials, look for an answer involving:

Microsoft Entra ID + managed identity + appropriate Cosmos DB data-plane permissions.

4. Using the Azure Cosmos DB SDK

Microsoft provides SDKs for several programming languages, including:

.NET
Java
JavaScript/TypeScript
Python

The SDK provides classes and methods for interacting with Cosmos DB.

For example, a .NET application can use the Azure Cosmos DB SDK package.

A simplified connection looks like:

			
var client = new CosmosClient(
    endpoint,
    credential);

The CosmosClient represents the client connection to the Cosmos DB account.

Applications can then access databases and containers through the client.

Conceptually:

			
CosmosClient
     │
     └── Database
           │
           └── Container
                 │
                 ├── Create item
                 ├── Read item
                 ├── Replace item
                 ├── Delete item
                 └── Query items

		

5. Reuse the CosmosClient

A common application-design mistake is creating a new CosmosClient for every database operation.

Instead, applications should generally create and reuse a single CosmosClient instance for the lifetime of the application.

For example:

			
private static CosmosClient client = new CosmosClient(
    endpoint,
    credential);

The SDK manages connections internally.

Creating clients repeatedly can cause unnecessary connection overhead and negatively affect performance.

Exam tip

If a question presents code that creates a new CosmosClient for every request, consider whether the question is testing your knowledge of client reuse.

Reuse the client rather than repeatedly creating new instances.

6. Accessing a Database

Once the client has been created, the application can obtain a reference to a database.

For example:

Database database = client.GetDatabase("CustomerDatabase");

This does not necessarily mean that the database has been created.

It obtains a client-side reference to the database.

If the database needs to be created, the SDK provides methods such as:

			
DatabaseResponse response =
    await client.CreateDatabaseIfNotExistsAsync("CustomerDatabase");

The CreateIfNotExists pattern is useful when an application should create the resource only when necessary.

7. Accessing a Container

After obtaining a database reference, the application can access a container:

			
Container container =
    database.GetContainer("Customers");

As with GetDatabase(), obtaining a container reference does not mean that the container has been created.

A container can be created when necessary:

			
ContainerResponse response =
    await database.CreateContainerIfNotExistsAsync(
        "Customers",
        "/country");

The second parameter specifies the partition key path.

In this example:

/country

is the partition key path.

8. Partition Keys

Partitioning is fundamental to Cosmos DB.

A container distributes its items across physical partitions based on the configured partition key.

For example:

			
{
    "id": "customer-1001",
    "country": "US",
    "name": "John Smith"
}

		

If /country is the partition key path, the value:

US

determines the logical partition to which the item belongs.

A good partition key should generally provide:

High cardinality.
Even distribution.
Sufficient request-volume distribution.
Values that match common access patterns.

Why this matters for queries

If a query includes the partition key value, Cosmos DB can often limit the query to the relevant partition rather than querying every partition.

This is called a single-partition query or targeted query, depending on the scenario.

A query that does not provide a partition key value may require a cross-partition query.

9. Creating Items

Items are JSON documents.

A .NET application can create an item using the SDK:

			
var customer = new
{
    id = "customer-1001",
    country = "US",
    name = "John Smith",
    loyaltyLevel = "Gold"
};
ItemResponse<dynamic> response =
    await container.CreateItemAsync(
        customer,
        new PartitionKey("US"));

		

The partition key value supplied to the SDK should correspond to the item’s partition key.

For a container partitioned on:

/country

the request should specify:

new PartitionKey("US")

10. Reading an Item

When the application’s partition key and item ID are known, the SDK can directly retrieve an item.

For example:

			
ItemResponse<Customer> response =
    await container.ReadItemAsync<Customer>(
        "customer-1001",
        new PartitionKey("US"));

This is generally much more efficient than querying for the item because Cosmos DB can directly address the item using its ID and partition key.

Important distinction

Consider these two operations:

ReadItem(id, partitionKey)

versus:

SELECT * FROM c WHERE c.id = "customer-1001"

The point read supplies both the item ID and partition key and is the preferred operation when those values are known.

Exam tip

If a question asks how to retrieve one known item as efficiently as possible, look for:

Point read using the item’s ID and partition key.

11. Updating Items

The SDK supports updating existing items.

Depending on the required behavior, developers can use operations such as:

Replace
Upsert
Patch

Replace

Replace generally replaces the entire item.

Upsert

Upsert means:

Update the item if it exists; otherwise create it.

For example:

			
await container.UpsertItemAsync(
    customer,
    new PartitionKey("US"));

Patch

Patch modifies selected properties without requiring the application to replace the entire document.

For example, an application might update only:

loyaltyLevel

rather than sending the entire customer document.

This can reduce the amount of data transmitted and simplify partial updates.

12. Deleting Items

An item can be deleted using its ID and partition key:

			
await container.DeleteItemAsync<Customer>(
    "customer-1001",
    new PartitionKey("US"));

Again, knowing both the ID and partition key allows Cosmos DB to directly identify the item.

13. Querying Azure Cosmos DB for NoSQL

Cosmos DB for NoSQL uses a SQL-like query language.

A simple query is:

SELECT * FROM c

The c represents each item being queried.

For example:

			
SELECT *
FROM c
WHERE c.country = "US"

This returns items whose country property is US.

14. Selecting Specific Properties

Applications don’t always need the entire document.

Instead of:

			
SELECT *
FROM c

you can select specific properties:

			
SELECT
    c.id,
    c.name,
    c.email
FROM c

		

This can reduce the amount of data returned to the application.

It can also make the application’s intent clearer.

15. Filtering Results

The WHERE clause filters documents.

For example:

			
SELECT *
FROM c
WHERE c.loyaltyLevel = "Gold"

Multiple conditions can be combined:

			
SELECT *
FROM c
WHERE c.country = "US"
AND c.loyaltyLevel = "Gold"

Other operators include:

			
=
!=
<
>
<=
>=
AND
OR

		

16. Parameterized Queries

Applications should avoid constructing queries by concatenating user input into SQL strings.

For example, this pattern should be avoided:

			
string query =
    "SELECT * FROM c WHERE c.name = '" + userName + "'";

Instead, use parameterized queries.

For example:

			
var query = new QueryDefinition(
    "SELECT * FROM c WHERE c.name = @name")
    .WithParameter("@name", userName);

This approach:

Separates query structure from values.
Helps prevent injection-style problems.
Makes query reuse easier.
Provides cleaner application code.

17. Executing a Query

The SDK provides query APIs that allow the application to execute a QueryDefinition.

For example:

			
var query = new QueryDefinition(
    "SELECT * FROM c WHERE c.country = @country")
    .WithParameter("@country", "US");
using FeedIterator<Customer> iterator =
    container.GetItemQueryIterator<Customer>(query);
while (iterator.HasMoreResults)
{
    FeedResponse<Customer> response =
        await iterator.ReadNextAsync();
    foreach (Customer customer in response)
    {
        Console.WriteLine(customer.name);
    }
}

		

This demonstrates an important concept:

Cosmos DB queries can return results in multiple pages.

18. FeedIterator and Pagination

A query may return more data than can reasonably be delivered in one response.

The SDK therefore exposes query results through an iterator.

Conceptually:

			
Query
  │
  ▼
Page 1
  │
  ▼
Page 2
  │
  ▼
Page 3
  │
  ▼
...

		

The application checks:

iterator.HasMoreResults

and retrieves each page using:

await iterator.ReadNextAsync()

This is important for scalability.

Exam tip

If a question asks how to process a potentially large Cosmos DB query result set, look for an answer involving:

FeedIterator / paginated results rather than loading the entire result set into memory.

19. Cross-Partition Queries

Suppose a container uses:

/country

as its partition key.

A query such as:

			
SELECT *
FROM c
WHERE c.country = "US"

provides a partition key value.

This allows Cosmos DB to target the appropriate partition.

However, a query such as:

			
SELECT *
FROM c
WHERE c.loyaltyLevel = "Gold"

does not specify the partition key.

The service may therefore need to query multiple partitions.

This is a cross-partition query.

Cross-partition queries are not inherently wrong. They are sometimes necessary.

However, they can require more resources and incur higher request charges than targeted queries.

20. Supplying a Partition Key to a Query

The SDK can provide the partition key value separately from the query itself.

For example:

			
var query = new QueryDefinition(
    "SELECT * FROM c WHERE c.loyaltyLevel = @level")
    .WithParameter("@level", "Gold");
var requestOptions = new QueryRequestOptions
{
    PartitionKey = new PartitionKey("US")
};
using FeedIterator<Customer> iterator =
    container.GetItemQueryIterator<Customer>(
        query,
        requestOptions: requestOptions);

		

The application is effectively telling Cosmos DB:

Search only the US partition.

This can significantly improve query efficiency when the access pattern permits it.

21. Query Performance and Request Units

Azure Cosmos DB measures database operations using Request Units (RUs).

The RU charge depends on factors such as:

The operation being performed.
The amount of data processed.
The complexity of the query.
Indexing.
Number of partitions involved.
Number of documents examined.
Amount of data returned.

A query that scans many partitions can consume substantially more RUs than a targeted query.

Applications should therefore design queries and partition keys together.

22. Indexing

Cosmos DB automatically indexes properties by default in many common configurations.

Indexes help Cosmos DB efficiently locate matching documents.

However, indexing every property isn’t always optimal for every workload.

Applications with specialized workloads may need to configure indexing policies to balance:

Query performance.
Write performance.
Storage.
RU consumption.

For the AI-200 exam, understand the relationship:

			
More/appropriate indexing
        ↓
Efficient queries
        ↓
Potentially lower query cost

		

But indexing isn’t a substitute for good partition-key design.

23. Querying Arrays and Nested Properties

Cosmos DB documents can contain nested objects and arrays.

For example:

			
{
    "id": "1001",
    "customer": {
        "name": "John",
        "country": "US"
    },
    "orders": [
        {
            "id": "O100",
            "total": 125
        },
        {
            "id": "O101",
            "total": 200
        }
    ]
}

		

A nested property can be accessed using dot notation:

			
SELECT c.customer.name
FROM c

Cosmos DB also supports array operations.

For example, the ARRAY_CONTAINS function can determine whether an array contains a particular value.

The ability to query nested JSON is one of the significant advantages of the NoSQL model.

24. Query Functions

Azure Cosmos DB for NoSQL supports many built-in functions.

Examples include functions for:

Strings.
Arrays.
Mathematical calculations.
Date/time operations.
Type checking.
Spatial data.

For example:

			
SELECT *
FROM c
WHERE CONTAINS(c.name, "Smith")

Another example:

			
SELECT *
FROM c
WHERE ARRAY_CONTAINS(c.tags, "AI")

The important exam concept is not memorizing every function but understanding that Cosmos DB’s query language provides rich querying capabilities against JSON documents.

25. Querying With `ORDER BY`

Results can be sorted using ORDER BY.

For example:

			
SELECT
    c.id,
    c.name,
    c.total
FROM c
ORDER BY c.total DESC

		

This returns the highest totals first.

Queries can also use OFFSET and LIMIT patterns for controlled result sets.

26. Querying With Aggregates

Cosmos DB supports aggregate functions such as:

			
COUNT
SUM
AVG
MIN
MAX

		

For example:

			
SELECT VALUE COUNT(1)
FROM c
WHERE c.country = "US"

The VALUE keyword is useful when the desired result is the scalar value rather than an object containing a property.

27. Querying With `SELECT VALUE`

Consider:

			
SELECT c.name
FROM c

This returns objects such as:

			
{
    "name": "John"
}

Using:

			
SELECT VALUE c.name
FROM c

returns the values directly:

			
"John"
"Mary"
"Robert"

This distinction can appear in exam questions.

28. Querying With Continuation Tokens

Cosmos DB can return a continuation token when a query result spans multiple pages.

The application can use the continuation token to continue retrieving results.

This is particularly useful for:

Large result sets.
Pagination.
Resuming queries.
Avoiding the need to retrieve everything at once.

The SDK’s iterator abstraction commonly handles this pagination process for the application.

29. Point Reads vs. Queries

One of the most important distinctions to understand is:

Requirement	Preferred operation
Retrieve a known item by ID and partition key	Point read
Find items matching conditions	Query
Retrieve multiple items from a partition	Query
Modify one known item	Replace/Patch
Create or update an item	Upsert
Remove one known item	Delete

Example

If you know:

			
id = customer-1001
country = US

use:

ReadItem(id, partitionKey)

rather than:

SELECT * FROM c WHERE c.id = "customer-1001"

The point read is designed specifically for this scenario.

30. Common Exam Traps

Trap 1: Confusing the database with the container

A database contains containers.

A container contains items.

Trap 2: Treating Cosmos DB like a relational database

Cosmos DB for NoSQL stores JSON documents and uses containers rather than relational tables.

Trap 3: Forgetting the partition key

The partition key is central to Cosmos DB scalability and query performance.

Trap 4: Using a query for a known item

If both the item ID and partition key are known, use a point read.

Trap 5: Creating a CosmosClient for every request

The client should generally be reused.

Trap 6: Building queries with string concatenation

Use parameterized queries with QueryDefinition.

Trap 7: Assuming every query is single-partition

A query that doesn’t target a partition may become a cross-partition query.

Trap 8: Loading all results into memory

Use the SDK’s iterator/pagination model to process potentially large result sets incrementally.

31. AI-200 Exam Takeaways

For this topic, make sure you can explain the following without referring to documentation:

Cosmos DB hierarchy
- Account → Database → Container → Item.
CosmosClient
- Establishes the SDK connection to the Cosmos DB account.
- Should generally be reused.
Authentication
- Understand account keys versus Microsoft Entra ID and managed identity.
Partition keys
- Determine logical data distribution.
- Are critical to scalability and query performance.
Point reads
- Use item ID + partition key when both are known.
Queries
- Use Cosmos DB’s SQL-like query language.
Parameterized queries
- Use QueryDefinition and parameters rather than string concatenation.
Cross-partition queries
- Can occur when a query isn’t targeted to a specific partition.
FeedIterator
- Used to process paginated query results.
Request Units
- Measure Cosmos DB resource consumption.
Indexing
- Supports efficient queries and can affect RU consumption.
CRUD operations
- Create, read, update, upsert, patch, and delete items through the SDK.

Practice Exam Questions

Question 1

An application running in Azure needs to connect to Azure Cosmos DB for NoSQL. The organization requires that no database credentials be stored in application configuration.

Which authentication approach should the developer prefer?

A. Store the Cosmos DB account key in the application’s source code.

B. Store the Cosmos DB connection string in an environment variable.

C. Use a managed identity with Microsoft Entra ID authentication and appropriate Cosmos DB permissions.

D. Create a new Cosmos DB account key whenever the application starts.

Answer: C

Explanation:
A managed identity allows an Azure-hosted application to authenticate without storing long-lived credentials in application code or configuration. The identity must have the appropriate permissions to access Cosmos DB. Hard-coded keys and connection strings introduce credential-management risks.

Question 2

A container uses /customerId as its partition key. An application needs to retrieve a specific item, and it already knows both the item’s id and customerId.

Which operation should the application use?

A. A point read using the item ID and partition key.

B. A cross-partition SQL query.

C. A query using ORDER BY.

D. A query using GROUP BY.

Answer: A

Explanation:
When the item ID and partition key are known, a point read is the appropriate operation. It directly addresses the item instead of executing a query across documents.

Question 3

A developer needs to allow users to search for customers by name. The name is supplied by the user at runtime.

Which approach should the developer use?

A. Concatenate the user input into the SQL string.

B. Encode the user’s input as Base64 and concatenate it into the SQL string.

C. Create a separate container for each possible customer name.

D. Use a parameterized QueryDefinition.

Answer: D

Explanation:
A parameterized query separates query structure from user-supplied values. The Cosmos DB SDK supports parameters through QueryDefinition.WithParameter(). This is preferable to dynamically concatenating user input into query strings.

Question 4

A Cosmos DB container is partitioned by /region. An application executes:

			
SELECT *
FROM c
WHERE c.productCategory = "AI"

The query does not specify a region.

What should the developer understand about this query?

A. It automatically becomes a point read.

B. It may require a cross-partition query.

C. It can only return one document.

D. Cosmos DB automatically changes the partition key for the query.

Answer: B

Explanation:
Because the query does not restrict the /region partition key, Cosmos DB may need to query multiple partitions. Cross-partition queries are supported, but they can consume more resources than targeted queries.

Question 5

An application executes a query that can return hundreds of thousands of documents. The developer wants to avoid loading all results into memory simultaneously.

Which SDK approach is most appropriate?

A. Use a FeedIterator and process the results page by page.

B. Convert the query into a point read.

C. Increase the item’s partition key value.

D. Retrieve the entire result set using a single string response.

Answer: A

Explanation:
Cosmos DB queries can return results in multiple pages. The SDK’s FeedIterator allows an application to retrieve and process each page incrementally, which is more appropriate for large result sets.

Question 6

An application repeatedly creates a new CosmosClient object every time it performs a database operation.

What should the developer do?

A. Create a new client for every item.

B. Create two clients for every request to provide redundancy.

C. Reuse a CosmosClient instance for the lifetime of the application.

D. Replace the SDK with direct HTTP calls for every operation.

Answer: C

Explanation:
CosmosClient is designed to be reused. Creating clients repeatedly introduces unnecessary connection-management overhead and can negatively affect application performance.

Question 7

A container uses /country as its partition key. An application frequently retrieves customers when both their customer ID and country are known.

Which design provides the most direct access to an individual customer?

A. Store all customers in a single partition.

B. Use a point read with the customer ID and country as the partition key value.

C. Run a cross-partition query for every customer.

D. Use ORDER BY country before retrieving the customer.

Answer: B

Explanation:
A point read using the item ID and partition key can directly locate an item. This is preferable to running a query when the application’s access pattern already provides both values.

Question 8

A developer wants to update only the status property of a large Cosmos DB document rather than replacing the entire document.

Which operation is most appropriate?

A. CreateItem

B. ReadItem

C. DeleteItem

D. Patch

Answer: D

Explanation:
Patch is designed for modifying specific properties or paths within an existing item without requiring the entire document to be replaced.

Question 9

A Cosmos DB application performs a query that searches across many physical partitions. The query consumes significantly more Request Units than a similar query that targets a single partition.

What is the most likely explanation?

A. Cross-partition queries can require work across multiple partitions.

B. Cosmos DB charges a fixed number of RUs for every query regardless of its scope.

C. Point reads always consume more RUs than cross-partition queries.

D. Partition keys have no relationship to query performance.

Answer: A

Explanation:
Queries that span multiple partitions may require Cosmos DB to perform work across those partitions, which can increase resource consumption. Designing partition keys around application access patterns can help reduce unnecessary cross-partition queries.

Question 10

A developer wants a query to return only customer names as scalar values instead of objects such as:

			
{
    "name": "John Smith"
}

Which query should the developer use?

			
SELECT *
FROM c

			
SELECT c
FROM c

			
SELECT VALUE c.name
FROM c

			
SELECT OBJECT(c.name)
FROM c

Answer: C

Explanation:
SELECT VALUE returns the selected expression directly rather than wrapping it in a JSON object. Therefore:

			
SELECT VALUE c.name
FROM c

returns scalar values such as:

			
"John Smith"
"Mary Jones"

rather than objects containing a name property.

Final Exam Reminder

For AI-200, don’t think of Cosmos DB simply as “a NoSQL database that I can query.” Think about the relationship between data modeling, partitioning, SDK operations, queries, and performance.

The most important decision pattern is:

Know the item ID + partition key? → Point read.
Need to find items based on criteria? → Query.
Know the partition key? → Target the partition when possible.
Large result set? → Process pages with the SDK iterator.
User-supplied values? → Parameterize the query.
Azure-hosted application without stored credentials? → Prefer managed identity/Entra ID where supported.

Go to the AI-200 Exam Prep Hub main page

azure, Cloud computing, Microsoft Certification August 15, 2026August 15, 2026

Monitor and troubleshoot solutions on AKS and Container Apps by inspecting logs, events, and end-to-end connectivity (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container-orchestrated solutions
      --> Monitor and troubleshoot solutions on AKS and Container Apps by inspecting logs, events, and end-to-end connectivity

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Modern AI applications frequently run as distributed containerized solutions. A typical application might include several containers, APIs, background workers, databases, messaging services, and external Azure services. When something goes wrong, determining where the problem exists is often more difficult than identifying that a problem exists.

For the AI-200 exam, developers should understand how to troubleshoot applications running on:

Azure Kubernetes Service (AKS)
Azure Container Apps
The networking and services that connect application components
Azure monitoring and logging capabilities

A particularly important skill is knowing how to work from the application outward:

Application/container → Pod or replica → Service/ingress → Network → Destination

This approach helps isolate whether a problem is caused by the application itself, the container runtime, Kubernetes configuration, service discovery, ingress, networking, or an external dependency.

1. The Troubleshooting Mindset

When an application is failing, avoid immediately changing configuration. First determine which layer is failing.

A useful troubleshooting sequence is:

Is the application running?
Is the container healthy?
Are there useful application logs?
Are there Kubernetes or platform events indicating a problem?
Can the application communicate with its immediate dependency?
Can the service route traffic to the application?
Can traffic enter or leave the application environment?
Is the external dependency itself healthy?

For AKS, Microsoft recommends an inside-out approach for connectivity problems: begin with the pod and application, then work outward through the service and networking layers toward the client or destination.

This approach is particularly useful on the exam because a scenario may provide several symptoms but only one layer is actually responsible for the failure.

2. Logs vs. Events vs. Metrics

One of the most important distinctions to understand is the difference between logs, events, and metrics.

Signal	What it tells you	Typical use
Logs	What the application or platform reported	Application errors, exceptions, startup failures
Events	What happened to an infrastructure/resource object	Scheduling failures, image pulls, restarts
Metrics	Numerical measurements over time	CPU, memory, request rate, latency
Traces	How a request traveled through distributed components	End-to-end request troubleshooting

Logs

Logs are particularly useful when the application itself knows why it failed.

Examples include:

Database connection failures
Authentication errors
Exceptions
Invalid configuration
Failed API calls
Application startup errors

Events

Events are especially useful when Kubernetes or the hosting platform is having difficulty creating, scheduling, starting, or managing a workload.

Examples include:

Failed scheduling
Failed image pulls
Container creation failures
Probe failures
Pod restarts
Resource constraints

Metrics

Metrics help identify patterns rather than individual failures.

Examples include:

CPU utilization
Memory utilization
Request rate
Replica count
Network traffic
Latency
Restart counts

A common exam scenario is:

An application is slow and occasionally unavailable.

Logs may identify the immediate application error, while metrics may reveal that CPU or memory is saturated and events may reveal that pods are being restarted.

You often need all three signals to understand the complete problem.

3. Monitoring and Troubleshooting AKS

AKS provides Kubernetes-native troubleshooting capabilities together with Azure monitoring services.

Important tools include:

kubectl get
kubectl describe
kubectl logs
kubectl exec
kubectl get events
Azure Monitor
Container insights
Azure portal
Application logs
Kubernetes events
Metrics

4. Start by Checking Pod Status

The first question is simple:

Is the workload actually running?

Use:

kubectl get pods

For a specific namespace:

kubectl get pods -n <namespace>

To see pods across all namespaces:

kubectl get pods -A

You might see states such as:

Running
Pending
Succeeded
Failed
CrashLoopBackOff
ImagePullBackOff
ErrImagePull
ContainerCreating
Terminating

These statuses provide an initial indication of where to investigate.

Example

Suppose you see:

			
NAME                         READY   STATUS             RESTARTS
ai-worker-7f4b8c9d8-x2k4m   0/1     CrashLoopBackOff   8

The pod is repeatedly starting and failing.

The next step should generally be to investigate the pod rather than immediately examining the network.

5. Use kubectl describe to Examine Resource Details and Events

Use:

kubectl describe pod <pod-name>

Or:

kubectl describe pod <pod-name> -n <namespace>

kubectl describe provides detailed information about the Kubernetes object, including its configuration, status, conditions, and associated events.

This is particularly useful for identifying problems such as:

Failed scheduling
Image pull failures
Insufficient resources
Failed health probes
Volume mount problems
Container startup problems

For example, an event such as:

Failed to pull image

points toward an image or registry problem rather than an application networking problem.

Likewise:

FailedScheduling

suggests that Kubernetes cannot place the pod on an appropriate node.

6. Kubernetes Events

Kubernetes events record significant activities involving Kubernetes resources.

Examples include:

Pod scheduling
Container creation
Container startup
Image pulling
Failed scheduling
Probe failures
Resource-related problems

You can list events with:

kubectl get events

For a namespace:

kubectl get events -n <namespace>

Events can also be sorted or filtered when investigating a particular problem.

Kubernetes events are extremely useful for troubleshooting, but they are not intended to be a permanent application log store. By default, Kubernetes events have limited retention; current Azure documentation notes that events are available for approximately one hour unless longer-term collection is configured through monitoring capabilities such as Container insights.

Exam Tip

If a question asks:

“Which tool should you use to determine why a pod failed to start?”

Think:

kubectl describe pod and Kubernetes events

If the question asks:

“What did the application itself report?”

Think:

container logs

7. Inspect Container Logs in AKS

Use:

kubectl logs <pod-name>

For a specific namespace:

kubectl logs <pod-name> -n <namespace>

For a particular container in a multi-container pod:

kubectl logs <pod-name> -c <container-name>

This is especially useful when:

The application starts and then crashes
The application throws an exception
A dependency cannot be reached
Configuration is invalid
Authentication fails
The application is returning errors

8. Inspect Logs from a Previous Container Instance

This is an important troubleshooting technique.

If a container has crashed and restarted, its current log may not contain the information from the previous instance.

Use:

kubectl logs <pod-name> --previous

For a particular container:

kubectl logs <pod-name> -c <container-name> --previous

This is particularly valuable when diagnosing:

CrashLoopBackOff
Startup failures
Unexpected application termination
Configuration errors during initialization

Exam Scenario

A pod repeatedly restarts. The current container appears healthy, but you need to determine why the previous instance terminated.

The appropriate command is:

kubectl logs <pod-name> --previous

9. Kubernetes Health Probes

Health probes are another major source of troubleshooting information.

Kubernetes supports:

Liveness probe

Determines whether a container is still functioning.

If the liveness probe repeatedly fails, Kubernetes can restart the container.

Readiness probe

Determines whether the application is ready to receive traffic.

A container can be running but not ready.

Startup probe

Provides additional time for applications that require significant startup time before liveness/readiness checks should begin.

Why Probes Matter

Consider an AI inference service that requires 60 seconds to load a model.

If its liveness probe begins failing after only 10 seconds, Kubernetes may repeatedly restart the container before the model finishes loading.

The result can be:

CrashLoopBackOff

even though the application itself is not fundamentally broken.

Therefore, when investigating repeated restarts, inspect:

kubectl describe pod <pod-name>

and look for probe-related events.

10. Inspect AKS Services

A pod’s IP address is generally not the endpoint that clients should depend on.

Kubernetes Services provide stable networking for workloads.

List services:

kubectl get svc

Describe a service:

kubectl describe svc <service-name>

You should investigate:

Service type
Port
Target port
Selector
Cluster IP
Endpoints
Associated pods

A common failure is a Service selector that does not match the labels on the intended pods.

For example, a Service might select:

			
selector:
  app: ai-api

while the pods actually have:

			
labels:
  app: ai-service

The pods may be healthy, but the Service has no appropriate endpoints.

11. Check Service Endpoints

One of the most important connectivity checks is determining whether a Service actually has endpoints.

For example:

kubectl get endpoints <service-name>

Depending on the Kubernetes version and configuration, EndpointSlices can also be examined:

kubectl get endpointslices

If the Service has no usable endpoints, traffic cannot be routed to the expected application pods.

This creates an important troubleshooting distinction:

Pod is healthy ≠ Service is correctly routing traffic

12. Test Connectivity from Inside the Cluster

When troubleshooting network connectivity, testing from inside the cluster can eliminate several variables.

For example, you can run a temporary diagnostic pod and test connectivity to another service.

Useful tools can include:

nslookup <service-name>

curl http://<service-name>:<port>

or:

nc -z -v <host> <port>

The exact tools available depend on the container image.

This allows you to determine whether:

DNS resolution works
The destination port is reachable
The service responds
The application is actually listening

13. End-to-End AKS Connectivity Troubleshooting

Consider this architecture:

			
Internet
   |
   v
Ingress / Load Balancer
   |
   v
Kubernetes Service
   |
   v
Pod
   |
   v
Application
   |
   v
External Azure Service

		

A useful troubleshooting process is to work through the architecture one layer at a time.

Step 1: Is the pod running?

kubectl get pods

Step 2: Is the application healthy?

kubectl logs <pod-name>

Step 3: Are there Kubernetes events?

kubectl describe pod <pod-name>

Step 4: Does the Service exist?

kubectl get svc

Step 5: Does the Service have endpoints?

kubectl get endpoints <service-name>

Step 6: Can another pod reach the Service?

Use a test container and:

curl http://<service-name>:<port>

Step 7: Does DNS work?

For example:

nslookup <service-name>

Step 8: Does external ingress work?

Test the externally exposed endpoint.

Step 9: Can the application reach external dependencies?

Test the required destination from inside the workload.

This approach prevents you from assuming that every connectivity problem is an ingress problem.

14. Container Insights for AKS

Azure Monitor Container insights provides monitoring capabilities for AKS.

It can provide visibility into:

Container logs
Kubernetes events
Pod metrics
Cluster information
Resource utilization

The Live Data capability can provide direct access to AKS container logs, events, and pod metrics for real-time troubleshooting.

This can be particularly useful when you want Azure-based monitoring rather than relying exclusively on command-line Kubernetes tools.

Important distinction

kubectl logs is a Kubernetes-native method for retrieving container logs.

Container insights provides an Azure monitoring experience that can aggregate and visualize Kubernetes telemetry.

15. Azure Container Apps Monitoring

Azure Container Apps abstracts much of the underlying Kubernetes infrastructure.

Unlike AKS, you generally do not troubleshoot Container Apps by directly managing Kubernetes nodes and pods.

Instead, use Container Apps’ platform-level monitoring capabilities.

Important sources include:

Container console logs
System logs
HTTP logs
Log streams
Azure Monitor
Application Insights
Metrics
Diagnose and solve problems

16. Container App Console Logs

Container console logs originate from the application’s:

stdout
stderr

These are useful for diagnosing application-level problems.

For example:

Database connection failed

or:

Authentication failed

or:

Unhandled exception

These messages can help identify problems inside the application.

Azure Container Apps allows console logs to be viewed through the Azure portal and CLI.

17. Container Apps System Logs

System logs are generated by the Container Apps service rather than directly by the application.

They can help identify platform-level problems such as:

Revision provisioning failures
Container startup issues
Configuration problems
Volume mounting failures
Dapr component issues
Application configuration changes
Other service-level events

This creates an important exam distinction:

Problem	Most useful source
Application exception	Console logs
Revision provisioning failure	System logs
Container lifecycle issue	System/platform logs
HTTP request behavior	HTTP logs
Resource utilization	Metrics

18. Viewing Container Apps Log Streams

In the Azure portal, navigate to the Container App and select:

Monitoring → Log stream

You can select between:

Console
System

The console stream displays application/container output, while the system stream provides platform-level information.

You can also use the Azure CLI.

For example:

			
az containerapp logs show \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --type console

For system logs:

			
az containerapp logs show \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --type system

You can use --tail to limit the number of messages and --follow to continuously stream logs.

19. Container Apps Revisions and Replicas

Container Apps uses revisions and replicas.

This matters when troubleshooting because the application may have:

Multiple revisions
Multiple replicas
Multiple containers

A log problem might exist only in one revision or replica.

Therefore, when investigating Container Apps logs, determine:

Which revision is receiving traffic?
Which replica is experiencing the problem?
Which container is producing the error?
Is the problem isolated or occurring across all replicas?

This is particularly important during deployments.

For example:

			
Revision A → healthy
Revision B → failing

If traffic has been shifted to Revision B, users may experience failures even though Revision A remains healthy.

20. Container Apps and Scaling to Zero

Container Apps can scale an application down to zero replicas depending on its scaling configuration.

This creates a potential troubleshooting trap.

If an application is scaled to zero, there may be no active replica from which to stream console logs.

If the log stream indicates that the revision is scaled to zero, you may need to temporarily configure a minimum replica count greater than zero to investigate the running application.

Exam Tip

If a Container App has no active replicas:

Don’t assume the application has crashed.

It may simply have scaled to zero.

21. Container Apps HTTP Logs

Container Apps can also provide HTTP-related telemetry through its ingress layer when diagnostic settings are configured.

These logs can help investigate:

HTTP status codes
Request behavior
Client requests
Ingress problems
Application availability

This is useful when the container itself appears healthy but clients are receiving errors.

For example:

Client → Container Apps ingress → Container

If the container logs show no corresponding request, investigate the ingress/routing layer.

22. Diagnose and Solve Problems in Container Apps

Azure Container Apps provides a Diagnose and solve problems experience for investigating application health, configuration, and performance.

This can be useful when problems are not immediately obvious from application logs.

For example, Container Apps diagnostics can help investigate container exit events and provide information about possible causes and resolutions.

23. AKS vs. Container Apps Troubleshooting

Understanding the difference between AKS and Container Apps is important for AI-200.

Area	AKS	Azure Container Apps
Kubernetes API access	Yes	Abstracted from developer
`kubectl` troubleshooting	Yes	Generally not the primary approach
Pod troubleshooting	Yes	Platform abstracts replicas
Kubernetes events	Directly available	Platform-level diagnostics/logs
Container logs	`kubectl logs`	Log stream / CLI
System logs	Kubernetes/Azure monitoring	Container Apps system logs
Service configuration	Kubernetes Services	Container Apps ingress
Scaling	Kubernetes autoscaling mechanisms	Container Apps scaling rules
Node troubleshooting	Possible	Managed/abstracted
Azure Monitor	Yes	Yes
Container Insights	Available	Not the primary troubleshooting interface

Key Exam Principle

If a question emphasizes:

Pods, nodes, Services, Deployments, Kubernetes events, kubectl

think:

AKS

If it emphasizes:

Revisions, replicas, Container Apps log streams, system logs, console logs, ingress

think:

Azure Container Apps

24. Troubleshooting Common AKS Problems

Problem: Pod is Pending

Check:

kubectl describe pod <pod-name>

Look for events such as:

FailedScheduling

Potential causes include:

Insufficient CPU
Insufficient memory
Node constraints
Affinity rules
Taints and tolerations
Resource quotas

Problem: ImagePullBackOff

Check:

kubectl describe pod <pod-name>

Potential causes include:

Incorrect image name
Incorrect image tag
Private registry authentication
Network connectivity to the registry
Image does not exist

Problem: CrashLoopBackOff

Check:

kubectl logs <pod-name>

Then:

kubectl logs <pod-name> --previous

And:

kubectl describe pod <pod-name>

Potential causes include:

Application crash
Invalid configuration
Missing secret
Failed dependency connection
Failed liveness probe
Incorrect startup behavior

Problem: Pod is Running but Requests Fail

Investigate:

Application logs
Pod readiness
Service configuration
Service endpoints
DNS
Network policies
Ingress/load balancer
External networking

A Running status does not guarantee that an application is reachable.

25. Troubleshooting Common Container Apps Problems

Problem: Container exits

Check:

Console logs
System logs
Container exit events
Revision status
Application startup configuration

A zero exit code can indicate normal termination, while a nonzero exit code generally indicates failure. Container Apps provides diagnostic information about container exit events.

Problem: Application is unavailable

Check:

Active revision
Replica count
Ingress configuration
Console logs
System logs
HTTP logs
Health probes
Application dependencies

Problem: New deployment fails

Check:

Revision provisioning
Container image
Environment variables
Secrets
Managed identity
Registry access
Container startup
Application logs

A new revision can fail while a previous revision continues to operate.

26. Troubleshooting End-to-End Connectivity

End-to-end connectivity problems require a broader perspective.

Consider an AI application with this architecture:

			
User
  |
  v
Azure Front Door / Application Gateway
  |
  v
Container App or AKS Ingress
  |
  v
Application
  |
  +------> Azure OpenAI
  |
  +------> Azure Cosmos DB
  |
  +------> Azure Service Bus
  |
  +------> Azure Storage

		

A failure could occur anywhere along this path.

The correct troubleshooting approach is to identify the first point at which communication fails.

27. Test from the Same Network Context

A common troubleshooting mistake is testing connectivity from your laptop when the actual application runs inside Azure.

For example:

Laptop → Azure service

may work while:

Container → Azure service

fails.

The application should therefore be tested from the same network context in which it runs.

For AKS, this may mean executing commands from a diagnostic pod.

For Container Apps, troubleshooting may involve application logs, platform diagnostics, ingress configuration, and network configuration.

28. DNS Troubleshooting

DNS problems can make a healthy application appear unavailable.

Suppose an application attempts:

https://my-database.example.com

but cannot resolve the hostname.

The application may produce errors such as:

Name or service not known

or:

DNS resolution failed

In AKS, test DNS from inside the cluster:

nslookup <hostname>

or:

nslookup <service-name>

If DNS resolution fails, investigate DNS configuration before investigating the application itself.

29. Port and Protocol Troubleshooting

A common problem is confusing:

Container port
Service port
Target port
External port

For example:

			
Client
  |
  | TCP 443
  v
Ingress
  |
  | TCP 8080
  v
Service
  |
  | TCP 8080
  v
Pod

		

The application must actually be listening on the expected port.

A connectivity test such as:

nc -z -v <host> <port>

can help determine whether a TCP port is reachable.

30. Application Connectivity vs. Infrastructure Connectivity

Another important distinction is:

Can the network connection be established?

versus:

Does the application successfully process the request?

For example:

			
TCP connection succeeds
        |
        v
HTTP 500

The network is functioning, but the application has an error.

Conversely:

Connection timeout

may indicate a networking, routing, firewall, DNS, or service availability problem.

The HTTP response code and application logs should therefore be considered together.

31. A Practical AKS Troubleshooting Playbook

When an AKS application is unavailable, use this sequence.

Step 1 — Check pods

kubectl get pods -A

Step 2 — Inspect unhealthy pods

kubectl describe pod <pod-name>

Step 3 — Read logs

kubectl logs <pod-name>

Step 4 — Check previous container logs

kubectl logs <pod-name> --previous

Step 5 — Check events

kubectl get events

Step 6 — Check Services

kubectl get svc

Step 7 — Check endpoints

kubectl get endpoints <service-name>

Step 8 — Test DNS

nslookup <service-name>

Step 9 — Test connectivity

curl http://<service-name>:<port>

Step 10 — Investigate ingress and external networking

Only after the internal application path is confirmed should you move farther outward.

32. A Practical Container Apps Troubleshooting Playbook

For Azure Container Apps:

Step 1 — Check revision status

Determine whether the expected revision is active and healthy.

Step 2 — Check replica state

Determine whether the application has active replicas or has scaled to zero.

Step 3 — Inspect console logs

Look for application-level errors.

Step 4 — Inspect system logs

Look for platform and revision-level problems.

Step 5 — Inspect HTTP/ingress telemetry

Determine whether requests are reaching the application.

Step 6 — Check configuration

Review:

Environment variables
Secrets
Managed identity
Registry configuration
Ingress
Health probes

Step 7 — Check external dependencies

Determine whether the application can communicate with required Azure services.

Step 8 — Use Azure diagnostics

Use the Container Apps diagnostic capabilities when the source of the problem remains unclear.

33. Common Troubleshooting Mistakes

Mistake 1: Assuming Running Means Healthy

A pod can be Running while the application inside it is broken.

Use readiness status, logs, and probes.

Mistake 2: Looking Only at Application Logs

Infrastructure events may reveal the actual problem.

For example:

ImagePullBackOff

is unlikely to be explained by an application log because the application may never have started.

Mistake 3: Looking Only at Events

Events can tell you that something happened, but application logs may explain why the application itself failed.

Use both.

Mistake 4: Troubleshooting Ingress First

If the pod isn’t running, spending time troubleshooting ingress is premature.

Work from the application outward.

Mistake 5: Ignoring Previous Container Logs

A restarted container may have lost the most useful evidence.

Use:

kubectl logs --previous

Mistake 6: Assuming a Container App with No Logs Is Broken

The application might be scaled to zero.

Check its replica/scaling state.

Mistake 7: Testing from the Wrong Location

A connection that succeeds from your development machine does not prove that it will succeed from the Azure-hosted application.

Test from the application’s network context whenever possible.

34. Exam-Focused Command Reference

Task	Command
List pods	`kubectl get pods`
List all pods	`kubectl get pods -A`
Describe pod	`kubectl describe pod <pod>`
View container logs	`kubectl logs <pod>`
View previous container logs	`kubectl logs <pod> --previous`
View a specific container	`kubectl logs <pod> -c <container>`
List events	`kubectl get events`
List services	`kubectl get svc`
Describe service	`kubectl describe svc <service>`
View endpoints	`kubectl get endpoints <service>`
Test HTTP connectivity	`curl <url>`
Test DNS	`nslookup <hostname>`
Test TCP connectivity	`nc -z -v <host> <port>`
Container Apps console logs	`az containerapp logs show --type console`
Container Apps system logs	`az containerapp logs show --type system`
Follow Container Apps logs	`az containerapp logs show --follow`

35. Key Concepts to Remember for AI-200

The following distinctions are particularly important for exam preparation.

AKS

kubectl get

Use it to see the current state of Kubernetes resources.

kubectl describe

Use it to investigate resource configuration, status, conditions, and events.

kubectl logs

Use it to inspect application/container output.

kubectl logs --previous

Use it to inspect logs from a previous container instance.

kubectl get events

Use it to investigate Kubernetes lifecycle and scheduling events.

Services and endpoints

Use them to determine whether traffic can be routed from a Kubernetes Service to the intended pods.

Container insights

Use Azure Monitor capabilities for broader monitoring, logs, events, and metrics.

Azure Container Apps

Console logs

Application/container output.

System logs

Container Apps platform/service events.

HTTP logs

Ingress-level HTTP activity when configured.

Log stream

Near-real-time access to console and system logs.

Revisions

Different deployed versions of an application.

Replicas

Running instances of a revision.

Diagnose and solve problems

Azure’s diagnostic capabilities for investigating application health and platform problems.

36. Final Exam Strategy

When presented with a troubleshooting scenario, identify the symptom first.

If the question mentions:

CrashLoopBackOff

Think:

kubectl logs
kubectl logs --previous
kubectl describe pod
Health probes

ImagePullBackOff

Think:

Image name/tag
Container registry
Authentication
kubectl describe pod

FailedScheduling

Think:

Node resources
Scheduling constraints
Taints/tolerations
kubectl describe pod

Pod is Running but service is unreachable

Think:

Service
Selector
Endpoints
DNS
Ports
Network policies
Ingress

Container Apps application error

Think:

Console logs

Container Apps platform/revision problem

Think:

System logs
Revision status

Container App has no active replica

Think:

Scaling to zero

Requests reach the application but return HTTP errors

Think:

Application logs
HTTP logs
Dependency failures

Application cannot reach an Azure service

Think:

DNS
Network routing
Firewall/network restrictions
Identity/authentication
Service availability
Test from the application’s network context

The most important principle is:

Don’t troubleshoot the entire system at once. Start at the failing workload and move outward until you find the first broken connection or component.

Practice Exam Questions

Question 1

An application running on AKS repeatedly enters the CrashLoopBackOff state. The development team wants to determine what happened immediately before the most recent container restart.

Which command should you use?

A. kubectl get svc <pod-name>

B. kubectl logs <pod-name> --previous

C. kubectl get events --all-namespaces

D. kubectl top nodes

Answer: B

Explanation:
kubectl logs --previous retrieves logs from the previous instance of a container. This is particularly useful when a container has crashed and restarted. kubectl get events can provide additional context, but it does not provide the application’s actual log output from the previous container instance.

Question 2

An AKS pod remains in the Pending state. You need to determine why Kubernetes has not scheduled the pod onto a node.

Which action should you take first?

A. Run kubectl logs on the pod.

B. Restart the deployment.

C. Run kubectl describe pod and inspect the Events section.

D. Check the application’s HTTP logs.

Answer: C

Explanation:
kubectl describe pod provides detailed information about the pod and its associated events. Scheduling failures such as insufficient resources, taints, affinity constraints, or other scheduling problems are commonly reported there. A pod that has not started generally will not have useful application logs.

Question 3

An AKS application is running successfully in its pod. However, requests sent through a Kubernetes Service do not reach the application.

Which investigation is most appropriate next?

A. Check whether the Service has endpoints corresponding to the application pods.

B. Restart the AKS cluster.

C. Examine only the application’s CPU utilization.

D. Delete and recreate the container image.

Answer: A

Explanation:
A healthy pod does not guarantee that a Service is routing traffic to it. Checking the Service and its endpoints helps determine whether the Service selector matches the intended pods and whether usable endpoints have been registered.

Question 4

An Azure Container Apps application is returning errors. The developer wants to see messages written by the application’s container to stdout and stderr.

Which log source should be inspected?

A. Container Apps system logs

B. Azure Activity Log

C. Kubernetes events

D. Container Apps console logs

Answer: D

Explanation:
Container Apps console logs contain output from the application’s containers, including stdout and stderr. System logs instead contain information generated by the Container Apps service.

Question 5

An Azure Container Apps application was working yesterday but now appears to have no running instances. No application errors are visible in the console log stream.

What should you investigate first?

A. Whether the container image has been deleted.

B. Whether the application has scaled to zero replicas.

C. Whether Kubernetes nodes are running.

D. Whether the AKS API server is reachable.

Answer: B

Explanation:
Container Apps can scale applications to zero replicas depending on the configured scaling rules. When no replicas are running, there may be no active container instance producing console logs. AKS node and API-server troubleshooting is not appropriate because Container Apps abstracts the underlying Kubernetes infrastructure.

Question 6

An AKS application is accessible from one pod but cannot resolve the DNS name of another Kubernetes Service.

Which troubleshooting technique is most appropriate?

A. Increase the pod’s CPU limit.

B. Restart every node in the cluster.

C. Run a DNS lookup such as nslookup from the application’s network context.

D. Rebuild the container image.

Answer: C

Explanation:
If the problem appears to be DNS resolution, testing DNS from inside the cluster helps determine whether the workload can resolve the target name. Testing from the same network context as the application is important because DNS behavior can differ between environments.

Question 7

A new revision of an Azure Container Apps application fails during deployment, while the previous revision continues to operate correctly.

Which information is most useful for determining whether the new revision encountered a platform-level provisioning problem?

A. The system logs for the Container App

B. The developer’s local application logs

C. The user’s browser cache

D. The CPU utilization of an unrelated Azure VM

Answer: A

Explanation:
Container Apps system logs contain platform-level information, including revision provisioning and service-level events. They are therefore appropriate when investigating deployment or revision provisioning failures.

Question 8

An AKS application is running, but clients receive connection timeouts. The development team wants to troubleshoot the problem using an inside-out approach.

Which sequence is most appropriate?

A. Check the external client, then immediately restart the cluster.

B. Check the Azure subscription, then rebuild the application.

C. Check the ingress first and ignore the pods.

D. Check the pod/application, then Service and endpoints, then networking and external access.

Answer: D

Explanation:
An inside-out approach begins with the workload itself and progressively moves outward. First verify that the pod and application are healthy, then verify Service routing and endpoints, and finally investigate ingress and external networking. This approach helps identify the first layer where connectivity fails.

Question 9

An AKS application container is repeatedly restarted. The application logs show no obvious error, but kubectl describe pod reports repeated liveness probe failures.

What is the most likely area to investigate?

A. The Azure subscription’s billing configuration.

B. The container’s liveness probe configuration and application startup/health behavior.

C. The user’s browser DNS cache.

D. The container registry’s image retention policy.

Answer: B

Explanation:
Repeated liveness probe failures can cause Kubernetes to restart a container. The probe’s path, port, timing, timeout, and failure thresholds should be evaluated against the application’s actual startup and health behavior.

Question 10

An AI application running in AKS can connect to an external Azure service from a developer workstation but receives connection timeouts when running inside the cluster.

Which approach provides the most useful next diagnostic step?

A. Assume the external service is unavailable.

B. Increase the application’s memory allocation.

C. Test DNS and network connectivity to the destination from inside the AKS network context.

D. Delete the application deployment and recreate it.

Answer: C

Explanation:
Successful connectivity from a developer workstation does not prove that connectivity from AKS is working. Testing DNS resolution and network connectivity from inside the cluster helps isolate problems involving routing, firewall rules, network policies, private endpoints, DNS, or other network-specific configuration.

Summary

For AI-200, monitoring and troubleshooting containerized applications is fundamentally about understanding where the failure occurs.

For AKS, become comfortable with:

kubectl get
kubectl describe
kubectl logs
kubectl logs --previous
kubectl get events
Services
Endpoints
DNS testing
Connectivity testing
Health probes
Azure Monitor and Container insights

For Azure Container Apps, understand:

Console logs
System logs
HTTP logs
Log streams
Revisions
Replicas
Scaling to zero
Ingress
Container exit events
Azure diagnostics

Most importantly, develop an inside-out troubleshooting methodology:

Container → application → pod/replica → Service/ingress → network → external dependency

When you can identify the first layer where communication or execution breaks, you can usually identify the correct troubleshooting tool and the most appropriate remediation.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Microsoft Certification August 15, 2026August 15, 2026

Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container-orchestrated solutions
      --> Deploy and manage applications to Azure Kubernetes Service (AKS) by using manifest files

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Kubernetes Service (AKS) provides a managed Kubernetes environment for deploying and operating containerized applications. For AI solutions, AKS can be particularly useful when applications require container orchestration, multiple cooperating services, custom networking, persistent workloads, or more control over Kubernetes configuration.

One of the fundamental skills for working with AKS is the ability to define and deploy applications by using Kubernetes manifest files.

A Kubernetes manifest is a declarative configuration file, commonly written in YAML, that describes the desired state of Kubernetes resources. Rather than manually creating each resource with individual commands, developers can define the application’s resources in one or more manifest files and use kubectl to apply those definitions to an AKS cluster.

The AI-200 exam expects you to understand how these manifests are structured, how they are deployed, how Kubernetes resources work together, and how to manage and troubleshoot the resulting application.

1. Understanding Kubernetes Manifest Files

A Kubernetes manifest describes one or more Kubernetes resources.

A typical manifest specifies information such as:

The resource type
The resource name
The container image
The number of replicas
Container ports
Environment variables
Resource requests and limits
Configuration references
Secrets
Health probes
Labels and selectors
Service configuration
Storage requirements

A manifest is declarative.

That distinction is important.

Instead of telling Kubernetes:

Start three containers, then create a network endpoint, then connect the endpoint to those containers.

you describe the desired state:

I want a Deployment with three replicas and a Service that selects those replicas.

Kubernetes controllers continuously work toward making the actual state of the cluster match the desired state defined by the manifests.

2. YAML Manifest Structure

A basic Kubernetes manifest typically contains:

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myregistry.azurecr.io/ai-api:v1
          ports:
            - containerPort: 8080

		

The major sections are:

Property	Purpose
`apiVersion`	Specifies the Kubernetes API version used by the resource
`kind`	Specifies the type of Kubernetes resource
`metadata`	Provides identifying information such as name and labels
`spec`	Defines the desired configuration of the resource

For the exam, be comfortable recognizing the relationship between these sections.

3. The `apiVersion` Property

apiVersion identifies the API group and version used to create the resource.

For example:

apiVersion: apps/v1

is commonly used for a Deployment.

A Service generally uses:

apiVersion: v1

The API version matters because Kubernetes resources belong to different API groups and versions.

For example:

			
apiVersion: apps/v1
kind: Deployment

is different from:

			
apiVersion: v1
kind: Service

The apiVersion must be appropriate for the resource being defined.

4. The `kind` Property

The kind property identifies the Kubernetes resource being created.

Common resources include:

Deployment
Service
Pod
ConfigMap
Secret
StatefulSet
Job
CronJob
Ingress
HorizontalPodAutoscaler

For AI-200, pay particular attention to Deployment and Service, as these are fundamental to deploying and exposing applications.

5. Kubernetes Deployments

A Deployment manages a set of replicated Pods.

For example:

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myregistry.azurecr.io/ai-api:v1
          ports:
            - containerPort: 8080

		

The important relationship is:

Deployment → ReplicaSets → Pods

The Deployment controller creates and manages a ReplicaSet, which in turn maintains the requested number of Pods.

If:

replicas: 3

is specified, Kubernetes attempts to maintain three Pods matching the Deployment’s selector.

If a Pod fails, Kubernetes can create a replacement.

6. Labels and Selectors

Labels are extremely important in Kubernetes.

A label identifies or categorizes a resource:

			
labels:
  app: ai-api

A selector determines which resources should be associated with another resource.

For example:

			
selector:
  matchLabels:
    app: ai-api

The Deployment’s selector must correspond to labels on its Pod template.

A Service can then use the same label:

			
selector:
  app: ai-api

This allows the Service to route traffic to the appropriate Pods.

Exam Tip

A common exam scenario presents a Deployment and Service that aren’t communicating.

Check the Service selector and the Pod labels.

For example:

			
# Pod
labels:
  app: ai-api

and:

			
# Service
selector:
  app: ai-api

match.

But:

			
selector:
  app: api

does not.

A mismatch can result in a Service with no appropriate endpoints.

7. Container Images

A Deployment specifies the image that Kubernetes should run:

			
containers:
  - name: ai-api
    image: myregistry.azurecr.io/ai-api:v1

For Azure-based applications, the image may be stored in Azure Container Registry (ACR).

The image reference generally contains:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/inference-api:2.1

The tag identifies the particular version of the image.

Best Practice

Avoid relying on ambiguous tags such as:

latest

for production deployments when deterministic versioning is important.

Using an explicit version such as:

inference-api:2.1.4

makes deployments easier to reproduce and troubleshoot.

8. Connecting AKS to Azure Container Registry

An AKS application frequently pulls its container images from ACR.

The AKS cluster must have appropriate permissions to pull the image.

For example, Azure CLI can be used to attach an ACR to an AKS cluster:

			
az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --attach-acr myRegistry

The exact identity and authorization configuration can vary depending on how the AKS cluster is configured.

The important concept is:

AKS must be authorized to pull the private container image.

If the image cannot be pulled, Pods may enter states such as:

ImagePullBackOff

or:

ErrImagePull

9. Exposing an Application with a Service

A Pod’s IP address is generally not intended to be the stable endpoint for an application.

A Kubernetes Service provides a stable network abstraction for accessing a set of Pods.

Example:

			
apiVersion: v1
kind: Service
metadata:
  name: ai-api
spec:
  selector:
    app: ai-api
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

		

Here:

port: 80 is the Service port.
targetPort: 8080 is the container/application port.
selector: app: ai-api identifies the Pods receiving traffic.
type: LoadBalancer requests an externally accessible load-balancing endpoint through the cloud provider integration.

10. Service Types

The most important Service types to recognize are:

ClusterIP

type: ClusterIP

This is the default Service type.

It provides an internal cluster endpoint.

Use it when the application should be reachable from within the Kubernetes cluster but doesn’t need to be directly exposed externally.

NodePort

type: NodePort

Exposes the Service through a port on each node.

It is useful in certain scenarios but is generally less convenient than higher-level ingress or load-balancing approaches for production web applications.

LoadBalancer

type: LoadBalancer

Requests an external load balancer from the cloud provider.

In AKS, this can provide an externally reachable IP address for the application.

A newly created LoadBalancer Service may initially show:

EXTERNAL-IP   <pending>

until the Azure networking resources are provisioned.

11. Deploying a Manifest to AKS

Once kubectl is configured to communicate with the AKS cluster, the primary command for applying a manifest is:

kubectl apply -f deployment.yaml

For example:

kubectl apply -f ai-api.yaml

kubectl apply is an important command because it applies the desired configuration described by the manifest to the cluster.

Microsoft’s AKS documentation uses this pattern for deploying applications from YAML manifests.

You can also apply a directory:

kubectl apply -f ./manifests/

This is useful when an application consists of multiple YAML files.

12. Applying Multiple Resources in One File

A YAML file can contain multiple Kubernetes resources.

The resources are separated using:

---

For example:

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  ...
---
apiVersion: v1
kind: Service
metadata:
  name: ai-api
spec:
  ...

		

This allows the Deployment and Service to be maintained together.

An AKS application can therefore be deployed using a single command:

kubectl apply -f ai-api.yaml

The manifest can create multiple Kubernetes objects.

13. Connecting `kubectl` to AKS

Before deploying an application, kubectl must be configured to communicate with the correct AKS cluster.

A common command is:

			
az aks get-credentials \
  --resource-group myResourceGroup \
  --name myAKSCluster

This configures the local Kubernetes client with credentials and cluster information.

You can then verify connectivity:

kubectl get nodes

If the connection is successful, the cluster’s nodes should be displayed.

Exam Tip

Know the distinction:

az aks ...

is used to manage/interact with the Azure AKS resource.

kubectl ...

is used to interact with Kubernetes resources running in the cluster.

14. Namespaces

Namespaces provide logical isolation within a Kubernetes cluster.

A manifest can specify a namespace:

			
metadata:
  name: ai-api
  namespace: production

Alternatively, the namespace can be supplied when using kubectl:

kubectl apply -f ai-api.yaml -n production

You can view resources in a namespace with:

kubectl get pods -n production

Namespaces are useful for separating environments or application components.

For example:

			
development
testing
production

can exist within the same cluster.

15. Environment Variables

Container applications often require configuration through environment variables.

A manifest can specify them directly:

			
env:
  - name: MODEL_NAME
    value: "my-model"
  - name: LOG_LEVEL
    value: "Information"

		

However, application configuration should generally be separated from the container image.

Kubernetes provides ConfigMaps for non-sensitive configuration and Secrets for sensitive information.

16. ConfigMaps

A ConfigMap stores non-sensitive configuration data.

Example:

			
apiVersion: v1
kind: ConfigMap
metadata:
  name: ai-config
data:
  MODEL_NAME: "my-model"
  LOG_LEVEL: "Information"

		

A Deployment can consume the values:

			
envFrom:
  - configMapRef:
      name: ai-config

This makes it possible to change configuration without rebuilding the container image.

17. Kubernetes Secrets

Sensitive information should not normally be hard-coded into a Deployment manifest.

Kubernetes Secrets can be used to store sensitive configuration such as:

Passwords
API keys
Connection strings
Certificates

For example:

			
env:
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: ai-secrets
        key: api-key

		

For production Azure applications, you should also understand Azure-native approaches for managing secrets, such as Azure Key Vault and workload identity, rather than treating a Kubernetes Secret as equivalent to a fully managed secret-management solution.

18. Resource Requests and Limits

Containers can specify CPU and memory requests and limits.

For example:

			
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

		

Requests

A request indicates the resources needed for scheduling.

Kubernetes uses requests when determining where a Pod can run.

Limits

A limit establishes the maximum resource usage permitted for the container.

For AI workloads, resource specifications can be particularly important because inference workloads can consume substantial CPU or memory.

19. Health Probes

Kubernetes supports health probes that help determine application health.

Three important probe concepts are:

Startup probe

Determines whether an application has successfully started.

This is particularly useful for applications that take a long time to initialize.

Readiness probe

Determines whether the application is ready to receive traffic.

If a container isn’t ready, Kubernetes can prevent traffic from being sent to it through a Service.

Liveness probe

Determines whether the container is still functioning correctly.

If the liveness probe repeatedly fails, Kubernetes can restart the container.

Example:

			
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

		

Exam Distinction

Remember:

Readiness = Should this Pod receive traffic?

Liveness = Is this container still healthy enough to keep running?

Startup = Has this application finished starting?

20. Updating an Application

One of the major benefits of declarative manifests is that you can modify the desired state and apply it again.

For example, changing:

image: myregistry.azurecr.io/ai-api:v1

to:

image: myregistry.azurecr.io/ai-api:v2

and running:

kubectl apply -f ai-api.yaml

causes Kubernetes to reconcile the Deployment with the new desired configuration.

A Deployment can perform a rolling update, gradually replacing existing Pods with Pods running the new version.

This reduces application downtime compared with manually deleting all existing Pods.

21. Checking Deployment Status

After deploying a manifest, use:

kubectl get deployments

For more detailed information:

kubectl describe deployment ai-api

To inspect Pods:

kubectl get pods

To obtain additional information:

kubectl get pods -o wide

You can also watch changes:

kubectl get pods --watch

These commands are important for verifying whether the application has successfully transitioned to its desired state.

22. Viewing Application Logs

If a container is running but the application isn’t behaving correctly, inspect its logs:

kubectl logs <pod-name>

If a Pod contains multiple containers:

kubectl logs <pod-name> -c <container-name>

Logs are often the first place to look for application-level failures.

23. Using `kubectl describe`

When Kubernetes reports an unexpected condition, kubectl describe provides useful diagnostic information.

For example:

kubectl describe pod <pod-name>

This can reveal:

Scheduling problems
Container image errors
Failed probes
Mount failures
Events
Resource issues

For a Service:

kubectl describe service ai-api

can help identify configuration problems.

24. Common Deployment Problems

Several problems are particularly useful to recognize for the exam.

`ImagePullBackOff`

Usually indicates that Kubernetes cannot successfully pull the specified image.

Potential causes include:

Incorrect image name
Incorrect tag
Image doesn’t exist
Authentication/authorization failure
Registry connectivity issue

`CrashLoopBackOff`

Indicates that a container repeatedly starts and then fails.

Potential causes include:

Application startup failure
Invalid configuration
Missing environment variables
Application exception
Dependency failure

Start troubleshooting with:

kubectl logs <pod-name>

and:

kubectl describe pod <pod-name>

Pod stuck in `Pending`

A Pod may remain Pending because:

No node has sufficient resources
Node selectors don’t match available nodes
A required volume cannot be provisioned
Scheduling constraints cannot be satisfied

Inspect:

kubectl describe pod <pod-name>

for scheduling events.

Service has no endpoints

If a Service exists but isn’t routing traffic, check:

Service selector
Pod labels
Pod readiness
Service and container ports

For example:

			
selector:
  app: ai-api

must correspond to:

			
labels:
  app: ai-api

25. Managing Applications Declaratively

The major conceptual advantage of manifests is that they allow infrastructure and application configuration to be represented as code.

Instead of manually configuring a production environment, the desired configuration can be stored in source control.

For example:

			
/manifests
    namespace.yaml
    configmap.yaml
    deployment.yaml
    service.yaml

		

A deployment pipeline can then apply these manifests to an AKS cluster.

This provides:

Repeatability
Version control
Change tracking
Easier rollback
Consistent environments
Automation
Infrastructure-as-code characteristics

26. Manifest Files and CI/CD

Manifest files fit naturally into CI/CD processes.

A typical workflow might look like:

			
Developer commits code
        ↓
Build container image
        ↓
Push image to ACR
        ↓
Update Kubernetes manifest
        ↓
CI/CD pipeline
        ↓
kubectl apply
        ↓
AKS Deployment
        ↓
Rolling update

		

The image and Kubernetes configuration should generally be treated as separate concerns.

The container image defines the application artifact.

The Kubernetes manifest defines how that artifact should be deployed.

27. Example Complete Manifest

The following example illustrates a simplified AI inference API deployed to AKS.

			
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference-api
  template:
    metadata:
      labels:
        app: inference-api
    spec:
      containers:
        - name: inference-api
          image: myregistry.azurecr.io/inference-api:1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: inference-api
spec:
  selector:
    app: inference-api
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

		

Deploy it with:

kubectl apply -f inference-api.yaml

Then verify:

			
kubectl get deployments
kubectl get pods
kubectl get services

The Service can expose the application externally through an Azure load balancer.

28. Important Commands to Know

Command	Purpose
`az aks get-credentials`	Configure `kubectl` to connect to an AKS cluster
`kubectl get nodes`	View cluster nodes
`kubectl apply -f file.yaml`	Create/update resources from a manifest
`kubectl get deployments`	View Deployments
`kubectl get pods`	View Pods
`kubectl get services`	View Services
`kubectl describe pod`	Inspect detailed Pod information
`kubectl describe deployment`	Inspect a Deployment
`kubectl logs`	View container logs
`kubectl get pods -o wide`	View Pods with additional placement/network information
`kubectl delete -f file.yaml`	Delete resources defined by a manifest
`kubectl get events`	View Kubernetes events

A particularly important distinction is:

kubectl apply -f manifest.yaml

is generally preferred for declarative management because it creates or updates the resources described by the manifest.

29. Key Exam Takeaways

For AI-200, make sure you understand these relationships:

Manifest

Defines the desired state of Kubernetes resources.

Deployment

Manages replicated Pods and supports controlled updates.

Pod

The basic execution unit containing one or more containers.

Service

Provides a stable network endpoint for a group of Pods.

Labels

Identify resources.

Selectors

Determine which resources another resource targets.

ConfigMap

Stores non-sensitive configuration.

Secret

Stores sensitive configuration within Kubernetes.

`kubectl apply`

Applies a declarative manifest.

ACR

Commonly stores the container images consumed by AKS.

Readiness probe

Determines whether a Pod should receive traffic.

Liveness probe

Determines whether a container should continue running.

Startup probe

Determines whether an application has successfully started.

`kubectl describe`

Useful for diagnosing Kubernetes resource and scheduling problems.

`kubectl logs`

Useful for diagnosing application/container failures.

Practice Exam Questions

Question 1

You have an AI inference application running in AKS. The application should run three identical instances, and Kubernetes should replace an instance if its Pod fails.

Which Kubernetes resource should you use?

A. Deployment

B. Service

C. ConfigMap

D. Ingress

Answer: A

Explanation

A Deployment manages replicated Pods and maintains the desired number of replicas. If a Pod managed by the Deployment fails, Kubernetes can create a replacement.

A Service provides network access to Pods but doesn’t manage their lifecycle. A ConfigMap stores configuration, and an Ingress manages HTTP/HTTPS routing.

Question 2

An AKS application has a Deployment with the following Pod label:

			
labels:
  app: inference-api

The application is exposed through a Service, but the Service isn’t routing traffic to the Pods.

The Service contains:

			
selector:
  app: ai-service

What should you change?

A. Change the Deployment’s replicas value

B. Change the Service selector to app: inference-api

C. Change the Service type to ClusterIP

D. Change the container’s containerPort

Answer: B

Explanation

The Service selector must match the labels assigned to the target Pods. The Pods are labeled:

app: inference-api

Therefore, the Service should use:

			
selector:
  app: inference-api

Changing the replica count or Service type does not correct the selector mismatch.

Question 3

You have modified a Kubernetes Deployment manifest to use version 2 of an AI inference container:

image: myregistry.azurecr.io/inference-api:v2

What command should you normally use to apply the change?

A. kubectl restart deployment

B. kubectl create deployment

C. kubectl apply -f deployment.yaml

D. az aks update --image v2

Answer: C

Explanation

kubectl apply -f applies the desired state represented by the manifest. When the Deployment’s Pod template changes, Kubernetes can perform a rolling update to replace Pods running the previous image.

Question 4

An AI API deployed to AKS takes several minutes to initialize because it loads a large machine-learning model. Kubernetes is restarting the container before initialization completes.

Which configuration is most appropriate?

A. Increase the Service’s targetPort

B. Add a startup probe

C. Add a ConfigMap

D. Change the Service to LoadBalancer

Answer: B

Explanation

A startup probe is designed for applications that require significant time to initialize. It allows Kubernetes to determine when startup has completed before normal liveness checking takes effect.

A readiness probe controls whether traffic should be sent to the application, while a startup probe is specifically useful during initialization.

Question 5

An AKS Deployment has been created, but its Pods remain in the Pending state.

Which command is most useful for investigating scheduling-related events for a specific Pod?

A. kubectl describe pod <pod-name>

B. kubectl logs <pod-name>

C. kubectl get service <service-name>

D. kubectl apply -f deployment.yaml

Answer: A

Explanation

kubectl describe pod provides detailed information about the Pod, including Kubernetes events. These events can reveal issues such as insufficient resources, unsatisfied scheduling constraints, or volume problems.

kubectl logs is more useful when a container has started and is producing application logs.

Question 6

You want an application in AKS to be reachable from outside the cluster using an Azure-provided external load balancer.

Which Service type should you specify?

A. ClusterIP

B. ExternalName

C. NodePort

D. LoadBalancer

Answer: D

Explanation

A Service with:

type: LoadBalancer

requests an external load balancer through the cloud provider integration. In AKS, this can provide an externally reachable IP address.

ClusterIP is primarily for internal cluster access.

Question 7

An AI application requires the following configuration:

			
MODEL_NAME=customer-support-model
LOG_LEVEL=Information

The values are not sensitive and should be changed independently of the container image.

Which Kubernetes resource is most appropriate?

A. Secret

B. ConfigMap

C. Deployment replica

D. Service

Answer: B

Explanation

A ConfigMap is designed to store non-sensitive configuration data separately from the application container image.

A Kubernetes Secret is intended for sensitive information such as credentials and keys.

Question 8

You have successfully deployed an AKS application, but the Pods show ImagePullBackOff.

The Deployment specifies:

image: myregistry.azurecr.io/inference-api:v5

Which is the most likely category of problem?

A. The Service selector doesn’t match the Pod labels

B. The readiness probe is failing

C. AKS cannot successfully retrieve the specified container image

D. The Deployment has too many replicas

Answer: C

Explanation

ImagePullBackOff indicates that Kubernetes is having difficulty pulling the container image. Potential causes include an incorrect image name or tag, an image that doesn’t exist, or insufficient authorization to access a private registry.

Service selectors and readiness probes are unrelated to the initial image-pull operation.

Question 9

You want an AKS application to receive traffic only after its /health endpoint indicates that it is ready.

Which probe should you configure?

A. Readiness probe

B. Liveness probe

C. Startup probe

D. Resource probe

Answer: A

Explanation

A readiness probe determines whether a container is ready to receive traffic. If the readiness probe fails, Kubernetes can keep the Pod out of the Service’s ready endpoints.

A liveness probe determines whether a container should continue running, while a startup probe is intended to determine whether a slow-starting application has completed initialization.

Question 10

An AKS application is deployed from a YAML file containing both a Deployment and a Service separated by ---.

Which command can be used to create or update both resources according to the manifest?

A. kubectl get -f application.yaml

B. kubectl logs -f application.yaml

C. kubectl describe -f application.yaml

D. kubectl apply -f application.yaml

Answer: D

Explanation

kubectl apply -f processes the resources defined in the manifest and creates or updates them to match the desired state.

The --- separator allows multiple Kubernetes resource definitions to be included in the same YAML file.

Final Review

For this AI-200 topic, the most important thing is to understand how a declarative Kubernetes manifest translates into a running application on AKS.

The core flow is:

			
Container image
      ↓
Azure Container Registry
      ↓
Kubernetes Deployment manifest
      ↓
kubectl apply
      ↓
Deployment
      ↓
ReplicaSet
      ↓
Pods
      ↓
Service
      ↓
Application endpoint

		

When troubleshooting, think systematically:

			
Can't deploy?
    ↓
Can AKS pull the image?
    ↓
Is the Pod scheduled?
    ↓
Is the container starting?
    ↓
Are startup/readiness/liveness probes correct?
    ↓
Do Service selectors match Pod labels?
    ↓
Are ports configured correctly?

		

If you understand that flow—and can recognize Deployment vs. Pod vs. Service vs. ConfigMap vs. Secret, along with the purpose of kubectl apply, labels/selectors, probes, and common Pod states—you will have a strong foundation for the manifest-based AKS questions in AI-200.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification August 15, 2026

Implement event-driven scaling by using Kubernetes Event‑driven Autoscaling (KEDA) in Container Apps (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container-orchestrated solutions
      --> Implement event-driven scaling by using Kubernetes Event‑driven Autoscaling (KEDA) in Container Apps

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Modern AI applications frequently perform work asynchronously. Instead of processing every request synchronously, an application might place work onto a queue or event stream and have one or more containerized workers process those events.

This architecture creates an important scaling question:

How can the application automatically add or remove container instances based on the amount of work waiting to be processed?

Kubernetes Event-driven Autoscaling (KEDA) provides the answer.

Azure Container Apps uses KEDA to support event-driven autoscaling. A container app can use KEDA-based scaling rules to respond to events and metrics from supported sources such as Azure Service Bus, Azure Event Hubs, Apache Kafka, and Redis. Container Apps manages the KEDA integration for you, so you don’t install or operate KEDA yourself.

For the AI-200 exam, the important skill is understanding when to use KEDA, how KEDA determines replica counts, how scaling rules are configured, and how authentication and scale limits affect the resulting application behavior.

1. What Is KEDA?

Kubernetes Event-driven Autoscaling (KEDA) is an autoscaling component designed to scale containerized workloads based on events or external metrics.

Traditional autoscaling commonly uses resource metrics such as:

CPU utilization
Memory utilization

Those metrics can be useful, but they don’t always represent the actual workload.

Consider an AI document-processing application:

                ┌──────────────────┐
Documents ────► │  Service Bus     │
                │      Queue       │
                └────────┬─────────┘
                         │
                         │ Pending messages
                         ▼
                ┌──────────────────┐
                │ KEDA scaler      │
                └────────┬─────────┘
                         │
                  Scale decision
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
        Container App         Container App
          Replica 1             Replica 2

If there are only a few messages, the application may need only one replica.

If thousands of messages are waiting, additional replicas can be created to process the workload concurrently.

This is event-driven autoscaling.

2. KEDA in Azure Container Apps

Azure Container Apps incorporates KEDA into its scaling architecture.

This is an important exam distinction:

You don’t deploy and manage a separate KEDA installation for an Azure Container App.

Instead, you configure a scale rule on the container app. Azure Container Apps uses KEDA behind the scenes to evaluate the rule and determine how many replicas are needed.

Conceptually:

			
External event source
        │
        ▼
   KEDA scaler
        │
        ▼
Scale rule evaluation
        │
        ▼
Desired replica count
        │
        ▼
Azure Container Apps
        │
        ├── Replica 1
        ├── Replica 2
        ├── Replica 3
        └── ...

		

This makes KEDA particularly useful for background workers and asynchronous AI workloads.

3. Why Event-Driven Scaling Is Important for AI Applications

AI workloads frequently have unpredictable demand.

For example, imagine a document-processing application:

Users upload documents.
Documents are placed into an Azure Service Bus queue.
Containerized workers retrieve documents.
Workers send documents to an AI service.
Results are stored in a database.

During periods of low activity, perhaps only one worker is necessary.

During a large batch upload, hundreds or thousands of documents might be waiting.

A fixed number of replicas creates two problems:

Too few replicas

			
1 worker
   │
   ├── Document 1
   ├── Document 2
   ├── Document 3
   ├── ...
   └── Document 10,000

		

Processing becomes slow.

Too many replicas

			
20 workers
   │
   └── Almost nothing to process

Resources are unnecessarily consumed.

KEDA allows the application to dynamically respond to the workload.

4. KEDA Versus CPU-Based Autoscaling

A common exam scenario is determining whether resource-based scaling or event-based scaling is more appropriate.

Suppose a worker application consumes messages from Azure Service Bus.

CPU usage might look like this:

Queue Messages	CPU Usage
0	5%
100	15%
1,000	20%
10,000	25%

CPU isn’t necessarily a good representation of the amount of work waiting.

KEDA can instead monitor the queue itself.

For example:

			
Target = 20 messages per replica
messages → 1 replica
messages → 2 replicas
messages → 5 replicas
messages → 10 replicas

		

This makes the scaling decision directly related to the workload.

5. KEDA Scalers

A KEDA scaler connects KEDA to an external event source or metric.

Azure Container Apps supports KEDA-based custom scaling rules for various event sources.

Common examples include:

Azure Service Bus
Azure Event Hubs
Apache Kafka
Redis
Azure Queue Storage
Other supported KEDA scalers through custom rules

Azure Container Apps also supports HTTP and TCP scaling rules, but these aren’t the same thing as event-driven KEDA scaling.

For the exam, remember:

HTTP scaling and event-driven scaling are different scaling mechanisms.

6. Container Apps Scale Rules

Scaling is configured through the container app’s scale configuration.

A scale configuration contains concepts such as:

minReplicas
maxReplicas
rules
polling interval
cooldown period

A simplified conceptual configuration looks like this:

			
scale:
    minReplicas: 0
    maxReplicas: 10
    rules:
        - name: service-bus-rule
          type: azure-servicebus
          metadata:
              queueName: orders
              messageCount: 20

		

The exact metadata depends on the KEDA scaler being used.

The important exam concept is the relationship:

			
Scale Rule
   │
   ├── Scaler type
   ├── Metadata
   └── Authentication
          │
          ▼
        KEDA
          │
          ▼
   Desired replicas

		

7. `minReplicas`

minReplicas specifies the minimum number of replicas that the application can maintain.

For example:

minReplicas = 1

means that the application won’t scale below one replica.

This is useful when:

The application must always be available.
Cold-start latency is undesirable.
The workload can’t tolerate scaling to zero.

By contrast:

minReplicas = 0

allows the application to scale down to zero when there is no workload.

Azure Container Apps supports a minimum of zero replicas and a maximum configurable replica count of up to 1,000.

8. `maxReplicas`

maxReplicas establishes the upper limit on scaling.

For example:

			
minReplicas: 0
maxReplicas: 20

means:

0 ≤ replicas ≤ 20

Even if the event source contains a massive backlog, the application won’t exceed the configured maximum.

This is important for:

Controlling costs
Protecting downstream services
Preventing excessive concurrency
Preventing an application from overwhelming a database or AI service

Exam tip

If a question asks:

“How can you prevent an event-driven application from creating an excessive number of replicas?”

Look for:

Configure maxReplicas.

9. Target Values and Scaling

Many KEDA scalers use a target value that represents the desired workload per replica.

For example, consider:

messageCount = 20

Conceptually, this means the scaler targets approximately 20 messages per replica.

If there are 100 messages:

			
Desired replicas = ceil(100 / 20)
Desired replicas = 5

Therefore:

			
100 messages
      │
      ▼
Target = 20 messages/replica
      │
      ▼
5 replicas

		

Azure Container Apps describes the general scaling calculation as:

			
desiredReplicas =
    ceil(currentMetricValue / targetMetricValue)

subject to the configured scaling limits and Container Apps’ scaling behavior.

10. Example: Azure Service Bus

Suppose an AI application processes image-analysis requests from an Azure Service Bus queue.

The scaling rule specifies:

			
messageCount = 10
minReplicas = 0
maxReplicas = 10

The approximate relationship is:

Messages	Desired Replicas
0	0
1–10	1
11–20	2
21–30	3
51–60	6
91–100	10
500	10

The final example is limited by maxReplicas.

Therefore, even if 500 messages are waiting, the application won’t create 50 replicas when the maximum is 10.

11. Polling Interval

KEDA periodically checks the event source.

Azure Container Apps uses a default KEDA polling interval of 30 seconds for custom scale rules.

Conceptually:

			
T0
 │
 ├── KEDA checks queue
 │
T+30 sec
 │
 ├── KEDA checks queue
 │
T+60 sec
 │
 ├── KEDA checks queue
 │
...

		

This is important because event-driven scaling isn’t necessarily instantaneous.

If a question describes a workload that suddenly receives messages and asks why scaling doesn’t happen immediately, the polling interval may be relevant.

12. Cooldown Period

The cooldown period determines how long KEDA waits before scaling an application from its final active replica down to zero after the event source becomes inactive.

The default cooldown period for Container Apps custom scaling is 300 seconds.

For example:

			
Messages arrive
     │
     ▼
Scale out
     │
     ▼
Messages processed
     │
     ▼
Queue becomes empty
     │
     ▼
Cooldown period
     │
     ▼
Scale to zero

		

An important distinction is that the cooldown period specifically affects scaling from the final replica to zero; it isn’t simply a universal delay applied to every scale-in operation.

13. Scale-to-Zero

One of the major advantages of event-driven scaling is the ability to scale an application to zero.

For example:

			
No work
   │
   ▼
0 replicas
   │
   │ New event arrives
   ▼
1 replica
   │
   ▼
More events
   │
   ▼
5 replicas

		

This is especially useful for workloads that aren’t continuously active.

Examples include:

Document processing
Image processing
AI inference jobs
Data enrichment
Background processing
Queue consumers

When the workload disappears, the application can eventually return to zero replicas.

Azure Container Apps doesn’t charge usage charges for a container app while it is scaled to zero.

14. Authentication for KEDA Scale Rules

A KEDA scaler often needs permission to inspect the external event source.

For example, a Service Bus scaler needs access to Service Bus.

Azure Container Apps supports authentication for scale rules using:

Secrets
Managed identities for supported Azure resources

The authentication configuration is associated with the scale rule rather than requiring application code to perform the scaling operation.

Managed identity

For Azure resources, managed identity is often preferable because the application doesn’t need to store a long-lived credential.

Conceptually:

			
Container App
     │
     │ Managed Identity
     ▼
Microsoft Entra ID
     │
     ▼
Azure Service Bus

		

This is generally preferable to embedding credentials in application source code.

15. Secret-Based Authentication

Scale rules can also reference secrets.

Conceptually:

			
Container App
    │
    ├── Secret
    │
    ▼
KEDA scale rule
    │
    ▼
Event source

		

For example, a Service Bus connection string could be stored as a Container Apps secret and referenced by the scale rule.

Exam distinction

Don’t confuse:

Application authentication

with:

Scaler authentication

The application itself may have its own credentials or managed identity, while KEDA separately needs authorization to inspect the event source.

16. Multiple Scaling Rules

A container app can have multiple scaling rules.

For example:

			
Container App
     │
     ├── HTTP rule
     │
     ├── Service Bus rule
     │
     └── Redis rule

		

When multiple rules are configured, the application scales when the first applicable scaling condition is met.

This means you can combine different workload signals.

For example:

			
HTTP traffic ────────┐
                     │
Service Bus backlog ─┼──► Scaling decision
                     │
Redis events ────────┘

		

17. KEDA and Azure Container Apps Revisions

A particularly important Azure Container Apps concept is that changing scaling rules creates a new revision of the container app. A revision is an immutable snapshot of the application configuration.

Conceptually:

			
Revision 1
    │
    ├── Old scaling rules
    │
    ▼
Update scaling configuration
    │
    ▼
Revision 2
    │
    └── New scaling rules

		

This matters when managing production applications using revision-based deployment strategies.

18. KEDA and Dapr

KEDA can also be used with Dapr-based applications.

For example, an application could use Dapr pub/sub:

			
Publisher
    │
    ▼
Dapr Pub/Sub
    │
    ▼
Subscriber Container App
    │
    ▼
KEDA

		

KEDA can scale the subscriber based on pending events/messages.

In this scenario, KEDA can scale both the application and its Dapr sidecar based on the workload.

19. KEDA Versus Event-Driven Container Apps Jobs

Azure Container Apps supports both:

Container Apps

A container app normally maintains a number of replicas that continuously process work.

			
Queue
  │
  ▼
Container App
  ├── Replica 1
  ├── Replica 2
  └── Replica 3

		

Event-driven Container Apps Jobs

An event can instead trigger individual job executions.

			
Queue
  │
  ├── Event 1 ──► Job execution 1
  ├── Event 2 ──► Job execution 2
  └── Event 3 ──► Job execution 3

		

Both use KEDA-based scaling concepts, but the result is different.

For an application, the scaling rule determines the number of replicas.

For an event-driven job, the scaling rule determines the number of job executions to start.

Exam tip

If the question says:

“Each event should result in a separate container execution.”

Consider an event-driven Container Apps Job rather than a continuously running container app.

20. KEDA Configuration Concepts to Know

For AI-200, be comfortable recognizing these concepts:

Concept	Purpose
Scaler	Connects KEDA to an event source or metric
Scale rule	Defines how Container Apps uses a scaler
Metadata	Provides scaler-specific configuration
Authentication	Allows KEDA to access the event source
minReplicas	Lowest number of replicas
maxReplicas	Highest number of replicas
Polling interval	How frequently KEDA checks an event source
Cooldown period	Delay associated with scaling the final replica to zero
Scale-to-zero	Allows inactive applications to have zero replicas
Replica	An active instance of the container app revision

21. Example Architecture

Consider an AI document-classification system.

                         ┌──────────────────┐
                         │   Web/API App    │
                         └────────┬─────────┘
                                  │
                                  │ Submit document
                                  ▼
                         ┌──────────────────┐
                         │ Azure Service    │
                         │ Bus Queue        │
                         └────────┬─────────┘
                                  │
                           Pending messages
                                  │
                                  ▼
                         ┌──────────────────┐
                         │      KEDA        │
                         │     Scaler       │
                         └────────┬─────────┘
                                  │
                           Scaling decision
                                  │
                                  ▼
                    ┌─────────────────────────┐
                    │    Azure Container App  │
                    │                         │
                    │ ┌────┐ ┌────┐ ┌────┐   │
                    │ │ R1 │ │ R2 │ │ R3 │...│
                    │ └────┘ └────┘ └────┘   │
                    └───────────┬─────────────┘
                                │
                                ▼
                         Azure AI Service
                                │
                                ▼
                            Data Store

The important point is that KEDA doesn’t process the messages.

KEDA’s responsibility is to determine how many replicas should be running.

The application replicas are responsible for processing the messages.

22. Common Exam Scenarios

Scenario 1: Queue backlog

A containerized AI worker processes Service Bus messages. The application should automatically add workers as the queue backlog increases.

Use KEDA event-driven scaling.

Scenario 2: Scale to zero

The application should consume no running replicas when there are no messages.

Configure:

minReplicas = 0

and use an appropriate event-driven scale rule.

Scenario 3: Limit cost

A sudden event spike must not cause more than 20 workers.

Configure:

maxReplicas = 20

Scenario 4: Avoid stored credentials

KEDA needs access to an Azure Service Bus resource, and the organization doesn’t want connection strings stored.

Use an appropriate managed identity configuration.

Scenario 5: Separate execution per event

Each event should start an independent container execution.

Consider an event-driven Container Apps Job rather than a continuously running container app.

23. Common Mistakes to Avoid

Mistake 1: Installing KEDA manually

For Azure Container Apps, you don’t need to deploy your own KEDA installation.

Remember: Container Apps provides the KEDA integration.

Mistake 2: Assuming KEDA only works with Kubernetes clusters

KEDA originated in the Kubernetes ecosystem, but Azure Container Apps exposes KEDA functionality without requiring you to manage Kubernetes infrastructure.

Mistake 3: Confusing KEDA with CPU autoscaling

KEDA is particularly valuable when scaling should be driven by external events or metrics, such as queue length or event backlog.

Mistake 4: Forgetting `maxReplicas`

Without an appropriate maximum, a large workload can potentially result in substantial scale-out.

Always consider:

			
minReplicas
maxReplicas

Mistake 5: Assuming scaling is instantaneous

KEDA polls event sources. The default polling interval for custom Container Apps scaling rules is 30 seconds, so there can be a delay between a change in workload and the scaling decision.

Mistake 6: Confusing cooldown with polling

These are different:

Polling interval

How frequently KEDA checks the event source.

Cooldown period

How long KEDA waits before scaling the final replica to zero after the workload becomes inactive.

24. AI-200 Exam Takeaways

For the exam, make sure you can answer these questions:

What is KEDA?

A Kubernetes-based event-driven autoscaling mechanism used by Azure Container Apps to scale workloads based on external events and metrics.

Why use KEDA?

When application demand is better represented by an external event source—such as a queue backlog—than by CPU or memory utilization.

Do you install KEDA in Container Apps?

No. Azure Container Apps provides the KEDA integration.

What controls the minimum number of replicas?

minReplicas

What controls the maximum?

maxReplicas

What determines the type of event source?

The KEDA scaler type, such as:

azure-servicebus

What does scaler metadata provide?

The scaler-specific information needed to monitor the event source and determine scaling.

Can Container Apps scale to zero?

Yes, when configured appropriately, such as with minReplicas: 0.

What is the default polling interval?

30 seconds for custom KEDA scale rules.

What is the default cooldown period?

300 seconds for custom scaling, with the cooldown specifically applying to scaling from the final replica to zero.

What happens when multiple scale rules exist?

The application begins scaling when the condition for the first applicable rule is met.

Practice Exam Questions

Question 1

An AI application running in Azure Container Apps processes messages from an Azure Service Bus queue. The application should automatically increase the number of replicas when the number of pending messages increases.

Which technology should you use?

A. Kubernetes Event-driven Autoscaling (KEDA)
B. Azure Traffic Manager
C. Azure Front Door
D. Azure DNS

Answer: A

Explanation

KEDA is designed for event-driven autoscaling. In Azure Container Apps, KEDA can monitor supported event sources such as Azure Service Bus and adjust the number of application replicas according to the workload.

The other services are primarily concerned with traffic routing or DNS rather than workload-driven container scaling.

Question 2

You configure an Azure Container App with the following settings:

			
minReplicas: 0
maxReplicas: 10

The application uses a KEDA-based scale rule and currently has no events to process.

What is the expected minimum number of running replicas?

A. 0
B. 5
C. 1
D. 10

Answer: A

Explanation

minReplicas specifies the minimum number of replicas. Setting it to 0 permits the application to scale to zero when the workload is inactive.

This is one of the major benefits of event-driven scaling for intermittently used workloads.

Question 3

An AI worker consumes messages from an Azure Service Bus queue. The KEDA scale rule uses a target of 20 messages per replica. There are currently 100 messages waiting.

Ignoring scaling limits and other scaling behavior, approximately how many replicas does the target calculation request?

A. 2
B. 5
C. 20
D. 100

Answer: B

Explanation

The target calculation is conceptually:

			
desiredReplicas = ceil(currentMetricValue / targetMetricValue)
desiredReplicas = ceil(100 / 20)
desiredReplicas = 5

Therefore, the target is approximately 5 replicas.

Question 4

An organization wants to ensure that an event-driven Container App never scales beyond 25 replicas, even when a large backlog accumulates.

Which setting should you configure?

A. pollingInterval
B. cooldownPeriod
C. minReplicas
D. maxReplicas

Answer: D

Explanation

maxReplicas establishes the maximum number of replicas that the container app can use for the configured scaling configuration.

For this requirement, configure:

maxReplicas: 25

pollingInterval controls how frequently the event source is checked, while cooldownPeriod relates to scale-down behavior. minReplicas controls the lower bound.

Question 5

A developer wants KEDA in an Azure Container App to determine scaling based on the number of pending messages in Azure Service Bus.

Which component identifies the event source and its associated scaling behavior?

A. Azure Monitor workbook
B. Container Apps ingress configuration
C. KEDA scaler
D. Azure Load Balancer

Answer: C

Explanation

A KEDA scaler connects the autoscaling mechanism to an event source or external metric. The scaler type and associated metadata define how KEDA obtains the workload information.

Ingress and load-balancing configurations don’t provide this event-driven autoscaling capability.

Question 6

An application uses a KEDA custom scale rule in Azure Container Apps. The administrator wants to understand how frequently KEDA checks the external event source by default.

Which interval should the administrator expect?

A. 5 seconds
B. 30 seconds
C. 5 minutes
D. 15 minutes

Answer: B

Explanation

The default polling interval for custom KEDA scaling rules in Azure Container Apps is 30 seconds.

This means event-driven scaling isn’t necessarily evaluated continuously or instantaneously.

Question 7

An AI application uses an Azure Service Bus queue. The organization wants KEDA to access the Azure resource without storing a long-lived Service Bus credential in the application configuration.

Which approach is most appropriate?

A. Disable authentication for the scale rule
B. Store the credential in application source code
C. Use a managed identity where supported
D. Increase the maximum replica count

Answer: C

Explanation

Azure Container Apps supports managed identity authentication for supported Azure resource scale rules.

Managed identities allow Azure resources to authenticate without requiring application developers to embed long-lived credentials in source code or configuration.

Question 8

An event-driven Container App has finished processing its queue. The application currently has one replica, and the queue remains empty.

The application is configured with the default 300-second cooldown period.

What is the purpose of the cooldown period?

A. Determine how frequently the queue is polled
B. Determine the maximum number of replicas
C. Determine the target number of messages per replica
D. Delay scaling the final replica to zero after the workload becomes inactive

Answer: D

Explanation

The cooldown period is associated with scaling from the final active replica to zero.

For Container Apps custom scaling rules, the default cooldown period is 300 seconds.

It should not be confused with the polling interval, which determines how frequently KEDA checks the event source.

Question 9

An Azure Container App has two scaling rules:

An HTTP scaling rule
An Azure Service Bus KEDA scaling rule

The Service Bus queue suddenly contains a large backlog while HTTP traffic remains low.

What happens?

A. The application can scale based on the Service Bus rule
B. Only the HTTP rule is evaluated
C. The application must use CPU scaling instead
D. The two rules are averaged before scaling

Answer: A

Explanation

Azure Container Apps can have multiple scaling rules. The application begins scaling when the condition for an applicable rule is met.

Therefore, a Service Bus backlog can cause scaling even if HTTP traffic isn’t high enough to trigger the HTTP rule.

Question 10

A development team has a workload in which each incoming event should trigger a separate container execution. The workload doesn’t need a continuously running pool of worker replicas.

Which Azure Container Apps capability is the best fit?

A. HTTP ingress scaling
B. Event-driven Container Apps Jobs
C. Azure Traffic Manager
D. TCP ingress scaling

Answer: B

Explanation

Event-driven Container Apps Jobs are designed for workloads where events trigger individual job executions.

This differs from a normal Container App, where KEDA determines how many replicas of the application should be running to process the workload.

For example:

			
Event 1 → Job execution 1
Event 2 → Job execution 2
Event 3 → Job execution 3

A continuously running container application would instead maintain a pool of replicas that process events.

Final Exam Cheat Sheet

Topic	Key Point
KEDA	Event-driven autoscaling
Azure Container Apps + KEDA	KEDA integration is managed by Container Apps
Primary use case	Scale based on external events/metrics
Examples	Service Bus, Event Hubs, Kafka, Redis
`minReplicas`	Minimum replicas
`maxReplicas`	Maximum replicas
`minReplicas = 0`	Allows scale-to-zero
Scaler	Connects KEDA to an event source
Metadata	Configures the scaler
Authentication	Secrets or managed identity where supported
Default polling interval	30 seconds
Default cooldown	300 seconds
Target calculation	`ceil(metric / target)` conceptually
Multiple rules	Scaling can begin when an applicable rule triggers
Scaling-rule changes	Create a new Container Apps revision
Container App	Scales replicas
Event-driven Container Apps Job	Scales job executions
Primary benefit	Efficient scaling based on actual workload
Major advantage	Can scale inactive workloads to zero

The key idea to remember for AI-200 is simple: KEDA allows Azure Container Apps to scale containerized workloads according to events and external workload metrics rather than relying solely on traditional resource utilization such as CPU or memory.

Go to the AI-200 Exam Prep Hub main page

AI-200, azure, Cloud computing, Microsoft Certification August 15, 2026

Deploy applications to Azure Container Apps, including environment configuration and revision management (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Deploy applications to Azure Container Apps, including environment configuration and revision management

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Azure Container Apps is a serverless container platform designed for running modern applications and microservices without requiring developers to manage the underlying Kubernetes infrastructure. For the AI-200 exam, developers should understand not only how to deploy a containerized application, but also how to configure its Container Apps environment, manage application settings, and use revisions to safely deploy and operate different versions of an application.

This topic is particularly important because Azure Container Apps separates the concepts of the application environment, the container application, and the revision. Understanding those boundaries makes many exam questions much easier to answer.

1. What Is Azure Container Apps?

Azure Container Apps provides a managed platform for running containerized applications while abstracting much of the infrastructure management associated with Kubernetes.

It is well suited for applications such as:

REST APIs
Web applications
Microservices
Background processing services
Event-driven applications
AI inference services
Containerized application backends

Unlike Azure Kubernetes Service, developers do not need to manage Kubernetes clusters, nodes, or the Kubernetes control plane.

Azure Container Apps can provide:

Containerized application hosting
Automatic scaling
Scale-to-zero capabilities
HTTP and TCP ingress
Service-to-service communication
Revisions and traffic splitting
Secrets and configuration
Managed identities
Dapr integration
Logging and monitoring
Workload profiles

For AI applications, Container Apps can be particularly useful for hosting APIs, inference services, orchestration components, and other containerized workloads.

2. Understand the Container Apps Environment

A Container Apps environment is a secure boundary around a group of Container Apps.

Multiple Container Apps can be deployed into the same environment. Apps within the same environment can share important infrastructure characteristics, including networking and logging. Microsoft describes the environment as a secure boundary for a group of container apps.

A useful mental model is:

Azure subscription → Resource group → Container Apps environment → Container Apps → Revisions

For example:

			
Subscription
│
└── Resource Group
    │
    └── Container Apps Environment
        │
        ├── customer-api
        │   ├── Revision 1
        │   ├── Revision 2
        │   └── Revision 3
        │
        ├── recommendation-api
        │   ├── Revision 1
        │   └── Revision 2
        │
        └── document-processor
            └── Revision 1

		

The environment therefore provides infrastructure-level isolation and shared capabilities, while the individual Container App represents an application or service running inside that environment.

3. Why the Environment Matters

When creating a Container App, you either select an existing Container Apps environment or create a new one.

Environment configuration can affect:

Networking
Logging
Workload profiles
Application isolation
Communication between applications
Infrastructure configuration

For example, applications deployed into the same environment can communicate with one another using Container Apps’ internal networking capabilities.

The environment can also be associated with logging infrastructure such as a Log Analytics workspace.

Exam Tip

If a question says that several Container Apps need to share a common environment, networking boundary, or logging configuration, think about the Container Apps environment rather than creating separate environments for every application.

4. Creating a Container App

A typical deployment involves the following conceptual steps:

Create or select a resource group.
Create or select a Container Apps environment.
Specify the container image.
Configure compute resources.
Configure environment variables and secrets.
Configure ingress if the application needs to receive traffic.
Configure scaling.
Deploy the application.
Monitor the resulting revision.

For example, Azure CLI can deploy an existing container image with a command conceptually similar to:

			
az containerapp create \
  --name my-container-app \
  --resource-group my-resource-group \
  --environment my-container-environment \
  --image myregistry.azurecr.io/myapp:v1 \
  --target-port 80 \
  --ingress external

		

The important exam concept is not memorizing the exact command syntax. Instead, understand which configuration belongs to the environment and which belongs to the Container App.

5. Container App Configuration vs. Revision Configuration

One of the most important concepts for AI-200 is that not every change to a Container App creates a new revision.

Azure Container Apps distinguishes between:

Revision-scope changes

These changes define the version of the application and result in a new revision.

Examples include changes to:

Container image
Container configuration
Container resources
Environment variables associated with the container template
Scale configuration
Scale rules
Container commands and arguments
Probes
Volumes and mounts
Revision suffix

The Container Apps API documentation describes the template as the versioned application definition, and changes to the template result in a new immutable revision.

Application-scope changes

These changes affect the Container App configuration rather than creating a new version of the application.

Examples include:

Revision mode
Ingress configuration
Traffic rules
Secrets
Registry credentials
Dapr configuration
Other application-level configuration

These settings apply to the application rather than representing a new immutable revision.

Exam shortcut

When deciding whether a change creates a revision, ask:

Does this change define the versioned application template?

If yes, it is generally a revision-scope change.

If it changes how the application is configured or exposed without changing the application template, it is generally an application-scope change.

6. What Is a Revision?

A revision is an immutable snapshot of a Container App’s versioned configuration.

Think of a revision as a deployable version of the application.

For example:

			
customer-api
│
├── Revision 1 → v1 container image
├── Revision 2 → v2 container image
└── Revision 3 → v3 container image

		

Once created, a revision is immutable.

If you change the container image from:

myapp:v1

to:

myapp:v2

Azure Container Apps creates a new revision rather than modifying the existing revision.

This provides an important deployment-management capability:

A deployed revision represents a known version of the application.

Microsoft’s documentation describes revisions as immutable, versioned snapshots that can remain available for rollback, testing, or traffic management.

7. Why Revisions Are Important

Revisions provide several important capabilities.

Version management

You can identify different versions of an application.

Safe deployments

A new revision can be deployed without immediately replacing the existing version in multiple-revision scenarios.

Rollbacks

If a new version fails, traffic can be directed back to a previous revision.

A/B testing

Different revisions can receive different percentages of traffic.

Blue-green deployments

One revision can serve production traffic while another is deployed and validated before switching traffic.

Testing

A new revision can be tested before directing production traffic to it.

These capabilities make revisions particularly valuable for AI applications where changes to models, inference code, prompts, dependencies, or APIs may need controlled deployment.

8. Single Revision Mode

Azure Container Apps supports single revision mode and multiple revision mode. Single revision mode is the default.

In single revision mode:

Only one revision is active at a time.
A new revision is created when a revision-scoped change is deployed.
Azure manages the transition from the old revision to the new revision.
Traffic moves to the new revision after it is ready.
The old revision is eventually deprovisioned.

This mode is useful when the desired deployment model is essentially:

“Deploy the new version and replace the old version.”

For example:

			
Before deployment:
100% traffic
     │
     ▼
Revision 1
After deployment:
100% traffic
     │
     ▼
Revision 2

		

9. Zero-Downtime Deployment

Single revision mode is designed to avoid unnecessary downtime during deployment.

When a new revision is created, the existing revision continues serving traffic while the new revision is provisioned.

The new revision must become ready before traffic is moved.

Readiness involves factors such as:

Successful provisioning
Required replicas becoming available
Startup probes passing
Readiness probes passing

Therefore, if a new revision fails to become ready, the existing revision can continue serving traffic rather than immediately being replaced.

Exam scenario

Suppose:

Revision 1 is healthy.
Revision 2 is deployed.
Revision 2 fails its readiness checks.

The safest answer is generally that Revision 1 continues receiving traffic in single revision mode while Revision 2 fails to become ready.

10. Multiple Revision Mode

Multiple revision mode allows multiple revisions to remain active simultaneously.

This provides significantly more control over deployments.

For example:

                 ┌── Revision 1 ── 80%
Incoming traffic ┤
                 └── Revision 2 ── 20%

This is useful for:

A/B testing
Canary releases
Blue-green deployments
Gradual rollouts
Testing a new application version
Maintaining multiple application versions

Microsoft’s traffic-splitting functionality allows traffic to be distributed among active revisions using percentage weights. The total traffic allocation must equal 100%.

11. Traffic Splitting

In multiple revision mode, traffic can be divided among revisions.

For example:

			
Revision 1 → 90%
Revision 2 → 10%

This means approximately 90% of incoming traffic is routed to Revision 1 and 10% to Revision 2.

A common deployment strategy is to gradually increase the percentage assigned to the new revision:

			
Stage 1
v1 = 100%
v2 =   0%
Stage 2
v1 =  90%
v2 =  10%
Stage 3
v1 =  50%
v2 =  50%
Stage 4
v1 =   0%
v2 = 100%

		

This provides a controlled rollout.

Important exam point

Traffic weights must add up to 100%.

For example:

			
Revision A = 70%
Revision B = 30%

is valid.

But:

			
Revision A = 70%
Revision B = 20%

does not fully allocate traffic.

12. Revision Labels

Revision labels provide a way to identify a particular revision with a meaningful name.

Instead of relying entirely on an automatically generated revision name, a developer can use a label representing an environment or deployment stage.

For example:

			
staging
production

A labeled revision can be accessed through a label-specific endpoint.

Labels can be useful when:

Testing a specific revision
Maintaining a staging version
Providing direct access to a particular revision
Performing deployment workflows
Separating testing traffic from production traffic

Azure CLI provides commands for managing revision labels, including adding, removing, and swapping labels.

13. Revision Names and Suffixes

Azure Container Apps automatically generates revision names, but developers can provide a meaningful revision suffix.

For example:

customer-api-v2

could be represented conceptually by a Container App named:

customer-api

with a revision suffix such as:

v2

Meaningful revision naming can make deployment management easier.

Good naming can help identify:

Application version
Deployment stage
Release identifier
Build number
Feature release

However, revision names and suffixes have naming restrictions, so applications should follow Azure’s supported naming rules rather than assuming arbitrary strings are valid.

14. Deploying a New Revision

A new revision is created when a revision-scope property changes.

For example, changing:

image = myregistry.azurecr.io/customer-api:v1

to:

image = myregistry.azurecr.io/customer-api:v2

creates a new revision.

Conceptually:

			
Revision 1
Image: customer-api:v1
       │
       │ deploy image v2
       ▼
Revision 2
Image: customer-api:v2

		

Revision 1 remains an independent immutable version.

This is one of the most important concepts to understand for exam questions involving deployments.

15. Rollbacks

Suppose Revision 2 introduces a serious problem:

			
Revision 1 → stable
Revision 2 → defective

In a multiple-revision deployment, traffic can be redirected back to Revision 1.

For example:

			
Before rollback:
Revision 1 → 20%
Revision 2 → 80%
After rollback:
Revision 1 → 100%
Revision 2 → 0%

		

The existing revision doesn’t need to be rebuilt because the previous revision already represents the known-good application version.

This is one of the primary benefits of immutable revisions.

16. Blue-Green Deployments

Azure Container Apps revisions can be used to implement a blue-green deployment strategy.

For example:

			
BLUE
Revision 1
Production
100% traffic
GREEN
Revision 2
New version
0% traffic

		

The new revision can be tested while receiving no production traffic.

Once validation is complete:

			
BLUE  → 0%
GREEN → 100%

The new version becomes the production version.

If a problem occurs:

			
BLUE  → 100%
GREEN → 0%

This provides a fast rollback mechanism.

17. Canary Deployments

Multiple revisions can also support a canary release.

For example:

			
Stable revision → 95%
New revision    → 5%

Only a small percentage of users initially reach the new version.

If the new version performs well, the deployment can gradually increase its traffic allocation:

This is especially useful for AI applications because a new model or inference implementation can be exposed to a limited portion of traffic before being fully deployed.

18. Scaling and Revisions

Scaling configuration can also be revision-scoped.

For example, a Container App might use:

			
Minimum replicas: 1
Maximum replicas: 10

and scale based on HTTP concurrency.

Changing the application’s scale configuration can result in a new revision because scale settings are part of the versioned template.

This is important because two revisions can potentially have different scaling configurations.

For example:

			
Revision 1
min replicas = 1
max replicas = 5
Revision 2
min replicas = 2
max replicas = 20

		

In multiple revision mode, these revisions can coexist with their respective configurations.

19. Ingress Configuration

Ingress determines how network traffic reaches a Container App.

Depending on the application, ingress can be:

External
Internal

External ingress makes the application accessible from outside the environment.

Internal ingress is useful when the application should only be reachable from within the environment or associated network configuration.

Container Apps supports HTTP and TCP-oriented ingress scenarios, with HTTP/1.1, HTTP/2, and TCP transport options depending on the configuration and workload.

Exam clue

If a question asks:

“The application must be accessible from the public internet.”

Look for an external ingress configuration.

If it asks:

“The API should only be accessible by other applications inside the Container Apps environment.”

Look for internal ingress.

20. Environment Variables

Containerized applications frequently require configuration values such as:

			
ENVIRONMENT=Production
MODEL_NAME=my-model
API_ENDPOINT=https://example

These values can be provided as environment variables.

Environment variables are part of the container configuration and therefore can be associated with a revision.

For example:

			
Revision 1
API_ENDPOINT = endpoint-v1
Revision 2
API_ENDPOINT = endpoint-v2

This is important when different application versions need different configuration.

21. Secrets

Sensitive information should not be hard-coded into container images.

Examples include:

API keys
Passwords
Connection strings
Tokens
Credentials

Azure Container Apps supports secrets that can be referenced by container environment variables.

Conceptually:

			
Container
   │
   └── Environment variable
           │
           └── secretRef
                    │
                    ▼
              Container App Secret

		

The Container Apps API supports environment variables that reference Container App secrets using secretRef.

For more advanced secret-management requirements, Azure Key Vault can be used rather than embedding credentials directly in the application.

Exam Tip

If the question asks where to store a password or API key, do not choose a Dockerfile or hard-coded environment variable.

Think:

Secret management → Container Apps secrets / Azure Key Vault

22. Private Container Registries

Container Apps can deploy images from private container registries.

For example:

			
Azure Container Registry
        │
        │ image
        ▼
Azure Container Apps

		

The Container App must have appropriate authorization to pull the image.

For Azure-hosted workloads, managed identities can often be used to avoid embedding long-lived credentials.

This follows an important security principle:

Prefer identity-based authentication over hard-coded credentials.

23. Container Apps and Azure Container Registry

A common AI-200 deployment architecture is:

			
Developer
   │
   ▼
Build container image
   │
   ▼
Azure Container Registry
   │
   ▼
Azure Container Apps
   │
   ├── Revision 1
   └── Revision 2

		

Azure Container Registry stores the container image while Azure Container Apps runs the container.

A new image version can then be deployed as a new revision.

For example:

			
my-ai-api:v1
my-ai-api:v2
my-ai-api:v3

Each deployment can correspond to a new revision.

24. Environment Configuration vs. Revision Management

A useful exam distinction is:

Concept	Purpose
Container Apps environment	Shared boundary and infrastructure context
Container App	The application/service
Revision	Immutable version of the application
Revision mode	Determines how revisions are activated
Ingress	Controls how traffic reaches the application
Traffic splitting	Determines how traffic is distributed
Revision label	Provides identifiable access to a revision
Secret	Stores sensitive configuration
Environment variable	Supplies application configuration
Scale configuration	Determines how the application responds to demand

Understanding these distinctions helps prevent choosing an answer that sounds plausible but operates at the wrong level.

25. A Typical Deployment Lifecycle

A production deployment might look like this:

Step 1 — Build

Create the container image.

			
AI application source
        ↓
Docker build
        ↓
Container image

		

Step 2 — Store

Push the image to Azure Container Registry.

			
Container image
        ↓
Azure Container Registry

Step 3 — Deploy

Deploy the image to Azure Container Apps.

			
Registry
   ↓
Container App
   ↓
Revision 1

		

Step 4 — Update

Deploy a new image.

			
Registry
   ↓
Container App
   ↓
Revision 2

		

Step 5 — Validate

Check:

Provisioning state
Running state
Replica health
Application logs
Health probes
Application metrics

Step 6 — Route traffic

In multiple revision mode:

			
Revision 1 → 90%
Revision 2 → 10%

Step 7 — Complete rollout

If the new revision is healthy:

			
Revision 1 → 0%
Revision 2 → 100%

Step 8 — Roll back if necessary

If problems appear:

			
Revision 1 → 100%
Revision 2 → 0%

This workflow illustrates why revisions are such an important Azure Container Apps capability.

26. Common Exam Traps

Trap 1: Assuming every configuration change creates a revision

Not every change creates a new revision.

Remember the distinction between revision-scope and application-scope configuration.

Trap 2: Assuming revisions are mutable

Revisions are immutable.

To change the versioned application configuration, deploy a new revision.

Trap 3: Confusing single and multiple revision modes

Single mode is designed around one active revision.

Multiple mode allows several revisions to be active simultaneously.

Trap 4: Using traffic splitting in single mode

Traffic splitting requires multiple active revisions.

If the question specifically requires distributing traffic between two versions, look for multiple revision mode.

Trap 5: Assuming a failed new revision automatically replaces the healthy one

Azure Container Apps provides mechanisms that help maintain availability during deployment. In single revision mode, the existing revision can continue serving traffic while the new revision is being prepared.

Trap 6: Confusing a Container Apps environment with a Container App

The environment is the broader hosting boundary.

The Container App is the actual application.

Multiple Container Apps can exist within an environment.

Trap 7: Hard-coding secrets into a container

Passwords and API keys should not be placed directly into application code or container images.

Use appropriate secret-management capabilities.

Trap 8: Forgetting that scale configuration can be revision-specific

Scale configuration belongs to the versioned application template and can therefore create a new revision when changed.

27. AI-200 Exam Summary

For the AI-200 exam, remember these core points:

Azure Container Apps provides managed hosting for containerized applications.
A Container Apps environment provides a secure boundary for a group of Container Apps.
Multiple Container Apps can share the same environment.
A revision represents an immutable version of a Container App.
Changes to revision-scoped properties create new revisions.
Application-scoped changes don’t create new revisions.
Single revision mode is the default.
Multiple revision mode allows multiple active revisions.
Traffic can be split between active revisions in multiple mode.
Traffic weights must total 100%.
Revisions support blue-green deployments.
Revisions support canary and A/B testing scenarios.
Previous revisions can provide a convenient rollback target.
Revision labels can provide meaningful access to particular revisions.
Environment variables provide application configuration.
Secrets should be used for sensitive values.
Container Apps can pull images from container registries such as Azure Container Registry.
Managed identities can reduce the need for embedded credentials.
Ingress determines how applications receive network traffic.
Health probes and application readiness are important during deployment.
Scaling configuration can be revision-specific.
Understanding the difference between environment, application, revision, and traffic configuration is essential for scenario-based questions.

Practice Exam Questions

Question 1

You deploy a container app named orders-api using revision 1. You then change the container image from orders:v1 to orders:v2.

What happens when the change is deployed?

A. Revision 1 is modified in place.

B. A new revision is created containing the new container image.

C. The Container Apps environment is recreated.

D. The application is automatically moved to another region.

Answer: B

Explanation

The container image is part of the versioned container template. Changing the image is therefore a revision-scope change, which causes a new immutable revision to be created. Revision 1 remains unchanged. Azure’s Container Apps API identifies the container template as versioned and states that changes to it create a new revision.

Question 2

An organization has three Container Apps that need to share a common networking boundary and logging infrastructure.

What should you create?

A. A separate revision for each application.

B. A single Container Apps environment containing the three applications.

C. A single container image containing all three applications.

D. A separate Azure Kubernetes Service cluster for each application.

Answer: B

Explanation

A Container Apps environment provides a secure boundary around a group of Container Apps. Applications within the same environment can share environment-level capabilities such as networking and logging.

Question 3

You need to gradually introduce a new version of an API. Initially, 95% of requests should go to the existing revision and 5% should go to the new revision.

Which configuration should you use?

A. Single revision mode with an environment variable.

B. A new Container Apps environment.

C. Multiple revision mode with traffic splitting.

D. A second container inside the same revision.

Answer: C

Explanation

Multiple revision mode allows multiple revisions to remain active simultaneously and supports percentage-based traffic splitting. This makes it appropriate for gradual or canary deployments.

Question 4

A Container App is currently configured in single revision mode. A developer deploys a new revision, but the new revision fails its readiness checks.

What is the expected behavior?

A. The existing healthy revision can continue serving traffic while the new revision fails to become ready.

B. All revisions are immediately deactivated.

C. The environment is automatically deleted.

D. Traffic is automatically divided equally between the failed and healthy revisions.

Answer: A

Explanation

In single revision mode, Azure Container Apps maintains the existing revision while the new revision is being provisioned. The new revision must become ready before traffic is moved to it. This helps support zero-downtime deployments.

Question 5

You need to deploy a new revision for testing while keeping the current production revision at 100% traffic. The test revision should remain available so developers can test it directly.

Which approach is most appropriate?

A. Use single revision mode and delete the production revision.

B. Create a second Container Apps environment and duplicate the application.

C. Modify the existing production revision in place.

D. Use multiple revision mode and keep the test revision active with appropriate traffic allocation or a revision label.

Answer: D

Explanation

Multiple revision mode allows several revisions to remain active. A revision can also be associated with a label to provide direct access to a particular revision. This is useful for staging and testing scenarios without immediately shifting production traffic.

Question 6

A developer changes an application’s revision mode from Single to Multiple.

Does changing the revision mode itself create a new revision?

A. Yes. Every configuration change creates a revision.

B. Yes, but only if traffic splitting is also configured.

C. No. Revision mode is an application-scope configuration.

D. No, because revision mode is stored in the container image.

Answer: C

Explanation

Revision mode is an application-scope configuration setting. Changing the revision mode does not itself create a new revision. Azure’s current API documentation identifies activeRevisionsMode as part of the non-versioned Container App configuration.

Question 7

An application has two active revisions configured with traffic weights of 70% and 20%.

What is wrong with this configuration?

A. Traffic splitting can only be 50/50.

B. Traffic weights must total 100%.

C. Multiple revision mode only supports two revisions.

D. Traffic splitting requires three revisions.

Answer: B

Explanation

Traffic weights define the percentage of incoming traffic routed to each revision. The combined weights must equal 100%. A 70% + 20% configuration accounts for only 90% of traffic.

Question 8

An AI inference API stores an Azure OpenAI API key in its container image.

What is the best improvement?

A. Move the key into a Dockerfile argument.

B. Put the key into the container image as an encrypted text file.

C. Store the key in a Container Apps secret or an appropriate external secret-management service such as Azure Key Vault.

D. Put the key directly into the application’s source code.

Answer: C

Explanation

Secrets such as API keys and passwords should not be embedded in source code or container images. Container Apps supports secrets that can be referenced by environment variables, while Azure Key Vault provides centralized secret management for more advanced scenarios. The Container Apps API supports secretRef for connecting environment variables to Container App secrets.

Question 9

You are implementing a blue-green deployment. Revision 1 is currently serving production traffic. Revision 2 contains a new version that has been fully tested.

What should you do to switch production to Revision 2 while retaining the ability to quickly roll back?

A. Delete Revision 1 immediately.

B. Update Revision 1 so it contains Revision 2’s code.

C. Create a new Container Apps environment and redirect DNS.

D. Shift production traffic from Revision 1 to Revision 2 while keeping Revision 1 available.

Answer: D

Explanation

Revisions are immutable versions of an application. A blue-green deployment can maintain the existing revision while the new revision is validated. Production traffic can then be shifted to the new revision. Keeping the previous revision available provides a straightforward rollback target if problems occur.

Question 10

You have an application running in multiple revision mode:

			
Revision A → 80%
Revision B → 20%

You change the container image used by Revision B.

What should you expect?

A. Revision B is modified in place while retaining its existing revision identity.

B. The Container Apps environment is recreated.

C. A new revision is created containing the changed container image.

D. Revision A is automatically deleted.

Answer: C

Explanation

The container image is part of the revision’s versioned template. Changing it creates a new revision rather than modifying the existing immutable revision. The new revision can then be activated and assigned traffic according to the application’s revision configuration.

Final Exam Takeaway

The easiest way to reason about Azure Container Apps deployment questions is to think in terms of layers:

			
CONTAINER APPS ENVIRONMENT
        │
        │  Shared hosting/networking boundary
        ▼
CONTAINER APP
        │
        │  Application configuration
        ▼
REVISION
        │
        │  Immutable version
        ▼
CONTAINER IMAGE + TEMPLATE + SCALE CONFIGURATION

		

Then ask:

Does the question involve the hosting boundary?
→ Think Container Apps environment.

Does it involve the application itself?
→ Think Container App configuration.

Does it change the versioned application template?
→ Think new revision.

Does it require multiple versions to run simultaneously?
→ Think multiple revision mode.

Does it require controlled percentages of traffic?
→ Think traffic splitting.

Does it require a gradual rollout?
→ Think canary deployment.

Does it require switching between old and new versions?
→ Think blue-green deployment.

Does it require returning to a known-good version?
→ Think previous revision and rollback.

Mastering those distinctions will cover a substantial portion of the scenario-based questions you are likely to encounter around deploying applications to Azure Container Apps for AI-200.

Go to the AI-200 Exam Prep Hub main page

azure, Cloud computing, Microsoft Certification August 15, 2026

Deploy containers to Azure App Service, including configuring App Service to supply environment variables and secrets (AI-200 Exam Prep)

This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Deploy containers to Azure App Service, including configuring App Service to supply environment variables and secrets

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure App Service is a fully managed platform-as-a-service (PaaS) offering that allows developers to host web applications, APIs, and containerized applications without managing the underlying virtual machines or operating system.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how to deploy a container image to App Service and, importantly, how to configure the application so that the container receives the configuration, environment variables, and secrets it needs at runtime.

This is particularly important for AI applications because containerized AI workloads commonly need configuration values such as:

Azure AI service endpoints
Model deployment names
Database connection information
Storage account names
Service Bus configuration
Application Insights configuration
Feature flags
API keys or other secrets

A well-designed application should not bake these values into the container image. Instead, configuration should be supplied by the hosting environment, with sensitive values preferably retrieved from a secure secret store such as Azure Key Vault.

1. Understand Azure App Service for Containers

Azure App Service can run applications packaged as custom container images. This allows developers to use their own runtime, dependencies, libraries, and operating-system configuration instead of relying exclusively on App Service’s built-in application stacks.

A typical architecture looks like this:

Developer → Container Image → Container Registry → Azure App Service → Running Container

For example:

A developer creates a Dockerfile.
The Dockerfile is used to build an image.
The image is pushed to Azure Container Registry.
App Service is configured to use that image.
App Service pulls the image.
App Service starts the container.
App Service supplies configuration values as environment variables.
The application reads those values at runtime.

App Service pulls the configured container image when the application starts. If an updated image is pushed to the registry, restarting the application causes App Service to pull the updated image.

This separation between the application image and the application configuration is an important concept for the exam.

2. Why Use Containers with App Service?

A custom container is useful when the application’s requirements don’t fit cleanly into one of App Service’s predefined runtime stacks.

For example, an AI application might require:

A particular Python version
Specific native libraries
Custom machine-learning packages
A specialized web server
OS-level dependencies
A combination of packages that isn’t available in a standard App Service stack

Instead of configuring all those dependencies on the App Service platform, you can package them into a container.

Key benefit

The container provides a consistent application environment.

The same image can potentially be used in:

Development
Testing
Staging
Production
Other container-hosting environments

This supports the important principle:

Build the application once and configure it differently for each environment.

The container should contain the application and its dependencies—not environment-specific secrets.

3. The Container Image and App Service Are Separate Concerns

One of the most important concepts to understand is the difference between the container image and the App Service configuration.

Container image

The image contains things such as:

Application code
Runtime
Dependencies
Libraries
System packages
Startup configuration

App Service configuration

App Service supplies environment-specific information such as:

Database endpoints
API endpoints
Feature flags
Environment names
Secret references
Connection information

This allows the same image to run in multiple environments.

For example:

			
Container Image
    |
    +-- Application code
    +-- Python runtime
    +-- Required libraries
    +-- AI SDKs
    |
    v
App Service
    |
    +-- ENVIRONMENT=Production
    +-- AI_ENDPOINT=...
    +-- MODEL_NAME=...
    +-- DATABASE_CONNECTION=...
    +-- API_KEY=<Key Vault reference>

		

The application doesn’t need a different Docker image simply because it is moving from development to production.

4. Deploying a Container to App Service

There are several ways to deploy a containerized application to App Service.

A common approach is:

			
Dockerfile
    ↓
docker build
    ↓
Container Image
    ↓
Azure Container Registry
    ↓
Azure App Service

		

For example, a container image might be named:

myregistry.azurecr.io/my-ai-api:v1

The registry name identifies the container registry.

The repository identifies the application:

my-ai-api

And the tag identifies a particular version:

v1

Therefore:

myregistry.azurecr.io/my-ai-api:v1

identifies a specific container image.

5. Configure the Container Image

When creating or configuring an App Service application, you specify the container image that App Service should run.

For an image hosted in Azure Container Registry, App Service needs access to the registry.

For a private registry, authentication must be configured.

Depending on the scenario, App Service can use authentication mechanisms such as managed identity rather than embedding registry credentials. Current App Service configuration also supports managed-identity-based access to Azure Container Registry, which is generally preferable to managing long-lived registry passwords.

Exam concept

When you see a question asking for the most secure way to allow App Service to pull a private image from Azure Container Registry, consider:

Managed identity and appropriate Azure role assignments

rather than storing a registry password in application configuration.

6. The Container’s Listening Port

A containerized application must listen on the appropriate port so App Service can route traffic to it.

For custom containers, the port configuration is particularly important.

For example, suppose the application listens on:

The application inside the container needs to listen on that port, and App Service needs to know which port to use.

A common App Service configuration is:

WEBSITES_PORT=8080

The WEBSITES_PORT application setting tells App Service which port the custom container is listening on. Microsoft specifically identifies WEBSITES_PORT as required for custom-container port configuration.

Example

Suppose the Dockerfile contains:

EXPOSE 8080

The application should also actually listen on port 8080.

Then App Service can be configured with:

WEBSITES_PORT = 8080

Important distinction

EXPOSE in a Dockerfile documents the port the container expects to use. It does not by itself guarantee that the application is actually listening on that port.

A common troubleshooting scenario is:

The container starts successfully, but the application isn’t reachable.

One of the first things to verify is whether the application is listening on the expected port and whether WEBSITES_PORT is configured correctly.

7. Environment Variables in App Service

App Service application settings are exposed to applications as environment variables.

This is one of the most important concepts for this exam topic.

For example, you could configure:

			
ENVIRONMENT = Production
MODEL_NAME = gpt-4o-mini
AI_ENDPOINT = https://example.openai.azure.com/

Your application can then read these values from its environment.

For Linux applications and custom containers, App Service passes application settings into the container as environment variables. Changes to App Service settings cause the application to restart.

This allows the application code to remain environment-independent.

8. Why Environment Variables Are Better Than Hard-Coding Configuration

Consider this application code:

AI_ENDPOINT = "https://production-ai.example.com"

This is problematic because the endpoint is embedded in the application.

A better approach is:

			
import os
AI_ENDPOINT = os.environ["AI_ENDPOINT"]

Then App Service supplies:

AI_ENDPOINT=https://production-ai.example.com

The same container can then be deployed elsewhere with:

AI_ENDPOINT=https://development-ai.example.com

without rebuilding the image.

This supports:

Environment portability
Easier deployments
Configuration management
Separation of code and configuration
Safer secret handling

9. Configure Application Settings

App Service application settings can be configured through the Azure portal, Azure CLI, PowerShell, ARM/Bicep, or other deployment mechanisms.

In the Azure portal, application settings are managed under the app’s environment/configuration settings.

For example, you might define:

Setting	Example value	Sensitive?
`APP_ENVIRONMENT`	`Production`	No
`AI_ENDPOINT`	`https://my-ai.openai.azure.com/`	Usually no
`MODEL_NAME`	`chat-model`	No
`LOG_LEVEL`	`Information`	No
`DATABASE_CONNECTION`	Connection information	Potentially
`API_KEY`	Secret value	Yes

App Service stores app settings encrypted at rest. However, for secrets that require centralized secret management, Microsoft recommends using Azure Key Vault references rather than directly storing the secret value in the App Service setting.

10. Secrets Should Not Be Baked into Container Images

This is a major security principle.

Avoid putting something like this in a Dockerfile:

ENV API_KEY="abc123secret"

Also avoid:

API_KEY = "abc123secret"

Why?

Because the secret can potentially become part of the image or source code and therefore propagate into:

Container registries
Image layers
Source repositories
Build systems
Developer machines
Backups
Logs

Instead:

			
Container Image
      +
App Service Configuration
      +
Azure Key Vault

		

should provide the necessary runtime configuration.

11. Azure Key Vault Integration

Azure Key Vault provides centralized management for secrets, keys, and certificates.

For App Service, Key Vault can be integrated using Key Vault references.

Instead of putting the actual secret into an App Service setting, the setting contains a reference to the secret.

Conceptually:

			
API_KEY
    ↓
@Microsoft.KeyVault(...)
    ↓
Azure Key Vault
    ↓
Secret value
    ↓
Application

		

The application can consume the resolved value as an ordinary environment variable.

One of the major benefits is that application code doesn’t need to contain Key Vault-specific retrieval logic just to consume a referenced application setting.

12. Key Vault References

A Key Vault reference has a format similar to:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)

Alternatively, a reference can use the vault and secret names:

@Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret)

A specific secret version can also be specified.

For example:

			
AI_API_KEY =
@Microsoft.KeyVault(VaultName=myvault;SecretName=AI-API-Key)

The application can continue to access the setting using the environment variable:

AI_API_KEY

The application doesn’t have to know that the value originated from Key Vault.

13. Managed Identity and Key Vault

For Key Vault references to work securely, App Service needs an identity that can access the Key Vault.

A recommended architecture is:

			
Azure App Service
       |
       | Managed Identity
       |
       v
Azure Key Vault
       |
       v
Secret

		

The application does not need to store a Key Vault username/password or service principal secret.

App Service Key Vault references use the app’s system-assigned managed identity by default, although a user-assigned managed identity can also be configured. The identity must have permission to read secrets from the vault. With Azure RBAC, the Key Vault Secrets User role is an appropriate role for reading secrets.

14. System-Assigned vs. User-Assigned Managed Identity

You should understand the difference for exam questions.

System-assigned managed identity

The identity is tied to the Azure resource.

For example:

			
App Service
    |
    +-- System-assigned identity

If the App Service is deleted, the identity is also deleted.

User-assigned managed identity

The identity is a separate Azure resource.

			
User-assigned identity
       |
       +---- App Service A
       |
       +---- App Service B

		

It can therefore be reused by multiple resources.

Exam consideration

If a scenario specifically requires an identity to exist before the application is created or requires reuse across several resources, a user-assigned managed identity may be more appropriate.

15. Key Vault Secret Rotation

Key Vault references can simplify secret rotation.

When a Key Vault reference doesn’t specify a particular secret version, App Service can use the latest version of the secret.

App Service caches Key Vault reference values and periodically refreshes them. Microsoft documents a refresh interval of up to 24 hours; configuration changes that restart the app can cause the references to be fetched immediately.

This is an important distinction:

Changing the secret in Key Vault does not necessarily mean that the application immediately receives the new value.

If an application must immediately consume a new value, you need to account for the Key Vault reference refresh behavior.

16. What Happens When a Key Vault Reference Fails?

Suppose App Service has:

			
AI_API_KEY =
@Microsoft.KeyVault(VaultName=myvault;SecretName=AI-Key)

but the managed identity doesn’t have permission to retrieve the secret.

The reference might fail to resolve.

Potential causes include:

Incorrect Key Vault name
Incorrect secret name
Secret deleted
Incorrect reference syntax
Managed identity not enabled
Missing Key Vault permissions
Network restrictions preventing access to Key Vault

App Service provides Key Vault reference resolution information that can help diagnose these problems.

Exam clue

If a question says:

The application receives the literal @Microsoft.KeyVault(...) value instead of the expected secret.

Think:

The Key Vault reference failed to resolve.

Then investigate identity, permissions, reference syntax, secret existence, and networking.

17. App Settings vs. Key Vault

A useful exam distinction is:

Requirement	Recommended approach
Non-sensitive configuration	App Service application setting
Environment-specific value	App Service application setting
Secret value	Azure Key Vault
Secret consumed as an environment variable	Key Vault reference in an App Service setting
Shared centralized configuration	Azure App Configuration
Application code	Do not hard-code secrets

App Service application settings are appropriate for ordinary configuration.

Key Vault should be preferred when the value is a secret requiring centralized secret management, access control, auditing, and rotation.

18. App Configuration vs. Key Vault

AI-200 also covers Azure App Configuration, so understand how it differs from Key Vault.

Azure App Configuration

Designed primarily for centralized application configuration.

Examples:

			
Feature flags
Application settings
Environment configuration
Dynamic configuration

Azure Key Vault

Designed for sensitive information such as:

			
Passwords
API keys
Connection secrets
Certificates
Cryptographic keys

		

A common architecture uses both:

                    +---------------------+
                    | Azure App Config     |
                    |                     |
                    | Feature flags       |
                    | Application config  |
                    +----------+----------+
                               |
                               |
Application <------------------+
     |
     |
     +------------------------+
                              |
                              v
                    +---------------------+
                    | Azure Key Vault     |
                    |                     |
                    | API keys            |
                    | Passwords           |
                    | Secrets             |
                    +---------------------+

Do not confuse centralized configuration with secret management.

19. Container Startup Commands

A container has a default startup command defined by its image.

However, App Service can override the startup behavior for a custom container.

This can be useful when:

The container’s default command isn’t appropriate.
The application requires a specific startup command.
Different hosting environments require different startup behavior.

For example:

python app.py

or:

gunicorn --bind 0.0.0.0:8080 app:app

App Service supports specifying a startup command for custom containers.

Exam clue

If a container image works locally but App Service starts it incorrectly, investigate:

Startup command
Listening port
Environment variables
Container logs
Image configuration

20. Environment Variables and Container Startup

Environment variables are available to the application when the container starts.

For example:

			
APP_ENVIRONMENT=Production
PORT=8080
MODEL_NAME=my-model

Your application might use:

			
import os
environment = os.getenv("APP_ENVIRONMENT")
model = os.getenv("MODEL_NAME")

The values can be changed in App Service without changing the container image.

This is especially valuable when promoting the same image through:

			
Development
     ↓
Testing
     ↓
Staging
     ↓
Production

		

Each environment can supply different configuration.

21. App Settings Cause Application Restarts

A frequently tested detail is that changing App Service application settings causes the application to restart.

This matters because configuration changes aren’t necessarily applied to an already-running process without interruption.

Microsoft documents that adding, removing, or modifying app settings causes an App Service app restart.

Therefore, if a scenario says:

An administrator changes an application setting and the application immediately restarts.

That is expected behavior.

22. Container Image Updates

Suppose App Service is configured to run:

myacr.azurecr.io/my-ai-api:latest

A developer builds a new version and pushes it using the same tag.

The registry now contains a newer image associated with latest.

However, simply pushing the new image doesn’t necessarily mean that an already-running container immediately changes.

Restarting the App Service causes it to pull the image again.

This is one reason immutable version tags are often preferable for controlled deployments.

For example:

			
my-ai-api:v1.0.0
my-ai-api:v1.1.0
my-ai-api:v2.0.0

rather than relying exclusively on:

my-ai-api:latest

23. Using `latest` vs. Versioned Tags

`latest`

Advantages:

Simple
Convenient for development

Disadvantages:

Doesn’t clearly identify what is deployed
Makes rollback more difficult
Can make troubleshooting harder
Can introduce unexpected image changes

Versioned tags

For example:

my-ai-api:1.4.2

Advantages:

Clear version identification
Easier rollback
Better deployment traceability
Easier troubleshooting

For production workloads, versioned image tags are generally a better operational practice.

24. Container Logs and Troubleshooting

When a container doesn’t start correctly, examine the container logs.

Common problems include:

Wrong port

The application listens on:

but App Service expects:

Application crashes

For example:

ModuleNotFoundError

or:

Connection refused

Incorrect environment variable

The application expects:

DATABASE_URL

but App Service defines:

DB_URL

Secret resolution failure

The Key Vault reference isn’t resolving.

Startup command failure

The command specified by App Service doesn’t exist or fails.

25. Container Startup Timeout

Custom containers sometimes take longer to initialize than expected.

App Service provides the WEBSITES_CONTAINER_START_TIME_LIMIT setting to control how long the platform waits for a container to start.

The documented default is 230 seconds, with a maximum of 1,800 seconds.

This can matter for AI applications that have relatively large startup workloads.

However, increasing the startup timeout should not be the first response to every startup problem.

First determine why startup is slow.

For example:

Is the container downloading dependencies at startup?
Is the application loading a large model?
Is it waiting for an external service?
Is the application listening on the wrong port?
Is the startup command incorrect?

26. HTTPS and Custom Containers

A custom container doesn’t necessarily need to implement HTTPS itself when hosted through App Service.

App Service can handle HTTPS termination at the platform’s front ends.

Therefore, an application can commonly listen for HTTP inside the container while clients connect to the application through HTTPS.

Conceptually:

			
Client
  |
 HTTPS
  |
  v
App Service
  |
 HTTP
  |
  v
Container

		

This is different from saying that application traffic is universally unprotected in every internal configuration; networking and security architecture still matter.

27. Continuous Deployment for Containers

App Service can integrate with container registries to support automated deployments.

A common flow is:

			
Developer
   |
   v
Source Repository
   |
   v
Build
   |
   v
Container Image
   |
   v
Azure Container Registry
   |
   v
App Service

		

A registry push can be used to trigger a deployment/restart workflow.

App Service supports continuous deployment scenarios involving container registries, including Azure Container Registry.

For production systems, CI/CD is generally preferable to manually rebuilding and deploying containers.

28. A Recommended AI Application Architecture

A reasonable architecture for an AI application hosted in a container on App Service might look like this:

                         Azure Container Registry
                                  |
                                  | Container Image
                                  v
                         +-------------------+
                         |   Azure App       |
                         |     Service       |
                         +---------+---------+
                                   |
                    +--------------+--------------+
                    |                             |
             Environment Variables          Managed Identity
                    |                             |
                    |                             v
                    |                      Azure Key Vault
                    |                             |
                    |                           Secrets
                    |
                    +--------------------+
                                         |
                                         v
                                  AI Application
                                         |
                  +----------------------+----------------+
                  |                      |                 |
                  v                      v                 v
             Azure AI             Azure Database      Azure Storage

The container image contains the application.

App Service provides environment-specific configuration.

Managed identity provides secure access to Azure resources.

Key Vault stores secrets.

This is a strong pattern to recognize in AI-200 scenario questions.

29. Security Best Practices

For the exam, remember these principles.

Don’t hard-code secrets

Avoid:

API_KEY=abc123

inside source code or Dockerfiles.

Don’t put secrets in image layers

Building a secret into an image doesn’t make it secure simply because the image is stored in a private registry.

Use managed identities

When Azure services support Microsoft Entra authentication and managed identities, prefer them over long-lived credentials.

Use Key Vault for secrets

Store sensitive values centrally.

Use least privilege

Grant the App Service identity only the permissions it requires.

Separate environments

Development, testing, and production should have appropriately separated configuration and secrets.

Use versioned images

Prefer:

myapp:1.2.3

over relying exclusively on:

myapp:latest

30. Important AI-200 Exam Concepts to Remember

The following relationships are particularly important:

Concept	Remember
Custom container	Runs your own container image in App Service
Azure Container Registry	Common private registry for App Service container images
App settings	Become environment variables
`WEBSITES_PORT`	Identifies the port used by a custom container
Startup command	Controls/overrides how the container application starts
Key Vault	Secure centralized secret management
Key Vault reference	Allows an App Service setting to reference a Key Vault secret
Managed identity	Avoids storing credentials for Azure resource access
System-assigned identity	Lifecycle tied to the Azure resource
User-assigned identity	Separate reusable identity resource
App setting changes	Cause an application restart
Image update	Restart causes App Service to pull the updated image
`latest`	Convenient but less predictable
Versioned tags	Better traceability and rollback
Container logs	Important for startup/runtime troubleshooting
`WEBSITES_CONTAINER_START_TIME_LIMIT`	Controls custom-container startup wait time

Practice Exam Questions

Question 1

You have a Python-based AI API packaged as a Linux container. The application listens on port 8080 inside the container.

You deploy the container to Azure App Service, but requests to the application fail because App Service cannot connect to the application.

Which App Service setting should you verify first?

A. WEBSITE_RESOURCE_GROUP

B. WEBSITE_SITE_NAME

C. WEBSITES_PORT

D. WEBSITE_SKU

Answer: C

Explanation

For custom containers, App Service needs to know which port the container is listening on. If the application listens on port 8080, configuring:

WEBSITES_PORT=8080

helps App Service route traffic to the correct container port.

The other settings describe the App Service environment but do not determine the container’s application port.

Question 2

An AI application is deployed as a container to Azure App Service. The application requires an API key that changes periodically.

The development team wants to avoid storing the API key in source code, the Dockerfile, or the container image.

Which solution provides the best approach?

A. Store the API key in the Dockerfile as an ENV value.

B. Store the API key in Azure Key Vault and reference it from an App Service application setting.

C. Store the API key in the container image and use a private Azure Container Registry.

D. Store the API key in the application’s source code and protect the repository with RBAC.

Answer: B

Explanation

Azure Key Vault is designed for centralized secret management. App Service can use a Key Vault reference as an application setting, allowing the application to consume the secret as an environment variable without embedding the secret in the image or source code.

A private container registry protects access to the image but does not make secrets embedded inside the image a good security practice.

Question 3

An Azure App Service application uses a Key Vault reference to retrieve an API key. The application is receiving the literal Key Vault reference string rather than the expected secret value.

Which issue should you investigate?

A. Whether the Dockerfile contains an EXPOSE instruction

B. Whether WEBSITES_PORT matches the application port

C. Whether the App Service managed identity has permission to read the Key Vault secret

D. Whether the image uses the latest tag

Answer: C

Explanation

A Key Vault reference must be resolved by App Service. The application’s managed identity needs permission to retrieve the referenced secret.

A missing or incorrectly configured identity, missing Key Vault permissions, an invalid secret name, or other Key Vault configuration problems can prevent resolution.

The port and image tag are unrelated to Key Vault reference resolution.

Question 4

A development team wants to deploy the same container image to development, test, and production environments. The AI endpoint differs between environments.

What is the best approach?

A. Build a separate Docker image for each environment.

B. Store all three endpoints in the Dockerfile and select one at runtime.

C. Create separate source-code branches containing different endpoint values.

D. Store the endpoint as an App Service application setting in each environment.

Answer: D

Explanation

Environment-specific configuration should be separated from the application image.

Each App Service environment can provide its own application setting:

AI_ENDPOINT=https://development...

or:

AI_ENDPOINT=https://production...

The same container image can therefore be deployed across environments.

Question 5

A developer pushes a new version of an image to Azure Container Registry using the same latest tag that an App Service application is already configured to use.

When should the developer expect App Service to retrieve the updated image?

A. When the running container is restarted

B. Immediately when the image is pushed

C. Only when the App Service plan is resized

D. Only after the image tag is deleted

Answer: A

Explanation

App Service pulls the configured container image when the application starts. If an updated image is pushed using the same tag, restarting the App Service causes the updated image to be pulled.

This is one reason explicit version tags are often preferable for controlled production deployments.

Question 6

An organization wants an App Service application to retrieve secrets from Azure Key Vault without storing a Key Vault password or service principal secret in the application.

Which feature should be used?

A. Docker ENV instructions

B. Managed identity

C. App Service startup command

D. Container port mapping

Answer: B

Explanation

Managed identity allows Azure resources such as App Service to authenticate to supported Azure services without requiring developers to store credentials in application configuration.

For Key Vault references, App Service can use its system-assigned managed identity by default or a configured user-assigned identity.

Question 7

An AI container deployed to App Service takes approximately five minutes to initialize because it performs a large initialization operation before listening for HTTP traffic.

The platform terminates the container before initialization completes.

Which setting can be used to increase the amount of time App Service waits for the container to start?

A. WEBSITES_PORT

B. WEBSITE_SITE_NAME

C. WEBSITES_CONTAINER_START_TIME_LIMIT

D. WEBSITE_WARMUP_PATH

Answer: C

Explanation

WEBSITES_CONTAINER_START_TIME_LIMIT controls how long App Service waits for a custom container to start.

The documented default is 230 seconds and the maximum is 1,800 seconds.

However, increasing the timeout should be done only after determining that the startup delay is legitimate rather than caused by a configuration or application problem.

Question 8

An application administrator changes the value of an App Service application setting.

What should the administrator expect?

A. The setting changes only the next time a new container image is deployed.

B. The setting changes the Dockerfile stored in Azure Container Registry.

C. App Service restarts the application so that the new setting can be supplied to the application environment.

D. The setting automatically modifies the source code in the application repository.

Answer: C

Explanation

App Service application settings are supplied to the application as environment variables. Changes to application settings cause the application to restart, allowing the new configuration to be supplied to the running application.

The setting does not modify the container image, Dockerfile, or source repository.

Question 9

You are designing a production AI application running in a custom container on Azure App Service. The application requires an API key.

Which design provides the strongest separation between application code and the secret?

A. Store the secret in Azure Key Vault and expose it to the application through an App Service Key Vault reference.

B. Store the secret in the Dockerfile using an ENV instruction.

C. Store the secret in a text file inside the container image.

D. Store the secret in the application’s source code and restrict repository access.

Answer: A

Explanation

A Key Vault reference allows the secret to remain in Azure Key Vault while the application consumes it through an App Service configuration setting.

This provides better separation between:

Application code
Container image
Deployment configuration
Secrets

The App Service managed identity can be granted the minimum required permissions to retrieve the secret.

Question 10

An organization has multiple App Service applications that need to use the same identity when accessing Azure Key Vault. The identity must also be able to exist independently of the lifecycle of any individual App Service application.

Which type of managed identity should be used?

A. System-assigned managed identity

B. App Service publishing credentials

C. User-assigned managed identity

D. Container registry administrator credentials

Answer: C

Explanation

A user-assigned managed identity is a standalone Azure resource that can be assigned to multiple Azure resources.

This makes it appropriate when:

Multiple applications need the same identity.
The identity needs an independent lifecycle.
The identity must exist before an application is created.
The organization wants to reuse the identity across resources.

A system-assigned identity is tied to the lifecycle of its associated Azure resource.

Final Exam Takeaways

For AI-200, the most important mental model is:

The container image contains the application; App Service supplies the environment-specific configuration; Key Vault protects sensitive values; managed identity provides secure access to Azure resources.

When you encounter an exam scenario, think through the problem in this order:

Where is the container image?
- Azure Container Registry?
- Another private registry?
- Public registry?
Can App Service pull the image?
- Is authentication configured?
- Would managed identity be appropriate?
What port does the application actually listen on?
- Does it match the App Service configuration?
- Is WEBSITES_PORT configured appropriately?
How does the application receive configuration?
- App Service application settings
- Environment variables
Does the configuration contain a secret?
- Use Azure Key Vault rather than embedding the secret in the image or source code.
How does App Service access Key Vault?
- Managed identity
- Appropriate Key Vault permissions
Is the container starting correctly?
- Startup command
- Container logs
- Port
- Environment variables
- Startup timeout
How is the image version managed?
- Prefer identifiable/versioned image tags for production deployments.
- Understand what happens when an image behind a tag is replaced.

These distinctions—particularly App Service settings vs. container image contents, environment variables vs. secrets, Key Vault references vs. hard-coded credentials, and system-assigned vs. user-assigned managed identities—are exactly the kinds of distinctions that can turn a plausible answer into the correct AI-200 answer.

Go to the AI-200 Exam Prep Hub main page