Coordinate the AI Workspace and Infrastructure

Where This Task Sits

Coordinate AI workspace and infrastructure is the fourth task of Domain III, and its position matters: it sits after you have identified data sources and locations, and before you gather the data. You are not building the environment — you are confirming it exists, is secure, and is ready before the team needs it. On the exam, the defensible answer treats provisioning as scheduled, owned, dependency-managed work rather than something IT will "sort out."

Start provisioning while sources are still being mapped. Quota approvals, network changes, security reviews, and vendor agreements routinely take weeks, and infrastructure lead time is one of the most common reasons the Data Understanding phase slips. Sequencing provisioning after source mapping finishes is a scheduling error, not caution.

Provisioning Compute for Data Processing and Training

Two questions decide what you request: what shape is the work, and for how long?

• CPU or GPU. Profiling, joins, cleansing, and most classical machine learning — gradient-boosted trees for claims triage, regression for demand forecasting — run fine on central processing units (CPUs). Graphics processing units (GPUs) matter for deep learning: recognition, speech, and anything built on large language models. GPU capacity is scarcer, costs several times more per hour, and carries the longest allocation queue, so discovering you need one a week before training starts is a schedule hit.
• Burst or steady. Training is bursty — heavy for hours or days, then idle. Elastic cloud capacity fits that shape, while a fixed reserved cluster idles expensively between runs. Steady workloads such as a nightly feature build justify reserved capacity at a lower unit rate.
• Cost controls. Insist on budget alerts, spending caps, automatic shutdown of idle instances, and project tagging before the first instance is created. Uncontrolled experimentation on elastic infrastructure produces overruns that surface only at the month-end invoice.
• Quota lead time. Cloud accounts ship with default limits. Raising a GPU quota, opening a network path, or getting a data-transfer agreement signed can take weeks. Each one belongs on the schedule as a dated dependency with a named owner.

Training capacity is not production inference capacity. They are sized on different variables, they behave differently, and they are funded differently, so treat them as two separate requests from the start:

Budgeting only for training leaves you with a validated model and nowhere to run it — a Domain V problem you created back in Domain III. The opposite error is just as common and easier to commit: requesting GPUs speculatively, "in case" the team needs them. Reserved capacity bills whether or not anyone trains on it, and an allocation you queued six weeks for and never used is a budget leak nobody notices until the invoice. Do not raise a GPU request until the data science lead has named the model family that needs one and the workload that justifies it — if the first iteration is gradient-boosted trees on tabular claims data, the honest answer is that no GPU is required at all. Ask for the smallest allocation that covers the planned round with a route to extend it, rather than the largest allocation anyone might eventually want.

Secure Development Environments

Keep development, test, and production separate, with different credentials and different access lists.

The control failure this task exists to prevent is production data copied into a development environment because it was convenient. It is common, it is serious, and it is the fastest route from an experiment to a privacy incident: development environments have looser access, weaker logging, and more people in them, including contractors. Once real customer records land there, everyone on that access list is handling regulated data outside its approved boundary and outside your audit trail.

Two acceptable answers:

• Masked or de-identified data — real structure and realistic distributions with direct identifiers removed, tokenized, or replaced.
• Synthetic data — generated records that preserve the schema and rough statistical shape with no real individuals in them.

Both let engineers build and test pipelines without exposing real records. Training on genuinely representative data may still require approved access to real data inside a controlled environment, and that access is granted through the privacy and access-approval route covered later in this domain — never by copying a table.

Storage and Backup Sized to Real Volumes

Size storage from the data volumes you established when you defined the required data in the first task of this domain, then multiply. A project stores raw extracts, cleaned working copies, engineered features, model artifacts, and logs. Planning against the raw figure alone is the standard underestimate. Model binaries also sit in object storage with integrity hashes while their metadata sits in a registry database — two stores, both needing capacity and backup.

Confirm three things beyond capacity:

1. Backup exists and restore has been tested. An untested backup is an assumption, not a control.
2. Retention rules are set — how long raw extracts, intermediate copies, and derived datasets are kept, and when they are deleted. Retention must match the privacy commitments under which the data was obtained; keeping everything indefinitely "in case we need it" contradicts them.
3. Encryption at rest and access logging are active on every store holding project data.

Collaboration Tooling to Provision

Four pieces of tooling belong on the provisioning list alongside compute and storage, and all four are licensing-and-setup items you can start immediately: a code repository, an experiment tracking service, dataset versioning, and a model registry. Treat them as a set. Procuring only the code repository is the common shortfall, and it is the one that shows up months later as a result nobody can rebuild.

Your Domain III job is confirming these exist, are licensed, and are actually adopted by the team before modeling begins. How they are used — what must be pinned together for a result to count as reproducible, and what each system records — is covered under Domain IV model QA/QC, and it is not a decision you make here.

Security and Governance as a Precondition

Security and governance sign-off is a precondition of data access, not a review you schedule afterwards. Environment hardening, access approvals, encryption standards, logging, and any required privacy assessment must be complete before data lands. Teams that load first and seek approval later usually end up deleting the environment and starting again — and that deletion is the correct outcome.

Infrastructure Readiness Checklist