CCNA Visualize and analyze the data Questions

Option A is correct because a single column of visuals matches the vertical scrolling orientation of phones in the Power BI mobile app, so each visual fills the width and remains legible without horizontal panning. Option D is correct because large, easy-to-tap slicers respect touch-target sizing guidance, reducing mis-taps on small screens where precise pointing is difficult. Option E is correct because grouping related measures into one visual (for example, a multi-row card or a single chart with several measures) conserves scarce canvas space and reduces the number of separate visuals a user must scroll through.

Options B and C are not best practices: many small text tables are hard to read on a narrow screen and force zooming, while placing visuals side by side shrinks each one and typically requires horizontal scrolling, which the mobile layout is designed to avoid.

The correct option is A: create an index on the Region column in the source database. In a DirectQuery model, slicer interactions are translated into SQL queries sent to SQL Server, so filtering on Region benefits directly from a supporting index that lets the database seek matching rows instead of scanning the table, which is the most targeted fix for the slow slicer. Option B does not apply because Power BI Desktop caching does not govern DirectQuery query performance against the source.

Option C would improve speed but changes the model's data freshness and architecture rather than optimizing the existing DirectQuery scenario. Option D is not a valid optimization because the 50 distinct values are legitimate business data and reducing them would alter the data model's correctness.

Option B is correct because in a star schema the fact table stores the quantitative, numeric measures (such as Sales Amount or Quantity) along with foreign keys that reference the dimension tables, forming the core of the model. Option D is correct because dimension tables hold the descriptive, textual attributes (such as Product Name, Category, or Customer City) used for slicing and filtering the measures. Option E is correct because star schema relationships are one-to-many, with the dimension on the "one" side and the fact table on the "many" side, filtered in a single direction from dimension to fact.

Option A is incorrect because many-to-many relationships between dimensions are not a star schema design factor; they add ambiguity and are typically avoided or resolved via bridge tables. Option C is incorrect because dimension tables in a star schema are intentionally denormalized (flattened) to reduce the number of joins and improve query performance, not normalized to reduce redundancy.

Option B is correct because a logical tab order lets keyboard and screen-reader users move through report elements in a meaningful sequence, which is a core accessibility requirement in Power BI. Option C is correct because high color contrast between text and background ensures content remains legible for users with low vision or color-vision deficiencies, aligning with WCAG contrast guidance. Option E is correct because alt text gives screen readers a textual description of visuals, charts, and images so non-visual users can understand the data being presented.

Option A is not appropriate because 3D effects reduce clarity and can distort data perception rather than improve accessibility. Option D is not appropriate because using as many colors as possible harms differentiation for color-blind users and creates visual clutter; accessible designs use a limited, distinguishable palette.

The correct option is C: the YTD measure must be wrapped in a CALCULATE that filters the Calendar to the last date in the selected period, because TOTALYTD evaluates at whatever date granularity is in the current filter context, so on a visual by date it returns a running YTD per day rather than a single YTD-as-of-latest-date value. To force the measure to always show YTD as of the maximum date for the selected year, you need something like CALCULATE([YTD Amount], LASTDATE('Calendar'[Date])) (or FILTER to the max date), which overrides the row-level date context. Option A is wrong because an inactive relationship would break all time intelligence, not just the YTD granularity, and the scenario implies the Calendar relationship works.

Option B is wrong because slicer-to-Calendar filtering is not the cause; the slicer already filters the year, and the issue is date-level context within the visual. Option D is wrong because DATESYTD is the underlying time-intelligence function TOTALYTD uses and would not by itself change the per-date evaluation behavior.

Option A is correct because with DirectQuery, every visual interaction translates into queries sent to the underlying source, so defining user-defined aggregations (or aggregation tables) in the data source lets Power BI satisfy many queries from pre-aggregated summary tables instead of scanning detail rows, dramatically reducing query cost and latency. Option D is correct because each visual on a DirectQuery report page typically issues its own query (or queries) to the source, so reducing the number of visuals lowers the number of concurrent queries and the volume of data returned, improving render time and easing source load. Option B is not appropriate because calculated columns are computed and stored in the model at refresh time and, in DirectQuery, they are either unsupported for certain expressions or force row-by-row evaluation that cannot be pushed down, so they do not improve query performance.

