Fundamentals of AI and ML

AWS expects you to hold these apart rather than treat "AI" as one thing.

• Artificial intelligence: the umbrella.
• Machine learning: systems that learn patterns from data instead of being explicitly programmed.
• Deep learning: machine learning using multi-layer neural networks; what made modern vision and language possible.
• Generative AI: models that produce new content resembling their training data.
• Agentic AI: systems that use a model plus tools to pursue a goal over several steps.

Training versus inference is worth being precise about because it drives cost. Training is the expensive one-off (or occasional) process of producing a model. Inference is running it to get an answer, and it is what you pay for continuously in production. A conversation about "the cost of AI" that does not distinguish them will go badly.

The three learning approaches, each matched to a problem shape:

Approach	Learns from	Typical use
Supervised	Labeled examples with known answers	Classification, regression
Unsupervised	Unlabeled data	Clustering, segmentation, anomaly detection
Reinforcement	Feedback on its own actions	Sequential decisions, behavior tuning

Matching technique to task is directly tested:

• Regression predicts a quantity: revenue, demand, time to resolution.
• Classification predicts a category: spam or not, which of eight queues.
• Clustering finds groupings nobody defined in advance: customer segments.

Bias and fit round out the vocabulary. Bias is systematic error that treats some cases or groups differently. Overfitting means the model learned the training data including its noise and performs worse on new data; underfitting means it did not learn enough to be useful. Both show up as a gap between how well it scores in development and how well it works in production.

AWS makes "determine when AI/ML solutions are not appropriate" an explicit objective, which is unusual and welcome. The tested judgment is restraint.

AI is not the answer when:

• A specific deterministic outcome is required rather than a prediction. Tax calculations, regulatory thresholds, entitlement rules. These have correct answers that code computes exactly and auditably.
• The cost-benefit does not work. Low volume, high build cost, marginal gain.
• Explainability is a hard requirement and the accurate model cannot provide it.
• Rules already capture the problem completely and they rarely change.

Traditional ML versus foundation models is the more subtle version of the same judgment, and AWS names the criteria: regulatory concerns, explainability requirements, and operational constraints.

A smaller purpose-built model trained on your own data is often better than a foundation model for a narrow prediction task: cheaper to run, easier to explain, easier to validate, and it does not change under you when a vendor ships an update. Reach for a foundation model when the task involves language, unstructured content, or breadth that a narrow model cannot cover.

Managed AI services versus foundation models is the third layer of the same decision. For transcription, translation, document extraction, or entity recognition, a purpose-built managed service is usually cheaper, faster, more predictable, and easier to evaluate than prompting a general model. Reaching for a foundation model when a dedicated service exists is common and expensive.

The pipeline runs from data collection and preparation through feature work, training, evaluation, deployment, and monitoring. The exam-relevant framing is that everything before training is where the effort actually goes, and everything after deployment is where projects quietly fail.

Inference options matter because they map to cost and latency:

• Real-time: a persistent endpoint answering immediately. Highest cost, lowest latency.
• Batch: process a large set on a schedule. Much cheaper where nobody is waiting.
• Asynchronous: submit and collect later. Suits large payloads and long-running work.
• Serverless: scales to zero between requests. Suits spiky or unpredictable traffic.

Choosing batch where the business does not need real-time is one of the largest cost levers available, and it is frequently overlooked because the default is real-time.

Where models come from: open pre-trained models you adopt, or custom models you train. The latter commits you to data, expertise, and ongoing maintenance. How you run them: a managed API service, or self-hosted infrastructure you operate. Managed trades control for far less operational burden.

MLOps exists because a model is not a deliverable, it is a running system: repeatable processes, versioning, production readiness, monitoring, and scheduled retraining. Its absence is why models decay silently.

Metrics come in two kinds, and the exam wants both:

• Model metrics: accuracy, precision, recall, F1. Precision and recall matter most where the classes are imbalanced: a fraud model that says "not fraud" every time can score 99% accuracy and be worthless.
• Business metrics: cost per user, development cost, customer feedback, return on investment.

A project reporting only model metrics has not shown it delivered anything.