事象

罠に引っかかるまでの流れを記します。

■準備段階
①検証アカウントで、既に存在していた「AWSDataLifecycleManagerDefaultRole」のARNを確認
②DLMの設定をデプロイするためのCloudFormationテンプレートに①で確認したARNを記載。
※アカウントID部分は本番アカウントIDに置換しました。

■構築時
③新規の本番アカウントでCloud ShellからAWS CLIでAWSDataLifecycleManagerDefaultRoleを事前に作成
④新規の本番アカウントで②で準備したCloudFormationテンプレートをデプロイ

■試験時
⑤構築翌日にDLMの実行がエラーになっていることを確認

入念にCloudFormationテンプレートの中身は確認していたので、単なる誤字脱字ではありませんでした。
皆さんはこの事象が起きた原因が何かわかりますでしょうか。

そもそもIAMサービスロールってなんだっけという方は、以下の記事のIAMサービスロールとIAMロールの違いをまとめた表がわかりやすかったです。
IAMサービスロールとIAMロールの違い

原因

単刀直入に述べると
CloudFormationテンプレートのDLM設定に記載したIAMロールのARN（①で確認したARN）が正しい文字列でなかったこと
が原因でした。

ではなぜ間違っていたか。
それは以下のようにIAMサービスロールの作成方法が異なることが根本の原因でした。

検証アカウントの「AWSDataLifecycleManagerDefaultRole」→ AWSコンソールで作成されたIAMサービスロール
本番アカウントの「AWSDataLifecycleManagerDefaultRole」→ CloudShell（AWS CLI）で作成されたIAMサービスロール

具体的には以下のように異なるようです。

作成方法	ARN形式
AWSコンソール	arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole
AWS CLI	arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole

AWS公式：Amazon Data Lifecycle Manager のデフォルトのサービスロール

話を戻すと、本番アカウントでは新規にCloudShell（AWS CLI）で作成されたIAMロール、つまり /service-role/のパスがつかないIAMサービスロールが作成されたにもかかわらず、
CloudFormationテンプレートのDLMの設定部分では /service-role/のパスがついたIAMサービスロールのARNを指定してしまっていたことにより、エラーが起きたようでした。

あとがき

日頃、事前準備時にリソースに必要なパラメータなどは準備しておくことが多いですが、本番のリソースをどのように作成するかで今回のようにIAM ARNが変わるといったこともあるので、構築の流れを見据えて準備するべきだと学んだ一件でした。
どなたかの役に立ちますように。