How do you attribute cloud costs to ML projects and implement tagging?

WHAT THIS TESTS:

This question evaluates whether you know that resource tagging is the standard cloud-native mechanism for cost attribution, and whether you can design an operational implementation rather than just naming a feature. Interviewers want to see that you understand the difference between simply creating tags and actually governing them so that finance and engineering can trust the data.

A GOOD ANSWER COVERS:

First, name the mechanism explicitly: AWS Cost Allocation Tags, Azure Resource Tags, or GCP Labels. Second, describe a tagging strategy with mandatory dimensions such as project, team, environment, and experiment_id so that costs can be sliced by any combination. Third, explain enforcement through infrastructure-as-code by defining default tags in Terraform or CloudFormation and adding CI/CD policy checks that block deployments missing required keys. Fourth, mention activation steps: in AWS you must activate tags in the Billing Console before they appear in Cost Explorer; in GCP you enable detailed billing export to BigQuery. Fifth, note the pipeline-specific implementation by having the orchestrator pass experiment metadata into resource tags at runtime for compute clusters, storage buckets, and endpoint deployments.

COMMON WRONG ANSWERS:

A major red flag is proposing manual tracking via spreadsheets or asking data scientists to self-report usage after the fact. Another weak pattern is suggesting separate cloud accounts or subscriptions for every project or experiment, which does not scale and ignores the standard shared-tenant model that enterprises actually use. Simply saying use tags without explaining activation, enforcement, or reporting is also insufficient at the senior level because it shows theoretical knowledge without operational follow-through.

LIKELY FOLLOW-UPS:

The interviewer may ask how you handle untaggable resources like some managed services or shared networking costs, so be ready to discuss allocation rules based on data volume or compute share. They might also probe how you prevent tag sprawl, which you can answer with an allowed-values list in a tagging policy and automated remediation lambdas or functions. Another common follow-up is how to surface costs to the end user, which leads to dashboards in AWS Cost Explorer, GCP Billing, or third-party tools like Kubecost tied back to the same tag dimensions.

ONE CONCRETE EXAMPLE:

For a new SageMaker training pipeline, you would define a default tag set in Terraform with keys for Project, Team, Environment, and ExperimentID. The pipeline orchestration tool would inject the specific experiment identifier when provisioning the training job. You would activate these tags in the AWS Billing Console, then build a Cost Explorer saved report filtered by Project and ExperimentID that the finance team reviews monthly. A CI/CD gate using OPA or a simple pre-deployment script would reject any pull request that adds untagged SageMaker resources.