Option C is wrong because adding slicers increases the number of queries and filter combinations sent to the source, which adds latency rather than reducing it. Option E is wrong because the Power BI service cache applies to imported/refreshed datasets and cached tiles, not to DirectQuery queries that must hit the source live, so increasing cache size does not speed up DirectQuery reports.

Option D is correct because CALCULATE modifies the filter context of SUM(Sales[Amount]) by applying a filter on the related Products table's Category column, and since a relationship exists between Sales and Products, the filter propagates to the Sales table to return only Electronics sales. Option A is invalid syntax: SUMX requires a table as its first argument and an expression as its second, not a boolean condition and a column. Option B is wrong because RELATED is a column-reference function that requires row context and cannot be used directly inside a CALCULATE filter argument like that.

Option C returns total sales for all categories with no Electronics filter applied.

Option B is correct because RLS in Power BI enforces row filtering through the DAX filter expression defined on each table in the role; when a user is assigned to that role, queries executed against the dataset return only the rows where the DAX predicate evaluates to TRUE. Option E is correct because roles are authored in Power BI Desktop, but user or group membership in those roles is assigned in the Power BI service (via the dataset's Security page or the Admin portal / REST API), since Desktop has no knowledge of the service's users and groups. Option A is not correct because RLS filters data at query time for viewers and does not change or affect the dataset's scheduled refresh process.

Option C is not correct because RLS filters rows in the underlying tables, not visual titles or other report metadata, which are not automatically altered by RLS. Option D is not correct because RLS operates at the row level on tables, not at the measure level; restricting measures requires object-level security (OLS), which is a separate feature.

The Q&A visual (option C) is the correct choice because it lets report consumers type natural-language questions and automatically returns answers as visuals, which is exactly the requirement for asking questions about the data in natural language. Quick Insights (A) instead runs automated analytics to surface patterns and anomalies without accepting user questions. The Key Influencers visual (B) is a predefined AI visual that explains which factors drive a metric, not a natural-language query interface.

Copilot for Power BI (D) can generate report content and summaries, but the dedicated in-report natural-language question feature is the Q&A visual.

The Q&A visual is the correct choice because it lets report consumers type natural-language questions into a report and receive automatic visual answers, which is exactly the requested capability. It works by interpreting the question against the semantic model and rendering an appropriate chart without requiring users to build visuals manually. The Key influencers visual instead explains which factors drive a metric, and the Decomposition tree is for interactive root-cause breakdowns across dimensions, so neither accepts free-form natural-language questions.

Copilot for Power BI can assist with authoring and summaries, but the dedicated in-report feature for natural-language questions and visual answers is the Q&A visual.

Option B is correct because with DirectQuery, every visual interaction is translated into a query against the source, so pushing transformations (filters, joins, aggregations) to the data source lets the source engine do the heavy lifting and reduces the amount of data Power BI must process. Option C is correct because reducing the number of columns in the query shrinks the result set returned to Power BI, lowering network transfer and memory/processing overhead, which directly improves DirectQuery report performance. Option A is not correct because calculated columns are computed and stored in the model, and in DirectQuery they can force row-by-row processing or unsupported query patterns rather than improving source-side performance.

Options D and E are not correct because bidirectional cross-filtering (cross-filter direction set to both) adds extra query complexity and can degrade performance rather than improve it.

The stacked area chart (option B) is correct because it plots each product category as a cumulative band whose thickness represents that category's contribution to total sales, while the total height of the stack shows overall sales across the time axis. This makes it ideal for showing both part-to-whole composition and trends over time simultaneously. A waterfall chart (A) is designed for showing incremental positive and negative changes leading to a final total, not continuous category contributions over time.

A pie chart (C) shows proportions at a single point in time and cannot represent a time series. A scatter plot (D) displays the relationship between two numeric variables as individual points, not compositional contributions over time.

CALCULATE (option C) is correct because it is the only DAX function that modifies the filter context of a measure, allowing you to override or replace existing filters for a specific calculation by supplying new filter arguments. ALL (option A) is a table function that removes filters from a column or table but does not itself change the evaluation context of a calculation. FILTER (option B) returns a filtered table and is typically used as an argument inside CALCULATE, not as the context-modifying function itself.

VALUES (option D) returns a one-column table of distinct values and does not alter filter context.

Option C is correct because adding data labels to visuals makes the underlying values directly readable on the canvas, so users who rely on screen readers or who cannot hover over data points can still access the exact numbers without needing tooltips or mouse interaction. Option D is correct because using a high-contrast theme improves readability for users with low vision or color-vision deficiencies by ensuring foreground text and visual elements stand out clearly against the background, meeting accessibility contrast guidelines. Option A is not correct because a dark background with light text is not inherently more accessible and can actually reduce readability for some users if contrast is insufficient or if it causes glare.

Option B is not correct because images are not inherently inaccessible; they can be made accessible with alt text and are often useful in visuals, so avoiding them entirely is not a valid accessibility improvement. Option E is not correct because removing all tooltips reduces the information available to users rather than improving accessibility; tooltips should be retained and made keyboard-accessible instead.

The Decomposition tree (C) is correct because it is specifically designed to explore hierarchical data by letting users drill down through dimensions in any order, expanding nodes to reveal contributing sub-levels. The Matrix (D) is correct because it natively supports hierarchical row and column groupings, enabling expand/collapse drill-down through levels such as Year > Quarter > Month. The Scatter plot (A) is incorrect because it plots numeric values on X and Y axes to show correlations, with no hierarchical structure.

The Card (B) is incorrect because it only displays a single aggregate value with no drill-down capability. The Pie chart (E) is incorrect because it shows proportional parts of a whole in a flat, single-level format without hierarchy.

The correct option is D: in the 'Edit interactions' settings, ensure that the line chart cross-filters the table. By default, a visual can filter other visuals on the same page, but if the interaction has been set to None (or Highlight instead of Filter), clicking a date point will not filter the table; setting the line chart to cross-filter the table restores the expected behavior so the measure evaluating StartDate/EndDate against the selected date returns only active campaigns. Option A is wrong because disabling cross-filtering would prevent the table from updating at all.

Option B is wrong because drillthrough navigates to a separate drillthrough page rather than filtering the existing table on the same page. Option C is wrong because bookmarks capture static visual states and are not the mechanism for dynamic cross-filtering based on a selected data point.

The correct option is C: check for an updated version of the custom visual from the developer. Custom visuals from AppSource are third-party components that can break when Power BI Desktop updates change the underlying rendering APIs, so the developer typically publishes a compatible update that resolves the rendering issue. Option A is not a real Power BI feature for custom visuals, and compatibility mode applies to semantic model/version settings, not to fixing a broken visual.

Option B would discard the intended custom functionality rather than fix it, and option D merely re-adds the same outdated version, so the problem would persist.

The correct answer is A: add an object to the 'relationships' array. In a Power BI dataset's JSON schema (as used in Tabular Model Scripting Language / TMSL and the dataset definition), relationships between existing tables are declared as entries in the top-level 'relationships' array, where each object specifies the fromTable, fromColumn, toTable, toColumn, and cardinality/crossFilteringBehavior. Since both the 'Sales' and 'Calendar' tables already exist in the dataset, the only required modification is to append a new relationship object describing that join.

Option B is wrong because adding a table to the 'tables' array would create a new table, not define a relationship between two existing ones. Option C is wrong because changing the 'version' field does not create a relationship and could break compatibility. Option D is wrong because a measure is a DAX calculation, not a relationship definition, and it would not establish the required join between the tables.

The correct answer is D: with a live connection to a Power BI dataset, the report is bound directly to the published dataset's model, so calculated columns cannot be authored in the report and must instead be created in the source dataset (using Power BI Desktop or the dataset's modeling features). This is because live connections only allow report-level visuals and measures, not modifications to the underlying tabular model. Option A is incorrect because row-level security is unrelated to preventing calculated columns.

