Make the Azure decision before you build, expose, scale, or change.

• A project is a workspace-level organizing concept; a service resource is the deployable Azure control-plane boundary.
• Resources carry keys, endpoints, managed identity, private endpoints, and diagnostic settings.
• Projects help learners reason about app lifecycle, but production security still lives at the resource, identity, and network layers.

Assuming a project setting secures all deployed endpoints. Exam scenarios often separate development workspace choices from resource-level access and network controls.

• Indexers depend on data-source credentials, skillsets, schedules, and indexer status.
• Manual ingestion shifts transformation, retries, and error handling into app/pipeline code.
• Exam questions often reveal the answer through data-source support, refresh cadence, or required transformations.

Debugging query relevance while ignoring indexer failures or stale source-to-index refresh status.

• Keys are simple but can leak and must be rotated.
• Managed identity reduces secret handling but requires role assignment and supported service integration.
• Exam scenarios often mention Key Vault, app settings, identity, or least privilege as clues.

Putting an AI service key directly in app settings or code because it made the first demo work.

• Content Safety focuses on content category risk; Prompt Shields focus on attack patterns against instructions and grounding.
• Production systems may need both, plus human review and logging.
• Prompt-injection risk becomes more important when agents, tools, or retrieval are involved.

Assuming content moderation alone protects agent tools or system prompts from malicious retrieved text.

• AI Search owns indexes, analyzers, vector fields, data sources, indexers, and retrieval ranking.
• Azure OpenAI owns model deployments, prompt behavior, token usage, and generation quality.
• Many production designs use both: Search retrieves evidence, then OpenAI produces the answer grounded on that evidence.

Treating Azure OpenAI as a knowledge base. Without retrieval, permissions, and grounding, model output may not reflect your approved data.

• Vision OCR is image-centric; Document Intelligence is document-centric.
• Document Intelligence adds layout, prebuilt models, and custom extraction choices.
• The right answer often depends on whether the exam scenario asks for fields/tables or raw text.

Using generic OCR for document workflows that require field confidence, tables, or model-specific extraction.

• CLU is dialog/intent oriented; classification is category-label oriented.
• CLU design depends on utterances, intents, and entities.
• Classification design depends on labeled examples and category boundaries.

Using a conversational intent model for every NLP problem even when the requirement is document classification.

• Layout is broader and structure-oriented; prebuilt models are targeted and field-oriented.
• Prebuilt models reduce custom training when the document type matches.
• Layout is often a step before deciding whether custom extraction is needed.

Training a custom model before testing whether layout or a prebuilt model already solves the extraction need.

• Agents add orchestration concepts that must be secured and monitored beyond the model call.
• Chat completion remains simpler and easier to reason about for stateless prompt/response flows.
• Agent scenarios usually require more attention to tool permissions, data boundaries, and human approval points.

Using an agent for every generative AI scenario. On exams, the simpler model call is often enough when no tool orchestration is required.

• Integrated vectorization reduces custom code but still needs service identity, indexer, skillset, and data-source permissions.
• Custom pipelines can fit mature data engineering flows but create more moving parts to secure and monitor.
• Both patterns need evaluation for chunk quality, relevance, cost, and stale index behavior.

Choosing vectorization mechanics before defining retrieval quality, permissions, refresh cadence, and cost limits.

• Catalog selection is design-time; deployments are runtime resources with cost, quotas, and access patterns.
• Applications usually need deployment names/endpoints rather than catalog entries.
• Operational questions focus on metrics, throttling, capacity, and deployment health.

Assuming selecting a model in a catalog means the application is ready to call it in production.

• Online endpoints need traffic routing, authentication, scale, and live availability planning.
• Batch endpoints need job scheduling, input/output storage, retry behavior, and throughput planning.
• Online cost is tied to serving capacity; batch cost is tied to job execution and data movement.

Using an online endpoint for large offline jobs, then fighting timeout, cost, and scaling issues that batch inference is designed to absorb.

• Prebuilt models reduce training effort but limit field control.
• Custom models require labeled examples and validation but can fit your document shape.
• Custom accuracy depends on representative samples, versioning, and ongoing review after document templates change.

Training a custom model before proving that a prebuilt model fails on real samples, or trusting a prebuilt model without testing edge cases.

• Private endpoint answers “where can traffic come from?”
• Managed identity answers “who is allowed to call or manage this?”
• Strong designs often need both, plus DNS, diagnostics, and least-privilege roles.

Adding a private endpoint and assuming identity/role assignments are no longer needed.

• Prompt flow helps with experimentation and evaluation; code owns production-grade control and app-specific lifecycle.
• Code-first paths may integrate better with existing CI/CD and testing standards.
• Prompt flow can clarify model and prompt behavior before teams harden the production implementation.

Treating prompt flow as a complete production architecture without checking identity, observability, deployment, and rollback requirements.

• RAG keeps knowledge in data sources and indexes; fine-tuning changes the model artifact or deployment behavior.
• RAG needs retrieval quality, chunking, indexing, and access control.
• Fine-tuning needs training data quality, evaluation, cost, deployment governance, and rollback planning.

Fine-tuning a model just because the model does not know private company documents. That is usually a retrieval/grounding problem first.

• An indexer controls data source reads, schedules, field mappings, and indexing runs.
• A skillset controls enrichment steps that transform or add fields during indexing.
• A failed indexer run may be caused by data access, mapping, or skill execution, so inspect both when troubleshooting.

Adding a skillset to fix a data-loading problem. If the indexer cannot reach or map the source, enrichment will not solve it.

• Speech to text is the base transcription workload.
• Speech translation adds language translation requirements and related quality considerations.
• Both require attention to language, audio quality, region, latency, and privacy requirements.

Choosing translation when the scenario only asks for transcription or captions in the original language.

• Vector search depends on embeddings, vector fields, chunking strategy, and distance similarity.
• Semantic ranker works over text results and semantic configuration; it does not replace an embedding strategy.
• Hybrid retrieval can combine keyword, vector, and semantic ranking, but each layer adds cost and tuning complexity.

Turning on every relevance feature at once and then not knowing whether vector quality, keyword matching, or semantic ranking caused the result.