Free AI-200 Exam Flashcards

Geo-replication, private endpoints, customer-managed keys, content trust for signed images, zone redundancy, and repository-scoped tokens are Premium-only. Basic and Standard differ mainly in included storage and throughput. Choose Premium when the registry must be local to several regions or must not be reachable over the public internet.

It runs an ACR Tasks quick task: your source context is uploaded to the registry, the image is built by Azure, and the result is pushed automatically. No local Docker daemon is required, which is why it works from Cloud Shell and from build agents that cannot run Docker.

A source-code commit, an update to the base image, or a schedule. The base-image update trigger is the patching story: when the image named in your FROM statement is refreshed, ACR rebuilds every dependent image without a code change, so security fixes reach your containers.

Give the compute resource a managed identity, grant that identity the AcrPull role on the registry, and point the app at it (App Service sets acrUseManagedIdentityCreds; AKS uses `az aks update --attach-acr`). Leave the registry admin account disabled: it is one shared password that cannot be scoped or traced to a person.

App settings are injected into the container as environment variables. Keep secrets in Key Vault and reference them from an app setting as @Microsoft.KeyVault(SecretUri=...), which the app's managed identity resolves at startup. If the container listens on a port other than the default, set WEBSITES_PORT to that port or App Service cannot route requests to it.

It is the isolation and networking boundary. Apps in one environment share a virtual network and a single Log Analytics workspace and can call each other by internal app name without going through the public internet. Two workloads that must be network-isolated from each other belong in separate environments.

In single mode (the default) each new revision immediately receives all traffic and the previous revision is deactivated. In multiple mode several revisions stay active and you assign traffic weights across them. Blue-green and canary rollouts therefore require multiple mode; traffic splitting is not available in single mode.

Revision-scope changes are edits inside properties.template (image tag, environment variables, CPU/memory, scale rules) and produce a new immutable revision. Application-scope changes live in properties.configuration (ingress, secret values, registry credentials, revision mode) and apply across revisions without creating one - though a running container only picks up a changed secret after it restarts.

A default HTTP rule with a minimum of 0 replicas and a maximum of 10, adding a replica for roughly every 10 concurrent requests. Because the default minimum is zero, an app with ingress disabled and no rule scales to zero with nothing left to wake it: set minReplicas to 1 or add an event-driven rule such as a Service Bus queue-length scaler.

Jobs run to completion and exit, which fits batch embedding, index rebuilds, and scheduled data loads. They support manual, scheduled (cron), and event-driven (KEDA) trigger types. Container apps are for long-running services; note that jobs cannot use HTTP or TCP scale rules because they are not serving requests.

Deployment declares the pod template and replica count and manages rolling updates. Service gives a stable address in front of matching pods - ClusterIP is reachable only inside the cluster, LoadBalancer provisions an Azure load balancer with an external IP. Ingress routes HTTP traffic by host and path. Apply them with `kubectl apply -f`, which is declarative and safe to re-run.

ImagePullBackOff means the image could not be pulled: wrong tag, or the kubelet identity lacks AcrPull. CrashLoopBackOff means the image ran but the process keeps exiting - read `kubectl logs --previous`. Pending means the scheduler found no node with enough CPU/memory or matching tolerations. Start every investigation with `kubectl describe pod` and `kubectl get events`.

Every response reports its charge in the x-ms-request-charge header, surfaced as RequestCharge in the SDK. A 1 KB point read by id and partition key costs about 1 request unit; a cross-partition query costs many times more. When you exceed provisioned RU/s the service returns HTTP 429 with x-ms-retry-after-ms, and the SDK retries a bounded number of times before surfacing the error.

By default every property is indexed, so each write pays to maintain index entries for fields you never filter on. Excluding unused paths lowers write cost; adding a composite index lets queries that filter or sort on several properties avoid a scan. Policy changes are applied online in the background, so reindexing does not take the container offline.

Strong and bounded staleness. They read from two replicas to honor their guarantee, so read throughput per RU is half that of session, consistent prefix, and eventual, which are served from a single replica. Session is the account default and provides read-your-own-writes within a client session.

A container vector embedding policy naming the path, dimension count, and distance function (cosine, dot product, or Euclidean), plus a vector index on that path. Queries then order by VectorDistance(c.embedding, @queryVector) and take the top N. Index type sets the trade-off: flat is exact, quantizedFlat compresses vectors for speed, and DiskANN is a graph index built for large collections.

A durable log of creates and updates, ordered within each partition key, consumed by the change feed processor with a lease container that stores checkpoints and distributes partitions across instances. In the default latest-version mode deletes are not emitted and only the newest version of an item is seen - model deletions as a soft-delete flag with a TTL if downstream systems must react to them.

