ACP-220 common mistakes
ACP-220 · Understand the traps and how to avoid them.
Treating Model Studio's built-in application templates as production-ready defaults and quoting their out-of-box parameters as if they were tuned recommendations.
Templates are demo scaffolding; candidates memorize the visible default values instead of understanding which settings (temperature, retrieval config, context limits) must be changed per use case.
What to do instead
For each template, articulate what it assumes about input length, knowledge grounding, and output format, and identify the specific settings you would re-tune and why.
Answering model-selection questions by always picking the largest or newest model rather than matching model capability tier to the task's latency, cost, and modality constraints.
Candidates equate 'more parameters' with 'correct answer' and ignore the trade-off framing that scenario questions are testing.
What to do instead
Build a decision table mapping task types (short classification, long-context summarization, multimodal reasoning, real-time chat) to capability tier, and justify picks on latency/cost/context rather than raw size.
Conflating fine-tuning with retrieval augmentation, e.g., recommending fine-tuning to inject frequently changing factual knowledge.
Both are 'customization' options in the product surface, so candidates pick whichever they studied last without checking whether the problem is behavioral (fine-tune) or knowledge-recency (RAG).
What to do instead
Classify the requirement first: style/format/behavior adherence points to fine-tuning; fresh or proprietary facts point to retrieval; then state the failure mode of the wrong choice.
Describing PAI training jobs as if data, code, and output locations can be arbitrary local paths, ignoring that jobs need accessible storage and registered datasets.
Candidates reason from local-machine intuition and skip the platform's storage/registry layer that connects datasets to training and deployment.
What to do instead
Trace the full lifecycle explicitly: dataset registration, storage mount/URI, job submission, artifact output location, model registration, then deployment endpoint.
Assuming a model deployed to an inference endpoint automatically picks up a newly registered model version, or that redeploying is unnecessary after a retrain.
The lifecycle stages look like one continuous pipeline on slides, so candidates miss the explicit promotion/deployment step between registry and serving.
What to do instead
Memorize the boundary: registration ≠ deployment. State the explicit action needed to serve a new version and how traffic is shifted or rolled back.
Treating multimodal and speech services as interchangeable with text LLM endpoints, e.g., expecting a speech-to-text service to summarize or answer questions directly.
The APIs share auth and invocation patterns, so candidates assume shared capabilities and forget each service's single-responsibility output contract.
What to do instead
For each service, write its input format, output format, and one thing it cannot do; chain services explicitly when a scenario needs transcription plus reasoning.
Ignoring audio/vision input constraints such as duration, sample rate, file size, or image resolution limits when designing a pipeline, and proposing a design that fails at scale.
Candidates focus on model quality and skip the preprocessing/chunking step that service limits force.
What to do instead
For every multimodal scenario, state the input limit, the preprocessing step (resampling, chunking, frame extraction), and how partial results are reassembled.
Using AI coding assistants as autocomplete and accepting generated code without verifying API signatures, SDK versions, or platform-specific configuration.
Generated code looks plausible and compiles conceptually, so candidates skip checking it against the actual SDK surface, which is exactly what exam scenarios probe.
What to do instead
Adopt a verify-then-accept habit: for each generated snippet, identify the SDK call it depends on and confirm the parameter names and return types against documentation.
Over-trusting AI-generated code for security- or correctness-sensitive paths (auth handling, retries, data validation) and shipping it without review.
The assistant produces confident, complete-looking functions, and candidates conflate fluency with correctness.
What to do instead
Define a review checklist for generated code: input validation, error/retry handling, credential handling, and edge cases; apply it explicitly in scenario answers.
Memorizing product feature names without being able to map a stated business requirement to the correct service and justify the choice against alternatives.
Feature lists are easier to cram than decision logic, so candidates recognize terms but cannot discriminate between overlapping services under scenario pressure.
What to do instead
Practice requirement-to-service mapping drills: for each requirement, name the chosen service, one rejected alternative, and the discriminating constraint that decided it.