AI & ML Concepts

You arrive already picturing AI, ML, GenAI, and deep learning as nested sets from the cheat-sheet above; Task Statement 1.1 asks you to define basic AI terms and describe the similarities and differences between AI, ML, GenAI, and deep learning, and here you learn to map any stem's term to its parent. The cheat-sheet above frames these as nested sets; this section pins down the individual vocabulary the blueprint lists by name so a stem can quote any one of them and you still recognize the parent concept. The figure below draws that nesting directly: AI is the outermost set, ML sits inside AI, deep learning inside ML, and generative AI as the innermost set built on deep-learning foundation models.

Neural networks and deep learning, mechanically

A neural network is a model loosely inspired by the human brain^[1]: layers of artificial neurons (software nodes) connected by weighted links, with an input layer, one or more hidden layers, and an output layer. Deep learning is simply machine learning that uses neural networks with many hidden layers. AWS describes it as an AI method that "teaches computers to process data in a way that is inspired by the human brain"^[2] and explicitly places it as a subset of ML (ML → deep learning → generative AI). The practical reason depth matters: deep networks learn their own hierarchical features from raw, unstructured input, so they handle unstructured data without extensive manual feature engineering^[2]. That is why deep learning, not classical ML, powers the two application areas the blueprint names next.

Computer vision and NLP are application domains, not algorithms

Computer vision is the field that extracts information and insights from images and videos^[2]: image classification, object detection, facial recognition. Natural language processing (NLP) gathers insights and meaning from text^[2]: sentiment, entities, translation, summarization, chatbots. On the exam these are problem domains you map to a service (Amazon Rekognition for vision, Amazon Comprehend for text), not learning techniques. A common trap pairs the domain with the wrong service tier; recognizing "image" vs "text" is the first filter.

Algorithm vs model vs training vs inferencing

The single most tested terminology pair on Task 1.1: an algorithm is the learning procedure; a model is the trained artifact it produces. Training is the phase where the algorithm consumes data and adjusts the model's internal parameters; inferencing (the cheat sheet covers batch vs real-time) is the later phase where the finished model is given new inputs and returns predictions. AWS frames the ML flow exactly this way: historical data is used to train the algorithm^[3], and the resulting model then predicts on new, previously unseen data. Hold the two phases apart: you do not "train a model on new data at inference time". Inference is read-only against frozen parameters.

Bias, fairness, and fit are three different ideas the blueprint bundles together

"Bias" is overloaded, and AIF-C01 exploits it. Statistical bias is the underfitting error: a model too simple to capture the signal, defined fully under Fit, bias, and variance below. Societal/data bias and fairness are about outcomes across groups. A model can be accurate on average yet systematically disadvantage a subgroup, which is why responsible-AI controls (Domain 4) exist as a separate layer. Fit is how well the model generalizes from training data to unseen data. When a question says "the model is biased," the surrounding context tells you which meaning: an accuracy/error discussion points to statistical bias, while a demographic or fairness discussion points to data bias.

The cheat-sheet comparison table contrasts supervised, unsupervised, and reinforcement learning at a glance. This section goes one level deeper into why the data dictates the paradigm, and into the data-type taxonomy the blueprint enumerates, because most Domain 1 questions are really a chain: identify the data, infer the paradigm, then name the technique.

Supervised learning: labels are the teacher

In supervised learning, data scientists supply the algorithm with labeled training data^[3] (each input is paired with its correct output) and the model learns the mapping. Two sub-shapes matter for the exam: classification predicts a discrete category (spam / not-spam, fraud / legitimate, defect type), and regression predicts a continuous number (price, demand, temperature). If a stem hands you historically labeled examples and asks for a category or a number, it is supervised.

Unsupervised learning: structure without answers

Unsupervised algorithms train on unlabeled data and independently spot patterns and categorize data^[3]. The canonical tasks are clustering (group similar records, e.g. customer segmentation), dimensionality reduction, and anomaly detection. The tell in a stem: there is no target column and the goal is discovery ("find natural groups," "surface unusual transactions without prior fraud labels").

