A previous treatment by the first author [1] presented artifact promotion as a control model for cloud deployment, comparing build-on-target with build-once-and-promote in accessible engineering prose. This paper has two parts. Part I restates the control model in stricter form, covering the release object, the control domains a deployment crosses, the artifact-versus-environment identity distinction, source-control compromise as a control-domain question, and the regulatory frameworks under which the model’s properties become structurally required rather than merely preferable. Part II is an anonymized implementation case study of a production web application on Amazon Web Services, in which the only manual deployment step is the upload of a versioned artifact to an S3 bucket and every subsequent stage runs autonomously. We report end-to-end deployment timings from a development-environment trial.Contributions. Beyond restating the model, the paper (1) characterizes promotion as layer-independent, holding equally for container images, virtual-machine images, operating-system packages, and versioned archives; (2) separates secrets mechanism from secrets timing and shows that build-time secret injection is incompatible with promotion; (3) frames deployment-time dependency resolution as an adversarial supply-chain surface that scales with the dependency closure; (4) derives a separation of release authority from runtime-secret authority;(5) translates the cited compliance frameworks (FedRAMP/SI-7, SOX 404, FFIEC, DO-178C, FDA 21 CFR Part 11, HIPAA, DoD IL) into the concrete obligations they place on engineers, not only auditors; and (6) reports end-to-end deployment timings from a trial. The full list of contributions appears at the end of the Preface.