Tips, Trampas y Chuletas del DP-700

01Elegir el artefacto de almacenamiento correcto

🎯 Método: tacha cada requisito uno a uno sobre cada opción. Gana la que no falla ninguno, no la que "encaja con la palabra que más suena".

02Elegir herramienta de transformación

🎯 Caza la palabra clave: "visuals" → notebook · "windowing" → T-SQL · "low-code/simple" → dataflow.

03Arquitectura medallion: herramienta por capa

🎯 La respuesta sale de cazar la frase exacta del requisito, no de qué herramienta prefieres. Bronze pide cero transformación → Copy activity (¡NO dataflow, que transforma!). Silver pide limpieza pesada → notebook.

04Modelado dimensional (star schema)

🎯 Reglas de oro:

• Star schema = dimensiones denormalizadas (planas, una tabla por dimensión). "Minimize joins / development effort / analytical performance" → estrella ⭐
• Snowflake = dimensiones normalizadas en varias tablas → más joins, más complejo.
• Joining key = siempre surrogate key (identificador único generado por el sistema), nunca nombres ni fechas de negocio.

💡 Por qué surrogate key y no la business key del origen: aísla de los cambios del origen, soporta SCD (historial) y hace joins más eficientes (entero pequeño).

05SCD: los 4 tipos (0, 1, 2, 3)

Qué hace cada tipo cuando un valor cambia (ejemplo: una clienta se muda de ciudad):

🎯 Identificar en el examen:

• "histórico / at the time of / point-in-time / track over time" + columnas ValidFrom/ValidTo → Type 2.
• "solo valor actual / overwrite / latest" → Type 1.
• "valor actual Y anterior" (un nivel) → Type 3.
• "nunca cambia / inmutable" → Type 0.

06Join a un SCD Type 2: histórico vs actual

Columnas de un SCD Type 2: valid_from (desde cuándo), valid_to (hasta cuándo) e is_current (¿es la versión de ahora? 1/0).

🎯 Regla: "historical / point-in-time / como era ENTONCES" → rango de fechas. "current / como es AHORA" → is_current = 1. El límite inferior es >= valid_from (inclusivo) y el superior < valid_to (exclusivo, para no solapar versiones).

07Hash functions para detectar cambios

Un hash es una "huella dactilar" de una fila: convierte todas las columnas en un código corto. Si CUALQUIER dato cambia → el hash cambia por completo.

🎯 Uso: detectar cambios en tablas anchas (muchas columnas) de forma eficiente. En vez de comparar 100 columnas × millones de filas, comparas un solo hash por fila.

💡 Regla: "detectar cambios + muchas columnas + minimize resources" → hash function sobre los datos entrantes (source). Implementación real: HASHBYTES('SHA2_256', ...) en T-SQL o sha2() en PySpark. También se llama "row hash" o "checksum column".

08Roles de workspace y least privilege

🎯 Regla de oro (¡patrón que cae fijo!): cuando el enunciado dice "you already assigned object-level / item permissions" + "least privilege" → la respuesta es casi siempre Viewer, porque la escritura ya está cubierta por otra vía (object-level) y el rol de workspace solo tiene que aportar la visibilidad.

💡 Lección transversal: lee dos veces las frases que parecen de relleno ("you already assigned..."). Suelen resolver medio requisito y cambiar la respuesta.

09Sharing de Lakehouse y permisos

🎯 Reglas de oro:

• "SQL sí, Spark no" → Read all SQL endpoint data sola (sin ReadAll). ReadData da las tablas por T-SQL pero NO los ficheros.
• "Que no vea el resto del workspace" → sharing directo del item, cero roles de workspace.

10Roles de dominio y gobierno

🎯 Regla de oro: "gestionar dominio / crear subdominios / asignar workspaces" + "least privilege" → domain admin (NO Fabric admin).

💡 Señal luminosa: la coletilla "principle of least privilege" casi nunca lleva al rol más poderoso. Elige el permiso más ajustado que aún cumpla la tarea.

11Dominios: la herencia que no existe

🎯 Regla de oro: pertenecer a un dominio NUNCA da un rol de workspace. Son planos separados:

• Dominio = gobierno (organización lógica, sensitivity labels, catálogo).
• Roles de workspace = acceso real (Viewer/Contributor/Member/Admin).

