Last reviewed: June 2026
A scannable reference of architectural patterns the C1000-177 exam tests. Read top-to-bottom, or jump to a section.
Stakeholder asks to "find patterns in customers" with no labelled outcome.
Frame as unsupervised (clustering / segmentation). Reserve supervised learning for when a labelled target variable exists.
Why: No target column means there is nothing to predict; forcing a supervised setup invents a label and biases the result.
Deciding between predicting churn (yes/no) and predicting spend ($).
Churn is binary classification; spend is regression. The target's data type drives the task and the metric family.
Why: Mismatching the task to the target produces meaningless metrics — e.g. RMSE on a yes/no label.
Business wants to "reduce fraud" but no fraud flag exists in the data.
Define the target before modelling — agree an operational fraud definition and label historical records, or treat it as anomaly detection.
Why: A vague objective with no measurable target cannot be modelled; the target definition is a business decision, not a technical one.
Choosing a success metric for a marketing-response model.
Tie the metric to business value — e.g. precision/recall at the campaign budget, or expected uplift in revenue — not just raw accuracy.
Why: Accuracy can look high while the model misses the rare responders the business actually cares about.
Asked to sequence a data-science project end to end.
Follow CRISP-DM: business understanding → data understanding → data preparation → modelling → evaluation → deployment.
Why: CRISP-DM is the methodology IBM aligns to; data preparation is iterative and typically the largest effort.
Request is "report last quarter's total sales by region".
Solve with aggregation / BI reporting, not a model. No prediction is required.
Why: Deterministic lookups and aggregations need queries, not machine learning; recognising this avoids over-engineering.
Goal needs a feature the organisation does not collect.
Scope feasibility against available data first; descope the goal or start data collection before promising a model.
Why: Data availability bounds what is achievable; assuming ideal data leads to undeliverable projects.
New tabular dataset just loaded into a notebook.
Start with pandas `df.describe()`, `df.info()`, and `df.head()` to read counts, dtypes, ranges, and obvious nulls.
Why: Summary statistics surface missing values, wrong dtypes, and scale differences before any plotting or modelling.
Need to understand the shape of a single numeric feature.
Use a histogram or KDE plot for shape and a box plot for spread/outliers.
Why: Distribution shape (skew, modality) drives later transform and scaling choices.
Income feature has a long right tail.
Flag it as right-skewed (mean ≫ median); plan a log or power transform during preprocessing.
Why: Skewed inputs distort distance- and variance-based models; identifying skew in EDA informs the fix.
Checking relationships among many numeric features.
Compute a correlation matrix and visualise as a heatmap; inspect pairs with |r| above ~0.8.
Why: High pairwise correlation flags redundancy and potential multicollinearity to address before linear models.
Box plot shows points far beyond the whiskers.
Quantify with the IQR rule (below Q1−1.5·IQR or above Q3+1.5·IQR) or z-score; investigate before deleting.
Why: Outliers may be errors or genuine rare events — EDA distinguishes them so you do not discard real signal.
Exploring whether two numeric features move together.
Use a scatter plot; add a trend line or hue by class to reveal direction, strength, and groupings.
Why: Scatter plots expose non-linear relationships a single correlation coefficient hides.
Profiling a categorical column with unknown cardinality.
Use `value_counts()` and a bar chart to see level frequencies and rare categories.
Why: High cardinality and rare levels change encoding strategy and warn of overfitting risk.
Binary target with unknown class balance.
Plot the target distribution early; note the positive-class ratio (e.g. 3% fraud).
Why: Imbalance discovered in EDA dictates resampling and metric choice (not accuracy) downstream.
Nulls scattered across several columns.
Quantify nulls per column (`df.isnull().sum()`) and inspect whether missingness is random or systematic.
Why: Missing-not-at-random patterns can carry signal; the mechanism drives the imputation decision.
Manager asks "what did EDA tell us?" before modelling.
Summarise data-quality issues, candidate predictive features, and hypotheses to test — not just charts.
Why: EDA's purpose is to form hypotheses and guide preprocessing/feature choices, not to produce decoration.
Organising a data-science effort inside watsonx.
Create a Watson Studio project; add data, notebooks, and models as assets sharing a common storage and runtime.
Why: Projects are the unit of collaboration, access control, and asset lineage in watsonx.
Choosing where Python code executes in Watson Studio.
Attach the notebook to an environment/runtime sized for the workload; release it when idle to control compute cost.
Why: Runtimes consume capacity units; right-sizing balances performance and spend.
Need a strong baseline model quickly with limited time.
Run an AutoAI experiment; it auto-selects algorithms, generates pipelines, and ranks them on a leaderboard.
Why: AutoAI accelerates baselining and feature engineering; you still validate and refine the top pipeline.
Stakeholders prefer a visual, low-code pipeline over notebooks.
Build an SPSS Modeler flow — drag-and-drop nodes for import, prep, modelling, and scoring.
Why: Modeler suits teams that need transparent, code-light pipelines; notebooks suit code-first customisation.
Picking libraries for a code-first analysis.
Use pandas/NumPy for data, scikit-learn for modelling, matplotlib/seaborn for plots — the watsonx default stack.
Why: These libraries are pre-installed in Watson Studio runtimes and assumed by the exam.
A teammate must rerun your analysis next quarter.
Version notebooks and data as project assets, pin library versions, and document the runtime.
Why: Reproducibility depends on captured code, data, and environment — not on a one-off local session.
Scaling features before splitting into train/test.
Split first, then fit transformers on train only and apply (`transform`) to test. Wrap steps in a scikit-learn Pipeline.
Why: Fitting on the full dataset leaks test statistics into training and inflates evaluation scores.
A numeric column has 8% missing values.
Impute with median (robust to skew) via `SimpleImputer`; consider a missing-indicator flag.
Why: Median resists outliers; an indicator preserves signal when missingness itself is informative.
A categorical column has gaps.
Impute with the mode or an explicit "Unknown" / "Missing" category.
Why: An explicit category keeps the missingness pattern as a usable signal rather than discarding rows.
Low-cardinality nominal feature (e.g. region with 5 values).
Apply one-hot encoding (`OneHotEncoder`); drop one column if the model needs no collinearity.
Why: One-hot avoids imposing a false order on nominal categories; dropping a level prevents the dummy trap.
Feature has a natural order (low / medium / high).
Use ordinal encoding that preserves rank.
Why: One-hot would discard the ordering; rank-aware encoding lets the model exploit it.
Categorical with thousands of levels (e.g. ZIP code).
Use target/frequency encoding or grouping rather than one-hot.
Why: One-hot explodes dimensionality; target encoding is compact but must be fit inside CV to avoid leakage.
Features span very different scales before a distance-based model.
StandardScaler (zero mean, unit variance) for roughly Gaussian features; MinMaxScaler to bound [0,1].
Why: KNN, SVM, PCA, and gradient descent are scale-sensitive; tree models are not.
A right-skewed positive feature hurts a linear model.
Apply a log or Box-Cox/Yeo-Johnson power transform to compress the tail.
Why: Reducing skew stabilises variance and linearises relationships for linear and distance-based models.
Want to capture a non-linear age effect in a linear model.
Bin the continuous feature into ranges (equal-width or quantile) and treat as categorical.
Why: Binning lets linear models capture step changes, at the cost of some information loss.
Genuine extreme values destabilise model training.
Cap/winsorise at a percentile or use a robust scaler; delete only confirmed errors.
Why: Capping limits leverage of extremes while keeping the records; deletion loses real rare-event signal.
Positive class is only 3% of training rows.
Resample — SMOTE/oversample minority or undersample majority — fitting only on the training fold; or set class weights.
Why: Balancing the test set would give a false read; resampling belongs inside the training pipeline.
Raw timestamps and amounts under-perform.
Engineer features — day-of-week, time-since-last-event, ratios, aggregates per customer.
Why: Domain-informed derived features often add more lift than swapping the algorithm.
Hundreds of features, many redundant or noisy.
Select via filter (correlation/mutual information), wrapper (RFE), or embedded (L1/tree importances) methods.
Why: Fewer, relevant features cut overfitting, training cost, and improve interpretability.
Many correlated numeric features slow training and overfit.
Apply PCA to project onto top components capturing most variance; scale first.
Why: PCA removes multicollinearity and compresses dimensionality, trading some interpretability for stability.
Multiple preprocessing steps must apply identically in train and serving.
Chain imputers, encoders, and scalers in a `Pipeline` / `ColumnTransformer` fit only on training data.
Why: A single fitted pipeline guarantees consistent transforms and prevents leakage across folds.
A raw date column adds little predictive value.
Decompose into year, month, day-of-week, is-weekend, and cyclical sin/cos encodings.
Why: Models cannot read calendar semantics from a raw timestamp; explicit parts expose seasonality.
Need an honest estimate of generalisation.
Split into train / validation / test; tune on validation, report final numbers on the untouched test set.
Why: Reusing the test set for tuning leaks information and overstates real-world performance.
Small dataset makes a single split unreliable.
Use k-fold cross-validation (stratified for classification) to average performance across folds.
Why: CV gives a lower-variance estimate and uses all data for both training and validation.
Train accuracy high, test accuracy low.
Diagnose overfitting (high variance); add regularisation, simplify the model, or get more data.
Why: The opposite — both scores low — is underfitting (high bias), needing a richer model or features.
Fraud model reports 97% accuracy but misses most fraud.
Use precision, recall, F1, and ROC-AUC / PR-AUC instead of accuracy.
Why: On imbalanced targets a constant majority prediction scores high accuracy while being useless.
Need to see where a classifier makes mistakes.
Read the confusion matrix; derive precision (FP cost) and recall (FN cost) from it.
Why: The right threshold depends on whether false positives or false negatives are costlier.
Evaluating a continuous-target model.
Report RMSE/MAE for error magnitude and R² for variance explained; choose RMSE when large errors matter most.
Why: RMSE penalises large errors more than MAE; R² alone can mislead on non-linear fits.
Default model parameters leave performance on the table.
Tune with grid or randomized search under cross-validation; prefer randomized for large search spaces.
Why: Random search finds good regions faster than exhaustive grids when many parameters interact.
Comparing several candidate pipelines from AutoAI.
Rank on the AutoAI leaderboard by the chosen metric, then validate the top pipeline on held-out data before deploy.
Why: The leaderboard accelerates selection, but the final choice must hold up on untouched data.