Option B is incorrect because table visuals are fully supported over live connections. Option C is incorrect because there is no 'Allow calculations' setting in dataset settings that enables calculated columns for live-connected reports.

Option A is correct because providing alternative text (alt text) for visuals lets screen readers announce a meaningful description of each chart, image, or shape, which is a core accessibility requirement in Power BI. Option C is correct because sufficient color contrast between text and background ensures that low-vision users and people viewing reports in bright environments can read content, and Power BI's Accessibility Checker flags insufficient contrast. Option B is not recommended because animations can distract users and may cause issues for people with cognitive or vestibular sensitivities, and they are not an accessibility best practice.

Option D is not ideal because relying on color alone to differentiate data points excludes color-blind users; accessible designs should add labels, shapes, or patterns instead. Option E is wrong because small font sizes reduce readability; accessible reports should use legible font sizes rather than shrinking text to fit more data.

A box and whisker plot (C) is correct because it summarizes the distribution of a single numeric variable using the median, quartiles, and potential outliers, making spread and skewness easy to see. A histogram (D) is also correct because it bins a single numeric variable and displays the frequency distribution across intervals, revealing shape, center, and spread. A pie chart (A) is not suitable because it shows parts of a whole for categorical data, not the distribution of a numeric variable.

A scatter chart (B) is not suitable because it displays the relationship between two numeric variables. A bar chart (E) is not suitable because it compares categorical categories or discrete counts rather than showing the distribution of one numeric variable.