Nadie "hereda" acceso a un workspace por estar en el mismo dominio o grupo → hay que asignar el rol explícitamente.

12Contributor bypasea OneLake Security (aislar PII) ⭐

🎯 CONCEPTO CRÍTICO: los roles de workspace Admin/Member/Contributor BYPASEAN la seguridad de OneLake (RLS/CLS/table-level). Si un usuario necesita escribir en un lakehouse (requiere Contributor o superior), automáticamente puede leer TODO ese lakehouse, incluida cualquier PII.

💡 Nota del mundo real: "migrar la tabla" en el examen es un paso conceptual; en la práctica es un notebook/pipeline/CLI, y el deployment pipeline NO copia datos. El examen abstrae el "cómo".

13Row-Level Security (RLS)

El RLS en Fabric Warehouse son dos piezas: una inline table-valued function (TVF) (el predicado) + un CREATE SECURITY POLICY que la aplica.

-- 1️⃣ LA FUNCIÓN (predicado): inline TVF
CREATE FUNCTION dbo.tvf_rlspredicate(@Author AS varchar(50))
    RETURNS TABLE
WITH SCHEMABINDING                    -- ← palabra clave tras WITH (NO "inline")
AS
    RETURN SELECT 1 AS resultado
    WHERE @Author = USER_NAME()        -- ← compara con el usuario actual
GO

-- 2️⃣ LA POLÍTICA (aplica el filtro):
CREATE SECURITY POLICY RLSFilter
ADD FILTER PREDICATE Security.tvf_rlspredicate(AuthorEmail)  -- la columna aquí
ON AuthorSales                          -- ← solo la TABLA, no tabla.columna
WITH (STATE = ON)                       -- ON = activa la política

🎯 Piezas clave:

• Si piden UN objeto imprescindible → FUNCTION.
• Tras RETURNS TABLE → WITH SCHEMABINDING (no INLINE; inline es el tipo de función, no una keyword).
• El predicado usa USER_NAME() para identificar al usuario.
• En el ON de la policy → solo el nombre de la tabla.

💡 Bonus: en Direct Lake, si hay RLS en el SQL endpoint, Power BI hace fallback a DirectQuery.

14Column-Level Security (CLS)

Oculta columnas enteras (da error si las pides, no las ves).

GRANT SELECT ON tabla(col1, col2, col3) TO [usuario@dominio.com];
-- Las columnas OMITIDAS de la lista quedan ocultas

🎯 Reglas de oro:

• Permiso de lectura = SELECT (nunca "READ").
• Usuario = email de Entra entre corchetes [user@contoso.com].
• Ocultar una columna = omitirla de la lista.

💡 CLS vs DDM: el CLS oculta (error si la pides); el DDM enmascara (la ves con XXXX). "Prevent accessing" → CLS. "Ver parcial/enmascarado" → DDM.

15Dynamic Data Masking (DDM)

Enmascara los datos sensibles (los ves con XXXX, no se ocultan).

ALTER TABLE dbo.tabla
ALTER COLUMN columna
ADD MASKED WITH (FUNCTION = 'partial(2,"XXXXXXXXX",4)');

🎯 Sintaxis fija: ALTER TABLE ... ALTER COLUMN ... ADD MASKED WITH FUNCTION (siempre ALTER + ALTER).

💡 El Viewer lo ve enmascarado; Admin/Member/Contributor o quien tenga UNMASK ven los datos reales.

16Endorsement badges

Solo existen 3 badges (+ "no endorsement"):

🎯 Trucos:

• El item es un dashboard → respuesta casi segura "Cannot be endorsed".
• "core / single source of truth" + lakehouse/semantic model → Master data.
• "meets organizational standards" → Certified. "ready for sharing and reuse" → Promoted.

17Deployment pipelines: qué se despliega y qué no

🎯 Regla de oro: los deployment pipelines despliegan metadata y contenido, NUNCA datos ni triggers operativos (schedules).

🔧 Nota del mundo real: el botón Compare puede marcar un dataflow como "Different" si tocaste su programación en un stage — es la metadata del item marcada como modificada (y el compare de dataflows da falsos positivos famosos). Eso NO significa que el schedule viaje al desplegar.

