Rather unhelpfully the Nucleo F429ZI UM1974 user manual download link at https://www.st.com/en/evaluation-tools/nucleo-f429zi.html#resource appears to be broken (at time of writing), but I have found a copy elsewhere, and the pin assignments of the three user LEDs is described thus:

The schematic suggests that the factory state of solder-bridges SB120 and SB119 are set for LD1 on PB0 rather then PA5. The problem with your attempt to set LD2 (blue) is that you did not enable GPIOB in the RCC - it enables GPIOA as in the LD1(green) attempt.
Another issue is that your setting of GPIO MODER assumes that the reset state for the port is zero. That is not the case (although it is for the specific pins in question - so you "get away with it" in this case):

It is a good idea to define all the port/pin specific constants in one place so you can switch or add outputs easily and with less chance of error:
#define LED_PORT GPIOB
#define LED_PORT_RCC_EN 0x2u
#define GPIO_MODE_MASK ~0x3u
#define GPIO_MODE_OUTPUT 0x1u
#define GREEN_LED_PIN 0u
#define BLUE_LED_PIN 7u
#define RED_LED_PIN 14u
#define FLASH_LED GREEN_LED_PIN
int main(void)
{
RCC->AHB1ENR |= LED_PORT_RCC_EN ;
LED_PORT->MODER &= GPIO_MODE_MASK << (FLASH_LED << 1) ;
LED_PORT->MODER |= GPIO_MODE_OUTPUT << (FLASH_LED << 1) ;
for(;;)
{
LED_PORT->ODR |= 0x1 << FLASH_LED ;
delayMs( 100 ) ;
LED_PORT->ODR &= ~(0x1 << FLASH_LED) ;
delayMs( 100 ) ;
}
return 0 ;
}
Your delay function is seriously flawed, and likely to be optimised out to "do nothing". Your loop counter needs to be declared volatile to avoid being optimised out. If that happens, the indicator will not visibly blink but will be pulsed at a very high frequency and be on but not at full brightness.
The following will prevent the loops being optimised out.
void delayMs( unsigned delay )
{
for( volatile unsigned d = delay; d > 0; d--)
{
for( volatile int i = 0; i < 3195; i++ )
{
}
}
}
However it is a 180MHz part; if you are running it at full-speed 3195 iterations it will probably not take 1ms. More like a few tens of microseconds. Even if running at the start-up HSI frequency of 16MHz, it is likely to of the order of a few 100s of microseconds, and will in any case vary with optimisation settings and time spent in any interrupt handlers running. Much better to use the Cortex-M SYSTICK counter as follows:
static volatile uint32_t ms_tick = 0 ;
void SysTick_Init(void)
{
SysTick_Config( SystemCoreClock / 1000 ) ;
}
void SysTick_Handler(void)
{
ms_tick++;
}
void delayMs( uint32_t delay)
{
uint32_t start_tick = ms_tick ;
while( (ms_tick - start_tick) < delay );
}
Then the delay will be accurate regardless of the clock speed you run your processor at or interrupt load.