Option B is correct because providing descriptive alt text for all visuals lets screen-reader users understand the meaning and content of each chart, table, or image, which is a core accessibility requirement in Power BI. Option E is correct because every visual should have a clear, meaningful title so users of assistive technology and all readers can identify what the visual represents without relying on color or position alone. Option A is incorrect because a complex tab order makes keyboard navigation harder; accessible reports should use a logical, simple tab order.

Option C is incorrect because using only high-contrast colors is not sufficient and can itself create issues; color should not be the sole means of conveying information, and sufficient contrast should be combined with other cues. Option D is incorrect because decorative images should generally be marked as decorative or have empty alt text, not given descriptive alt text, to avoid unnecessary screen-reader noise.

A 100% stacked bar chart (B) is correct because it normalizes each bar to 100%, so every segment represents a category's share of the total, making it ideal for comparing part-to-whole proportions across multiple groups. A pie chart (E) is correct because it divides a single circle into slices whose arc angles are proportional to each category's percentage of the whole, directly visualizing composition. The waterfall chart (A) is not appropriate here because it shows how sequential positive and negative values accumulate to a running total, not proportions of a whole.

The scatter plot (C) is used to show the relationship or correlation between two numeric variables, and the line chart (D) is used to display trends over a continuous dimension such as time, so neither compares parts of a whole.

Using ALL('Date') within CALCULATE removes the filter context on the Date table, causing the measure to return the total sales across all dates, not the current date context. Option A is incorrect; ALLEXCEPT would keep certain filters, but the problem here is specifically the removal of all date filters by ALL. Option C is incorrect; using MIN versus MAX in VAR SelectedDate does not cause the described behavior; the issue is the ALL function.

Option D is incorrect; an inactive relationship would prevent proper filtering but would not result in the measure returning the total for all dates; the symptom would be different.