18Git integration: GitHub vs Azure DevOps

🎯 Reglas de oro:

• GitHub + commit + least privilege → Contents (Read and write) only. NO Actions, NO Commit statuses.
• Azure DevOps → detalles: org + project + repository + branch. Autenticación OAuth, NO PAT.
• Si ves "PAT" en una pregunta de Azure DevOps → señuelo (el PAT es de GitHub).
• Solo un workspace Admin conecta a Git.

19Identidades y autenticación

🎯 Truco — pregúntate "¿quién llama a quién?":

• Algo externo llama a Fabric (Azure DevOps ejecuta un deployment pipeline vía API) → service principal.
• Fabric necesita acceder a un recurso de Azure protegido → workspace identity.

20Conectividad de red

🎯 Regla de oro: "Azure resource + public access disabled + Spark job/notebook" → managed private endpoint. "on-premises SQL Server + gateway + copy data" → pipeline (Copy activity).

💡 Efecto secundario del MPE: al crearlo se genera una managed virtual network que desactiva los starter pools → los Spark jobs arrancan en pools on-demand (3-5 min más lentos al inicio).

21Orquestación: schedule vs evento vs encadenado

💡 Workflow event-driven: "when a file arrives → process it" = reflex item (el trigger que escucha el evento) + pipeline/notebook (la acción). Un fichero en la carpeta Files del lakehouse → OneLake event. "as soon as possible" → evento, NUNCA schedule.

22runMultiple y DAGs

DAG = Directed Acyclic Graph = mapa de tareas con dependencias (qué va antes de qué), sin bucles. NO es un fichero: es una variable de Python dentro de una celda del notebook.

DAG = {
    "activities": [                          # lista de tareas
        {"name": "NB1", "path": "NB1", "timeoutPerCellInSeconds": 300},
        {"name": "NB2", "path": "NB2", "dependencies": ["NB1"]}  # NB2 espera a NB1
    ],
    "timeoutInSeconds": 43200
}
mssparkutils.notebook.runMultiple(DAG)       # notebookutils = nuevo nombre

🎯 activities = tareas · dependencies = orden · runMultiple = ejecuta.

💡 runMultiple (solo notebooks, comparten sesión de Spark, ahorra CU) vs pipeline (mezcla tipos de actividad, conectores, triggers).

23Environments (librerías por defecto)

3 pasos en orden para tener librerías por defecto en el workspace:

1. Create an environment (el contenedor vacío).
2. Install the libraries (llenarlo).
3. Set the default environment (marcarlo como default).

24Patrón de ingesta metadata-driven ⭐

Para la ingesta dinámica de N tablas listadas en una tabla de control, en una sola ejecución:

1. Lookup    → lee la lista de la tabla de control → array
2. ForEach   → recorre cada tabla del array
   └─ 3. Copy data (inner) → copia esa tabla (parametrizada con @item())

🎯 Los 3 pasos en orden: Lookup (leer la lista) → ForEach (recorrer) → Copy data dentro del bucle.

💡 Ventaja real: añadir una tabla = añadir una fila a la tabla de control, sin tocar el pipeline.

25Ingesta: qué item usar

🎯 Asociaciones fiables:

• On-premises + gateway + copy data → pipeline (Copy activity). (Nunca notebook/Spark: no hablan con el gateway on-prem.)
• Copiar batch A→B sin transformar → pipeline con Copy activity.
• Near-real-time + streamed from REST API + only Fabric → eventstream.
• Transformación con código → notebook (si la fuente es accesible por Spark).

26Copy activity → Warehouse (staging)

🎯 El Warehouse ingesta con COPY INTO, que solo lee directamente de Azure Blob y ADLS Gen2. Si el origen NO es compatible (Snowflake, on-prem, etc.) → Enable staging (staged copy): pasa por un storage intermedio y luego hace el COPY.

27CDC (Change Data Capture)

🎯 CDC = función de una base de datos que registra automáticamente todos los cambios (inserts/updates/deletes). Es el "diario de cambios" que herramientas como el eventstream o el pipeline leen para propagarlos.

💡 Regla: "stream record changes from a SQL DB" + "no se propagan" → Enable CDC en la BD origen.

No confundir:

• CDC = captura cambios de DATOS (inserts/updates/deletes). ✅
• Extended Events = diagnóstico y rendimiento (queries lentas, deadlocks). NO cambios de datos. ❌ señuelo.
• Read-only replica = distribuir la carga de lecturas. ❌

28Caché de shortcuts

Para que un shortcut sirva datos desde la caché deben cumplirse LAS TRES condiciones:

1. Fuente cacheable: S3 / GCS / S3-compatible / on-premises gateway. ❌ ADLS Gen2 (Azure) NO (no hay egress cross-cloud que ahorrar).
2. Tamaño del fichero ≤ 1 GB (los > 1 GB nunca se cachean).
3. Último acceso dentro de la ventana de retención (por defecto 24 h; configurable de 1 a 28 días; cada acceso resetea el contador).

🎯 Algoritmo (aprende esto, no la respuesta — los números cambian):

1. ¿Fuente cacheable? (S3/GCS sí, ADLS Gen2 no).
2. ¿≤ 1 GB?
3. ¿Accedido dentro de la retención?

Si falla cualquiera → va al origen, no a la caché.

29Patrón de carga: overwrite vs merge

Patrón híbrido con DeltaTable.forName como comprobación de existencia:

• La tabla NO existe → write.mode('overwrite') (full load inicial) + return.
• La tabla SÍ existe → MERGE (upsert incremental).

🎯 Cuidado con "always" en las preguntas de Sí/No:

• "always overwritten" → No (solo la 1ª vez, cuando no existe).
• "merge always runs" → No (solo si la tabla ya existe).
• "supports full AND incremental" → Sí (overwrite = full la 1ª vez, merge = incremental después).

💡 overwrite = "escribe en modo reemplazo": si la tabla no existe, la crea; si existe, la reemplaza. NO necesita nada previo. Todos los modos (overwrite/append/error/ignore) crean la tabla si no existe; difieren solo en qué hacen si YA existe.

30Delta MERGE: whenMatched / BySource ⭐

targetDF.merge(sourceDF, "source.Key = target.Key")
  .whenMatchedUpdate(set={...})              # existe en AMBAS → actualizar
  .whenNotMatchedInsert(values={...})         # nueva en SOURCE → insertar
  .whenNotMatchedBySourceUpdate(              # huérfana en TARGET → inactivar/borrar
      condition="...", set={"Status": "inactive"})
  .execute()

🎯 La clave es "BySource":

• Sin "BySource" → mira desde el source ("nueva del origen" → insertar).
• Con "BySource" → mira desde el target ("huérfana, el origen ya no la trae" → soft delete / inactivar).

31Real-Time Intelligence: las 4 piezas ⭐

🌸 Analogía: una fábrica de paquetería 📦 donde los "paquetes" son datos que llegan sin parar:

🎯 Identifica por el VERBO:

• "descubrir/ver qué streams hay" → Real-Time hub
• "ingesta/mueve/transforma streaming" → Eventstream
• "guardar + consultar con KQL datos RT" → Eventhouse (+ la KQL database dentro)
• "cuando pase X, dispara Y" → Activator / reflex item

💡 Flujo: los datos entran por el hub → viajan por el eventstream → descansan en el eventhouse → el activator los vigila para reaccionar.

32Eventstream vs Notebook (transformar)

🎯 Los datos en streaming fluyen sin parar → transformaciones ligeras para no atascar el flujo → eventstream (no-code). Streaming + complejo + código → Spark Structured Streaming (notebook, la excepción). Batch + código → notebook normal.

33Windowing functions

🎯 Palabras clave que cantan cada una:

• "non-overlapping / contiguous / each event in exactly one window / fixed intervals" → TUMBLING ⭐
• "overlapping / moving average / smoothed / hop" → HOPPING
• "every event / continuously / anomaly detection" → SLIDING
• "inactivity gap / session / user activity / dynamic duration" → SESSION

34Operadores de transformación de Eventstream

💡 Para agregaciones avanzadas por ventana temporal (como la desviación estándar) → Group by (permite elegir la ventana + la función estadística).

35OneLake availability en Eventhouse

Al activar la OneLake availability en un eventhouse/KQL, por defecto:

• Solo fluye a OneLake lo que se ingiere a partir de ese momento (datos nuevos).
• Los datos existentes NO se rellenan hacia atrás (no hay backfill).