Two steps. Add `vector` to the azure.extensions server parameter, which is the server-level allowlist, then run CREATE EXTENSION vector; inside each database that needs it. Skipping the allowlist makes CREATE EXTENSION fail even for the administrator account, which is the usual cause of 'extension is not allow-listed' errors.

Use a vector(n) column whose n matches the embedding model's dimension count - a mismatch fails on insert - and keep the source text with it so retrieved chunks can be sent to the model. Put filterable attributes in typed columns, or in a jsonb column with a GIN index, so metadata filters run as a WHERE clause on the same table as the similarity ordering.

`<->` is L2 (Euclidean) distance, `<=>` is cosine distance, and `<#>` is negative inner product. The index operator class must match the operator you query with - for example vector_cosine_ops for `<=>`. If they disagree, PostgreSQL simply ignores the index and does a sequential scan, which looks like a performance bug rather than an error.

HNSW builds a layered proximity graph: slower to build and heavier on memory, but better recall and query speed, and it can be created on an empty table. IVFFlat groups rows into lists and should be built only after representative data is loaded, so it is cheaper to build but degrades as the data distribution shifts. Recall is tuned at query time with hnsw.ef_search or ivfflat.probes.

Approximate-nearest-neighbor search is fast only while the index stays resident in memory, so size the SKU above index plus working set and prefer a memory-optimized tier. Raise maintenance_work_mem before building a large HNSW index or the build spills to disk and takes far longer. On flexible server, IOPS scale with provisioned storage size unless you choose a storage type whose IOPS are configured independently.

Every PostgreSQL connection is a separate backend process with its own memory, so a burst of new connections costs handshake latency and can exhaust server memory. Use the built-in PgBouncer in transaction pooling mode, or a client-side pool, and keep one long-lived pool per instance. This matters most for functions and containers that scale out aggressively under load.

On read: check Redis first; on a miss, load from the database, write the value into Redis with an expiration, and return it. On write: update the database, then delete or overwrite the cached key so the next read repopulates it. Always set a TTL - it bounds how long a missed invalidation can serve stale data.

Eviction depends on the maxmemory policy. Under a volatile-* policy only keys that carry a TTL are eligible for eviction, so keys written without an expiration are never evicted; under noeviction, writes simply fail once the limit is reached. For a pure cache, either use an allkeys-* policy such as allkeys-lru or guarantee every key is written with an expiration.

You create a search index over hash or JSON keys containing a VECTOR field, declaring the algorithm (FLAT for exact, HNSW for approximate), the dimension count, and the distance metric (cosine, L2, or inner product), then run a KNN query for the top N neighbours, optionally combined with a filter expression. This is what makes a semantic cache possible: look for a near-identical earlier prompt before paying for another model call.

A queue delivers each message to exactly one competing consumer. A topic keeps one published stream but delivers a copy to every subscription, and each subscription is consumed like its own queue. Choose a topic whenever a second consumer might later need the same messages - you can add a subscription without touching the publisher.

Boolean filters (the default 1=1 accepts everything), correlation filters that match system and user properties by equality and are the cheapest to evaluate, and SQL filters that evaluate a SQL-like expression over properties. Filters read message properties, not the body, so any value you want to route on must be set as an application property.

Peek-lock, the default, hides the message behind a lock that the handler must complete; abandoning it or letting the lock expire makes it visible again and increments the delivery count. Receive-and-delete removes the message the moment it is handed to the client, so a crash loses it. For long model calls use peek-lock and renew the lock rather than lengthening processing beyond it.

Exceeding MaxDeliveryCount (default 10) through repeated abandons or lock expiries, expiring when dead-lettering on expiration is enabled, a subscription filter that throws while evaluating, and explicit dead-lettering by the application with a reason. Read them from the sub-queue path <entity>/$deadletterqueue and build a repair-and-resubmit path, because nothing removes them automatically.

It retries with exponential back-off, delivering at least once, until either the retry limit or the event time-to-live (24 hours by default) is reached, and then drops the event - unless you configure a dead-letter destination, which is a Blob Storage container. Because delivery is at-least-once, handlers must be idempotent to survive duplicates.

Service Bus for business messages that need ordering, sessions, transactions, and dead-lettering. Event Grid for reactive publish/subscribe distribution of discrete events, with per-subscription filtering and support for the CloudEvents schema. Event Hubs for high-throughput telemetry streams read by partition and offset. The question to ask is whether you are handing off work, announcing that something happened, or ingesting a stream.

Exactly one trigger: it defines what starts the function and supplies the payload. Input and output bindings are optional and declarative, letting the function read from or write to services such as Blob Storage, Cosmos DB, or Service Bus without SDK setup code. Every binding's connection property names an application setting - it never holds the connection string itself.

