Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Associate
Proyecto Associate y simulacro de 45 preguntas
Integra ingesta, transformación, gobierno, Jobs y CI/CD en una solución defendible.
- Entregar un pipeline Associate completo
- Justificar decisiones de arquitectura
- Medir preparación con un simulacro original
01Modelo mentalBrief y criterios de aceptación
El proyecto Associate comienza por criterios verificables, no por herramientas.
+
Brief y criterios de aceptación
El proyecto Associate comienza por criterios verificables, no por herramientas.
- Objetivo
- El proyecto Associate comienza por criterios verificables, no por herramientas.
- Duración estimada
- 30 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- m11
Define fuentes, SLA, consumidores, seguridad y aceptación.
Traza cada requisito a componente, prueba y evidencia.
Modelo mental
Un proyecto de certificación comienza traduciendo una historia ambigua en criterios observables. Fuente, volumen, frecuencia, mutabilidad, SLA, consumidores, seguridad, coste y recuperación definen el problema; una lista de servicios no. Cada requisito se convierte en métrica, umbral, prueba y evidencia con owner. Freshness de treinta minutos necesita un timestamp de inicio y fin; cero duplicados necesita grain y clave; acceso restringido necesita identities y prueba negativa. Los criterios también fijan alcance y alternativas descartadas. Esta disciplina prepara para el examen Associate porque las preguntas situacionales incluyen restricciones cuya combinación elimina opciones plausibles. Elegir antes de explicitar criterios favorece respuestas por palabra clave y arquitecturas imposibles de validar.
Condición medible con umbral y procedimiento de comprobación que determina si una entrega satisface un requisito concreto.
Transforma objetivos vagos en evidencia reproducible y permite comparar decisiones arquitectónicas bajo las mismas obligaciones.Relación explícita entre requisito, componente, configuración, prueba, resultado y owner responsable de aceptar la evidencia.
Evita funciones sin propósito y revela requisitos importantes que todavía no tienen una comprobación implementada.Afirmación no verificada que se utiliza temporalmente para diseñar y cuya falsedad cambiaría la decisión o su validez.
Hacerlo visible permite validarlo antes de que se convierta en una dependencia oculta de producción.acceptance:
freshness_minutes: 30
duplicate_order_ids: 0
valid_amount_ratio: 0.995Añade owner y respuesta al incumplimiento.
Puntos clave
- Criterios medibles
- Alcance explícito
- Trazabilidad
Evita
- Empezar por cluster
- SLA sin métrica
Recuerdo activo
¿Qué convierte un objetivo en aceptación?
Borrador privado · solo en este navegador02ImplementaciónArquitectura y seguridad inicial
La arquitectura integra ingesta, transformación, gobierno y consumo con mínimo privilegio.
+
Arquitectura y seguridad inicial
La arquitectura integra ingesta, transformación, gobierno y consumo con mínimo privilegio.
- Objetivo
- La arquitectura integra ingesta, transformación, gobierno y consumo con mínimo privilegio.
- Duración estimada
- 30 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- m11
Usa UC como frontera, Delta como tabla y compute adecuado por workload.
Aísla dev/prod y diseña replay antes de automatizar.
Modelo mental
La arquitectura Associate debe formar una cadena de garantías: una entrada durable y gobernada permite replay; Delta aporta commits de tabla; Silver añade contrato; Gold atiende consumidores; Unity Catalog aplica identidad y permisos; compute y Jobs ejecutan y observan cada frontera. Ningún componente resuelve todo. El diagrama debe mostrar datos, control, identidades y recuperación, no solo cajas. Dev y prod comparten código pero separan catálogos, estado y principals. La elección entre COPY INTO, Auto Loader o conector nace de la fuente; entre SQL warehouse y Jobs compute, del consumidor y workload. Una arquitectura defendible explica también dos alternativas descartadas y el cambio de requisito que las haría preferibles.
Secuencia de fronteras donde cada capa añade una propiedad verificable sin asumir que otra herramienta la proporcionará implícitamente.
Permite localizar fallos y demostrar que gobierno, calidad, recuperación y servicio están cubiertos de extremo a extremo.Punto en el que un principal concreto recibe únicamente los privilegios necesarios para leer o publicar un objeto gobernado.
Evita credenciales compartidas y limita el impacto de un Job comprometido o configurado incorrectamente.Opción plausible no elegida acompañada de la restricción, coste o capacidad que justificó excluirla en ese contexto.
Demuestra razonamiento comparativo y permite revisar la arquitectura si cambian requisitos o capacidades oficiales.flow: [volume, bronze_delta, silver_delta, gold_mv, sql_warehouse]
orchestrator: lakeflow_jobsAñade identidades y checkpoints.
Puntos clave
- UC gobierna
- Delta persiste
- Compute se elige
Evita
- Credenciales en código
- Una copia por equipo
Recuerdo activo
¿Dónde aplicas permisos de tabla?
Borrador privado · solo en este navegador03OperaciónConstrucción del pipeline
La implementación debe ser idempotente, parametrizada y observable.
+
Construcción del pipeline
La implementación debe ser idempotente, parametrizada y observable.
- Objetivo
- La implementación debe ser idempotente, parametrizada y observable.
- Duración estimada
- 30 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- m11
COPY INTO/Auto Loader ingiere, DataFrames conforman y Jobs coordina.
Cada escritura se prueba con segundo run y datos inválidos.
Modelo mental
Una implementación confiable es idempotente, parametrizada, observable y comprobable. Idempotente significa que la misma entrada repetida converge al mismo estado lógico; parametrizada significa que fecha, catálogo y modo se declaran sin editar código; observable significa que cada run publica métricas y contexto; comprobable significa que tests y reconciliaciones detectan desviaciones. COPY INTO o Auto Loader resuelven progreso de archivos, no duplicados de negocio. DataFrames expresan transformación; Delta MERGE o reemplazo acotado define escrituras; Jobs coordina. La prueba decisiva ejecuta dos veces, introduce un fallo después de un efecto parcial y demuestra que la recuperación no cambia conteos ni métricas correctas.
Propiedad por la que reejecutar una entrada identificable conserva una única representación correcta de cada entidad o evento.
Completa las garantías técnicas de archivos y commits con la semántica necesaria para retries productivos seguros.Comprobación que relaciona unidades de origen, filas válidas, rechazos, cambios aplicados y resultados publicados durante un run.
Detecta pérdidas y multiplicaciones que podrían pasar inadvertidas aunque todas las tareas terminen con estado SUCCESS.Experimento controlado que interrumpe una ejecución en un punto relevante y verifica reanudación y estado final.
Demuestra recuperación real en vez de asumirla a partir de una configuración de retries no ejercitada.SELECT count(*) rows, count(DISTINCT order_id) ids
FROM main.silver.orders;Si grain no es pedido, usa la clave correcta.
Puntos clave
- Replay
- Parámetros
- Métricas
Evita
- Validar solo happy path
- Append no idempotente
Recuerdo activo
¿Cómo demuestras idempotencia?
Borrador privado · solo en este navegador04DiagnósticoPruebas, operación y documentación
Operación combina run history, Spark UI, alertas y runbook.
+
Pruebas, operación y documentación
Operación combina run history, Spark UI, alertas y runbook.
- Objetivo
- Operación combina run history, Spark UI, alertas y runbook.
- Duración estimada
- 30 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- m11
Run history localiza tarea; Spark UI diagnostica ejecución.
Runbook define owner, reparación y escalado.
Modelo mental
Operar exige distinguir estado del workflow, ejecución del motor y salud del producto de datos. Run history muestra qué tarea, intento y parámetro falló; Spark UI y Query Profile explican planes, stages y recursos; métricas de calidad y freshness muestran si una ejecución técnicamente exitosa sirvió datos válidos. Las alertas dirigen a un owner con impacto y acción. El runbook decide pausar, reparar, hacer rollback o backfill según evidencia. Repair run evita repetir tareas correctas, pero solo cuando las salidas son durables y compatibles. Una operación madura define SLI, umbral y respuesta antes del incidente, y conserva postmortem para eliminar la causa, no solo restaurar el color verde.
Indicador cuantitativo del servicio, como freshness, tasa de éxito, duración o ratio de calidad observado en producción.
Proporciona la señal objetiva que se compara con el objetivo y activa una respuesta operacional proporcional.Proceso inicial de acotar impacto, fase, evidencia y urgencia antes de modificar sistemas o relanzar trabajos.
Evita cambios simultáneos y dirige al equipo hacia la superficie de diagnóstico que contiene la causa probable.Conjunto verificable de condiciones de datos, servicio y prevención que permite declarar resuelto un incidente.
Impide cerrar únicamente porque una tarea aparece verde mientras consumidores o controles siguen degradados.SELECT * FROM system.lakeflow.job_run_timeline
ORDER BY period_start_time DESC LIMIT 20;Filtra workspace y job.
Puntos clave
- Señal correcta
- Repair selectivo
- Owner
Evita
- Reejecutar todo
- Alerta sin acción
Recuerdo activo
¿Dónde investigas skew?
Borrador privado · solo en este navegador05Decisión de diseñoRetrospectiva y simulacro Associate
La preparación Associate se mide por dominio y capacidad de decidir en escenarios nuevos.
+
Retrospectiva y simulacro Associate
La preparación Associate se mide por dominio y capacidad de decidir en escenarios nuevos.
- Objetivo
- La preparación Associate se mide por dominio y capacidad de decidir en escenarios nuevos.
- Duración estimada
- 30 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- m11
El blueprint vigente cubre plataforma, ingesta, transformación, Jobs, CI/CD, diagnóstico y gobierno.
Un simulacro útil explica distractores y dirige repaso; no memoriza dumps.
Modelo mental
Prepararse para Associate significa construir modelos mentales que permitan decidir en escenarios nuevos, no memorizar menús o dumps. El blueprint vigente para exámenes desde el 4 de mayo de 2026 organiza capacidades de plataforma, desarrollo, ingesta, transformación, Jobs, CI/CD, troubleshooting y gobierno. Cada error de simulacro se clasifica por dominio y por causa: desconocimiento, lectura apresurada, restricción ignorada o distractor absoluto. La revisión útil explica por qué la opción correcta satisface todas las condiciones y por qué cada alternativa falla al menos una. El 80% de esta academia es un indicador interno de preparación, no una nota oficial publicada. La práctica debe incluir código, operación y decisiones, no solo preguntas.
Guía oficial fechada que enumera dominios y objetivos evaluables para una versión concreta del examen de certificación.
Define el alcance real de preparación y debe revisarse si la fecha del examen cruza una actualización publicada.Opción plausible que viola una restricción, confunde capas o aplica una función correcta al problema equivocado.
Analizarlo desarrolla discriminación conceptual y evita depender de reconocer literalmente una respuesta vista anteriormente.Capacidad de aplicar un principio comprendido a un escenario nuevo con detalles, nombres o restricciones diferentes.
Es una señal más robusta de preparación que memorizar preguntas, letras o secuencias de interfaz.domains:
ingestion: 0.82
transformation: 0.76
jobs: 0.88
governance: 0.71Prioriza gobierno sin abandonar práctica integrada.
Puntos clave
- Blueprint manda
- Repaso por dominio
- Sin dumps
Evita
- Memorizar respuestas
- Ignorar dominio débil
Recuerdo activo