How to Create a Date Dimension Table in Power Query
You are a Power BI developer for a healthcare organization. You are building a dataset that includes patient data from an on-premises SQL Server database. The database contains a table 'PatientVisits' with columns: PatientID, VisitDate, DiagnosisCode, and Cost. The database also has a table 'DiagnosisLookup' with DiagnosisCode and Description. You need to create a star schema in Power BI. The requirements are: - The dataset must include a date dimension table that covers all dates from 2010 to 2030. - The 'PatientVisits' table should be the fact table. - Diagnosis descriptions should be in a dimension table. - You must use Power Query to create the date dimension table using M code. - The data refresh must be scheduled daily via the on-premises data gateway.
You have already loaded the 'PatientVisits' and 'DiagnosisLookup' tables. What should you do next to complete the star schema?
Quick Answer
The correct approach is to create a date dimension table in Power Query using the List.Dates function with a blank query, then load it and mark it as a date table. This is the only method that directly satisfies the requirement to use M code for generating a continuous date range from 2010 to 2030, as List.Dates is the native Power Query function for creating sequential date lists. On the PL-300 exam, this scenario tests your ability to distinguish between creating a date table in Power Query versus DAX—a common trap is using CALENDAR or CALENDARAUTO in DAX, which would not meet the explicit “M code” requirement. The exam also emphasizes that marking the table as a date table is essential for enabling time intelligence functions like TOTALYTD. Memory tip: think “List.Dates for M, CALENDAR for DAX”—if the prompt says “Power Query” or “M code,” always choose List.Dates.
⚠ Common exam trap
Many candidates default to using DAX's CALENDAR function (Option A) because it is simpler, but the question explicitly requires M code in Power Query, making DAX-based solutions incorrect even if functionally equivalent.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
In Power Query, create a blank query that generates a date table using the List.Dates function with a custom column for Year, Month, etc. Load it into the model and mark it as a date table.
The requirement explicitly states that the date dimension table must be created using M code in Power Query, and the List.Dates function is the appropriate M function to generate a continuous range of dates from 2010 to 2030. After creating the table with additional columns like Year and Month, you must load it into the model and mark it as a date table to enable time intelligence functions. This approach satisfies the need for a custom date dimension that is not dependent on DAX or auto-generated hierarchies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use DAX to create a date table using CALENDAR function in Power BI Desktop, then mark it as a date table.
Why it's wrong here
CALENDAR is DAX, and the requirement explicitly demands the date dimension be built in Power Query using M code; DAX also cannot be scheduled through the gateway refresh pipeline. It tempts because DAX date tables are common, but they suit models where Power Query generation is not mandated.
- ✗
Enable the 'Auto date/time' option in Power BI Desktop and hide the generated date hierarchy.
Why it's wrong here
Auto date/time generates hidden per-column hierarchies covering only dates present in the fact column, not a contiguous 2010–2030 calendar, and it is created by the engine rather than Power Query M code. It tempts as a quick date table, but it is the right choice only for simple models needing basic time intelligence.
- ✗
In the model view, create a relationship between PatientVisits[VisitDate] and DiagnosisLookup[DiagnosisCode].
Why it's wrong here
VisitDate and DiagnosisCode share no key, so this relationship is invalid and cannot be created; it also leaves the required date dimension absent. It tempts because relating the fact to a lookup feels like star-schema work, but the correct join is PatientVisits[DiagnosisCode] to DiagnosisLookup[DiagnosisCode].
- ✓
In Power Query, create a blank query that generates a date table using the List.Dates function with a custom column for Year, Month, etc. Load it into the model and mark it as a date table.
Why this is correct
A Power Query blank query using List.Dates generates a contiguous calendar covering 2010 to 2030, and adding Year and Month columns supports the star schema. Marking it as the date table enables time intelligence, and it refreshes through the existing on-premises gateway.
Go deeper
Related to this question
About these practice questions
One of 524 original PL-300 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PL-300
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are building a Power BI semantic model that uses a large fact table from a data warehouse. The fact table has a date column and you want to create a date dimension. The organization requires that the date dimension includes all dates from 2010 to 2030, including weekends and holidays. What is the best practice for creating the date dimension?
hard- A.Use the CALENDAR function in DAX to generate the date range
- B.Mark the date column from the fact table as a date table and disable Auto Date/Time
- C.Create a date dimension by using DISTINCT on the fact table's date column
- ✓ D.Create a date table in Power Query by generating a list of dates from 1/1/2010 to 12/31/2030 and then add columns for attributes
Why D: It follows the best practice of creating a dedicated date dimension table in Power Query, which ensures full control over the date range (2010–2030) and allows you to add custom attributes like holidays. This approach avoids relying on the fact table's date column, which may have gaps or missing dates, and ensures the date dimension is complete and independent for robust time intelligence calculations.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PL-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-300 exam.