SnowPro Advanced Architect Practice Test

The idea being tested is how a materialized view derives its structure from its defining SELECT. When you use SELECT *, the materialized view takes all columns that exist in the base table at the moment the MV is created, and that column list becomes fixed for the MV. If you later add new columns to the base table, those new columns don’t automatically become part of the materialized view. The MV’s schema won’t evolve with the base table—you’d have to redefining the MV with an explicit column list (or recreate it) to include or adjust columns. Explicitly listing columns gives you deliberate control over exactly what is materialized, making maintenance predictable. It avoids schema drift where changes to the base table aren’t reflected in the MV, which is why the recommended practice is to avoid SELECT * in MV definitions.