Run a job at the right time — EventBridge Scheduler

Your goal

Plan a scheduled job with a clear clock, permissions, and failure path.

Why this matters

A daily report should start at a useful local time. You will choose a schedule, authorize its target, and decide what happens if the target cannot accept the work.

Words you will use

A schedule defines when work starts. A time zone gives local time meaning. An execution role grants the scheduler permission to call its target. A retry is another attempt.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Describe the intended time

The report should start at 8 a.m. in the office’s local time. A bare number without a time zone can create surprising results.

What should the schedule specify?

The recurrence, time zone, and acceptable delivery window.

Choose the supported schedule expression and time zone that match the need. Review daylight-saving behavior and whether a flexible time window is acceptable. Test the expected run times before relying on them.

The schedule describes when the business actually needs the job.

Recurrence + time zone + delivery window → planned run

2. Authorize the target call

The schedule exists, but its target call is denied. A clock entry alone does not grant permission to start the job.

What should you check?

The scheduler’s execution role and target permissions.

The execution role must allow the intended target action and be usable by the scheduler. Limit it to the work needed. A valid schedule and valid authorization are separate requirements.

The schedule can call only its intended target.

Schedule → scoped execution role → allowed target action

3. Keep failed deliveries visible

The target is temporarily unavailable at the scheduled time. The team needs a bounded retry plan and a way to inspect work that could not be delivered.

What should be configured?

Appropriate retries and a dead-letter queue, with repeat-safe work.

Use supported retry and dead-letter settings to make delivery failures visible. The job should also handle repeated delivery safely. A schedule starts attempts; it is not proof that the business task completed.

Missed delivery has a visible recovery path.

Delivery attempt → bounded retries → dead-letter handling

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.