CloudDeploy blocked by CloudObject directory permissions when redeploying to an existing URI

CloudDeploy can fail when the deploying Wolfram Cloud identity lacks write access to the directory containing the target CloudObject. The precise component is the cloud object permission model, not the deployed expression itself. This failure mode is documented, but the underlying behavior becomes ambiguous when the target URI already exists.

When the second argument is an existing CloudObject URI, current Wolfram Language documentation does not clearly specify whether CloudDeploy performs an atomic replace or creates a new revision that preserves the old URI. This distinction affects rollback, caching, and whether concurrent readers see a consistent object. The same expression may behave differently across public Wolfram Cloud, Wolfram Enterprise Private Cloud, and a local Wolfram Engine because permission defaults, authentication, and object storage differ. Deployment logs often expose only a generic transport failure, which obscures whether the root cause is the permission model or the expression.

Before diagnosing the expression, the effective identity and permissions on the target path must be identified. However, the exact decision logic for redeploying to an existing URI remains unspecified in a way that complicates reproducible deployment workflows.

Does CloudDeploy treat an existing URI as an atomic replace or as a versioned update? How do permission inheritance rules from parent cloud directories interact with the Permissions option during redeployment? Which environment-specific factors in public, private, and local Wolfram deployments most commonly cause a generic transport failure to mask a permission error?