Deployment management partners and suppliers
Domain 5: Partners and suppliers
This domain tests deployment when components or services come from suppliers. Expect questions on shared responsibility, contract coordination, and supplier-caused change risk.
Core rules
- Suppliers include cloud providers, SaaS vendors, managed service providers, software vendors, and integrators. Their deployments can change your service even when your own team does nothing.
- Clarify shared responsibility: the provider may deploy infrastructure or platform updates, while you deploy configuration, integrations, and applications. Both sides need notification, maintenance windows, and rollback expectations.
- Contracts and agreements should cover change notification, release cadence, deployment windows, support during cutover, data migration, and exit or rollback. SLAs alone do not coordinate deployments.
- Multi-supplier environments need service integration and management, or equivalent coordination. Track supplier release notes and dependency maps; test interfaces before supplier deprecations.
Worked example
A SaaS vendor will deprecate an API version in 90 days. Your integration must deploy an adapter update first. The contract gives 60 days notice, but the internal team needs 30 days for testing. The deployment plan sequences the adapter release before the vendor cutoff, uses a feature flag for rollback, and schedules a joint test. The reasoning is dependency-first sequencing, not simply waiting for the vendor date.
Traps
- Assuming supplier deployments need no change control.
- Ignoring vendor release notes and deprecation timelines.
- Confusing an SLA with deployment coordination.
- Having no rollback or exit path for supplier-driven change.