Which timer should be used?
I have a task to stimulate the work of the traffic light


How can I know which timer to use, 8 bit or 16 bit timer and which prescaler to use?

Typically (especially in an academic setting) a traffic light is implemented as a software state machine.  In plain language, a list of changes of light setting that need to happen with some time in between.
It's not at all clear that such a task would necessarily use a hardware timer at all.  For example, if a processor has no other duties (or at least none that cannot themselves run as an interrupt) then one could do something like this pseudocode:
while (1) {
  set_light_green()
  busy_wait_delay_loop(GREEN_TIME)
  set_light_yellow()
  ...

The downside of course is that the processor is just &quot;busy waiting&quot; for the time of the next cycle, but the advantage is that it's conceptually clean and most environments offer a busy wait loop that's sufficiently accurate for human-scale needs.
To be able to do other things, the program might be re-architected to repeatedly check if it's time for a task.  For example, you might have:
while(1) {
  service_traffic_light()
  service_street_light()
}

with the traffic light routine looking something like:
if (state = GREEN) {
    if (time_now() &gt; next_change_time) {
        state = YELLOW
        next_change_time = time_now() + YELLOW_TIME

this would typically run utilizing some general &quot;system time&quot; capability, for example in the Arduino realm (from your tag) there's the millis() function which uses one of the system timers to provide a shared time reference for any and all purposes (beware it has an eventual overflow hazard if one uses comparison as above, really subtraction should be used, but that's not done here for conceptual clarity).
But let's say that for some reason you didn't want to use a shared timer, but instead use your own.  In that case, what you'd probably do is find the greatest common factor of the various time periods you needed to produce.  Maybe for example that's one whole second.   You'd then set up another timer to produce intervals of a second, and count elapsed intervals in each state.   Maybe with some MCU and main clock frequency one of the timers can't actually produce an interval as long as you like; in that case you use a higher count of small intervals.   Sounds good - only if you actually think about it, this is really just the same as using the already configured millis() timer, only now counting in chunks of a second, or 100 milliseconds, or whatever.   Computers have little trouble counting to thousands instead of single digits, so there's no real benefit there - life will be simpler if you just use the already setup timer traditionally used to track milliseconds, and spend some time learning how to make your usage integer-overflow safe.
So when would you actually use a hardware timer?   Typically when you want to have an event happen as a direct hardware result of the timer count, eg, not monitor the timer in software and set output pins, but have the timer set them directly.  This tends to be situations where you need very precise low-jitter timing, and where the task is simple enough to support that - things like PWM to motor drivers or hobby servos.  Or its complement, precisely counting the duration of an external pulse input to the MCU timer.  You don't have enough timers on an ATmega to implement a traffic light in hardware - at best you could do it via some overly complex external register &quot;queued&quot; by software with a next state that would be &quot;released&quot; by the timer output.  But there's no need; software is well more than fast enough to change the state of a traffic light with the required speed.