The correct answer is C: the Date table is missing dates for the previous year, causing SAMEPERIODLASTYEAR to return no data. SAMEPERIODLASTYEAR requires a contiguous, complete date range in a marked Date table to shift the current period back exactly one year; if prior-year dates are absent, the CALCULATE denominator returns BLANK, and DIVIDE yields BLANK for those months. Option A is not the cause because an unmarked date table would typically break time intelligence entirely rather than only certain months, and marking it is a prerequisite, not the root cause here.

Option B is incorrect because DIVIDE returns BLANK only when the denominator is zero or BLANK, which is a symptom of the missing prior-year data, not the underlying cause. Option D is wrong because TOTALYTD computes a year-to-date aggregate, not a prior-year comparison, so it would not fix the YoY calculation.

Option A is correct because applying a high-contrast color theme in Power BI (via View > Themes or a custom JSON theme) increases the luminance difference between foreground text/visuals and background, which helps users with low vision or color-vision deficiencies distinguish content. Option B is correct because adding alt text to every visual in the Visualizations pane's Format > General > Alt Text field lets screen readers such as Narrator, JAWS, or NVDA announce a meaningful description of each chart, making the report navigable for blind users. Option C is wrong because small font sizes reduce legibility rather than improve it, working against accessibility best practices.

Option D is wrong because high color saturation alone does not guarantee sufficient contrast and can actually worsen readability for users with color-vision deficiencies. Option E is wrong because complex drillthrough interactions add navigation complexity and are not an accessibility improvement; simpler, predictable navigation is preferred.

A slicer is correct because it lets users interactively filter the report page by selecting a region, and the sales details visuals on that same page update in place without any navigation. This matches the requirement of staying on the same page while changing the displayed data. Drillthrough would not fit because it navigates users to a separate drillthrough page filtered to the selected item.

A matrix with expand/collapse changes the level of detail within a single visual rather than filtering the whole page by region selection. A card visual only displays a single aggregated value and provides no selection mechanism.

Option B is correct because AI visuals such as Key Influencers and Decomposition Tree have practical limits on the volume of data points they can process effectively, so large datasets may need filtering or aggregation before use. Option D is correct because several AI-powered features (for example, some Cognitive Services integrations and certain AI insights) require Power BI Premium or Premium Per User capacity rather than being fully available on shared/Pro capacity. Option E is correct because AI visuals depend on the semantic type of fields: for instance, Key Influencers needs a categorical field to analyze and a numeric or categorical target, while Q&A and Smart Narrative rely on properly typed numeric, categorical, or date fields to generate meaningful results.

Option A is not a valid consideration because AI visuals are part of Power BI Pro/Premium licensing and do not require a separate 'AI workload' license. Option C is not correct because AI visuals are not deprecated in favor of Copilot; Copilot is an additional generative feature, and the AI visuals remain supported.

The correct option is B: add latitude and longitude fields to the map visual. Power BI's built-in map relies on geocoding city names, and ambiguous or duplicate city names across regions often fail to plot, so supplying explicit latitude and longitude values gives the visual unambiguous coordinates to render each store location. Option A is unnecessary because switching to the ArcGIS Map visual does not resolve missing geocoding data.

Option C is irrelevant since a filled map still depends on the same geocoding and would not fix missing points. Option D is not the issue because the scenario already confirms the city names are correct, and a text data type is expected for city fields anyway.

The correct answer is D: use the Analytics pane to add a constant line, because in Power BI the Analytics pane is the built-in feature that lets you add a horizontal constant line to a line chart and set its value to 100,000 (with options for color, style, and data label). This directly produces the target reference line the user wants without altering the data model. Option A is incorrect because constant lines are not added from the Formatting pane.

Option B is wrong because a gauge visual shows progress toward a target rather than overlaying a target line on the existing line chart. Option C is wrong because a calculated column adds a data field to the model and does not by itself render a horizontal target line on the chart.

Option B is correct because custom visuals from AppSource are compiled against specific Power BI API versions, so a visual built for a newer API than your Power BI Desktop build can fail to render; confirming version compatibility is a standard first troubleshooting step. Option C is correct because updating the visual to the latest version from AppSource resolves known rendering bugs and ensures you have the most recent API-compatible build. Option E is correct because custom visuals require their expected data roles/fields to be bound; if required fields are missing or mapped incorrectly, the visual will render blank or incorrectly.