Reinforcement learning: reward replaces the dataset

Reinforcement learning has no fixed table of right answers. AWS describes it as attaching reward values to the steps an algorithm must go through^[3], with the agent learning a policy that maximizes cumulative reward through trial and error in an environment. Stem signals: an agent, actions, rewards/penalties, sequential decisions, a game or robot/control loop. If you see those words, neither labeled nor merely unlabeled data is the right framing. It is reinforcement learning.

The data taxonomy: four axes, not one

The blueprint lists labeled/unlabeled, tabular, time-series, image, text, and structured/unstructured as data "types," but they live on different axes:

• Labeled vs unlabeled. Does each record carry the target answer? AWS defines labeled data as input categorized with its corresponding defined output value^[4]; unlabeled data has no such target. This axis decides supervised vs unsupervised.
• Structured vs unstructured. Structured data fits rows and columns (databases, spreadsheets); unstructured data (free text, images, audio, video) has no fixed schema and typically needs deep learning. AWS notes deep learning's value is handling unstructured input that classical ML struggles with.
• Tabular is structured rows-and-columns; time-series is structured data ordered by timestamp (forecasting); image and text are unstructured.

Note a record can be labeled and tabular and structured simultaneously: the axes are independent, which is why "what type of data is this" questions can have one defensible answer per axis. Read which axis the stem is probing (the answer choices reveal it: if options are supervised/unsupervised, it wants labeled vs unlabeled; if options are services, it wants structured vs unstructured). The figure below lays out both axes side by side: labeled vs unlabeled on one, and structured (tabular, time-series) vs unstructured (image, text) on the other.

Fit, bias, and variance as measurable errors

Overfitting is when a model gives accurate predictions for training data but not for new data^[5]: it memorized noise. Underfitting is when the model cannot determine a meaningful relationship between input and output^[5] and fails on both training and test data. AWS ties these to the bias-variance tradeoff directly: an underfit model has high bias^[5] (inaccurate on both sets), an overfit model has high variance^[5] (good on training, poor on test), and more training reduces bias but can increase variance^[5], so the goal is the balanced sweet spot. The exam-portable rule: poor on training too → underfit/high bias; great on training but poor on new data → overfit/high variance.

Task 1.1 is conceptual, but AIF-C01 routinely grounds the concepts in the service that owns the full ML build: Amazon SageMaker AI (formerly Amazon SageMaker). Knowing where "training" and the inference flavors live turns abstract terms into answerable mapping questions.

Training happens in a SageMaker AI training job

