Testing unattended-upgrades on a staging VM without production credentials, and deciding the automatic reboot policy

Goal

I want to validate our unattended-upgrades configuration on a staging VM before rolling it out to production Ubuntu servers. The test should mirror production behavior as closely as possible, but the staging environment has no production credentials, no access to internal mirrors that require authentication, and no live mail relay.

Current configuration plan

The plan is to scope Unattended-Upgrade::Allowed-Origins in /etc/apt/apt.conf.d/50unattended-upgrades to the security pocket only, point Unattended-Upgrade::Mail at a local mailbox, and use Unattended-Upgrade::Package-Blacklist to hold back kernel packages during the trial. I would validate with unattended-upgrade --dry-run --debug and review /var/log/unattended-upgrades/ before enabling anything for real. Assume a recent Ubuntu LTS release.

Unresolved decision

The open question is reboot policy. Unattended-Upgrade::Automatic-Reboot defaults to false, and we have not decided whether to enable it with a fixed Automatic-Reboot-Time window, rely on Automatic-Reboot-WithUsers, or leave reboots manual and accept that some updates stay pending.

Questions

• Is a dry-run plus log inspection on a VM a sufficient proxy for production behavior, given that real dependency interactions cannot be fully replicated?
• Can Allowed-Origins and mail reporting be fully exercised without any external accounts or credentials?
• What criteria should drive the automatic reboot decision for services without a defined maintenance window?