Option A does not belong because disabling hardware acceleration addresses general rendering glitches in Desktop, not a specific AppSource custom visual's compatibility or data-binding issues. Option D does not belong because clearing the browser cache applies to the Power BI Service in a browser, not to troubleshooting a custom visual in Power BI Desktop.

Option D is correct because a drillthrough page keeps the main category page lightweight and only loads the daily revenue line chart when a user right-clicks a product and drills through, so the 10 million-row detail query runs on demand rather than on every page render. This design also lets the drillthrough page be filtered to the selected product, reducing the data volume processed by the line chart. Options A and C are wrong because rendering both category and daily-trend visuals on one page forces all queries, including the high-cardinality daily aggregation, to execute on initial load.

Option B is wrong because bookmarks only toggle visual visibility on the same page; hidden visuals and their underlying queries can still be evaluated, so it does not reliably reduce load time.

Option A is correct because DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -30, DAY) returns a 30-day rolling window ending at the last date in the current filter context, which is exactly what a 'last 30 days' measure requires when the model has a marked date table. Wrapping it in CALCULATE with COUNTROWS(Sales) then counts the Sales rows whose related Date values fall in that window. Option B uses DATESBETWEEN with TODAY()-30 and TODAY(), which hard-codes the window to the actual current date rather than the model's latest date and can return blank or wrong results if the data is not current.

Option C uses PREVIOUSMONTH, which returns the entire prior calendar month, not a 30-day period. Option D uses DATEADD with -30 DAY, which shifts the current filter context back 30 days rather than returning a 30-day range, so it does not produce a rolling 30-day count.

In Power BI Paginated Reports, every report must be bound to at least one dataset (option C), which defines the fields and query results the report's tables, matrices, and other regions render. That dataset in turn must be backed by a data source (option D), the connection object that specifies the provider and connection string used to retrieve the data. Together, the data source and dataset form the minimum required data-retrieval components of a paginated report.

A subscription (option A) is an optional delivery mechanism for scheduled report distribution, not a required report component. A map visual (option B) is just one optional report item type, and a query parameter (option E) is an optional filtering/parameterization feature, neither of which is mandatory for a paginated report to exist.

Option A is correct because in a composite model, DAX functions that traverse relationships between DirectQuery and Import tables (or that rely on certain query-folding capabilities) can be limited; functions like CALCULATE, time intelligence, and some iterators may not fully translate to the source, so cross-storage-mode calculations can behave differently or be restricted. Option C is correct because when a report needs aggregations that combine data from both DirectQuery and Import sources, Power BI must query the external source and then combine results locally, which can degrade performance due to network latency, source query cost, and limited query folding. Option B is incorrect because relationships can be defined across tables of different storage modes in a composite model; that is a core capability of composite models.

Option D is incorrect for the same reason—DirectQuery tables can be related to imported tables as long as the relationship is valid and the model is configured as a composite model. Option E is incorrect because measures can be created on DirectQuery tables as well as imported tables; there is no requirement that all measures reside in imported tables.

The correct answer is D, ALL, because it removes all filters from the specified table or column and returns the grand total across the entire dataset, which is exactly what is needed to compute each category's percentage of total sales (e.g., SUM(Sales[Amount]) / CALCULATE(SUM(Sales[Amount]), ALL(Product[Category]))). ALL is the standard DAX function for obtaining an unfiltered grand total in ratio measures. VALUES does not remove filters; it returns a single-column table of distinct values, so it cannot produce a grand total.

ALLSELECTED respects filters applied outside the query (such as slicers) rather than giving the true grand total, and REMOVEFILTERS is a filter modifier used inside CALCULATE that removes filters but is not the conventional function for retrieving a grand total in this scenario.