The "training" phase from Section 1 is realized as a SageMaker AI training job: you point it at data in Amazon S3, choose an algorithm or your own container, and it spins up compute, runs the learning procedure, writes out the model artifact, then tears the compute down. The exam framing is that you train an algorithm to produce a model: the model artifact is what you subsequently deploy. (Hyperparameter tuning, EDA, and feature engineering are out of scope for the practitioner and belong to Task 1.3's lifecycle subtopic, not here.)

Inferencing maps to four SageMaker AI deployment options

The cheat sheet's batch-vs-real-time split expands into the four options SageMaker AI documents, and matching the latency and payload profile to the option is the exam skill:

• Real-time inference. A persistent endpoint for interactive, low-latency^[6] requests, one prediction at a time (chatbot reply, fraud check at checkout). Choose it when a human or system is waiting on each prediction.
• Serverless inference. Fully managed, auto-scaling, no infrastructure to size; AWS positions it for workloads with idle periods between traffic spurts that can tolerate cold starts^[6]. The cost-conscious choice for intermittent traffic.
• Asynchronous inference. Queues requests for large payloads (up to 1 GB), long processing times (up to one hour), and near-real-time latency^[6]. The pick when a single request is too big or slow for a synchronous endpoint but you still want timely results.
• Batch transform. No persistent endpoint at all; AWS recommends it to get inferences from large datasets and run inference when you don't need a persistent endpoint^[7]. It reads a dataset from S3, starts compute instances, distributes the workload, and writes predictions back to S3^[7], then shuts down. The pick for scheduled bulk scoring (rescore the whole customer base overnight).

The decision rule the exam rewards

Real-time vs batch is the headline distinction the blueprint names, and it hinges on one question: is something waiting on each individual prediction? The figure below models the choice across all four options, following the structure of the AWS "Deploy models for inference" guide. If yes → real-time (or asynchronous for big/slow payloads); if no, and you have a bounded set to score → batch transform; if traffic is spiky and a cold start is acceptable → serverless. Cost and latency move in opposite directions across these (batch is the cheapest per prediction at the cost of latency, real-time is the lowest latency at the cost of always-on compute) and that tradeoff is exactly what a well-written stem makes you weigh.

Domain 1 is 20% of the scored exam, and Task 1.1 questions follow a few repeatable shapes. This section names the patterns and shows why the right answer is right and the common distractors are wrong, so you score on recognition rather than recall under time pressure.

Pattern 1: "Which type of learning?" decided by the data, not the goal

The stem describes a dataset and asks for the paradigm. The deciding clue is what the data carries, never the business goal:

• Historical records, each tagged with the outcome → supervised (and if the answer set forces it: a category → classification, a number → regression). Distractor "unsupervised" is wrong precisely because labels are present.
• Records with no target, goal is to find natural groups / outliers → unsupervised (clustering / anomaly detection). Distractor "supervised" is wrong because there is nothing to predict against.
• An agent, rewards, sequential actions → reinforcement learning. Distractors that mention labeled or unlabeled datasets are wrong because RL learns from a reward signal, not a dataset of answers.

Pattern 2: "AI vs ML vs deep learning vs GenAI" the nesting is the answer

The stem offers four overlapping terms and asks which fits, or which is a subset of which. Anchor on the hierarchy: AI ⊃ ML ⊃ deep learning, with generative AI built on deep-learning foundation models. A stem about multi-layer neural networks on images or text points to deep learning; one about learning patterns from data instead of hand-coded rules points to ML; one about producing new content points to GenAI. The classic distractor calls deep learning a replacement for or alternative to ML. It is a subset of ML, so that option is definitionally wrong.

Pattern 3: "Batch or real-time inference?" find who is waiting

The stem gives a deployment scenario and asks for the inference type or the matching service option. Resolve it with the latency question from the previous section: an interactive, one-at-a-time, user-facing prediction → real-time endpoint; a large, bounded dataset scored on a schedule with no waiting user → batch transform. A frequent distractor offers a real-time endpoint for an overnight bulk job, wrong because it pays for always-on compute and adds operational burden the batch use case does not need. The inverse distractor offers batch for a live checkout fraud check, wrong because batch cannot meet interactive latency.

Pattern 4: "The model performs well in training but poorly in production" overfitting

This is the single most recognizable fit question. "Great on training data, poor on new/unseen data" is the textbook signature of overfitting / high variance; "poor on both training and new data" is underfitting / high bias. The distractor swaps the two, or blames "insufficient training" for an overfit model (more training of the same kind can worsen overfitting). Map the symptom to the term mechanically and the distractors collapse.

Pattern 5: "Should we even use ML here?" appropriateness

Some stems describe a problem and ask whether AI/ML is the right tool. The exam-correct instinct: ML fits when rules are too complex to hand-code but representative data exists; it is the wrong tool when a single guaranteed, deterministic, or fully auditable answer is required (tax calculation, an access-control rule), or when there is too little representative data. A distractor that reaches for a custom ML model where a deterministic rule or a higher-level managed AI service already solves the problem is wrong on cost-benefit grounds: a recurring AWS theme is choosing the highest-level service that solves the problem rather than building from scratch.