🎯 Regla de oro: "you enable OneLake availability" (a secas) → only new data. Si mencionan explícitamente "apply to existing tables" → entonces new + existing.

💡 Bonus: con la OneLake availability activa en una tabla, NO puedes borrar/truncar/purgar datos, ni alterar el esquema, ni renombrar la tabla (restricciones del "one logical copy").

36KQL: operadores esenciales y prev()

🎯 Reglas de oro:

• sort/order by es DESCENDENTE por defecto → si piden "ascending" y falta asc → No cumple.
• extend CREA columna, project ELIGE columnas.
• prev()/next() necesitan sort/order by antes (serialización).
• sort/order by antes de project es válido (el orden entre operadores es flexible).
• KQL database + código T-SQL → No (lenguaje equivocado). KQL ordena DESCENDENTE por defecto; T-SQL ordena ASCENDENTE por defecto (son opuestos).

37KQL: crear tabla (.create table + dynamic)

.create table NombreTabla (
    columna1:datetime,
    columna2:string,
    columna3:dynamic
)

🎯 Deducir el tipo mirando la muestra de datos: fecha → datetime · texto → string · JSON/objeto/array → dynamic ⭐ · entero → int/long · decimal → real · true/false → bool.

38PySpark: when / split / dropDuplicates

🎯 Detalles que caen en preguntas de Sí/No:

1. when((A) | (B), valor) → el | es OR: cubre A O B. Dos condiciones con | → reemplaza ambos casos (ej. null Y empty: isNull() | (col=="")).
2. split(col, "@").getItem(N) → índices base 0: getItem(0) = antes del separador (primer trozo); getItem(1) = después del separador (segundo trozo). ⚠️ Si el statement dice "before" pero el código usa item(1) (after) → falso.
3. dropDuplicates(["columna"]) → dedup por esa columna exacta. Si dice "por año" pero el código pone ["OrderDate"] (fecha completa) → no coincide → falso.

39Parámetros de pipeline: @ vs @{}

🎯 "return as int / preserve type" → @ sin llaves (@pipeline().parameters.param1). "Construir un texto con valores dentro" → @{ } con llaves.

40Mantenimiento Delta: OPTIMIZE vs VACUUM

🎯 El par que SIEMPRE confunden (verbos opuestos):

• "consolidate / compact / small files / merge files" → OPTIMIZE (junta).
• "remove old / unreferenced / obsolete files / clean up" → VACUUM (tira).

41V-Order: el trade-off lectura/escritura ⭐

🎯 V-Order optimiza LECTURAS pero añade overhead a las ESCRITURAS. Es un trade-off.

💡 Regla clave — pregúntate qué optimizar: optimizar LEER (queries) → Enable V-Order. Optimizar ESCRIBIR (minimize LOAD time, write-intensive) → Disable V-Order.

42Statistics para optimizar queries

🎯 Las statistics (histogramas, cardinalidad) las usa el query optimizer para elegir el mejor plan. Unas stats desactualizadas (tras crecer la tabla) → planes malos → queries lentas. Actualizarlas → queries rápidas.

💡 "optimize query experience / queries lentas porque los datos crecieron" → Create/update statistics.

43Direct Lake: el tipo de dato de las keys

🎯 En Direct Lake, todo se carga comprimido en memoria. Los strings largos (MD5, SHA256, GUIDs) son enemigos cuando se repiten en millones de filas → hinchan el modelo → exceden los guardrails → fallback a DirectQuery o errores en los visuals. Los enteros (INT/BIGINT) son amigos (comprimen genial).

💡 Patrón: "surrogate keys con hash" + "Direct Lake" + "performance/errors" + "millones de filas" → sospecha del tipo de dato de las keys → cámbialas a entero.

44Optimización KQL: filtrar temprano ⭐

🎯 LA optimización nº1: FILTRAR LO ANTES POSIBLE. Mover el filter/where antes de las operaciones costosas (join, summarize) reduce las filas que se procesan → mucho más rápido.

💡 Truco: ¿el cambio REDUCE datos antes de la parte cara? → optimiza. ¿Añade trabajo o cambia resultados? → No.

45Herramientas de monitorización (cuál es cuál)

