Greengrass: How to detect & auto-heal deployment drift after SD-card fail-over?

Summary

We run a production fleet of Greengrass v2 core devices that boot from a primary SD card but automatically fail over to a minimal secondary SD card when the primary is damaged, causing deployment drift that must be detected and healed.

Scenario

Each device has two SD cards:

• Primary SD – boot + full thing-group deployment (application components).
• Secondary SD – minimal factory image used only if the primary card fails.

The factory image includes only:

• aws.greengrass.Nucleus
• aws.greengrass.TokenExchangeService
• aws.greengrass.LogManager
• aws.greengrass.Cli
• aws.greengrass.crypto.Pkcs11Provider

What happens

1. Device boots from the primary SD.
2. Thing-group deployment succeeds (SUCCEEDED IoT Job).
3. Primary SD later becomes unreadable → bootloader falls back to the secondary SD.
4. Device reconnects to AWS IoT Core / Greengrass missing all application components.
5. Because the previous deployment job is already completed, Greengrass does not redeploy anything, and the core remains UNHEALTHY until we create a new deployment manually.

Questions

1. Drift detection Does Greengrass v2 have a built-in way to notice that the local component state no longer matches the thing-group deployment and automatically trigger redeployment?

2. Recommended pattern / best practice If no built-in feature exists, what approach would you recommend for:

   • Detecting “deployment drift” (component versions on device vs. desired state).
   • Automatically starting a fresh deployment—without manual console or CLI steps—when drift is detected.

Any pointers to docs, sample code, or your own patterns would be hugely appreciated.
Thanks!