Explain basic AI concepts and terminologies.

Artificial intelligence is the academic and engineering field concerned with building systems that perform tasks that historically required human cognition: recognizing images, understanding language, planning, recommending, or generating. Machine learning is the subset of AI that obtains those capabilities by learning statistical relationships from data rather than by following explicitly programmed rules. Generative AI is a further subset that learns the joint distribution of training data well enough to produce new, plausible samples (text, images, audio, code) on demand. The exam tests whether a candidate can place a stated capability into the correct layer of that hierarchy and pick the AWS service that targets it.

A second framing the exam uses heavily is the distinction between a prediction and a guaranteed outcome. Machine learning produces probabilistic outputs: a fraud score, a topic label, a generated paragraph. If the business requirement is deterministic ("every refund above 500 USD must be reviewed by a human"), then a rules engine, a workflow built on AWS Step Functions, or a database constraint is the correct answer, not an ML model. Mis-identifying that boundary is one of the most common AIF-C01 trap patterns.

A third framing is fit for purpose under cost and data constraints. Even when an outcome is genuinely probabilistic, ML may still be the wrong tool. Building a custom model demands labeled data, training compute, evaluation cycles, deployment plumbing, monitoring, and retraining. If the volume of decisions is low (twenty per month), if reliable training data does not exist, or if a simple statistical heuristic already meets the target accuracy, then the ML solution is more expensive without measurable benefit. The exam frequently presents a scenario with very few data points and asks the candidate to recognize that an ML solution is not justified.

Determine when AI/ML solutions are not appropriate

The exam guide lists "cost-benefit analyses" and "situations when a specific outcome is needed instead of a prediction" as the two canonical disqualifiers, but practitioners apply a longer checklist:

1. Deterministic regulatory requirements. A capital-adequacy calculation under banking regulations must return the exact value defined by the formula. Approximating it with a regression model creates a compliance breach. Use the formula.
2. Insufficient or biased training data. If the only available historical data reflects a discriminatory loan-approval process, a model trained on it inherits the discrimination. A rules-based or human-in-the-loop approach is preferable until the data set is corrected.
3. Low decision volume. A model that scores ten transactions per week cannot justify its build, evaluation, and monitoring cost. The break-even point depends on the cost of an incorrect decision; the exam typically frames this as "the company processes only a few hundred records per month."
4. Need for full traceability. If every decision must be defensible line by line to a regulator, a model whose internal weights are non-interpretable creates documentation risk. Tree-based models or rules engines are easier to audit than a transformer.
5. High cost of an incorrect prediction with no human reviewer. Autonomous high-stakes decisions (medical dosing, structural engineering) generally require either a human-in-the-loop or formal verification, both of which are outside the scope of a stand-alone ML deployment.

💡 Exam Trap: A scenario describing "must always pay the customer the exact tariff defined in the contract" is a deterministic outcome, not a prediction. The correct answer is a deterministic system, not Amazon SageMaker AI.

⚠️ Anti-Pattern: Building an ML pipeline for a problem that can be answered by a single SQL query. The cost of operating the pipeline outweighs any accuracy gain, and the SQL solution is fully auditable.

🎯 Scenario: A retail finance team wants to apply a "loyalty discount" of exactly 7% to every customer with five or more years of tenure. A junior engineer proposes a classification model. The correct design is a SQL filter or a rule in Amazon EventBridge, because the rule is deterministic, auditable, and changes with the contract, not with retraining.

Methods to use a model in production

Once a model is trained, the exam expects candidates to recognize two consumption patterns and to map them to AWS services.

Managed API service. The model runs in a service that AWS operates: Amazon Bedrock for foundation models, an Amazon SageMaker AI endpoint for custom models, or a fully managed task-specific service (Amazon Comprehend, Amazon Transcribe, Amazon Rekognition, Amazon Polly, Amazon Translate, Amazon Lex). The consumer calls an HTTPS API, authenticates with AWS Signature Version 4 via IAM, and receives a response. The customer is responsible for the request, the input data, prompt design, and downstream handling; AWS operates the model serving infrastructure, scaling, patching, and the underlying accelerators.

Self-hosted API. The model runs on infrastructure the customer operates: an Amazon EC2 instance with GPUs, an Amazon EKS cluster running a model server such as Triton or vLLM, or an on-premises GPU rack. The customer takes on operating-system patching, GPU driver maintenance, autoscaling, load balancing, and certificate management. This is appropriate when the model is bespoke, when latency or data residency constraints rule out a managed service, or when the throughput-economics of a dedicated accelerator beat the per-token price of a managed API.

# Managed API call to a foundation model on Amazon Bedrock
aws bedrock-runtime invoke-model \
 --model-id anthropic.claude-3-haiku-20240307-v1:0 \
 --content-type application/json \
 --accept application/json \
 --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":200,"messages":[{"role":"user","content":"Summarize the loan policy."}]}' \
 --region us-east-1 \
 response.json

# Managed API call to a SageMaker AI real-time endpoint hosting a custom model
aws sagemaker-runtime invoke-endpoint \
 --endpoint-name fraud-scoring-prod \
 --content-type application/json \
 --body '{"amount": 142.50, "merchant_id": "M-9911", "country": "US"}' \
 --region us-east-1 \
 response.json

The choice between managed and self-hosted production patterns is rarely binary. A common hybrid pattern is to use Amazon Bedrock for generative tasks while keeping a small bespoke classifier on an Amazon SageMaker AI endpoint for a domain decision. Both are managed APIs, but the second one runs a customer-owned model.

Limits and quotas

📊 Limit: Amazon Bedrock InvokeModel synchronous request has a 25 MB request body maximum and a 25 MB response body maximum per call (smaller for individual models). For larger payloads, use batch inference with input and output in Amazon S3.

📊 Limit: Amazon SageMaker AI real-time endpoint default request/response payload is 6 MB. For payloads up to 1 GB and processing times up to one hour, use asynchronous inference.

📊 Limit: Amazon SageMaker AI batch transform jobs accept inputs up to several terabytes from Amazon S3, with no per-record size cap beyond what the container supports.

Decision anchor

Choose a managed API service when the team lacks GPU operations skill, the workload tolerates the service's Region availability, and per-call cost is acceptable. Choose a self-hosted API when the model must run in a Region or VPC where no managed service is available, when total cost of ownership at high constant throughput beats the per-call price, or when the model is a bespoke architecture that no managed service supports.

💡 Exam Trap: A scenario stating "the team has no MLOps experience and needs to deploy a chatbot within two weeks" points to a managed API service (Amazon Bedrock plus Amazon Lex), not a self-hosted vLLM on Amazon EC2. The exam rewards minimum operational overhead unless the question specifies a constraint that forbids it.