The runtime completes the message automatically when the function returns successfully, and abandons it on an unhandled exception, so the message is redelivered and its delivery count climbs toward the dead-letter threshold. Handlers must therefore be idempotent. Use a session-enabled trigger when messages for the same entity have to be processed in order.

The Cosmos DB trigger, which is a change feed processor underneath: it needs a lease container to checkpoint progress and to distribute partitions across scaled-out instances. It fires on creates and updates and hands the function a batch of changed documents, so the code must loop over items rather than assume one per invocation.

anonymous accepts any caller; function requires a function or host key passed in the code query parameter or the x-functions-key header; admin requires the host master key. Keys are shared secrets and identify no one, so put App Service authentication, Microsoft Entra ID tokens, or API Management in front when you need real caller identity.

Consumption scales to zero and bills per execution, but has cold starts and a 5-minute default timeout with a 10-minute maximum. Flex Consumption and Premium add always-ready or pre-warmed instances, virtual network integration, and longer timeouts, which suits latency-sensitive calls to AI services. A Dedicated (App Service) plan is worthwhile mainly when you already run other apps on that plan.

Deploy the built artifact with zip deploy or run-from-package so the app executes from a read-only package, and put configuration in application settings - local.settings.json is a development file and is never deployed. Prefer identity-based connections, such as ServiceBusConnection__fullyQualifiedNamespace resolved through a managed identity, over connection strings stored in settings.

Azure RBAC is the recommended model: assign a data-plane role such as Key Vault Secrets User to a managed identity, scoped to the vault or to an individual secret, and manage it with the same tooling and access reviews as any other Azure role. Access policies are the legacy per-vault list that cannot scope below the vault. A vault uses one permission model at a time.

Soft delete is always on: a deleted vault or secret remains recoverable for the retention period (90 days by default) and its name stays reserved during that window. Purge protection additionally blocks permanent deletion until the retention period elapses and cannot be switched off once enabled - required for scenarios such as customer-managed keys, but it also means a test vault name cannot be reused right away.

Reference the secret without a version so the vault returns the current one, cache it in memory with a refresh interval instead of fetching per request (the data plane is throttled), and re-read on an authorization failure. Automate the rotation itself with a rotation policy plus near-expiry Event Grid events that trigger a function to write the new version.

Use the Key Vault SDK with DefaultAzureCredential - managed identity in Azure, developer credentials locally - so the app holds no credential of its own. Storing a client secret in app settings just to authenticate to Key Vault moves the problem rather than solving it, because that bootstrap secret is exactly what an attacker needs.

A label is the variant dimension on a key: the same key can hold different values labelled dev, test, and prod, and the app selects the label it wants when it loads configuration. Because values are cached, pair labels with a sentinel key and a refresh interval - the app polls only the sentinel and reloads everything when it changes.

Feature flags are stored as specially typed key-values and evaluated through the feature management SDK, so you can turn a model version or prompt variant on for an environment or a percentage of users without redeploying. App Configuration can also store a Key Vault reference - it holds only the secret URI, so the application still needs its own Key Vault permission to resolve the value.

Add the Azure Monitor OpenTelemetry distro and set APPLICATIONINSIGHTS_CONNECTION_STRING. The distro auto-instruments incoming requests, outgoing HTTP, and Azure SDK calls, and exports traces, metrics, and logs. Instrumentation keys are retired: the connection string also carries the regional ingestion endpoint, so key-only configuration no longer works.

Through W3C trace context: each outbound call carries a traceparent header holding the trace id and the parent span id, and the receiving service continues that same trace. Application Insights surfaces the trace id as operation_Id, which the end-to-end transaction view and Application Map join on. Rebuild a request without forwarding the header - a common mistake in queue workers - and the trace splits in two.

Sampling retains a fraction of telemetry to control ingestion volume and cost. Application Insights stores itemCount on each retained record, so summarize sum(itemCount) still estimates true totals while a plain count() undercounts. Related items from one operation are sampled together, so an end-to-end transaction is kept or dropped as a whole rather than half-recorded.

requests holds inbound calls your app served (duration, result code, success); dependencies holds the outbound calls it made, which is where a slow Azure OpenAI or Cosmos DB call appears; exceptions holds thrown errors; traces holds log statements; customMetrics holds your own measurements. A slow endpoint whose own processing time is small is almost always waiting on a dependency.

Name the table, then pipe rows through operators: requests | where timestamp > ago(1h) | summarize count() by bin(timestamp, 5m), resultCode | render timechart. Filter on time first and narrow columns with project early, because each operator only sees what the previous one emitted - late filtering scans far more data for the same answer.

has and has_any match whole indexed terms and are fast; contains scans for a substring and is slower. == compares case-sensitively while =~ is the case-insensitive form (and !~ its negation). Table and column names are always case-sensitive, so requests and Requests are not interchangeable.