Simulado Microsoft Azure AI Engineer Associate (AI-102)

Custom neural models are designed for structured-to-unstructured and mixed-type documents whose layouts vary, and they handle variation in field positions and handwriting far better than template matching — making them the right choice for invoices with unpredictable layouts. A single custom template model is the wrong fit because template models rely on consistent visual positioning (layout cues at fixed coordinates); they degrade badly when layouts vary widely. Using prebuilt-layout and parsing bounding boxes yourself extracts structure (tables, lines, selection marks) but not the semantic key-value fields you want, pushing all the field-mapping logic onto you with no learned generalization. Composing many per-layout template models still inherits the template fragility for each unseen layout variation, and composition only routes inputs to the best-matching sub-model — it does not add the generalization that the variable, handwriting-heavy invoices require.

A composed model groups multiple standalone custom models under one model ID; at analysis time the service classifies the input and routes it to the best-matching sub-model, returning that model's fields — exactly the auto-routing requested. Merging both document types into one custom neural schema is possible but conflates two distinct field sets into a single model, which is harder to maintain, can blur field semantics, and is not the documented routing mechanism. Calling prebuilt-read and branching on detected language is wrong because prebuilt-read does OCR/text and language detection, not document-type classification or custom-field routing. 'Incremental training so the receipt model learns purchase-order fields' is a misconception — Document Intelligence custom models are retrained from a labeled set; there is no online incremental-learning mode that absorbs a second document type into an existing model at inference time.

The central-secret-store pattern is Azure Key Vault accessed via managed identity. Storing the AI key as a Key Vault secret and granting the Function App's identity the least-privilege 'Key Vault Secrets User' (read secrets only) keeps the key out of app settings and source control, and the parallel move to 'Cognitive Services User' RBAC achieves the keyless end state. Wrong: 'app settings marked as slot setting' misunderstands slot settings — they control swap behavior, not secret governance; the value still lives in app configuration, violating the standard. Wrong: 'embed in the deployment package' literally places the secret in build artifacts, the opposite of central, non-source-controlled storage. Wrong: 'grant Key Vault Administrator' violates least privilege — the app only needs to READ a secret; Administrator grants destructive control and is an over-permission governance mistake.