watsonx platform fundamentals and architecture
Domain 1 - watsonx platform fundamentals and architecture
This domain tests whether you can map a business requirement onto the right watsonx component and explain how the pieces fit together at runtime.
The four products
- watsonx.ai - build, tune, and serve foundation models and classical ML: Prompt Lab, Tuning Studio, AutoAI, Jupyter notebooks, and a model catalog of IBM Granite plus third-party open models such as Llama, Mistral and flan-ul2.
- watsonx.data - open lakehouse: object storage with open table formats (Iceberg, Hudi, Delta), Presto and Spark engines, and governed connections to Db2, Snowflake and others.
- watsonx.governance - model inventory, AI Factsheets, risk assessment, and monitoring for both ML and generative AI.
- watsonx Orchestrate - skills and agents that connect models to enterprise systems.
Projects vs spaces
A project is the collaborative workspace holding assets: notebooks, prompts, tuned models, evaluations. A space is the deployment boundary where a model is served and collaborators get inference access. You associate a project with the watsonx.ai Runtime to run notebooks and tuning jobs.
Worked example
A team must log who approved a model, what data it saw, and how it scored. The answer is not the Tuning Studio: create an AI Factsheet in the governance console, attach the model, and record the risk assessment and approval. Reasoning: the requirement is evidence and lifecycle, which is governance, not model building.
Traps that cost marks
- Assuming data must be physically copied into watsonx.data before use - federation and connections are supported.
- Confusing a project asset with a deployment; deleting the project does not necessarily stop a served model.
- Treating watsonx.governance as GenAI-only; it covers traditional ML models too.