🎯 Trucos: "¿Qué pasó en una ejecución concreta?" (estado, duración, versión) → Monitor hub. "¿Cuánta capacidad se gastó?" → Capacity Metrics app. "Auditoría a nivel organización" → Admin monitoring workspace.

46Monitorización de queries (DMVs): histórico vs tiempo real ⭐

🎯 Reglas:

• sys.dm_exec_* = TIEMPO REAL (lo que pasa ahora; desaparece al acabar).
• queryinsights.* = HISTÓRICO (persistido, últimos 30 días).
• "last 60 minutes / durante las últimas X" (pasado) → queryinsights.
• "currently running / en vivo" → dm_exec_requests.
• "names of users" → dm_exec_sessions (tiene login_name).

47Refrescar semantic model: execute vs monitor

🎯 La palabra clave manda:

• "dynamically EXECUTE" (+ monitor) un refresh → semantic link (sempy) en un notebook. Es el único que lanza el refresh Y lo monitoriza programáticamente.
• "MONITOR" (solo ver) el histórico → Monitoring hub, DMVs o el refresh history del modelo.

48Debug de pipeline: input vs output JSON ⭐

Cuando una actividad falla, en el Monitoring hub → run fallido → tienes dos JSONs:

🎯 "which SQL query was executed" → INPUT JSON (la query es un parámetro de entrada, especialmente con un source dinámico).

49Exhibit de pipeline: Inactive y flechas

🎯 El estado "Inactive" de una actividad significa que está DESACTIVADA (comentada). Una actividad inactiva nunca se ejecuta: se salta (skipped) en cada run, sin importar las dependencias.

Flechas de dependencia (cómo leer el exhibit):

• Sin flecha entre cajas → paralelo (simultáneas).
• Con flecha → secuencia. Colores: 🟢 verde = on success, 🔴 rojo = on failure, 🔵 azul = on completion, ⚫ gris = on skip.

50Monitorización Spark: History Server vs run series

🎯 Diferencia clave: el run series compara VARIAS ejecuciones (cada barra = un run), mostrando la tendencia entre runs. El Spark History Server muestra los jobs/stages DENTRO de UN run, en timeline.

51Meta-estrategia: cómo pensar como el examinador

Patrones de comportamiento de las preguntas que conviene interiorizar:

• 🔑 "Least privilege" = descarta el rol o permiso más poderoso. Elige el mínimo que cumpla la tarea.
• 🔑 Frases "de relleno" ("you already assigned...", "Inactive") = NO son relleno. Resuelven medio requisito y cambian la respuesta. Léelas dos veces.
• 🔑 Case studies: la respuesta sale de cazar la frase exacta del requisito (busca el verbo clave: transform vs copy vs cleanse), no de tu preferencia de herramienta.
• 🔑 "Qué artefacto uso": tacha cada requisito uno a uno sobre cada opción. Gana el que no falla ninguno, no el de la palabra que más suena.
• 🔑 Una sola palabra (ej. "KQL", "LOAD time", "last 60 minutes") puede desviarte o ser la clave. Léela con atención.
• 🔑 "always" en preguntas de Sí/No → casi siempre No (si el código tiene ramas if/try).
• 🔑 Series de preguntas que repiten el escenario → cambian UN detalle cada vez; lee cada una fresca.
• 🔑 Optimización de queries → filtrar temprano es casi siempre la respuesta.
• 🔑 Aprende algoritmos, no respuestas: las preguntas de caché, permisos y DMVs tienen variantes con los números cambiados. Domina el procedimiento.
• 🔑 El examen abstrae la implementación: "migrate table" es un paso en el examen; en la vida real es un proyecto entero.

52Cuando la doc gana al dump

Los volcados de preguntas de examen ("dumps") son útiles para practicar el formato y los temas, pero tienen errores: respuestas mal marcadas, opciones que faltan o contenido desactualizado (Fabric cambia rápido). Cuando una respuesta marcada choca con la documentación oficial de Microsoft Learn, gana la documentación.

Casos donde conviene desconfiar del dump y verificar en la doc:

🎯 Meta-regla: aprende el procedimiento y el razonamiento, no la respuesta memorizada. Ante una opción "que suena bien pero no cuadra con la doc", confía en tu razonamiento + la documentación oficial.