Temario Flashcards

Question

What does “scalability” mean in the context of cloud computing? a) The ability to measure server utilization. b) The ability to increase or decrease computing resources according to the needs of running processes. c) A mechanism to increase the security of the networks used in the platform, d) A tool for debugging container-based applications.

Answer 1

B The ability to increase or decrease computing resources according to the needs of running processes.

Answer 2

D Por qué es la buena: El objetivo principal de PaaS (Platform as a Service) es que los desarrolladores se olviden de los servidores. Abstracción: Tú traes tu código (la aplicación) y el proveedor de nube se encarga de todo lo que hay debajo: el sistema operativo, los parches de seguridad, el balanceo de carga, el escalado y el hardware. El trato: Tú gestionas la app + datos; ellos gestionan la plataforma + infraestructura. Esto "abstrae" (oculta) la complejidad del hierro para que te centres en programar. Por qué las otras son las malas A. ... se refiere a servicios enfocados en la virtualización de hardware. Por qué falla: Esto es la definición de manual de IaaS (Infrastructure as a Service). El detalle: En IaaS (como Compute Engine), tú alquilas máquinas virtuales y tienes control total sobre el hardware virtualizado, el sistema operativo, etc. El foco está en la "infraestructura". B. ... se refiere a servicios que integran las aplicaciones con la capa de infraestructura. Por qué falla: Esta frase es un poco confusa, pero sugiere que tienes que "pegar" o gestionar la unión entre tu app y la infraestructura manualmente. La realidad: PaaS hace justo lo contrario: desacopla tu preocupación. No quieres integrar tu app con la infraestructura; quieres que la infraestructura sea invisible. C. ... no es parte del Cloud Computing. Por qué falla: Falso. PaaS es uno de los tres pilares fundamentales del Cloud Computing, junto con IaaS y SaaS. Decir esto es como decir que el volante no es parte de un coche.

Answer 3

A It provides a programming model for building portable data pipelines

Answer 4

C IaaS (infrastructure) - PaaS (Platform) - SaaS (Software).

Answer 5

B Cloud Spanner.

Answer 6

B Building SQL-based data transformation pipelines in BigQuery.

Answer 7

B ✅ Explicación de la Respuesta Correcta B. BigQuery debe consultar el conjunto de datos cada vez para obtener datos, ya que no se encuentran en el almacenamiento nativo de BigQuery. Esta es la explicación más precisa y completa. Tablas Nativas vs. Externas: En una tabla nativa 📦, los datos se cargan y se almacenan físicamente dentro de BigQuery. BigQuery gestiona este almacenamiento y puede acceder a él de forma instantánea para funciones como la vista previa. En una tabla externa 🔗, los datos residen fuera de BigQuery (en este caso, en una Google Sheet). La tabla en BigQuery es solo un "puntero" o un conjunto de metadatos que le dice a BigQuery cómo leer los datos de la fuente externa cuando se le pide. ¿Por qué no funciona la "Vista Previa"?: La función de Vista previa está diseñada para mostrar rápidamente una pequeña muestra de los datos de una tabla nativa, ya que están inmediatamente disponibles. Como los datos de la tabla externa no están en BigQuery, no hay nada que "previsualizar". Para ver los datos, BigQuery debe ejecutar activamente una consulta en tiempo real contra la fuente externa (la Google Sheet), lo que va más allá de una simple vista previa. ❌ Por qué las otras opciones son incorrectas A. Los datos no se encuentran en BigQuery, sino en Hojas de cálculo de Google: Si bien esta afirmación es cierta, es una razón incompleta. No explica por qué el hecho de que los datos sean externos impide la vista previa. La opción B da el siguiente paso lógico y explica la consecuencia: se necesita una consulta activa. C. Los datos nunca se pueden almacenar en caché y mostrar en BigQuery porque son una fuente de datos externa: Esta afirmación es demasiado categórica y, por lo tanto, incorrecta. BigQuery sí puede almacenar en caché los resultados de una consulta a una fuente externa. Si ejecutas la misma consulta SELECT dos veces sobre la tabla externa, la segunda vez es muy probable que se sirva desde la caché de resultados de BigQuery, siempre que los datos de origen no hayan cambiado. El problema es específico de la función "Vista Previa", no del almacenamiento en caché en general. D. Todas las anteriores: Dado que A es una respuesta incompleta y C es incorrecta, esta opción no puede ser la correcta.

Answer 8

B The sources describe the third-wave cloud as Google's container-based architecture where services automatically provision and configure the infrastructure. This third-wave cloud is made available to Google customers today. Options A and D describe characteristics of earlier waves or virtualization, where enterprises still maintained infrastructure. Option C describes colocation, the "first wave"

Answer 9

C The sources explicitly state that Compute Engine is an example of a Google Cloud IaaS service. App Engine is given as an example of PaaS. Gmail is classified as SaaS. Cloud Run is mentioned as a Serverless technology

Answer 10

C Por qué la C es la respuesta correcta Esta opción describe una medida de seguridad que se aplica directamente al usuario en el momento en que intenta demostrar quién es (es decir, a nivel de su identidad). El concepto clave aquí es el inicio de sesión adaptativo o basado en el riesgo. En lugar de simplemente pedir un usuario y una contraseña, el sistema de Google analiza múltiples factores de riesgo en tiempo real, como: ¿Estás iniciando sesión desde un dispositivo desconocido? ¿Te encuentras en una ubicación geográfica inusual? ¿La hora del día es extraña para tu patrón de uso? ¿La red desde la que te conectas es sospechosa? Si el sistema detecta un riesgo, "desafía" al usuario pidiéndole una prueba adicional de su identidad. Esto es, en esencia, la autenticación multifactor (MFA) o la verificación en dos pasos (2SV), como recibir un código en tu teléfono o confirmar el inicio de sesión desde otro dispositivo. 📲 Como esta medida se centra en verificar si la persona que inicia sesión es realmente quien dice ser, opera directamente en el nivel de identidad del usuario. Por qué las otras respuestas son incorrectas Las otras opciones son medidas de seguridad válidas y muy importantes que Google implementa, pero operan en diferentes capas de su infraestructura, no en la del usuario. A) Encriptar todo el tráfico RPC de la infraestructura entre los centros de datos: Incorrecto. Esto es una medida de seguridad a nivel de red 🌐. Se asegura de que si alguien intercepta los datos mientras viajan entre los servidores de Google, no pueda leerlos. Protege los datos "en tránsito", pero no tiene nada que ver con verificar la identidad de un usuario final. B) Diseñar placas de servidor y equipos de red personalizados: Incorrecto. Esto es una medida de seguridad a nivel de hardware ⚙️. Google construye su propio hardware para asegurarse de que no haya vulnerabilidades o "puertas traseras" instaladas por terceros. Protege la base física de la infraestructura, no la identidad del usuario que accede a los servicios. D) Encriptar datos en la capa de servicios de almacenamiento utilizando claves gestionadas centralmente: Incorrecto. Esto es una medida de seguridad a nivel de almacenamiento 💾. Se refiere a que los datos, una vez guardados en los discos duros de Google, están cifrados (lo que se conoce como encriptación "en reposo" o at-rest). Si alguien robara físicamente un disco duro, no podría leer la información. De nuevo, esto protege los datos guardados, no verifica la identidad de quien intenta acceder a ellos.

Answer 11

C ✅ Opción C: Gobernar el número máximo de recursos específicos que puede tener un proyecto. Esta afirmación es correcta. El propósito principal de las "cuotas de asignación" (Allocation quotas) en Google Cloud es establecer un límite en la cantidad de un tipo de recurso que puedes crear dentro de un proyecto. Piensa en ello como un límite de seguridad. Por ejemplo, tu proyecto puede tener una cuota que te permite crear un máximo de 24 CPUs, 5 redes VPC o 10 balanceadores de carga. Estos límites existen por dos razones principales: Proteger al usuario: Evitan que accidentalmente crees una cantidad masiva de recursos y generes una factura inesperadamente alta. защита Proteger a Google: Ayudan a Google a gestionar la capacidad de sus centros de datos y a garantizar que los recursos estén disponibles de manera justa para todos los clientes. Si necesitas más recursos de los que permite tu cuota, puedes solicitar un aumento. ❌ Opciones incorrectas A. Limitar la frecuencia de las llamadas a la API en un período de tiempo determinado. Esto es falso. Este tipo de límite se conoce como cuota de tasa (Rate Quota). Su función es prevenir el abuso o el uso excesivo de una API, limitando cuántas veces puedes llamarla por segundo o por minuto. Es diferente a la cuota de asignación, que se refiere a la cantidad total de recursos. B. Establecer un límite de gasto financiero para un proyecto o cuenta de facturación. Esto es falso. La herramienta para controlar el gasto financiero se llama presupuestos y alertas (Budgets and alerts). Te permite fijar un presupuesto y recibir notificaciones cuando tu gasto se acerca o supera ese límite, pero no es la función de una cuota de recursos. Las cuotas controlan la cantidad de recursos, no su coste. D. Proporcionar automáticamente descuentos por el uso continuado de los recursos. Esto es falso. Esto describe una característica de precios de Google Cloud llamada Descuentos por uso continuado (Sustained Use Discounts - SUDs) o Descuentos por compromiso de uso (Committed Use Discounts - CUDs). Son descuentos que se aplican a tu factura cuando usas ciertos recursos (como máquinas virtuales) durante un tiempo prolongado. No tienen ninguna relación con las cuotas.

Answer 12

C The sources state that Google publishes key elements using open source licenses to create ecosystems that provide customers with options other than Google, including the ability to run applications elsewhere. They also mention providing interoperability at multiple layers, citing Kubernetes and GKE as examples that allow mixing microservices across different clouds. Options A, B, and D describe proprietary or internal aspects of Google's infrastructure, not actions taken to provide customer flexibility or avoid vendor lock-in through openness.

Answer 13

B Y D Cloud computing is defined by traits like on-demand self-service and elasticity, allowing users to quickly scale and provision resources as needed. El NIST define 5 características esenciales para que un servicio sea considerado "cloud": On-demand self-service (Autoservicio bajo demanda): Un consumidor puede obtener capacidades de computación (como tiempo de servidor o almacenamiento en red) de forma automática, sin necesidad de interacción humana con el proveedor del servicio. Broad network access (Amplio acceso a la red): Las capacidades están disponibles a través de la red y se accede a ellas mediante mecanismos estándar (ej. navegadores web, APIs en teléfonos, portátiles, etc.). Resource pooling (Agrupación de recursos): Los recursos del proveedor (cómputo, almacenamiento, red) se agrupan para servir a múltiples clientes (modelo multi-tenant). Los recursos se asignan y reasignan dinámicamente según la demanda. Rapid elasticity (Rápida elasticidad): Las capacidades se pueden provisionar y liberar de forma elástica, en algunos casos automáticamente, para escalar rápidamente hacia arriba o hacia abajo según la demanda. Para el cliente, los recursos disponibles parecen ser ilimitados. Measured service (Servicio medido): Los sistemas en la nube controlan y optimizan automáticamente el uso de los recursos. El uso se puede monitorear, controlar y reportar, proporcionando transparencia tanto para el proveedor como para el consumidor. Esto es lo que permite el modelo de "pago por uso". Ahora, veamos las opciones: Respuesta Correcta: D. On-demand self-service (Autoservicio bajo demanda) Por qué es correcta: Esta opción coincide directamente con la primera característica esencial de la definición del NIST. Es la idea fundamental de que puedes entrar a una consola web (como la de AWS, Azure o Google Cloud) o usar una API y "pedir" un servidor, una base de datos o almacenamiento, y tenerlo disponible en minutos sin hablar con un vendedor o un técnico. Respuesta Correcta: B. Elasticity of resources (Elasticidad de los recursos) Por qué es correcta: Esta opción es una forma de describir la característica de "Rápida elasticidad" del NIST. La elasticidad es la capacidad de la nube para adaptar los recursos a las necesidades del momento. Por ejemplo, si tu sitio web de comercio electrónico tiene un pico de tráfico por el Black Friday, la nube puede añadir servidores automáticamente para soportar la carga y luego quitarlos cuando el tráfico vuelva a la normalidad. Esta capacidad de "estirarse" y "encogerse" es fundamental. Por qué las otras respuestas son incorrectas: A. Fixed pricing for long-term contracts (Precios fijos para contratos a largo plazo) Por qué es incorrecta: Esto describe un modelo de negocio o una opción de compra, no una característica técnica fundamental de la nube. De hecho, una de las características clave del cloud ("Servicio medido") es lo que permite el modelo de pago por uso (pay-as-you-go), que es lo opuesto a un precio fijo. Aunque los proveedores de la nube sí ofrecen descuentos por contratos a largo plazo (como las Instancias Reservadas de AWS), esta no es una característica definitoria de la tecnología en sí. C. Access to resources via dedicated circuits (Acceso a recursos mediante circuitos dedicados) Por qué es incorrecta: Esto contradice directamente la característica de "Amplio acceso a la red" (Broad network access). El principio de la nube es que los recursos son accesibles a través de redes estándar como internet. Un "circuito dedicado" (como AWS Direct Connect o Azure ExpressRoute) es una conexión privada, costosa y especializada que algunas grandes empresas usan por seguridad o rendimiento, pero no es la forma estándar ni una característica esencial de la nube. La nube está diseñada para ser accesible desde cualquier lugar con una conexión a internet. Resumen Clave: Las respuestas B y D son correctas porque la elasticidad (escalar según la demanda) y el autoservicio bajo demanda (obtener recursos por ti mismo) son dos de las cinco características técnicas que definen la computación en la nube según el NIST. Las respuestas A y C son incorrectas porque describen, respectivamente, un modelo de precios y un método de conexión opcional y especializado, no características fundamentales de la tecnología cloud.

Answer 14

B Using multiple zones in a region provides fault tolerance, ensuring that a failure in one zone doesn't impact services running in another.

Answer 15

B PaaS (e.g., App Engine) handles the underlying infrastructure so developers can focus on their code and application logic.

Answer 16

B y C Google Cloud pursues sustainability through practices like ISO 14001 certification and innovations such as seawater cooling in the Hamina, Finland data center.

Answer 17

C Por qué la opción C es la correcta Google Cloud divide sus cuotas en dos categorías principales para gestionar el consumo de recursos: Allocation quotas (Cuotas de asignación): Qué son: Limitan la cantidad total de un recurso que puedes tener en tu proyecto, independientemente de si lo estás usando activamente. Propósito: Sirven para gestionar el inventario de recursos estáticos o aprovisionados. Ejemplo: Tener una cuota que te permite crear un máximo de 50 máquinas virtuales (VMs) en una región específica, o un máximo de 10 direcciones IP estáticas. Rate quotas (Cuotas de tasa): Qué son: Limitan la velocidad a la que puedes consumir un recurso o hacer solicitudes, generalmente medido en un intervalo de tiempo (como por minuto o por día). Propósito: Sirven para prevenir picos de uso abusivos o repentinos que puedan degradar el servicio para otros usuarios. Ejemplo: Permitir un máximo de 600 solicitudes de API por minuto a un servicio específico, o un límite de cuántos discos puedes crear por minuto. Por qué las otras opciones son incorrectas A. Project-level and Organization-level quotas (Cuotas a nivel de proyecto y organización): Estos son niveles de la jerarquía donde se aplican las cuotas, pero no son los tipos de cuotas. Una cuota de asignación (tipo C) puede aplicarse a nivel de proyecto (nivel A). B. Billing and Performance quotas (Cuotas de facturación y rendimiento): No existe una categoría formal llamada "cuota de facturación" (la facturación se gestiona con presupuestos y alertas, no con cuotas de este tipo). Y aunque las cuotas de tasa afectan el rendimiento, "cuotas de rendimiento" no es el término técnico que usa Google. D. User quotas and Network quotas (Cuotas de usuario y de red): Estos son ejemplos demasiado específicos. Las "cuotas de red" (como las IPs) son un subtipo de "cuotas de asignación". Las "cuotas de usuario" (como solicitudes de API por usuario) son un subtipo de "cuotas de tasa". Por lo tanto, no representan las dos categorías principales.

Answer 18

A, C, D Cloud computing provides on-demand and self-service resources, elastic scalability, and a pay-as-you-go model. Access is available over the internet, not limited to corporate networks

Answer 19

B Compute Engine is GCP’s IaaS product, offering raw compute, storage, and network capabilities. App Engine is PaaS, Cloud Run is serverless, and BigQuery is a managed analytics service

Answer 20

B IaaS delivers raw compute, storage, and networking resources, while PaaS manages both hardware and software, allowing developers to focus on application logic

Answer 21

A A region is an independent geographic area composed of multiple zones, which are isolated locations within the region where resources are deployed.

Answer 22

B Managed services allow organizations to concentrate on business objectives, as Google handles the underlying infrastructure, improving speed and reliability of product delivery.

Answer 23

D Page 6 specifically mentions that "First, customers get computing resources that are on-demand and self-service. Through a web interface, users get the processing power, storage, and network they need with no need for human intervention." This directly aligns with on-demand self-service.

Answer 24

B Page 19 describes PaaS as delivering and managing all hardware and software, allowing developers to bind code to libraries that provide access to infrastructure needs, thus focusing more on application logic. App Engine is given as an example.

Answer 25

B Page 28 and 29 explain that Regions are independent geographic areas composed of Zones. Deploying resources across multiple zones within a region (e.g., europe-west2-a, europe-west2-b) enhances resource redundancy and fault tolerance for failures within that region.

Answer 26

C La respuesta correcta es la C). Esta es la respuesta correcta porque se refiere directamente a la seguridad integrada en los componentes físicos que forman la infraestructura de Google. ¿Qué significa? Google no compra servidores o componentes de red genéricos. Diseña y fabrica su propio hardware, incluyendo las placas base y chips de seguridad especializados como el chip Titan. Arranque Seguro (Secure Boot): Este proceso, controlado por el chip Titan, verifica criptográficamente que cada componente del software que se carga al encender un servidor (desde el firmware hasta el sistema operativo) es de confianza y no ha sido manipulado. ¿Por qué es la capa de "Hardware"? Porque la seguridad se origina en el propio silicio. Es la capa de defensa más fundamental, asegurando que la plataforma sobre la que se ejecuta todo lo demás es íntegra y segura desde el primer momento. ¿Por qué las otras opciones son incorrectas? A) Cifrado de la comunicación RPC entre servicios dentro de los centros de datos: Esto es parte de la capa de seguridad de la red y de los servicios. Aunque es una medida de seguridad crucial que se ejecuta sobre la infraestructura, no es una característica del hardware en sí, sino una protección para los datos en tránsito entre diferentes servicios. B) Uso de llaves U2F para el acceso de los empleados: Esto corresponde a la capa de seguridad operativa y del personal. Se centra en la gestión de identidades y accesos para asegurar que solo el personal autorizado pueda administrar la infraestructura. Es una política sobre las personas y sus credenciales, no sobre el hardware. D) Google Front End (GFE) terminando conexiones TLS y proporcionando protección DoS: El GFE es un servicio que actúa en el borde de la red de Google. Es una capa de software distribuida globalmente que protege contra ataques de denegación de servicio (DoS) y gestiona el tráfico entrante. Aunque se ejecuta sobre el hardware de Google, es una función de la infraestructura de servicios, no de la capa de hardware base.

Answer 27

D Page 59 explains that "Compute Engine offers automatically applied sustained-use discounts, which are automatic discounts that you get for running a virtual-machine instance for a significant portion of the billing month." This happens automatically without explicit commitment for the specific instance.

Answer 28

B Google Compute Engine is an IaaS offering that provides virtual machines, allowing users to manage their own infrastructure. Google App Engine is PaaS, BigQuery is a data warehouse service, and Google Workspace is SaaS.

Answer 29

B Zones are distinct locations within a region, designed to provide isolation and redundancy. They are used to deploy resources like virtual machines and ensure high availability.

Answer 30

B Google Cloud provides encryption at rest for data storage, using hardware encryption in drives and SSDs, which is a fundamental security measure for protecting data.

Answer 31

B Google Cloud offers per-second billing for services like Compute Engine, which means users are charged only for the seconds they use, providing cost efficiency.

Answer 32

C Cloud computing offers a pay-as-you-go model, allowing users to pay only for the resources they use, which is more cost-effective than traditional on-premises infrastructure that often requires significant upfront investment.

Answer 33

D The "who" part of an IAM policy, also called a "principal," can be a Google account, a Google group, a service account, or a Cloud Identity domain.

Answer 34

C The sources state that project names are user-created, they don’t have to be unique, and they can be changed at any time, making them mutable. Project IDs are globally unique and immutable after creation. Project numbers are assigned by Google Cloud, immutable, and used internally

Answer 35

C Los Roles Básicos (Basic Roles) son los roles originales de Google Cloud y se caracterizan por ser muy amplios y potentes. Hay tres roles básicos: Propietario (Owner): Control total sobre todos los recursos, la facturación y los permisos. Editor (Editor): Puede crear, modificar y eliminar la mayoría de los recursos. Lector (Viewer): Permisos de solo lectura para la mayoría de los recursos. La clave es que estos roles no son específicos de un servicio. Si asignas el rol de Editor a un usuario a nivel de proyecto, esa persona puede editar máquinas virtuales de Compute Engine, tablas de BigQuery, buckets de Cloud Storage, etc. Por eso se describen como "bastante amplios" y que afectan a "todos los recursos de ese proyecto". Son como una brocha gorda para dar permisos. Por qué las otras opciones son incorrectas A. Rol personalizado (Custom role) Esta opción es incorrecta porque los roles personalizados son lo contrario a "amplios". Se crean para seguir el principio de privilegio mínimo, permitiéndote agrupar un conjunto muy específico y limitado de permisos para una tarea concreta. Su objetivo es ser lo más restrictivos posible, no amplios. B. Rol predefinido (Predefined role) Esta opción es incorrecta porque los roles predefinidos, aunque son creados por Google, son mucho más granulares que los roles básicos. Están diseñados para un servicio o un grupo de servicios relacionados. Por ejemplo, el rol roles/compute.instanceAdmin da control total sobre las máquinas virtuales, pero no da ningún permiso sobre Cloud Storage o Cloud SQL. D. Rol de cuenta de servicio (Service account role) Esta opción es incorrecta porque "rol de cuenta de servicio" no es un tipo de rol como los demás. Una cuenta de servicio es una identidad (utilizada por aplicaciones o máquinas virtuales), no un conjunto de permisos. A esta identidad se le puede asignar cualquier tipo de rol (básico, predefinido o personalizado) para que pueda acceder a los recursos que necesite. Es un término usado para confundir, ya que mezcla el concepto de "quién" (la identidad) con "qué puede hacer" (el rol).

Answer 36

D The sources list four ways to interact with Google Cloud: the Google Cloud console (GUI), the Google Cloud SDK and Cloud Shell (command-line tools), the APIs, and the Google Cloud app (mobile). The services offer APIs so that code you write can control them. Cloud Identity manages users and groups, Resource Manager manages projects, and service accounts are identities for non-human users

Answer 37

C Resources (e.g., VMs, storage buckets, BigQuery tables) are the lowest level in the Google Cloud resource hierarchy. They are grouped into projects, which are then grouped into folders and organizations.

Answer 38

A, C, D IAM roles in Google Cloud are categorized into Basic, Predefined, and Custom roles. "Granular" is not an official type.

Answer 39

C The project ID is globally unique and cannot be changed after it is created, though users can choose it during project creation.

Answer 40

D A custom role can be defined to allow only specific actions such as starting and stopping VMs—ideal for a least-privilege access model.

Answer 41

A, B, D Users can interact with Google Cloud via the Console (GUI), SDK & Cloud Shell (CLI tools), and APIs. “Google Cloud Storage App” is not an official method; however, the Google Cloud mobile app is a valid option (not listed here).

Answer 42

D The Google Cloud resource hierarchy consists of four levels: resources (bottom), projects, folders, and the organization node at the top, which encompasses all other elements

Answer 43

A, B, D Projects are separate compartments with unique owners and users, each resource belongs to only one project, and projects are billed separately. Project IDs are immutable after creation

Answer 44

A, B, C ✅ Las respuestas correctas A. To group projects on a per-department basis (Para agrupar proyectos por departamento) Por qué es correcta: Esta es una de las principales razones de ser de las carpetas. Permiten reflejar la estructura de una empresa real. Puedes crear una carpeta para "Ingeniería", otra para "Marketing" y otra para "Finanzas", y colocar los proyectos de cada equipo dentro de su carpeta correspondiente. Esto simplifica enormemente la gestión. B. To assign policies that are inherited by projects and subfolders (Para asignar políticas que son heredadas por proyectos y subcarpetas) Por qué es correcta: Este es el beneficio más potente. Cualquier política de IAM (permisos) o política de la organización (restricciones) que apliques a una carpeta, será heredada automáticamente por todas las subcarpetas y proyectos que contenga. Por ejemplo, si das permisos de "Auditor" a un grupo de usuarios en la carpeta "Finanzas", podrán ver todos los proyectos dentro de esa carpeta sin tener que darles permiso en cada proyecto individualmente. C. To allow delegation of administrative rights (Para permitir la delegación de derechos administrativos) Por qué es correcta: Como consecuencia de la herencia, puedes delegar responsabilidades de forma segura. Puedes nombrar a alguien "Administrador de la Carpeta de Ingeniería" (roles/resourcemanager.folderAdmin). Esa persona tendrá control total sobre esa carpeta y sus proyectos, pero no podrá tocar los proyectos de la carpeta "Finanzas" ni afectar a la organización global. ❌ La respuesta incorrecta D. To define custom IAM roles at the folder level (Para definir roles IAM personalizados a nivel de carpeta) Por qué es incorrecta: Aquí está el detalle clave. Puedes asignar (usar) roles personalizados en una carpeta, pero no puedes definirlos (crearlos) a nivel de carpeta. La creación o definición de roles IAM personalizados solo se puede hacer en dos niveles: A nivel de Organización: El rol puede ser usado en toda la organización (en carpetas y proyectos). A nivel de Proyecto: El rol solo puede ser usado dentro de ese proyecto específico. No existe la opción de "crear un rol personalizado que solo exista para una carpeta". La palabra clave es "definir", que es diferente de "asignar" o "usar".

Answer 45

D Resource role The types of IAM roles are basic, predefined, and custom. "Resource role" is not a recognized IAM role type in Google Cloud

Answer 46

A, B, D A. Para permitir que las aplicaciones en máquinas virtuales accedan a otros servicios Por qué es buena: Este es el caso de uso número 1. Imagina que tienes una aplicación en una VM (Compute Engine) que necesita leer datos de Cloud Storage. En lugar de guardar una contraseña en el código, le asignas una Service Account a la VM. La VM usa esa identidad para "llamar" a la puerta del Storage y entrar. B. Para asignar permisos específicos a una máquina en lugar de a una persona Por qué es buena: Las personas cambian de puesto, se van de vacaciones o dejan la empresa. Las máquinas (servidores, apps) se quedan. Una Service Account es una identidad no humana. Le das permisos a "la aplicación de facturación", no a "Juan el desarrollador". D. Para eliminar la necesidad de intervención humana al autenticar servicios Por qué es buena: Se trata de automatización. Cuando un script corre a las 3 de la mañana para hacer un backup, no hay un humano delante para escribir su usuario y contraseña. Las Service Accounts se autentican mediante claves o tokens automáticos, permitiendo que los procesos funcionen solos (machine-to-machine). Por qué la C es la mala C. Para otorgar acceso automáticamente a cualquier persona en internet Por qué falla: ¡Esto es justo lo contrario! El peligro: Dar acceso a "anyone on the internet" se hace usando identificadores especiales como allUsers o allAuthenticatedUsers en las políticas de IAM (Identity and Access Management). Una Service Account sirve para restringir y controlar el acceso de una aplicación específica, no para abrir las puertas al público.

Answer 47

B As detailed on page 7, the Project Name is chosen by the user, does not need to be unique, and can be changed (is mutable). The Project ID is globally unique and immutable after creation (though can be customized during creation). The Project Number is globally unique, assigned by Google, and immutable. Organization ID is related to the organization node, not a project attribute in this context.

Answer 48

C Page 23 explains that custom roles are ideal for a "least-privilege" model, allowing for a specific set of permissions. While a predefined role like "Compute Instance Admin" might grant more than needed, and basic roles are too broad, a custom role can be tailored to only include compute.instances.start and compute.instances.stop permissions. The Service Account User role is for allowing users to act as a service account, not for direct resource manipulation.

Answer 49

B Page 5 states, "Policies are also inherited downward. This means that if you apply a policy to a folder, it will also apply to all of the projects within that folder." Page 17 reinforces this with "Policy Inheritance." Deny policies (page 18) can override allow policies. Option C is incorrect because inheritance flows down; a more permissive role at a lower level doesn't override a higher-level one in the way described.

Answer 50

C Pages 25-26 specifically describe service accounts for scenarios where a program or VM needs to access other cloud services. The service account acts as the identity for the application, and IAM roles are granted to this service account to define what it can do (e.g., read from Cloud Storage, write to BigQuery). User accounts are for humans, and API keys are generally not recommended for server-to-server authentication within GCP when service accounts are available.

Answer 51

D Page 37 describes Cloud Shell as providing "command-line access to cloud resources directly from a browser." It also states, "With Cloud Shell, the Google Cloud SDK gcloud command and other utilities are always installed, available, up to date, and fully authenticated." The Console is GUI-based (page 35), local SDK requires local installation (page 36), and APIs are for programmatic interaction (page 38).

Answer 52

C The Organization is the top-level entity in the Google Cloud resource hierarchy, under which Folders and Projects are organized. It allows for centralized management of policies and access control across all resources.

Answer 53

D Google Cloud IAM roles are categorized into Basic, Predefined, and Custom roles. There is no such category as Dynamic Role in Google Cloud IAM.

Answer 54

C Custom Roles allow you to create fine-grained permissions that can be applied to specific resources, such as instances in a particular zone, which is more precise than the broader permissions offered by Basic or Predefined Roles. Un rol personalizado es la herramienta adecuada porque el requisito es extremadamente específico y no está cubierto por los roles que Google Cloud ofrece por defecto. El objetivo es conceder permisos solo en una zona concreta, lo que se conoce como el principio de mínimo privilegio. La forma estándar de lograr esto en Google Cloud es: Crear un Rol Personalizado que contenga solo los permisos necesarios para gestionar instancias (por ejemplo, compute.instances.start, compute.instances.stop, etc.). Asignar ese rol personalizado al usuario a nivel de proyecto, pero añadiendo una Condición de IAM. La condición es una expresión lógica que comprueba los atributos de la solicitud. En este caso, la condición sería algo como: resource.zone == "europe-west1-b". Esto asegura que los permisos del rol solo se apliquen cuando el usuario intente gestionar una instancia en la zona europe-west1-b, y se denieguen en cualquier otra zona. La necesidad de crear esta regla tan específica hace que el rol personalizado sea la elección correcta. ❌ Respuestas Incorrectas A. Basic Role y D. Primitive Role (Rol Básico o Primitivo) Por qué son incorrectas: Estas dos opciones se refieren a lo mismo: los roles originales de Propietario (Owner), Editor y Lector (Viewer). Estos roles son extremadamente amplios y otorgan permisos sobre todos los recursos de un proyecto. Es imposible usarlos para limitar el acceso a una única zona. B. Predefined Role (Rol Predefinido) Por qué es incorrecta: Los roles predefinidos son colecciones de permisos creadas por Google para servicios comunes (por ejemplo, roles/compute.instanceAdmin). Aunque son más granulares que los roles básicos, siguen estando diseñados para aplicarse a nivel de proyecto, lo que daría al usuario permisos sobre las instancias en todas las zonas, no solo en una. No existe un rol predefinido "Administrador de Instancias para la zona X".

Answer 55

B Service accounts are used by applications, virtual machines, and other services to authenticate and interact with Google Cloud APIs without the need for user credentials.

Answer 56

D Esta es la respuesta de manual para los exámenes de Google Cloud debido a dos palabras clave en la pregunta: "Semi-structured data" (Datos semi-estructurados): Esto elimina automáticamente a las bases de datos relacionales tradicionales (que requieren esquemas fijos y tablas). Datastore es una base de datos NoSQL orientada a documentos, ideal para JSON, catálogos de productos, perfiles de usuario, etc. "Automatic scaling" (Escalado automático): Datastore es Serverless. Tú no configuras servidores ni discos; Google lo escala automáticamente desde 0 a millones de operaciones por segundo sin que tú muevas un dedo. 🔴 Por qué las malas son las malas A. Cloud SQL El problema: Es para datos estructurados (Relacional/SQL como MySQL o PostgreSQL). Escalado: Aunque ha mejorado, su escalado es principalmente vertical (hacer la máquina más grande) y gestionar el escalado horizontal (réplicas de lectura) requiere configuración manual. No es "automático" al nivel de Datastore. B. Cloud Spanner El problema: Aunque escala horizontalmente de forma increíble, sigue siendo una base de datos relacional (SQL) diseñada para datos estructurados con consistencia global. Coste: Es la opción más cara y potente ("el Ferrari" de las bases de datos). Usarla solo para "datos semi-estructurados" sin necesitar consistencia global transaccional suele ser matar moscas a cañonazos. C. BigQuery El problema: BigQuery es un Data Warehouse (Almacén de datos) para Analítica (OLAP), no una base de datos operativa para aplicaciones. Matiz: Aunque BigQuery escala y soporta JSON, su función es ejecutar consultas masivas sobre datos históricos, no servir como la base de datos transaccional de un sistema de procesamiento en tiempo real o backend de aplicaciones (tiene latencia de segundos, no de milisegundos). Resumen de palabras clave (Cheat Sheet) Para el examen de Google Cloud, asocia mentalmente así: Palabra clave en la pregunta Servicio (Respuesta) Relacional + Local / Lift & Shift Cloud SQL Relacional + Global + Escalado Horiz. Cloud Spanner Semi-estructurado + Serverless + Apps Datastore / Firestore Analítica + SQL + Warehouse BigQuery NoSQL + Latencia muy baja (<10ms) + IoT Bigtable

Answer 57

B La Jerarquía de Redes en Google Cloud: Global ➔ Regional ➔ Zonal Para entender la respuesta, es útil visualizar la estructura de las redes en Google Cloud, que sigue una jerarquía clara. Red VPC (Global): La red de nube privada virtual (VPC) es un recurso global. Esto es una característica clave de Google Cloud. Significa que una única VPC puede abarcar todas las regiones de Google en todo el mundo, permitiendo que los recursos en diferentes continentes se comuniquen de forma privada. Subred (Regional): Dentro de esa VPC global, creas una o más subredes. Cada subred es un recurso regional. Está vinculada a una única región, como europe-west1 (Bélgica) o us-central1 (Iowa). Una subred no puede extenderse a través de múltiples regiones. Su rango de direcciones IP está disponible para todos los recursos dentro de esa región específica. Recursos (Zonal): Finalmente, los recursos como las máquinas virtuales (VM instances) se despliegan en una zona específica, que es una ubicación aislada dentro de una región (por ejemplo, europe-west1-b). Esa máquina virtual obtendrá su dirección IP del rango de la subred regional a la que pertenece. Una buena analogía es una empresa multinacional: La empresa es la VPC (Global). La oficina en un país es la Subred (Regional). Un piso específico de esa oficina es la Zona (Zonal), donde se sientan los empleados (las VMs). Por qué las otras opciones son incorrectas ❌ A. Zonal: Incorrecto. Aunque los recursos como las VMs son zonales, la subred en sí misma abarca todas las zonas de su región. No creas una subred por cada zona. C. Global: Incorrecto. Este es el alcance de la red VPC, no de la subred. Es un error común confundir ambos. D. Multi-regional: Incorrecto. Esto es esencialmente otra forma de decir global. Una subred está estrictamente confinada a una sola región.

Answer 58

B Preemptible and Spot VMs are primarily chosen because their per-hour price incorporates a substantial discount compared to standard VMs. This makes them cost-effective for fault-tolerant, non-time-sensitive workloads like batch jobs. They have the same performance as ordinary VMs of the same machine type and do not guarantee continuous availability as Compute Engine may terminate them if resources are needed elsewhere.

Answer 59

C Cloud Load Balancing, particularly Application Load Balancers for HTTP(S) traffic, is a fully distributed, software-defined service that provides global and cross-region load balancing, including automatic multi-region failover. This allows an application to present a single front-end to users while distributing traffic across instances in multiple regions

Answer 60

C Dedicated Interconnect allows for one or more direct, private connections to Google and can be covered by up to a 99.99% SLA if the connection topologies meet Google's specifications. Direct Peering and Carrier Peering are explicitly noted as not being covered by a Google Service Level Agreement. Cloud VPN over the Internet is not mentioned in the sources as offering an SLA.

Answer 61

C Esta afirmación es CIERTA y describe perfectamente qué es Google Cloud DNS. Vamos a desglosarla: "Servicio DNS gestionado (managed)": Significa que no tienes que preocuparte por aprovisionar, mantener o parchear servidores DNS. Google se encarga de toda la infraestructura, la seguridad y la disponibilidad. Tú simplemente configuras tus dominios (zonas) y registros (A, CNAME, MX, etc.). "Se ejecuta en la infraestructura de Google": Aprovecha la red global de Google para ofrecer un servicio de baja latencia y alta disponibilidad. De hecho, Google Cloud DNS tiene un SLA (Acuerdo de Nivel de Servicio) del 100% de disponibilidad. "Programable y rentable": Puedes gestionar tus zonas y registros a través de la consola, la línea de comandos (gcloud) o mediante una API. Esto permite automatizar la gestión de DNS, lo cual es fundamental en entornos de DevOps. Además, su modelo de precios es muy competitivo. "Para hacer que las aplicaciones estén disponibles": Este es su propósito principal: traducir un nombre de dominio fácil de recordar (como www.miempresa.com) a la dirección IP del servidor donde se aloja tu aplicación, haciéndola accesible a los usuarios de todo el mundo. Por qué las otras opciones son incorrectas A) It is a public DNS resolver service available globally at 8.8.8.8. (Es un servicio de resolución de DNS público disponible globalmente en 8.8.8.8). Esta afirmación es FALSA. Describe un servicio diferente de Google llamado Google Public DNS. Google Public DNS (8.8.8.8) es un resolvedor de DNS. Es el servicio que tu ordenador usa para "preguntar" dónde está google.com. Es como usar la guía telefónica para buscar un número. Google Cloud DNS es un servicio autoritativo. Es el servicio que usan las empresas para "publicar" sus propios dominios en la guía telefónica global de internet. No es un resolvedor, sino el lugar donde se guardan los registros oficiales. B) It is a self-managed service requiring customers to provision and maintain DNS servers. (Es un servicio autogestionado que requiere que los clientes aprovisionen y mantengan servidores DNS). Esta afirmación es FALSA. Es exactamente lo contrario de lo que ofrece Cloud DNS. El principal valor de un servicio "gestionado" (managed) es, precisamente, evitar que el cliente tenga que aprovisionar, configurar y mantener servidores. Esta opción describe lo que tendrías que hacer si montaras tu propio servidor DNS en una máquina virtual de Compute Engine, por ejemplo. D) Its primary use is limited to internal network resolution within a single VPC subnet. (Su uso principal se limita a la resolución de red interna dentro de una única subred VPC). Esta afirmación es FALSA. Si bien Cloud DNS tiene una función de zonas privadas para la resolución de nombres dentro de una red VPC (por ejemplo, para que servidor-db se resuelva a una IP interna), este no es su uso principal. La característica clave y el uso más común de Cloud DNS es como servicio de DNS público y global. Además, una zona privada puede funcionar para una VPC completa, no está limitada a una "única subred".

Answer 62

B Subnets in Google Cloud are regional. This means they can span all zones within a region, enabling high availability without added network complexity.

Answer 63

A y C Preemptible and Spot VMs are ideal for cost-effective, fault-tolerant workloads. They can be interrupted by Google, making them unsuitable for long-running critical tasks, but great for batch processing.

Answer 64

C Autoscaling adds or removes VMs based on load metrics, optimizing cost and performance for applications with variable workloads.

Answer 65

B Cloud Storage buckets are designed for affordable, scalable object storage, making them ideal for backups, logs, and static content.

Answer 66

C Cloud Load Balancing is a fully managed, global solution that supports multiple protocols and doesn’t require pre-warming, making it ideal for auto-scaling applications.

Answer 67

C Una red VPC de Google Cloud es un recurso global, no está limitada a una sola región. Esto significa que puedes crear una única red VPC y, dentro de ella, añadir subredes en diferentes regiones de todo el mundo (por ejemplo, una subred en Europa, otra en EE. UU. y otra en Asia, todas perteneciendo a la misma red VPC). Esto simplifica enormemente la comunicación entre recursos desplegados en distintas partes del planeta. Las Respuestas Incorrectas ❌ A) VPC networks are limited to a single region. (Las redes VPC están limitadas a una sola región.) Esto es falso. Como se mencionó, las redes VPC de Google Cloud son globales. Esta es una diferencia clave con otros proveedores de nube, como AWS, donde las VPC son de ámbito regional. B) VPC networks require you to manually provision routers. (Las redes VPC requieren que aprovisiones routers manualmente.) Esto es falso. Cada red VPC viene con un router virtual distribuido y totalmente gestionado por Google. No necesitas configurar ni gestionar ningún dispositivo de enrutamiento. Tú solo te encargas de definir las reglas de enrutamiento (rutas), pero la infraestructura subyacente es automática. D) VPC networks do not support firewall rules. (Las redes VPC no admiten reglas de firewall.) Esto es completamente falso. Las reglas de firewall (VPC Firewall Rules) son una parte fundamental e integrada de la seguridad de las redes VPC en Google Cloud. Permiten controlar el tráfico entrante y saliente de las máquinas virtuales de forma detallada y segura.

Answer 68

B y C Preemptible VMs are limited to 24 hours of runtime, while Spot VMs have no maximum runtime and offer more features, although both can be interrupted if Google needs the resources.

Answer 69

B The most common solution is to add a persistent disk (specifically, a zonal persistent disk) to a Compute Engine instance for efficient and reliable block storage Un disco persistente zonal es la opción de almacenamiento en bloque estándar y más versátil para las máquinas virtuales (VMs) de Compute Engine. Piensa en él como el "disco duro" principal de tu servidor virtual. ¿Por qué es ideal para uso general? Persistente y fiable: Los datos almacenados en un disco persistente se conservan incluso si apagas o eliminas la máquina virtual a la que estaba conectado. Puedes desconectarlo de una VM y conectarlo a otra dentro de la misma zona. Disco de arranque: Por defecto, el sistema operativo de una nueva instancia de Compute Engine se instala en un disco persistente. Flexible: Puedes redimensionar los discos persistentes fácilmente y sin detener tu VM, lo que te permite adaptarte a tus necesidades de almacenamiento. Buen equilibrio: Ofrece un buen equilibrio entre coste, rendimiento y fiabilidad, lo que lo hace adecuado para una amplia variedad de cargas de trabajo, desde pequeñas aplicaciones web hasta bases de datos. Las Respuestas Incorrectas A) Local SSD (SSD Local) ❌ Los SSD locales son discos de estado sólido físicamente acoplados al servidor que aloja tu VM. ¿Por qué no es para uso general? Almacenamiento temporal (efímero): Los datos en un SSD local se borran permanentemente si la VM se detiene o se reinicia (por ejemplo, durante un mantenimiento). No son persistentes. Uso específico: Se utilizan para tareas que requieren una velocidad de lectura/escritura extremadamente alta, como cachés, procesamiento de datos a gran escala o espacio de almacenamiento temporal (scratch disk). No son fiables para datos que necesites conservar. C) Cloud Storage bucket (Bucket de Cloud Storage) ❌ Cloud Storage es un servicio de almacenamiento de objetos, no de bloques. ¿Por qué no es para uso general (como disco de la VM)? No es un disco de sistema: No puedes instalar un sistema operativo en un bucket de Cloud Storage ni montarlo como si fuera un disco duro local para el sistema de archivos raíz. Funciona más como un repositorio de archivos externo accesible a través de APIs. Uso diferente: Es ideal para almacenar archivos no estructurados (imágenes, vídeos, backups, archivos de sitios web estáticos), pero no para ser el disco principal donde se ejecutan las aplicaciones y el sistema operativo de tu VM. D) Filestore ❌ Filestore es un servicio de almacenamiento de archivos en red (NAS) totalmente gestionado. ¿Por qué no es la opción más común? Almacenamiento compartido: Su principal caso de uso es proporcionar un sistema de archivos que puede ser accedido y compartido por múltiples máquinas virtuales simultáneamente (como una unidad de red compartida). Solución especializada: Para una sola instancia que no necesita compartir su almacenamiento de esta manera, un disco persistente es una solución mucho más simple y económica. Filestore es una opción más específica y, generalmente, más costosa para casos de uso concretos.

Answer 70

A y C Cloud Load Balancing distributes user traffic across multiple instances and provides cross-region load balancing with automatic failover. It does NOT require pre-warming and supports various traffic types, not just HTTP(S)

Answer 71

C Firewall rules in Google Cloud VPCs can be defined using network tags on Compute Engine instances, making it easy to control access based on instance roles

Answer 72

C Google VPC networks are global resources. This means you can have a single VPC network that spans all Google Cloud regions, allowing VMs in different regions to communicate using their private IP addresses within that VPC. Subnets are regional, but the VPC itself is global.

Answer 73

B Spot VMs (and their predecessor, Preemptible VMs) offer the largest discounts (up to 90%) compared to standard VM prices. They are ideal for fault-tolerant workloads like batch processing jobs that can handle preemption, as Compute Engine might terminate these instances if resources are needed elsewhere.

Answer 74

C ✅ La Solución Correcta: C C) Global External Application Load Balancer (Balanceador de Carga de Aplicaciones Externo y Global) Este balanceador es la elección perfecta porque cada palabra en su nombre se alinea con un requisito del problema: Global: La aplicación sirve a usuarios globalmente. Este balanceador proporciona una única dirección IP Anycast que dirige a los usuarios al punto de presencia de Google más cercano, minimizando la latencia. External: El tráfico proviene de usuarios en internet, por lo que se necesita un balanceador externo. Application (Aplicación / Capa 7): Este es el punto más importante. Al ser un balanceador de "Aplicación", opera en la Capa 7 (HTTP/S) del modelo OSI. Esto le permite: Entender el tráfico HTTP/S: Esencial para el requisito. Realizar terminación SSL: Gestiona los certificados SSL y descifra el tráfico antes de enviarlo a las instancias, cumpliendo con el requisito de "SSL termination". Hacer enrutamiento basado en contenido: Puede inspeccionar la URL (por ejemplo, /videos o /imagenes) o el host para dirigir el tráfico a diferentes grupos de instancias, cumpliendo exactamente con el requisito de "content-based routing". ❌ Las Opciones Incorrectas: A, B y D A) Regional Internal TCP/UDP Load Balancer Es incorrecto por tres razones: es Regional (no global), Interno (no para tráfico de internet) y de Capa 4 (TCP/UDP), por lo que no puede hacer enrutamiento basado en contenido ni terminación SSL. B) Network Load Balancer (Passthrough) Es incorrecto porque es un balanceador de Capa 4 de tipo "passthrough". Simplemente reenvía los paquetes sin interpretarlos. No puede "ver" el tráfico HTTP/S, por lo que no puede realizar terminación SSL ni enrutamiento basado en contenido. D) Regional External TCP Proxy Load Balancer Es incorrecto por dos razones. Primero, es Regional, lo que no es ideal para una audiencia global. Segundo, aunque termina la conexión TCP, sigue operando en la Capa 4 y no entiende el protocolo HTTP/S lo suficiente como para realizar enrutamiento basado en contenido.

Answer 75

D Dedicated Interconnect provides direct physical connections between an on-premises network and Google's network. It offers high bandwidth, low latency, private connectivity, and is eligible for up to a 99.99% SLA, making it suitable for enterprise-grade, mission-critical workloads. Cloud VPN operates over the public internet, while Peering options might not offer the same level of dedicated bandwidth or SLA for private VPC traffic.

Answer 76

C Cloud CDN integrates seamlessly with Google Cloud's external Application Load Balancer. It can be enabled with a simple checkbox to cache content at Google's globally distributed edge locations, reducing latency for users and decreasing the load on backend origin servers. Claro, aquí tienes el análisis de esa pregunta. La respuesta correcta es C. Cloud CDN. ✅ Explicación de la Respuesta Correcta C. Cloud CDN (Content Delivery Network) es la respuesta correcta porque está diseñado específicamente para este propósito y se integra de forma nativa con el balanceador de carga de aplicaciones (Application Load Balancer). Reduce la latencia: Cloud CDN almacena en caché copias de tu contenido estático (imágenes, CSS, JavaScript) en los puntos de presencia perimetrales de Google repartidos por todo el mundo 🌐. Cuando un usuario solicita el contenido, se le entrega desde la ubicación de caché más cercana en lugar de tener que viajar hasta el servidor de origen, lo que reduce drásticamente el tiempo de carga. Descarga a los servidores de origen: Dado que la mayoría de las solicitudes de contenido estático son atendidas por la caché de Cloud CDN, tu servidor de origen (backend) recibe mucho menos tráfico. Esto reduce su carga de trabajo y los costos asociados. "Casilla de verificación única": Esta es la clave de la pregunta. Al configurar un backend en un Application Load Balancer externo, hay literalmente una casilla de verificación llamada "Habilitar Cloud CDN" ✅. Marcarla activa el servicio para ese backend, lo que lo convierte en la solución más simple y directa posible. ❌ Por qué las otras opciones son incorrectas A. Cloud Storage configurado para acceso multirregional: Aunque Cloud Storage es excelente para almacenar y servir activos estáticos y una configuración multirregional ofrece alta disponibilidad, no funciona como una capa de caché para un balanceador de carga existente con un solo clic. Cloud Storage sería el origen del contenido, no una caché que se antepone a otro origen. B. Cloud DNS con IP Anycast: El Application Load Balancer ya utiliza una IP Anycast para dirigir a los usuarios al punto de presencia de Google más cercano. Cloud DNS se encarga de la resolución de nombres de dominio. Aunque ayuda a reducir la latencia de la conexión inicial, no almacena en caché el contenido de la aplicación en sí. Simplemente te dice cómo llegar a la puerta principal más rápido, pero no te entrega el contenido. D. Filestore High Scale: Filestore es un servicio de almacenamiento de archivos de alto rendimiento basado en NFS (Network File System). Está diseñado para cargas de trabajo de computación, como renderizado o análisis, que necesitan una semántica de sistema de archivos compartido. No tiene ninguna relación con la entrega de contenido web ni con el almacenamiento en caché para aplicaciones globales.

Answer 77

B A VPC in Google Cloud is a virtual network that provides a secure, isolated environment for your resources, including networking and firewalling capabilities to control communication.

Answer 78

C Google Compute Engine allows users to create VMs with custom machine types, enabling flexibility in specifying vCPUs and memory for specific needs.

Answer 79

B Autoscaling automatically adjusts the number of VM instances based on load changes, ensuring optimal performance and cost-efficiency.

Answer 80

B Preemptible VMs offer up to 90% discount compared to standard VMs, ideal for non-critical workloads that can handle interruptions.

Answer 81

C Dedicated Interconnect provides a direct, private connection with up to 99.99% uptime SLA, suitable for mission-critical applications.

Answer 82

C Cloud Storage is Google's object storage product, designed for durable and highly available storage of data managed as "objects" rather than files or disk chunks. It is well suited for storing binary large-object (BLOB) data like videos, photos, and other online content, as well as for backup, archiving, and storing intermediate results. It is not intended for use as a root file system for virtual machines (Persistent Disk is used for that), for data warehousing/analytical querying (BigQuery is), or for managing relational databases (Cloud SQL or Spanner are RDBMS offerings).

Answer 83

D Archive Storage is the lowest-cost Cloud Storage class and is ideally used for data archiving, online backup, and disaster recovery, specifically for data that you plan to access less than once a year. While Coldline Storage is also low-cost for infrequently accessed data (at most once every 90 days), Archive Storage is designed for even less frequent access and offers the lowest storage cost, although it has higher costs for data access and operations

Answer 84

B Spanner is a fully managed relational database service that scales horizontally to petabytes and is designed for applications requiring high availability, strong global consistency, and high numbers of input/output operations per second (tens of thousands or more). Cloud SQL is also a fully managed relational database with full SQL support but scales vertically and is limited to a maximum of 64 TB in the source material. Firestore and Bigtable are NoSQL databases and do not support full SQL.

Answer 85

C Firestore is a flexible, horizontally scalable, NoSQL cloud database specifically designed for mobile, web, and server development. It stores data as documents organized into collections. Key features include massive scaling, predictability, real-time query results, offline data synchronization, and the ability to cache data for offline access. Cloud SQL and Spanner are relational databases, and Bigtable is a NoSQL database typically used for big data workloads and analytics with heavy read/write events, not optimized for mobile/web synchronization or offline access in the way Firestore is

Answer 86

C ✅ La Respuesta Correcta: C) Access Control Lists (ACLs) La clave de la pregunta está en "control más granular (finer-grained)" que la "herencia a nivel de proyecto (project-level)" de IAM. IAM (Identity and Access Management) es el sistema estándar de permisos en Google Cloud. Cuando aplicas un rol de IAM (como "Visualizador de Objetos de Storage") a un usuario a nivel de proyecto, este puede ver todos los objetos en todos los buckets de ese proyecto. Si lo aplicas a nivel de bucket, puede ver todos los objetos dentro de ese bucket. ¿Qué pasa si solo quieres que un usuario vea un solo archivo (un objeto) dentro de un bucket que contiene 1,000 archivos? No puedes usar IAM a nivel de bucket, porque eso le daría acceso a los 1,000 archivos. Aquí es donde entran las ACLs (Listas de Control de Acceso). Las ACLs son un sistema de permisos más antiguo, pero mucho más granular, que te permite asignar permisos (como READ o WRITE) a usuarios específicos (ej. usuario@gmail.com) sobre objetos individuales. Por lo tanto, las ACLs son el método que ofrece ese control "más fino" a nivel de objeto individual, yendo más allá del control "todo o nada" de IAM a nivel de bucket. ❌ Por Qué las Otras Opciones Son Incorrectas Las otras tres opciones son funciones importantes de Cloud Storage, pero no tienen nada que ver con gestionar permisos de acceso de usuarios: A. Object Versioning (Versionado de Objetos): Esta función sirve para mantener un historial de las versiones de un archivo. Si subes un archivo nuevo con el mismo nombre, el antiguo no se borra, sino que se guarda como una versión anterior. Es una medida de seguridad de datos (para no perder trabajo), no de acceso (para controlar quién entra). B. Lifecycle Policies (Políticas de Ciclo de Vida): Esta función sirve para automatizar acciones sobre los objetos según ciertas reglas (como su antigüedad o tipo). Por ejemplo: "Borra todos los archivos que tengan más de 90 días" o "Mueve los archivos que nadie ha leído en 30 días a almacenamiento más barato (Coldline)". Gestiona el coste y el almacenamiento, no los permisos. D. Autoclass: Esta es una función que optimiza automáticamente los costes de almacenamiento. Analiza con qué frecuencia se accede a los objetos y los mueve a la clase de almacenamiento más barata posible (ej. de Standard a Nearline) sin que tengas que crear políticas de ciclo de vida. De nuevo, gestiona costes, no acceso.

Answer 87

C Object versioning in Cloud Storage keeps a history of modifications like overwrites and deletions. You can list, restore, or delete old versions of objects.

Answer 88

C Bigtable is optimized for massive workloads, especially analytical and time-series data, with consistent low latency and high throughput.

Answer 89

B y D Opciones Correctas ✅ B. Puedes eliminar objetos que superen un cierto número de días de antigüedad. Esta es una de las funciones principales de las políticas de ciclo de vida. Puedes configurar una regla con la acción Delete (Eliminar) y una condición basada en la Age (Antigüedad) del objeto. Por ejemplo, puedes establecer una regla para que cualquier objeto con más de 365 días de antigüedad se elimine automáticamente, lo cual es muy útil para la limpieza de datos y la gestión de costes. D. Puedes conservar solo las 3 versiones más recientes de cada objeto. Esto también es una función clave para los buckets que tienen habilitado el control de versiones. Puedes crear una regla que utilice la acción Delete (Eliminar) con la condición NumNewerVersions (Número de Versiones Más Recientes). Si estableces esta condición en 3, la política eliminará automáticamente cualquier versión no actual de un objeto tan pronto como existan 3 versiones más nuevas que ella. Esto te permite controlar la cantidad de historial que guardas y evitar costes de almacenamiento innecesarios por versiones antiguas. Opciones Incorrectas ❌ A. Puedes mover datos a Standard Storage automáticamente. Esto es falso. Las políticas de ciclo de vida están diseñadas para mover datos a clases de almacenamiento más frías y económicas (de Standard a Nearline, de Nearline a Coldline, etc.), no al revés. La clase Standard es la más "caliente" y cara, por lo que no hay un caso de uso para mover datos hacia ella de forma automática. C. Puedes aumentar la redundancia de los objetos más antiguos. Esto es falso. La redundancia de los datos (por ejemplo, si se almacenan en una sola región, en dos regiones o en varias) es una propiedad que se define a nivel del bucket en el momento de su creación. Las políticas de ciclo de vida gestionan la clase de almacenamiento (que afecta al coste y al tiempo de acceso), pero no pueden cambiar la configuración de redundancia de un objeto.

Answer 90

C Firestore is a NoSQL database optimized for real-time synchronization and offline access, ideal for mobile and web applications.

Answer 91

B y C ¿Por qué las opciones B y C son correctas? ✅ Google Cloud Storage tiene cuatro clases principales: Standard, Nearline, Coldline y Archive. Aunque están diseñadas para diferentes casos de uso y tienen distintos precios, comparten varias características fundamentales de diseño. B. Geo-redundancy in multi-region settings La geo-redundancia es una característica de la ubicación que eliges para tus datos, no de la clase de almacenamiento. Si creas un bucket en una ubicación multirregional (por ejemplo, eu o us), Google Cloud replica automáticamente tus datos en centros de datos geográficamente separados dentro de esa región. Esto proporciona una altísima disponibilidad en caso de que un centro de datos entero falle. Cualquier clase de almacenamiento (Standard, Nearline, Coldline o Archive) puede ser utilizada en un bucket multirregional y se beneficiará de esta geo-redundancia. C. Low latency and high durability Alta durabilidad (High durability): Esta es una de las características más importantes y es idéntica para todas las clases. Google Cloud Storage está diseñado para una durabilidad anual del 99.999999999% (11 nueves). Esto significa que, estadísticamente, puedes esperar perder un objeto una vez cada 100 mil millones de años. No importa si tus datos están en Standard o Archive, la protección contra la pérdida de datos es la misma. Baja latencia (Low latency): Esto se refiere al tiempo hasta el primer byte (time to first byte). Todas las clases de almacenamiento ofrecen acceso en milisegundos. Aunque el costo y el tiempo mínimo de almacenamiento varían, la capacidad de acceder a un objeto rápidamente es común a todas. Es importante no confundir "latencia de acceso" con "costo de acceso" o "disponibilidad". ¿Por qué las otras opciones son incorrectas? ❌ A. Maximum 1 TB per object El tamaño máximo para un solo objeto en Google Cloud Storage es de 5 TB, no 1 TB. Este límite de 5 TB es consistente en todas las clases de almacenamiento, pero el valor indicado en la opción (1 TB) es incorrecto, lo que invalida la respuesta. D. Free ingress and egress for all objects Esto es incorrecto en varios niveles: Ingress (subida de datos): La entrada de datos a Google Cloud Storage es generalmente gratuita para todas las clases. Egress (salida de datos): La salida de datos (leer o descargar) casi siempre tiene un costo. De hecho, los costos de egress y acceso a los datos son una de las principales diferencias entre las clases de almacenamiento. Por ejemplo, leer datos de Coldline o Archive es significativamente más caro que leerlos de Standard Storage. La afirmación de que el egress es gratuito es incorrecta.

Answer 92

C Cloud Storage is Google’s object storage solution, ideal for storing unstructured data like images, videos, and backups, and is designed for high availability and scalability

Answer 93

B y C In object storage, data is managed as objects with metadata and a unique key. Objects are immutable—modifications result in new versions, not in-place edits ✅ Respuestas Correctas B) Cada objeto tiene asociados metadatos y un identificador único. Explicación: Esta es una característica fundamental del almacenamiento de objetos. Cada fichero que subes a Google Cloud Storage se trata como un objeto. Este objeto tiene un nombre único dentro de su "bucket" (el contenedor) y un conjunto de metadatos (datos sobre los datos), como el tipo de contenido, el tamaño, la fecha de creación, etc. C) Los objetos son inmutables; se crean nuevas versiones al cambiarlos. Explicación: "Inmutable" significa que no puedes editar una parte de un objeto que ya existe. Si quieres cambiar un fichero, en realidad tienes que subir una nueva versión completa del fichero, que reemplaza a la anterior. No puedes, por ejemplo, abrir un fichero de texto en Cloud Storage y modificar solo una línea. Esta inmutabilidad garantiza la consistencia de los datos. ❌ Respuestas Incorrectas A) Los datos se gestionan como archivos en una jerarquía de directorios. Explicación: Esto describe un sistema de archivos tradicional (como el de tu ordenador), no el almacenamiento de objetos. Aunque en la consola de Google Cloud veas una estructura de carpetas, es solo una ilusión visual. En realidad, todos los objetos viven en el mismo nivel dentro del bucket, en un "espacio de nombres plano". El carácter / en el nombre de un objeto simplemente simula una carpeta para que sea más fácil organizarlos. D) Los objetos se pueden editar directamente sin crear nuevas versiones. Explicación: Esta opción es incorrecta porque contradice directamente el principio de inmutabilidad (opción C). Como los objetos no se pueden cambiar, es imposible editarlos "en el sitio". Cualquier modificación requiere la subida de un objeto nuevo.

Answer 94

D Archive Storage is optimized for data accessed less than once a year, offering the lowest storage cost but higher access costs and a 365-day minimum storage duration

Answer 95

B Autoclass monitors object access and moves data to colder or hotter storage classes to optimize costs and performance automatically

Answer 96

B y C Por qué las respuestas B y C son las correctas Opción B: Soporta copias de seguridad gestionadas y replicación automática True (Verdadera). Esta es la definición de libro de "Fully Managed" (Totalmente gestionado). Backups: Cloud SQL hace copias de seguridad automáticas todos los días (y retiene los logs de transacciones) para que puedas recuperar la base de datos a un punto específico en el tiempo (PITR). Replicación: Te permite crear "Read Replicas" (para lectura) o configurar "High Availability" (Alta Disponibilidad) con una instancia en espera (standby) en otra zona, todo con unos pocos clics. Google se encarga de la sincronización. Opción C: Puede ejecutar MySQL, PostgreSQL y SQL Server True (Verdadera). Cloud SQL no es un motor de base de datos inventado por Google (como Spanner o BigQuery). Es un servicio que aloja versiones nativas de estos tres motores populares: MySQL (Open source) PostgreSQL (Open source) SQL Server (Microsoft) Esto facilita mucho la migración "Lift and Shift": si ya tienes tu DB en uno de estos motores "on-premise", puedes moverla a Cloud SQL sin cambiar el código de tu aplicación. Por qué las otras son falsas Opción A: Requiere instalación y mantenimiento manual False (Falsa). Por qué es mala: Esto describe el modelo IaaS (Infraestructura como Servicio), es decir, instalar tu propia base de datos dentro de una máquina virtual (Compute Engine). La realidad de Cloud SQL: Tú no instalas el sistema operativo, ni instalas el software de la base de datos, ni aplicas parches de seguridad manualmente. Google lo hace por ti. Opción D: Diseñado para almacenar objetos binarios grandes no estructurados (BLOBs) False (Falsa). Por qué es mala: Aunque técnicamente puedes guardar pequeños datos binarios en una base de datos relacional, no está diseñada para almacenar archivos grandes como videos, imágenes o documentos (BLOBs masivos). Eso sería muy caro e ineficiente. La herramienta correcta: Para objetos no estructurados (BLOBs), la solución correcta en Google Cloud es siempre Cloud Storage.

Answer 97

C Cloud Storage is designed for storing immutable blobs (Binary Large Objects) like images and videos. It offers various storage classes (Standard, Nearline, Coldline, Archive) and lifecycle management to transition objects between these classes, making it ideal for cost-effective storage of infrequently accessed large files. (Slides 6, 8, 15, 16, 47)

Answer 98

D Firestore is a NoSQL document database specifically designed for mobile, web, and server development. It stores data in documents organized into collections, supports real-time synchronization, and offers offline support, making it ideal for applications like the one described. (Slides 33, 34, 36, 50)

Answer 99

C Spanner is a fully managed, relational database service that offers strong global consistency, horizontal scalability, and SQL support. It's designed for mission-critical applications that require high availability and high throughput for transactional workloads, as described in the scenario. (Slides 30, 31, 49)

Answer 100

B y D B) Bigtable is designed for massive workloads involving semi-structured data, making it suitable for IoT, user analytics, and financial data analysis. (Slide 39, 40) D) Bigtable is a NoSQL big data database service known for consistent low latency and high throughput, capable of handling petabytes of data. (Slide 39, 40) A is more suitable for Cloud SQL. C describes Cloud SQL.

Answer 101

B Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server. It's designed to handle mundane tasks like patching, updates, backups, and replication, making it ideal for migrating existing applications that use these database engines without requiring significant re-architecture for global scale (which Spanner offers). Its capacity (up to 64TB mentioned in slide 48) is well within the 500GB requirement. (Slides 25, 26, 48)

Answer 102

B Cloud Storage is designed for object storage, ideal for handling large amounts of unstructured data like videos and images, with high durability and availability for frequent access. Cloud SQL is for relational databases, Spanner for scalable relational databases, and Firestore for NoSQL real-time applications, none optimized for such unstructured data.

Answer 103

C Cloud SQL is a managed relational database scaling vertically (up to 64 TB), while Spanner offers horizontal scalability and strong global consistency, designed for high-scale applications needing real-time query performance.

Answer 104

B Google Cloud Storage has four classes: Standard (frequent access), Nearline (once per month or less), Coldline (once every 90 days or less), and Archive (less than once a year). Nearline is cost-effective for infrequently accessed data, balancing cost and availability.

Answer 105

A Firestore, a NoSQL database, is ideal for real-time data synchronization in mobile/web apps, with offline support. Bigtable handles massive, high-throughput workloads for analytical and operational batch processing, not real-time updates. Firestore: La Base de Datos para Aplicaciones Propósito Principal: Servir como un backend flexible y escalable para aplicaciones web y móviles. Fortaleza Clave (Tiempo Real): Su característica más destacada es la capacidad de sincronizar datos en tiempo real con los clientes (navegadores, apps móviles). Usando "listeners" (observadores), tu aplicación puede recibir actualizaciones instantáneamente cuando los datos cambian en la base de datos. Esto es ideal para apps de chat, juegos multijugador, dashboards en vivo, etc. Modelo de Datos: Base de datos de documentos (similar a MongoDB), organizada en colecciones y documentos. Es muy intuitiva para el desarrollo de aplicaciones. Bigtable: El Monstruo del Big Data Propósito Principal: Almacenar y servir cantidades masivas de datos (terabytes a petabytes) con un rendimiento muy alto y baja latencia, especialmente para cargas de trabajo analíticas y operacionales a gran escala. Fortaleza Clave (Batch y Alto Rendimiento): Es perfecto como destino (sink) para pipelines de procesamiento de datos por lotes (batch) que se ejecutan con Dataflow o Dataproc. También es ideal para almacenar datos de series temporales (como datos de sensores de IoT) o para servir datos a modelos de machine learning. No tiene capacidades de "sincronización en tiempo real" al estilo de Firestore. Modelo de Datos: Base de datos de columnas anchas (wide-column), optimizada para lecturas y escrituras rápidas de filas individuales. Ahora, analicemos las opciones: ✅ A. Firestore es mejor para aplicaciones en tiempo real, mientras que Bigtable es para procesamiento por lotes. (Correcta) Esta afirmación captura perfectamente la diferencia fundamental en el diseño y el caso de uso principal de cada base de datos. Usarías Firestore para crear una app de colaboración y Bigtable para analizar los datos de sensores de una flota de miles de vehículos. ❌ B. Firestore admite consultas SQL, mientras que Bigtable no. (Incorrecta) Esto es falso para ambos. Ninguno de los dos es una base de datos SQL. Ambos son NoSQL y se consultan utilizando sus propias librerías (SDKs). Firestore usa consultas basadas en documentos y colecciones, y Bigtable se consulta por clave de fila (row key). ❌ C. Firestore es más escalable que Bigtable. (Incorrecta) Esto es rotundamente falso. Si bien Firestore es muy escalable para su propósito (millones de usuarios concurrentes), Bigtable está diseñado para una escala de datos y rendimiento mucho mayor (petabytes). Google usa Bigtable internamente para servicios como Búsqueda, Gmail y Maps. Bigtable es una de las soluciones de base de datos más escalables del planeta. ❌ D. Firestore es más barato que Bigtable. (Incorrecta y Engañosa) El costo depende completamente del caso de uso. Para una pequeña aplicación móvil, Firestore será casi gratis al principio. Sin embargo, para una aplicación con muchísimas lecturas y escrituras, Firestore puede volverse muy caro. Por otro lado, un clúster de Bigtable tiene un costo base más alto, pero a una escala masiva, su costo por operación o por GB almacenado puede ser significativamente más bajo para cargas de trabajo analíticas. No se puede afirmar que uno sea categóricamente más barato que el otro.

Answer 106

C Cloud Storage supports object versioning, lifecycle management, and encryption at rest, but not automatic sharding, as it manages data as objects in buckets, with scalability handled by Google's infrastructure.

Answer 107

D A Pod is described as the smallest unit in Kubernetes that you create or deploy. It represents a running process on your cluster, which can be either a component of your application or an entire app. While a Pod can contain multiple containers, it is considered the smallest deployable unit

Answer 108

C A Service is an abstraction that defines a logical set of Pods and a policy by which to access them. It provides a stable endpoint (or fixed IP address) for a group of Pods because the individual IP addresses assigned to Pods can change over time as Deployments create and destroy them. While a LoadBalancer is often attached to a Service for external access, the Service itself provides the stable internal IP. Option B describes a Deployment. Option D relates more to the container image and Pod configuration Para entender la respuesta, primero hay que entender el problema principal con los Pods en Kubernetes: Los Pods son efímeros (temporales): Los Pods se crean y se destruyen constantemente. Pueden fallar y ser reemplazados por un ReplicaSet, o pueden ser eliminados y creados de nuevo durante un despliegue (Deployment). Las IPs de los Pods no son estables: Cada vez que un Pod se crea, obtiene una nueva dirección IP interna en el clúster. Si un Pod muere y es reemplazado por uno nuevo, el nuevo Pod tendrá una dirección IP diferente. Esto crea un problema: si tienes una aplicación "frontend" que necesita comunicarse con una aplicación "backend", no puede depender de la dirección IP de un Pod específico del backend, porque esa IP cambiará. La Solución: El Service Aquí es donde entra el Service. Un Service actúa como una abstracción de red estable frente a un grupo de Pods. Punto de Acceso Estable: El Service obtiene su propia dirección IP virtual (llamada ClusterIP) y un nombre DNS estable dentro del clúster. Esta IP y este nombre no cambian mientras el Service exista. Conjunto Lógico de Pods: El Service utiliza un "selector" basado en etiquetas (labels) para identificar a qué Pods debe dirigir el tráfico. Por ejemplo, puede apuntar a todos los Pods que tengan la etiqueta app: backend. Balanceo de Carga Interno: Cuando el frontend envía una solicitud al Service del backend (usando su IP fija o su nombre DNS), el Service automáticamente redirige el tráfico a uno de los Pods del backend que esté sano y disponible. En resumen, el Service es como un número de teléfono fijo y único para un grupo de personas, donde cada persona tiene un móvil con un número que puede cambiar. No necesitas saber el número de móvil de cada uno, solo llamas al número fijo y el sistema te conecta con alguien que esté disponible. Análisis de las Opciones C. To provide a stable endpoint (fixed IP address) for a logical set of Pods. (Respuesta Correcta) ¿Por qué es correcto? Esta opción describe perfectamente el propósito principal y fundamental de un Service: ser una capa de abstracción con una dirección IP fija que permite la comunicación fiable con un grupo dinámico de Pods. ¿Por qué las otras opciones son incorrectas? A. To provide external load balancing with a public IP address. ¿Por qué es incorrecto? Aunque un Service de tipo LoadBalancer puede hacer esto, no es su propósito principal y universal. El propósito fundamental es la comunicación dentro del clúster, que se logra con el tipo por defecto, ClusterIP. Exponer un servicio al exterior es un caso de uso específico, no la función principal de todos los Services. B. To define a group of replica Pods and keep them running. ¿Por qué es incorrecto? Esta es la descripción de un Deployment o un ReplicaSet. Estos son los objetos de Kubernetes responsables de asegurarse de que un número específico de réplicas de un Pod estén siempre en ejecución. Un Service no gestiona el ciclo de vida de los Pods, solo les dirige el tráfico. D. To manage container configurations and dependencies within a Pod. ¿Por qué es incorrecto? Esto describe la función del propio Pod. La especificación de un Pod (su archivo YAML) es donde se definen los contenedores que debe ejecutar, las imágenes que debe usar, las variables de entorno, los volúmenes de datos, etc. Un Service es un objeto de red y no tiene nada que ver con la configuración interna de un Pod.

Answer 109

B The sources state that while imperative commands are useful for learning and testing, the real strength of Kubernetes comes when you work in a declarative way. This involves providing a configuration file that describes what you want your desired state to look like, and Kubernetes then determines how to achieve that state

Answer 110

C The sources explicitly state that GKE is a Google-hosted managed Kubernetes service where the environment consists of multiple machines, specifically Compute Engine instances, grouped together to form a cluster. A separate quiz question also confirms that the resources come from Compute Engine

Answer 111

B The sources define a container as "an invisible box around your code and its dependencies with limited access to its own partition of the file system and hardware". It requires only an OS kernel that supports containers and a container runtime, virtualizing the OS and dependencies. Option D describes Kubernetes or GKE, not a container itself. Containers are distinct from virtual machines

Answer 112

B Cloud Dataflow is a fully managed service for processing both batch and streaming data using Apache Beam, making it ideal for scalable, serverless data pipelines

Answer 113

B ✅ Por qué la B es la respuesta correcta B) Database Migration Service (DMS) es la herramienta diseñada específicamente para el escenario descrito en la pregunta. El objetivo es migrar una base de datos relacional (como MySQL, PostgreSQL, etc.) con tiempo de inactividad mínimo (minimal downtime). DMS está creado exactamente para eso. Así es como funciona: Carga inicial (Bulk load): Primero, DMS copia una "foto" completa de tu base de datos actual. Replicación continua (Change Data Capture): Mientras se realiza la copia inicial y después de ella, DMS captura todos los cambios (inserciones, actualizaciones, borrados) que ocurren en tu base de datos original y los aplica en tiempo real a la nueva base de datos en Google Cloud. Corte final (Cutover): Una vez que ambas bases de datos están sincronizadas, puedes elegir un momento para detener la base de datos original y redirigir tus aplicaciones a la nueva en Google Cloud. Este proceso final es muy rápido, logrando una migración con una interrupción del servicio casi imperceptible. Por lo tanto, es la solución perfecta para una migración "en caliente" o con mínima inactividad. Migration Service is built for this.] ❌ Por qué las otras opciones son incorrectas A) BigQuery Data Transfer Service: Esta herramienta se usa para mover datos hacia BigQuery, que es un almacén de datos para análisis (data warehouse), no una base de datos relacional transaccional (OLTP). No está diseñada para migrar una base de datos operativa como MySQL o PostgreSQL a su equivalente en la nube (como Cloud SQL). C) Cloud Pub/Sub: Es un servicio de mensajería para procesar eventos en tiempo real. Se utiliza para conectar diferentes aplicaciones y servicios, no para migrar una base de datos completa. No maneja la carga inicial de datos, la sincronización de esquemas ni la validación. D) Cloud Storage Transfer Service: Este servicio está diseñado para mover archivos y objetos a Cloud Storage. Podrías usarlo para mover un archivo de respaldo (backup) de tu base de datos, pero este método implicaría un tiempo de inactividad considerable: tendrías que detener la base de datos, crear el respaldo, transferir el archivo gigante y finalmente restaurarlo en la nube. Esto viola el requisito clave de "minimal downtime".

Answer 114

B Bigtable is optimized for large-scale, low-latency workloads such as time-series data, making it the best fit for this use case

Answer 115

A y C ✅ Respuestas Correctas A) Usar Cloud KMS para gestionar las claves de cifrado (Use Cloud KMS to manage encryption keys) ¿Por qué es correcta? 🛡️ Google Cloud cifra todos los datos en reposo (at rest) por defecto. Sin embargo, para un control máximo y para cumplir con normativas estrictas, la mejor práctica es gestionar tus propias claves de cifrado. Cloud Key Management Service (KMS) es el servicio de Google Cloud diseñado exactamente para esto. Te permite crear, rotar y gestionar claves criptográficas en un solo lugar. Usar KMS te da control sobre quién y qué puede acceder a tus datos cifrados, ya que sin la clave, los datos son inútiles. Esto se conoce como Cifrado con Claves Gestionadas por el Cliente (CMEK) y es un pilar de la seguridad en la nube. C) Cifrar los datos antes de almacenarlos en Cloud Storage (Encrypt data before storing in Cloud Storage) ¿Por qué es correcta? 🔐 Esta práctica se conoce como cifrado del lado del cliente (client-side encryption). Significa que tu aplicación cifra los datos con una clave que solo tú controlas antes de enviarlos a Google Cloud. De esta manera, Google nunca ve los datos sin cifrar. Esto ofrece la máxima seguridad porque protege los datos tanto en tránsito (ya van cifrados por la red) como en reposo (están almacenados en un formato ilegible sin tu clave). Es una capa de seguridad adicional sobre el cifrado que Google ya proporciona. ❌ Respuestas Incorrectas B) Deshabilitar todos los roles de IAM (Disable all IAM roles) ¿Por qué es incorrecta? 🚫 IAM (Identity and Access Management) es el sistema que controla quién puede hacer qué en tu proyecto de Google Cloud. Deshabilitar todos los roles sería como tirar las llaves de tu casa y cerrar la puerta con cerrojo por dentro. Nadie, ni tú ni tus aplicaciones, podría acceder o gestionar ningún recurso. Es una acción destructiva, no una práctica de seguridad. La verdadera mejor práctica es aplicar el principio de privilegio mínimo: dar a cada usuario o servicio solo los permisos estrictamente necesarios para hacer su trabajo, y nada más. D) Almacenar datos sensibles en texto plano para un acceso más rápido (Store sensitive data in plain text for faster access) ¿Por qué es incorrecta? ☠️ Esta es la peor práctica de seguridad posible. "Texto plano" (plain text) significa sin cifrar, es decir, totalmente legible para cualquiera que obtenga acceso. Almacenar datos sensibles (contraseñas, datos de tarjetas de crédito, información personal) de esta forma es una invitación a un desastre de seguridad. Cualquier ganancia mínima de velocidad (que es a menudo insignificante con los sistemas modernos) se ve eclipsada por el riesgo catastrófico de una fuga de datos. La seguridad siempre debe tener prioridad sobre un rendimiento marginal cuando se trata de información sensible.

Answer 116

C Materialized views in BigQuery store the results of a query, allowing for faster access and improved performance for repeated queries

Answer 117

C Page 9 states, "A Pod is the smallest unit in Kubernetes that you create or deploy. It represents a running process on your cluster... Deploying containers on nodes by using a wrapper around one or more containers is what defines a Pod." It also mentions shared networking and storage

Answer 118

C Page 18 clarifies, "The GKE environment consists of multiple machines, specifically Compute Engine instances, grouped together to form a cluster." Page 23 also lists "Google Cloud's load-balancing for Compute Engine instances" as a GKE benefit.

Answer 119

C Page 19 explains, "With the Autopilot mode, which is recommended, GKE manages the underlying infrastructure such as node configuration, autoscaling, auto-upgrades, baseline security configurations, and baseline networking configuration."

Answer 120

B y C B: Page 4 states, "In short, containers are portable, loosely coupled boxes of application code and dependencies that allow you to 'code once, and run anywhere.'" C: Page 4 also mentions, "A container gives you the best of two worlds - it scales like Platform as a Service (PaaS) but gives you nearly the same flexibility as Infrastructure as a Service (IaaS.)" Option A is incorrect; containers are about application virtualization, not VM management. Option D is incorrect; containers share the host OS kernel (Page 4: "Only needs an OS kernel that supports containers...").

Answer 121

B Page 11 states, "Kubernetes creates a Service with a fixed IP address for your Pods, and a controller says 'I need to attach an external load balancer...'" Page 12 elaborates, "A Service is an abstraction which defines a logical set of Pods and a policy by which to access them... A Service group is a set of Pods and provides a stable endpoint (or fixed IP address) for them."

Answer 122

B Containers package an application with its dependencies into a single, isolated unit, making it easy to deploy and run consistently across different environments, such as from development to production or from a laptop to the cloud.

Answer 123

B Por qué la opción B es la correcta B) By duplicating single containers or managing multiple containers (Duplicando contenedores individuales o gestionando múltiples contenedores) Esta es la definición de escalado horizontal (scaling out), que es el método principal y más eficaz para escalar aplicaciones en la nube. Duplicar contenedores: En lugar de hacer un contenedor más grande (escalado vertical), simplemente creas más copias idénticas (réplicas) del mismo contenedor. Gestionar múltiples contenedores: Un orquestador (como Kubernetes o servicios serverless como Cloud Run) gestiona este grupo de contenedores. Cuando la demanda (tráfico) aumenta, automáticamente crea más copias. Cuando la demanda baja, elimina las copias sobrantes. Un balanceador de carga distribuye el tráfico entre todas las copias, permitiendo que tu aplicación maneje una carga masiva. Esta es la forma moderna y flexible de escalar. Por qué las otras opciones son incorrectas A) By manually installing additional software on each container (Instalando manualmente software adicional en cada contenedor) Incorrecto porque: Esto no es escalar. Esto es modificar el contenedor. Escalar se refiere a aumentar la capacidad para manejar más carga de trabajo, no a cambiar lo que hace el contenedor. C) By increasing the size of the virtual machine hosting the container (Aumentando el tamaño de la máquina virtual que aloja el contenedor) Incorrecto porque: Esto es escalado vertical (scaling up) de la infraestructura subyacente, no del contenedor en sí. Si bien puedes darle a un solo contenedor más CPU o RAM (también escalado vertical), este método es menos flexible y tiene límites. El método idiomático de la nube (Opción B) es escalar horizontalmente. D) By changing the network configuration of the container (Cambiando la configuración de red del contenedor) Incorrecto porque: Cambiar la red (como abrir un puerto o cambiar una regla de firewall) no tiene nada que ver con la capacidad de procesamiento del contenedor. No le ayuda a manejar más solicitudes.

Answer 124

B Kubernetes is an open-source platform designed to manage and orchestrate containers. It automates the deployment, scaling, and operation of application containers, ensuring that applications run smoothly and can be scaled as needed across multiple hosts.

Answer 125

B In Kubernetes, a pod is the smallest deployable unit. It can contain one or more containers that share the same network namespace and can communicate with each other. Pods are deployed, started, stopped, and replicated as a group.

Answer 126

B GKE is Google's managed Kubernetes service, which simplifies the management of containerized applications. For data engineers, this is crucial as it enables the deployment and scaling of data processing jobs, such as those using Apache Spark on Dataproc or Apache Beam on Dataflow, in a containerized environment.

Answer 127

B The sources explicitly state that Cloud Run is a managed compute platform that can run stateless containers. It is also highlighted as being serverless, removing the need for infrastructure management. This differentiates it from services like managing virtual machines or dedicated server infrastructure.

Answer 128

D The Cloud Run developer workflow is described as a straightforward three-step process: First, you write your application code; Second, you build and package your application into a container image; Third, you deploy the container image to Cloud Run

Answer 129

D ✅ Opción D: Son una solución de cómputo ligera, asíncrona y basada en eventos. Esta afirmación es correcta porque describe perfectamente la esencia de Cloud Run. Ligera (Lightweight): Cloud Run ejecuta contenedores, que son mucho más ligeros y rápidos de iniciar que una máquina virtual completa. Esto permite que escale de cero a muchas instancias en segundos. Basada en eventos (Event-based): Un servicio de Cloud Run puede activarse no solo por una petición web (HTTP), sino también en respuesta a una gran variedad de eventos de Google Cloud, como la subida de un archivo a Cloud Storage, un mensaje nuevo en una cola de Pub/Sub o una tarea de Cloud Tasks. Asíncrona (Asynchronous): Es ideal para procesar tareas en segundo plano que no necesitan una respuesta inmediata, como procesar imágenes, generar informes o enviar notificaciones. Solución de cómputo (Compute solution): Su propósito fundamental es ejecutar tu código. En resumen, esta opción captura la naturaleza flexible y moderna de Cloud Run como plataforma serverless. ❌ Opciones incorrectas A. Requieren que aprovisiones y gestiones servidores o máquinas virtuales. Esto es falso. Cloud Run es una plataforma serverless (sin servidor). Su principal ventaja es precisamente que Google gestiona toda la infraestructura por ti. Tú solo te preocupas por subir tu código en un contenedor, y Google se encarga de los servidores, el escalado y el mantenimiento. B. Se utilizan principalmente para alojar aplicaciones grandes y monolíticas. Esto es falso. Aunque técnicamente podrías ejecutar una aplicación monolítica, Cloud Run está optimizado para microservicios y aplicaciones sin estado (stateless). Su capacidad para escalar rápidamente instancias individuales lo hace ideal para arquitecturas donde la aplicación se divide en componentes pequeños e independientes, no para un único bloque de código grande y complejo. C. Se facturan en función de la capacidad del servidor inactivo. Esto es falso y, de hecho, es todo lo contrario al modelo de Cloud Run. La facturación se basa en el pago por uso real: solo pagas por los recursos (CPU y memoria) que tu código consume mientras está procesando peticiones. Si tu servicio no recibe tráfico, puede escalar a cero instancias y no pagas absolutamente nada.

Answer 130

C The sources indicate that Cloud Run functions are well-suited for event-driven tasks such as generating thumbnails or resizing images triggered by uploads to Cloud Storage. Hosting a dynamic web application is presented as a suitable scenario for Cloud Run. The sources describe Cloud Run functions as lightweight and single-purpose, less ideal for continuous background processes or stateful application servers.

Answer 131

D Cloud Run functions can be triggered in multiple ways. The sources state that Events from Cloud Storage and Pub/Sub can trigger Cloud Run functions asynchronously, and you can also use HTTP invocation for synchronous execution. Therefore, they are not limited to just one type of trigger.

Answer 132

B Cloud Run charges only when the container is handling requests, down to 100ms increments. This is more cost-effective than traditional compute options, which charge while the server is running.

Answer 133

A y D Cloud Run functions are event-driven, billed per 100ms while executing, and require no server setup. They are not intended for long-running or stateful processes.

Answer 134

B Cloud Run is ideal for scalable web apps that handle HTTP requests directly. Event-driven tasks are better suited for Cloud Run functions.

Answer 135

B y C Cloud Run pricing is based on resource usage (CPU, memory) while handling requests, with 100ms granularity. There is no charge when idle, and no fixed monthly fee. C. You pay based on the CPU and memory allocated while handling requests Esta es la afirmación más importante y precisa sobre el modelo de precios de Cloud Run. Es el núcleo del modelo serverless o de "pago por uso". Solo se te factura por los recursos (CPU y memoria) que tu contenedor utiliza mientras está procesando activamente una solicitud. El tiempo facturable comienza cuando se recibe la solicitud y termina cuando se envía la respuesta. Si no hay solicitudes, no pagas nada (en la configuración estándar). B. Billing is calculated to the nearest second Esta afirmación es conceptualmente correcta porque destaca la alta granularidad de la facturación de Cloud Run. En la práctica, la facturación es aún más precisa: se calcula al milisegundo más cercano (redondeado a los 100 milisegundos más próximos). Sin embargo, en el contexto de las opciones, esta es la correcta porque se opone a modelos más antiguos que facturan por minuto o por hora. La idea clave es que pagas por unidades de tiempo muy pequeñas, no por bloques grandes. ❌ Respuestas Incorrectas A. You pay even when containers are idle Esta afirmación es falsa en el caso de uso estándar de Cloud Run. El principal beneficio de Cloud Run es, precisamente, que no pagas por el tiempo de inactividad. Nota: Existe una configuración opcional (min-instances) que permite mantener instancias siempre activas para evitar los "arranques en frío" (cold starts). Si usas esta configuración, sí pagarías por esas instancias inactivas, pero no es el comportamiento por defecto del servicio. Como regla general, esta afirmación es incorrecta. D. There’s a fixed monthly cost regardless of usage Esto es completamente falso. Un coste fijo mensual es característico de un modelo de suscripción o de recursos provisionados (como alquilar un servidor dedicado). Cloud Run es lo opuesto: un modelo de pago por uso puro. Si tu servicio no recibe tráfico durante un mes, tu coste será de 0 € (sin contar el generoso nivel gratuito).

Answer 136

C In source-based workflows, Cloud Run uses Buildpacks to convert source code into secure, production-ready container images automatically.

Answer 137

B Cloud Run is ideal for scalable web applications with persistent connections and user interactions, such as hosting a dynamic photo-sharing app. The other scenarios are event-driven and better suited for Cloud Run functions

Answer 138

A, B y D Cloud Run functions is a scalable functions-as-a-service platform, can extend cloud services, and is integrated with Cloud Logging. It does not require server provisioning and can be triggered by events, not just HTTP requests

Answer 139

A Cloud Run functions are designed for event-driven code without the need to manage compute resources. The other options are incorrect or misleading.

Answer 140

B y C Cloud Run charges only for the resources used while handling requests, with billing granularity of 100 milliseconds. There is no charge for idle time or a flat fee

Answer 141

C Cloud Run is for stateless containerized applications, while Cloud Run functions are optimized for lightweight, event-driven, single-purpose functions

Answer 142

B Cloud Run is designed to run stateless containers that can serve web requests, making it ideal for deploying web applications or APIs. Options A, C, and D describe event-driven, single-purpose tasks which are better suited for Cloud Run functions.

Answer 143

B, C y E Por qué las Opciones B, C y E son CORRECTAS B. Puede escalar automáticamente a cero instancias cuando no hay solicitudes entrantes, ahorrando así costos. Por qué es buena: Esta es la característica principal de Cloud Run y la esencia de la "escalabilidad serverless". Si tu servicio no recibe tráfico, Cloud Run reduce el número de contenedores a cero. En ese estado, no pagas nada por las instancias (solo por el almacenamiento de la imagen del contenedor). Es la forma más eficiente de gestionar costos para aplicaciones con tráfico impredecible o esporádico. C. Está construido sobre Knative, lo que le permite ejecutarse en Google Cloud, Google Kubernetes Engine, o en cualquier lugar donde se ejecute Knative. Por qué es buena: Cloud Run no es solo un producto de Google Cloud; es la implementación gestionada del estándar abierto Knative. Knative es un complemento para Kubernetes que proporciona funcionalidades "serverless". Esto te da flexibilidad: puedes ejecutar tu contenedor en Cloud Run (totalmente gestionado) o, si necesitas más control, puedes instalar Knative en tu propio clúster de Google Kubernetes Engine (GKE) (lo que se conoce como "Cloud Run for Anthos") y desplegarlo allí, usando la misma API. E. Cobra por los recursos en función del tiempo que tu contenedor está manejando solicitudes, calculado hasta los 100 milisegundos más cercanos. Por qué es buena: Esto describe con precisión el modelo de precios de "pago por uso". A diferencia de una máquina virtual que pagas mientras está encendida, con Cloud Run solo pagas por la CPU y la memoria asignada mientras tu contenedor está procesando activamente una solicitud (además de un pequeño tiempo de inicio). La facturación es extremadamente granular (redondeada a los 100ms más cercanos), lo que lo hace muy rentable. Por qué las Opciones A y D son INCORRECTAS A. Requiere que los desarrolladores aprovisionen y gestionen manualmente las instancias de máquinas virtuales subyacentes. Por qué es mala: Esta afirmación es la definición opuesta a Cloud Run. Cloud Run es una plataforma "serverless" (sin servidor), lo que significa que abstrae completamente toda la infraestructura. El desarrollador nunca ve ni gestiona una máquina virtual, un sistema operativo o parches de seguridad. Ese es el trabajo de Google. Si quisieras gestionar VMs, usarías Google Compute Engine (GCE). D. Admite principalmente aplicaciones escritas únicamente en Go y Python. Por qué es mala: Esto es completamente falso. Cloud Run es agnóstico al lenguaje porque no ejecuta tu código, ejecuta tu contenedor. Siempre que puedas empaquetar tu aplicación en una imagen de contenedor (como un Dockerfile) y esta escuche solicitudes HTTP en el puerto esperado, funcionará. Puedes usar Go, Python, Node.js, Java, C#, Rust, PHP, o cualquier otro lenguaje.

Answer 144

C The presentation material (page 7) explicitly states that for a source-based workflow, Cloud Run uses Buildpacks (an open-source project) to build the source and package the application into a container image.

Answer 145

C Cloud Run functions are lightweight, event-based, and asynchronous (or synchronous via HTTP). They are ideal for small, single-purpose functions responding to events (like from Cloud Storage or Pub/Sub) or direct HTTP calls, without needing to manage servers or runtime environments.

Answer 146

B y D B: As per page 8, you are charged for the system resources used while a container is handling web requests, and when it is starting or shutting down. D: Page 8 also states, "The price of container time increases with CPU and memory. A container with more vCPU and memory is more expensive." A is incorrect: You do not pay if your container does not handle requests (i.e., when idle and scaled to zero). C is incorrect: Cloud Run's pricing is primarily usage-based, not a fixed monthly fee.

Answer 147

A Cloud Run is a managed serverless computing platform that allows you to run stateless containers, eliminating the need for infrastructure management. It is designed for applications that handle web requests or Pub/Sub events and is built on Knative, an open API and runtime environment based on Kubernetes.

Answer 148

A Cloud Run automatically scales up and down from zero almost instantaneously, charging only for the resources used (calculated to the nearest 100 milliseconds). This ensures cost efficiency by not charging for idle time.

Answer 149

B ✅ La Respuesta Correcta: Procesar tareas impulsadas por eventos (B) El caso de uso principal de una plataforma serverless (sin servidor) como Cloud Run es ejecutar código en respuesta a un evento. Este es el núcleo del modelo de "Funciones como Servicio" (FaaS). Un evento puede ser muchas cosas: Una solicitud HTTP a un endpoint (como en una API o una web). Un nuevo archivo que se sube a un bucket de Cloud Storage. Un mensaje que llega a un tema de Pub/Sub. Un evento programado (ejecutar una tarea cada hora). Cloud Run está diseñado para activarse cuando ocurre uno de estos eventos, ejecutar la lógica contenida en tu contenedor para procesarlo, y luego escalar a cero si no hay más peticiones. Este modelo es extremadamente eficiente para cargas de trabajo que no son constantes. ❌ Por Qué las Otras Opciones son Incorrectas A) Alojar aplicaciones web dinámicas: Si bien este es un uso muy popular y válido de Cloud Run, es en realidad un subconjunto de la opción B. Una aplicación web es simplemente un programa que responde a un tipo específico de evento: una solicitud HTTP. La opción B es más general y describe de manera más fundamental el paradigma operativo de Cloud Run. C) Almacenar grandes conjuntos de datos: Esto es incorrecto. Cloud Run es un servicio de cómputo, no de almacenamiento. Para almacenar datos se utilizan servicios como Cloud Storage, BigQuery o Cloud SQL. D) Gestionar máquinas virtuales: Esto es lo contrario del propósito de Cloud Run. Se llama "serverless" precisamente porque abstrae por completo la gestión de servidores y máquinas virtuales. Tú no tienes que preocuparte por ellas; Google lo hace por ti. Para gestionar VMs manualmente se usa Compute Engine.

Answer 150

B Cloud Run is used for running containerized applications that handle web requests or Pub/Sub events, while Cloud Run functions are lightweight, event-based functions designed for specific, single-purpose tasks triggered by events.

Answer 151

B Cloud Run charges only for the resources used while handling requests, with no cost for idle time. Charges are calculated down to the nearest 100 milliseconds, and there is an additional small fee for every one million requests served.

Answer 152

D The source states that Standard Storage is used for frequently accessed hot data. Nearline Storage and Coldline Storage are used for less-frequently accessed cool data, and Archive Storage is also listed

Answer 153

C The source clearly states that in Module 2, you learned about the Google Cloud Resource Hierarchy, which is made up of four levels: resources, projects, folders, and an organization node.

Answer 154

B Module 5 introduces Kubernetes as an open-source platform for managing containerized workloads and services and then describes Google Kubernetes Engine (GKE) as a Google-hosted managed Kubernetes service in the cloud. Option C describes Cloud Run, and Option D describes Cloud Run functions

Answer 155

A a descripción clave es: "servicio gestionado, definido por software y totalmente distribuido para todo tu tráfico". Definido por Software (Software-Defined): Esto significa que creas y configuras tu red mediante software (a través de la consola de Google Cloud, comandos gcloud o APIs), en lugar de configurar hardware físico como routers y switches. VPC: Encaja perfectamente. Creas redes VPC, subredes, reglas de firewall y rutas, todo de manera programática. Es la esencia de la Red Definida por Software (SDN). Totalmente Distribuido: Esto implica que el servicio no está limitado a una ubicación física o un solo dispositivo. Opera a nivel global en toda la infraestructura de Google. VPC: Encaja perfectamente. Una red VPC es un recurso global. Puedes tener subredes en diferentes regiones de todo el mundo (por ejemplo, una en us-central1 y otra en europe-west1) que pertenecen a la misma red VPC y pueden comunicarse entre sí de forma privada. Servicio Gestionado (Managed Service): Significa que Google se encarga de toda la complejidad de la infraestructura subyacente (hardware, mantenimiento, escalabilidad, redundancia). Tú solo usas el servicio. VPC: Encaja perfectamente. No tienes que preocuparte por los routers, cables o switches físicos que hacen funcionar tu red virtual. Google lo gestiona todo. Para todo tu tráfico (for all your traffic): Este es el punto más importante. Se refiere al servicio fundamental que proporciona el entorno de red para todos tus recursos en la nube. VPC: Encaja perfectamente. La VPC es la "casa" de tus recursos en Google Cloud. Proporciona el aislamiento y la conectividad privada para tus máquinas virtuales (Compute Engine), clústeres de Kubernetes (GKE), bases de datos, etc. Es el lienzo sobre el cual fluye todo tu tráfico interno. ¿Por Qué las Otras Opciones son Incorrectas? B) Google Compute Engine: Es un servicio de cómputo, no de red. Proporciona máquinas virtuales. Estas máquinas usan la red VPC, pero no son la red en sí. C) Cloud Load Balancing: Es un componente de red, pero tiene un propósito muy específico: distribuir el tráfico entrante entre múltiples servidores (backends). No gestiona "todo tu tráfico" interno, solo el que se dirige a un servicio específico. Es una herramienta que usas dentro de tu VPC. D) Google Cloud Interconnect: Es un servicio para conectar tu red local (on-premises) a tu red VPC de Google Cloud de forma privada y dedicada. Es un puente entre tu centro de datos y la nube, no la red interna de la nube en sí misma. Resumen Servicio Descripción ¿Por qué no es la respuesta? A) VPC La red virtual privada, global y fundamental para tus recursos. (Respuesta Correcta) B) Compute Engine Servicio para crear máquinas virtuales (cómputo). No es un servicio de red. C) Load Balancing Distribuye tráfico entrante a tus servicios. Es un componente específico, no la red completa. D) Interconnect Conecta tu red local con la red de Google Cloud. Es una conexión híbrida, no la red interna de la nube.

Answer 156

B Cloud Run is a managed compute platform designed to run stateless containers triggered by HTTP or Pub/Sub events.

Answer 157

A, B y C You can interact with Google Cloud through the Console, SDK/Cloud Shell, and APIs. Amazon CLI is not part of the Google Cloud ecosystem.

Answer 158

B Nearline Storage is designed for data that is accessed less frequently but still needs to be retrieved occasionally.

Answer 159

B, C y D Por qué B, C y D son correctas La Jerarquía de Recursos de Google Cloud es el sistema de contenedores que GCP utiliza para organizar, gestionar y aplicar políticas (como permisos de IAM o políticas de organización) a todos tus recursos. La jerarquía sigue este orden, de arriba hacia abajo: D. Organization node (Nodo de Organización): Es el nodo raíz de toda la jerarquía. Generalmente representa a tu empresa (ej., miempresa.com). Te da control centralizado sobre todos los recursos que pertenecen a la organización. C. Folders (Carpetas): Son un nivel de agrupación opcional que se sitúa entre la Organización y los Proyectos. Se usan para modelar la estructura de tu empresa, como departamentos (p.ej., "Ingeniería", "Marketing") o entornos (p.ej., "Producción", "Desarrollo"). Las carpetas pueden contener proyectos u otras carpetas. B. Projects (Proyectos): Este es el nivel base obligatorio para todos los recursos. Cualquier recurso que crees (como una máquina virtual, una base de datos o un bucket) debe vivir dentro de un proyecto. Los proyectos son la unidad donde se gestiona la facturación, se habilitan las APIs y se aplican la mayoría de los permisos. Por qué la A es incorrecta A. Buckets (Cubetas): Un Bucket de Cloud Storage no es parte de la jerarquía de organización, sino un recurso individual. Los buckets (junto con las máquinas virtuales, las bases de datos SQL, los temas de Pub/Sub, etc.) son los servicios que viven dentro de un Proyecto. La jerarquía (Organización, Carpetas, Proyectos) es el contenedor; los buckets son el contenido.

Answer 160

C Autoscaling ensures optimal performance and cost by adjusting the number of VM instances according to current traffic.

Answer 161

D Elastic Block Store is an AWS storage service, not part of Google Cloud’s core storage options, which include Cloud Storage, Bigtable, Cloud SQL, Spanner, and Firestore

Answer 162

D Archive Storage is designed for data that is rarely accessed (less than once a year) and offers the lowest cost among the storage classes

Answer 163

A, B y D IAM allows you to define access to resources, policies are inherited downward in the resource hierarchy, and IAM can be used to manage API access. IAM can be accessed via the console, SDK, Cloud Shell, APIs, and the app, so C is incorrect.

Answer 164

C Cloud Run is the managed compute platform for running stateless containers in response to HTTP requests or Pub/Sub events

Answer 165

A The resource hierarchy starts with the organization node at the top, followed by folders, then projects, and finally resources

Answer 166

B Explanation: The scenario describes data that is accessed infrequently ("cool data") but requires immediate availability. Nearline Storage is specifically designed for this use case, offering lower storage costs than Standard Storage with the same low-latency access. Standard Storage would be too expensive for data that is rarely accessed. Archive Storage is even cheaper but has a retrieval delay, which does not meet the "available immediately" requirement. Firestore is a NoSQL document database, not a service for storing backup files.

Answer 167

C Pensemos en ello como si fuera un edificio de una empresa 🏢. Organization (Organización): Es el nodo raíz, el nivel más alto. Representa a toda tu empresa (ej: "MiEmpresa S.L."). Todas las políticas de seguridad y permisos que apliques aquí se heredan hacia abajo. Es el edificio entero. Folder (Carpeta): Son un nivel opcional de agrupación que se encuentra dentro de la Organización. Sirven para separar diferentes departamentos, equipos o entornos (ej: "Departamento de Marketing", "Entorno de Producción"). Puedes anidar carpetas dentro de otras. Son las plantas o departamentos del edificio. Project (Proyecto): Este es el nivel fundamental donde creas, habilitas y utilizas los servicios de Google Cloud. Cada recurso (como una máquina virtual o una base de datos) debe pertenecer a un proyecto. Los proyectos se organizan dentro de carpetas (o directamente bajo la Organización si no usas carpetas). Son las oficinas específicas en cada planta donde se realiza el trabajo. Resource (Recurso): Son los componentes individuales que despliegas dentro de un proyecto. Por ejemplo, una instancia de Compute Engine (una máquina virtual), un bucket de Cloud Storage, una base de datos de Cloud SQL, etc. Son los ordenadores, mesas y sillas que hay dentro de cada oficina.

Answer 168

B y C This is a classic high-availability and scalability problem. Cloud Load Balancing (C) distributes incoming user traffic across multiple virtual machine instances, preventing any single instance from being overwhelmed. Compute Engine's Autoscaling (B) works in conjunction with the load balancer. It automatically adds more virtual machine instances to the group when traffic increases and removes them when traffic decreases, ensuring performance during spikes and saving costs during quiet periods. Cloud Interconnect is for dedicated connections to on-premises networks. VPC Peering is for connecting two VPC networks.

Answer 169

C Google Kubernetes Engine (GKE) is Google's managed Kubernetes service. It provides a production-ready Kubernetes environment while handling the complex and burdensome tasks of managing the control plane, node provisioning, and upgrades. This allows developers to focus on deploying and managing their containerized applications rather than the underlying orchestration infrastructure.

Answer 170

C The key requirements are "stateless container," "fully managed," "serverless," and "pay only when a request is being processed." Cloud Run is designed for exactly this. It runs stateless containers on a serverless platform, automatically scaling up or down (even to zero), so you only pay for the compute you actually use. GKE requires you to manage a cluster, so it is not fully serverless in this context. Compute Engine requires you to provision and manage virtual machines. Cloud SQL is a managed database service, not a compute platform for containers.

Answer 171

D While maximizing data processing speed is important, it should not compromise security. Options A, B, and C are key for ensuring security and compliance.

Answer 172

C Dataflow is designed for both batch and streaming data processing. BigQuery is for querying large datasets, Cloud Storage for object storage, and Dataproc for Apache Spark/Hadoop jobs.

Answer 173

D ¡Claro que sí! Analicemos esta pregunta sobre los servicios de Google Cloud. La respuesta correcta es la D. BigQuery. Aquí te explico por qué BigQuery es la elección adecuada basándonos en los requisitos de la pregunta, y por qué las otras opciones no encajan. Los Requisitos Clave La pregunta nos da tres requisitos muy específicos que debe cumplir la solución: Large dataset (Gran volumen de datos): Debe poder manejar conjuntos de datos muy grandes. Low-latency access (Acceso de baja latencia): Debe responder a las peticiones rápidamente. Complex queries (Consultas complejas): Debe ser capaz de ejecutar consultas que involucren JOINs, agregaciones (GROUP BY), subconsultas, etc. El punto más importante y el que realmente decide la respuesta correcta es la necesidad de "consultas complejas". Por qué D. BigQuery es la respuesta correcta BigQuery es el almacén de datos analítico (enterprise data warehouse) de Google Cloud. Está diseñado específicamente para cumplir con estos tres requisitos en el contexto del análisis de datos. Gran volumen de datos: BigQuery es una plataforma serverless que escala de forma transparente para manejar petabytes de datos sin problemas. Este es su punto fuerte. Consultas complejas: Este es el motivo principal por el que BigQuery es la respuesta correcta. Utiliza un dialecto de SQL estándar y está optimizado para ejecutar análisis increíblemente complejos sobre grandes volúmenes de datos. Es el único servicio de la lista diseñado fundamentalmente para este propósito. Acceso de baja latencia: Aquí hay un matiz importante. En el mundo de las bases de datos, "baja latencia" puede significar dos cosas: Latencia transaccional (milisegundos): Obtener una sola fila muy rápido (ej: el perfil de un usuario). Latencia analítica (segundos a minutos): Obtener el resultado de una consulta compleja sobre terabytes de datos muy rápido. BigQuery ofrece una latencia analítica extremadamente baja. Una consulta que en un sistema tradicional podría tardar horas, en BigQuery puede completarse en segundos o minutos. Dado que el requisito es para "consultas complejas", se infiere que se busca una baja latencia en este contexto analítico, y BigQuery es el líder en ello. Por qué las otras opciones son incorrectas Las otras opciones pueden manejar grandes volúmenes de datos y ofrecer baja latencia, pero todas fallan en el requisito de las "consultas complejas". A. Cloud Storage ¿Qué es? Es un sistema de almacenamiento de objetos. Piensa en él como un disco duro infinito en la nube para guardar archivos (imágenes, vídeos, backups, ficheros CSV, Parquet, etc.). ¿Por qué es incorrecto? No es una base de datos ni tiene un motor de consulta propio. No puedes ejecutar consultas complejas directamente sobre Cloud Storage. Para analizar los datos que viven allí, necesitarías usar otro servicio... ¡como BigQuery! B. Bigtable ¿Qué es? Es una base de datos NoSQL de tipo "wide-column" (columna ancha), diseñada para cargas de trabajo masivas con un rendimiento muy alto y una latencia extremadamente baja (milisegundos). ¿Por qué es incorrecto? Su principal ventaja es también su limitación en este caso: está optimizado para lecturas y escrituras muy simples y rápidas basadas en una clave de fila (row key). No soporta consultas complejas. No puedes hacer JOINs, ni tiene un lenguaje de consulta SQL. Es ideal para series temporales o datos de IoT, pero no para análisis de negocio complejo. C. Firestore ¿Qué es? Es una base de datos NoSQL de documentos, pensada principalmente para el desarrollo de aplicaciones web y móviles (backend). ¿Por qué es incorrecto? Al igual que Bigtable, no está diseñado para consultas analíticas complejas. Aunque su modelo de consulta es más flexible que el de Bigtable, sigue siendo muy limitado en comparación con SQL. No soporta JOINs y no es la herramienta adecuada para ejecutar agregaciones complejas sobre un dataset masivo. Tabla Resumen Servicio Tipo Ideal para... ¿Soporta Consultas Complejas (SQL)? Cloud Storage Almacenamiento de Objetos Guardar archivos (data lake) No Bigtable NoSQL Wide-Column Cargas masivas de lectura/escritura simples (IoT) No Firestore NoSQL Documentos Backends de aplicaciones web/móviles No BigQuery Data Warehouse Analítico Análisis de negocio, BI, consultas complejas (SQL) Sí

Answer 174

B Materialized views in BigQuery store query results for faster visualization. Other options are not specifically for this purpose.

Answer 175

C Cloud Monitoring and Logging are used to monitor and troubleshoot data jobs, not for automation or scheduling, which are handled by other tools.

Answer 176

C The sources explicitly list the four stages as "replicate and migrate, ingest, transform, and store". This sequence describes the journey data takes from external or internal systems into Google Cloud, through processing, and finally to its destination for use.

Answer 177

C The sources state that unstructured data, such as documents, images, and audio files, is "usually suited for Cloud Storage" and that Cloud Storage is an "ideal solution for... any unstructured data". While BigQuery offers some capability for unstructured data via object tables, Cloud Storage is presented as the primary destination for this data type.

Answer 178

B The sources describe Spanner as Google Cloud’s "fully managed relational database service that offers both strong consistency and horizontal scalability". Cloud SQL and AlloyDB are mentioned as managed relational databases, but Spanner is highlighted for global scalability and strong consistency across regions. Firestore is a NoSQL database

Answer 179

B The sources define a Data Lake as a repository for "raw, unprocessed data in various formats, including unstructured, semi-structured, and structured". A Data Warehouse, conversely, is described as a structured repository for "pre-processed and aggregated data from multiple sources". Option A incorrectly reverses the data formats. Option C incorrectly maps the services (Data Lake often uses Cloud Storage, Data Warehouse is BigQuery). Option D incorrectly assigns the primary use cases based on the source descriptions

Answer 180

D The sources explicitly state that "Analytics Hub was created to meet these data sharing challenges," particularly "sharing data outside your organization". It helps organizations share datasets by "publishing and subscribing to analytics-ready datasets". Dataplex is for data management and governance, including discovery within an organization, BigQuery is a data warehouse, and Cloud Storage is for data storage

Answer 181

C The primary role of a data engineer is to build pipelines that move and transform data so it can be used in dashboards, reports, or ML models to support business decisions.

Answer 182

B, C y D The course mentions three common transformation patterns: ELT, ETL, and EL. "ET" is not a valid standalone pattern.

Answer 183

C Cloud Storage is optimized for storing unstructured data such as documents, images, and audio, and supports storage classes for different access needs.

Answer 184

A, C y D Herramientas Correctas para Replicar y Migrar Estas herramientas están diseñadas específicamente para mover datos de un lugar a otro. A) Datastream - ✅ Correcta Es un servicio de replicación de datos en tiempo real y captura de datos de cambios (CDC - Change Data Capture). Su función principal es leer los cambios de una base de datos de origen (como Oracle o MySQL) y replicarlos continuamente en un destino de Google Cloud (como BigQuery o Cloud Storage) con una latencia muy baja. Es ideal para migraciones con mínimo tiempo de inactividad y para mantener sistemas sincronizados. C) Transfer Appliance - ✅ Correcta Es una solución de migración de datos offline. Es literalmente un dispositivo físico que Google te envía. Lo conectas a tu red local, cargas grandes cantidades de datos (cientos de terabytes o petabytes) y luego se lo envías de vuelta a Google para que ellos lo suban a Cloud Storage. Se usa cuando transferir los datos por internet tardaría demasiado tiempo o sería demasiado costoso. D) Storage Transfer Service - ✅ Correcta Es un servicio gestionado para la transferencia de datos en línea a gran escala hacia Cloud Storage. Es perfecto para mover datos desde otras nubes (como Amazon S3), desde servidores on-premise, o entre diferentes buckets de Cloud Storage. Permite programar transferencias periódicas para mantener los datos sincronizados. Por qué Cloud SQL es incorrecta B) Cloud SQL - ❌ Incorrecta Cloud SQL no es una herramienta de migración, sino un destino para la migración. Es un servicio de base de datos relacional totalmente gestionado (para MySQL, PostgreSQL y SQL Server). Piénsalo de esta manera: si estás haciendo una mudanza, Transfer Appliance es el camión de mudanzas y Cloud SQL es la casa nueva a la que llevas tus cosas. Usarías Datastream o Storage Transfer Service para mover tus datos hacia una base de datos en Cloud SQL, pero Cloud SQL en sí mismo no realiza la acción de transferir.

Answer 185

B BigQuery allows fine-grained security control at the dataset, table, column, and row levels through IAM roles and policies.

Answer 186

B The primary role of a data engineer is to build data pipelines that move, transform, and store data so it can be used for decision-making, reporting, or machine learning

Answer 187

C Cloud Storage is designed for storing unstructured data like documents, images, and audio files, and supports objects up to 5 TB in size

Answer 188

A, B y C The three main transformation patterns in data pipelines are EL, ELT, and ETL. LTE is not a recognized pattern.

Answer 189

B Data lakes are designed for storing raw, unprocessed data in multiple formats, whereas data warehouses store structured, pre-processed data optimized for analysis

Answer 190

B Dataplex is a comprehensive solution for discovering, managing, monitoring, and governing distributed data, offering unified metadata and governance capabilities

Answer 191

B As shown on slide 6, the data engineering pipeline is presented as a four-stage process. The first step is to get the data into Google Cloud ("Replicate and migrate"). Then, the raw data is made available in a data source ("Ingest"). Next, the data is processed ("Transform"), and finally, the processed data is saved in a data sink ("Store").

Answer 192

B Slide 17 explicitly defines a Data Lake as a repository for storing raw, unprocessed data in various native formats (unstructured, semi-structured, structured). It is used for data science, applications, and business decisions. The slide also maps the Data Lake concept directly to the Google Cloud Storage service.

Answer 193

D Slide 16 outlines the options for storing structured data. For a transactional workload requiring a SQL database with "Global scalability," the chart points directly to Spanner. Spanner is designed to be a globally distributed relational database service that offers both strong consistency and horizontal scalability.

Answer 194

C Slide 24 describes Dataplex as a solution to "Centrally discover, manage, monitor, and govern distributed data." It highlights features like unified metadata, data quality, data classification, and unified governance across various storage systems, which directly addresses the requirements in the question.

Answer 195

B As detailed on slides 27 and 28, Analytics Hub is specifically designed to solve the challenges of sharing data across organizations. It allows a publisher to create listings for their datasets, which subscribers can then access in their own projects. This is done without copying the data, providing a secure, manageable, and auditable way to share data.

Answer 196

B Data engineers focus on building and maintaining data pipelines that handle the ingestion of raw data, its transformation into a usable format, and its storage for analysis or machine learning, enabling data-driven decision-making.

Answer 197

C A data lake, such as Cloud Storage, stores raw, unprocessed data (unstructured, semi-structured, or structured) for flexible use cases like data science. A data warehouse, like BigQuery, contains curated, transformed data optimized for long-term business analysis and reporting.

Answer 198

B Dataplex is a Google Cloud service that provides centralized metadata management, enabling discovery, monitoring, and governance of distributed data across various storage systems, with features like unified metadata and auto-discovery.

Answer 199

B Analytics Hub simplifies the process of sharing datasets by allowing organizations to list, subscribe to, and exchange data securely, addressing challenges like security, permissions, and data freshness. Explicación: Analytics Hub es una plataforma de intercambio de datos construida sobre Google BigQuery. Permite a las organizaciones publicar, descubrir y compartir conjuntos de datos de forma segura, tanto internamente como con otras organizaciones. Facilita la colaboración en datos sin necesidad de copiar o mover la información, manteniendo el control y la seguridad. Por qué las otras opciones no son correctas: A. Proporcionar análisis en tiempo real sobre datos en streaming → Esto corresponde más a servicios como Dataflow, Pub/Sub o las capacidades de streaming de BigQuery. C. Gestionar y monitorear modelos de aprendizaje automático → Esto lo manejan plataformas como Vertex AI. D. Almacenar y procesar grandes volúmenes de datos de series temporales → Normalmente se hace con Bigtable, BigQuery u otras bases de datos especializadas.

Answer 200

B Structured data is typically organized in a tabular format with rows and columns, making it suitable for storage in relational databases or data warehouses like BigQuery, allowing for efficient querying and analysis.

Answer 201

C Transfer Appliance For very large datasets and scenarios with limited bandwidth, the sources recommend using Transfer Appliance for offline transfer. While Storage Transfer Service handles large datasets online, Transfer Appliance is highlighted for "Large transfers with limited bandwidth" and moving "massive datasets offline". The gcloud storage command is suitable for "small to medium-sized transfers". Datastream is for continuous replication of structured data, specifically RDBMS

Answer 202

C To enable continuous, online replication of Relational Database Management Systems (RDBMS) for analytics. Datastream is specifically described as enabling "continuous replication of your on-premises or multicloud relational databases such as Oracle, MySQL, PostgreSQL, or SQL Server into Google Cloud". Its purpose includes landing data in Cloud Storage or BigQuery for analytics. Options a and b describe Transfer Appliance and gcloud storage/Storage Transfer Service, respectively. Option d mentions Database Migration Service and Dataflow for workload migration, which is separate from Datastream's primary function of continuous RDBMS replication. Datastream is also noted for its "Batch and Stream" velocity

Answer 203

A, B y C ✅ Respuestas Correctas: a, b, c a) On-premises file systems (Sistemas de archivos locales): Es una de las funciones principales del servicio. Para ello, instalas un pequeño software llamado "agente de transferencia" en tus propios servidores. Este agente se encarga de leer los datos de tus sistemas de archivos (como NFS o carpetas compartidas en Windows/Linux) y los envía de forma segura y eficiente a Cloud Storage. b) Amazon S3 object stores: Es el caso de uso más común. Muchas empresas migran sus datos desde AWS a Google Cloud. Storage Transfer Service se conecta directamente a los buckets de S3 (usando las credenciales que le proporciones) para copiar los objetos. c) Azure Blob Storage object stores: Al igual que con S3, el servicio también soporta la migración directa desde el almacenamiento de Microsoft Azure. Se conecta a la cuenta de Azure Storage y transfiere los blobs. En resumen, las opciones a, b y c representan los tres tipos de orígenes principales para los que se diseñó Storage Transfer Service: sistemas locales, y los dos mayores proveedores de almacenamiento en la nube. ❌ Respuesta Incorrecta: d d) HDFS (Hadoop Distributed File System): Storage Transfer Service no soporta HDFS directamente como origen de datos. Aunque es técnicamente posible mover datos desde HDFS a Cloud Storage, la herramienta recomendada y nativa para esta tarea no es Storage Transfer Service. Para mover datos desde un clúster de Hadoop, la herramienta estándar es hadoop distcp (Distributed Copy), que está optimizada para transferir grandes volúmenes de datos entre sistemas de archivos compatibles con Hadoop, incluido Cloud Storage.

Answer 204

D The comparison table explicitly lists the transfer type for each tool. gcloud storage is "Batch", Storage Transfer Service is "Batch (hourly at minimum)", Transfer Appliance is "Batch", and Datastream is "Batch and Stream"

Answer 205

D ¿Por qué la "d) Transaction logs" es la correcta? Google Cloud Datastream, cuando se conecta a SQL Server, se basa fundamentalmente en la lectura de los registros de transacciones (Transaction Logs). Para que Datastream pueda capturar los cambios (CDC - Change Data Capture), SQL Server debe tener habilitada la función de MS-CDC (Microsoft Change Data Capture) o la Replicación Transaccional. Ambas tecnologías funcionan escaneando el Transaction Log activo de la base de datos. El mecanismo: SQL Server registra cada operación (INSERT, UPDATE, DELETE) en su archivo de registro de transacciones (generalmente con extensión .ldf) antes de confirmarla en la base de datos. La captura: Datastream aprovecha este comportamiento. No lee las tablas directamente todo el tiempo (lo cual sería lento), sino que lee este registro secuencial para saber qué cambió exactamente y cuándo. Nota clave: Aunque técnicamente Datastream usa la función llamada CDC, el mecanismo de registro subyacente que contiene la información es el Transaction Log. ¿Por qué las otras opciones son incorrectas? El resto de las opciones son mecanismos de registro reales y válidos, pero pertenecen a otros motores de base de datos. En el mundo de las bases de datos, cada fabricante tiene su propio nombre para el "diario" donde anota los cambios. Aquí te explico a quién pertenece cada uno: a) LogMiner: ❌ Incorrecta para SQL Server. Pertenece a: Oracle Database. Explicación: LogMiner es una utilidad específica de Oracle que permite consultar los Redo Logs archivados y online a través de sentencias SQL. Datastream usa LogMiner (o BFILE) cuando la fuente es Oracle. b) Binary log: ❌ Incorrecta para SQL Server. Pertenece a: MySQL. Explicación: En MySQL, el registro de cambios se conoce comúnmente como "binlog" (Binary Log). Es el archivo que contiene los eventos que describen los cambios en los datos. c) Logical decoding: ❌ Incorrecta para SQL Server. Pertenece a: PostgreSQL. Explicación: PostgreSQL utiliza un mecanismo llamado Write-Ahead Logging (WAL), pero para exponer esos datos a sistemas externos (como Datastream), utiliza un proceso llamado "decodificación lógica" (Logical Decoding) a través de Replication Slots.

Answer 206

D ✅ La Herramienta Correcta: gcloud storage command (D) Para transferir conjuntos de datos pequeños desde un sistema local (on-premises) a Google Cloud Storage, el comando gcloud storage es la herramienta más simple, directa y eficiente. gcloud storage es parte de la interfaz de línea de comandos (CLI) de Google Cloud. Funciona de manera muy similar a los comandos cp (copiar) o rsync (sincronizar) que usarías en un terminal de Linux. Con un simple comando, puedes subir, bajar o sincronizar archivos y carpetas. Ejemplo: Para copiar un solo archivo gcloud storage cp mi_archivo_local.csv gs://mi-bucket/ Para sincronizar un directorio completo gcloud storage rsync mi_directorio_local/ gs://mi-bucket/mi_directorio/ Es la solución perfecta para transferencias rápidas y puntuales sin la necesidad de configurar un servicio más complejo. 💻 ❌ Por Qué las Otras Opciones No Son las Mejores Las otras herramientas están diseñadas para escenarios mucho más complejos o a mayor escala, lo que las hace inadecuadas para "datasets pequeños". A) Datastream: Este servicio no es para transferir archivos. Su función es replicar bases de datos en tiempo real (Change Data Capture) desde un origen (como MySQL u Oracle) a un destino en Google Cloud. B) Storage Transfer Service: Es un servicio gestionado para orquestar transferencias de datos a gran escala (generalmente terabytes o petabytes). Usarlo para un dataset pequeño sería excesivo, como usar un camión de mudanzas para mover una caja de zapatos. 🚚 C) Transfer Appliance: Esta es una solución física. Google te envía un servidor (un "appliance") a tu centro de datos, lo llenas con enormes cantidades de datos (cientos de terabytes o petabytes) y lo envías de vuelta. Solo se usa cuando la transferencia por red no es viable debido al volumen masivo de datos.

Answer 207

B Datastream is designed for continuous (streaming) and batch replication of structured data using change data capture (CDC) from databases like Oracle, MySQL, PostgreSQL, and SQL Server.

Answer 208

C Transfer Appliance is a physical device ideal for offline bulk transfers in environments with limited bandwidth.

Answer 209

B y D Datastream can capture both historical data and ongoing changes (CDC), and it allows fine-grained control over what is replicated.

Answer 210

B y D ✅ Opción B: Supports scheduled transfers from AWS S3 and Azure Blob Esta es una de las funciones clave del servicio. El Storage Transfer Service (STS) está diseñado específicamente para facilitar la migración de grandes volúmenes de datos desde otras fuentes a Google Cloud Storage. Fuentes Externas: Sus principales conectores son para otras nubes públicas como Amazon Web Services (AWS) S3 y Microsoft Azure Blob Storage. Programación (Scheduled): No solo permite hacer una transferencia única, sino que también puedes programarla para que se ejecute periódicamente (por ejemplo, cada día a las 3 AM). Esto es muy útil para tareas de respaldo, sincronización o para migrar datos en fases. En resumen, es una herramienta fundamental para mover datos hacia Google Cloud desde otras plataformas de manera planificada. ✅ Opción D: Scales up to tens of Gbps for large datasets Esta es su mayor ventaja técnica. Cuando transfieres terabytes o petabytes de datos, la velocidad es crucial. Gestionado por Google: STS es un servicio totalmente gestionado. Esto significa que no tienes que preocuparte por la infraestructura subyacente (servidores, redes, etc.). Escalabilidad Automática: Google escala automáticamente los recursos necesarios para maximizar el ancho de banda y la velocidad de la transferencia. El servicio divide los datos en partes más pequeñas y las transfiere en paralelo, optimizando el proceso para alcanzar velocidades muy altas, que pueden llegar a las decenas de Gigabits por segundo (Gbps), dependiendo de la conexión de origen. ❌ Opción A: Requires physical hardware to be shipped Esto es incorrecto porque describe un servicio diferente. Aunque relacionado, el servicio que implica enviar hardware físico se llama Transfer Appliance. Storage Transfer Service (STS): Es un servicio online. Se ejecuta completamente en la nube para transferir datos a través de la red. Transfer Appliance: Es una solución offline/híbrida. Google te envía un servidor físico (un "appliance") que conectas en tu centro de datos. Cargas tus datos en él y luego se lo envías de vuelta a Google para que ellos los suban a la nube. Se usa cuando la conexión a internet es demasiado lenta o inestable para una transferencia online masiva. ❌ Opción C: Optimized for real-time data streams Esto es conceptualmente lo opuesto al propósito de STS. STS (Batch/Lotes): Está diseñado para transferencias masivas y programadas. Su objetivo es mover grandes conjuntos de datos que ya existen (ficheros, objetos, etc.). Es un proceso "por lotes" (batch). Streaming (Tiempo Real): Para flujos continuos de datos que se generan y procesan en tiempo real (por ejemplo, datos de sensores, logs de aplicaciones, clics en una web), Google Cloud ofrece otros servicios especializados como Pub/Sub o Dataflow.

Answer 211

C Transfer Appliance is a Google-owned hardware solution designed for large, offline data migrations. It is ideal when transferring massive datasets and network bandwidth is limited

Answer 212

A y C Datastream is used for continuous, real-time replication of relational databases and supports change data capture for analytics. It is not used for one-off file transfers or large offline migrations

Answer 213

B El Storage Transfer Service (STS) de Google Cloud está diseñado para mover grandes volúmenes de datos desde otras ubicaciones, como Amazon S3, de forma automática, programada y eficiente. Es ideal cuando necesitas hacer migraciones periódicas, configurar tareas recurrentes o mover cantidades masivas de información con control de errores y de ancho de banda. 📌 Las otras opciones, explicadas: A) Para transferencias pequeñas y puntuales de menos de 1 TB: Para esto, es mejor usar el comando gcloud storage, que es más simple y directo para tareas rápidas. C) Para transferencias sin conexión de red: En este caso, no usarías STS ni gcloud. Lo apropiado sería el Transfer Appliance, un dispositivo físico que se envía para cargar los datos y luego se traslada a Google Cloud. D) Para replicación continua de tablas de bases de datos: No es el propósito de STS. Aquí lo recomendable sería una herramienta como Datastream, especializada en replicar datos estructurados como los de bases de datos.

Answer 214

B Datastream captures inserts, updates, and deletes by reading the write-ahead log or equivalent mechanism of the source database, enabling near real-time replication

Answer 215

C The gcloud storage command is best for small, ad-hoc, online transfers from on-premises sources to Cloud Storage

Answer 216

C Transfer Appliance is Google's solution for large-scale, offline data transfers. For scenarios with massive amounts of data (like 500 TB) and limited network bandwidth, a physical appliance is shipped to the data center, data is loaded onto it, and it's shipped back to Google to be uploaded to Cloud Storage. This avoids congesting or relying on a slow network connection.

Answer 217

C Datastream is Google Cloud's serverless Change Data Capture (CDC) and replication service. It is designed to read from source database transaction logs (like PostgreSQL's logical decoding) to continuously replicate data changes to destinations like BigQuery, Cloud Storage, or Cloud Spanner, making it perfect for real-time analytics scenarios. While DMS also performs migrations, Datastream is the purpose-built service for continuous replication for analytics.

Answer 218

B y D B is correct: The gcloud storage command is a versatile command-line tool, perfect for smaller, one-off transfers or for integration into custom scripts where a full managed service is not required. D is correct: Storage Transfer Service is the managed solution for large online transfers. It offers features like scheduling, manifest files, and direct integration with sources like Amazon S3, Azure Blob Storage, and HDFS, making it suitable for recurring, large-scale data movement. A is incorrect because Transfer Appliance is an offline service. C is incorrect because Datastream is for structured data from relational databases, not files from HDFS.

Answer 219

B Datastream event messages are split into generic metadata, source-specific metadata, and the payload. The read_timestamp (the time when Datastream read the event) is part of the generic metadata applicable to any source. In contrast, row_id, scn, and change_type are specific to the source database system (in this case, Oracle), providing deeper context about the change within that source, and are therefore part of the source_metadata.

Answer 220

C Storage Transfer Service is the most suitable option. It is a fully managed service designed for large-scale (2 TB fits this description), scheduled transfers between cloud storage providers, including Amazon S3 and Google Cloud Storage. It handles the scheduling, retries, and scalability automatically. A custom script (D) would require more management, Datastream (B) is for databases, and Transfer Appliance (A) is for offline transfers and is overkill for this online scenario.

Answer 221

B Por qué la opción B es la correcta ✅ Storage Transfer Service es una herramienta diseñada específicamente para orquestar y gestionar transferencias de datos a gran escala hacia Google Cloud Storage desde diversas fuentes, incluyendo sistemas de archivos locales (on-premises). Para una migración de 500 GB, es la opción ideal por estas razones: Gestionado y Robusto: Es un servicio totalmente gestionado. Tú configuras el "trabajo" de transferencia y Google se encarga de optimizarlo, reintentar en caso de fallos y verificar la integridad de los datos. Optimizado para la Red: Utiliza el ancho de banda de manera eficiente y puede realizar transferencias en paralelo para maximizar la velocidad. Funcionalidades Avanzadas: Permite programar transferencias, filtrar archivos y sincronizar directorios, lo que es muy útil para migraciones complejas. En resumen, para una cantidad de datos como 500 GB, que es considerable pero manejable a través de una buena conexión a internet, Storage Transfer Service ofrece la combinación perfecta de rendimiento, fiabilidad y facilidad de uso. Por qué las otras opciones son incorrectas ❌ A. gcloud command line tool: Aunque puedes usar el comando gcloud storage cp (o gsutil cp) para copiar archivos a Cloud Storage, no es la mejor herramienta para una transferencia tan grande. Una migración de 500 GB podría tardar muchas horas o incluso días. Si la conexión se interrumpe o tu máquina local se reinicia, el proceso puede fallar y es más difícil de reanudar de forma fiable en comparación con el servicio gestionado. Es viable para archivos pequeños, no ideal para 500 GB. C. Transfer Appliance: Esta es una solución para migraciones a una escala mucho, mucho mayor, típicamente de cientos de terabytes o petabytes. Consiste en un servidor físico (un "appliance") que Google te envía, tú cargas los datos directamente en él y se lo envías de vuelta para que lo suban a la nube. Usar esto para 500 GB sería como contratar un camión de mudanzas para mover una sola silla. Es una solución desproporcionada (overkill) para esta cantidad de datos. D. Datastream: Esta herramienta tiene un propósito completamente diferente. Datastream se utiliza para la replicación de bases de datos y la captura de datos de cambio (CDC) en tiempo real. Su función es capturar cambios en bases de datos (como Oracle o MySQL) y transmitirlos a servicios en Google Cloud como BigQuery o Cloud Spanner. No está diseñado para migrar archivos de un sistema de ficheros. Es la herramienta incorrecta para el tipo de datos del problema.

Answer 222

D Datastream is designed for continuous, online replication of structured data from relational databases like MySQL to Google Cloud services such as BigQuery, using change data capture for real-time updates.

Answer 223

B Transfer Appliance is ideal for massive offline data migrations, physically transporting data to Google Cloud to bypass network limitations, making it suitable for very large datasets.

Answer 224

C Datastream supports both batch and streaming transfers, not just batch, and uses CDC for real-time replication, making this statement incorrect.

Answer 225

B The key factor is data size; gcloud is for less than 1 TB, while Storage Transfer Service is for larger datasets (more than 1 TB), influencing the choice based on volume.

Answer 226

C Source explicitly states that the extract and load data pipeline pattern "focuses on the tools and options to bring data into BigQuery by eliminating the need for upfront transformation." Source also mentions it "greatly simplifies data ingestion into BigQuery" and "eliminates the need for data copying

Answer 227

D Source states that external tables skip BigQuery storage but receive low performance, while BigLake tables skip BigQuery storage and receive high performance with no data movement required. Sources and specifically mention that BigLake queries are performant due to metadata caching, while source notes that querying external tables may have limitations like slower performance.

Answer 228

D Source states that the BigQuery Data Transfer Service is a "managed and serverless solution" and provides "scheduling options for recurring or on-demand transfers" from "diverse sources, like SaaS applications, object stores, and other data warehouses". It also notes its "no-code approach".

Answer 229

B explains that external tables require the user to have separate permissions for the table and the underlying data source, leading to complex access management. Source contrasts this by stating BigLake tables delegate access using a service account, decoupling table and data source access, which simplifies permission management and enhances security.

Answer 230

B explains that the BigLake metadata cache stores details about external data, such as file size, row count, and column statistics for files in Cloud Storage. It adds that this cache allows querying to "skip listing all objects, prune files, and partitions faster, and enable dynamic predicate pushdown, resulting in improved query performance." Esta es la respuesta correcta porque describe exactamente la función de la caché. Qué almacena: La caché no guarda una copia de tus datos. En su lugar, guarda información sobre tus archivos de datos: su ubicación, tamaño, número de filas y, lo más importante, estadísticas a nivel de columna (como los valores mínimos y máximos de cada columna dentro de un archivo). Cómo mejora el rendimiento (Descarte o "Pruning"): Imagina que tienes una consulta con un filtro como WHERE fecha = '2025-07-17'. En lugar de tener que abrir cada archivo en tu data lake para ver qué fechas contiene, BigQuery primero consulta su caché de metadatos. Si la caché indica que un archivo (archivo_1.parquet) solo contiene fechas del año 2024, BigQuery sabe que puede ignorar o "descartar" completamente ese archivo sin siquiera leerlo. Este proceso, llamado descarte de archivos/particiones, reduce drásticamente la cantidad de datos que se deben escanear, acelerando enormemente la consulta. Por qué las otras opciones son incorrectas A) Almacena copias de los datos externos reales...: Incorrecto. La caché de metadatos de BigLake almacena información sobre los datos, no los datos en sí. Confunde una caché de metadatos con una caché de datos. C) Almacena en caché los resultados de consultas anteriores...: Incorrecto. Esto describe la caché de resultados de consulta de BigQuery, que es una función diferente y general. La caché de metadatos de BigLake acelera las consultas al optimizar la lectura de datos de origen, no al devolver un resultado antiguo. D) Almacena solo la información del esquema...: Incorrecto. Almacena mucho más que solo el esquema. El valor real proviene de las estadísticas de archivo y de columna, que son precisamente las que permiten evitar un escaneo completo de los datos externos.

Answer 231

A, B, C y D Por qué todas las opciones son correctas BigQuery es una plataforma muy flexible y ofrece distintas herramientas para cargar datos, cada una adaptada a una necesidad diferente. A. Usando la interfaz web de BigQuery (UI) Esta es la forma más directa y visual. Desde la consola de Google Cloud, puedes seleccionar una tabla y usar la opción "Cargar datos" para subir archivos directamente desde tu ordenador o desde Google Cloud Storage (GCS). Es ideal para cargas puntuales, pruebas o para usuarios que prefieren una interfaz gráfica. 💻 B. Usando la herramienta de línea de comandos bq load bq es la herramienta de línea de comandos (CLI) de BigQuery. El comando bq load está diseñado específicamente para cargar datos desde un archivo (local o en GCS) a una tabla de BigQuery. Es el método preferido para automatizar procesos y para desarrolladores que trabajan desde la terminal o integran la carga de datos en scripts. ⚙️ C. Usando el Servicio de Transferencia de Datos de BigQuery (DTS) El BigQuery Data Transfer Service (DTS) es una solución totalmente gestionada para automatizar la carga de datos de forma periódica y programada. No es para cargar un archivo una sola vez, sino para configurar pipelines que importen datos regularmente desde otras aplicaciones de Google (como Google Ads, YouTube, Google Play) o desde fuentes externas como Amazon S3 o Teradata. 🔄 D. Usando la sentencia SQL LOAD DATA Esta es una forma más moderna y muy potente que permite cargar datos directamente usando una consulta SQL. La sintaxis LOAD DATA [INTO | OVERWRITE] nombre_tabla FROM FILES (...) te permite ejecutar un trabajo de carga desde Google Cloud Storage como si fuera una instrucción SQL más. Esto es extremadamente útil para orquestar flujos de trabajo de ETL (Extracción, Transformación y Carga) directamente en SQL, combinando la carga y la transformación en un solo script. 📄 Resumen En definitiva, todas las opciones son correctas porque BigQuery proporciona un abanico de herramientas para cubrir diferentes casos de uso: A (UI): Para cargas manuales y sencillas. B (bq CLI): Para automatización y scripting. C (DTS): Para transferencias programadas y recurrentes desde otras plataformas. D (LOAD DATA): Para integrar la carga de datos dentro de flujos de trabajo SQL.

Answer 232

B The extract and load pattern allows data to be ingested into BigQuery without the need for transformation before loading, simplifying and speeding up the data ingestion process

Answer 233

A, B y C BigQuery supports loading data from Avro, Parquet, ORC, CSV, JSON, and Firestore export formats. XML is not natively supported.

Answer 234

C Por qué la opción C es la correcta ✅ La opción C: "Las tablas BigLake utilizan una cuenta de servicio para la delegación de acceso" describe la diferencia fundamental y más importante entre ambos tipos de tablas. Este mecanismo se llama delegación de acceso (access delegation) y es el superpoder de BigLake. Funciona así: Tablas Externas (el método antiguo): Para que un usuario pueda consultar una tabla externa, necesita dos permisos: uno sobre la tabla en BigQuery y otro permiso directo sobre los archivos en el lago de datos (ej: Google Cloud Storage). Esto es difícil de gestionar y poco seguro. Tablas BigLake (el método nuevo): El usuario solo necesita permiso sobre la tabla en BigQuery. BigQuery, a su vez, utiliza una cuenta de servicio (service account) preconfigurada a través de un recurso llamado "conexión" para acceder a los archivos en el lago de datos en nombre del usuario. Piénsalo como un bibliotecario. En el modelo antiguo (tabla externa), para leer un libro de una sección restringida (el lago de datos), necesitabas permiso del bibliotecario (BigQuery) Y tu propia llave de esa sección. En el modelo nuevo (BigLake), solo necesitas el permiso del bibliotecario; él tiene la única llave y te trae el libro. Esta delegación permite centralizar el control de acceso y aplicar políticas de seguridad detalladas (a nivel de fila y columna) directamente en BigQuery, sin importar dónde estén los datos físicamente. Por qué las otras opciones son incorrectas ❌ A) Las tablas BigLake requieren que los usuarios tengan acceso directo a la fuente de datos subyacente. Esto es incorrecto. Es exactamente lo contrario. Esta afirmación describe cómo funcionan las tablas externas tradicionales. El principal beneficio de BigLake es precisamente eliminar este requisito. B) Las tablas externas proporcionan controles de seguridad detallados (fine-grained). Esto es incorrecto. Las tablas externas ofrecen una seguridad muy básica (o tienes acceso a todos los archivos o no tienes acceso a ninguno). Son las tablas BigLake las que introducen la capacidad de aplicar controles de seguridad detallados, como a nivel de fila y columna, sobre datos externos. D) Las tablas externas admiten el almacenamiento en caché de metadatos. Esto es incorrecto. El almacenamiento en caché de metadatos (metadata caching) es una de las optimizaciones de rendimiento que ofrecen las tablas BigLake para acelerar las consultas sobre lagos de datos, especialmente cuando hay muchos archivos pequeños. Las tablas externas tradicionales no tienen esta capacidad.

Answer 235

C When querying Google Sheets data via external tables in BigQuery, performance is slower compared to permanent tables, and features like query cost estimation and query caching are not available

Answer 236

C BigLake tables are the ideal solution for this scenario. They allow you to query data in Cloud Storage without moving or copying it, thus satisfying the policy restriction. Critically, as shown on slides 13 and 17, BigLake uses metadata caching to deliver high query performance, which is a significant improvement over the lower performance of standard External tables. Options A and D both involve copying data into BigQuery's managed storage, violating the policy.

Answer 237

C ¿Por qué la C (BigLake tables) es la respuesta correcta? ✅ Las BigLake tables son una evolución de las tablas externas y están diseñadas específicamente para resolver este problema: desacoplar los permisos de la tabla en BigQuery de los permisos de los datos de origen en Cloud Storage. Funciona de la siguiente manera: Creas una Conexión de Recurso (Resource Connection): Piensa en esto como una "llave" especial que BigQuery usará. Esta conexión tiene asociada una cuenta de servicio (service account). Otorgas Permisos a la Conexión: Le das permiso a la cuenta de servicio de la conexión para que pueda leer los archivos en el bucket de Cloud Storage (el permiso storage.objects.get). Otorgas Permisos al Usuario: Le das permiso al grupo de usuarios para que pueda consultar la tabla BigLake en BigQuery. El resultado: Cuando un usuario hace una consulta a la tabla BigLake, BigQuery utiliza su "llave" (la conexión) para ir a Cloud Storage y leer los archivos en nombre del usuario. El usuario final nunca necesita tener permisos directos sobre el bucket de Cloud Storage. Esto cumple perfectamente con el requisito de seguridad: los usuarios consultan los datos a través de BigQuery, pero no pueden ir al bucket y descargar los archivos directamente. 🧐 ¿Por qué las otras opciones son incorrectas? ❌ A. Standard External tables (Tablas Externas Estándar): Esta es la forma "antigua" de hacerlo, y es precisamente el problema que BigLake viene a solucionar. Con una tabla externa estándar, el usuario que realiza la consulta necesita dos permisos: uno para consultar la tabla en BigQuery y otro permiso directo (storage.objects.get) sobre los archivos en Cloud Storage. Esto es exactamente lo contrario de lo que pide el requisito de seguridad. B. IAM conditions on the Cloud Storage bucket (Condiciones IAM en el bucket): Las condiciones IAM son muy potentes para dar permisos granulares (por ejemplo, "permitir el acceso solo desde esta IP"), pero no resuelven el problema fundamental de desacoplamiento. El usuario todavía necesitaría tener un rol con permisos sobre el bucket, aunque fuera condicional. El objetivo es que el usuario no tenga ningún permiso sobre el bucket. D. BigQuery authorized views (Vistas Autorizadas de BigQuery): Las vistas autorizadas resuelven un problema de desacoplamiento, pero a un nivel diferente. Permiten que un usuario consulte una vista sin tener permisos sobre las tablas base de BigQuery subyacentes. El problema aquí no es el acceso a una tabla base de BigQuery, sino el acceso a los archivos de origen en Cloud Storage. Por lo tanto, no es la herramienta adecuada para este caso.

Answer 238

C ¿Por qué la C es la respuesta correcta? ✅ Esta opción es la combinación perfecta para resolver el problema de forma directa y eficiente desde un script: El comando bq load: Este es el comando de la herramienta de línea de comandos bq diseñado específicamente para cargar datos desde una fuente (como Cloud Storage) a una tabla de BigQuery. Es la herramienta estándar para este tipo de automatización. Puede tanto crear una tabla nueva como, en este caso, añadir datos a una tabla ya existente. El flag --skip_leading_rows=2: Este argumento le dice explícitamente al comando bq load que ignore un número determinado de filas al principio del fichero de origen. Como el problema dice que hay una cabecera de dos líneas con metadatos, usar el valor 2 es exactamente lo que se necesita para no cargar esa información en la tabla. 🎯 Por tanto, el comando completo en el script se vería algo así: bq load --source_format=CSV --skip_leading_rows=2 my_dataset.my_table gs://my-bucket/new_file.csv ¿Por qué las otras opciones son incorrectas? ❌ A. bq mk --table with the --source_format=CSV flag: El comando bq mk se usa para crear (del inglés make) nuevos recursos, en este caso, una tabla. El enunciado dice claramente que se deben cargar los datos en una tabla existente, por lo que crear una nueva cada día es incorrecto. B. LOAD DATA SQL statement with the skip_leading_rows=2 option: Aunque la sentencia SQL LOAD DATA sí sirve para cargar datos y tiene la opción skip_leading_rows, el problema pregunta por el comando y el flag a usar en un script. La opción C (bq load) es el comando de línea de comandos directo y más idiomático para esta tarea, mientras que LOAD DATA es una sentencia SQL que tendrías que ejecutar a través de otro comando (como bq query). bq load es la herramienta más específica y adecuada. D. bq query command with the --destination_table flag: El comando bq query se usa para ejecutar consultas SQL. Aunque técnicamente podrías leer los datos de Cloud Storage (definiendo una tabla externa primero) y usar --destination_table para guardar el resultado, es una forma innecesariamente compleja y menos eficiente de hacer una simple carga de datos. El comando bq load está optimizado para justamente esa tarea.

Answer 239

C The BigQuery Data Transfer Service (DTS), as detailed on slide 10, is a fully managed, serverless, and no-code solution designed to automate data movement into BigQuery from SaaS applications (like Salesforce, Google Ads), Google Cloud services, and other data warehouses. This perfectly matches the marketing team's requirements for an automated, easy-to-use service.

Answer 240

A y C As summarized on the comparison slide (page 20), BigLake tables offer two major advantages over standard External tables: Security (A): BigLake supports fine-grained security controls, including column-level security and data masking, which are not available for standard external tables. Performance (C): BigLake leverages a metadata cache (slide 17) that stores information about the external files. This enables performance optimizations like partition and file pruning, resulting in significantly faster queries than standard external tables. Option B is a feature of standard External tables, not a unique advantage of BigLake. Option D is incorrect; BigLake tables require a connection resource to delegate access.

Answer 241

B The document (Page 4) explicitly states that the extract and load pattern simplifies data ingestion into BigQuery by eliminating the need for upfront transformation, using tools like bq load and Data Transfer Service to directly load data from various sources.

Answer 242

B The document (Page 8) describes the bq command line tool as a way to interact with BigQuery, including creating datasets (e.g., bq mk --location:US -dataset dataset-name) and loading data, making it ideal for programmatic operations.

Answer 243

A, C y D According to Page 5, BigQuery supports loading data from formats like Avro, Parquet, ORC, CSV, JSON, and Firestore exports. XML is not mentioned as a supported format, so it is not a correct answer.

Answer 244

B Page 18 explains that BigLake tables simplify permission management by using a service account to decouple access to the table from the data source, whereas external tables require users to have separate permissions for both the table and the data source.

Answer 245

B Page 17 highlights that BigLake uses a metadata cache to store details about external data (e.g., Parquet files), enabling faster file and partition pruning, dynamic predicate pushdown, and improved query performance without needing to copy data into BigQuery.

Answer 246

C the ELT pattern centers around data being loaded into BigQuery first. Once loaded, transformations are applied within BigQuery itself using various methods like SQL scripts or Dataform. Structured data is loaded into BigQuery staging tables, transformations are applied within BigQuery, and the transformed data moves to production tables in BigQuery

Answer 247

B El Concepto Clave: Scripting vs. Consultas Simples En SQL tradicional, una consulta (un SELECT) es una única instrucción declarativa: le pides a la base de datos "qué" datos quieres, y ella se encarga del "cómo" obtenerlos. La descripción de la pregunta va más allá. Habla de ejecutar múltiples pasos en orden, usar variables, tomar decisiones (IF) y crear bucles (WHILE). Esto se asemeja más a un lenguaje de programación tradicional. Esa capacidad en BigQuery se conoce como lenguaje procedimental o, más comúnmente, scripting. Por qué la opción b) es la correcta: Procedural Language El Lenguaje Procedimental de BigQuery es exactamente lo que se describe en la pregunta. Permite escribir scripts que se ejecutan como una unidad. Analicemos cada punto de la descripción: "execution of multiple SQL statements in sequence" (ejecución de múltiples sentencias SQL en secuencia): Esto es la base del scripting. Puedes escribir un CREATE TABLE, seguido de un INSERT, seguido de un SELECT, todo en un mismo script que se ejecuta de principio a fin. "with shared state" (con estado compartido): Esto se refiere al uso de variables. Puedes declarar una variable al inicio (DECLARE), asignarle un valor (SET) y luego usarla en sentencias posteriores dentro del mismo script. "automation of management tasks like creating/dropping tables" (automatización de tareas de gestión como crear/eliminar tablas): El scripting es ideal para tareas de ETL (Extracción, Transformación y Carga) o de administración, ya que puedes, por ejemplo, crear una tabla temporal, procesar datos en ella y luego eliminarla, todo de forma automatizada en un solo script. "implementation of complex logic using programming constructs like IF and WHILE" (implementación de lógica compleja con IF y WHILE): Estas son las estructuras de control que ofrece el lenguaje procedimental para manejar flujos de trabajo complejos, como ejecutar ciertas acciones solo si se cumple una condición (IF) o repetir una tarea hasta que se cumpla un criterio (WHILE). Ejemplo simple de Lenguaje Procedimental: -- Un script que crea una tabla solo si no existe BEGIN DECLARE target_table STRING DEFAULT 'my_project.my_dataset.my_new_table'; IF NOT EXISTS (SELECT 1 FROM `my_dataset.__TABLES__` WHERE table_id = 'my_new_table') THEN EXECUTE IMMEDIATE 'CREATE TABLE ' || target_table || ' (id INT64, name STRING)'; INSERT INTO `my_project.my_dataset.my_new_table` VALUES (1, 'test'); END IF; END; Este ejemplo usa variables, una secuencia de comandos y una estructura IF, encajando perfectamente en la descripción. Por qué las otras opciones son incorrectas a) User-Defined Functions (UDFs) - Funciones Definidas por el Usuario: Una UDF es una función personalizada que toma valores de entrada (generalmente de columnas de una tabla) y devuelve un único valor de salida. Se usa dentro de una sentencia SELECT para realizar una transformación o cálculo complejo fila por fila. No puede ejecutar una secuencia de comandos como CREATE TABLE o INSERT. Su propósito es extender la lógica dentro de una consulta, no orquestar múltiples consultas. c) Stored Procedures for Apache Spark - Procedimientos Almacenados para Apache Spark: Esta es una capacidad específica que permite ejecutar código de Apache Spark (escrito en Python, por ejemplo) desde BigQuery. Aunque es una forma de ejecutar lógica compleja, la pregunta describe constructos nativos de SQL (IF, WHILE en un entorno SQL), no la ejecución de código en un motor externo como Spark. La descripción se refiere al lenguaje procedimental propio de BigQuery. d) Remote Functions - Funciones Remotas: Son similares a las UDFs, pero la lógica de la función se ejecuta fuera de BigQuery, típicamente en Google Cloud Functions. BigQuery le envía los datos, la Cloud Function los procesa y devuelve el resultado. Al igual que las UDFs, operan a nivel de fila dentro de una consulta y no pueden ejecutar secuencias de comandos DDL (CREATE, DROP) en BigQuery. Resumen Procedural Language (Correcta): Es para escribir scripts completos con múltiples pasos, variables y lógica de control (IF/WHILE) para orquestar tareas. UDFs y Remote Functions (Incorrectas): Son para realizar cálculos o transformaciones a nivel de fila dentro de una única consulta SELECT. Stored Procedures for Spark (Incorrecta): Es para ejecutar código Spark, no para usar las capacidades de scripting nativas de BigQuery SQL.

Answer 248

C Dataform is defined as a serverless framework to develop and operationalize ELT pipelines in SQL. It unifies data transformation, assertion, and automation within BigQuery, streamlining processes that would otherwise be time-consuming and error-prone

Answer 249

B y C Formas Correctas de Declarar Dependencias ✅ b) Usando la función ref() en el cuerpo del SQL Este es el método principal y más común para crear dependencias. Cuando usas ref("nombre_de_otra_tabla") dentro de una consulta SELECT, le estás diciendo a Dataform: "Para construir esta tabla, primero necesitas haber construido la tabla a la que estoy haciendo referencia". Dataform usa estas referencias para construir automáticamente un gráfico de dependencias (DAG), asegurando que todo se ejecute en el orden correcto. 🔗 Ejemplo: -- En el archivo: /definitions/clientes_limpios.sqlx config { type: "table" } SELECT * FROM ${ref("clientes_brutos")} WHERE es_activo = true Aquí, clientes_limpios depende de clientes_brutos. c) Listando dependencias en el array dependencies dentro del bloque config Esta es una forma alternativa y más explícita de declarar una dependencia. Es útil cuando una tabla depende de otra, pero esa dependencia no aparece directamente en la consulta SELECT principal. Por ejemplo, si una tabla se usa solo en una pre_operations o simplemente quieres forzar un orden de ejecución específico. Ejemplo: -- En el archivo: /definitions/reporte_final.sqlx config { type: "table", dependencies: ["tabla_de_validaciones"] } SELECT * FROM ${ref("ventas")} Aunque la consulta principal solo referencia a ventas, hemos forzado a que reporte_final espere a que tabla_de_validaciones se complete primero. Opciones Incorrectas ❌ a) Usando la función resolve() en el cuerpo del SQL La función resolve() se parece a ref(), pero tiene un propósito diferente: se usa para hacer referencia a tablas que NO están definidas en tu proyecto de Dataform (fuentes de datos externas). Le dice a Dataform: "Usa esta tabla, pero no intentes construirla tú mismo". Por lo tanto, no declara una dependencia dentro de tu flujo de trabajo. d) Las dependencias se infieren automáticamente Esto es falso. La gran ventaja de Dataform es precisamente que no adivina las dependencias. Requiere que las declares explícitamente usando ref() o el array dependencies. Sin estas declaraciones, Dataform no sabría en qué orden ejecutar tus scripts y el proceso fallaría. La declaración explícita es lo que lo hace tan robusto.

Answer 250

C Por qué la Opción C es la Correcta C. La compilación ocurre en Dataform, y la ejecución ocurre en BigQuery. Esta respuesta describe perfectamente el flujo de trabajo de Dataform: Compilación en Dataform: Tú escribes tu código en SQLX (que es SQL con funciones adicionales como macros, gestión de dependencias con ref(), y aserciones de calidad de datos). El servicio de Dataform toma este código SQLX, resuelve todas las dependencias (entiende qué tabla debe crearse primero), aplica las macros y lo "compila" en una serie de consultas SQL estándar (puro SQL que BigQuery puede entender). Ejecución en BigQuery: Dataform no es un motor de base de datos. No almacena datos ni ejecuta consultas por sí mismo. Su trabajo es enviar ese SQL estándar ya compilado a BigQuery. BigQuery es el servicio que recibe estas instrucciones SQL, las ejecuta contra los datos, y crea las nuevas tablas o vistas. En resumen: Dataform es el "cerebro" (gestiona el qué y el cuándo), mientras que BigQuery es el "músculo" (hace el trabajo de procesamiento). Por qué las Otras Opciones son Incorrectas A. La compilación y la ejecución ocurren ambas dentro de Dataform. Incorrecto: Dataform no tiene un motor de ejecución de consultas. No puede ejecutar el trabajo pesado de transformar petabytes de datos; para eso utiliza BigQuery. B. La compilación ocurre en BigQuery, y la ejecución ocurre en Dataform. Incorrecto (y al revés): BigQuery no entiende el lenguaje SQLX; solo entiende SQL estándar. Por lo tanto, no puede "compilar" el código de Dataform. Y, como se mencionó, Dataform no "ejecuta" las consultas. Esta opción invierte las responsabilidades. D. La compilación ocurre en Cloud Storage, y la ejecución ocurre en BigQuery. Incorrecto: Cloud Storage es un servicio de almacenamiento de objetos (archivos). Es pasivo; almacena cosas, pero no "compila" código. El servicio de Dataform es el que realiza la lógica de compilación. (Aunque Dataform puede usar Cloud Storage internamente para almacenar artefactos, la acción de compilar sucede en Dataform). La parte de la ejecución en BigQuery es correcta, pero la primera mitad de la afirmación es falsa.

Answer 251

C In ELT, data is first loaded into the destination system (e.g., BigQuery), and then transformations are applied, leveraging the power of that system.

Answer 252

A, B y D Por qué A, B y D son correctas El lenguaje procedimental de BigQuery (GoogleSQL) permite ejecutar scripts complejos, no solo consultas individuales. Esto lo acerca a lo que tradicionalmente se hacía con PL/SQL en Oracle o T-SQL en SQL Server. A) Ability to declare and use variables (Declarar y usar variables) Correcto. Puedes usar la instrucción DECLARE para crear una variable y SET para asignarle valor. Es fundamental para cualquier script procedimental. Ejemplo: DECLARE x INT64 DEFAULT 10; B) Use of transactions like COMMIT and ROLLBACK Correcto. BigQuery soporta transacciones multi-sentencia dentro de scripts. Esto garantiza las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad). Puedes iniciar una transacción, hacer varios cambios y luego hacer COMMIT (guardar) o ROLLBACK (deshacer si hay error). D) Support for IF and WHILE logic constructs (Lógica de control) Correcto. El lenguaje soporta flujo de control. IF/ELSE: Para ejecutar código condicionalmente. WHILE/LOOP: Para crear bucles y repeticiones. Ejemplo: WHILE x < 10 DO ... END WHILE; Por qué la C es la "mala" (en este contexto) C) Scheduling SQL workflows (Programación de flujos de trabajo) La distinción técnica: Aunque BigQuery tiene una función llamada "Scheduled Queries" (Consultas Programadas), esta es una característica de la plataforma/servicio, no una capacidad intrínseca de la sintaxis del lenguaje procedimental. Explicación: Tú no escribes un comando dentro de tu script SQL como SCHEDULE EVERY MONDAY DO.... Para programar, utilizas la consola de Google Cloud, la API o el CLI (bq mk). El lenguaje procedimental se encarga de la lógica (qué hacer), pero el servicio se encarga del cronograma (cuándo hacerlo). Resumen La pregunta evalúa si sabes diferenciar entre lo que puedes escribir en el código SQL (variables, bucles, transacciones) y lo que configuras en la infraestructura (programar la ejecución).

Answer 253

C Dataform is a serverless framework to manage ELT pipelines and SQL workflows within BigQuery.

Answer 254

A y C Respuestas correctas: A y C A) Performing complex data transformations using external Python code (Realizar transformaciones de datos complejas usando código Python externo). ¿Por qué es correcto? Este es uno de los casos de uso más potentes. Imagina que necesitas usar una librería de Python que no existe en SQL (por ejemplo, para análisis de sentimiento, traducción de texto o aplicar un modelo de machine learning específico). Con una función remota, puedes escribir esa lógica en Python, alojarla en Cloud Functions o Cloud Run, y llamarla directamente desde tu consulta de BigQuery para transformar los datos fila por fila. 🐍 C) Extending SQL with logic hosted on Cloud Run (Extender SQL con lógica alojada en Cloud Run). ¿Por qué es correcto? Esta es la definición perfecta de una función remota. Te permite "extender" las capacidades de tu SQL estándar. Si hay algo que SQL no puede hacer por sí solo, puedes programar esa "lógica" en el lenguaje que prefieras (Go, Python, Node.js), alojarla como un microservicio en Cloud Run y usarla como si fuera una función nativa más dentro de tus consultas. 🚀 ¿Por qué las otras son incorrectas? B) Triggering scheduled queries from external workflows (Disparar consultas programadas desde flujos de trabajo externos). ¿Por qué es incorrecto? Esto invierte la dirección del proceso. Una función remota es llamada desde dentro de una consulta de BigQuery. Para disparar o ejecutar una consulta de BigQuery desde fuera (por ejemplo, desde un orquestador como Cloud Composer o Airflow), usarías la API de BigQuery o el cliente de línea de comandos, no una función remota. D) Replacing SQL UDFs for simple arithmetic calculations (Reemplazar UDFs de SQL para cálculos aritméticos simples). ¿Por qué es incorrecto? Aunque técnicamente podrías hacerlo, sería extremadamente ineficiente. Para una suma simple (ej: 2+2), usar una función remota implica empaquetar los datos, hacer una llamada de red (HTTP) a otro servicio, esperar la respuesta y desempaquetarla. Esto añade una latencia y un coste enormes en comparación con usar un operador + nativo de SQL, que es prácticamente instantáneo. Las funciones remotas son para tareas complejas que justifican esa sobrecarga, no para operaciones simples. 🐢

Answer 255

C The config block defines key metadata like output table/view type, dependencies, and documentation used in Dataform's workflow compilation.

Answer 256

B In the ELT pattern on Google Cloud, structured data is first loaded into BigQuery staging tables, and then transformations are applied within BigQuery using SQL scripts or tools like Dataform.

Answer 257

A, B y C Scheduled queries, Dataform, and Jupyter Notebooks all support scheduling of data transformations in BigQuery. Cloud Monitoring is used for monitoring and alerting, not for scheduling transformations.

Answer 258

B Dataform is a serverless framework that simplifies the development and management of ELT pipelines using SQL, including data transformation, quality assertions, and workflow automation.

Answer 259

A, B y C Explicación Los procedimientos almacenados para Spark en BigQuery son una funcionalidad que te permite ejecutar código de Apache Spark directamente desde la interfaz de BigQuery. Esto es muy útil para realizar transformaciones de datos complejas, ejecutar algoritmas de machine learning o llevar a cabo tareas que serían muy difíciles o ineficientes de hacer solo con SQL. La clave para responder a esta pregunta es saber qué lenguajes son compatibles con el ecosistema de Apache Spark, ya que esta funcionalidad de BigQuery se basa en él. Opciones A, B y C: Python, Java y Scala (Correctas) ✅ Estas tres opciones son correctas porque son los lenguajes principales y oficialmente soportados por Apache Spark. Python: Es extremadamente popular en el mundo de los datos gracias a su simplicidad y al potente ecosistema de librerías como Pandas, NumPy y Scikit-learn. La API de Spark para Python se llama PySpark. Scala: Es el lenguaje en el que se construyó originalmente Apache Spark. Ofrece el mejor rendimiento y acceso inmediato a las últimas funcionalidades de la plataforma, ya que no necesita una capa de traducción. Java: Dado que Scala se ejecuta en la Máquina Virtual de Java (JVM), la compatibilidad con Java es nativa y muy sólida. Muchas grandes empresas con ecosistemas basados en Java lo utilizan para sus pipelines de Spark. Dado que la funcionalidad de BigQuery ejecuta un trabajo de Spark por debajo, es natural que soporte los lenguajes nativos de esta tecnología. Opción D: Go (Incorrecta) ❌ Esta opción es incorrecta. Explicación: Aunque Go (o Golang) es un lenguaje moderno y eficiente desarrollado por Google y muy utilizado en infraestructura en la nube, no es un lenguaje soportado por el ecosistema de Apache Spark. Por lo tanto, no se puede utilizar para escribir procedimientos almacenados de Spark en BigQuery.

Answer 260

B UDFs in BigQuery allow users to define custom transformation logic using SQL or JavaScript, enabling more complex or reusable data transformations within queries.

Answer 261

C In ELT, data is extracted, loaded into the target system like BigQuery, and then transformed, while ETL involves transforming data before loading it, often in a separate processing layer.

Answer 262

D Dataform is a separate tool integrated with BigQuery, not a feature of BigQuery itself, unlike UDFs, Stored Procedures, and Remote Functions, which are part of BigQuery's transformation capabilities.

Answer 263

C Dataform is a serverless framework for developing and operationalizing ELT pipelines using SQL on BigQuery, managing workflows, transformations, and scheduling.

Answer 264

B The "definitions" folder in Dataform contains SQLX files, which define tables, views, and operations for data pipeline transformations. Explicación Para entender por qué esta es la respuesta correcta, es útil conocer la estructura de carpetas estándar de un proyecto de Dataform: definitions/: Esta es la carpeta principal y el corazón de un proyecto Dataform. Contiene todos los archivos .sqlx (y a veces .js) que definen el flujo de trabajo de transformación de datos (el DAG). Cada archivo en esta carpeta define un nodo en tu grafo, que puede ser: Una tabla (type: "table"): Se crea una tabla en tu data warehouse. Una vista (type: "view"): Se crea una vista en tu data warehouse. Una tabla incremental (type: "incremental"): Una tabla que se actualiza de forma incremental. Una aserción (type: "assertion"): Una prueba de calidad de datos que se ejecuta para verificar tus datos. Una operación (type: "operations"): Código SQL arbitrario que se ejecuta (por ejemplo, para conceder permisos GRANT). includes/: Esta carpeta se utiliza para almacenar código reutilizable, como constantes o funciones de JavaScript, que pueden ser importadas y utilizadas en tus archivos de definitions. dataform.json: Este es el archivo de configuración principal para tu proyecto. Define cosas como el data warehouse de destino, el esquema por defecto y las variables globales. package.json: Gestiona las dependencias de tu proyecto, como si estuvieras usando paquetes de Dataform compartidos por otros. Ahora, evaluemos las opciones: A) Configuration files like .gitignore and package.json: Incorrecto. Estos son archivos de configuración a nivel de proyecto que generalmente se encuentran en el directorio raíz del proyecto, no dentro de la carpeta definitions. B) SQLX files that define tables, views, and operations: Correcto. Este es precisamente el propósito de la carpeta definitions. Es donde se define toda la lógica de transformación y el modelado de datos. C) JavaScript files for custom functions: Incorrecto. Aunque puedes usar JavaScript en Dataform, los archivos que contienen funciones personalizadas reutilizables se colocan típicamente en la carpeta includes/ para mantener el código organizado y separado de las definiciones de tablas específicas. D) Workflow settings and scheduling configurations: Incorrecto. La configuración del flujo de trabajo (workflow) se define en el archivo dataform.json, y la programación (scheduling) se configura en la interfaz de usuario de Google Cloud o a través de herramientas de orquestación como Cloud Composer. No se encuentra dentro de la carpeta definitions.

Answer 265

A BigQuery's SQL scripting allows running multiple SQL statements in sequence with shared state, useful for complex transformations, unlike the other options which are not directly related to this feature.

Answer 266

B The presentation emphasizes the Extract, Load, and Transform (ELT) pattern, as shown on slide 5. In this model, data is first extracted from the source and loaded into the data warehouse (BigQuery) into staging tables. The transformation step then happens inside BigQuery, leveraging its powerful SQL engine and features like SQL scripts, scheduled queries, and Dataform. The other options describe an ETL (Extract, Transform, Load) pattern, where transformation occurs before loading.

Answer 267

A, C y D ✅ Las respuestas correctas Cada una de estas opciones cumple exactamente con uno de los tres requisitos de la pregunta: A. config { type: "declaration" } Para qué se usa: Esta es la respuesta al primer requisito: "Referenciar una tabla existente... sin crear una nueva tabla desde ella". Explicación: Una declaration (declaración) es cómo le dices a Dataform: "Esta tabla ya existe en mi data warehouse (por ejemplo, en BigQuery), y quiero usarla como fuente". Dataform la añade a su gráfico de dependencias (DAG) para que puedas usar la función ref() para consultarla, pero no intentará crearla ni actualizarla. C. config { type: "assertion" } Para qué se usa: Esta es la respuesta al segundo requisito: "Definir un chequeo de calidad de datos...". Explicación: Una assertion (aserción o afirmación) es la funcionalidad específica de Dataform para pruebas de calidad. Es una consulta SQL que escribes esperando que no devuelva ninguna fila. Si la consulta devuelve filas (por ejemplo, filas donde mi_columna_clave IS NULL), la aserción falla y puede detener el pipeline, alertando sobre el problema de calidad. D. config { type: "table" } Para qué se usa: Esta es la respuesta al tercer requisito: "Crear una tabla final que se reconstruye desde cero...". Explicación: Este tipo de configuración define cómo se materializa tu consulta SQL. type: "table" le instruye a Dataform que ejecute tu SELECT y cree (o reemplace) una tabla física en BigQuery con los resultados. Este es el comportamiento estándar de "reconstruir desde cero" (a diferencia de type: "incremental", que solo añadiría datos nuevos). ❌ La respuesta incorrecta B. config { type: "operations" } Para qué se usa: Se utiliza para ejecutar sentencias SQL arbitrarias que no crean una tabla o vista. Explicación: Su uso más común es para ejecutar comandos de DML (Data Manipulation Language) como INSERT, UPDATE, DELETE, o comandos de DCL (Data Control Language) como GRANT (para dar permisos). Por qué es incorrecta: Ninguno de los tres requisitos pide ejecutar una sentencia DML o gestionar permisos. Las tareas son declarar una fuente (A), probar la calidad (C) y materializar una tabla (D). operations no es la herramienta adecuada para ninguna de esas tareas.

Answer 268

D As detailed on slide 11, Remote Functions are the ideal solution for this scenario. They allow you to write complex logic in languages like Python, package it with any necessary libraries, deploy it to a serverless environment like Cloud Run, and then call it from a BigQuery SQL query as if it were a native function. A SQL UDF cannot run Python code. A JavaScript UDF has limited library support and cannot handle all third-party packages. A Spark stored procedure (slide 10) runs a Spark job, which is a much heavier process and not designed for simple, function-like invocation within a standard SQL query.

Answer 269

B La clave para entender esto es ver a Dataform y a BigQuery como dos herramientas especializadas que trabajan juntas, cada una haciendo lo que mejor sabe hacer. Pensemos en la analogía de un arquitecto (Dataform) y un equipo de construcción (BigQuery). Fase 1: Diseño y Planos (Desarrollo y Compilación en Dataform) El arquitecto diseña los planos del edificio. Define qué paredes se construyen primero, cómo se conectan las habitaciones y qué materiales usar. Este es un trabajo de lógica, organización y planificación. Esto es exactamente lo que hace Dataform: te proporciona un entorno para escribir la lógica de tus transformaciones, gestionar las dependencias entre tablas y "compilar" tus instrucciones en un conjunto de planos de SQL estándar y ejecutables. Toda esta fase de "diseño" ocurre dentro de Dataform. Fase 2: Construcción (Ejecución en BigQuery) Una vez que los planos están listos, el arquitecto se los entrega al equipo de construcción. Este equipo, con su maquinaria pesada y su poder, es el que realmente levanta el edificio, mueve la tierra y vierte el hormigón. Esto es lo que hace BigQuery: Dataform le entrega el SQL final y le dice "ejecuta esto". BigQuery, con su motor de procesamiento masivo, es quien realiza el trabajo pesado de ejecutar esas consultas sobre petabytes de datos. La "ejecución" real ocurre directamente en BigQuery. Por lo tanto, la opción B describe esta separación perfectamente: el desarrollo y la compilación (los planos) se hacen en Dataform, pero la ejecución final del SQL (la construcción) se delega a BigQuery. Por qué las otras no son correctas: A) Es incorrecto porque Dataform no es un motor de base de datos; no tiene la capacidad para ejecutar consultas a gran escala por sí mismo. Su función es organizar, no ejecutar. C) Es incorrecto porque aunque el desarrollo puede empezar en un entorno local, la "compilación" (la creación de los planos finales de SQL) es una función central de Dataform, no de BigQuery. BigQuery solo entiende el resultado final. D) Es incorrecto porque el desarrollo y la compilación son tareas de Dataform, no ocurren "dentro" de BigQuery. Además, esta opción confunde la ejecución con la orquestación (que podría hacer Cloud Composer, pero la ejecución del SQL sigue siendo en BigQuery).

Answer 270

B, C y D Estas tres opciones describen las ventajas clave de usar Dataform para crear un pipeline de ELT (Extract, Load, Transform), en lugar de usar consultas programadas simples. Por qué B, C, y D son correctas B) It allows developers to define dependencies between SQL scripts, creating a directed acyclic graph (DAG). Correcto. Esta es la ventaja principal. En lugar de programar script_1 a la 1:00 am y script_2 a las 2:00 am (y rezar para que el primero termine a tiempo), en Dataform usas la función ref(). Si script_2 usa ref('script_1'), Dataform entiende que script_2 depende de script_1. Automáticamente construye un DAG (un gráfico de dependencias) y se asegura de ejecutar los scripts en el orden correcto. C) It automatically documents tables and columns and can display a visual lineage of the workflow. Correcto. Dataform te permite (y anima a) añadir descripciones para cada tabla y columna directamente en tu código SQL. Luego, genera una página de documentación. Además, el DAG (de la opción B) se puede ver de forma visual, lo que te da un linaje de datos claro: puedes ver exactamente qué tablas de origen se usan para construir tus tablas finales. D) It has built-in features for data quality testing called "assertions". Correcto. Esta es una característica de nivel de producción que las consultas programadas no tienen. En Dataform, puedes escribir una "aserción", que es una consulta SQL que esperas que devuelva 0 filas. Por ejemplo, una aserción puede ser SELECT * FROM orders WHERE total_price < 0. Si esta consulta devuelve alguna fila, Dataform sabe que hay un problema de calidad de datos y puede hacer que el pipeline falle. Por qué A es incorrecta A) It handles the extraction of data from source systems like on-premises databases. Incorrecto. Dataform es una herramienta de T (Transformación) en un pipeline ELT. Asume que los datos ya han sido extraídos (E) y cargados (L) en tu data warehouse (BigQuery). Dataform no se conecta a bases de datos locales para extraer datos; su trabajo comienza una vez que los datos ya están en BigQuery.

Answer 271

C Dataprep by Trifacta is explicitly described as a "serverless, no-code solution to build data transformation flows", simplifying data transformation. It provides a visual interface to preview transformations and offers intelligent suggestions for data cleaning and preparation. While Cloud Data Fusion is also GUI-based and for data integration, Dataprep is specifically highlighted for "data wrangling" and its no-code, serverless nature

Answer 272

B Dataflow leverages the Apache Beam programming framework to efficiently process "both batch and streaming data". It is listed as "recommended" for both "Batch, stream" workloads in the comparison table

Answer 273

B y C Dataproc Serverless for Spark allows running Spark workloads "without cluster management". Advantages listed include "Auto-scaling," "No infrastructure to tune," "No clusters to manage," and "Only pay for the execution time". It is suitable for "Batches, interactive notebooks, Vertex AI pipelines" Explicación La pregunta pide comparar las ventajas de Dataproc Serverless frente a la gestión de clústeres de Dataproc tradicional (también conocido como Dataproc en Compute Engine). La clave está en entender la diferencia fundamental entre un modelo "serverless" y un modelo de "clúster gestionado". Dataproc Tradicional: Tú creas explícitamente un clúster de máquinas virtuales (un maestro y varios trabajadores). Eres responsable de su tamaño, su configuración, de iniciarlo antes de los trabajos y de apagarlo después para ahorrar costos. Aunque es un servicio "gestionado" (Google se encarga de instalar Spark/Hadoop), tú sigues gestionando el ciclo de vida del clúster. Dataproc Serverless: Tú no gestionas ningún clúster. Simplemente envías tu trabajo de Spark (un "batch") y Google Cloud se encarga de provisionar, configurar y escalar la infraestructura necesaria para ejecutar ese trabajo específico. Una vez que el trabajo termina, toda la infraestructura desaparece. Ahora, evaluemos las opciones con este contexto: A) Manual management of Hadoop/Spark clusters is required. (Se requiere la gestión manual de clústeres de Hadoop/Spark). Incorrecto. Esta es una característica del Dataproc tradicional, no de Dataproc Serverless. De hecho, la principal ventaja de Serverless es precisamente eliminar esta gestión manual. B) Automatic scaling and no infrastructure to tune or manage. (Escalado automático y sin infraestructura que ajustar o gestionar). Correcto. Esta es la definición de Dataproc Serverless. No hay clústeres que crear ni máquinas virtuales que elegir. El servicio escala automáticamente los recursos necesarios para tu trabajo sin tu intervención. Es una ventaja clave sobre el modelo tradicional donde sí tienes que gestionar la infraestructura. C) Pay-per-execution pricing model (only pay for execution time). (Modelo de precios de pago por ejecución). Correcto. Con Dataproc Serverless, solo pagas por los recursos (vCPU y memoria) que tu trabajo consume mientras se está ejecutando. No pagas por tiempo de inactividad. En el modelo tradicional, pagas por las máquinas virtuales mientras el clúster esté encendido, incluso si no está procesando ningún trabajo. El modelo de pago por ejecución es una ventaja económica significativa para cargas de trabajo intermitentes. D) It is primarily designed for interactive notebooks but not batch processing. (Está diseñado principalmente para cuadernos interactivos pero no para procesamiento por lotes). Incorrecto. Esto es exactamente lo contrario. Dataproc Serverless está diseñado específicamente para procesamiento por lotes (batch processing). Para trabajos interactivos en cuadernos (notebooks), se suele utilizar un clúster de Dataproc tradicional (con el componente Jupyter) o servicios como Vertex AI Notebooks.

Answer 274

C Streaming ETL workloads on Google Cloud involve the continuous ingestion of event data, "often through Pub/Sub". Pub/Sub is used to "ingest high volumes of event data and distribute to different consuming systems". It acts as a messaging bus

Answer 275

C Bigtable is recommended as a sink in streaming data pipelines for "millisecond latency analytics". It's suitable for "NoSQL queries over large datasets (petabytes)" and offers "High throughput with millisecond latency". It is described as a "wide-column with column families" NoSQL database

Answer 276

C Dataprep by Trifacta is a serverless, no-code tool designed for building and previewing data transformation flows with prebuilt transformation functions.

Answer 277

A y B ¿Por qué A y B son las correctas? A. Dataflow Es el servicio "estrella" de Google Cloud para este propósito. Lo bueno: Fue diseñado desde cero para ser un servicio unificado; es decir, procesa tanto datos por lotes (batch) como flujos en tiempo real (streaming) utilizando el mismo código y modelo de programación. Técnicamente: Es un servicio serverless (sin servidor) que ejecuta pipelines de Apache Beam. B. Dataproc Es el servicio gestionado de Hadoop y Spark en Google Cloud. Lo bueno: Aunque tradicionalmente se asocia a batch (MapReduce), herramientas modernas como Spark Streaming o Apache Flink (que se ejecutan dentro de Dataproc) son extremadamente potentes para procesar datos en streaming. Técnicamente: Si ya tienes código en Spark que hace streaming, Dataproc es el lugar donde lo ejecutas. ¿Por qué las otras son las "malas"? C. Apache Beam Esta es una trampa común en los exámenes. La razón: Apache Beam no es un servicio, es un modelo de programación (SDK). Tú escribes el código usando Apache Beam, pero necesitas un servicio (como Dataflow) para ejecutarlo. La pregunta pide explícitamente "servicios". D. Dataprep La razón: Dataprep es una herramienta visual para limpiar y preparar datos, pero funciona fundamentalmente en modo batch. Aunque por debajo usa Dataflow para procesar los datos, la herramienta está diseñada para que usuarios de negocio limpien datasets estáticos o programados, no para ingerir y procesar flujos de eventos en milisegundos.

Answer 278

C Dataproc Serverless allows users to run Spark workloads without needing to manage clusters, and it automatically scales based on workload needs.

Answer 279

A y B Cloud Data Fusion connects to multiple sources like SAP, BigQuery, Cloud Storage, etc. Google Sheets is supported by Dataprep but not directly highlighted in Cloud Data Fusion within the module.

Answer 280

C Pub/Sub is used to ingest large volumes of event data in real time, acting as the entry point in streaming pipelines.

Answer 281

C Dataprep by Trifacta is a serverless, no-code solution that allows users to visually build data transformation flows and provides intelligent suggestions for data cleaning and preparation.

Answer 282

A, B y D Estas tres opciones definen lo que significa ser "Serverless" en el ecosistema de Big Data de Google: A) No need to manage clusters: Esta es la principal ventaja. En el Dataproc "estándar", tú tienes que elegir cuántos nodos quieres y qué tipo de máquina usar. En el Serverless, tú solo envías tu código Spark y Google se encarga de crear el entorno necesario, ejecutarlo y destruirlo. B) Automatic scaling: El sistema analiza la carga de trabajo de tu job de Spark y escala los recursos (memoria y CPU) hacia arriba o hacia abajo dinámicamente según sea necesario para completar la tarea de forma eficiente. D) Pay only for execution time: A diferencia de un clúster tradicional que te cobra mientras esté encendido (aunque no esté haciendo nada), en la modalidad Serverless solo pagas por los segundos que tu código estuvo procesando datos. Por qué la C es "la mala" C) Requires manual resource allocation: Esta opción es lo opuesto a la filosofía Serverless. Si tuvieras que asignar recursos manualmente (como decidir el número exacto de ejecutores o memoria por nodo), estarías volviendo al modelo de gestión de infraestructura tradicional. Dataproc Serverless elimina precisamente esa carga operativa. Si ves las palabras "Serverless" y "Spark" juntas, busca siempre opciones que hablen de "No Ops" (sin operaciones), "Autoscaling" y "Pay-per-use".

Answer 283

A Cloud Data Fusion is a GUI-based, code-free tool designed for building enterprise data integration pipelines with a drag-and-drop interface and rich plugin ecosystem.

Answer 284

A. B y C 1. Opción B: Cloud Storage (GCS) Esta es la joya de la corona en Dataproc y la respuesta más importante. Por qué es correcta: Dataproc utiliza un conector especial (Cloud Storage Connector) que permite a Hadoop y Spark leer y escribir datos directamente en GCS como si fuera su sistema de archivos nativo. La ventaja: Permite desacoplar el cómputo del almacenamiento. Puedes borrar tu clúster de Dataproc para ahorrar dinero, pero tus datos siguen seguros y persistentes en Cloud Storage. 2. Opción C: BigQuery Por qué es correcta: Dataproc también tiene un conector para BigQuery. Puedes usar BigQuery como una fuente de entrada o como un lugar para guardar los resultados finales de tus procesamientos. La ventaja: BigQuery es, por definición, un almacén de datos (Data Warehouse) persistente y altamente disponible. 3. Opción A: HDFS on persistent disks (HDFS en discos persistentes) Por qué es correcta: HDFS (Hadoop Distributed File System) es el sistema de archivos estándar de Hadoop. En Google Cloud, HDFS se instala sobre los Discos Persistentes (Persistent Disks - PD) de las máquinas virtuales (Compute Engine). El matiz: Aunque a menudo borramos los clústeres de Dataproc (y con ellos sus discos), técnicamente los PDs son almacenamiento persistente (a diferencia de la memoria RAM o los SSD locales). Si reinicias una máquina, los datos en HDFS siguen ahí. Nota: Aunque es una opción válida, Google recomienda usar la Opción B (Cloud Storage) en su lugar para la mayoría de los datos. ❌ La "Mala" (Respuesta Incorrecta: D) Opción D: Local SSD only (Solo SSD local) Por qué es incorrecta: Los SSD locales son discos físicos conectados directamente al servidor donde corre la máquina virtual. Ofrecen una velocidad increíble (muy baja latencia), pero son efímeros. El problema: Si apagas la instancia (máquina virtual) o si Google necesita mover tu máquina a otro host por mantenimiento, todos los datos del SSD local se borran instantáneamente. No pueden garantizar la persistencia de los datos, por lo tanto, no son una opción válida para "persistent data". Se usan solo para caché o archivos temporales de alta velocidad.

Answer 285

B Apache Spark on Dataproc is primarily used for data engineering, machine learning model training, analytics, and other large-scale data processing tasks.

Answer 286

C As stated on slide 6, Dataprep by Trifacta is a "serverless, no-code solution to build data transformation flows." It is designed for data wrangling with a visual interface, connects to sources like Cloud Storage, and provides intelligent suggestions (slide 7), making it ideal for non-technical users. Dataproc is code-based (Spark/Hadoop), and Cloud Data Fusion is more for enterprise-level data integration pipelines, while BigQuery is a data warehouse, not a data transformation tool itself.

Answer 287

B y D Slide 16 ("Using Serverless for Spark") explicitly lists the key benefits. B is correct: The slide states, "Only pay for the execution time (no startup or shutdown cost)". D is correct: The slide highlights "No infrastructure to tune" and "No clusters to manage" as primary advantages over the traditional approach. A is incorrect as it describes the opposite of the serverless value proposition. C is incorrect; while tools like Cloud Data Fusion offer a GUI, Dataproc Serverless is about submitting code (e.g., Spark jobs) without managing the execution environment.

Answer 288

C Slide 25 clearly states that Dataflow "can process both batch and streaming data using the Apache Beam programming model" and highlights the "Unified programming model for batch and stream." This unified approach is the core value proposition for this specific scenario. While other options are parts of a data pipeline, only Dataflow with Beam is explicitly designed to handle both batch and streaming with one SDK.

Answer 289

B ✅ Respuesta Correcta B. Cloud Data Fusion 🔌 Explicación: Este servicio está diseñado específicamente para el caso de uso descrito. Cloud Data Fusion es una plataforma de integración de datos totalmente gestionada que cumple con todos los requisitos: Interfaz Gráfica (GUI): Permite a los desarrolladores construir pipelines de datos complejos de forma visual, sin necesidad de escribir código. Librería de Conectores: Su principal fortaleza es una extensa biblioteca de conectores preconstruidos para una gran variedad de fuentes, incluyendo sistemas empresariales como SAP, aplicaciones SaaS y bases de datos locales. Motor de Ejecución: Puede ejecutar las transformaciones de datos en un clúster de Dataproc (Hadoop/Spark) que provisiona y gestiona automáticamente, cumpliendo con este requisito clave. ❌ Respuestas Incorrectas A. Dataprep Por qué es incorrecta: Dataprep es una herramienta visual para la limpieza y preparación de datos, no para la integración compleja de sistemas. Carece de los conectores empresariales avanzados (como para SAP) y se ejecuta sobre el servicio de Dataflow, no de Dataproc. C. Dataproc Por qué es incorrecta: Dataproc es el motor de ejecución de trabajos de Spark y Hadoop, no una herramienta de desarrollo con interfaz gráfica. Para usar Dataproc directamente, el equipo tendría que escribir código, lo que contradice el requisito de una herramienta basada en GUI. D. Dataflow Templates Por qué es incorrecta: Los "Templates" de Dataflow son pipelines pre-escritos para tareas comunes (ej: de Cloud Storage a BigQuery). No son una herramienta para construir visualmente nuevas pipelines complejas ni ofrecen la amplia gama de conectores necesarios para sistemas como SAP.

Answer 290

D Slide 29 positions Bigtable specifically as a "sink in your streaming data pipeline for millisecond latency analytics." It highlights its high throughput, low latency, and its suitability for applications like "Time-series data" and "IoT." While BigQuery is an excellent analytical data warehouse, Bigtable is the superior choice for the NoSQL, low-latency, high-throughput read/write patterns described in the question.

Answer 291

A ETL stands for Extract, Transform, and Load. The "E" represents extracting data from various sources, which is the first step in the process.

Answer 292

B Dataprep by Trifacta is a serverless, no-code tool designed for data wrangling and transformation, connecting to sources like Cloud Storage and BigQuery.

Answer 293

C Dataproc is a managed service for running Apache Hadoop and Spark, ideal for batch processing with features like flexible runtimes and autoscaling.

Answer 294

B Pub/Sub manages high volumes of event data in real-time, acting as a hub to distribute events to various systems, making it suitable for streaming pipelines.

Answer 295

D Dataflow uses the Apache Beam model to process both batch and streaming data, offering serverless execution and integration with services like Pub/Sub and BigQuery.

Answer 296

B y C Esta pregunta es un poco "tricky" (tramposa) por cómo está formulada, pero es fundamental para entender la diferencia entre Arquitectura basada en Tiempo (Scheduled) y Arquitectura basada en Eventos (Event-driven). Las respuestas correctas son la B y la C. Las Respuestas Correctas B) An HTTP/S call C) A Pub/Sub message ¿Por qué? Cloud Scheduler es, en esencia, un cron as a service (un reloj despertador en la nube). Su único trabajo es "despertarse" a una hora específica y "darle un toque" a otro servicio para que haga el trabajo. ¿Cómo da ese "toque"? Solo tiene dos manos (mecanismos) principales para hacerlo: HTTP/S (Opción B): Cloud Scheduler envía una petición web (GET, POST, etc.) a una URL. Ejemplo: A las 9:00 AM, llama a https://mi-api.com/generar-reporte. Esto sirve para invocar Cloud Run, Cloud Functions o cualquier servidor web externo. Pub/Sub (Opción C): Cloud Scheduler publica un mensaje en un "Tema" (Topic) de Pub/Sub. Ejemplo: A las 12:00 PM, envía el mensaje "iniciar_backup" al tema "mantenimiento". Luego, cualquier servicio suscrito a ese tema reaccionará. Por qué las otras opciones son incorrectas Aquí está la confusión común: Cron vs. Eventos. A. "A new file upload to Cloud Storage" (Una nueva subida de archivo a Cloud Storage). Por qué es mala: Esto es un Evento, no un horario. Explicación: Si tú quieres que algo pase cuando subes un archivo, no usas Cloud Scheduler. El archivo puede subir a las 3:00 PM o a las 3:05 PM; no hay un horario fijo. Para esto se usan Cloud Functions con un "Storage Trigger" o Eventarc. Scheduler no "mira" archivos, solo mira el reloj. D. "A BigQuery INSERT event" (Un evento de inserción en BigQuery). Por qué es mala: Igual que la anterior, esto es un disparador basado en datos/eventos. Explicación: Si quieres reaccionar a una inserción en una base de datos, necesitas un sistema de logs o triggers de base de datos (event-driven). No puedes programar un cron job para "cuando ocurra un insert", porque no sabes a qué hora ocurrirá. Resumen Mental: La Analogía del Despertador vs. el Timbre Para el examen, distingue así los servicios de automatización: Cloud Scheduler (El Despertador): Funciona con TIEMPO. "Haz esto todos los días a las 8 AM". Usa HTTP o Pub/Sub para despertar a otros. Cloud Functions / Eventarc (El Timbre de la Puerta): Funciona con EVENTOS (Acciones). "Haz esto cuando alguien suba un archivo (Opción A) o cuando alguien escriba en la base de datos (Opción D)". No le importa la hora, le importa la acción. Por tanto, Cloud Scheduler nunca se invoca por un archivo o una base de datos, solo por el reloj. Y para ejecutar su tarea, usa HTTP o Pub/Sub.

Answer 297

B Cloud Composer is described as a central orchestrator that integrates pipelines across diverse systems, including Google Cloud, on-premises, and multicloud environments. It uses Apache Airflow and Python for defining workflows (DAGs). It is explicitly stated as not serverless and requires medium coding effort. Cloud Scheduler is generally recommended for simple scheduled tasks with low coding effort (using YAML with Workflows)

Answer 298

A, B y C a) Eventos de Cloud Storage (fuente) - ✅ Correcta Eventarc está diseñado para reaccionar a eventos que ocurren en otros servicios de Google Cloud. Cloud Storage es una de las fuentes de eventos más comunes y soportadas. Por qué es correcta: Puedes configurar un trigger (disparador) de Eventarc para que se active cuando ocurra una acción específica en un bucket de Cloud Storage, como por ejemplo: Cuando se crea un nuevo objeto (google.cloud.storage.object.v1.finalized). Cuando un objeto es borrado (google.cloud.storage.object.v1.deleted). Cuando un objeto es archivado (google.cloud.storage.object.v1.archived). Esto es fundamental para arquitecturas que procesan ficheros en cuanto se suben a la nube. b) Cloud Audit Logs (fuente) - ✅ Correcta Esta es una de las capacidades más potentes de Eventarc. Cloud Audit Logs registra las llamadas a las APIs de casi todos los servicios de Google Cloud. Por qué es correcta: Eventarc puede usar estos logs como una fuente de eventos. Esto te permite reaccionar a casi cualquier acción que ocurra en tu proyecto de Google Cloud. Por ejemplo, puedes crear un trigger que se dispare cuando: Alguien crea una nueva máquina virtual en Compute Engine. Se modifica una regla del firewall. Se concede un nuevo permiso de IAM a un usuario. Esto abre la puerta a automatizar respuestas de seguridad, auditorías o gestión de infraestructura. c) Funciones de Cloud Run (destino) - ✅ Correcta Los destinos (targets) en Eventarc son los servicios que reciben y procesan el evento. Cloud Run es uno de los destinos principales y más comunes. Por qué es correcta: Eventarc puede enrutar un evento (venga de Cloud Storage, Audit Logs, Pub/Sub, etc.) y enviárselo a un servicio de Cloud Run. El evento llega como una petición HTTP POST al contenedor de Cloud Run, que se encarga de procesarlo. Otros destinos comunes son Cloud Functions, Google Kubernetes Engine (GKE) y Workflows. d) Tablas de BigQuery (destino para inserción directa) - ❌ Incorrecta Aquí está la clave: la palabra "directa". Por qué es incorrecta: Eventarc por sí solo no puede insertar datos directamente en una tabla de BigQuery. El trabajo de Eventarc es enrutar el evento a un servicio de cómputo que pueda procesarlo. Para insertar los datos de un evento en BigQuery, el flujo correcto sería: Una fuente (ej. Cloud Storage) genera un evento. Eventarc captura y enruta ese evento. Eventarc envía el evento a un destino (ej. una función de Cloud Run o Cloud Functions). El código dentro de Cloud Run/Cloud Functions recibe el evento, lo procesa y ejecuta la lógica para insertar los datos en la tabla de BigQuery.

Answer 299

B Cloud Run functions are described as providing a serverless execution environment. Serverless means you do not need to provision or manage virtual machines. YAML configuration is associated with Cloud Scheduler and Workflows, not Cloud Run functions directly. Cloud Run functions support multiple programming languages, not just Python

Answer 300

D Cloud Composer is explicitly designed for orchestrating pipelines across diverse systems, including on-premises environments. It leverages Apache Airflow, which uses operators, tasks, and dependencies to manage complex workflows, and offers robust monitoring and logging features. The other services are less suitable: Cloud Scheduler is for simpler scheduled tasks, Cloud Run functions and Eventarc are primarily for event-driven processing of individual functions or connecting services based on events

Answer 301

C Cloud Composer is built on Apache Airflow and is designed to orchestrate pipelines across various environments, offering features for triggering, monitoring, and logging.

Answer 302

A Cloud Scheduler can trigger workloads at recurring intervals using various methods, including HTTP/S calls, App Engine HTTP calls, Pub/Sub messages, and Workflows. ✅ Explicación: Cloud Scheduler es un servicio de Google Cloud que permite ejecutar tareas programadas (cron jobs) en la nube. Los tipos de desencadenadores (triggers) que admite son: HTTP/S: Puedes hacer peticiones a cualquier endpoint HTTP o HTTPS, autenticado o no. App Engine HTTP: Llamadas directas a servicios alojados en App Engine. Pub/Sub: Puedes publicar mensajes en un tema de Pub/Sub para activar otras aplicaciones o flujos. Workflows: Puedes iniciar una ejecución de Workflows, lo cual es útil para orquestar procesos más complejos. ❌ Por qué las otras opciones son incorrectas: b) Cloud Scheduler no se activa directamente por eventos de Cloud Storage, Firestore o servicios de Google Cloud. Eso lo hace Eventarc o EventBridge. c) Aunque Cloud Scheduler se basa en cron jobs, no solo es para cron jobs tradicionales, sino que puede ejecutar tareas a través de diferentes tipos de destinos. d) Limitarlo solo a HTTP/S omite otros tipos válidos como Pub/Sub o Workflows.

Answer 303

C Cloud Run Functions allow you to run code serverlessly in response to events from various sources like HTTP requests, Pub/Sub messages, and Cloud Storage changes.

Answer 304

C Eventarc enables the creation of event-driven architectures by connecting various event sources to targets using a standardized CloudEvent message format.

Answer 305

A Cloud Run functions can be used to capture Cloud Storage events, such as file uploads, and trigger other services or processes, like Dataproc workflows.

Answer 306

D Cloud Composer is Google Cloud's fully managed workflow orchestration service built on Apache Airflow. It is specifically designed for authoring, scheduling, and monitoring complex pipelines that span hybrid and multi-cloud environments. Its ability to manage dependencies, handle retries, and integrate with a wide range of services makes it the ideal choice for this scenario over simpler scheduling or event-based services.

Answer 307

C La Respuesta Correcta C. Eventarc ¿Por qué? Hay tres palabras clave en la pregunta que gritan "Eventarc": "Standardized CloudEvents format": Eventarc es el servicio de Google que adopta nativamente el estándar CloudEvents (un formato open-source de la industria). Esto garantiza que, venga el evento de donde venga (Storage, BigQuery, IoT), tu código siempre lo reciba con la misma estructura (headers, body, etc.). "Over 90 different Google Cloud sources": Eventarc está pre-conectado a los Cloud Audit Logs. Esto significa que casi cualquier cosa que ocurra en la infraestructura de Google (crear una VM, borrar un dataset, insertar en BigQuery) puede disparar una acción sin que tengas que configurar nada complejo. "Central event bus": Eventarc actúa como ese director de orquesta centralizado que filtra y enruta eventos hacia destinos como Cloud Run (que es su "mejor amigo" en integración). Por qué las otras opciones son incorrectas (o menos precisas) A. Cloud Pub/Sub La trampa: ¡Esta es la que más confunde! Eventarc usa Pub/Sub por debajo (under the hood) como mecanismo de transporte. Por qué es mala: Pub/Sub es la "tubería" cruda. Si usaras solo Pub/Sub para conectar 90 fuentes distintas: Tendrías que escribir código para normalizar el formato de cada una (porque BigQuery manda datos distintos a Storage). No tendrías el filtrado avanzado de atributos ni el estándar CloudEvents automático. Pub/Sub es un sistema de mensajería, Eventarc es un gestor de eventos. La pregunta pide el servicio que estandariza y centraliza esas fuentes específicas de Google. B. Cloud Functions Por qué es mala: Cloud Functions es un destino (Compute), no el bus de transporte. Es quien recibe el evento y hace el trabajo, no quien lo transporta desde la fuente. (Aunque Cloud Functions de 2ª generación usa Eventarc nativamente para dispararse, la función en sí es código, no infraestructura de eventos). D. Cloud Scheduler Por qué es mala: Como vimos en la pregunta anterior, Scheduler es un reloj (basado en tiempo), no un bus de eventos (basado en acciones). No sirve para reaccionar a "un insert en BigQuery". Resumen Mental: La Analogía del Adaptador Universal Imagina que tienes electrodomésticos de 90 países diferentes (las 90 fuentes de Google), cada uno con un enchufe distinto. Cloud Pub/Sub (Opción A): Es como un cable de extensión simple. Si el enchufe no encaja, es tu problema; tienes que cortar y empalmar cables manualmente. Eventarc (Opción C - La Correcta): Es un Adaptador de Corriente Universal. No importa qué enchufe traiga el electrodoméstico (Audit Logs, Storage, etc.), Eventarc lo transforma automáticamente a un formato estándar (CloudEvents) para que puedas conectarlo a tu pared (Cloud Run) sin esfuerzo. Pista Pro: Si lees "Cloud Run" + "Events" o "Audit Logs" en la misma frase, la respuesta es casi siempre Eventarc.

Answer 308

B As shown in the comparison table (slide 19), Cloud Composer is the only service in the list that is not serverless. Cloud Composer environments are built on Google Kubernetes Engine (GKE) clusters that are provisioned specifically for your environment. The other three options—Cloud Scheduler, Cloud Run functions, and Eventarc—are all fully managed, serverless services where you don't manage the underlying infrastructure.

Answer 309

D Cloud Composer is Google Cloud's fully managed workflow orchestration service built on Apache Airflow. It is specifically designed for authoring, scheduling, and monitoring complex pipelines with multiple task dependencies, as described in the scenario (slide 10). Its ability to manage dependencies, handle retries, and integrate with a wide range of services (including on-premises) makes it the ideal choice over simpler scheduling or event-based services.

Answer 310

C Eventarc es el servicio diseñado específicamente para ser el "bus de eventos" centralizado en Google Cloud. Es "la buena" por tres razones clave mencionadas en tu pregunta: Más de 90 fuentes de Google Cloud: Eventarc puede escuchar eventos de casi cualquier cosa en GCP a través de los Cloud Audit Logs (como cuando alguien crea una tabla en BigQuery o sube un archivo a GCS). Formato CloudEvents: Eventarc utiliza el estándar CloudEvents de la CNCF para que todos los eventos tengan la misma estructura, facilitando que el destino (como Cloud Run) los entienda sin importar de dónde vengan. Entrega Directa a Destinos: A diferencia de Pub/Sub, que requiere que tú gestiones la suscripción, Eventarc se encarga de "rutear" el evento directamente a Cloud Run, Cloud Functions o GKE. Opción,Por qué es incorrecta A (Cloud Pub/Sub),"Aunque es un servicio de mensajería asíncrona, no es un bus de eventos nativo de GCP. Para que Pub/Sub reciba un evento de BigQuery, tendrías que configurar manualmente esa exportación. Pub/Sub no ""entiende"" nativamente el formato CloudEvents ni escucha automáticamente a +90 fuentes." B (Cloud Run functions),"Esto es el destino, no el bus. Las funciones son las que procesan el evento una vez que les llega, pero no son el servicio que centraliza la recepción y el ruteo desde las fuentes." D (Cloud Scheduler),"Este servicio es simplemente un cron job (un despertador). Sirve para ejecutar tareas en momentos específicos (ej: ""cada lunes a las 8 AM""), pero no reacciona a eventos que ocurren en otros servicios." Diferencia Clave: Pub/Sub vs. Eventarc Para no fallar en el examen, recuerda esto: Usa Pub/Sub cuando quieras enviar mensajes personalizados entre tus propias aplicaciones (App A -> App B). Usa Eventarc cuando quieras reaccionar automáticamente a algo que pasó dentro de Google Cloud (GCS -> Cloud Run) usando un formato estándar.

Answer 311

B As shown in the comparison table on slide 19, Cloud Composer is the only service in the list that is not serverless. Cloud Composer environments are built on Google Kubernetes Engine (GKE) clusters that are provisioned specifically for your environment, which requires management of the underlying compute resources. The other three options—Cloud Scheduler, Cloud Run functions, and Eventarc—are all fully managed, serverless services.

Answer 312

C Cloud Scheduler is the ideal service for this use case. It is a fully managed cron job service designed for simple, recurring tasks. As shown on slide 7, it can directly trigger a Workflow via an HTTP call. This is the most straightforward, lowest-effort, and serverless approach for a time-based trigger, perfectly matching the scenario's requirements. Cloud Composer would be unnecessarily complex for this simple task.

Answer 313

B Cloud Run functions (and its predecessor Cloud Functions) are designed for this exact event-driven pattern (slide 14). They can be directly triggered by events in Cloud Storage, are serverless (meaning no infrastructure management), and automatically scale down to zero, ensuring you only pay for execution time. This makes them perfect for running lightweight, event-driven code like the validation and loading script described.

Answer 314

C Cloud Scheduler is designed for scheduling and invoking workloads at recurring intervals or manually, and it requires low coding effort, primarily using YAML with Workflows. It is serverless and easy to set up for defining job frequency and execution time, making it ideal for simple, recurring automation tasks.

Answer 315

B Aunque es un servicio gestionado, su arquitectura subyacente se basa en un clúster de Google Kubernetes Engine (GKE) que se aprovisiona dentro del proyecto del cliente. Esto implica que, si bien Google se encarga de la gestión y el mantenimiento de este clúster, su existencia es visible para el usuario y se incurre en costos asociados a los nodos de dicho clúster, lo que lo diferencia del modelo puramente serverless. A continuación, se detalla por qué las otras opciones sí son consideradas serverless: A. Cloud Scheduler: Serverless por definición Cloud Scheduler es un programador de trabajos (cron) totalmente gestionado y serverless. Su función es invocar otros servicios en momentos predefinidos. Los usuarios solo definen el trabajo a ejecutar, la frecuencia y el destino, sin necesidad de aprovisionar ni gestionar ninguna infraestructura subyacente. Se paga únicamente por la cantidad de trabajos programados. C. Cloud Run Functions: La evolución de las funciones sin servidor Cloud Run Functions (anteriormente conocido como Cloud Functions) es un entorno de ejecución serverless para ejecutar código en respuesta a eventos. Los desarrolladores solo se preocupan por su código (la función), y Google Cloud se encarga de manera transparente de escalar los recursos necesarios para ejecutar esa función, incluso hasta cero si no hay solicitudes. El cobro se basa estrictamente en el tiempo de ejecución y los recursos consumidos durante la misma. D. Eventarc: El conector de eventos serverless Eventarc proporciona un servicio unificado para la entrega de eventos, permitiendo a los desarrolladores construir arquitecturas basadas en eventos de manera sencilla. Es una plataforma serverless que se encarga de recibir eventos de diversas fuentes (más de 90 servicios de Google Cloud, Pub/Sub o fuentes personalizadas) y enrutarlos a destinos como Cloud Run, Cloud Functions o Workflows. Toda la infraestructura para la ingesta, el enrutamiento y la entrega de eventos es gestionada por Google, siendo completamente transparente para el usuario.

Answer 316

C Cloud Composer is ideal for orchestrating complex workflows across different systems, such as this data pipeline involving Cloud Storage, Dataproc, and BigQuery. It allows defining tasks, dependencies, and schedules using Directed Acyclic Graphs (DAGs) in Python, making it suitable for managing multi-step data processes.

Answer 317

D Explicación: ¿Por qué Eventarc es la respuesta correcta? Eventarc es el servicio de Google Cloud diseñado específicamente para construir arquitecturas basadas en eventos. Actúa como un "centro de distribución" o un bus de eventos unificado. Su función es escuchar los eventos que ocurren en una gran variedad de servicios de Google Cloud (llamados "productores de eventos"), como una subida de archivos a Cloud Storage o un cambio en Firestore, y reenviarlos de forma segura a un servicio que pueda procesarlos (llamado "consumidor de eventos"), como Cloud Run o Cloud Functions. En resumen, Eventarc es el pegamento que te permite conectar un "suceso" (el evento) con una "acción" (tu código). 🧠 ¿Por qué las otras opciones son incorrectas? A. Cloud Scheduler: Este servicio no reacciona a eventos. Es un programador de tareas (cron) que ejecuta acciones basándose en el tiempo, no en sucesos. Por ejemplo, "ejecutar todos los días a las 8:00 AM". ❌ B. Cloud Composer: Es un servicio de orquestación de flujos de trabajo complejos (basado en Apache Airflow). Se utiliza para organizar pipelines de datos de varios pasos, no para reaccionar a eventos simples y directos. Usarlo para esto sería excesivamente complejo. ❌ C. Cloud Run Functions: Esta opción es un poco confusa, ya que mezcla dos servicios: Cloud Run y Cloud Functions. Si bien Cloud Functions y Cloud Run son los destinos comunes para procesar los eventos, no son el servicio que gestiona el enrutamiento del evento en sí. Eventarc es la capa que se encarga de capturar el evento y entregárselo a Cloud Functions/Run. Por lo tanto, Eventarc es la respuesta más precisa a la pregunta sobre qué servicio "te permite responder a eventos". ❌

Answer 318

D Automation in data engineering, particularly with services like Cloud Scheduler, Cloud Composer, Cloud Run Functions, and Eventarc, helps in streamlining repetitive tasks such as scheduling data pipelines, orchestrating workflows, and responding to events. This improves efficiency, reduces manual intervention, and allows data engineers to focus on more complex tasks.

Answer 319

B Slide 2 explicitly mentions "The role and responsibilities of a data engineer" and "Creating and deploying data pipelines of varying patterns on Google Cloud" as key learning points. The other options describe tasks more aligned with a Data Analyst (A), ML Engineer (C), or a Cloud/Security Administrator (D).

Answer 320

C The course summary (slide 2) links "automation techniques" to "complete data engineering tasks." In practice, automation in data engineering focuses on making processes like pipeline deployment (CI/CD), scheduling, and error handling more robust, repeatable, and efficient. The other options are either incorrect (D is the opposite of automation) or misinterpret the goal (A and B).

Answer 321

B Data engineers focus on creating and maintaining the infrastructure for data collection, storage, and analysis, enabling data scientists and analysts to work efficiently.

Answer 322

A Google Cloud Storage is optimized for unstructured data and offers cost-effective storage classes like Nearline and Coldline for infrequently accessed data.

Answer 323

B Batch pipelines are used for processing large datasets at scheduled times, such as daily or weekly, for tasks like ETL processes. Esta opción describe perfectamente la esencia del procesamiento por lotes (batch processing). Grandes volúmenes de datos: Las arquitecturas batch están optimizadas para procesar de manera eficiente grandes cantidades de datos que se han acumulado a lo largo del tiempo. Priorizan el rendimiento total (throughput) sobre la latencia. Intervalos programados: El procesamiento no ocurre de manera instantánea. En su lugar, se ejecuta en momentos específicos, por ejemplo, cada noche para generar informes diarios, una vez a la semana para consolidar datos de ventas, o cada hora para actualizar un dashboard. Un pipeline de datos batch en Google Cloud (usando herramientas como Dataflow en modo batch, Dataproc o BigQuery) está diseñado para ejecutar tareas de ETL/ELT sobre conjuntos de datos masivos de forma periódica y planificada. ❌ Respuestas Incorrectas A) To process and analyze data in real-time (Para procesar y analizar datos en tiempo real) Por qué es incorrecta: Esto describe el objetivo de los pipelines de datos en streaming, no en batch. El procesamiento en tiempo real se encarga de los datos a medida que llegan, evento por evento, con una latencia muy baja. El procesamiento batch, por definición, espera y acumula datos para procesarlos en conjunto. C) To manage user authentication and authorization (Para gestionar la autenticación y autorización de usuarios) Por qué es incorrecta: Esta tarea corresponde al ámbito de la seguridad y la gestión de identidades, no al procesamiento de datos. En Google Cloud, el servicio diseñado para esto es IAM (Identity and Access Management). Aunque un pipeline de datos necesita los permisos correctos para operar, su propósito no es gestionar esos permisos. D) To deploy machine learning models (Para desplegar modelos de machine learning) Por qué es incorrecta: Esta es una tarea relacionada pero distinta. Si bien un pipeline de datos batch puede ser usado para preparar los datos para entrenar un modelo o para ejecutar predicciones en lote con un modelo ya entrenado, el acto de desplegar un modelo (hacerlo disponible para recibir predicciones) es una función de plataformas de MLOps como Vertex AI Endpoints. El propósito principal del pipeline sigue siendo el procesamiento de los datos.

Answer 324

A Google Cloud Dataflow is designed for both batch and streaming data processing, making it ideal for building resilient streaming analytics systems.

Answer 325

C Cloud Composer is a managed service for Apache Airflow, making it easier to author, schedule, and monitor complex data pipelines.

Answer 326

D The sources list "Storage is cheap," "Focus on queries, not Infrastructure," and "Massive scalability" as reasons why Google Cloud is used for data analysis. They also state that "Traditional big data platforms require an investment in infrastructure", which is presented as a contrast to Google Cloud, not a characteristic or reason for using it.

Answer 327

C The sources define the "next wave of cloud computing" as a "fully automated, elastic cloud" where "The service automatically provisions and configures the infrastructure used to run your applications" and developers "do not think about individual machines". Options A and B describe previous stages in the evolution of cloud computing.

Answer 328

A, B y C Which of the following statements about Google Cloud Project basics is/are correct? (Select all that apply) A) A Google Cloud Project is the base level organizing entity and is required to use Google Cloud services. B) Data analysts commonly use Google Cloud Storage buckets for scalable storage and BigQuery datasets for analysis. C) Billing for BigQuery includes charges for query processing (bytes processed) and table storage. D) All projects consist of a mutable display name, but their lifecycle state cannot be changed once created

Answer 329

C One of the main benefits of Google Cloud is that it abstracts away infrastructure management, allowing data analysts to focus on getting insights from their data.

Answer 330

A, C y D El Contexto: Sistemas On-Premise Antes de analizar las opciones, recordemos qué significa "on-premise": la empresa es dueña y responsable de toda la infraestructura física (servidores, almacenamiento, redes) en sus propias instalaciones. Esto contrasta con la nube, donde los recursos son elásticos y gestionados por un proveedor. Esta diferencia es la raíz de todos los desafíos. Por qué A, C y D son Desafíos Comunes A. Las consultas tardan demasiado en ejecutarse ✅ Este es un problema clásico. En un sistema on-premise, los recursos de computación (CPU, RAM) son finitos y compartidos. Si un analista lanza una consulta pesada, puede consumir toda la capacidad disponible, haciendo que las consultas de otros usuarios se ralenticen o se pongan en cola. No se puede "añadir más potencia" instantáneamente como en la nube; requiere comprar e instalar nuevo hardware, un proceso lento y costoso. C. Falta de un data warehouse central o de herramientas ✅ En entornos tradicionales, es muy común que los datos estén fragmentados en "silos". El departamento de ventas tiene su base de datos, marketing la suya, finanzas otra, etc. Para un analista, esto es una pesadilla, ya que debe invertir un enorme esfuerzo en encontrar, limpiar y unificar datos de diferentes fuentes. Construir y mantener un data warehouse centralizado on-premise es un proyecto complejo y caro que muchas empresas no completan con éxito. D. La infraestructura es difícil de mantener ✅ Aunque esto parece un problema exclusivo del equipo de TI, afecta directamente al analista. Un mantenimiento difícil significa: Actualizaciones lentas: Si el analista necesita una nueva versión de una herramienta o una librería, puede tardar semanas o meses en ser aprobada e instalada. Inflexibilidad: Probar nuevas herramientas es un proceso burocrático y técnico complejo. Riesgo de fallos: El hardware envejece y falla, y el software necesita parches de seguridad, lo que puede causar caídas del sistema que interrumpen el trabajo del analista. Por qué B es Incorrecto B. Fácil acceso a almacenamiento escalable ❌ Esta afirmación describe una de las principales ventajas de la nube, y es exactamente lo opuesto a la realidad on-premise. El almacenamiento en un sistema local es limitado. Aumentarlo implica comprar discos duros o sistemas de almacenamiento, esperar a que lleguen, instalarlos y configurarlos. Es un proceso lento, caro y nada "fácil" o "escalable" de forma inmediata.

Answer 331

C BigQuery uses a pay-as-you-go model where you are charged for the amount of data processed by your queries and the amount of data stored.

Answer 332

C Buckets in Google Cloud Storage are typically used to stage raw data (e.g., large CSVs) before processing or analysis in tools like BigQuery.

Answer 333

A y C 🟢 Por qué la A y la C son las buenas A. Each project has a unique project ID and number (Cada proyecto tiene un ID y un número únicos). Esto es Verdadero. En Google Cloud, cada proyecto tiene dos identificadores principales: Project ID (ID del proyecto): Es un nombre legible (ej: mi-app-prod-2024). Tú lo eliges (si está disponible) y es único en todo Google Cloud. No se puede cambiar después de crearlo. Project Number (Número del proyecto): Es un número asignado automáticamente por Google (ej: 123456789012). Es único y tampoco cambia. C. IAM (Identity and Access Management) is used to manage users in a project (IAM se usa para gestionar usuarios en un proyecto). Esto es Verdadero. IAM es el sistema central de "quién puede hacer qué". Tú no das permisos a un servidor específico directamente; das permisos a un usuario sobre un proyecto (o una carpeta/organización). Por ejemplo, le dices a IAM: "El usuario Pepito es Editor en el Proyecto A". 🔴 Por qué las malas son las malas B. Projects are optional and only used in billing reports (Los proyectos son opcionales y solo se usan en informes de facturación). El error: Decir que son "opcionales". La realidad: Los proyectos son obligatorios. Son la unidad atómica de organización en Google Cloud. No puedes crear una máquina virtual, una base de datos o un bucket de almacenamiento flotando en la nada; deben vivir dentro de un proyecto. El proyecto es el contenedor que agrupa recursos, activa las APIs y gestiona la facturación. D. You can bypass project creation by working directly with resources (Puedes saltarte la creación de proyectos trabajando directamente con los recursos). El error: Creer que puedes tocar recursos "sueltos". La realidad: Imposible. Como mencioné arriba, todos los recursos deben pertenecer a un proyecto. Si intentas usar la línea de comandos (gcloud) o la consola sin tener un proyecto seleccionado o creado, no te dejará hacer nada. El proyecto es el "padre" de todos los recursos.

Answer 334

C Google Cloud offers automatic scaling and a pricing model where you only pay for what you use, unlike on-premise solutions that require manual provisioning and maintenance.

Answer 335

B A Google Cloud Project is the main organizational unit for managing resources, permissions, and billing in the cloud.

Answer 336

B y C BigQuery is a fully-managed data warehouse that automatically scales and charges based on usage. Users do not manage servers, and it is designed for structured data analysis (not unstructured storage).

Answer 337

B Buckets in Google Cloud Storage are containers used to store and organize data files, making them ideal for staging and managing large datasets.

Answer 338

C Slides 9 and 10 illustrate this concept perfectly. The "Typical big data processing" pie chart (slide 9) shows time is fragmented across many infrastructure-related tasks. The "Big data with Google" diagram (slide 10) shows that the goal is for the entire focus to be on "Insights." The key value proposition is to let Google manage the underlying complexities so the team can focus on deriving value from the data.

Answer 339

A, C y D lide 6 explicitly lists the "Reasons why Google Cloud is used for data analysis": "Massive scalability" (Answer A). "Focus on queries, not Infrastructure" (Answer C). "Storage is cheap" (Answer D). Answer B is incorrect as Google Cloud is a service provider; you don't receive free physical hardware.

Answer 340

B Slide 16 ("Separation of storage and computing power") highlights this benefit. With on-premise systems, you often "Pay for ability to use processing power even when no queries [are] running." With Google Cloud, you "Pay for only the resources you are using and no more." This decoupling is a fundamental economic and architectural advantage of cloud data warehousing.

Answer 341

C Slide 23 ("Projects") states, "Projects organize and govern your activities in the cloud." It is the base-level organizing entity required to use Google Cloud. Resources, such as Cloud Storage buckets and BigQuery datasets (slide 24), are created and exist within a project. The dashboard is the user interface for viewing and managing these components.

Answer 342

A The document highlights automatic and elastic scaling as a key advantage, allowing resources to adjust based on demand without manual intervention.

Answer 343

A The document specifies Projects (for organization), Resources (like storage and datasets), and Billing (for resource usage costs) as the main components.

Answer 344

B Google Cloud offers automatic and elastic scaling, contrasting with on-premise solutions that often require manual scaling and can lead to inefficiencies.

Answer 345

A, B y D ✅ Herramientas Correctas del Ingeniero de Datos Un Ingeniero de Datos 👷‍♂️ es como un arquitecto y fontanero del mundo de los datos: su trabajo es construir los sistemas para recolectar, mover, transformar y almacenar grandes cantidades de datos de manera eficiente y fiable. A) BigQuery ¿Por qué es correcta? BigQuery es un almacén de datos (data warehouse) sin servidor, masivamente escalable. Para un Ingeniero de Datos, esta es una de las herramientas más importantes. La usan para: Diseñar el destino final de los datos: Crean las tablas y definen los esquemas donde se guardará la información procesada. Cargar datos a gran escala: Implementan procesos (ETL/ELT) para mover datos desde diversas fuentes hacia BigQuery. Optimizar el almacenamiento y las consultas: Aseguran que los datos estén organizados de forma que los analistas puedan consultarlos rápidamente. B) Dataflow ¿Por qué es correcta? Dataflow es un servicio para procesar datos a gran escala, tanto en tiempo real (streaming) como por lotes (batch). Es la herramienta por excelencia para construir las tuberías de datos (data pipelines). Un Ingeniero de Datos la utiliza para: Transformar datos: Limpiar, enriquecer, agregar y dar formato a los datos crudos para que sean útiles. Mover datos entre servicios: Por ejemplo, leer datos de Pub/Sub, procesarlos con Dataflow y escribirlos en BigQuery o Bigtable. D) Bigtable ¿Por qué es correcta? Bigtable es una base de datos NoSQL de alto rendimiento, diseñada para cargas de trabajo masivas y de baja latencia (como datos de IoT, series temporales, etc.). El Ingeniero de Datos la usa para: Almacenar datos no estructurados o semiestructurados: Es ideal cuando el modelo de datos no encaja en una tabla relacional tradicional. Diseñar claves de fila eficientes: Como vimos en la pregunta anterior, el diseño de la row key es crucial para el rendimiento, y esta es una tarea clave del ingeniero. Integrarla en pipelines de datos: Sirve como fuente o destino para datos en tiempo real que necesitan ser leídos y escritos muy rápidamente. ❌ Herramienta Incorrecta C) Looker Studio ¿Por qué es incorrecta? Looker Studio (antes conocido como Google Data Studio) es una herramienta de visualización y Business Intelligence (BI). Su propósito es crear informes, gráficos y dashboards interactivos para explorar los datos. 📊 Este no es el dominio del Ingeniero de Datos. El trabajo del ingeniero es preparar y entregar los datos limpios y estructurados para que otros roles, como el Analista de Datos o el Analista de Negocios, puedan usar herramientas como Looker Studio para encontrar información valiosa y tomar decisiones. En resumen, el ingeniero construye la autopista, y el analista conduce el coche por ella.

Answer 346

C BigQuery is highlighted as fully managed and serverless ("No-ops"), eliminating the need for server administration and provisioning. It also supports real-time analytics on streaming data, which is noted as unique. BigQuery does not require indexes, keys, or partitions for performance

Answer 347

C ✅ La respuesta correcta C. Data can be ingested from raw formats into Cloud Storage, then batch loaded into BigQuery. (Los datos pueden ser ingeridos desde formatos crudos a Cloud Storage, y luego cargados en lote a BigQuery.) Por qué es correcta: Esta es la forma más común, escalable y rentable de cargar grandes volúmenes de datos en BigQuery. Subes tus archivos (CSV, JSON, Avro, Parquet, etc.) a un bucket de Google Cloud Storage (GCS). GCS actúa como un área de preparación o "data lake". Ejecutas un "Load Job" (un trabajo de carga) en BigQuery, apuntando a esos archivos en GCS. BigQuery lee los archivos en paralelo y los ingiere masivamente en la tabla. Este es el método principal para la ingesta en lote (batch). ❌ Las respuestas incorrectas A. Directly from on-premise SQL databases via a direct connector only. (Directamente desde bases de datos SQL locales a través de un conector directo solamente.) Por qué es incorrecta: La palabra "only" (solamente) la invalida. Si bien existen herramientas (como el BigQuery Data Transfer Service o conectores de terceros) para migrar datos desde bases de datos locales, no es la única forma. Además, muchos de estos conectores primero extraen los datos a archivos en GCS (como en la opción C) antes de cargarlos. B. Via streaming ingestion at a rate of 10 rows/sec per table. (Mediante ingesta de streaming a una tasa de 10 filas/seg por tabla.) Por qué es incorrecta: Aunque BigQuery sí tiene una API de ingesta por streaming (para datos en tiempo real), el límite de 10 filas/seg es drásticamente bajo y falso. La API de streaming está diseñada para alta ingesta, soportando cientos de miles de filas por segundo por tabla (sujeto a cuotas). Este número es tan incorrecto que invalida la opción. D. Through direct programmatic access using only the Web UI. (A través de acceso programático directo usando solamente la interfaz de usuario web.) Por qué es incorrecta: Esta opción se contradice a sí misma. El "acceso programático" (programmatic access) se refiere al uso de APIs, bibliotecas de cliente (Python, Java, etc.) o la herramienta de línea de comandos (bq). La "Web UI" (interfaz de usuario web o Consola de Cloud) es una interfaz gráfica, lo opuesto a programático. Además, la palabra "only" (solamente) también es incorrecta; la UI web es solo una de las muchas formas de interactuar con BigQuery.

Answer 348

B The sources state that BigQuery is actually two services in one: fully-managed and scalable data storage (BigQuery Managed Storage) and a fast massively parallel SQL Engine (BigQuery Analysis), based on Google's internal Dremel query engine technology

Answer 349

A, B, C y D The sources highlight that Google Cloud offers scalable big data tools to overcome various data challenges. These include siloed data, which BigQuery addresses by allowing mashing up data across multiple datasets. Storage cost is listed as a challenge that BigQuery helps overcome by storing datasets inexpensively and charging only for used storage and processing. Slow queries and tool latency on large datasets are also challenges that BigQuery's fast, highly parallel processing model addresses. Finally, the hard to scale challenge and issues related to provisioning are overcome by BigQuery being a fully managed and serverless solution that eliminates the need for manual hardware optimization

Answer 350

C BigQuery is described as a fully-managed and serverless data warehouse, meaning users do not need to manage infrastructure or operations, which allows them to focus solely on data analysis.

Answer 351

A, C y D BigQuery supports built-in ML (via BigQuery ML), real-time streaming data ingestion, and secure encryption of data both in transit and at rest. It uses columnar, not row-based, storage for performance.

Answer 352

B Looker Studio (formerly Data Studio) is commonly used for creating dashboards and visualizations with data queried from BigQuery.

Answer 353

A y C Aquí la "trampa" es que hay dos opciones que parecen correctas, pero una define mejor el desafío de la acción de ingerir. La Respuesta Correcta La respuesta correcta principal es A. Data velocity (Velocidad de los datos). (Nota: Dependiendo del examen específico, la C. Data volume también se considera un desafío de ingestión, pero la Velocidad es el reto más crítico y específico de la fase de entrada "en movimiento"). ¿Por qué es la A? La fase de Ingestión (Ingest) es la puerta de entrada. Imagina que intentas beber agua de una manguera de bomberos: Ingestión = Movimiento: Es el proceso de capturar datos desde la fuente (sensores, clicks de usuarios, logs) y moverlos a tu sistema. El reto de la Velocidad: Si los datos llegan más rápido de lo que tu sistema puede "tragarlos" (latencia de red, ancho de banda, escritura en disco), el sistema se colapsa o pierdes datos. Este es el desafío clásico de "Streaming" o tiempo real. Tienes que ser capaz de capturar el flujo constante sin interrupciones. Por qué las otras opciones son incorrectas (o menos acertadas) C. Data volume (Volumen de datos) Por qué es confusa: El volumen es un desafío, sin duda. La distinción: El volumen masivo es principalmente un desafío de Almacenamiento (Storage) y Procesamiento (Compute). Si tienes muchos datos (Volumen) pero llegan despacio, la ingestión es fácil (tardará mucho, pero no es difícil). Si tienes datos que llegan a una velocidad extrema (Velocidad), la ingestión es arquitectónicamente difícil, aunque el volumen total no sea infinito. En exámenes, solemos asociar Velocidad -> Ingestión y Volumen -> Almacenamiento. B. Tool latency (Latencia de la herramienta) Por qué es mala: La latencia de la herramienta es una limitación del software que eliges, no una característica intrínseca de los datos o de la fase en sí. Es un "problema", no un "desafío de análisis" estándar como las 3 V del Big Data (Volumen, Velocidad, Variedad). D. Slow visualization (Visualización lenta) Por qué es mala: Esta es la más fácil de descartar. La visualización ocurre al final del proceso (fase de Análisis/Visualización), no al principio (Ingestión). Si la visualización es lenta, el problema está en la herramienta de BI o en la capa de consultas, no en la ingesta. Resumen Mental para el Examen Cuando veas "Ingest" (Ingesta), piensa en: Captura: Traer los datos. Velocidad: ¿Llegan demasiado rápido? (El reto de la manguera). Variedad: ¿Vienen en formatos raros? (El reto del traductor). Por tanto, Data Velocity es el desafío dinámico que pone a prueba tu tubería de entrada.

Answer 354

A, C y D BigQuery is a fully managed, serverless enterprise data warehouse that supports SQL queries at petabyte scale and includes built-in machine learning and GIS features. Manual hardware provisioning is not required

Answer 355

A Dataprep is designed for preparing, cleaning, and transforming data quickly and easily before it is analyzed or stored.

Answer 356

A, B y C Trabajar con datasets muy grandes (a menudo llamados Big Data) presenta desafíos únicos que no se encuentran en conjuntos de datos más pequeños. ✅ A) Latencia de las herramientas (Tool latency) Cuando intentas usar herramientas de análisis tradicionales (como Excel o incluso un portátil con poca RAM ejecutando Python/R) con gigabytes o terabytes de datos, las operaciones se vuelven extremadamente lentas. Una consulta que tardaría segundos en un dataset normal puede tardar minutos u horas. Esta latencia o retraso en el rendimiento de las herramientas es un obstáculo constante que obliga a los analistas a usar sistemas distribuidos y herramientas especializadas (como Spark, BigQuery, etc.). ✅ B) Volumen de los datos (Data volume) El volumen es la característica que define a un "gran dataset". El simple tamaño de los datos es el origen de los demás problemas. Mover, procesar, limpiar y analizar miles de millones de filas de datos requiere una infraestructura y unas técnicas completamente diferentes a las que se usan con miles de filas. El volumen en sí mismo es el desafío fundamental. ✅ C) Alto coste de almacenamiento (High storage cost) Almacenar petabytes de información no es gratis. Aunque los costes de almacenamiento han disminuido con el tiempo gracias a la nube, mantener grandes volúmenes de datos de forma segura, accesible y con copias de seguridad genera costes significativos. Las empresas deben planificar cuidadosamente su presupuesto para el almacenamiento de datos, lo que se convierte en un desafío administrativo y financiero. La respuesta incorrecta: D ❌ D) Variedad de datos limitada (Limited data variety) Esta opción es incorrecta porque los grandes datasets suelen tener el problema opuesto: una enorme variedad de datos. El concepto de Big Data se define a menudo por las "V", y una de las más importantes es la Variedad. Esto significa que los datos provienen de muchas fuentes y en diferentes formatos: Datos estructurados: Tablas de bases de datos (SQL). Datos semi-estructurados: Archivos JSON, XML. Datos no estructurados: Texto libre, imágenes, vídeos, audios. El verdadero desafío no es la falta de variedad, sino cómo gestionar e integrar esa alta variedad para poder analizarla de forma coherente.

Answer 357

D ❌ La Interfaz Incorrecta: D D) SSH Terminal SSH (Secure Shell) es un protocolo de red que se utiliza para conectarse de forma segura a una máquina remota, como una máquina virtual (VM) en Google Compute Engine. ¿Por qué no es una interfaz para BigQuery? La razón principal es que BigQuery es un servicio serverless (sin servidor) y totalmente gestionado. No hay un "servidor de BigQuery" específico al que puedas conectarte a través de SSH. Toda la infraestructura está abstraída y es manejada por Google. Analogía 💡: Decir que usas SSH para interactuar con BigQuery es como decir que usas la llave de tu coche para sacar dinero de un cajero automático. La llave te permite llegar al lugar (arrancar el coche para ir al banco), pero la interfaz real para interactuar con el cajero es su pantalla y teclado. De manera similar, podrías usar SSH para conectarte a una máquina virtual y desde ahí usar el CLI (bq), pero SSH en sí mismo no es la interfaz con BigQuery. ✅ Las Interfaces Correctas y Estándar: A, B y C Estas son las tres formas principales y estándar de trabajar con BigQuery. A) Web UI Es la interfaz gráfica de usuario dentro de la Consola de Google Cloud. Es la forma más común y visual de interactuar con BigQuery: puedes escribir consultas, ver esquemas de tablas, gestionar trabajos y explorar datos fácilmente. B) Command-Line Interface (CLI) Es la herramienta de línea de comandos bq, que forma parte del SDK de Google Cloud (gcloud). Es ideal para automatizar tareas, ejecutar scripts y gestionar BigQuery desde un terminal. Por ejemplo, puedes cargar datos o ejecutar una consulta con un simple comando como bq query 'SELECT ...'. C) REST API Esta es la interfaz de programación que permite que las aplicaciones se comuniquen con BigQuery. Todas las librerías cliente (como las de Python, Java, Go, etc.) y muchas herramientas de terceros utilizan la API REST por debajo para enviar trabajos, obtener resultados y gestionar recursos. Es la base para la integración programática.

Answer 358

B Y D ✅ Respuestas Correctas B) Dataproc Por qué es para ingenieros de datos: Es el servicio gestionado para ejecutar clústeres de Apache Spark y Hadoop. Los ingenieros de datos lo usan para migrar cargas de trabajo "legacy" de Big Data a la nube o para procesar volúmenes masivos de datos usando herramientas de código abierto que ya conocen. Uso común: ETL masivo, procesamiento por lotes (batch) y machine learning a gran escala. D) Dataflow Por qué es para ingenieros de datos: Es el corazón del procesamiento de datos moderno en Google Cloud (basado en Apache Beam). Permite crear tuberías (pipelines) que procesan datos tanto en tiempo real (streaming) como por lotes (batch) de forma totalmente automática y sin servidores (serverless). Uso común: Ingesta de datos desde Pub/Sub hacia BigQuery, transformación de datos en tiempo real y limpieza de datos compleja. ❌ Respuestas Incorrectas A) Compute Engine Por qué no es la respuesta "ideal": Aunque un ingeniero de datos puede usar máquinas virtuales (VMs) para instalar herramientas personalizadas, Compute Engine es IaaS (Infraestructura como Servicio) de propósito general. En los exámenes y en las mejores prácticas de Google, se espera que el ingeniero de datos use servicios gestionados (como Dataproc o Dataflow) para no perder tiempo gestionando sistemas operativos o parches de seguridad. C) Looker Studio Por qué no es para ingenieros de datos: Looker Studio (antes Google Data Studio) es una herramienta de Visualización y BI (Business Intelligence). Su usuario principal es el Analista de Datos. El ingeniero de datos se encarga de que los datos lleguen limpios y rápidos a BigQuery, y es el analista quien se conecta desde Looker Studio para crear los gráficos y cuadros de mando.

Answer 359

B The presentation emphasizes that BigQuery is "fully managed and serverless" (Slide 11) and "No-ops" (Slide 12). This means Google handles all the underlying infrastructure management, scaling, and performance optimization, allowing users to focus on analysis without provisioning servers or managing clusters, which directly meets the company's requirement.

Answer 360

C Slide 17, "BigQuery is actually two services in one," explicitly breaks it down into BigQuery Managed Storage (scalable data storage) and BigQuery Analysis (a fast, massively parallel SQL engine based on Dremel). This separation of storage and compute is a foundational concept of BigQuery.

Answer 361

B, C y D This question tests the data analysis lifecycle shown on Slide 6. Cloud Storage (C) is used to land and store the raw data files ("Ingest"). BigQuery (B) is the tool used to store the structured data and run SQL queries to transform and analyze it ("Transform", "Store", "Analyze"). Looker Studio (D) is the tool for creating interactive dashboards and reports to present the findings ("Visualize"). Cloud Spanner is a transactional database and is not the primary tool for this type of analytics workflow.

Answer 362

C Slide 21, "Each data-related role uses a different suite of tools," clearly defines the Data Engineer's role as designing and building data processing systems. The tools listed for the Data Engineer include Dataflow, Dataproc, Cloud Storage, Bigtable, etc., which are all focused on building and managing the data infrastructure and pipelines, not just consuming the data.

Answer 363

B As described on Page 11, BigQuery is a fully managed and serverless enterprise data warehouse, meaning no hardware provisioning or operations are required. This eliminates the need for manual management (ruling out A), supports petabyte-scale datasets (ruling out C), and uses familiar SQL (ruling out D).

Answer 364

B Page 9 highlights Looker Studio as a tool that connects to BigQuery to visualize insights, as shown in the merchandise store dashboard example. Vertex AI (A) is for data scientists, Dataflow (C) is for data engineers, and Bigtable (D) is a NoSQL database, not a visualization tool (Page 21).

Answer 365

A. B y D Page 13 states BigQuery uses a highly parallel processing model for fast queries (A) and secures data with encryption in transport and at rest (B). Page 14 mentions streaming ingestion at 100K rows/second (D). However, BigQuery does not require manual indexing (C), as it uses columnar storage and simple schemas without indexes (Page 14).

Answer 366

C Page 15 emphasizes that the course focuses on the Web UI as the primary interface for data analysts to build, validate, and run queries quickly. The CLI (B) and REST API (A) are secondary options, and the Google Cloud SDK (D) is a broader toolset that includes the CLI but is not the primary focus.

Answer 367

C The sources explicitly recommend avoiding SELECT * for data exploration and instead suggest using the built-in Preview tab in BigQuery to quickly explore rows. This practice helps in controlling costs, as BigQuery charges for data processed during queries. While storing data in BigQuery is a separate cost, query processing is also charged. Furthermore, if you run the exact same query twice, you benefit from a query cache, which means it might not process data again (unless non-deterministic elements are present)

Answer 368

C The sources clearly state that "Newly defined aliases in the SELECT statement cannot be used yet for filtering but are allowed in ORDER BY, GROUP BY, HAVING". This is because "When SQL reads the table from disk, it filters for the columns you want returned (where clause). At the time of pulling the data from disk our aliased columns in the select statement are not interpreted and are thus not available". However, once the data is pulled, you can use aliased fields in clauses like ORDER BY

Answer 369

C En el mundo real, los datos rara vez son perfectos. Es muy común tener una columna de texto (STRING) que debería contener números, pero que por errores o distintas fuentes, también contiene texto normal (p. ej., "N/A", "error", "manzana"). Si intentas convertir toda la columna a número usando la función normal CAST, la consulta se detendrá y te dará un error en cuanto encuentre el primer valor que no pueda convertir. CAST("123" AS INT64) → Funciona, devuelve el número 123. CAST("apple" AS INT64) → FALLA, la consulta se detiene con un error. El objetivo es realizar esta conversión de forma "segura", permitiendo que la consulta termine sin errores y simplemente marcando los valores problemáticos (p. ej., con NULL) para poder tratarlos después. ✅ Por qué la opción (c) es la correcta C) SAFE_CAST("value" AS INT64) Como su nombre indica, esta función es la versión segura de CAST. Está diseñada específicamente para este escenario. ¿Cómo funciona?: Intenta hacer la conversión. Si tiene éxito, devuelve el valor convertido (el número). Si la conversión no es posible (porque el texto no es un número válido), no produce un error, sino que simplemente devuelve NULL. Esto permite que la consulta se procese por completo, transformando una columna con datos "sucios" en una columna numérica limpia, donde los valores no válidos son ahora NULL y fáciles de identificar o filtrar. Ejemplo de resultado: | Valor Original (String) | Resultado con SAFE_CAST (Integer) | | :---------------------- | :---------------------------------- | | "123" | 123 | | "apple" | NULL | | "99" | 99 | | "not a number" | NULL | ❌ Por qué las otras opciones son incorrectas A) CAST("value" AS INT64) Esta es la función de conversión estándar, pero no es "segura". Como se explicó antes, fallará y detendrá la consulta en cuanto encuentre un valor no numérico, lo que incumple el requisito principal del problema. B) CONVERT("value", INT64) Esta sintaxis no es la utilizada en Google BigQuery para la conversión de tipos. CONVERT es una función que existe en otros dialectos de SQL (como SQL Server), pero no es la correcta para BigQuery. D) TRY_CAST("value", INT64) Esta función es conceptualmente idéntica a SAFE_CAST (intenta convertir y devuelve NULL si falla), pero TRY_CAST es el nombre que se usa en otros sistemas de bases de datos como SQL Server o Presto. En el dialecto específico de Google BigQuery, la función correcta se llama SAFE_CAST.

Answer 370

B The sources address the issue of differing data granularity, where one transaction can contain many products. They propose two solutions to combine these products into a single field per transaction: "Solution 1: Use a string aggregation function to combine all products ordered: STRING_AGG(v2ProductName)" and "Solution 2: Use an array aggregation function to combine all products ordered: ARRAY_AGG(v2ProductName)". Both functions allow rolling up multiple product entries into a single field, either as a comma-separated string or as an array of elements, respectively.

Answer 371

C The sources advise, "When writing complex queries, consider breaking apart the logic using WITH clauses". They clarify that "WITH clauses are effectively sub-queries and can be chained together", which improves readability and modularity of complex queries. Furthermore, if a WITH clause is consistently used, it is recommended to "consider promoting it to a view or table" for greater reusability and efficiency.

Answer 372

C Using SELECT * can be expensive because it processes all columns. It's better to explicitly select only the fields you need, and if used, always include a LIMIT clause to control cost and output.

Answer 373

B Por qué es la buena: En Standard SQL (el estándar actual y predeterminado de BigQuery), cualquier identificador que contenga caracteres especiales debe ir encerrado en comillas invertidas (backticks). El problema del guion: El guion medio (-) es un carácter especial en SQL porque el motor lo interpreta como el signo matemático de resta (menos). La solución: Al escribir `project-id.dataset.table`, le estás diciendo a BigQuery: "Todo lo que hay aquí dentro es un solo nombre, no intentes hacer matemáticas con ello". Esto es obligatorio cuando tu ID de proyecto tiene guiones, que es lo más habitual en Google Cloud. Por qué las otras son las malas A. [ project-id.dataset.table ] Por qué falla: Los corchetes [] eran la forma de escapar tablas en Legacy SQL (la versión antigua de SQL de BigQuery que ya casi no se usa). El problema: Si estás escribiendo una consulta en Standard SQL (lo normal hoy en día), los corchetes darán un error de sintaxis inmediato. Además, en Legacy SQL la sintaxis solía ser [project_id:dataset.table] (con dos puntos), por lo que la opción A es incorrecta en casi cualquier contexto moderno. C. ' project-id.dataset.table ' Por qué falla: Las comillas simples ' ' (o dobles " ") se utilizan para definir cadenas de texto (strings), no objetos de la base de datos. El problema: Si usas esto en un FROM, BigQuery pensará que le estás pasando un texto literal, no buscando una tabla real, y fallará diciendo que esperaba un nombre de tabla. D. project-id.dataset.table Por qué falla: Esta es la "trampa" más común. El problema: Como no tiene comillas, el analizador de SQL lee esto literalmente como una operación matemática: project MENOS id PUNTO dataset... El motor intenta restar la columna id a la columna project, lo cual rompe totalmente la referencia a la tabla y genera un error de sintaxis.

Answer 374

A, B y D El Concepto Clave: Funciones de Agregación Primero, es fundamental entender qué es una función de agregación (o aggregation function) en el contexto de SQL y BigQuery. Una función de agregación toma los valores de múltiples filas y los combina para devolver un único valor de resumen. Imagina que tienes una tabla con 1,000 ventas; una función de agregación te permitiría calcular la venta total (un solo número), la venta más alta (un solo número) o el número total de ventas (un solo número). Estas funciones se usan casi siempre junto con la cláusula GROUP BY para calcular resúmenes por categorías (por ejemplo, ventas totales por cada país). Por qué A, B y D son correctas (Funciones de Agregación) Estas tres funciones cumplen perfectamente con la definición: toman múltiples filas y devuelven un único valor. A. COUNT() Qué hace: Cuenta el número de filas en un grupo. Ejemplo: SELECT COUNT(order_id) FROM sales; tomaría todas las filas de la tabla sales y devolvería un solo número: el total de pedidos. Lógica: Muchas filas de entrada → Un solo valor de salida (el conteo). B. SUM() Qué hace: Suma todos los valores numéricos de una columna en un grupo. Ejemplo: SELECT SUM(price) FROM sales; tomaría los precios de todas las filas y devolvería un solo número: el ingreso total. Lógica: Muchas filas de entrada → Un solo valor de salida (la suma). D. MAX() Qué hace: Encuentra el valor máximo (el más alto o el más reciente) en una columna dentro de un grupo. Ejemplo: SELECT MAX(order_date) FROM sales; revisaría las fechas de todas las filas y devolvería una sola fecha: la del pedido más reciente. Lógica: Muchas filas de entrada → Un solo valor de salida (el máximo). Otras funciones de agregación comunes que siguen esta misma lógica son MIN(), AVG(), ARRAY_AGG(), etc. Por qué C es incorrecta (Función de Formato/Escalar) C. FORMAT() Qué hace: FORMAT() no es una función de agregación, sino una función escalar (o de formato). Las funciones escalares operan sobre una sola fila a la vez. Cómo funciona: FORMAT() toma un valor de una fila y lo convierte a un formato de texto específico. Si la aplicas a una columna con 1,000 filas, obtendrás 1,000 resultados formateados, no un único valor de resumen. Ejemplo: SELECT FORMAT("%'d", sales_amount) FROM sales; tomaría el valor de sales_amount de cada fila y le daría formato (por ejemplo, convirtiendo 12345.67 en "12,345.67"). No combina nada entre filas. Lógica: Una fila de entrada → Un valor de salida por cada fila. Tabla Resumen Función ¿Es de Agregación? Propósito COUNT() Sí Toma muchas filas y devuelve el número total de ellas. SUM() Sí Toma muchos valores numéricos y devuelve su suma total. FORMAT() No Toma un valor de una fila y cambia su formato de texto. MAX() Sí Toma muchos valores y devuelve el más alto de ellos.

Answer 375

B In SQL, aliased fields (like session_time_minutes) defined in the SELECT clause cannot be reused in the WHERE clause. You need to repeat the expression or use a subquery.

Answer 376

D ¿Para qué sirve realmente la cláusula WITH? La cláusula WITH, también conocida como Expresión de Tabla Común (CTE o Common Table Expression), es una herramienta para organizar y simplificar la escritura de consultas SQL. Su propósito es puramente lógico y estructural. Imagina que es como organizar los ingredientes (mise en place) antes de cocinar una receta compleja. No hace que el horno cocine más rápido, pero hace que todo el proceso sea mucho más limpio, ordenado y fácil de seguir. Las razones válidas para usar WITH (y por qué las otras opciones son correctas) son: B. Estructurar consultas complejas para la legibilidad: Este es su principal superpoder. Permite dividir una consulta monstruosa y llena de subconsultas anidadas en bloques lógicos y con nombres claros. Esto hace que la consulta sea infinitamente más fácil de leer, depurar y mantener. ✅ C. Definir vistas temporales: Esto es exactamente lo que es una CTE. Crea una especie de "vista" o tabla temporal que solo existe durante la ejecución de esa única consulta. Puedes definir varias y luego unirlas en tu SELECT final, como si fueran tablas reales. ✅ ¿Por qué la opción D es la respuesta correcta? D. Aumentar la velocidad de ejecución de la consulta automáticamente Esta afirmación es incorrecta y, por lo tanto, la respuesta correcta a la pregunta "Cuál NO es una razón válida". La cláusula WITH es un constructor lógico, no una optimización de rendimiento. El motor de consultas de BigQuery analiza la lógica completa de tu consulta y crea el plan de ejecución más eficiente que puede, independientemente de si usas una CTE o una subconsulta anidada. Pensar que usar WITH hará que tu consulta se ejecute más rápido es un error muy común. Aunque una consulta más legible puede ser más fácil de optimizar manualmente por un humano, la cláusula en sí misma no le da ninguna instrucción a BigQuery para que se ejecute más rápido. 🚀❌ Una nota sobre la opción A A. Reutilizar lógica en múltiples consultas Técnicamente, esta afirmación también es incorrecta, pero de una manera más sutil. Una CTE permite reutilizar lógica, pero solo DENTRO de una única consulta. Su alcance no va más allá. Para reutilizar la lógica ENTRE múltiples consultas diferentes, la herramienta correcta sería crear una VISTA (VIEW) o una VISTA MATERIALIZADA (MATERIALIZED VIEW). Sin embargo, la opción D es la "más incorrecta" porque ataca la concepción errónea fundamental sobre el propósito de las CTEs: estructura vs. rendimiento.

Answer 377

A, B y C ✅ Respuestas Correctas A) Writing SQL queries and using the web UI Por qué es la principal: Es la forma nativa y más directa de explorar datos. La consola de BigQuery (Web UI) te permite ver el esquema de las tablas, realizar vistas previas de los datos (gratis) y ejecutar consultas SQL para filtrar, agrupar y entender la distribución de la información. B) Using Data Preparation or BI tools Por qué es correcta: Herramientas como Cloud Dataprep (de Trifacta) están diseñadas específicamente para "explorar" y limpiar datos visualmente, permitiéndote ver anomalías o valores nulos sin escribir código. Asimismo, las herramientas de BI (Business Intelligence) como Looker se integran para explorar modelos de datos ya estructurados. C) Visualizing raw data with a visualization tool Por qué es correcta: Directamente desde la consola de BigQuery, existe el botón "Explore Data". Google fomenta el uso de Looker Studio para crear gráficos rápidos que te ayuden a identificar patrones o tendencias que no son obvios en una tabla de texto. ❌ Respuesta Incorrecta D) Editing data directly in Google Sheets Por qué es falsa: Aquí es donde muchos fallan. Existe una función llamada Connected Sheets que te permite conectar BigQuery con Google Sheets para analizar millones de filas, crear tablas dinámicas y gráficos. PERO: No puedes "editar": No puedes cambiar el valor de una celda en Google Sheets y esperar que se actualice en la tabla de BigQuery. BigQuery es un Data Warehouse (almacén de datos masivo), no una base de datos transaccional ni una hoja de cálculo. Unidireccional: El flujo de datos para exploración es de BigQuery hacia Sheets (lectura), no de Sheets hacia BigQuery (escritura). Exploración vs. Edición: La pregunta pide métodos de exploración (entender los datos), y la edición no forma parte de ese proceso en este contexto.

Answer 378

B Cuando haces una consulta en BigQuery y el nombre del proyecto contiene un guion (-), debes encerrar el nombre del proyecto entre acentos graves (backticks) → ` `. Esto se debe a que los guiones no son caracteres válidos en los identificadores sin comillas, y podrían provocar un error de sintaxis si no se encierran correctamente. ❌ Por qué las otras opciones son incorrectas: A. [project-id.dataset.table] → Los corchetes no son válidos en BigQuery. C. 'project-id.dataset.table' → Las comillas simples son para cadenas de texto, no para identificar tablas. D. project-id.dataset.table → Da error si el project-id tiene guiones, porque no está entre backticks. ✅ Ejemplo correcto: SELECT * FROM `mi-proyecto-123`.ventas.ordenes

Answer 379

C Aliased fields defined in the SELECT clause cannot be used in the WHERE clause because filtering happens before the SELECT step in SQL execution. However, you can use aliases in ORDER BY, GROUP BY, and HAVING

Answer 380

B BigQuery provides 1 TB per month of query processing at no cost. Loading and extract jobs are free, and query jobs are charged by bytes processed, not storage size.

Answer 381

B If you run the same query twice in BigQuery without non-deterministic elements, the second query will use the query cache, resulting in faster execution and no additional processing cost

Answer 382

B y C ✅ Acciones Correctas y Buenas Prácticas: B y C B) Usar la pestaña "Vista Previa" (Preview) en la interfaz de usuario de BigQuery para inspeccionar una muestra de las filas sin ejecutar una consulta. Esta es la forma más barata de explorar datos: es gratis. ¿Por qué es una buena práctica? La función de vista previa no ejecuta un trabajo de consulta ("query job"). Simplemente lee una pequeña muestra de los datos de la tabla para mostrarte cómo son las columnas y qué tipo de valores contienen. Es la herramienta perfecta para un primer vistazo sin procesar ni un solo byte de datos facturable. Analogía: Es como ojear la portada y el índice de un libro antes de comprarlo para saber si te interesa, en lugar de comprarlo y leerlo entero directamente. C) Ejecutar SELECT DISTINCT fullVisitorId, country FROM ... en lugar de seleccionar todas las columnas. Esta es la mejor práctica fundamental para escribir consultas económicas. ¿Por qué es una buena práctica? Al especificar únicamente las columnas que necesitas (fullVisitorId y country), le estás diciendo a BigQuery que ignore todas las demás. Como BigQuery almacena los datos en un formato columnar, puede leer eficientemente solo los datos de esas dos columnas, reduciendo drásticamente la cantidad de datos procesados y, por tanto, el coste. Analogía: Si solo necesitas saber el nombre y la edad de las personas en un archivo, no pides el archivo completo con su dirección, historial médico, etc. Pides solo las columnas "nombre" y "edad". ❌ Acciones Incorrectas y Malas Prácticas: A y D A) Ejecutar SELECT * FROM ... para ver todos los datos a la vez. Esta es la peor práctica posible si te preocupa el coste. ¿Por qué es una mala práctica? SELECT * le ordena a BigQuery que lea todas las columnas de la tabla. Esto maximiza la cantidad de datos procesados y, en consecuencia, genera el mayor coste posible para esa tabla. Es el antipatrón número uno del ahorro de costes. D) Ejecutar la misma consulta compleja exactamente varias veces seguidas para verificar los resultados. Aunque esto puede que no te cueste más después de la primera vez, no es una buena práctica de exploración. ¿Por qué es una mala práctica? BigQuery tiene una caché de resultados. Si ejecutas la misma consulta exacta en un plazo de 24 horas (y los datos no han cambiado), BigQuery te devolverá el resultado guardado en la caché sin volver a procesar los datos y sin coste. Sin embargo, la primera ejecución de esa "consulta compleja" podría ser muy cara. El objetivo es hacer que la primera consulta sea barata, no confiar en la caché para verificar. Esta acción no ayuda a minimizar la cantidad de datos procesados en la exploración inicial.

Answer 383

C In standard SQL, the WHERE clause is processed before the SELECT clause. This means that the column alias session_time_minutes, which is created in the SELECT statement, does not yet exist when the WHERE clause is evaluated. To fix this, you must repeat the calculation in the WHERE clause, like so: WHERE ROUND(timeOnSite / 60, 2) > 240. Slides 32 and 33 cover this exact scenario, noting that aliases can be used in ORDER BY but not WHERE.

Answer 384

D D is correct: ARRAY_AGG() aggregates values into an ARRAY. This is the most flexible and structured way to handle this, as it keeps the products as distinct elements within a single field, which can be further processed (as shown on slides 51-53). A is incorrect: CONCAT is a string function that joins two or more individual strings, not an aggregate function that works over multiple rows with a GROUP BY. B is incorrect: COUNT(DISTINCT) would only tell you how many unique products were in the transaction, it would not list them. C is correct in a way, but not the best answer: STRING_AGG() (slide 49) would also work by creating a single, long, comma-separated string. However, an ARRAY is a more structured data type that is generally preferable for lists of items, as it avoids parsing strings and maintains the items as separate elements.

Answer 385

C BigQuery standard SQL uses backticks ( ) to enclose project, dataset, or table names that contain special characters, such as hyphens (-). Since the project ID gcp-data-science contains a hyphen, it must be enclosed in backticks to be parsed correctly. Using double quotes would treat it as a string literal, and brackets are used for legacy SQL, not standard SQL. This is explained on slide 16.

Answer 386

C The large difference between the total count and the distinct count indicates that each fullVisitorId appears many times in the table. This is expected behavior in a web analytics dataset where each row might represent a pageview, a product view, or another event. The table is at a more granular level than just one row per unique visitor. This insight is explicitly discussed on slides 40-42, which show that fullVisitorId is duplicated due to multiple product views by the same user.

Answer 387

B ✅ Explicación de la respuesta correcta (B) Esta opción resume perfectamente las ventajas principales de usar SQL en una herramienta como BigQuery. Vamos a desglosarla: Familiar (Familiar): SQL (Structured Query Language) es el lenguaje estándar de facto para interactuar con bases de datos y almacenes de datos. La gran mayoría de los analistas de datos, científicos de datos e ingenieros ya lo conocen. Esto elimina la necesidad de aprender un lenguaje nuevo y propietario, permitiendo que los equipos sean productivos desde el primer día. Es el "idioma universal" del mundo de los datos 🗣️. Fast (Rápido): BigQuery está construido sobre la infraestructura de Google y su motor de procesamiento (Dremel) está optimizado para ejecutar consultas SQL sobre volúmenes masivos de datos (terabytes y petabytes) a una velocidad increíblemente alta. La combinación de la simplicidad de SQL con la potencia de BigQuery es su principal atractivo. Flexible (Flexible): SQL es un lenguaje muy potente. No solo sirve para SELECT * FROM tabla, sino que permite realizar agregaciones complejas, unir múltiples fuentes de datos, filtrar con condiciones muy específicas y realizar cálculos sofisticados, todo dentro de la misma consulta. En resumen, BigQuery aprovecha el lenguaje que los analistas ya dominan (SQL) y le proporciona una potencia de cálculo masiva. ❌ Análisis de las respuestas incorrectas A) It requires no prior knowledge of the dataset structure (No requiere conocimiento previo de la estructura del conjunto de datos): Esto es totalmente falso. Para escribir una consulta SQL, es fundamental conocer la estructura de los datos, como los nombres de las tablas y las columnas que deseas analizar. No puedes pedir datos si no sabes cómo se llaman o dónde están. C) It automatically visualizes data without additional tools (Visualiza los datos automáticamente sin herramientas adicionales): Esto es incorrecto. SQL es un lenguaje para consultar y recuperar datos, no para visualizarlos. El resultado de una consulta SQL es, típicamente, una tabla de texto. Para crear gráficos o cuadros de mando, necesitas conectar BigQuery a una herramienta de visualización como Looker Studio, Tableau, Power BI, etc. 📊 D) It eliminates the need for data preparation tools (Elimina la necesidad de herramientas de preparación de datos): Esto es una exageración y, por tanto, incorrecto. Si bien puedes usar SQL para realizar muchas tareas de transformación y limpieza de datos (un enfoque conocido como ELT - Extract, Load, Transform), no reemplaza por completo a las herramientas especializadas de preparación y ETL (Extract, Transform, Load) como Dataflow o Dataprep, especialmente en procesos complejos de ingesta y limpieza de datos brutos.

Answer 388

B The document (Page 14, 15, 18) points out that the query fails because it does not include the dataset name (e.g., dataset-name.all_sessions). BigQuery requires the full table reference, including the dataset name, to resolve the table. The other options are incorrect: the LIMIT clause syntax is correct, SELECT * is not used, and there are no non-deterministic functions in the query.

Answer 389

B y C The document advises including the dataset name in the FROM clause to avoid errors (Page 15, 16, 17) and recommends using the Preview tab to explore data instead of running SELECT * queries, which can process unnecessary data and increase costs (Page 19). Option A is incorrect because the document advises against using SELECT * even with a LIMIT clause (Page 19, 23). Option D is incorrect as ORDER BY is used in examples (e.g., Page 26) and not explicitly discouraged.

Answer 390

B The document explains that aliased fields (e.g., session_time_minutes) cannot be used in the WHERE clause because SQL evaluates the WHERE clause before the SELECT clause, when aliases are not yet interpreted (Page 32, 33). Option A is incorrect as aliases can be used in ORDER BY (Page 34). Option C is too restrictive, and Option D is not a requirement, though subqueries are suggested as a workaround.

Answer 391

A y B Las funciones de agregación toman valores de múltiples filas y los combinan en un único valor como resultado de una operación GROUP BY. A) STRING_AGG: Esta función es correcta. Se utiliza para tomar valores de texto de varias filas y unirlos en una única cadena de texto con un delimitador. Ejemplo de e-commerce: Para un mismo ID de transacción, puedes agrupar los nombres de todos los productos comprados en un solo campo: 'Portátil, Ratón, Teclado'. B) ARRAY_AGG: Esta función también es correcta. Agrupa valores de varias filas y los introduce en un ARRAY (una lista). Ejemplo de e-commerce: Para un mismo ID de transacción, puedes crear una lista con todos los nombres de los productos: ['Portátil', 'Ratón', 'Teclado']. Esta opción suele ser más potente que STRING_AGG porque mantiene los elementos estructurados y permite realizar análisis posteriores sobre la propia lista. ❌ Técnicas Incorrectas en este Contexto (C y D) Estas funciones son muy útiles en BigQuery, pero no son funciones de agregación. Operan en valores de una sola fila a la vez. C) FORMAT: Incorrecto en el contexto de la agregación. Esta función se usa para cambiar el formato de un valor y convertirlo en texto (por ejemplo, convertir el número 12.5 al texto '€12.50'). No combina datos de varias filas. D) CAST: Incorrecto en el contexto de la agregación. Esta función se usa para convertir un valor de un tipo de dato a otro (por ejemplo, convertir el texto '150' al número 150). Es un paso de preparación de datos que a menudo se realiza antes de poder aplicar una función de agregación (como SUM o AVG), pero CAST por sí misma no agrega nada.

Answer 392

D Accuracy is defined as "The degree of conformity of a measure to a standard or a true value". It is also noted that achieving accuracy often requires "accessing an external source of data that contains the true value," which is referred to as "gold standard" data

Answer 393

B Unique Constraints specify that "A field, or a combination of fields, must be unique across a dataset". An example given is that "no two persons can have the same social security number

Answer 394

C ✅ Respuesta Correcta: C C) Ancho pero corto; intentar obtener más datos. Terminología: La expresión "ancho pero corto" (en inglés, wide but short o short and wide) es la forma estándar de describir un conjunto de datos con muchas columnas (ancho) y muy pocas filas o registros (corto). Ancho: Se refiere al gran número de características o variables (las columnas). Corto: Se refiere al pequeño número de muestras u observaciones (las filas). Recomendación: Con tantos atributos y tan pocos ejemplos, un modelo de aprendizaje automático tiene un riesgo muy alto de sobreajuste (overfitting). Esto significa que el modelo podría aprender el "ruido" o las casualidades de los pocos datos que tiene, en lugar del patrón real y generalizable. La solución más fundamental y efectiva para este problema es intentar obtener más datos (más filas). Al aumentar el número de registros, le das al modelo más ejemplos para que aprenda patrones robustos y mejore su capacidad de generalización a datos nuevos. ❌ Respuestas Incorrectas: A, B y D A) Sesgo hacia la derecha; aplicar una transformación para normalizar los datos. El "sesgo" (skew) describe la distribución de los valores dentro de una sola columna, no la forma general de la tabla de datos. La normalización es una técnica para corregir distribuciones asimétricas, pero no resuelve el problema de tener muy pocos registros. B) Más alto que ancho; reducir el número de columnas para mejorar el rendimiento. "Más alto que ancho" (taller than wide o long and narrow) describe la situación opuesta: un conjunto de datos con muchas filas y pocas columnas, que suele ser el formato ideal. D) Sesgo pronunciado; usar GROUP BY y ORDER BY en SQL para identificar valores atípicos. Al igual que la opción A, esta se enfoca en el "sesgo" de una variable individual. Usar SQL para explorar los datos es una buena práctica, pero no aborda el problema central de la escasez de registros en comparación con el número de columnas.

Answer 395

A The sources explicitly state that "Blank or "" is not the same thing as a NULL. An empty string or blank is a valid data value whereas a NULL is the absence of any data". To filter out both NULL values and empty strings, the suggested SQL adjustment is WHERE state IS NOT NULL AND state <> ""

Answer 396

B "Recipes are a collection of wranglers". The sources further clarify that a recipe is a "Repeatable set of transformation steps build by chaining data wranglers together". When you are done writing your data transformation recipes, "you will then run your Dataprep job which processes your recipes against your entire dataset". "Dataprep flows are a collection of recipes

Answer 397

B Uniformity ensures that data uses the same units of measurement. Mixing metric and imperial units violates this principle.

Answer 398

A y B Técnicas Válidas ✅ A. IFNULL() Esta función es muy directa. Revisa un valor y, si es NULL, lo reemplaza por un valor por defecto que tú elijas. Su estructura es IFNULL(expresión, valor_si_es_nulo). Ejemplo: Imagina que tienes una columna email que a veces está vacía. Para reemplazar esos vacíos por un texto, harías: SELECT IFNULL(email, 'No proporcionado') FROM usuarios; Si el campo email contiene un correo, lo muestra. Si es NULL, muestra 'No proporcionado'. B. COALESCE() Esta función es como la navaja suiza 🇨🇭 para manejar nulos. Devuelve el primer valor que no sea NULL de una lista de valores que le proporciones. Es más potente que IFNULL porque puedes darle varias opciones. Ejemplo: Quieres obtener un número de contacto, dando prioridad al móvil, luego al fijo y, si no hay ninguno, poner un texto por defecto. SELECT COALESCE(telefono_movil, telefono_fijo, 'Sin contacto') FROM clientes; BigQuery revisará telefono_movil. Si no es NULL, lo devolverá. Si es NULL, pasará a telefono_fijo. Si tampoco es NULL, lo devolverá. Si ambos son NULL, devolverá 'Sin contacto'. Técnicas Inválidas ❌ C. GROUP BY Esta cláusula no tiene nada que ver con reemplazar valores. Su función es agregar filas para poder realizar cálculos sobre grupos de datos (como SUM(), COUNT(), AVG()). Agrupa todos los NULL en una misma categoría, pero no los reemplaza. D. NULLIF() Esta función hace justo lo contrario a lo que se pide: crea NULLs, no los elimina. Compara dos valores y, si son iguales, devuelve NULL. Si son diferentes, devuelve el primer valor. Ejemplo: A veces los datos faltantes no se guardan como NULL sino como un texto tipo "N/A". Para estandarizar tus datos, podrías usar NULLIF para convertir "N/A" en un NULL real. SELECT NULLIF(estado_pedido, 'N/A') FROM pedidos; Esto es útil para la limpieza de datos, pero no para "manejar" o reemplazar los NULLs existentes.

Answer 399

B Dataprep provides visual tools and suggestions for outliers, making this easier in the GUI than in SQL.

Answer 400

B Por qué la B (Completeness) es la correcta La Completitud (Completeness) es el principio de integridad de datos que se enfoca específicamente en si faltan datos. Un conjunto de datos se considera "completo" cuando todos los campos que son obligatorios o requeridos (required fields) tienen un valor. La pregunta ("...asegurando que todos los campos requeridos tengan valores") es la definición literal de completitud. Se trata de evitar valores nulos (NULL) o vacíos donde no deberían estar. Ejemplo: Si en un formulario de registro de usuarios el campo "Correo Electrónico" es obligatorio, un problema de completitud ocurre si se guarda un registro sin ese dato. Por qué las otras opciones son incorrectas A. Validity (Validez) La validez no se preocupa de si el campo está lleno, sino de si el valor que contiene sigue las reglas de formato definidas para ese campo. Por qué es incorrecta: Puedes tener un dato que sea "completo" (no está vacío) pero "inválido". Ejemplo: Si el campo "Fecha de Nacimiento" contiene el texto "hola", el campo está completo (tiene un valor), pero es inválido porque no tiene el formato de fecha correcto (p.ej., DD/MM/AAAA). C. Accuracy (Precisión / Exactitud) La precisión (o exactitud) mide si el dato, aunque esté completo y sea válido, es correcto y refleja la realidad. Por qué es incorrecta: Puedes tener un dato "completo" y "válido" que sea "inexacto". Ejemplo: Si tu dirección es "Calle Falsa 123" y en la base de datos escriben "Calle Falsa 124", el dato está completo (no está vacío) y es válido (es una dirección con formato correcto), pero es inexacto (no es tu dirección real). D. Consistency (Consistencia) La consistencia se asegura de que un mismo dato no se contradiga a sí mismo a través de diferentes sistemas o tablas. Por qué es incorrecta: La consistencia se preocupa por las contradicciones, no por los valores ausentes. Ejemplo: Si en la tabla de "Clientes" tu teléfono es "555-1111" pero en la tabla de "Envíos" tu teléfono es "555-2222",

Answer 401

A, C y D Validity is about data conforming to business rules, including range checks, mandatory values, and logic constraints. Duplicate records are a Consistency issue.

Answer 402

C The five principles of dataset integrity are Accuracy, Uniformity, Completeness, Consistency, and Validity. Scalability is not one of them

Answer 403

B To filter out rows with NULL values in a specific column, you use WHERE column IS NOT NULL. Note that empty strings ("") are not the same as NULLs.

Answer 404

A. B y C Validity is enforced through constraints such as data-type, range, and foreign-key constraints. Visualization constraints are not a recognized constraint for data validity.

Answer 405

B Uniformity refers to specifying data measures using the same units across all systems, which is crucial when combining data from different sources

Answer 406

B In Dataprep, a "recipe" is a repeatable set of transformation steps (wranglers) that are chained together to process and clean data

Answer 407

D As shown on slide 14, Uniformity is the principle that data measures should be specified using the same units across all systems. The failure to convert between metric and English systems is a classic example of a lack of uniformity. Explanation D) Uniformity: This principle dictates that data should be recorded using the same unit of measure across all datasets. The problem described, where acceleration is measured in both m/s² and ft/s², is a direct violation of uniformity. For data to be useful when combined, it must be in a uniform format. Why the other options are incorrect: A) Accuracy: Accuracy refers to how close a measured value is to the true value. The individual measurements (e.g., 9.8 m/s² or 32.2 ft/s²) could be perfectly accurate on their own, but their different units create the problem. B) Completeness: Completeness means that no data is missing. The problem isn't about missing acceleration values, but about the format of the existing values. C) Consistency: Consistency means that the same piece of data has the same value across different datasets. Uniformity is a specific type of consistency, but it more precisely refers to the units and format of the data, which is the core issue here.

Answer 408

C As discussed on slide 24, BigQuery treats NULL (the absence of a value) and an empty string ('') as two different things. state IS NOT NULL will filter out the NULL values but will still include the empty strings. state <> '' will filter out the empty strings but will not filter the NULLs. Therefore, you need both conditions to get only the rows with actual data.

Answer 409

B y E B) Para aplicar la Receta a tu conjunto de datos completo, debes ejecutar un "Job" (Trabajo). Esta afirmación es CIERTA. Dataprep funciona de la siguiente manera: para que la interfaz sea rápida y ágil, trabajas interactivamente sobre una muestra de tus datos. Cuando has terminado de definir todos los pasos de limpieza (la "Receta"), necesitas una forma de aplicar esa misma lógica a los millones de filas que pueden componer tu dataset completo. Ese proceso se lanza ejecutando un "Job" o Trabajo. Este Job utiliza la potencia de un motor de procesamiento de datos en segundo plano (normalmente Google Cloud Dataflow) para aplicar tu receta de forma masiva y escalable. E) Una "Recipe" (Receta) es una cadena de pasos de transformación que se puede aplicar a los datos. Esta afirmación es CIERTA. Esta es la definición exacta de una "Recipe". No es una sola acción, sino la secuencia ordenada de todas las transformaciones que has configurado. Por ejemplo, tu receta podría ser: Eliminar la columna "fecha_de_nacimiento". Reemplazar los valores vacíos de la columna "ciudad" por "desconocido". Crear una nueva columna "nombre_completo" uniendo "nombre" y "apellido". Esta lista de pasos, en ese orden, es tu "Recipe". Por qué A, C y D son incorrectas A) Una "Recipe" es una única función predefinida, como eliminar o derivar. Esta afirmación es FALSA. Confunde el todo con una de sus partes. Una "Recipe" no es una única función, sino que contiene un conjunto de funciones o pasos. "Eliminar" o "derivar" son ejemplos de pasos individuales de transformación que forman parte de una receta, pero no son la receta en sí misma. C) Un "Flow" (Flujo) es la secuencia ordenada de pasos de transformación individuales que has creado. Esta afirmación es FALSA. La descripción que da ("secuencia ordenada de pasos de transformación") es la definición de una "Recipe". Un "Flow" es un concepto de nivel superior. Es el contenedor visual que organiza uno o más conjuntos de datos (datasets) y las recetas asociadas a ellos. Puedes pensar en el "Flow" como el lienzo o el mapa de tu proyecto de preparación de datos, donde ves cómo los datos de entrada se conectan con las recetas para producir los datos de salida. D) La cuadrícula del transformador de Dataprep siempre muestra tu conjunto de datos completo, sin importar el tamaño. Esta afirmación es FALSA. De hecho, es todo lo contrario y uno de los puntos clave de Dataprep. La herramienta carga deliberadamente solo una muestra representativa de los datos en la cuadrícula de transformación. Hacer esto es lo que permite que la interfaz sea rápida e interactiva. Si intentara cargar un dataset de terabytes en el navegador, sería inviable y el sistema colapsaría.

Answer 410

C The entire second half of the presentation (starting from slide 25) highlights Cloud Dataprep's strengths as a graphical user interface (GUI) designed for visual data exploration, cleaning, and transformation. Its features, such as the data quality bar, suggestion cards, and live previews, are a perfect fit for a user who prefers a visual approach over writing code or SQL.

Answer 411

D The document lists five principles of dataset integrity: Validity, Accuracy, Completeness, Consistency, and Uniformity. Security is not included, as these principles focus on data quality and structure, not security measures.

Answer 412

A A right-skewed (positively skewed) distribution means most data points are on the left, with a long tail to the right, indicating a few high outliers. Esta es la parte que suele confundir a la gente. El nombre del sesgo ("a la derecha") no se refiere a dónde está la mayoría de los datos, sino a hacia dónde se extiende la "cola" larga de la distribución. Imagina un gráfico (como un histograma): El "cuerpo" o la "joroba": La mayoría de los valores de tus datos se agrupan, formando una especie de montaña o joroba en el gráfico. La "cola": Hay unos pocos valores que son mucho más altos que el resto. Estos valores "estiran" el gráfico hacia un lado, creando una cola larga y delgada. Cuando un conjunto de datos está sesgado a la derecha (en inglés, right-skewed o positive skew): La joroba (la mayoría de los datos) está en el lado izquierdo. La cola larga, formada por unos pocos valores atípicos muy altos, se extiende hacia el lado derecho. Un ejemplo clásico: Los salarios en un país. La gran mayoría de la gente tiene salarios en un rango bajo o medio (la joroba a la izquierda). Unas pocas personas (multimillonarios) tienen salarios extremadamente altos. Estos pocos valores "estiran" la distribución hacia la derecha, creando una cola larga. Por lo tanto, que esté "sesgado a la derecha" significa que la cola está a la derecha, lo que implica que el grueso de los datos está a la izquierda. Por qué las otras respuestas son incorrectas: B. La mayoría de los puntos de datos se concentran en el lado derecho de la distribución. Por qué es incorrecta: Esto describe exactamente lo contrario. Cuando la mayoría de los datos están a la derecha y la cola se extiende hacia la izquierda, el conjunto de datos se llama sesgado a la izquierda (left-skewed o negative skew). Ejemplo: Las notas de un examen muy fácil. La mayoría de los estudiantes sacarán notas altas (concentradas a la derecha), pero unos pocos sacarán notas muy bajas (la cola a la izquierda). C. El conjunto de datos tiene una distribución simétrica. Por qué es incorrecta: La palabra "sesgado" significa literalmente "asimétrico" o "no simétrico". Una distribución simétrica (como la famosa "campana de Gauss") no tiene sesgo. Los datos se reparten por igual a ambos lados del centro. D. El conjunto de datos no tiene valores atípicos (outliers). Por qué es incorrecta: Esta afirmación es casi lo opuesto a la realidad. El sesgo, de hecho, a menudo es causado por la presencia de valores atípicos. En un conjunto de datos sesgado a la derecha, son precisamente esos valores atípicos (muy altos) los que crean la cola larga hacia la derecha. Si no hubiera outliers, la distribución sería probablemente mucho más simétrica. Resumen Clave para Recordar: La dirección del sesgo (derecha o izquierda) te dice hacia dónde apunta la cola larga del gráfico, no dónde está la mayor concentración de datos. Sesgo a la Derecha: Cola a la derecha -> Datos concentrados a la izquierda. Sesgo a la Izquierda: Cola a la izquierda -> Datos concentrados a la derecha.

Answer 413

C In Dataprep, a "recipe" is a sequence of transformation steps (or "wranglers") chained together to automate data cleaning and preparation processes.

Answer 414

B La respuesta correcta es B. Viewing histograms and summary statistics (Ver histogramas y estadísticas de resumen). Explicación Detallada ¿Por qué la opción B es la correcta? El "monitoreo de la calidad de los datos" se refiere a la capacidad de observar, entender y evaluar el estado de tus datos. Dataprep está diseñado precisamente para esto a través de su interfaz visual. Cuando cargas un conjunto de datos en Dataprep, la herramienta genera automáticamente un perfil de datos para cada columna. Este perfil incluye: Histogramas: Gráficos de barras que muestran la distribución de los valores en una columna. Te permiten ver de un vistazo qué valores son más frecuentes, si la distribución es normal o sesgada, y detectar posibles valores atípicos (outliers). Estadísticas de resumen: Proporcionan métricas clave como el número de filas, la cantidad de valores únicos, la cantidad de valores faltantes (missing) y la cantidad de valores que no coinciden con el tipo de dato esperado (mismatched). Barras de calidad: Una barra visual en la parte superior de cada columna que te indica con colores el porcentaje de valores válidos (verde), no coincidentes (rojo) y faltantes (gris). Estas herramientas visuales y estadísticas son el núcleo de cómo un usuario monitorea y diagnostica la calidad de los datos antes de empezar a transformarlos. Te dan una visión completa del "estado de salud" de tu dataset. ¿Por qué las otras opciones son incorrectas? A. Crear campos calculados: Esto es una acción de transformación de datos o enriquecimiento. Se usa para crear nuevas columnas a partir de las existentes (por ejemplo, concatenar nombre y apellido). Si bien puedes usarlo para solucionar un problema de calidad, la acción en sí misma es de transformación, no de monitoreo. Primero monitoreas (opción B) y luego, si es necesario, transformas (opción A). C. Programar trabajos a BigQuery: Esto es una función de operacionalización. Una vez que has definido todos tus pasos de limpieza y transformación (lo que se conoce como una "receta"), puedes programar un trabajo para que se ejecute automáticamente y envíe el resultado limpio a un destino como BigQuery. Esto es parte de la ejecución del pipeline, no del análisis o monitoreo de la calidad de los datos de entrada. D. Manejar valores faltantes con COALESCE(): Al igual que la opción A, esta es una acción específica de limpieza o transformación de datos. La función COALESCE() se usa para reemplazar valores nulos o faltantes por otro valor. Es el remedio para un problema de calidad de datos que previamente has identificado. La detección del problema (ver cuántos valores faltantes hay) es el monitoreo, lo cual se hace con las herramientas de la opción B. COALESCE() es la solución que aplicas después.

Answer 415

A, B y C Respuestas correctas: A, B y C A. Interacting with a dataset visually is often faster than writing SQL to derive insights. (La interacción visual con datos suele ser más rápida que escribir SQL para obtener conclusiones). ¿Por qué es correcto? Esta es una de las mayores ventajas. Para un analista que quiere explorar los datos, es mucho más rápido arrastrar y soltar campos en un gráfico, aplicar filtros con un clic o cambiar el tipo de visualización que escribir, depurar y ejecutar múltiples consultas SQL. Permite una exploración ágil y rápida. ⚡️ B. Visualizing a dataset allows users to spot hidden trends. (Visualizar un conjunto de datos permite a los usuarios detectar tendencias ocultas). ¿Por qué es correcto? El cerebro humano es increíblemente bueno para reconocer patrones, anomalías y relaciones de forma visual. Un gráfico de líneas puede revelar al instante una tendencia estacional, un gráfico de dispersión puede mostrar una correlación y un mapa de calor puede resaltar clústeres que serían casi imposibles de ver mirando una tabla con miles de filas. 🧠 C. BigQuery-backed visualization tools offer scalable performance, even with billion+ row datasets. (Las herramientas de visualización conectadas a BigQuery ofrecen un rendimiento escalable, incluso con miles de millones de filas). ¿Por qué es correcto? Así funcionan las herramientas de BI modernas (como Looker Studio). En lugar de descargar los miles de millones de filas, la herramienta de visualización envía una consulta optimizada a BigQuery. BigQuery, con su arquitectura masiva, procesa los datos y devuelve solo el resultado agregado que se necesita para el gráfico. Esto permite tener cuadros de mando interactivos sobre volúmenes de datos enormes sin sacrificar el rendimiento. 📈 ¿Por qué la D es incorrecta? D. Visualization tools completely eliminate the need for SQL queries for data analysis. (Las herramientas de visualización eliminan por completo la necesidad de consultas SQL para el análisis de datos). ¿Por qué es incorrecto? La palabra clave aquí es "completamente". Esto es una exageración y es falso. Las herramientas de visualización son una capa que facilita la exploración, pero no reemplazan a SQL. A menudo, se necesita SQL para: Realizar una limpieza y preparación de datos compleja antes de la visualización. Crear métricas personalizadas muy específicas. Unir múltiples tablas de formas complejas. Las herramientas de visualización y SQL son complementarios, no excluyentes. Trabajan juntos. ❌

Answer 416

C y D 🎯 La Regla Clave: Medidas vs. Dimensiones En un conjunto de datos para análisis (como en Business Intelligence o Data Warehousing): Medidas (measures): Son los valores numéricos que se pueden agregar, sumar, promediar, contar o calcular. Representan cantidades que quieres analizar. Dimensiones (dimensions): Son los atributos que se utilizan para categorizar, segmentar o agrupar las medidas. Normalmente son valores de texto o números que se usan como identificadores o descriptores. ✅ Respuestas Correctas (Medidas) Las siguientes se clasifican como medidas porque son valores numéricos con significado cuantitativo y son aptas para cálculos matemáticos: C. Age (Edad): Es un valor numérico que representa una cantidad (los años de vida). Puedes promediar la edad de un grupo de empleados, sumar o contar empleados dentro de rangos de edad, o comparar la edad promedio entre departamentos. Por lo tanto, es una medida. D. Tenure at work (in years) (Antigüedad en el trabajo en años): Es un valor numérico que representa una cantidad (los años trabajados). Puedes calcular la antigüedad promedio de la fuerza laboral, contar cuántos empleados tienen más de 5 años de antigüedad, o sumar la antigüedad total. Por lo tanto, es una medida. ❌ Respuestas Incorrectas (Dimensiones/Identificadores) Las siguientes son incorrectas porque son usadas como atributos o identificadores, no como valores para ser calculados o agregados de forma significativa: A. Phone number (Número de teléfono): Aunque es numérico, no tiene significado cuantitativo. No tendría sentido sumar o promediar los números de teléfono. Se usa para identificar y contactar a una persona. Es una dimensión o un identificador. B. Employee ID (ID de empleado): Es un identificador único (numérico o alfanumérico). No tendría sentido sumar o promediar los IDs de empleado. Se usa para identificar registros. Es una dimensión o un identificador. E. Job title (Título del puesto de trabajo): Es una categoría de texto (como "Gerente", "Analista"). Se usa para agrupar (por ejemplo, ver la edad promedio por título de puesto). No se puede calcular, sumar o promediar. Es una dimensión. En resumen: Edad y Antigüedad son cantidades que se miden (measures), mientras que las otras opciones son etiquetas o identificadores (dimensions).

Answer 417

B y C Por qué las Opciones B y C son CORRECTAS (Buenas) B. Crear tablas de informes permanentes que pre-calculan campos, aunque los datos puedan estar ligeramente obsoletos. Por qué es buena: Esta es la estrategia fundamental. En lugar de hacer que el dashboard consulte una tabla con mil millones de filas cada vez que se abre, creas una "tabla de informes" (reporting table) que ya tiene los cálculos hechos (por ejemplo, ventas totales por día). Consultar esta tabla, que quizás solo tiene mil filas, es infinitamente más rápido. La concesión: El precio que pagas por esta velocidad es que los datos no son en tiempo real. Si la tabla de informes se actualiza cada hora, tus datos pueden tener hasta 59 minutos de "antigüedad" (stale). Para la mayoría de los dashboards, este es un intercambio aceptable. C. Utilizar consultas programadas en BigQuery para actualizar automáticamente las tablas de informes a intervalos regulares. Por qué es buena: Esta opción es la implementación de la opción B. ¿Cómo te aseguras de que esas "tablas de informes" (mencionadas en B) no se queden demasiado obsoletas? Usas una herramienta como las consultas programadas (scheduled queries) de BigQuery. Cómo funciona: Puedes programar la consulta que crea tu tabla de informes (opción B) para que se ejecute automáticamente cada hora, cada 30 minutos, o una vez al día. Esto mantiene los datos razonablemente frescos sin sacrificar el rendimiento del dashboard, ya que el trabajo "pesado" de la consulta se hace en segundo plano, no cuando el usuario carga el informe.

Answer 418

A, B y D Respuestas Correctas: A, B y D ✅ A. Looker Studio permite a los usuarios crear dashboards interactivos e informes desde una amplia variedad de fuentes de datos. Explicación: Esta es la descripción principal y el propósito fundamental de Looker Studio. Es una herramienta de visualización diseñada para conectarse a cientos de fuentes de datos (Google Analytics, BigQuery, Google Sheets, bases de datos SQL, etc.) y transformarlos en informes y dashboards fáciles de entender e interactivos para el usuario final. B. Looker Studio puede conectar a múltiples tipos de fuentes de datos diferentes dentro de un solo informe. Explicación: Esta es una de las capacidades más potentes de la herramienta, conocida como "combinación de datos" (data blending). Puedes tener un solo informe que muestre gráficos de Google Analytics, tablas de una hoja de cálculo de Google Sheets y métricas de una base de datos de BigQuery. Esto permite crear vistas unificadas a partir de datos que viven en sistemas completamente diferentes. D. Looker Studio soporta la creación de campos calculados directamente dentro de la UI usando fórmulas como sentencias CASE. Explicación: Correcto. No siempre necesitas que los datos estén perfectamente preparados en la fuente original. Looker Studio tiene un editor de fórmulas muy potente que permite crear nuevas dimensiones o métricas sobre la marcha. Puedes usar funciones matemáticas, de texto, de fecha y lógica condicional (como CASE...WHEN...THEN...END) para transformar y enriquecer tus datos directamente en el informe. ¿Por qué las otras opciones son incorrectas? ❌ C. Al compartir un informe de Looker Studio con permiso de visualización, siempre se requiere un inicio de sesión de Google para que el espectador acceda a él. Explicación: La palabra clave aquí es "siempre", lo que hace que la afirmación sea falsa. Looker Studio tiene opciones de uso compartido flexibles, similares a las de Google Drive. Si bien puedes compartirlo con usuarios específicos de Google, también puedes configurar el acceso para que "Cualquier persona con el enlace pueda ver". En este modo público, no se requiere ningún inicio de sesión de Google. E. Compartir un informe de Looker Studio comparte automáticamente el acceso directo a las fuentes de datos añadidas. Explicación: Esto es incorrecto y sería un fallo de seguridad grave. Looker Studio funciona como una capa de abstracción segura. El informe utiliza las credenciales del propietario de la fuente de datos (o credenciales de una cuenta de servicio) para consultar la información. Cuando compartes un informe con un "visualizador", solo le das acceso a la visualización de los datos, no a la fuente de datos subyacente. El espectador no puede usar el informe para acceder directamente a tu tabla de BigQuery o a tu Google Sheet. En Resumen A, B, D describen las fortalezas principales de Looker Studio: es una herramienta de visualización (A), que puede unificar diferentes fuentes (B) y permite la transformación de datos dentro de la propia herramienta (D). C y E describen incorrectamente su modelo de compartición y seguridad: la compartición es flexible (C) y siempre protege el acceso a la fuente de datos original (E).

Answer 419

A y D Estas dos afirmaciones capturan la esencia teórica y la aplicación práctica del procesamiento preatentivo. ✅ A. El procesamiento preatentivo involucra características que se extraen de forma rápida, sin esfuerzo y en paralelo sin atención enfocada. Esta es la definición técnica del concepto. El procesamiento preatentivo es una función de bajo nivel del sistema visual humano que ocurre en una fracción de segundo (menos de 250 milisegundos). Nuestro cerebro detecta automáticamente ciertas características visuales básicas (como el color, la forma, el tamaño o la orientación) en todo nuestro campo visual a la vez (en paralelo), antes de que decidamos conscientemente dónde enfocar nuestra atención. Por ejemplo, puedes encontrar instantáneamente el punto rojo en la imagen de abajo sin tener que escanear cada punto uno por uno. ✅ D. El objetivo de usar atributos preatentivos es permitir que la audiencia entienda tu mensaje sin requerir su atención enfocada, dejando esa atención para lo que estás diciendo. Esta es la aplicación práctica de la teoría en la visualización de datos y presentaciones. Al usar un atributo preatentivo (por ejemplo, colorear una barra de un gráfico de un color diferente), haces que la información más importante "salte a la vista". Esto reduce la carga cognitiva de tu audiencia. No tienen que gastar energía mental en buscar el dato clave; su sistema visual lo hace por ellos. Esto libera su valiosa atención enfocada para que puedan escuchar tu explicación, procesar el significado de los datos y pensar en las implicaciones. Las respuestas incorrectas: B y C Estas afirmaciones confunden el procesamiento preatentivo con otros conceptos cognitivos. ❌ B. Usar la codificación visual ayuda a resaltar información relevante de una manera que aprovecha el espacio de atención de un espectador. Esta afirmación es sutilmente incorrecta. El procesamiento preatentivo funciona precisamente porque opera en el sistema pre-atentivo, no en el atento. Procesamiento Preatentivo: Es automático, rápido y paralelo. No requiere esfuerzo consciente. Procesamiento Atento (o enfocado): Es consciente, lento y en serie (procesamos una cosa a la vez). Requiere esfuerzo. El objetivo de los atributos preatentivos es guiar la atención hacia dónde debe enfocarse, pero el mecanismo en sí mismo no "aprovecha el espacio de atención", sino que lo precede. ❌ C. El procesamiento preatentivo se caracteriza por el uso de la memoria a corto plazo, que retiene como máximo 4 trozos de información. Esta afirmación mezcla dos conceptos distintos de la psicología cognitiva. El procesamiento preatentivo es parte de la percepción visual inicial y la memoria sensorial (o icónica), que es casi instantánea. La memoria a corto plazo, que tiene una capacidad limitada (aproximadamente 4 "trozos" o chunks de información), es donde procesamos la información de forma consciente después de que ha pasado por el filtro de la atención.

Answer 420

A, C y D Preattentive attributes are visual properties like color, line length, and flicker that the brain processes quickly and unconsciously to identify patterns or outliers. Chart titles are not considered preattentive attributes. ✅ Por qué A, C y D son correctas A) Color 🎨: Un punto de un color diferente en un mar de puntos de otro color se detecta inmediatamente. Es uno de los atributos preatentivos más potentes para categorizar datos o resaltar valores específicos. C) Longitud de línea 📊: En un gráfico de barras, no necesitas medir cada barra para saber cuál es la más larga o la más corta. Tu cerebro percibe la diferencia en longitud de forma instantánea. D) Parpadeo (Flicker) ✨: El movimiento es uno de los atributos que más llaman la atención. Un elemento que parpadea en una pantalla estática es imposible de ignorar. Aunque es muy efectivo, debe usarse con moderación, ya que puede resultar molesto. ❌ Por qué B es incorrecta B) Título del gráfico 📖: Leer y comprender un título requiere un procesamiento consciente y enfocado. Debes leer las palabras, interpretar su significado y entender el contexto del gráfico. Este es un proceso atentivo, lo opuesto a preatentivo. El título proporciona un contexto crucial, pero solo después de que decidimos conscientemente leerlo.

Answer 421

B Measures are quantitative fields (e.g., revenue, salary) that can be aggregated or used in mathematical operations. Qualitative or categorical fields (like employee ID or job title) are typically dimensions.

Answer 422

A y B A) Small-dataset performance even on massive datasets ¿Por qué es buena? Esta es una frase muy común en la documentación de Google. Significa que, gracias a la arquitectura de procesamiento masivo en paralelo de BigQuery, puedes consultar petabytes de datos y obtener una respuesta en pocos segundos, con una velocidad que normalmente solo esperarías al trabajar con un archivo de Excel pequeño (small-dataset). Básicamente, dice que el tamaño del dato no degrada la experiencia del usuario. B) Ability to visualize data without writing SQL ¿Por qué es buena? Esta es la propuesta de valor principal de Looker Studio. Permite que usuarios de negocio (que no saben programar) utilicen una interfaz de arrastrar y soltar (drag-and-drop) para crear gráficos. Aunque por detrás Looker Studio traduce esas acciones a SQL para BigQuery, el usuario final no necesita ver ni escribir una sola línea de código. Respuestas Incorrectas: C y D C) Visuals load instantly, even without cache ¿Por qué es mala? Aunque BigQuery es muy rápido, no es "instantáneo" por arte de magia. Una consulta compleja sobre miles de millones de filas puede tardar unos segundos. Para que sea instantáneo, se necesita precisamente de la caché o de servicios adicionales como BigQuery BI Engine. Decir que es instantáneo "incluso sin caché" es técnicamente falso y exagerado. D) Automatically applies machine learning models ¿Por qué es mala? BigQuery tiene una función potente llamada BigQuery ML (BQML), pero no es automática. Un analista o ingeniero debe crear, entrenar y ejecutar el modelo de machine learning manualmente usando SQL. Looker Studio puede mostrar los resultados de esos modelos, pero no los "aplica automáticamente" por el simple hecho de conectar la herramienta.

Answer 423

B Dashboards powered by SQL views query raw data every time, which can cause performance issues. Precomputed tables load faster but may not be as fresh.

Answer 424

C Por qué la C es CORRECTA Query Cache (Caché de Consultas): Qué es: Es la caché estándar y automática. También se le conoce como "caché receptiva". Cómo funciona: Cuando abres un informe o cambias un filtro, Looker Studio ejecuta una consulta a tu fuente de datos (ej. BigQuery). Guarda los resultados de esa consulta específica en una memoria temporal. Si tú u otro usuario realizan la misma acción (ej. cargan la misma página con los mismos filtros) antes de que la caché expire (normalmente cada 12 horas), Looker Studio entrega los resultados guardados instantáneamente, sin volver a consultar la base de datos. Propósito: Mejorar la velocidad de interacción con el informe (filtrar, cambiar de página). Prefetch Cache (Caché de Precarga): Qué es: Es una función avanzada (disponible en Looker Studio Pro) que es proactiva en lugar de reactiva. Cómo funciona: En lugar de esperar a que un usuario cargue el informe, el "prefetch cache" te permite programar que las consultas del informe se ejecuten en segundo plano a intervalos regulares (ej. cada 30 minutos). Propósito: Mejorar drásticamente el tiempo de carga inicial del informe. Cuando un usuario abre el informe por primera vez ese día, los datos ya están listos y esperando en la caché, por lo que la carga es casi instantánea. Por qué las otras opciones son INCORRECTAS A. Predictive cache and SQL cache: Incorrecto. "Predictive cache" (caché predictiva) no es un término oficial de Looker Studio, aunque "prefetch" es conceptualmente similar. "SQL cache" es demasiado genérico; el "query cache" guarda los resultados de las consultas SQL, pero no se llama así. B. Data source cache and view cache: Incorrecto. "Data source cache" es vago; la caché se aplica a la fuente de datos, pero no es su nombre. "View cache" (caché de vista) tampoco es un término de Looker Studio; se almacenan en caché las consultas, no la "vista" del informe en sí. D. Manual cache and auto cache: Incorrecto. Esto describe cómo se podría gestionar una caché, no los tipos de caché. El "Query Cache" es automático ("auto"), y el "Prefetch Cache" se configura manualmente pero se ejecuta automáticamente. No son los nombres de las funciones.

Answer 425

C This question addresses the common pitfall discussed on slides 17-19. A view queries raw data every time, leading to slow performance on large datasets (performance intensive but fresh). Manually creating a table (Option B) makes the data stale. The optimal solution is to use a scheduled query. It automatically refreshes a materialized table on a regular cadence (daily), providing the balance of fast query performance (querying a smaller, pre-aggregated table) and acceptable data freshness.

Answer 426

A, C y D ¿Qué es un "Atributo Preatentivo"? Un atributo preatentivo es una característica visual que nuestro cerebro procesa de forma casi instantánea (en menos de 250 milisegundos) y sin esfuerzo consciente. Son las cosas que, literalmente, "saltan a la vista" en una visualización antes de que te pongas a analizarla en detalle. El objetivo es usar estos atributos para guiar la mirada del usuario hacia lo más importante. A) Tono de Color (Correcta) 👍 El color es uno de los atributos preatentivos más potentes. Si tienes un montón de puntos grises y uno rojo, tu cerebro detectará el punto rojo inmediatamente, sin necesidad de escanear uno por uno. Por qué es correcta: La diferencia de color se procesa de forma automática para destacar elementos. C) Tamaño (Correcta) 👍 Al igual que el color, el tamaño destaca de forma natural. Un círculo mucho más grande en un grupo de círculos pequeños captará tu atención al instante. No necesitas medir cada círculo para saber cuál es el más grande. Por qué es correcta: Nuestro cerebro es muy bueno detectando rápidamente diferencias de tamaño. D) Posición Espacial (Correcta) 👍 La ubicación de un objeto en relación con otros es algo que también procesamos de inmediato. Un punto de datos que está muy alejado de un grupo principal (un outlier en un gráfico de dispersión) se identifica al instante. Por qué es correcta: La posición relativa se percibe sin necesidad de un análisis consciente. B) El valor numérico específico (Incorrecta) 👎 Este es el único atributo que no es preatentivo. Para saber que un punto de datos vale "1.452,7", necesitas realizar un proceso atentivo y consciente: Encontrar la etiqueta o el número. Enfocar tu vista en él. Leer los dígitos. Procesar mentalmente su valor. Este proceso requiere tiempo y esfuerzo cognitivo. No es algo que "salte a la vista". Por qué es incorrecta: Leer e interpretar un número es una tarea deliberada, no un reflejo visual instantáneo.

Answer 427

A As defined on slide 13, "Dimensions and measures," a dimension is typically a categorical, independent variable (the "what you are grouping by"), such as a name or category. A measure is a dependent, quantitative variable (the "what you are counting or aggregating"), such as revenue, salary, or a count. In this scenario, "Product category" is the dimension, while "Average order value" and "Count of errors" are the quantitative measures.

Answer 428

A El Concepto Clave: Permisos del Informe vs. Permisos de la Fuente de Datos Esta pregunta pone a prueba tu comprensión de la separación fundamental entre los permisos en Looker Studio (el informe) y los permisos en la fuente de datos subyacente (BigQuery). Cuando creas una fuente de datos en Looker Studio (por ejemplo, conectándote a una tabla de BigQuery), debes elegir las "Credenciales de los Datos": Credenciales del Propietario (Owner's Credentials): Este es el modo más común y seguro. Significa que el informe siempre consultará BigQuery usando los permisos de la persona que creó la fuente de datos. Credenciales del Lector (Viewer's Credentials): Esto significa que el informe intentará consultar BigQuery usando los permisos de la persona que está viendo el informe. Asumiendo el escenario estándar (Credenciales del Propietario), que es el implicado en la pregunta, analicemos las opciones: La Respuesta Correcta A) El mánager de ventas puede ver los datos presentados en el informe pero no puede acceder a la tabla de BigQuery subyacente directamente a través de la conexión de Looker Studio. Por qué es correcta: Esto describe perfectamente el escenario. "Puede ver los datos presentados en el informe": Sí, para eso le diste el permiso de "Viewer" (Lector) en el informe. "Pero no puede acceder a la tabla de BigQuery subyacente": Correcto. El permiso de "Viewer" del informe no otorga ningún permiso en BigQuery (es decir, ningún rol de IAM como bigquery.dataViewer). El mánager solo ve el resultado de las consultas que el informe ejecuta usando las credenciales del propietario de la fuente de datos. Las Respuestas Incorrectas B) El mánager de ventas puede ahora usar la consola de BigQuery para ejecutar consultas SELECT * contra la tabla usada en el informe. Por qué es incorrecta: Compartir un informe de Looker Studio nunca concede permisos en la consola de Google Cloud / BigQuery. Son sistemas de permisos completamente separados. C) El mánager de ventas no podrá ver los datos del informe a menos que también le concedas el rol IAM bigquery.dataViewer en la tabla de origen. Por qué es incorrecta: Esto solo sería cierto si la fuente de datos se hubiera configurado explícitamente para usar "Credenciales del Lector". En la configuración estándar y por defecto ("Credenciales del Propietario"), el mánager puede ver los datos perfectamente sin necesidad de tener ningún rol de IAM en BigQuery. D) El mánager de ventas puede ver el informe y también crear sus propios gráficos dentro de ese informe usando la fuente de datos existente. Por qué es incorrecta: Esta acción (crear gráficos, editar el informe) requiere el permiso de "Editor". El mánager solo recibió permiso de "Viewer" (Lector), que, como su nombre indica, solo le permite ver e interactuar con los filtros existentes, pero no editar el lienzo ni añadir nuevos componentes.

Answer 429

D This question relates to choosing effective visuals (slides 10-11). A Pie or Donut chart is specifically designed to show a part-to-whole relationship, where different segments represent proportions of a total. A Line Chart is best for showing trends over time. A Scatter Plot is for observing relationships between two numeric variables. While a Bar Chart could be used, a Pie/Donut chart more intuitively represents the concept of market share as a percentage of a whole.

Answer 430

B El objetivo fundamental de la visualización de datos es traducir datos complejos y en bruto (como tablas llenas de números) a un formato gráfico (como diagramas de barras, gráficos de líneas, mapas de calor, etc.). La razón por la que hacemos esto se explica al analizar cada opción: ✅ B) Ayuda a detectar tendencias y patrones ocultos (Correcta) Este es el superpoder de la visualización de datos. El cerebro humano está increíblemente bien adaptado para procesar información visual de manera rápida y eficiente. Es mucho más fácil y rápido para una persona: Ver una tendencia ascendente en un gráfico de líneas. Identificar un valor atípico (outlier) que se sale de la norma en un diagrama de dispersión. Comparar categorías al instante en un gráfico de barras. Descubrir un patrón o una correlación entre dos variables. Estos conocimientos a menudo están "ocultos" en las filas y columnas de una hoja de cálculo y serían muy difíciles, si no imposibles, de detectar simplemente mirando los números. La visualización los hace evidentes. ❌ A) Permite una entrada de datos más rápida (Incorrecta) Esta opción confunde la entrada de datos con la presentación de datos. La visualización ocurre después de que los datos han sido ingresados y recopilados. No tiene nada que ver con el proceso de introducir la información en un sistema. ❌ C) Reduce la necesidad de consultas SQL (Incorrecta) Esto es lo contrario de la realidad. Para crear una visualización, primero necesitas obtener los datos correctos de una base de datos, y la forma más común de hacerlo es mediante consultas SQL. De hecho, las visualizaciones complejas a menudo requieren consultas SQL complejas para agregar, filtrar y dar forma a los datos antes de que puedan ser graficados. Las herramientas de visualización no reemplazan a SQL; dependen de él. ❌ D) Automatiza los procesos de limpieza de datos (Incorrecta) La limpieza de datos (corregir errores, eliminar duplicados, manejar valores faltantes) es un paso crucial que se realiza antes del análisis y la visualización. Si bien una visualización puede ayudarte a identificar problemas en tus datos (por ejemplo, un punto de datos que parece un error), no automatiza el proceso de limpieza en sí. La limpieza se realiza con otras herramientas o scripts (como Python, R o el propio SQL). En Resumen La razón principal por la que transformamos datos en gráficos es para aprovechar la capacidad de nuestro cerebro para reconocer patrones visuales, permitiéndonos así descubrir ideas y conocimientos que de otro modo permanecerían ocultos en tablas de datos.

Answer 431

C Dimensions describe characteristics or labels (e.g., product name, date), while measures are numerical values that can be aggregated (e.g., sales amount, number of units), as defined in the certification material.

Answer 432

A Scheduled queries in BigQuery run periodically and save results to a table, ensuring reports are up-to-date without manual intervention, as covered in the syllabus.

Answer 433

A Looker Studio supports real-time collaboration, allowing multiple users to work on reports simultaneously, and connects to various data sources, as noted in the certification material.

Answer 434

C The 80/20 rule suggests analysts spend 80% of their time on data preparation and 20% on visualization, with audiences focusing almost entirely on the visualization output, as mentioned in the syllabus.

Answer 435

C Source indicates that "Re-running the same query will likely hit the cached temporary table" under conditions like the underlying table not being modified or dynamic functions not being used. Sources clarify that temporary tables are automatically created if a permanent destination is not specified, and they typically last for 24 hours.

Answer 436

C Source states that for logical views, "The underlying query is executed each time the view is accessed." In contrast, source explains that "materialized views are precomputed views that periodically cache the results of a query for increased performance and efficiency," implying they do not execute the full underlying query every time.

Answer 437

B y C Source states that "BigQuery does not guarantee data consistency for external data sources" and "Query performance for external data sources may not be as high as querying data in a native BigQuery table." Source explicitly mentions that "You cannot reference an external data source in a wildcard table query" and "You cannot run a BigQuery job that exports data from an external data source.

Answer 438

B ✅ La Afirmación Correcta: B B) El método tabledata().insertAll() permite consultar los datos sin esperar a una carga por lotes completa. Esta es la definición y la ventaja fundamental del streaming en BigQuery. ¿Por qué es correcto? El método tabledata().insertAll() es el corazón de la API de streaming. Cuando envías filas de datos con este método, BigQuery las introduce en un búfer de streaming y las hace disponibles para ser consultadas en cuestión de segundos. No necesitas esperar a que se complete un gran trabajo de carga (batch load). Caso de uso: Esto es crucial para aplicaciones que necesitan analizar datos en tiempo real, como paneles de control de monitorización, detección de fraudes o análisis de logs de aplicaciones al momento. Analogía 💡: Usar la API de streaming es como tuitear. Tan pronto como publicas el tuit, tus seguidores pueden verlo. Una carga por lotes (batch load) sería como escribir un libro entero y publicarlo; la gente tiene que esperar a que esté completamente terminado para poder leerlo. ❌ Las Afirmaciones Incorrectas: A, C y D A) Los datos en streaming se utilizan principalmente para el procesamiento por lotes de registros históricos. Esto es conceptualmente incorrecto; es una contradicción directa. ¿Por qué es falso? El streaming es para flujos de datos continuos y en tiempo real. El procesamiento por lotes (batch) es para cargar grandes volúmenes de datos de una sola vez, típicamente datos históricos. Son dos paradigmas opuestos. C) El tamaño máximo de fila para el streaming es ilimitado, lo que permite registros individuales muy grandes. Esto es factualmente incorrecto. Prácticamente ningún servicio en la nube ofrece recursos "ilimitados". ¿Por qué es falso? BigQuery tiene límites definidos para el tamaño máximo de una fila que se puede insertar vía streaming. Estos límites existen para garantizar el rendimiento y la estabilidad del servicio. Intentar insertar una fila que exceda este límite resultará en un error. D) Los datos en streaming garantizan la coherencia de los datos y eliminan la posibilidad de datos duplicados. Esta afirmación es demasiado fuerte y no es cierta. La palabra clave aquí es "garantiza". ¿Por qué es falso? La API de streaming de BigQuery ofrece una semántica de entrega de "al menos una vez" (at-least-once). Esto significa que, en caso de incertidumbre en la red o reintentos, es posible que la misma fila se inserte más de una vez. BigQuery ofrece mecanismos como el insertId para una deduplicación de "mejor esfuerzo" durante un corto período, pero no garantiza la eliminación de todos los duplicados. Si se requiere una unicidad estricta, el usuario debe implementar una lógica de deduplicación posterior a la carga.

Answer 439

B Sources consistently state that "All query results are stored in tables (regardless if you save as table)" and "If you don’t create one, a temp one is created (per user, per project) and is saved for 24 hours". This confirms that results are always saved to a table, either temporary or permanent

Answer 440

C If no destination table is specified, BigQuery creates a temporary table which is cached and stored for 24 hours.

Answer 441

C Por qué la opción C es la correcta Una "vista" estándar en BigQuery (a veces llamada "vista lógica") no es una tabla que almacene datos. Es, fundamentalmente, una consulta SQL guardada a la que se le ha dado un nombre. Es una tabla "virtual": Actúa como una máscara o un atajo para una consulta más compleja. Ejecución en tiempo real: Cuando tú haces SELECT * FROM mi_vista, BigQuery no lee datos de "mi_vista". En su lugar, toma la consulta SQL que define "mi_vista" (que podría ser un JOIN complejo entre 5 tablas) y la ejecuta en ese preciso momento. Costos: Por esta razón, se te factura por los datos escaneados por la consulta subyacente de la vista, no por la vista en sí (que no almacena nada). Por qué las otras opciones son incorrectas A) Views store precomputed results for faster performance (Las vistas almacenan resultados precalculados para un rendimiento más rápido): Esto es falso. Esta declaración describe una Materialized View (Vista Materializada), que es un tipo de objeto diferente en BigQuery. Las vistas materializadas sí almacenan el resultado de la consulta y lo actualizan periódicamente para acelerar el rendimiento, pero una vista estándar (lógica) no lo hace. B) You cannot export data from a view using a BigQuery job (No puedes exportar datos desde una vista usando un trabajo de BigQuery): Esto es falso. Puedes exportar datos desde una vista perfectamente. Cuando ejecutas un trabajo de exportación sobre una vista, BigQuery primero ejecuta la consulta SQL de la vista (como dice la opción C) y luego exporta el conjunto de resultados de esa consulta a un archivo (por ejemplo, en Google Cloud Storage). D) Views support up to 100 levels of nesting in standard SQL (Las vistas soportan hasta 100 niveles de anidamiento en SQL estándar): Esto es falso. El "anidamiento" se refiere a una vista que consulta a otra vista, que a su vez consulta a otra vista, etc. Google Cloud tiene un límite para esto, pero no es 100. Según la documentación oficial de BigQuery, el límite de anidamiento para las vistas es de 16 niveles. 100 es un número incorrecto.

Answer 442

D Querying external data can suffer from performance disadvantages, and consistency is not guaranteed.

Answer 443

A y D Análisis de la ingesta de datos por streaming en BigQuery A) Soporta un tamaño máximo de fila de 1MB - ✅ Correcta Esta es una de las cuotas documentadas para la ingesta por streaming. Cada fila que envías a BigQuery a través de este método no puede superar 1 MB de tamaño después de ser convertida a formato JSON. Es un límite importante a tener en cuenta al diseñar el esquema y los datos que se van a enviar. D) Usa el método tabledata().insertAll() - ✅ Correcta Este es el nombre del método en la API REST de BigQuery que se utiliza para realizar la ingesta de datos por streaming. Aunque hoy en día Google recomienda la Storage Write API para escenarios de alto rendimiento, tabledata.insertAll es el método clásico, sigue siendo válido y es la respuesta correcta en este contexto. Por qué las otras opciones son incorrectas B) Puede ingestar hasta 100,000 filas por segundo por proyecto - ❌ Incorrecta Este es un detalle muy importante y una pregunta "trampa" común. La cuota de 100,000 filas por segundo es por tabla, no por proyecto. Un proyecto podría ingestar muchas más filas por segundo si los datos se distribuyen entre varias tablas (por ejemplo, 2 tablas podrían recibir 100,000 filas/s cada una, sumando 200,000 filas/s para el proyecto). C) Garantiza que no haya datos duplicados - ❌ Incorrecta La ingesta por streaming de BigQuery ofrece una semántica de entrega de "al menos una vez" (at-least-once). Esto significa que, en caso de reintentos por problemas de red, es posible que un mismo dato se inserte más de una vez. Para mitigar esto, BigQuery ofrece una desduplicación de "mejor esfuerzo" (best-effort) si proporcionas un insertId único para cada fila. Sin embargo, no es una garantía férrea. Para garantizar la unicidad de los datos, se requieren patrones de diseño adicionales (como usar una tabla de staging y luego una sentencia MERGE).

Answer 444

C Materialized views cache results from queries and are periodically refreshed, improving performance and reducing resource consumption.

Answer 445

C If you do not specify a destination table in BigQuery, a temporary table is automatically created and saved for 24 hours.

Answer 446

A, B y D Limitaciones Correctas A) La consistencia de los datos no está garantizada. ✅ Explicación: BigQuery no tiene control sobre la fuente de datos externa. Si los archivos en Google Cloud Storage o los datos en una base de datos externa (como Cloud SQL) se modifican mientras tu consulta se está ejecutando, BigQuery podría leer un estado inconsistente de los datos (parte antes del cambio y parte después). Esto no ocurre con las tablas nativas de BigQuery, que garantizan la consistencia de la consulta. B) El rendimiento de la consulta puede ser inferior al de consultar tablas nativas de BigQuery. ✅ Explicación: El almacenamiento nativo de BigQuery está altamente optimizado (en formato columnar, comprimido y distribuido) para funcionar con su motor de consultas. Al consultar una fuente externa, se añaden pasos adicionales que ralentizan el proceso: Latencia de red: BigQuery debe acceder a los datos a través de la red. Formato no optimizado: Los formatos como CSV o JSON son mucho más lentos de leer que el formato interno de BigQuery. Menos optimizaciones: BigQuery no puede aplicar todas sus técnicas avanzadas de optimización sobre datos que no gestiona directamente. D) No se pueden exportar datos desde una fuente de datos externa utilizando un trabajo de BigQuery. ✅ Explicación: La operación de "Exportar" de BigQuery está diseñada para funcionar únicamente con tablas nativas. No puedes ejecutar un trabajo de exportación directamente sobre una tabla externa. El procedimiento correcto sería primero ejecutar una consulta sobre la tabla externa para materializar los resultados en una nueva tabla nativa de BigQuery y, una vez hecho esto, exportar esa nueva tabla. Esta restricción es una limitación clara. Opción Incorrecta C) Se pueden utilizar comodines de tabla con fuentes de datos externas. ❌ Explicación: Esta opción es incorrecta porque describe una característica, no una limitación. De hecho, sí es posible usar comodines para consultar múltiples archivos en Google Cloud Storage como si fueran una única tabla externa (por ejemplo, SELECT * FROM \mydataset.my_external_table_*``). Al ser una funcionalidad disponible, no representa una restricción. Fuentes

Answer 447

B The tabledata().insertAll() API method allows you to stream records into BigQuery for real-time analysis. El objetivo es ingestar datos en BigQuery de forma continua y poder analizarlos casi al instante. Esto se conoce como streaming. B) Usar el método tabledata().insertAll(): Este es el método de la API de streaming de BigQuery. Está diseñado específicamente para enviar registros individuales o en pequeños grupos a BigQuery, haciéndolos disponibles para ser consultados en segundos. Es la definición perfecta de una ingesta para análisis en casi tiempo real. Por qué las otras opciones son incorrectas A) Usar la interfaz de usuario web de BigQuery: La interfaz web es para tareas manuales, como ejecutar consultas o cargar archivos de forma puntual. No es un método para ingestar datos de forma continua y programática. C) Exportar datos a Google Sheets: Esto es lo contrario de lo que se pide. Esta acción saca datos fuera de BigQuery, no los introduce. D) Ejecutar una carga por lotes desde Cloud Storage: Este es un proceso por lotes (batch), no de streaming. Implica acumular datos en archivos y luego cargarlos todos de una vez. Aunque es muy eficiente para grandes volúmenes, no es en tiempo real, ya que hay un retraso mientras se preparan los archivos y se ejecuta el trabajo de carga.

Answer 448

B BigQuery views are virtual tables defined by SQL queries and are executed each time they are accessed, whereas materialized views cache precomputed results and are periodically refreshed for improved performance

Answer 449

A, B y C BigQuery supports loading data in formats such as CSV, JSON, and Avro. XML is not listed as a supported format in the provided documentation

Answer 450

C As stated on slides 5 and 6, all query results are stored in a table. If a permanent destination table is not specified, BigQuery creates a temporary table that persists for 24 hours. This temporary table also serves as the basis for cached query results if the same query is run again under the right conditions.

Answer 451

C ¿Por qué la opción C es la correcta? ✅ Una vista estándar (o simplemente "vista") en BigQuery es esencialmente una consulta SQL guardada que se presenta como si fuera una tabla. Es la solución perfecta para este caso por dos razones clave que se alinean directamente con los requisitos de la pregunta: Siempre devuelve los datos más actualizados: Una vista no almacena ningún dato por sí misma. Cada vez que un usuario la consulta, BigQuery ejecuta la consulta guardada de la vista sobre las tablas base en ese preciso momento. Esto garantiza que los resultados reflejen el estado más reciente de los datos, cumpliendo con el requisito principal. ⏱️ Evita almacenar datos duplicados: Como es solo una consulta guardada (una definición lógica), no ocupa espacio de almacenamiento más allá de unos pocos bytes para el texto de la consulta. Esto cumple perfectamente con el requisito de no duplicar datos, lo que ahorra costos y complejidad. 💾 Además, su propósito principal es precisamente simplificar el acceso a los datos, ocultando uniones (joins) y filtros complejos detrás de un nombre de tabla simple y único para el equipo de BI. Analogía simple: Una vista es como un acceso directo en tu ordenador. El acceso directo no contiene el archivo, solo apunta a él. Cuando haces clic, siempre abres la versión más reciente del archivo original, y el acceso directo en sí no ocupa casi nada de espacio. ¿Por qué las otras opciones son incorrectas? ❌ A) A Materialized View Una vista materializada pre-calcula y almacena físicamente el resultado de una consulta. No siempre está actualizada: Se refresca periódicamente, por lo que los datos pueden estar desactualizados entre refrescos. Duplica datos: Almacena una copia de los datos, lo que contradice el requisito de evitar la duplicación. B) A permanent table created from a CTAS (CREATE TABLE AS SELECT) statement Crear una tabla permanente a partir de una consulta es como sacar una foto en un momento determinado. No está actualizada: La tabla se queda obsoleta tan pronto como los datos en las tablas originales cambian. Para actualizarla, hay que volver a crearla manualmente. Duplica datos: Crea una copia completa y física de los datos, lo que viola el requisito. D) An external table Una tabla externa se usa para consultar datos que residen fuera de BigQuery (por ejemplo, en archivos CSV o Parquet en Google Cloud Storage). No es la herramienta adecuada para crear una vista simplificada de tablas que ya existen dentro de BigQuery.

Answer 452

A, B y C Slide 16, "Pitfalls: Querying from external data sources directly," explicitly lists these limitations. It mentions "Strong performance disadvantages" (A), "Data consistency not guaranteed" (B), and "Can't use table wildcards" (C). Option D is incorrect; streaming is for ingesting into native BigQuery tables, not querying external ones.

Answer 453

C Slide 17 discusses "Streaming records into BigQuery through the API." It states, "Streaming data allows you to query data without waiting for a full batch load" and gives "Event Logging" as a primary example for real-time analysis. This is the only method presented that meets the "near real-time" requirement.

Answer 454

B Claro, aquí tienes la explicación. La respuesta correcta es la B. Una de las características más potentes y diferenciadoras de las vistas materializadas en BigQuery es su capacidad de "ajuste inteligente" (smart tuning). ✅ Por qué la opción B es la correcta B) The BigQuery optimizer can automatically use a Materialized View to accelerate a query on a base table, even if the Materialized View is not mentioned in the query. (El optimizador de BigQuery puede usar automáticamente una Vista Materializada para acelerar una consulta sobre una tabla base, incluso si la Vista Materializada no se menciona en la consulta.) Esta afirmación es la clave del valor de una vista materializada. Imagina que tienes una tabla enorme con miles de millones de filas y ejecutas una consulta que agrega datos (por ejemplo, SUM(ventas) agrupado por mes). Si tienes una vista materializada que ya tiene ese cálculo pre-hecho (CREATE MATERIALIZED VIEW resumen_ventas AS SELECT mes, SUM(ventas) FROM tabla_enorme GROUP BY mes), el optimizador de BigQuery es lo suficientemente inteligente como para detectarlo. En lugar de escanear la tabla enorme, reescribe tu consulta en segundo plano para leer directamente de la vista materializada, que es mucho más pequeña y rápida. Tú no tienes que hacer nada ni cambiar tu consulta original. Simplemente, se ejecuta mucho más rápido y consume menos recursos. ⚡ Esto no ocurre con una vista estándar, ya que esta no almacena ningún dato pre-calculado. ❌ Por qué las otras opciones son incorrectas A) A standard View stores a physical copy of the data, while a Materialized View only stores the query definition. (Una Vista estándar almacena una copia física de los datos, mientras que una Vista Materializada solo almacena la definición de la consulta.) Esta afirmación es exactamente al revés de la realidad. Una Vista Estándar es solo una consulta guardada (una definición). No almacena datos. Es como un atajo o un alias para una consulta compleja. Cada vez que la usas, la consulta se ejecuta desde cero sobre las tablas base. Una Vista Materializada sí almacena una copia física de los resultados de su consulta. Ocupa espacio de almacenamiento porque los datos están pre-calculados y guardados. C) Standard Views can only be created using the UI, while Materialized Views can only be created using SQL. (Las Vistas estándar solo se pueden crear usando la interfaz de usuario, mientras que las Vistas Materializadas solo se pueden crear usando SQL.) Esto es falso. Tanto las vistas estándar como las materializadas se pueden crear a través de múltiples métodos, incluyendo: La interfaz de usuario (UI) de la consola de Google Cloud. El lenguaje de consulta SQL (usando CREATE VIEW o CREATE MATERIALIZED VIEW). La herramienta de línea de comandos bq. Las APIs de BigQuery. No hay ninguna restricción de este tipo en la forma de crearlas. D) Data in a standard View is periodically refreshed, while data in a Materialized View is always real-time. (Los datos en una Vista estándar se actualizan periódicamente, mientras que los datos en una Vista Materializada son siempre en tiempo real.) Esta afirmación también es exactamente al revés de la realidad. Los datos de una Vista Estándar son siempre en tiempo real. Como es una consulta que se ejecuta en el momento, siempre refleja el estado actual de las tablas base. No necesita "refrescarse" porque no almacena nada. Los datos de una Vista Materializada no son en tiempo real. Son una instantánea (snapshot) de los datos que se actualiza periódicamente. BigQuery se encarga de refrescarla automáticamente cuando los datos de las tablas base cambian, pero siempre hay un pequeño desfase.

Answer 455

B Temporary tables in BigQuery are automatically created when a query is executed without specifying a destination table and last for 24 hours, improving performance for repeated queries if the data hasn't changed.

Answer 456

C The BigQuery API allows up to 10,000 rows per streaming request, with batching recommended for efficiency.

Answer 457

B Querying external data can lead to consistency issues if the data changes during the query, and it has performance disadvantages compared to managed storage.

Answer 458

C Materialized views improve performance by caching results, reducing resource usage compared to logical views, which are re-executed each time queried.

Answer 459

B Query results are stored in temporary tables by default, lasting 24 hours, and can be saved as permanent tables for longer retention.

Answer 460

C According to the source, JOINs enrich your dataset by potentially adding fields horizontally, while UNIONs append more data to your table vertically

Answer 461

C The document emphasizes the need to "first figure out what linking field they have in common" and investigate its uniqueness (e.g., checking if USAF is unique, then testing CONCAT(usaf, wban)). It states that "Finding the unique record identifier(s) in table is critical

Answer 462

B To avoid typing many UNIONs, the document introduces "Table Wildcards for Easy Merges". It specifically shows an example of SELECT ... FROM bigquery-public-data.noaa_gsod.gsod*to combine "All gsod tables" and mentions using_TABLE_SUFFIX` to filter them

Answer 463

D The source defines a LEFT JOIN as returning "all rows from the left table and matched rows from the right table

Answer 464

C The document identifies "Joining on non-unique fields explodes your dataset" as a pitfall. It explains that "Doing a many-to-many JOIN could result in more rows than either of your initial tables" and "This is a primary reason for exceeding your resource cap in BigQuery (unintentionally high compute)

Answer 465

B La Diferencia Clave: Unir Vertical vs. Horizontal En SQL, hay dos formas principales de combinar tablas, y es fundamental no confundirlas. B. UNION (Combinación Vertical) ⬆️⬇️ UNION se usa para apilar los resultados de dos o más consultas una encima de la otra. El resultado final tiene las mismas columnas, pero más filas (las filas de la primera tabla más las de la segunda). Analogía: Imagina que tienes dos hojas de cálculo con una lista de clientes, una de las ventas de enero y otra de las de febrero. Usar UNION sería como copiar y pegar la lista de febrero justo debajo de la de enero para crear una única lista maestra de clientes de ambos meses. SELECT nombre, ciudad FROM Clientes_Enero UNION SELECT nombre, ciudad FROM Clientes_Febrero; A. JOIN (Combinación Horizontal) ⬅️➡️ JOIN se usa para enriquecer los datos combinando columnas de diferentes tablas basándose en una clave común. El resultado final tiene las mismas filas (o menos, dependiendo del tipo de join), pero más columnas. Analogía: Imagina que tienes una hoja de cálculo con nombres de clientes y otra con sus direcciones. Usar JOIN te permitiría añadir la columna "Dirección" al lado de la columna "Nombre" para cada cliente coincidente. Por qué las otras opciones son incorrectas A. JOIN y D. CROSS JOIN: Ambos realizan combinaciones horizontales (añaden columnas), no verticales. Un CROSS JOIN es un tipo específico que crea todas las combinaciones posibles de filas entre las tablas, pero sigue siendo una operación de ensanchamiento, no de apilamiento. C. MERGE: Es una operación más compleja (a veces llamada UPSERT) que se usa para sincronizar dos tablas, realizando acciones como insertar, actualizar o borrar filas en una tabla de destino basándose en una tabla de origen. Su propósito no es simplemente combinar filas para una consulta.

Answer 466

A y C A UNION operation requires all combined tables to have the same number of columns and compatible data types. Changes in schema or mismatched column counts will cause errors.

Answer 467

C _TABLE_SUFFIX allows filtering on the names of matched tables in a wildcard query, e.g., filtering only gsod* tables from a certain year onward.

Answer 468

A, C y D ✅ A. An INNER JOIN returns rows that exist in both tables Esto es correcto. Es la definición fundamental de un INNER JOIN. Esta operación combina filas de dos tablas y solo devuelve aquellas en las que la condición de unión (la clave de cruce) se cumple en ambas. Si una fila no tiene una contraparte en la otra tabla, se excluye del resultado. Analogía: Es como encontrar los amigos que tienes en común con otra persona. Solo los que están en ambas listas de amigos aparecerán en el resultado final. ❌ B. A LEFT JOIN returns all rows from the right table Esto es incorrecto. La afirmación describe un RIGHT JOIN. Un LEFT JOIN (o LEFT OUTER JOIN) devuelve todas las filas de la tabla de la izquierda (left table), y solo las filas coincidentes de la tabla de la derecha. Si no hay coincidencia para una fila de la izquierda, las columnas de la derecha se rellenan con valores NULL. ✅ C. Joining on non-unique fields may increase the row count Esto es correcto y es una de las causas más comunes de errores y resultados inesperados al usar JOINs. Si la clave por la que estás uniendo las tablas no es única en una o ambas tablas, se producirá un producto cartesiano para esas claves duplicadas. Esto significa que una fila de una tabla se duplicará para coincidir con cada una de las filas correspondientes en la otra tabla, aumentando el número total de filas en el resultado. Ejemplo simple: Tabla_Ventas: tiene 2 filas para producto_id = 101. Tabla_Productos: tiene 1 fila para producto_id = 101. Al hacer un JOIN entre ellas por producto_id, las 2 filas de Tabla_Ventas coincidirán con la única fila de Tabla_Productos, resultando en 2 filas. Tabla_Ventas: tiene 2 filas para producto_id = 101. Tabla_Devoluciones: tiene 3 filas para producto_id = 101. Al hacer un JOIN entre ellas, obtendrás 2 * 3 = 6 filas en el resultado para ese producto. ✅ D. You can JOIN using a composite key made with CONCAT() Esto es correcto. La cláusula ON en un JOIN es muy flexible y no se limita a comparar columnas individuales. Puedes usar funciones y expresiones complejas para definir la condición de unión. Puedes crear una "clave compuesta" al vuelo concatenando varias columnas. Esto es útil cuando no tienes una única clave común, pero la combinación de varias columnas sí es única. Ejemplo de código: SELECT a.nombre, a.apellido, b.email FROM Tabla_A AS a JOIN Tabla_B AS b ON CONCAT(a.nombre, " ", a.apellido) = b.nombre_completo

Answer 469

C Ni usaf ni wban son únicos por sí solos, pero su combinación sí identifica de forma única cada estación meteorológica dentro de los datos de NOAA.

Answer 470

C As shown in slides 15 and 16, BigQuery's table wildcards (*) are designed for this exact scenario. They allow you to query across multiple similarly named tables. The _TABLE_SUFFIX pseudo-column enables you to filter which tables are included in the query, providing an efficient way to scan only the necessary tables (WHERE _TABLE_SUFFIX_ BETWEEN '1990' AND '1999') without writing repetitive UNION ALL statements

Answer 471

C El misterio del JOIN "explosivo" 💥 Cuando unes dos tablas, la base de datos toma cada fila de la tabla de la izquierda y busca todas las filas coincidentes en la tabla de la derecha. Si encuentra una coincidencia, se produce una fila en el resultado. Si encuentra cero coincidencias, se produce una fila (con valores NULL para las columnas de la derecha, porque es un LEFT JOIN). Si encuentra múltiples coincidencias, la fila de la izquierda se duplica para cada una de ellas. Aquí es donde ocurre la "explosión". La opción correcta: C C. La columna store_id, que se usa como clave de unión, no es única en la tabla stores (la tabla de consulta). Una tabla de consulta o "lookup table" (como stores) debería, por definición, tener una única fila para cada entidad que describe. En este caso, debería haber una sola fila por cada store_id. Si por un error en los datos la tabla stores contiene store_id duplicados (por ejemplo, dos filas para la store_id = 101), entonces cada vez que una fila de la tabla transactions con store_id = 101 busque su correspondencia, encontrará dos coincidencias. Esto hará que esa única fila de transacción se duplique en el resultado final, generando dos filas. Si esto ocurre para muchas tiendas, el número total de filas se dispara. Analogía: Imagina que estás organizando una agenda de contactos. Tienes una lista de llamadas (transactions) y quieres añadir el nombre de la persona a cada llamada usando tu directorio (stores). Si para un número de teléfono (store_id) tienes por error dos contactos diferentes en el directorio, al hacer la consulta acabarás duplicando esa llamada en tu agenda final, una vez con cada nombre. El problema está en el directorio, que debería tener una sola entrada por número. Las opciones incorrectas A. La tabla stores contiene store_id que no existen en la tabla transactions. En un LEFT JOIN, la tabla de la izquierda (transactions) es la que manda. Si hay tiendas en la tabla stores que no tienen ninguna transacción, simplemente no se incluirán en el resultado. Esto no aumenta el número de filas. B. La columna store_id en la tabla transactions no es única, lo cual es esperado. Esto es completamente normal. Es de esperar que una misma tienda tenga muchas transacciones. Que el store_id se repita en la tabla de la izquierda no causa una explosión, siempre que cada uno de esos store_id encuentre una (y solo una) coincidencia en la tabla de la derecha. D. Se debería haber usado un INNER JOIN en lugar de un LEFT JOIN. Cambiar el tipo de JOIN no solucionaría el problema. Un INNER JOIN también duplicaría las filas si encontrara múltiples coincidencias en la tabla de la derecha. El problema no es el tipo de unión, sino la calidad de los datos en la tabla stores.

Answer 472

B A LEFT JOIN (or LEFT OUTER JOIN) returns all rows from the left table (customers) and the matched rows from the right table (orders). If there is no match for a customer in the orders table, the result is NULL for the columns from the right table. This exactly matches the requirement to list all customers regardless of whether they have placed an order. This concept is visualized in the Venn diagrams on slide 27.

Answer 473

D When a single field is not unique, you must use a composite key for the join. The most direct and performant way to join on multiple columns is by specifying each condition with AND in the ON clause. While using CONCAT() (as in option C) might produce the correct logical result, it is less efficient because it prevents the query optimizer from using indexes on the individual columns and requires a function to be executed for every row. La clave para resolver esta pregunta está en la frase: "la combinación de las columnas usaf y wban crea un identificador único". Esto es lo que en bases de datos se conoce como una clave compuesta (o composite key). Significa que para identificar de forma única y sin ambigüedad un registro (en este caso, una estación meteorológica), no basta con una sola columna, sino que se necesita el par de columnas (usaf, wban). La forma correcta y estándar en SQL para unir tablas usando una clave compuesta es especificar una condición de igualdad para cada una de las columnas que forman parte de esa clave, uniéndolas con el operador AND. readings.stn = stations.usaf: Esta parte une la primera columna de la clave. (Asumimos que stn en la tabla readings es el equivalente a usaf en la tabla stations). AND: Le dice a la base de datos que la siguiente condición también debe cumplirse. readings.wban = stations.wban: Esta parte une la segunda columna de la clave. Al hacer esto, te aseguras de que una fila de la tabla readings se corresponda con exactamente una fila de la tabla stations, evitando duplicados y errores. Es la forma más precisa, segura y eficiente de realizar esta unión. Por qué las otras respuestas son incorrectas: A. ON readings.stn = stations.usaf Por qué es incorrecta: El enunciado nos dice explícitamente que la columna usaf no es única por sí sola. Si usas solo esta condición, una única lectura de temperatura (readings) podría coincidir con múltiples registros de estaciones (stations) que comparten el mismo usaf pero tienen diferente wban. Esto resultaría en datos duplicados y un análisis incorrecto. Estarías uniendo una lectura a varias estaciones a la vez, lo cual no tiene sentido. B. ON readings.wban = stations.wban Por qué es incorrecta: El razonamiento es idéntico al del punto A. La columna wban por sí sola tampoco es un identificador único. Usarla como única condición de unión también provocaría uniones incorrectas y datos duplicados. Estás usando una clave incompleta. C. ON CONCAT(readings.stn, readings.wban) = CONCAT(stations.usaf, stations.wban) Por qué es incorrecta: Aunque pueda parecer una solución ingeniosa, tiene dos problemas fundamentales que la hacen una mala práctica y, en algunos casos, incorrecta. Riesgo de Ambigüedad (El Error Fatal): La función CONCAT (que une cadenas de texto) puede crear resultados idénticos para valores diferentes. Imagina estos dos casos: Caso 1: usaf = '123', wban = '45' -> CONCAT crea '12345' Caso 2: usaf = '12', wban = '345' -> CONCAT también crea '12345' Como ves, dos claves compuestas completamente diferentes (('123', '45') y ('12', '345')) producirían el mismo resultado concatenado, llevando a uniones incorrectas. Este es un bug sutil pero crítico. Mal Rendimiento (Performance): Aplicar una función como CONCAT a las columnas dentro de la cláusula ON impide que el motor de la base de datos utilice eficientemente los índices que puedan existir en esas columnas. La base de datos tiene que calcular el resultado de CONCAT para cada fila de ambas tablas antes de poder compararlas, lo cual es mucho más lento que una comparación directa de columnas. La opción D, al usar comparaciones directas, es mucho más rápida y "amigable" con los índices. Resumen Clave: Cuando la unicidad de un registro depende de múltiples columnas (una clave compuesta), la forma correcta de unirlo es usando una condición para cada columna, conectadas por AND.

Answer 474

B y D ✅ Explicación de las respuestas correctas (B y D) B. Schemas changing over time, leading to a mismatched number of columns between tables. (Los esquemas cambian con el tiempo, lo que lleva a un número de columnas que no coincide entre las tablas). Por qué es un problema: El operador UNION tiene una regla estricta: todas las consultas que se combinan deben tener exactamente el mismo número de columnas y en el mismo orden, y los tipos de datos deben ser compatibles. Si tienes una consulta que une datos de ventas de 2024 y 2025, y en el futuro alguien añade una nueva columna a la tabla de 2025 (por ejemplo, region), la consulta UNION que antes funcionaba dejará de funcionar y dará un error. Este es un problema de mantenimiento muy común en entornos reales. D. If UNION ALL is used, duplicate records that exist across the tables will be kept in the final result. (Si se usa UNION ALL, los registros duplicados que existen en las tablas se mantendrán en el resultado final). Por qué es un problema: Hay dos versiones del operador: UNION: Compara todas las filas y elimina las que están duplicadas. Es más lento porque tiene que hacer esta comprobación. UNION ALL: Simplemente apila las tablas una sobre otra sin comprobar si hay duplicados. Es mucho más rápido. El "peligro" o pitfall es que un analista podría usar UNION ALL para mejorar el rendimiento sin darse cuenta de que si un mismo registro exacto existe en ambas tablas, aparecerá dos veces en el resultado. Esto puede llevar a cálculos incorrectos, como contar el número de clientes o sumar ventas y obtener un resultado inflado 🎈. ❌ Análisis de las respuestas incorrectas (A y C) A. Joining on a non-unique key can cause the number of rows to explode. (Unir con una clave no única puede hacer que el número de filas explote). Por qué es incorrecto: Este es un problema clásico del operador JOIN, no de UNION. Un JOIN combina columnas de diferentes tablas basándose en una clave (hace la tabla más "ancha"). Un UNION apila filas de tablas similares (hace la tabla más "larga"). Confundir estos dos operadores es un error común. C. It can only combine a maximum of two tables at a time. (Solo puede combinar un máximo de dos tablas a la vez). Por qué es incorrecto: Esto es simplemente falso. Puedes encadenar tantos operadores UNION como necesites para combinar múltiples tablas. Por ejemplo, la siguiente consulta es perfectamente válida: SELECT * FROM ventas_enero UNION ALL SELECT * FROM ventas_febrero UNION ALL SELECT * FROM ventas_marzo;

Answer 475

B Analytic functions compute aggregate values over a group of rows. Unlike standard aggregate functions, which return one value for the entire group, analytic functions return a single value for each row by computing the function over a group of input rows (also known as a "window" or "window frame")

Answer 476

A, B y C ✅ Respuestas Correctas A) No se admiten objetos DOM como Window, Document y Node. Esto es una limitación fundamental. Una UDF es una función que se ejecuta en el servidor de Google, dentro del motor de BigQuery. Los objetos del DOM (Document Object Model) como window y document solo existen en el entorno de un navegador web para interactuar con una página HTML. Es imposible que un servidor que procesa datos tenga acceso a ellos. B) Las funciones de JavaScript que dependen de código nativo pueden fallar. Por razones de seguridad y estabilidad, las UDFs se ejecutan en un entorno aislado y controlado llamado "sandbox" (caja de arena). Este entorno prohíbe que el código JavaScript llame a código nativo (como librerías escritas en C++), ya que podría comprometer la seguridad o la estabilidad de la plataforma de Google. C) Las operaciones a nivel de bits (bitwise) en JavaScript están limitadas a 32 bits. Esta es una limitación importante a tener en cuenta. Aunque BigQuery maneja enteros de 64 bits (INT64), el lenguaje JavaScript en sí mismo, por su especificación, trata los números como si fueran de 32 bits cuando se usan operadores a nivel de bits (como &, |, ^). Aunque técnicamente es una limitación del lenguaje JavaScript y no de la plataforma de UDFs, en la práctica es una restricción con la que te topas al escribir una UDF, y por eso se considera una limitación declarada. ❌ Respuesta Incorrecta D) Cada conjunto de datos (dataset) puede contener múltiples UDFs persistentes con el mismo nombre exacto. Esta afirmación es falsa y describe lo contrario a una limitación. En cualquier sistema de programación o base de datos, los nombres de las funciones dentro de un mismo espacio o ámbito (en este caso, un "dataset") deben ser únicos. Si pudieras tener varias funciones con el mismo nombre, BigQuery no sabría a cuál de ellas llamar, creando una ambigüedad imposible de resolver. Por lo tanto, estás limitado a que cada UDF tenga un nombre único dentro del dataset.

Answer 477

C A partitioned table is divided into segments (partitions), making data management and querying easier. By dividing a large table, you can improve query performance and control costs because queries can process a reduced number of bytes by scanning only the relevant partitions

Answer 478

C C) La consulta sobre la tabla particionada pudo referenciar la lista de particiones y determinó que no existían datos para el rango de fechas especificado dentro de las particiones disponibles. ¿Por qué es la correcta? ✅ El propósito principal de particionar una tabla (en este caso, por fecha) es evitar escanear datos innecesarios. BigQuery mantiene una lista de metadatos de todas las particiones existentes. Cuando ejecutas una consulta con un filtro en la columna de partición (por ejemplo, WHERE date = '2025-09-08'), BigQuery primero mira esa lista. Si la fecha que buscas no existe como una partición en la tabla, BigQuery lo sabe de inmediato sin necesidad de leer ni un solo byte de los datos reales. Por eso, el costo del procesamiento es de 0 B. Es el escenario más eficiente posible y se conoce como poda de particiones (partition pruning). Analogía: Imagina que tienes un archivador con una carpeta para cada día del año. Si te piden un documento del "32 de enero", no necesitas abrir ninguna carpeta; sabes al instante que no existe. Así funciona BigQuery con las particiones. A) La consulta realiza automáticamente una conversión de tipo de dato, lo que anula la necesidad de procesar datos en tablas particionadas. ¿Por qué es incorrecta? ❌ La conversión de tipos de datos (por ejemplo, de STRING a DATE) no elimina la necesidad de procesar datos. De hecho, a menudo impide que BigQuery pueda usar la poda de particiones eficazmente, forzándolo a escanear más datos de los necesarios, lo cual es justo lo contrario de lo que describe el problema. B) La tabla particionada almacena los datos en un formato inherentemente comprimido que no requiere procesamiento para los filtros de fecha. ¿Por qué es incorrecta? ❌ Si bien es cierto que BigQuery comprime los datos, esto lo hace para todas las tablas, particionadas o no. La compresión reduce el tamaño del almacenamiento, pero para filtrar los datos, BigQuery aún necesita descomprimirlos y leerlos. La compresión por sí sola no explica por qué el procesamiento baja de 205.9 MB a cero. D) La consulta utilizó una función de aproximación estadística para estimar el resultado sin leer realmente ningún dato. ¿Por qué es incorrecta? ❌ BigQuery tiene funciones de aproximación (como APPROX_COUNT_DISTINCT), pero estas deben ser invocadas explícitamente en la consulta. El enunciado dice que se ejecutó una "consulta idéntica" a la original, lo que implica que era una consulta de filtrado estándar, no una que usara funciones de aproximación. Estas funciones, además, suelen procesar una muestra de los datos, no necesariamente 0 bytes.

Answer 479

B The sources indicate that UDFs add sophistication at the expense of performance. Statistical approximation functions are for really large datasets, where there's an option to trade processing time for 100% accuracy. Partitioning tables is used to logically break apart tables for performance, especially with large datasets. Analytic Window Functions are specifically highlighted as a mechanism to operate over sub-groups of rows and perform tasks like ranking within each sub-group

Answer 480

C Analytic functions perform aggregations over a group of rows but return a value for each individual row, unlike aggregate functions which return one value per group.

Answer 481

A, C y D RANK(), LEAD(), and PERCENT_RANK() are analytic functions. AVG() is a standard aggregation function, not specifically a window function.

Answer 482

C Partitioning tables by date allows queries to scan only the relevant partitions, which improves performance and reduces costs.

Answer 483

C Persistent UDFs must include the dataset name and cannot be temporary. Option C follows the correct format using JavaScript. C. CREATE FUNCTION dataset.js_udf(x STRING) RETURNS INT64 LANGUAGE js AS ''' return x.length; '''; Esta es la sintaxis correcta para crear una función definida por el usuario (UDF) que sea persistente y de JavaScript. Persistente: Para que una UDF sea persistente (es decir, que se guarde y se pueda reutilizar en otras consultas), se debe crear dentro de un dataset de BigQuery. La sintaxis dataset.js_udf indica que la función js_udf se guardará permanentemente en el dataset especificado. Además, no utiliza la palabra clave TEMP. JavaScript: La cláusula LANGUAGE js especifica correctamente que el código de la función está escrito en JavaScript. Sintaxis Completa: La declaración tiene todos los elementos necesarios: el nombre completo (dataset + función), los parámetros de entrada (x STRING), el tipo de dato que devuelve (RETURNS INT64), el lenguaje y el cuerpo de la función con la lógica (AS '''...'''). ❌ Respuestas Incorrectas A. CREATE FUNCTION f() LANGUAGE SQL; Por qué es incorrecta: Esta UDF está declarada como LANGUAGE SQL, no JavaScript. Además, la sintaxis está incompleta, ya que le falta el cuerpo de la función (AS ...). B. CREATE TEMP FUNCTION js_udf(x STRING) RETURNS INT64 LANGUAGE js AS ''' return x.length; '''; Por qué es incorrecta: La palabra clave TEMP (o TEMPORARY) crea una función temporal. Esto significa que la UDF solo existirá durante la ejecución de esa consulta o script en particular y no se guardará de forma permanente. La pregunta pide una función persistente. D. CREATE FUNCTION js_udf RETURNS INT64 LANGUAGE js; Por qué es incorrecta: La sintaxis es inválida por dos motivos principales. Primero, para ser persistente, debe especificarse el dataset donde se guardará (ej. midataset.js_udf). Segundo, y más importante, le falta el cuerpo de la función con la cláusula AS, que contiene la lógica JavaScript.

Answer 484

B y C Opciones Correctas (Limitaciones Reales) ### B. Los objetos de JavaScript relacionados con el DOM no son compatibles ✅ Esta es una limitación fundamental. Una UDF de JavaScript en BigQuery se ejecuta en un entorno de servidor, aislado y seguro. No se ejecuta en un navegador web. El DOM (Document Object Model) es la estructura de objetos que un navegador usa para representar una página web (con objetos como window, document, alert, fetch, etc.). Como la UDF no se ejecuta en un navegador, no tiene acceso a ninguno de estos objetos. C. Solo una UDF persistente con el mismo nombre por conjunto de datos ✅ Esto también es una limitación. Dentro de un conjunto de datos (dataset) de BigQuery, cada UDF persistente debe tener un nombre único. Funciona de la misma manera que las tablas: no puedes tener dos tablas con el mismo nombre en el mismo conjunto de datos. No es posible tener sobrecarga de funciones (varias funciones con el mismo nombre pero diferentes parámetros) para las UDF persistentes. Opciones Incorrectas ### A. Las operaciones a nivel de bits en JavaScript están limitadas a 64 bits ❌ Esta afirmación es falsa. Si bien existe una limitación, está descrita incorrectamente. El tipo de dato Number en JavaScript es de 64 bits, pero para las operaciones a nivel de bits (&, |, ^, etc.), JavaScript convierte los números a enteros de 32 bits con signo. Por lo tanto, la limitación real es de 32 bits, no de 64. D. Las UDF persistentes pueden hacer referencia a UDF temporales ❌ Esta afirmación también es falsa. La lógica es la opuesta. Una UDF temporal solo existe durante la ejecución de una única consulta o script. Una UDF persistente se guarda en un conjunto de datos y está disponible permanentemente. Por lo tanto, una función persistente (que vive "para siempre") no puede depender de una función temporal (que "muere" al final de la consulta). Sería como construir una casa (persistente) sobre un andamio que se va a quitar de inmediato (temporal). Lo que sí es posible es que una UDF temporal haga referencia a una UDF persistente.

Answer 485

B Partitioning tables, especially by date, allows queries to scan only relevant partitions, reducing the amount of data processed and thus improving performance and lowering costs.

Answer 486

B y C El Concepto Clave: Funciones Analíticas (o de Ventana) Primero, hay que entender qué es una función analítica (o de ventana). A diferencia de una función de agregación normal con GROUP BY (que colapsa varias filas en una sola), una función analítica te permite realizar cálculos sobre un conjunto de filas (la "ventana") pero sin colapsarlas. Devuelve un valor para cada fila original. La sintaxis para definir esta "ventana" se hace con la cláusula OVER(). La estructura más común es: FUNCIÓN() OVER ( PARTITION BY ... ORDER BY ... ) Ahora veamos cada opción: Las Respuestas Correctas B) PARTITION BY Por qué es correcta: Esta cláusula es la que define sobre qué grupo de filas se va a ejecutar la función. Es similar a GROUP BY en el sentido de que "agrupa" datos, pero la diferencia crucial es que no colapsa las filas. Simplemente le dice a la función: "Calcula el resultado para este grupo, luego reiníciate y calcula el resultado para el siguiente grupo". Ejemplo: ROW_NUMBER() OVER (PARTITION BY departamento) asignará un número de fila (1, 2, 3...) a los empleados, pero la numeración se reiniciará a 1 por cada departamento diferente. C) ORDER BY Por qué es correcta: Esta cláusula define el orden lógico de las filas dentro de cada partición (o de la ventana completa si no hay PARTITION BY). Esto es absolutamente esencial para dos tipos de funciones: Funciones de Ranking: Como ROW_NUMBER(), RANK(), DENSE_RANK(). ¿Cómo podría el sistema saber quién es el número 1 si no le dices por qué columna ordenar? Funciones Acumulativas: Como SUM(...) OVER (ORDER BY fecha ...) para calcular una suma acumulada. El orden le dice al sistema qué fila va "antes" y qué fila va "después" para poder acumular el valor correctamente. Las Respuestas Incorrectas A) GROUP BY Por qué es incorrecta: GROUP BY es la cláusula de agregación estándar. Su propósito es colapsar (o reducir) múltiples filas en una única fila de resumen. Como se mencionó, las funciones analíticas hacen exactamente lo contrario: mantienen todas las filas. Son dos conceptos fundamentalmente diferentes y no se usan para definir la ventana de una función analítica. (Técnicamente, puedes usar una función analítica después de agrupar, pero GROUP BY en sí mismo no define la ventana OVER()). D) WHERE Por qué es incorrecta: La cláusula WHERE se usa para filtrar filas. Se ejecuta antes de que se procesen las funciones analíticas. WHERE simplemente decide qué filas entran en el conjunto de datos sobre el que se trabajará. No tiene ningún papel en definir cómo esas filas se agruparán (PARTITION BY) o se ordenarán (ORDER BY) para el cálculo de la función analítica.

Answer 487

A, B y D UDFs in BigQuery have several limitations, including lack of support for DOM objects, name uniqueness per dataset, and JavaScript bitwise operation limits. UDFs can be written in SQL or JavaScript, so C is incorrect

Answer 488

B Analytic (window) functions compute values for each row based on a defined window of rows, not just a single aggregate per group

Answer 489

B The correct syntax involves using CREATE OR REPLACE TABLE with the PARTITION BY clause specifying the date column

Answer 490

B As shown in slides 12-17, partitioning a table allows BigQuery to perform "partition pruning." When a query filters on the partitioning column (in this case, the date), BigQuery can scan only the relevant partitions instead of the entire 10 TB table. This drastically reduces the amount of data processed, which lowers costs and improves performance. The other options are incorrect because FORMAT() would still require a full table scan, a UDF adds processing overhead, and increasing slots doesn't solve the underlying inefficiency of a full table scan.

Answer 491

C Por qué la respuesta C es la correcta C) To define the independent groups (windows) of rows on which the RANK() function will be calculated separately. (Definir los grupos independientes (ventanas) de filas sobre los cuales la función RANK() se calculará por separado.) Esta es la definición exacta de lo que hace PARTITION BY dentro de una función de ventana (window function), que es lo que RANK() OVER(...) está haciendo. Piénsalo de esta manera: La consulta primero mira a todos los empleados de la tabla Employees. La cláusula PARTITION BY department le dice a SQL: "Antes de hacer nada más, divide a todos estos empleados en cubetas (o 'particiones') separadas, una por cada departamento". Así, tendrás una cubeta para 'Ventas', otra para 'Ingeniería', otra para 'Marketing', etc. Luego, la función RANK() (junto con ORDER BY startdate) se aplica dentro de cada cubeta de forma independiente. El RANK() se reinicia en 1 para cada nuevo departamento. El resultado es que obtienes el ranking de antigüedad (basado en startdate) de los empleados, pero solo comparados con sus compañeros del mismo departamento. La opción C describe perfectamente este proceso de crear "grupos independientes" (las cubetas) para que la función RANK() se calcule por separado en cada uno. Por qué las otras respuestas son incorrectas A) To sort all employees from all departments by their start date. (Ordenar a todos los empleados de todos los departamentos por su fecha de inicio.) Incorrecto. Para hacer esto, simplemente pondrías ORDER BY startdate al final de toda la consulta, fuera de la cláusula OVER(). El PARTITION BY hace lo contrario: interrumpe una ordenación global para crear ordenaciones locales dentro de cada grupo (departamento). B) To group rows by department and collapse them into a single summary row per department. (Agrupar filas por departamento y colapsarlas en una única fila de resumen por departamento.) Incorrecto. Esto es lo que hace una cláusula GROUP BY. Las funciones de ventana (como RANK() OVER (PARTITION BY ...) ) son diferentes: no colapsan las filas. Mantienen todas las filas originales de la tabla (todos los empleados) y simplemente añaden una nueva columna (rank) con el cálculo realizado. D) To filter out any departments that do not match the specified partition criteria. (Filtrar cualquier departamento que no coincida con los criterios de partición especificados.) Incorrecto. PARTITION BY no filtra datos. Para filtrar filas se usan las cláusulas WHERE o HAVING. PARTITION BY simplemente organiza las filas existentes en grupos para poder hacer cálculos sobre ellos, pero incluirá a todos los departamentos y todos los empleados en el resultado.

Answer 492

A y E Por qué A y E son correctas A) Las UDFs persistentes deben ser calificadas con el nombre del conjunto de datos (dataset) al que pertenecen cuando se llaman. ✅ Una UDF persistente no es una función temporal; es un objeto que se guarda de forma permanente dentro de un conjunto de datos, al igual que una tabla o una vista. Por lo tanto, para que BigQuery sepa exactamente a qué función te refieres (ya que podría haber funciones con el mismo nombre en diferentes datasets), es obligatorio especificar su ubicación completa al llamarla. La sintaxis correcta es proyecto.dataset.nombre_funcion(), o si estás en el mismo proyecto, dataset.nombre_funcion(). E) Las funciones de JavaScript en las UDFs que dependen de código nativo o de objetos DOM como Window no están soportadas. ✅ Esta afirmación es cierta debido al entorno en el que se ejecutan las UDFs de JavaScript. No se ejecutan en un navegador web, sino en un entorno seguro y aislado (sandbox) en los servidores de Google. Este entorno: No tiene un DOM (Document Object Model): Objetos de navegador como window, document, alert o setTimeout no existen y no se pueden usar. No puede ejecutar código nativo: Por razones de seguridad y portabilidad, no se pueden invocar librerías escritas en C++ u otros lenguajes nativos. Solo se permite código JavaScript puro. Por qué B, C y D son incorrectas B) Las UDFs solo pueden escribirse en SQL Estándar para garantizar el máximo rendimiento. ❌ Esto es falso. BigQuery soporta UDFs escritas en dos lenguajes principales: SQL y JavaScript. Si bien es cierto que las UDFs de SQL suelen tener mejor rendimiento porque se integran directamente en el motor de consulta, JavaScript es totalmente compatible y muy útil para lógica más compleja que no se puede expresar fácilmente en SQL. C) Las UDFs temporales pueden ser referenciadas por Vistas guardadas para una lógica modular. ❌ Esto es incorrecto debido a la diferencia en el ciclo de vida de ambos objetos. Una UDF temporal (CREATE TEMP FUNCTION...) solo existe durante la ejecución de una única consulta o script. Una vez que termina, desaparece. Una Vista guardada es un objeto persistente. No se puede crear un objeto persistente (la Vista) que dependa de un objeto temporal (la UDF) que no existirá cuando alguien intente consultar esa vista en el futuro. Las vistas solo pueden hacer referencia a UDFs persistentes. D) Las UDFs no pueden hacer referencia a bibliotecas de código externas almacenadas en Google Cloud Storage. ❌ Esto es falso. De hecho, es una característica muy útil de las UDFs de JavaScript. Puedes almacenar tus librerías de código .js en un bucket de Cloud Storage y luego importarlas al crear tu UDF usando la cláusula OPTIONS. Por ejemplo: OPTIONS (library="gs://mi-bucket/mi-libreria.js").

Answer 493

B This scenario directly tests the concept of partition pruning, as explained on slides 16 and 17. BigQuery's query planner will check the table's partition metadata before starting a scan. It sees that the query is filtering for a date (2023-06-01) for which no partition exists. Therefore, it knows no data can possibly match the WHERE clause and avoids scanning any data at all, resulting in 0 bytes processed and returning an empty result set.

Answer 494

C Por qué C) LEAD() y LAG() es la respuesta correcta LEAD() y LAG() son funciones de ventana (window functions). Esto significa que pueden "ver" otras filas que están relacionadas con la fila actual, sin colapsar las filas como lo haría un GROUP BY. LAG(salary): "Look Aside" (Mira hacia atrás). Obtiene el valor de la columna salary de la fila anterior a la fila actual. LEAD(salary): "Look Ahead" (Mira hacia adelante). Obtiene el valor de la columna salary de la fila siguiente a la fila actual. Para que funcionen como pide la pregunta, las usarías con dos cláusulas clave: PARTITION BY department: Esto divide los datos en "ventanas" o grupos, uno por cada departamento. LAG() y LEAD() no mirarán datos de un departamento diferente. Esto cumple con "within the same department". ORDER BY hire_date: Esto ordena a los empleados dentro de cada departamento por su fecha de contratación. Esto define qué fila es "anterior" y "siguiente". Esto cumple con "hired immediately before and immediately after". Una consulta de ejemplo se vería así: SELECT employee_name, department, hire_date, salary, LAG(salary, 1) OVER (PARTITION BY department ORDER BY hire_date) AS previous_employee_salary, LEAD(salary, 1) OVER (PARTITION BY department ORDER BY hire_date) AS next_employee_salary FROM employees Por qué las otras respuestas son incorrectas A) SUM() y COUNT() con GROUP BY: Estas son funciones de agregación. GROUP BY colapsa todas las filas de un departamento en una sola fila (por ejemplo, el salario total o el número de empleados). Esto te hace perder la información de los empleados individuales, por lo que es imposible comparar un empleado con el siguiente. B) RANK() y DENSE_RANK(): Estas también son funciones de ventana, pero su trabajo es asignar un número de ranking (como 1º, 2º, 3º) a cada empleado según su fecha de contratación. Te dirían que Juan es el 5º contratado, pero no te dirían el salario del 4º o del 6º. No obtienen el valor de otra fila. D) CREATE FUNCTION (UDF de Javascript): Esto implica escribir una función personalizada y compleja. Aunque técnicamente podrías programar esta lógica, es la solución menos eficiente, más lenta y más difícil de mantener. Es "matar una mosca a cañonazos" cuando SQL ya tiene las herramientas perfectas y optimizadas (LEAD/LAG) para la tarea.

Answer 495

B Analytic functions, also known as window functions, are designed to perform calculations across a subset of rows related to the current row, such as running totals or moving averages, without collapsing the result set.

Answer 496

B Este es el único punto que NO es un beneficio de la partición. ¿Por qué? La partición es una forma de organizar los datos, pero no cambia la cantidad total de datos que almacenas. Si tienes 1 TB de datos, seguirás teniendo 1 TB de datos ya sea en una tabla monolítica o en una tabla dividida en 365 particiones diarias. El coste del almacenamiento activo se basa en el volumen total de datos, no en su organización. Importante: No hay que confundir el coste de almacenamiento con el coste de las consultas. La partición reduce drásticamente el coste de las consultas, pero no el coste de guardar los datos. ¿Por qué las otras opciones SÍ son beneficios? A) Rendimiento de las consultas mejorado: Este es el principal beneficio de la partición. Cuando filtras una consulta por la columna de partición (por ejemplo, WHERE fecha = '2025-07-25'), BigQuery puede ignorar todas las demás particiones y escanear solo la que necesitas. Este proceso, llamado partition pruning, reduce enormemente la cantidad de datos leídos y acelera las consultas de forma espectacular. ⚡ C) Gestión de datos más sencilla: La partición te permite gestionar bloques enteros de datos como una sola unidad. Por ejemplo, puedes eliminar todos los datos de un día específico con una única y rápida operación (ALTER TABLE ... DROP PARTITION), en lugar de ejecutar una costosa sentencia DELETE que escanee toda la tabla. D) Caducidad automática de los datos: Puedes configurar una política de caducidad a nivel de partición. Por ejemplo, puedes indicar a BigQuery que elimine automáticamente cualquier partición que tenga más de 90 días de antigüedad. Esto es ideal para gestionar políticas de retención de datos (como el GDPR) sin intervención manual.

Answer 497

C UDFs can enhance query capabilities but may introduce performance trade-offs, especially with complex operations or large datasets, which is an important consideration. Para entender la frase, primero hay que saber qué es una UDF. ¿Qué es una UDF? Una UDF (User-Defined Function o Función Definida por el Usuario) es una función que tú, como programador o analista, creas para realizar una operación que no está disponible por defecto en el lenguaje de consultas de una base de datos (como SQL). Por ejemplo, podrías crear una UDF para calcular el IVA de un precio, para limpiar y formatear un texto de una manera muy específica, o para realizar un cálculo financiero complejo. Ahora, analicemos las dos ideas principales de la afirmación: "Las UDFs pueden mejorar las capacidades de las consultas...": Esto es cierto. Las UDFs te dan un poder enorme. Permiten encapsular lógica de negocio compleja en una función reutilizable. En lugar de escribir un cálculo largo y complicado cada vez que lo necesitas en una consulta, simplemente llamas a tu función (por ejemplo, CALCULAR_PRECIO_FINAL(producto_id)). Esto hace que las consultas sean más limpias, legibles y fáciles de mantener. Añaden flexibilidad y potencia al sistema. "...pero pueden introducir problemas de rendimiento...": Esto también es cierto y es la clave del asunto. Los sistemas de bases de datos (como SQL Server, Oracle, etc.) están altamente optimizados para ejecutar sus funciones nativas (SUM, AVG, COUNT, etc.). Sin embargo, cuando introduces una UDF, el optimizador de la base de datos a menudo la trata como una "caja negra". No sabe exactamente qué hay dentro ni cómo optimizarla. Esto puede llevar a varios problemas de rendimiento: Ejecución fila por fila: En muchos casos, la UDF se ejecuta una vez por cada fila del resultado, en lugar de operar sobre el conjunto de datos de forma optimizada. Esto es mucho más lento, especialmente con millones de filas. Impiden la paralelización: El optimizador puede ser incapaz de dividir la consulta en tareas paralelas porque no puede garantizar que la UDF no tenga efectos secundarios o dependencias. Malas estimaciones de coste: El sistema no puede calcular correctamente cuánto "costará" (en tiempo y recursos) ejecutar la UDF, lo que lleva a planes de ejecución de la consulta muy ineficientes. En resumen, la afirmación es correcta porque describe perfectamente la dualidad de las UDFs: son una herramienta muy potente para extender la funcionalidad, pero su uso debe ser cuidadoso y meditado debido a su potencial impacto negativo en el rendimiento. ¿Por qué las otras respuestas serían incorrectas? Aunque no has puesto las otras opciones, podemos imaginar cuáles serían las alternativas incorrectas basándonos en los conceptos erróneos más comunes sobre las UDFs: Una respuesta que diga: "Las UDFs siempre mejoran el rendimiento de las consultas." Por qué es incorrecta: Es falso. Como hemos visto, su principal inconveniente es precisamente el riesgo de empeorar el rendimiento. Aunque pueden simplificar el código, rara vez lo hacen más rápido que las funciones nativas o las operaciones en línea bien escritas. Una respuesta que diga: "Las UDFs no tienen ningún impacto en el rendimiento y son siempre seguras de usar." Por qué es incorrecta: Es una generalización peligrosa. Ignora por completo los problemas de optimización que los motores de bases de datos tienen con ellas. Es la principal razón por la que muchos administradores de bases de datos (DBAs) limitan o desaconsejan su uso indiscriminado. Una respuesta que diga: "Las UDFs son inútiles porque las funciones nativas pueden hacer todo lo necesario." Por qué es incorrecta: También es falso. Hay innumerables lógicas de negocio o cálculos específicos que simplemente no existen como funciones nativas. Las UDFs llenan ese vacío, permitiendo una personalización que de otro modo sería imposible de lograr directamente en SQL.

Answer 498

B Date partitioning enables partition pruning, where queries scan only relevant date partitions, reducing data processed and improving performance.

Answer 499

C For e-commerce data, date partitioning allows queries to skip irrelevant date partitions, leading to faster execution and lower costs by processing less data.

Answer 500

B BigQuery's column-oriented storage stores values of a particular column separately. This means that if a query only requires a few columns from a large number of rows, BigQuery only needs to load those specific columns into memory from disk, providing better utilization of I/O and CPU-memory bandwidth and avoiding reading unnecessary data

Answer 501

A, B y D Nested and repeated fields offer the performance benefit of pre-joined tables, effectively avoiding costly SQL JOINs. They allow for differing data granularity in the same table and help in creating a single source of truth that is rich in context while maintaining granular details Explicación de las Respuestas Correctas Los campos anidados (STRUCT) y repetidos (ARRAY) son una forma de desnormalizar los datos de manera inteligente dentro de BigQuery. En lugar de seguir el modelo relacional tradicional de muchas tablas pequeñas (esquema de estrella o copo de nieve), se busca agrupar la información relacionada en una sola tabla ancha y rica en contexto. A) Avoiding costly and time-consuming SQL JOIN operations. (Evitar operaciones JOIN de SQL costosas y lentas). Correcto. ✅ Esta es la ventaja principal. Si tienes datos de pedidos y los artículos de cada pedido, en un modelo tradicional necesitarías una tabla pedidos y otra articulos_pedido. Para obtener la información completa, tendrías que hacer un JOIN. Al usar campos anidados, puedes tener una sola fila por pedido y dentro de esa fila, un ARRAY de STRUCTs que contenga todos los artículos de ese pedido. Consultar estos datos no requiere un JOIN, lo que es mucho más rápido y eficiente en BigQuery. B) Allowing for differing data granularity within the same table. (Permitir distinta granularidad de datos dentro de la misma tabla). Correcto. ✅ Siguiendo el ejemplo anterior, la fila principal de la tabla tiene una granularidad de "pedido" (un registro por pedido). Sin embargo, el campo repetido (ARRAY) dentro de esa fila tiene una granularidad de "artículo de pedido". De esta forma, una única tabla puede mantener múltiples niveles de detalle, lo cual es muy potente. D) Creating a single source of truth that is rich in context and maintains fine granular details. (Crear una única fuente de la verdad rica en contexto que mantiene detalles granulares finos). Correcto. ✅ Al combinar las ventajas A y B, el resultado es una tabla que funciona como una fuente única y completa para una entidad de negocio (como un cliente o un pedido). Contiene toda la información contextual (los datos del cliente, sus direcciones, sus pedidos) y los detalles más finos (los artículos de cada pedido, los precios, etc.) en un solo lugar, facilitando el análisis. Por qué la Respuesta C es Incorrecta C) Simplifying the process of normalization by spreading data across many tables. (Simplificar el proceso de normalización distribuyendo los datos en muchas tablas). Incorrecto. ❌ Esta afirmación describe exactamente lo opuesto a lo que hacen los campos anidados. "Distribuir los datos en muchas tablas" es el proceso de normalización. Los campos anidados y repetidos se utilizan para la desnormalización, es decir, para reducir el número de tablas y agrupar los datos. Por lo tanto, esta opción es conceptualmente incorrecta.

Answer 502

C The UNNEST() function in BigQuery is specifically used to flatten an array, returning a row for each element in the array. This is necessary to access and perform operations on individual array elements

Answer 503

A, C y D A STRUCT is referred to as a RECORD type in BigQuery. Unlike arrays, structs are flexible containers that can store multiple data types in their fields. Furthermore, structs can contain arrays, and conversely, arrays can contain structs as values

Answer 504

✅ Respuestas Correctas: B y C B) Dividir las tablas en "fragmentos" (shards) más pequeños y dinámicamente reequilibrados para un procesamiento masivamente paralelo. Esta es la base de la escalabilidad de BigQuery. ¿Qué significa? En lugar de tener una tabla gigante en un solo lugar, BigQuery la divide en innumerables trozos pequeños. Tu consulta no la ejecuta un solo "trabajador" gigante, sino miles de pequeños trabajadores simultáneamente, cada uno analizando un trocito de los datos. Esto se conoce como Procesamiento Masivamente Paralelo (MPP). ¿Por qué es bueno? Imagina que tienes que contar todas las sillas de un estadio. Sería muy lento si lo hiciera una sola persona. Pero si envías a 1,000 personas, cada una a contar una sección, y luego sumas sus resultados, terminarás en una fracción del tiempo. Así es como funciona BigQuery: divide el problema (la consulta) en partes más pequeñas y las resuelve todas a la vez. C) Utilizar un "servicio de barajado" (shuffle) en memoria para una comunicación eficiente entre los trabajadores y el particionamiento de los datos. Este es el secreto de su alto rendimiento. ¿Qué significa? Cuando ejecutas una consulta compleja (por ejemplo, con GROUP BY o JOIN), los datos intermedios que cada trabajador ha procesado deben ser reorganizados y redistribuidos a otros trabajadores para la siguiente fase del cálculo. Este proceso se llama "shuffle" (barajado). ¿Por qué es bueno? BigQuery tiene un servicio ultrarrápido que hace este barajado directamente en la memoria y a través de la red interna de petabits de Google. Es como tener un director de orquesta que recoge y distribuye las partituras entre los músicos a una velocidad increíble, en lugar de que ellos se las pasen lentamente entre sí. Esto evita cuellos de botella y hace que las agregaciones y uniones de datos sean extremadamente rápidas. ❌ Respuestas Incorrectas: A y D A) Almacenar todos los datos en una única instancia de base de datos monolítica. Esto es exactamente lo contrario a cómo funciona BigQuery. ¿Por qué es malo? Una base de datos monolítica es como una única caja registradora en un supermercado enorme. No importa lo rápida que sea, se convierte en un cuello de botella y no puede escalar para manejar grandes volúmenes de datos o muchas consultas a la vez. Es un diseño fundamentalmente no escalable para el análisis de petabytes. D) Requerir la gestión manual explícita de la partición de datos y la asignación de trabajadores por parte del usuario. Esto describe cómo funcionaban sistemas más antiguos (como los primeros clusters de Hadoop), pero es lo opuesto a la filosofía de BigQuery. ¿Por qué es malo? Una de las mayores ventajas de BigQuery es que es serverless (sin servidor) y totalmente gestionado. Tú, como usuario, solo escribes tu consulta SQL y BigQuery se encarga automáticamente de asignar los recursos, particionar los datos y optimizar la ejecución. No tienes que preocuparte por la infraestructura subyacente. Eliminar esta gestión manual es una de sus características clave.

Answer 505

A y C Respuestas Correctas (Por qué son VERDADERAS) A) Los arrays deben contener elementos del mismo tipo de datos Esto es VERDADERO. Un array en BigQuery es una lista ordenada de cero o más elementos del mismo tipo de dato. No puedes mezclar tipos. Ejemplo: [1, 2, 3] (un ARRAY) o ['a', 'b', 'c'] (un ARRAY). Inválido: [1, 'a', true] C) Puedes aplanar arrays usando la función UNNEST() Esto es VERDADERO. La función UNNEST() es la herramienta fundamental para trabajar con arrays. Toma un array y expande sus elementos en filas separadas. Ejemplo: Si una fila tiene un array ['manzana', 'pera'], UNNEST() lo convierte en dos filas: una para manzana y otra para pera. Respuestas Incorrectas (Por qué son FALSAS) B) Los arrays pueden anidarse directamente inside otros arrays Esto es FALSO. BigQuery no permite definir una columna de una tabla con un tipo de dato como ARRAY>. Si intentas crear una tabla con un "array de arrays" directo, fallará. La confusión: Lo que sí puedes hacer, y es la forma correcta de anidar, es tener un array de STRUCTs, y que ese STRUCT contenga otro array. Forma correcta: ARRAY>>. Como la pregunta dice "anidarse directamente", la respuesta es falsa. El anidamiento requiere una estructura (STRUCT) intermedia. D) Los arrays se declaran usando {} en SQL Esto es FALSO. En el SQL estándar de BigQuery, los arrays se construyen usando corchetes ([]). Correcto: SELECT [1, 2, 3] Incorrecto: SELECT {1, 2, 3} (Las llaves {} se usan en otros sistemas como PostgreSQL, pero no en BigQuery).

Answer 506

C Arrays and structs allow you to combine related data in a single table, reducing the need for expensive SQL joins and enabling more performant queries.

Answer 507

B ORDINAL(n) uses 1-based indexing, so ORDINAL(2) returns the second item: "blackberry".

Answer 508

B Por qué la opción B es la correcta ✅ La función UNNEST() en BigQuery toma un array y lo "desanida", convirtiendo cada elemento del array en una fila separada. Cuando añades la palabra clave WITH OFFSET, le pides a BigQuery que, además de crear una fila por cada elemento, genere una columna adicional que contenga la posición (el índice) de ese elemento dentro del array original. Este índice siempre empieza en 0. Ejemplo práctico: Imagina que tienes este array: ['manzana', 'plátano', 'cereza']. Si ejecutas la siguiente consulta: SELECT fruta, posicion FROM UNNEST(['manzana', 'plátano', 'cereza']) AS fruta WITH OFFSET AS posicion; El resultado será: fruta posicion manzana 0 plátano 1 cereza 2 Como ves, WITH OFFSET ha creado la columna posicion que te permite saber que 'manzana' estaba en el índice 0, 'plátano' en el 1, etc. Es muy útil para mantener el orden original o para realizar uniones basadas en la posición. Por qué las otras opciones son incorrectas ❌ A) To skip a number of elements from the start (Para saltar un número de elementos desde el principio): Esto es incorrecto. Esta funcionalidad corresponde a la cláusula OFFSET que se usa junto con LIMIT para la paginación de resultados (por ejemplo, LIMIT 10 OFFSET 20), pero no tiene nada que ver con el WITH OFFSET que se usa en UNNEST(). Es una confusión común por compartir el mismo nombre. C) To convert arrays into structs (Para convertir arrays en structs): Esto es incorrecto. UNNEST() se usa para aplanar arrays en filas, no para convertirlos en STRUCTs (estructuras). Para crear STRUCTs se usa una sintaxis diferente, como SELECT STRUCT(1 AS x, 'foo' AS y). D) To sort arrays before flattening (Para ordenar arrays antes de aplanarlos): Esto es incorrecto. UNNEST() WITH OFFSET no ordena el array; de hecho, hace lo contrario: preserva el orden original y te da el índice de cada elemento en ese orden. Si quisieras ordenar los elementos, usarías una cláusula ORDER BY después de haber aplicado UNNEST().

Answer 509

D STRUCTs are flexible containers that allow multiple fields of different data types, including arrays, and fields can be optionally named.

Answer 510

C This is the canonical use case for nested and repeated fields in BigQuery. Using a REPEATED field of STRUCTs (as shown in slide 9) allows you to maintain the one-to-many relationship within a single row. This pre-joins the data, avoiding the computational overhead of JOINs at query time, which is more performant and scalable for analytical queries, directly addressing the core concept of the presentation.

Answer 511

D In the BigQuery schema definition, Type: RECORD is the official name for a STRUCT (a container for other fields). Mode: REPEATED signifies that the field is an ARRAY (it can have multiple values in a single row). Therefore, a field that is a REPEATED RECORD is an ARRAY of STRUCTs La respuesta correcta es la D. Esta pregunta es clave porque evalúa tu comprensión de cómo BigQuery maneja datos anidados y repetidos, una de sus características más potentes. ✅ Respuesta Correcta: D La opción D. An array of objects, where each object can have its own distinct set of sub-fields (Una matriz de objetos, donde cada objeto puede tener su propio conjunto de sub-campos) es la descripción correcta. Vamos a desglosarlo: Type = RECORD (también llamado STRUCT): Esto significa que el campo no es un valor simple (como un texto o un número), sino un contenedor o un objeto que agrupa otros campos dentro de sí. Por ejemplo, un RECORD llamado producto podría contener los sub-campos id_producto (INTEGER), nombre (STRING) y precio (FLOAT). Mode = REPEATED: Este modo significa que el campo puede contener múltiples valores de su tipo definido. En la práctica, esto lo convierte en una matriz o lista. Al combinar ambos, RECORD y REPEATED, el resultado es una matriz de objetos. En el contexto de la pregunta, el campo line_items representa una lista de todos los artículos de una factura, donde cada artículo de la lista es un objeto con sus propios detalles (como id_producto, cantidad, precio_unitario). ❌ Explicación de las Respuestas Incorrectas A. A single, complex object with multiple sub-fields. Incorrecto. Esto describiría un campo con Type = RECORD y Mode = NULLABLE (el modo por defecto). Sería un único objeto, no una lista de ellos. El modo REPEATED es el que indica que puede haber más de uno. B. An array of simple values, such as an array of strings. Incorrecto. Esto describiría un campo con un tipo simple (como STRING o INTEGER) y un Mode = REPEATED. Sería una lista de valores simples (ej: ['rojo', 'verde', 'azul']), pero no una lista de objetos complejos. El tipo RECORD es el que indica que cada elemento de la lista es un objeto. C. A single value that can be either a string or an integer. Incorrecto. Esto no describe una estructura estándar en un esquema de BigQuery. Un campo tiene un tipo de dato definido. Esta opción no tiene relación con los tipos RECORD o REPEATED.

Answer 512

C To filter based on the contents of an array, you must first "unpack" or flatten the array so that SQL operators can evaluate its individual elements. The UNNEST() function (slide 30) converts an array into a set of rows. The WHERE ... IN UNNEST() clause is the standard and most efficient way to check for the existence of an element within an array for each row, as demonstrated on slide 37.

Answer 513

B y C The presentation highlights two fundamental architectural pillars: Columnar Storage (B): Slide 45 explicitly contrasts record-oriented (row-based) storage with BigQuery's column-oriented storage, noting that it allows BigQuery to only read the columns required for a query, drastically reducing I/O and improving performance. Massively Parallel Processing (C): Slides 47-50 explain how BigQuery breaks tables into smaller shards and uses thousands of workers (slots) to read and process these shards in parallel, which is the key to its massive scalability. Row-oriented storage (A) and primary key indexing (D) are characteristic of traditional RDBMS/OLTP systems, not BigQuery's analytical architecture.

Answer 514

C La Respuesta Correcta: C (El usuario no será cobrado) Por qué es la buena: La regla de facturación de BigQuery para consultas bajo demanda (On-demand pricing) es muy clara y generosa en este aspecto: Si la consulta falla, es gratis: No importa si el error ocurre al principio (sintaxis) o a la mitad de la ejecución (como en este caso, un error de tiempo de ejecución o runtime error). Si el trabajo (Job) termina con estado de error, Google no te cobra nada por esa consulta específica. Análisis del Error (Contexto técnico) Para que entiendas por qué falló la consulta: El array ['apple', 'pear', 'orange'] tiene 3 elementos. En BigQuery, OFFSET empieza a contar desde 0. OFFSET(0) = apple OFFSET(1) = pear OFFSET(2) = orange La consulta pide OFFSET(3), que sería un cuarto elemento que no existe. Esto provoca un error de "Index out of bounds" (índice fuera de límites) durante la ejecución. Por qué las otras son las malas A. Se facturará por la cantidad total de datos que habría procesado Por qué falla: Esto sería muy injusto. Imagina una consulta que tarda 1 hora y falla en el último segundo. BigQuery no te cobra por el intento fallido. Solo pagas por éxito. B. Se facturará un mínimo de 10 MB Por qué falla: Los 10 MB son el coste mínimo para una consulta exitosa que procese pocos datos. Si la consulta da error, el coste es 0, no el mínimo. D. Se facturará basándose en los bytes de la columna fruit_array Por qué falla: Al igual que las anteriores, asume que hay un cobro. Si la consulta hubiera tenido éxito, esta sería la lógica correcta (pagas por las columnas leídas), pero al fallar, el contador se pone a cero.

Answer 515

B In traditional relational databases, data is often split across multiple tables, requiring expensive JOIN operations to combine data. BigQuery's support for nested and repeated fields (arrays and structs) allows related data to be stored together in a single table, minimizing the need for JOINs and improving query performance, especially for large-scale datasets.

Answer 516

D La opción correcta: POSITION En BigQuery, POSITION no es una función o palabra clave que se utilice para acceder directamente a los elementos de un ARRAY (una lista de valores) por su índice. La función POSITION tiene otro propósito: se usa dentro de la función ARRAY_AGG para especificar el orden de los elementos en la agregación, pero no para seleccionar un elemento individual de un ARRAY ya existente. Las opciones incorrectas: OFFSET, ORDINAL e INDEX Estas tres sí son formas válidas de acceder a los elementos de un ARRAY en BigQuery, aunque INDEX es un concepto más que una palabra clave específica como las otras dos. A) OFFSET: Esta es la forma más común y estándar. Permite acceder a un elemento del ARRAY utilizando un índice basado en cero. Esto significa que el primer elemento está en la posición 0, el segundo en la 1, y así sucesivamente. Ejemplo: mi_array[OFFSET(0)] devuelve el primer elemento del ARRAY. B) ORDINAL: Esta opción permite acceder a un elemento utilizando un índice basado en uno. Esto puede ser más intuitivo para quienes no están acostumbrados a la programación, donde el conteo suele empezar en 1. Ejemplo: mi_array[ORDINAL(1)] también devuelve el primer elemento del ARRAY. C) INDEX (Índice directo): BigQuery también permite el acceso directo a los elementos de un ARRAY mediante corchetes [], lo cual es conceptualmente usar un índice. Por defecto, este método se comporta como OFFSET, es decir, está basado en cero. Ejemplo: mi_array[0] es equivalente a mi_array[OFFSET(0)] y devuelve el primer elemento.

Answer 517

B The UNNEST() function in BigQuery is used to expand (or "flatten") an array into a set of rows, allowing you to query individual elements of the array as if they were separate rows in the table. This is particularly useful for analyzing repeated data.

Answer 518

C Structs in BigQuery are flexible containers that can hold fields of various data types, such as integers, strings, booleans, as well as more complex types like arrays and even other structs. This allows for deeply nested data structures, making it easier to store and query related data.

Answer 519

B BigQuery uses column-oriented storage, where data is stored column by column rather than row by row. This architecture allows for faster retrieval of specific columns and is particularly efficient for analytical queries where only a subset of columns is needed, especially at petabyte scale.

Answer 520

E he sources explicitly list I/O, Shuffle, Grouping, and Materialization as four key elements of work BigQuery performs on the back-end. CPU work (e.g., UDFs, functions) is also mentioned as a key element

Answer 521

B y C The sources recommend filtering with WHERE as early as possible and advise against using ORDER BY without a LIMIT clause to avoid wastefulness. Using SELECT * is discouraged, and grouping by high-cardinality unique IDs is considered a bad idea Las respuestas correctas son la B y la C. Estas prácticas son fundamentales para controlar los costes y mejorar el rendimiento de tus consultas en BigQuery. Prácticas Recomendadas ✅ B) Filter using WHERE as early as possible in your queries. (Filtrar usando WHERE lo antes posible en tus consultas). Correcto. Esta es una de las optimizaciones más importantes. Al filtrar pronto, reduces drásticamente la cantidad de datos que BigQuery necesita procesar en las siguientes etapas de la consulta (como JOINs o GROUP BYs). Si tu tabla está particionada (por ejemplo, por fecha), filtrar por esa columna de partición permite que BigQuery ignore por completo los datos de las particiones que no necesitas, ahorrando una enorme cantidad de I/O y coste. C) Avoid using ORDER BY without a LIMIT clause. (Evitar usar ORDER BY sin una cláusula LIMIT). Correcto. Un ORDER BY sobre un conjunto de resultados muy grande es una operación extremadamente costosa. Requiere que BigQuery recopile todos los resultados en un único nodo para realizar la ordenación final, lo que puede agotar la memoria y hacer que la consulta falle. Al añadir LIMIT, BigQuery puede realizar una ordenación mucho más eficiente (una operación "top-N") en paralelo y solo necesita combinar los mejores resultados, lo que consume muchos menos recursos. Prácticas a Evitar ❌ A) Use SELECT * to retrieve all columns for convenience. (Usar SELECT * para obtener todas las columnas por conveniencia). Incorrecto. Este es el anti-patrón número uno en BigQuery. Como BigQuery es una base de datos columnar, se te cobra por la cantidad de datos leídos de las columnas que especificas. SELECT * obliga a BigQuery a leer cada byte de cada columna de la tabla, maximizando el coste y el tiempo de procesamiento, incluso si solo necesitabas dos columnas. Siempre debes seleccionar explícitamente solo las columnas que necesitas. D) Group by a high-cardinality unique ID. (Agrupar por un ID único de alta cardinalidad). Incorrecto. "Alta cardinalidad" significa que hay muchos valores únicos (por ejemplo, un transaction_id). Agrupar por una columna así es ineficiente porque genera una cantidad masiva de grupos (prácticamente un grupo por cada fila). Esto provoca un "shuffle" de datos enorme entre los nodos de BigQuery, creando un cuello de botella y degradando gravemente el rendimiento. Generalmente, indica un error en la lógica de la consulta.

Answer 522

C The Query Explanation map can highlight data skew by allowing you to compare the Max vs. the Avg times. A large difference between the average and max times can indicate heavy skew inside your dataset

Answer 523

B Table partitioning helps reduce the volume of data scanned by allowing queries to restrict to specific date ranges, such as only the seven most recent daily partitions. In contrast, manual table sharding often leads to more complex SQL queries and manual table creation/maintenance, and performance can degrade as the number of referenced tables increases

Answer 524

B To reduce computational load and optimize performance, it is recommended to use native SQL functions whenever possible instead of UDFs. UDFs can increase computational load, and they have a lower concurrent rate limit (6) compared to non-UDF queries (50)

Answer 525

B y C Selecting only needed columns and applying filters early helps reduce the number of bytes processed, improving performance. SELECT * and ORDER BY without a limit are anti-patterns.

Answer 526

C Data skew causes imbalance by overloading some worker slots, leading to slower performance due to uneven data partitioning during shuffle operations.

Answer 527

B Grouping by high-cardinality fields like unique IDs increases shuffling, which can significantly degrade performance. La Lógica Clave: El "Shuffle" y la Cardinalidad Para entender por qué, primero debemos saber cómo funciona una operación GROUP BY en un sistema distribuido como BigQuery. Fase de Agregación Local (Map): BigQuery divide tu tabla en muchas partes pequeñas y las procesa en paralelo en diferentes "workers" (nodos de cómputo). Cada worker intenta pre-agregar los datos que tiene. Fase de Mezcla (Shuffle): Para completar el GROUP BY, los datos con la misma clave de agrupación (por ejemplo, el mismo country_code) deben ser enviados al mismo worker para la agregación final. Este proceso de mover datos a través de la red se llama "shuffle" y es, con diferencia, la parte más lenta y costosa de una consulta de agregación. El objetivo para tener un buen rendimiento es minimizar la cantidad de datos que se mueven en la fase de shuffle. Aquí es donde entra en juego la cardinalidad. Cardinalidad: Se refiere al número de valores distintos en una columna. Baja Cardinalidad: Pocos valores distintos (ej: una columna género con 'Hombre', 'Mujer', 'Otro'). Alta Cardinalidad: Muchos valores distintos (ej: una columna user_id donde cada valor es único). Análisis de las Opciones B. Grouping by a high-cardinality unique ID (Práctica Desaconsejada - Respuesta Correcta) ¿Por qué es malo? Cuando agrupas por una columna con altísima cardinalidad, como un user_id o un transaction_id (donde casi todos los valores son únicos), la fase de agregación local es inútil. Cada worker encuentra valores únicos y no puede pre-agregar casi nada. Como resultado, tiene que enviar casi todas las filas de la tabla a través de la red durante la fase de shuffle. Esto genera un cuello de botella masivo, consume muchos recursos y hace que la consulta sea extremadamente lenta. Es un anti-patrón de rendimiento conocido en sistemas de Big Data. ¿Por qué las otras opciones son correctas o incluso buenas prácticas? A. Grouping by a small number of distinct values (Práctica Recomendada) ¿Por qué es bueno? Esto es agrupar por una columna de baja cardinalidad. Es el escenario ideal. Si agrupas por país, cada worker puede calcular los totales para 'España', 'México', 'Argentina', etc., de forma local. Luego, en la fase de shuffle, solo necesita enviar una fila por cada país ('España', 1500, 'México', 1200, etc.). Esto reduce drásticamente la cantidad de datos que se mueven por la red, haciendo la consulta muy rápida y eficiente. C. Aggregating results with COUNT(*) (Práctica Estándar) ¿Por qué no es un problema? COUNT(*) es una de las funciones de agregación más optimizadas en BigQuery. Está diseñada específicamente para ser usada con GROUP BY. No causa problemas de rendimiento; al contrario, es una operación fundamental y muy eficiente. D. Using LOG10() to bucket numerical values (Práctica de Optimización) ¿Por qué es bueno? Esta es una técnica inteligente para reducir la cardinalidad. Imagina que tienes una columna precio con millones de valores distintos. Agrupar por precio sería muy lento (alta cardinalidad). Sin embargo, si agrupas por CAST(LOG10(precio) AS INT64), estás agrupando los precios por su orden de magnitud (precios entre 1-9, 10-99, 100-999, etc.). Has convertido una columna de alta cardinalidad en una de baja cardinalidad, mejorando enormemente el rendimiento. Es una técnica de "bucketing" (agrupación en cubos) muy recomendada.

Answer 528

C Partitioned tables reduce the volume of data scanned by narrowing queries to relevant partitions, especially when querying by date.

Answer 529

B Cloud Monitoring provides nearly real-time visual metrics (e.g., slot utilization, query time) that help in identifying performance bottlenecks.

Answer 530

C Applying WHERE filters as early as possible in your queries reduces the amount of data processed, leading to faster and more cost-effective queries

Answer 531

B Un "hotspot" o desequilibrio de datos (data skew) ocurre cuando un valor de clave específico en una operación GROUP BY tiene muchísimos más registros que el resto. Esto obliga a que un solo "slot" (unidad de trabajo) de BigQuery se sobrecargue procesando todos los datos de esa clave, mientras los demás slots están inactivos, creando un cuello de botella que ralentiza toda la consulta. La opción B describe la causa más clásica de este problema: Imagina una tabla de eventos de usuario: Tienes una columna user_id que es única para cada usuario registrado (alta cardinalidad). El problema: Para los usuarios no registrados o eventos del sistema, en lugar de un user_id único, se usa un valor genérico como NULL, '' (vacío) o 'guest'. La consecuencia: Al hacer GROUP BY user_id, la clave NULL (o 'guest') se convierte en un "hotspot" porque tiene millones de registros, mientras que los user_id de los usuarios reales tienen muy pocos. Todo el trabajo se concentra en procesar esa única clave NULL. ¿Cómo se evita? La solución más común es filtrar la clave problemática antes de la agrupación. Por ejemplo: SELECT user_id, COUNT(event) FROM my_table WHERE user_id IS NOT NULL -- Se excluye la clave problemática GROUP BY user_id Por qué las otras opciones son incorrectas A) Agrupar por un campo de baja cardinalidad: Esto es lo contrario a un hotspot. Un campo de baja cardinalidad tiene muy pocos valores distintos (ej: país, género, tipo_de_dispositivo). BigQuery está optimizado para manejar estas agrupaciones sin problemas. C) Usar ORDER BY con LIMIT: Aunque un ORDER BY sobre un conjunto de datos muy grande puede ser costoso porque requiere que todos los datos vayan a un único slot para la ordenación final, no es un problema de "hotspot" o desequilibrio de datos. Es un tipo de cuello de botella diferente, relacionado con el volumen total a ordenar, no con una clave específica que esté desequilibrada. D) Usar funciones nativas de SQL: Esto es demasiado genérico. Las funciones nativas de SQL (TIMESTAMP_TRUNC, CAST, JSON_EXTRACT, etc.) son herramientas optimizadas y la forma recomendada de trabajar en BigQuery. Su uso no causa desequilibrios; de hecho, a menudo se usan para prevenir o solucionar problemas de datos.

Answer 532

A, C y D Selecting only necessary columns, avoiding ORDER BY without a LIMIT, and using table partitioning all help reduce the amount of data scanned and processed. Self-joins should be avoided when possible

Answer 533

B (Nota: En la interfaz de BigQuery, esto se conoce más comúnmente como el "Plan de Consulta" o "Detalles de Ejecución" (Query plan / Execution details)). Por qué esta es la correcta B. Query Explanation Map (Plan de Consulta) Qué es: Es una visualización gráfica y tabular de los pasos (o "etapas") que BigQuery sigue para ejecutar tu consulta. Por qué encaja: Esta herramienta está diseñada específicamente para diagnosticar el rendimiento. Te muestra: Problemas de rendimiento: Dónde está gastando BigQuery la mayor parte del tiempo (por ejemplo, en una etapa específica de JOIN o GROUP BY). Data Skew (Sesgo de datos): Te muestra cuántas filas y cuántos datos procesó cada slot (trabajador) en cada etapa. Si ves que un solo slot está procesando el 90% de los datos mientras los demás están casi inactivos, has identificado un "data skew". Esto suele ocurrir por una mala elección de la clave en un JOIN o GROUP BY. Por qué estas son las incorrectas A. Cloud Storage Qué es: Es un servicio de almacenamiento de objetos (archivos). Por qué falla: Se usa para guardar o cargar archivos (como CSVs o Parquets) en BigQuery. No tiene ninguna función para analizar o diagnosticar el rendimiento de una consulta SQL. C. Dataflow Qué es: Es un servicio para crear pipelines de procesamiento de datos (ETL/ELT), tanto en batch como en streaming. Por qué falla: Podrías usar Dataflow para preparar los datos antes de que lleguen a BigQuery, pero no es la herramienta que usas para diagnosticar una consulta SQL dentro de BigQuery. D. Stackdriver Logging (ahora Cloud Logging) Qué es: Es el servicio centralizado de registros (logs) de Google Cloud. Por qué falla: Es útil para la auditoría. Puedes ver quién ejecutó una consulta, cuándo la ejecutó y cuánto tiempo total tardó. Sin embargo, no te da el desglose interno por etapas. Te dice "la consulta fue lenta", pero no te dice por qué fue lenta ni te permite ver el data skew entre los slots.

Answer 534

B Table partitioning allows queries to scan only relevant partitions (such as specific dates), significantly reducing the volume of data scanned and improving performance

Answer 535

A y C A is correct because SELECT * forces BigQuery to read all data from all columns in the table, which increases I/O and processing costs unnecessarily. Best practice is to select only the columns you need (Slide 5). C is correct because sorting a very large result set requires all the data to be collected on a single worker, which can easily cause the query to fail or run very slowly due to resource exhaustion. ORDER BY should almost always be paired with a LIMIT (Slide 5). (B is a best practice for reducing data scanned, and D is the ideal use case for GROUP BY).

Answer 536

C Data skew means that data is unevenly distributed among BigQuery workers, causing some workers (slots) to do far more work than others. The Query Explanation map visualizes this by showing both the average worker time (darker bar) and the maximum worker time (lighter bar). A large gap between these two values indicates that at least one worker is a "hotspot" and is taking much longer than the average, which is the definition of a performance problem caused by data skew (Slide 7).

Answer 537

B The main advantage of using native partitioning is partition pruning. When you filter on the partitioning column (e.g., WHERE event_date = '2023-10-26'), BigQuery can completely ignore the data in all other partitions. This dramatically reduces the bytes scanned, which lowers costs and improves query performance (Slide 15). Both sharded and partitioned tables are stored in a columnar format, and partitioning does not affect UDF concurrency or shuffling in this way.

Answer 538

A A GROUP BY operation requires BigQuery to shuffle data so that all rows with the same key end up on the same worker for aggregation. If the key has very high cardinality (many unique values), it results in a massive shuffle of data across the network, which is computationally expensive and slow. Grouping by a unique ID is a classic anti-pattern (Slide 8 & 14). While the other options can be performance issues, they do not directly cause an oversized shuffle.

Answer 539

B UDFs are computationally more expensive than native functions because they require spinning up a JavaScript processing environment for each row or batch of rows. Because of this overhead, BigQuery imposes a much lower concurrent query limit on projects running UDFs (a limit of 6) compared to standard SQL queries (a limit of 50). Therefore, best practice is to always use native functions when possible (Slide 10).

Answer 540

B ✅ La Respuesta Correcta: B) Shuffle La pregunta se refiere a un "elemento de trabajo" que "contribuye al rendimiento". El Shuffle (barajado o redistribución) es la operación más costosa y un elemento de trabajo fundamental en cualquier consulta distribuida. ¿Qué es el Shuffle? En un sistema como BigQuery, tu consulta se divide entre muchos trabajadores (slots) que se ejecutan en paralelo. Cada trabajador lee una parte de los datos. ¿Cuándo ocurre? Cuando necesitas agrupar o unir datos que están en diferentes trabajadores. Por ejemplo, en un GROUP BY, JOIN, o ORDER BY. ¿Por qué es un "elemento de trabajo"? Los trabajadores deben "hablar" entre sí a través de la red para intercambiar los datos y asegurarse de que todos los registros con la misma clave (ej. el mismo ID de usuario en un JOIN) terminen en el mismo trabajador para ser procesados juntos. ¿Por qué afecta al rendimiento? Este movimiento de datos a través de la red (el shuffle) es, con diferencia, la parte más lenta de la consulta. Es un cuello de botella. La cantidad de datos que se mueven en el shuffle es un "elemento de trabajo" clave que determina (contribuye a) el rendimiento final. En resumen: El Shuffle es el trabajo activo de mover datos entre nodos durante la ejecución de la consulta. Minimizar el shuffle (por ejemplo, usando clustering o particionado) es una de las técnicas principales para optimizar el rendimiento. ❌ Por Qué las Otras Opciones Son Incorrectas A) Data compression (Compresión de datos): BigQuery sí usa compresión (en su formato de almacenamiento columnar, Capacitor). Esto mejora el rendimiento porque se lee menos disco (I/O). Sin embargo, no es un "elemento de trabajo de la consulta", sino una característica del almacenamiento. Es algo pasivo que ocurre cuando se guardan los datos, no una fase activa de la ejecución de la consulta como lo es el shuffle. C) Query caching (Caché de consultas): BigQuery también usa una caché. Si ejecutas la misma consulta dos veces y los datos no han cambiado, te devuelve el resultado de la caché al instante, sin coste. Esto es lo opuesto a un "elemento de trabajo". Usar la caché significa que BigQuery evita hacer el trabajo por completo. La pregunta es sobre un elemento del trabajo, no sobre cómo evitarlo. D) Data encryption (Cifrado de datos): Esto es una característica de seguridad. BigQuery cifra todos los datos en reposo y en tránsito por defecto. No se considera un elemento clave del rendimiento de la consulta. Aunque técnicamente existe un coste mínimo de CPU para cifrar/descifrar, es marginal y no es un factor que los analistas o ingenieros optimicen para mejorar la velocidad de una consulta.

Answer 541

C Page 5 of the document explicitly advises filtering using WHERE as early as possible to reduce the amount of data processed, thus avoiding I/O wastefulness. The other options are either anti-patterns (A, B, D) or not recommended in the context of optimizing I/O.

Answer 542

A y D Page 7 explains that filtering datasets early avoids overloading workers during JOINs, helping to prevent data hotspots. It also recommends using the Query Explanation map to compare max vs. average times to highlight data skew, which causes hotspots. Option B is incorrect as self-joins are discouraged (Page 9), and option C is an anti-pattern (Page 8) that can exacerbate skew.

Answer 543

B Page 15 notes that daily tables for sharding have disadvantages, including the need to manually or programmatically create them. This adds maintenance overhead compared to partitioned tables. Options A, C, and D are incorrect as they either misrepresent the document or contradict its content (e.g., there is a 1,000-table limit).

Answer 544

B Page 7 states that comparing max vs. average times in the Query Explanation map can highlight data skew, and Page 17 reinforces that a large difference between average and max times indicates heavy skew in the dataset. This skew can bottleneck query performance. The other options are not associated with this specific indicator in the document.

Answer 545

D The sources mention securing individual columns through encryption, limiting access to specific rows in a table through authorized views, and hashing columns with FARM_FINGERPRINT() as methods for safeguarding data.

Answer 546

B La función $FARM_FINGERPRINT() genera un hash de un valor de entrada. Un hash es básicamente una "huella digital" numérica de un dato. Esta función tiene dos características clave para este caso de uso: Es determinista: Siempre que le das el mismo valor de entrada (ej: el string "hola"), te devuelve exactamente la misma huella digital (el mismo número). Distribuye bien los resultados: Genera huellas digitales que se reparten de manera muy uniforme, como si fueran números al azar. En bases de datos distribuidas muy grandes, los datos se dividen en particiones o "shards" para mejorar el rendimiento. Para que esto funcione bien, los datos deben repartirse de manera equitativa entre todos los shards. El problema: A veces, la clave primaria natural de una tabla no se distribuye bien. Por ejemplo, si usas una fecha o un ID de cliente secuencial, los datos nuevos siempre irán a parar al mismo shard, creando un "punto caliente" (hotspot) que ralentiza todo el sistema. La solución: Se crea una nueva columna aplicando $FARM_FINGERPRINT() a la clave primaria original (o a otra columna). El resultado es un número que sí se distribuye de manera uniforme. Usando esta nueva columna como clave de sharding (o clave de distribución), la base de datos puede repartir las filas de forma equitativa entre los diferentes servidores, equilibrando la carga y mejorando el rendimiento enormemente. Por eso, este es un caso de uso principal y una buena práctica para esta función. Por qué las otras opciones son incorrectas A) Almacenar contraseñas sensibles de forma segura. Esto es incorrecto y muy peligroso. $FARM_FINGERPRINT() es una función de hashing no criptográfica. Esto significa que está diseñada para ser rápida, no para ser segura. Para almacenar contraseñas se deben usar algoritmos de hash criptográficos y lentos por diseño (como bcrypt, scrypt o Argon2), que además incorporan una "sal" (salt). Estos están diseñados específicamente para resistir ataques de fuerza bruta y de diccionario, algo que $FARM_FINGERPRINT() no hace en absoluto. C) Cifrar conjuntos de datos completos para su almacenamiento a largo plazo. Esto es incorrecto porque confunde dos conceptos diferentes: hashing y cifrado (o encriptación). Hashing: Es un proceso de una sola vía. Conviertes un dato en una huella digital, pero no puedes revertir el proceso para obtener el dato original. $FARM_FINGERPRINT('hola') te da un número, pero con ese número no puedes saber que la palabra original era "hola". Cifrado (Encryption): Es un proceso de dos vías. Cifras los datos con una clave y luego puedes descifrarlos con la misma clave (o una clave relacionada) para recuperar la información original. Para almacenar datos a largo plazo y poder leerlos después, necesitas cifrado, no hashing. D) Limitar el acceso de los usuarios a filas específicas de una tabla. Esto es incorrecto. El control de acceso a los datos es una función del sistema de gestión de la base de datos, no del hashing de datos. Para limitar qué filas puede ver un usuario, se utilizan mecanismos como los permisos (GRANT/REVOKE), los roles y, más específicamente, la Seguridad a Nivel de Fila (Row-Level Security). Aplicar un hash a una columna no impide que un usuario autorizado vea la fila; simplemente verá el valor hasheado en lugar del original, pero no controla el acceso a la fila en sí.

Answer 547

C ✅ Por qué la opción C es la CORRECTA Para entender esto, hay que dividir la solución en dos partes técnicas: La lógica de filtrado (SESSION_USER()): Esta función de SQL devuelve el correo electrónico del usuario que está ejecutando la consulta (ej: juan@empresa.com). Si escribes una consulta como: SELECT * FROM Ventas WHERE vendedor_email = SESSION_USER() BigQuery filtrará dinámicamente los resultados. Juan solo verá las filas donde la columna vendedor_email coincida con su correo. El mecanismo de entrega (Authorized Views): Si le das acceso directo a Juan a la tabla Ventas, él podría borrar el filtro WHERE y ver todo. Aquí entra la Vista Autorizada. Creas una Vista con esa consulta SQL. Le das permiso a Juan para ver la Vista, pero NO la tabla original. Al ser una "Authorized View", la vista tiene permiso para leer la tabla, pero Juan solo puede ver lo que la vista le permite (sus propias filas). Nota Importante: Hoy en día, BigQuery tiene una función nativa llamada Row-Level Security policies, pero en el contexto de exámenes (y muchas implementaciones existentes), las Vistas Autorizadas son la respuesta estándar para este patrón. ❌ Por qué las otras opciones son MALAS A) "FARM_FINGERPRINT() for column hashing" (FARM_FINGERPRINT() para hash de columnas) Para qué sirve: FARM_FINGERPRINT es una función matemática que convierte un texto en un número (hash). Se usa para evitar duplicados o para distribuir datos aleatoriamente (sharding). Por qué falla: No tiene nada que ver con permisos o seguridad. Convertir "Juan" en "8473829" no impide que Pedro vea los datos de Juan. B) "BigQuery predefined roles like dataViewer" (Roles predefinidos de BigQuery como dataViewer) Para qué sirve: IAM (Identity and Access Management) controla el acceso a nivel de recurso. Por qué falla: IAM es "todo o nada" a nivel de tabla. Si le das a un usuario el rol dataViewer sobre una tabla, puede ver todas las filas de esa tabla. IAM no tiene la capacidad de mirar dentro de la tabla y decir "esta fila sí, esta fila no". D) "Granting the Owner role to specific users" (Otorgar el rol de Propietario a usuarios específicos) Para qué sirve: El rol Owner (Propietario) da control total: puede ver datos, borrarlos, cambiar permisos y eliminar la tabla. Por qué falla: ¡Es justo lo opuesto a lo que quieres! Quieres limitar el acceso, no darles las llaves maestras del castillo. Esto violaría el principio de "menor privilegio". Resumen Mental para el Examen ¿Control a nivel de Tabla/Dataset? -> Usa IAM (Roles). ¿Control a nivel de Fila (Row-Level)? -> Usa Vistas Autorizadas (con SESSION_USER) o Políticas de Seguridad de Fila. ¿Control a nivel de Columna (Column-Level)? -> Usa Policy Tags (Etiquetas de política).

Answer 548

B Source explicitly states that "If you create a dataset, BigQuery grants all project owners the bigquery.dataOwner predefined role for the new dataset." Source clarifies that IAM Project roles do affect BigQuery permissions, and that default access to datasets can be overridden. Source identifies jobUser as the lowest level predefined role.

Answer 549

D The sources recommend all listed practices: periodically auditing access controls, using separate environments for different stages like DEV, QA, and PRD, and having a written Data Access Policy for the organization

Answer 550

B Authorized views can filter data based on the logged-in user (e.g., using SESSION_USER()) to enforce row-level access control. B. Las vistas autorizadas se utilizan para restringir el acceso a las filas en función de la identidad del usuario. Este es uno de los casos de uso más importantes y potentes de las vistas autorizadas. Permiten implementar la seguridad a nivel de fila (row-level security). Funciona así: Creas una vista que contiene una consulta SQL. Dentro de la consulta, usas la función SESSION_USER() en la cláusula WHERE para filtrar los datos. Por ejemplo: WHERE email_cliente = SESSION_USER(). Concedes permiso a los usuarios para que consulten esta vista, pero no les das permiso para acceder a la tabla original. El resultado es que cuando un usuario consulta la vista, solo verá las filas que le pertenecen, ya que la vista filtra automáticamente los resultados según su identidad. ❌ Respuestas Incorrectas A. Permiten el enmascaramiento de datos basado en la seguridad a nivel de columna: Incorrecto. El enmascaramiento de datos y la seguridad a nivel de columna son características distintas en BigQuery que se gestionan con etiquetas de política (policy tags). Aunque puedes crear una vista que enmascare datos, esa no es su función principal ni la forma en que se implementa la seguridad de columna nativa. C. Solo se pueden usar en el mismo proyecto que el conjunto de datos original: Incorrecto. De hecho, uno de los beneficios clave de las vistas autorizadas es compartir datos de forma segura entre diferentes proyectos. D. Se utilizan para mejorar el rendimiento de las consultas: Incorrecto. Las vistas autorizadas son una herramienta de seguridad y control de acceso, no de rendimiento. Para mejorar el rendimiento, se utilizan vistas materializadas, particiones o clústeres.

Answer 551

D jobUser is the most restricted predefined role in BigQuery, typically only allowing a user to run jobs they start themselves.

Answer 552

B y D You should use authorized views to restrict row access and regularly audit user permissions to ensure the principle of least privilege.

Answer 553

B FARM_FINGERPRINT() is used to hash values to improve data distribution across shards, which can help with performance. La función FARM_FINGERPRINT() toma cualquier valor (como un ID de usuario o un país) y lo convierte en un número de 64 bits. La propiedad más importante de este número es que, aunque siempre es el mismo para la misma entrada, la distribución de los números de salida parece aleatoria. El propósito principal de esto es resolver el problema del sesgo de datos (data skew). Imagina que tienes una tabla de usuarios y el 80% son de "España". Si intentas agrupar o dividir el trabajo por país, una partición (shard) tendría que procesar el 80% de los datos, mientras que las demás estarían casi vacías. Esto es muy ineficiente. Al aplicar FARM_FINGERPRINT(pais), conviertes "España" en un número (por ejemplo, 54321), "Francia" en otro (12345), etc. Estos números se distribuyen de manera mucho más uniforme, lo que permite a BigQuery repartir la carga de trabajo de manera equitativa entre sus trabajadores internos. Usos comunes: Crear muestras de datos aleatorias pero consistentes. Asignar usuarios a grupos para pruebas A/B. Evitar cuellos de botella en el rendimiento por claves de unión o agrupación muy repetidas. Por qué las otras opciones son incorrectas A. Encrypting passwords securely. (Cifrar contraseñas de forma segura). Esto es peligroso e incorrecto. FARM_FINGERPRINT es una función de hash no criptográfica. Está diseñada para ser rápida, no segura. Nunca debe usarse para contraseñas o datos sensibles, ya que no ofrece las protecciones necesarias contra ataques. C. Compressing the dataset. (Comprimir el conjunto de datos). Esto es incorrecto. La compresión es una tecnología de almacenamiento que BigQuery aplica automáticamente en segundo plano para ahorrar espacio. FARM_FINGERPRINT es una función que realiza un cálculo sobre los datos, no una técnica de compresión. Son conceptos completamente distintos. D. Preventing unauthorized access. (Prevenir el acceso no autorizado). Esto es incorrecto. El acceso a los datos en BigQuery se controla mediante IAM (Identity and Access Management), donde se asignan roles y permisos. Aplicar una función a una columna no cambia quién tiene permiso para verla

Answer 554

A When an Editor creates a dataset, BigQuery grants that user the bigquery.dataOwner role for the new dataset.

Answer 555

B Authorized views combined with SESSION_USER() allow you to filter data at the row level, so only certain users can see specific rows based on their identity

Answer 556

C The jobUser is the lowest predefined BigQuery role and is primarily allowed to start jobs in the project

Answer 557

B y C Regular audits and separating environments are recommended best practices. Assigning all users Owner rights and sharing datasets publicly are not recommended

Answer 558

B Por qué la B es la respuesta correcta Esta respuesta tiene dos partes, y ambas son propósitos clave de FARM_FINGERPRINT: "Crear nuevas columnas de clave primaria": FARM_FINGERPRINT toma una entrada (como un email, un ID de usuario en formato texto, o una combinación de varias columnas) y la convierte en un número único de 64 bits (INT64). Este número es un "fingerprint" (huella digital) determinista, lo que significa que la misma entrada siempre producirá el mismo número de salida. Esto es perfecto para crear una clave sustituta (surrogate key). Es mucho más eficiente y rápido para BigQuery realizar un JOIN (unir tablas) usando un número (INT64) que usando una cadena de texto larga (STRING). "Distribuir los datos uniformemente": Esta es la razón más importante en un sistema distribuido como BigQuery. FARM_FINGERPRINT es una función de hash no criptográfica. Su diseño se centra en ser muy rápida y en distribuir las salidas de manera pseudoaleatoria y uniforme. Cuando usas CLUSTER BY (clusterizar) en BigQuery sobre una columna con hash, te aseguras de que los datos se repartan por igual entre los diferentes bloques de almacenamiento. Esto evita "puntos calientes" (hotspots), donde una sola partición o un solo nodo tiene que procesar una cantidad desproporcionada de datos, lo que mejora drásticamente el rendimiento de las consultas. Por qué las otras respuestas son incorrectas A) Para almacenar contraseñas de usuario de forma segura: Incorrecto. Esta es una práctica de seguridad muy peligrosa. FARM_FINGERPRINT es un hash no criptográfico diseñado para ser rápido. Para almacenar contraseñas de forma segura, necesitas un hash criptográfico y lento (como Argon2, scrypt, o como mínimo bcrypt), que sea resistente a ataques de fuerza bruta. Usar FARM_FINGERPRINT para esto sería un grave error de seguridad. C) Para encriptar todos los datos de una tabla: Incorrecto. El hashing no es encriptación. Son conceptos diferentes. La encriptación es un proceso de dos vías: puedes encriptar un dato con una clave y luego desencriptarlo con la clave para obtener el original. El hashing (como FARM_FINGERPRINT) es un proceso de una sola vía: conviertes un dato en un hash, pero no puedes "des-hashear" el resultado para recuperar el dato original. D) Para comprimir datos y mejorar la eficiencia de almacenamiento: Incorrecto. El propósito principal no es la compresión de datos. La compresión (como Gzip o Snappy) tiene como objetivo reducir el tamaño total de los datos para ahorrar espacio. Aunque el resultado de FARM_FINGERPRINT (un número de 8 bytes) puede ser más pequeño que un texto largo, también es más grande que, por ejemplo, un número de 4 bytes. Su objetivo no es ahorrar espacio, sino crear identificadores únicos y distribuirlos bien, como se describe en la opción B.

Answer 559

B The Editor role at the project level allows users to create new datasets and perform all actions associated with the dataEditor role within BigQuery

Answer 560

C Por qué la opción C es la correcta C. Create an authorized view that joins the table with a manager-employee mapping and filters the results using WHERE manager_email = SESSION_USER(). Este es el método canónico y más seguro para implementar la seguridad a nivel de fila (Row-Level Security) en BigQuery. Funciona así: Creas una VISTA (VIEW): Creas una vista sobre la tabla employee_salaries. Añades Lógica de Filtrado: En la definición de la vista, añades una cláusula WHERE manager_email = SESSION_USER(). La función SESSION_USER() es una función especial de BigQuery que devuelve la dirección de correo electrónico del usuario que está ejecutando la consulta. Autorizas la VISTA: Este es el paso clave. Haces que la vista sea una vista autorizada. Esto significa que: Das permiso a los mánagers para consultar solo la vista, no la tabla original. Das permiso a la vista misma para que acceda a la tabla original. Resultado: Cuando un mánager (ej. manager.boss@company.com) hace un SELECT * FROM tu_vista, BigQuery ejecuta la consulta de la vista como SELECT * FROM employee_salaries WHERE manager_email = 'manager.boss@company.com'. El mánager solo ve sus filas, no puede evitar el filtro y no tiene acceso a la tabla completa de salarios. Es la solución más efectiva y segura. Por qué las otras opciones son incorrectas A. Create a separate table for each manager containing only the data for their direct reports. Incorrecto porque: Esto es un infierno de mantenimiento. Si tienes 1000 mánagers, necesitas 1000 tablas. Si un empleado cambia de mánager, tienes que actualizar varias tablas. Es ineficiente y no escala en absoluto. B. Grant each manager the bigquery.dataViewer role and instruct them to use a WHERE clause in their own queries. Incorrecto porque: Esta es la opción más insegura. El rol bigquery.dataViewer les da permiso para ver toda la tabla. Si un mánager se olvida, o decide maliciosamente no usar, la cláusula WHERE, podrá ver el salario de todos los empleados. La seguridad que depende de que el usuario "siga instrucciones" no es seguridad. D. Use the FARM_FINGERPRINT() function to hash the employee_email column, giving managers access only to the hashes they are authorized to see. Incorrecto porque: Esto no resuelve el problema. La función FARM_FINGERPRINT() se usa para anonimizar o hashear datos. No oculta las filas de salarios; solo haría que la columna de email fuera ilegible. El mánager seguiría viendo los salarios de todos, pero con un email hasheado al lado. Es la herramienta equivocada para el trabajo. Esto es para enmascarar datos, no para filtrar filas.

Answer 561

B Slide 6 explicitly states the inherited permissions. For a user with the basic IAM "Viewer" role, "If you create a dataset in a project that contains any viewers, BigQuery grants those users the bigquery.dataViewer predefined role for the new dataset."

Answer 562

C y D Slide 7, "Avoid access pitfalls," lists several best practices. These include using separate projects or datasets for different environments to prevent accidental data loss in production, and auditing roles periodically to ensure users only have the minimum permissions necessary for their jobs (principle of least privilege). Granting admin roles widely and consolidating all environments are explicitly against these best practices.

Answer 563

C The table on Slide 5 shows the permissions for each role. Both dataViewer and dataEditor can list tables and get table data/metadata. However, only the dataEditor (and higher roles) has the checkmark (✓) for "Modify/delete tables". Creating new datasets is a dataOwner privilege, and creating jobs/queries is a user privilege. ✅ Explicación de la Respuesta Correcta La pregunta se centra en la diferencia fundamental entre un rol que solo puede "ver" y un rol que puede "editar". bigquery.dataViewer (Visor de datos 👁️): Este rol está diseñado para el acceso de solo lectura. Un usuario con este rol puede consultar datos (SELECT), ver metadatos y listar tablas, pero no puede realizar ningún cambio. bigquery.dataEditor (Editor de datos ✏️): Este rol incluye todos los permisos del visor, pero añade la capacidad de modificar datos y tablas. C. Modify table data and schema (Modificar datos y esquemas de tablas) es la acción que distingue a ambos. Un dataEditor puede ejecutar sentencias como INSERT, UPDATE, DELETE y ALTER TABLE para cambiar tanto el contenido como la estructura de una tabla. Un dataViewer no puede hacer nada de esto. ❌ Por qué las otras opciones son incorrectas A. Create new datasets (Crear nuevos conjuntos de datos): La creación de conjuntos de datos es una acción de nivel superior. Ni el rol dataViewer ni el dataEditor incluyen el permiso bigquery.datasets.create. Esta capacidad generalmente la tiene un rol como bigquery.user o bigquery.admin. B. Create or cancel jobs/queries (Crear o cancelar trabajos/consultas): Ambos roles pueden y deben hacer esto. Un dataViewer necesita crear un trabajo (una consulta SELECT) para poder ver los datos. Un dataEditor también necesita crear trabajos para leer y escribir datos (SELECT, INSERT, etc.). Como ambos roles pueden realizar esta acción, no es una diferencia entre ellos. D. List tables in a dataset (Listar tablas en un conjunto de datos): Esta es una acción de lectura básica. Tanto un dataViewer como un dataEditor necesitan poder ver la lista de tablas disponibles en un conjunto de datos para poder trabajar. Por lo tanto, ambos roles tienen este permiso.

Answer 564

C Claro, aquí va la explicación para esta pregunta. La respuesta correcta es la C. FARM_FINGERPRINT(). El Problema: "Hotspots" con Claves Secuenciales Primero, es clave entender el problema que se intenta resolver. Un sistema transaccional a menudo usa una clave primaria que se auto-incrementa (por ejemplo, 1, 2, 3, 4, ...). Si cargas estos datos directamente en BigQuery y los usas para particionar o clusterizar, creas un "hotspot" (un punto caliente). Imagina una gran oficina de correos con muchos mostradores. Si todas las personas nuevas que llegan fueran obligadas a hacer fila solo en el mostrador nº1, se formaría un atasco gigante en ese punto mientras los demás mostradores están vacíos. Esto es lo que pasa en BigQuery: todos los datos nuevos (con IDs 1001, 1002, 1003...) se escriben en el mismo lugar de almacenamiento (el mismo shard o bloque), sobrecargándolo y ralentizando el rendimiento de la escritura. Para optimizar, necesitas "repartir" a la gente de manera uniforme entre todos los mostradores. La solución es crear una nueva columna de clave que transforme los números secuenciales en valores que parezcan aleatorios y estén bien distribuidos. ✅ Por qué la opción (c) es la correcta C. FARM_FINGERPRINT() Esta es la función recomendada por Google para este propósito específico. Es una función de hashing no criptográfica. ¿Qué hace?: Convierte cualquier entrada (como tu ID numérico o de texto) en un número de 64 bits (INTEGER). ¿Por qué es ideal?: Distribución excelente: Entradas secuenciales como 1, 2, 3 producen salidas completamente diferentes y no secuenciales, lo que reparte los datos de manera uniforme por todo el almacenamiento, eliminando los hotspots. Extremadamente rápida: Al no ser criptográfica, está optimizada para la velocidad, lo cual es vital al procesar grandes volúmenes de datos. Determinista: Siempre produce el mismo resultado para la misma entrada. FARM_FINGERPRINT('hola') siempre devolverá el mismo número, lo cual es necesario para poder buscar los datos de forma consistente. Es la herramienta perfecta para el trabajo: rápida, distribuye bien los datos y es la práctica recomendada oficialmente. ❌ Por qué las otras opciones son incorrectas A. SESSION_USER() Esta función devuelve el email del usuario que está ejecutando la consulta. No tiene ninguna relación con los datos de la fila. Todas las filas insertadas en la misma sesión tendrían el mismo valor, lo que no sirve para crear una clave única y distribuida. B. SHA512() SHA512 es una función de hashing criptográfica. Técnicamente, también distribuiría los datos de manera uniforme. Sin embargo, las funciones criptográficas están diseñadas para ser seguras y, como consecuencia, son computacionalmente mucho más lentas que las no criptográficas como FARM_FINGERPRINT. Usar SHA512 sería como usar un camión blindado para repartir el correo: es excesivo, caro e innecesariamente lento para una tarea que no requiere seguridad. D. AEAD.ENCRYPT() Esta función es para cifrar datos, es decir, para la seguridad y la confidencialidad. Su propósito es ocultar información, no distribuirla para mejorar el rendimiento. Es un proceso lento y completamente inadecuado para generar una clave de sharding.

Answer 565

B La Respuesta Correcta: Opción B To create primary key columns for better sharding performance (Crear columnas de clave principal para un mejor rendimiento de fragmentación/sharding). ¿Qué hace FARM_FINGERPRINT()? Toma un valor de entrada (generalmente un STRING, como un email o un ID de producto) y lo convierte en un número entero (INT64) aparentemente aleatorio, pero determinista (siempre devuelve el mismo número para la misma entrada). ¿Por qué es "Buena Práctica" en BigQuery? BigQuery es un sistema distribuido. Si tus datos están ordenados secuencialmente (por ejemplo, fechas o IDs que van 1, 2, 3...), y tratas de procesarlos, puedes crear "puntos calientes" (hotspots) donde un solo servidor (worker) tiene que procesar demasiados datos mientras los otros no hacen nada. El beneficio: Al pasar tus claves por FARM_FINGERPRINT(), conviertes datos secuenciales en números distribuidos uniformemente. Esto permite que BigQuery distribuya la carga de trabajo de manera eficiente entre todos sus servidores (sharding), mejorando drásticamente la velocidad de las consultas y los JOINs. Por qué las otras son "malas" Opción A: Guardar contraseñas To securely store passwords in a dataset El problema: Seguridad. Por qué es malo: FARM_FINGERPRINT usa el algoritmo FarmHash. Es un algoritmo diseñado para ser extremadamente rápido, no seguro. Riesgo: Al ser tan rápido, es muy fácil de atacar mediante fuerza bruta (adivinar la contraseña probando millones de combinaciones por segundo). Para contraseñas se deben usar algoritmos lentos y criptográficos (como SHA-256, bcrypt, etc.). Opción C: Encriptar datos sensibles To encrypt sensitive data at the row level El problema: Confusión de términos (Hashing vs. Encriptación). Por qué es malo: Irreversible: FARM_FINGERPRINT es una función de hash. No se puede "desencriptar" para obtener el texto original. Colisiones: Aunque raro, es teóricamente posible que dos textos diferentes den el mismo número. Seguridad: Al igual que en la opción A, no es un método seguro para ocultar información sensible (PII). Opción D: Filtrar por roles To filter rows based on user roles El problema: Propósito incorrecto. Por qué es malo: Esta función devuelve un número entero (ej: -7346345345...). No tiene ninguna lógica de negocio para evaluar permisos, roles de usuario o control de acceso. Para eso se usan las "Row-Level Security policies" (Políticas de seguridad a nivel de fila) en BigQuery.

Answer 566

B El Concepto: Acceso a Nivel de Fila con Vistas Autorizadas El acceso a nivel de fila (Row-Level Security) es una técnica de seguridad que permite que diferentes usuarios vean diferentes filas de la misma tabla, según quiénes son. En BigQuery, la forma estándar de implementar esto es mediante una vista autorizada. El flujo es el siguiente: Tienes una tabla principal con todos los datos (ej: ventas_globales). Creas una tabla de mapeo que dice qué usuario puede ver qué datos (ej: mapeo_usuarios_region con columnas email y region). Creas una vista sobre la tabla principal que contiene una lógica de filtrado. Esta lógica usa una función para identificar al usuario que está ejecutando la consulta. Concedes a los usuarios acceso a la vista, pero no a la tabla principal. Por qué la opción B es la correcta B) SESSION_USER() ✅ Esta es la función específica que BigQuery proporciona para este propósito. SESSION_USER() devuelve una cadena de texto con la dirección de correo electrónico del usuario que ha iniciado sesión y está ejecutando la consulta. Al usar esta función dentro de la consulta de la vista autorizada, puedes filtrar los datos de forma dinámica. Ejemplo de la consulta de la vista: SELECT * FROM `proyecto.dataset.ventas_globales` WHERE region IN ( SELECT region FROM `proyecto.dataset.mapeo_usuarios_region` WHERE email = SESSION_USER() ) Cuando un analista de Europa (ej: analista.eu@empresa.com) consulta esta vista, SESSION_USER() devuelve su email, la subconsulta le da la región 'Europa', y la vista solo le muestra las filas de ventas de Europa. Por qué las otras opciones son incorrectas A) CURRENT_USER() ❌ Aunque CURRENT_USER() es una función común en otros sistemas de bases de datos SQL (como PostgreSQL), no es una función válida en el dialecto SQL estándar de BigQuery. C) USER_ROLE() ❌ Esta no es una función que exista en BigQuery SQL. La gestión de roles en Google Cloud se realiza a través de IAM (Identity and Access Management), no a través de funciones SQL que devuelvan el rol del usuario. D) AUTHENTICATED_USER() ❌ Al igual que las anteriores, esta no es una función reconocida por BigQuery SQL. Es un concepto de IAM, pero no una función que puedas usar en tus consultas para obtener la identidad del usuario.

Answer 567

A, B, C y D El motivo principal es la naturaleza del rol de IAM "Owner" (Propietario) en un proyecto de Google Cloud. El Principio Clave: El Rol "Owner" (Propietario) El rol roles/owner es el rol más primitivo y con más permisos en un proyecto de Google Cloud. Un usuario con este rol es, en esencia, el "superadministrador" del proyecto. Tiene todos los permisos para todos los servicios y recursos dentro del proyecto. Esto no se limita solo a BigQuery, sino a todas las APIs y servicios (Compute Engine, Cloud Storage, etc.). Puede hacer todo lo que un administrador puede hacer y más, como cambiar la facturación del proyecto o incluso eliminar el proyecto por completo. Implícitamente, el rol de Propietario incluye todos los permisos de todos los demás roles, como roles/bigquery.admin, roles/bigquery.user, roles/bigquery.dataEditor, etc. Sabiendo esto, analicemos cada opción. Análisis Detallado de las Opciones A) Can start a job in the project (Puede iniciar un trabajo en el proyecto) ¿Qué es? Iniciar un "job" (trabajo) en BigQuery significa ejecutar una consulta, cargar datos, exportar datos, etc. La capacidad de ejecutar consultas es fundamental. ¿Por qué es correcto? El permiso necesario es bigquery.jobs.create, que está incluido en el rol roles/bigquery.user. Como el rol de Propietario lo incluye todo, por supuesto que puede iniciar trabajos. Es una de las acciones más básicas. B) Can list all datasets in the project (Puede listar todos los conjuntos de datos en el proyecto) ¿Qué es? Es la capacidad de ver la lista de todos los conjuntos de datos (datasets) que existen en el proyecto. ¿Por qué es correcto? El permiso necesario es bigquery.datasets.list, que forma parte de roles como roles/bigquery.dataViewer. Dado que un Propietario tiene control total sobre el proyecto, tiene visibilidad completa de todos sus recursos. C) Can delete any dataset in the project (Puede eliminar cualquier conjunto de datos en el proyecto) ¿Qué es? Es una acción administrativa destructiva que elimina permanentemente un conjunto de datos y todas las tablas que contiene. ¿Por qué es correcto? El permiso requerido es bigquery.datasets.delete, que se encuentra en el rol roles/bigquery.admin. El Propietario del proyecto tiene, por definición, plenos poderes administrativos y puede crear, modificar y eliminar cualquier recurso, incluidos los conjuntos de datos de BigQuery. D) Can create authorized views for row-level access (Puede crear vistas autorizadas para el acceso a nivel de fila) ¿Qué es? Una vista autorizada es una técnica de seguridad avanzada. Permite que un usuario consulte una vista sin tener acceso a las tablas subyacentes. Para crearla, necesitas permisos para crear la vista y para modificar la configuración de acceso del conjunto de datos. ¿Por qué es correcto? Esto requiere permisos administrativos, como bigquery.tables.create (para crear la vista) y bigquery.datasets.update (para autorizarla). Un Propietario tiene todos estos permisos y más, por lo que puede configurar cualquier mecanismo de seguridad dentro de BigQuery.

Answer 568

C The document emphasizes periodically auditing roles and access credentials to ensure users have the minimum permissions needed, as part of avoiding access pitfalls. Option A is incorrect as it violates the principle of least privilege. Option B is discouraged, as the document recommends separate projects or datasets for different environments (DEV, QA, PRD). Option D is incorrect, as authorized views are recommended for row-level access control.

Answer 569

A, y C Respuestas Correctas ✅ A) Assign the minimum permissions needed for each user group (Asignar los permisos mínimos necesarios para cada grupo de usuarios) Esta es la aplicación del Principio de Mínimo Privilegio, una regla de oro en seguridad informática. Consiste en dar a los usuarios y grupos únicamente los permisos que son estrictamente necesarios para realizar su trabajo, y nada más. ¿Por qué es una estrategia recomendada? Reduce drásticamente el riesgo de acceso no autorizado, modificaciones accidentales o filtraciones de datos. Si una cuenta se ve comprometida, el daño potencial es mucho menor. C) Create authorized views for row-level access control (Crear vistas autorizadas para el control de acceso a nivel de fila) Una vista autorizada es una de las herramientas más potentes y recomendadas en BigQuery para implementar seguridad detallada. Permite compartir los resultados de una consulta con usuarios específicos sin darles acceso a las tablas de origen subyacentes. ¿Por qué es una estrategia recomendada? Puedes escribir una consulta en la vista que filtre las filas basándose en la identidad del usuario que la consulta (por ejemplo, WHERE email_empleado = SESSION_USER()). De esta forma, cada persona solo ve las filas que le corresponden, implementando un control de acceso a nivel de fila de manera segura y eficiente, sin necesidad de duplicar los datos. Respuestas Incorrectas ❌ B) Use a single project for all environments to reduce costs (Usar un único proyecto para todos los entornos para reducir costes) Esta es una muy mala práctica de seguridad y gestión. Mezclar entornos de desarrollo, pruebas y producción en un solo proyecto crea un riesgo de seguridad enorme. Los desarrolladores podrían acceder o modificar datos de producción por error. La estrategia recomendada es aislar cada entorno en su propio proyecto de Google Cloud. D) Mirror data into siloed environments with differing permissions (Duplicar datos en entornos aislados con diferentes permisos) Esta estrategia consiste en copiar los datos en diferentes datasets o proyectos y aplicar permisos distintos en cada copia. Aunque puede funcionar, es una solución ineficiente y no recomendada. ¿Por qué no se recomienda? Costes elevados: Duplicar los datos significa pagar el doble (o más) por el almacenamiento. Datos desactualizados: Es muy fácil que las copias se desincronicen con la fuente original, llevando a análisis incorrectos. Complejidad: Requiere mantener pipelines de datos adicionales solo para la sincronización. Las vistas autorizadas (Opción C) resuelven este problema de una manera mucho más limpia y económica.

Answer 570

C The source states that hand-coded rules become "unwieldy" and "hard to maintain," while ML "scales much better because it requires no hardcoded rules and it’s all automated". It also emphasizes that "Machine Learning = Examples, not rules"

Answer 571

B y C ✅ Respuestas Correctas B) A "label" is the correct answer that the model is trying to predict, derived from historical data. Esta es la definición exacta. La etiqueta (label) es la columna que contiene la "respuesta" que queremos que el modelo aprenda. En nuestro ejemplo, la columna precio sería la etiqueta. Es el objetivo a predecir. 🏷️ C) "Features" are the other columns of data used by the model to learn the relationship with the label. Correcto. Las características (features) son todas las columnas de entrada que el modelo utiliza para encontrar patrones y así poder predecir la etiqueta. En nuestro ejemplo, metros_cuadrados, num_habitaciones y año_construccion serían las características. ❌ Respuestas Incorrectas A) An "instance" (or observation) refers to a single column of data in a dataset. Esto es incorrecto. Una instancia (u observación) no es una columna, sino una fila completa de datos. Representa un único ejemplo en nuestro conjunto de datos (por ejemplo, toda la información de una casa en particular). Una columna sería una característica. D) "Training" involves predicting on unknown labels using a trained model. Esto describe el proceso de predicción (o inferencia), no el de entrenamiento. Entrenamiento (Training): Es el proceso de enseñar al modelo usando datos donde ya conocemos la etiqueta (las respuestas). Predicción (Prediction): Es el proceso de usar el modelo ya entrenado para adivinar las etiquetas de datos nuevos que no ha visto antes.

Answer 572

C En este escenario, estamos ante un problema de predicción categórica (sí/no), lo cual en el mundo del Machine Learning se conoce como Clasificación Binaria. La respuesta correcta es la C) Logistic Regression (Classification). Aquí te explico por qué es la herramienta ideal y por qué las otras no encajan con este objetivo: ✅ La respuesta correcta: C Logistic Regression (Clasificación Logística) Por qué es la mejor: A pesar de que lleva la palabra "regresión" en su nombre, la regresión logística se utiliza para calcular la probabilidad de que algo pertenezca a una categoría u otra. Resultado esperado: En tu caso, el modelo devolverá una probabilidad entre 0 y 1. Si la probabilidad es mayor a 0.5, el modelo predice que el usuario comprará; si es menor, que no comprará. Caso de uso: Es el estándar para problemas de "SÍ o NO", como detectar spam, diagnosticar una enfermedad o, en este caso, predecir una conversión de venta. ❌ Las respuestas incorrectas A) Linear Regression (Regresión Lineal) Por qué es mala: La regresión lineal se usa para predecir números continuos, no categorías. Ejemplo: Se usaría para predecir cuánto dinero va a gastar un cliente (ej. $15.50), pero no sirve para decidir entre "comprar" o "no comprar". Si intentas usarla para esto, podrías obtener resultados absurdos como "2.5" en una escala de sí/no. B) Matrix Factorization (Factorización de Matrices) Por qué es mala: Este modelo es el que se usa específicamente para Sistemas de Recomendación. Ejemplo: Es lo que usa Netflix para sugerirte películas basándose en lo que otros usuarios similares han visto. No te dice si vas a comprar o no, sino qué producto es más probable que te guste. D) Clustering (Agrupamiento / K-means) Por qué es mala: El clustering es una técnica de aprendizaje no supervisado. Se usa para encontrar grupos naturales en los datos cuando no sabemos qué estamos buscando. Ejemplo: Serviría para agrupar a tus clientes en "compradores impulsivos", "buscadores de ofertas" y "clientes VIP", pero no puede predecir una acción específica (como la compra) porque el modelo no sabe de antemano qué significa "comprar".

Answer 573

A, B y D BigQuery ML (BQML) está diseñado para democratizar el machine learning, permitiendo a los analistas de datos y desarrolladores construir modelos directamente dentro del data warehouse usando SQL. Ventajas y Características Correctas A) It significantly reduces the time typically spent on data export, transformation, and local model training. (Reduce significativamente el tiempo que se suele dedicar a la exportación de datos, la transformación y el entrenamiento de modelos locales). Correcto. ✅ Esta es una de sus mayores ventajas. En lugar de seguir el proceso tradicional de exportar datos desde BigQuery a otra plataforma (como notebooks de Python) para entrenar un modelo, BQML permite entrenar el modelo directamente sobre los datos sin moverlos. Esto elimina pasos complejos y lentos. B) It automatically handles hyperparameters like learning rate and data splitting (training/test sets). (Maneja automáticamente hiperparámetros como la tasa de aprendizaje y la división de datos (conjuntos de entrenamiento/prueba)). Correcto. ✅ BQML automatiza gran parte del trabajo tedioso. Por defecto, divide automáticamente los datos para entrenamiento y evaluación, y para muchos tipos de modelos, también realiza un ajuste automático de hiperparámetros clave. Esto simplifica enormemente el proceso de creación de modelos. D) It allows users to experiment and iterate on models directly where their data lives within BigQuery using SQL. (Permite a los usuarios experimentar e iterar con modelos directamente donde viven sus datos dentro de BigQuery usando SQL). Correcto. ✅ Todo el ciclo de vida del modelo, desde la creación (CREATE MODEL) hasta la evaluación (ML.EVALUATE) y la predicción (ML.PREDICT), se gestiona con comandos SQL. Esto permite a los usuarios con conocimientos de SQL ser productivos en machine learning sin necesidad de aprender nuevos lenguajes o herramientas. Por qué la Otra Respuesta es Incorrecta C) It requires advanced machine learning expertise to be used effectively, making it suitable only for data scientists. (Requiere una gran experiencia en machine learning para ser utilizado eficazmente, por lo que es adecuado solo para científicos de datos). Incorrecto. ❌ Esta afirmación es exactamente lo contrario del objetivo de BigQuery ML. Está diseñado específicamente para que los analistas de datos, que ya conocen SQL, puedan construir modelos de ML sin necesidad de ser expertos en frameworks como TensorFlow o PyTorch. Su propósito es hacer el ML más accesible, no más exclusivo.

Answer 574

B The "four major steps" for working with BigQuery ML are listed as: "01 Dataset", "02 Create/train", "03 Evaluate", and "04 Predict/classify". To obtain predictions from a trained model, the ML.PREDICT() function is used

Answer 575

C In ML terminology, the label is the value you want to predict. It's typically a known output from historical data used during training.

Answer 576

B This is a binary classification problem (buy/no buy), which is best handled using logistic regression. La regresión logística es el modelo ideal para este problema porque es un algoritmo de clasificación. Su objetivo es predecir la probabilidad de que un evento ocurra o no, lo cual se representa como un resultado binario (0 o 1, sí o no, verdadero o falso). En este caso, la pregunta es: "¿volverá un visitante a realizar una compra?". La respuesta es un "sí" o un "no". La regresión logística analizará las características del visitante (como páginas vistas, tiempo en el sitio, etc.) y calculará la probabilidad (un valor entre 0 y 1) de que la respuesta sea "sí". ❌ Respuestas Incorrectas A. Regresión Lineal (Linear Regression) La regresión lineal se utiliza para predecir un valor numérico continuo, no una categoría. Por ejemplo, la usarías para predecir el importe de la compra o el número de días hasta que un cliente regrese. No sirve para predecir una respuesta de "sí/no". C. Factorización de Matrices (Matrix Factorization) La factorización de matrices es un modelo que se usa principalmente en sistemas de recomendación. Su función es predecir la calificación que un usuario le daría a un artículo (por ejemplo, recomendarte películas en Netflix). No está diseñado para clasificar si un usuario realizará una acción o no. D. Clustering (Agrupamiento) El clustering es un tipo de aprendizaje no supervisado que se usa para agrupar datos similares. Por ejemplo, podrías usarlo para crear grupos o "clusters" de visitantes con comportamientos parecidos (ej: "compradores frecuentes", "visitantes de una sola vez"). Sin embargo, el clustering describe los datos que tienes, pero no predice un resultado futuro para un nuevo visitante.

Answer 577

C Features are input variables used by the model to learn and predict the label. Examples include page views, session duration, etc.

Answer 578

B y C El Concepto Clave: ¿Qué es BigQuery ML? BigQuery ML (BQML) es una funcionalidad dentro de BigQuery que permite a los usuarios crear y ejecutar modelos de machine learning (aprendizaje automático) utilizando comandos SQL estándar. La idea principal es "llevar el ML a los datos", permitiendo que los analistas de datos, que ya saben SQL, puedan construir modelos sin tener que mover los datos ni aprender lenguajes complejos como Python o frameworks como TensorFlow. Las Respuestas Correctas B) Puedes usar SQL para entrenar y evaluar modelos Por qué es correcta: Esta es la característica fundamental y la principal propuesta de valor de BigQuery ML. En lugar de exportar datos a otra plataforma, escribes comandos SQL como CREATE MODEL para entrenar un modelo y usas funciones SQL como ML.EVALUATE (para evaluar su rendimiento) o ML.PREDICT (para hacer predicciones). C) Divide automáticamente los datos en conjuntos de entrenamiento y prueba (testing) Por qué es correcta: Cuando ejecutas un comando CREATE MODEL, BQML por defecto realiza automáticamente una división de los datos (un split). Utiliza una porción para entrenar el modelo (datos de entrenamiento) y reserva otra porción (datos de prueba o evaluación) para comprobar qué tan bien funciona el modelo con datos que no ha visto antes. Esto es una práctica estándar en machine learning para evitar el sobreajuste (overfitting) y BQML lo maneja por ti. Las Respuestas Incorrectas A) Debes escribir código de TensorFlow para usarlo Por qué es incorrecta: Esta afirmación es diametralmente opuesta al propósito de BQML. El objetivo de BQML es evitar que tengas que escribir código en TensorFlow o Python para tareas comunes de ML. Si bien BQML te permite importar modelos de TensorFlow ya entrenados, no es en absoluto un requisito para usarlo; la mayoría de los modelos se crean de forma nativa con SQL. D) Admite redes neuronales profundas como su único tipo de modelo Por qué es incorrecta: La palabra clave que hace que esto sea falso es "único". BQML admite una gran variedad de tipos de modelos, no solo Redes Neuronales Profundas (DNN). Algunos ejemplos incluyen: Regresión Lineal (para predecir números, ej: ventas). Regresión Logística (para clasificación, ej: ¿es spam o no?). Árboles de decisión (Boosted Trees / XGBoost). K-Means (para clustering o segmentación de clientes). ARIMA (para pronóstico de series temporales). Y muchos más.

Answer 579

B In supervised ML, the model learns from labeled data (examples with known outcomes), unlike unsupervised or reinforcement learning.

Answer 580

C ML models scale better than traditional rule-based systems because they automate the decision-making process and do not require maintaining large numbers of hardcoded rules, making them easier to manage and adapt as data changes.

Answer 581

C The label is the value you want the model to predict, typically coming from historical data. It can be a number (for regression) or a class (for classification)

Answer 582

B Este es un problema clásico de clasificación binaria, y la regresión logística es el modelo ideal para resolverlo. ✅ Respuesta Correcta B) Regresión logística El objetivo es predecir un resultado que solo tiene dos opciones posibles: "el usuario comprará" o "el usuario no comprará". ¿Qué es un problema de clasificación? Es cuando intentas predecir a qué categoría pertenece algo. Como solo hay dos categorías, es una clasificación binaria. ¿Por qué Regresión Logística? Este modelo está diseñado específicamente para predecir la probabilidad de que un evento ocurra. El resultado que te da es un número entre 0 y 1 (por ejemplo, 0.8), que puedes interpretar como una probabilidad (en este caso, un 80% de probabilidad de que el usuario compre). En resumen, cuando la pregunta es "¿Sí o No?", la regresión logística es la herramienta estadística fundamental para responderla. ❌ Respuestas Incorrectas A) Regresión lineal ¿Para qué se usa? Para predecir un número continuo. Por ejemplo, para predecir cuánto dinero gastará un usuario o el precio de una casa. No sirve para predecir una categoría. C) Clustering ¿Para qué se usa? Para agrupar datos similares sin saber de antemano las categorías. Por ejemplo, para identificar diferentes segmentos de clientes (grandes compradores, visitantes ocasionales, etc.). Es una técnica de descubrimiento, no de predicción de un resultado conocido. D) Factorización de matrices ¿Para qué se usa? Principalmente para sistemas de recomendación. Por ejemplo, para predecir qué calificación le daría un usuario a una película que no ha visto y así poder recomendársela. No es el modelo adecuado para una simple predicción de "sí/no".

Answer 583

A, B y D ¿Por qué A, B y D son las correctas?Para entender esto, hay que tener clara la diferencia fundamental en Machine Learning entre Feature (Característica) y Label (Etiqueta).Feature ($X$): Son las variables de entrada. Son los datos que ya conoces y que utilizas para alimentar el modelo. Describen las propiedades, comportamientos o atributos de la entidad que estás analizando (en este caso, un visitante).Label ($y$): Es la variable de salida. Es lo que el modelo intenta predecir.Analicemos las opciones A, B y D:Todas ellas describen comportamientos pasados o atributos del usuario que ya han sucedido y que podemos medir hoy.(A) Días de visita: Nos dice cuán frecuente es el usuario.(B) Ingresos totales: Nos dice cuánto gasta el usuario (poder adquisitivo).(D) Tiempo en sitio: Nos dice cuán interesado está el usuario.Si tú quisieras predecir, por ejemplo, "¿Comprará este usuario una suscripción Premium el próximo mes?", utilizarías A, B y D como pistas (features) para llegar a esa conclusión.¿Por qué la C es la "mala"?C) The value you are trying to predict (label)❌ Incorrecta.Explicación: Esta opción es la definición literal de lo opuesto a una feature.En Machine Learning supervisado, dividimos los datos en dos: las preguntas (Features) y la respuesta correcta (Label).No puedes usar la respuesta como una característica de entrada para predecirse a sí misma (eso se llama "data leakage" o fuga de datos, y es un error grave).

Answer 584

A, B , C y D The end-to-end process in BigQuery ML involves extracting training data, creating and training the model, evaluating its performance, and then using it to make predictions

Answer 585

C The goal is to predict a continuous numerical value (total revenue), which is a forecasting or regression problem. According to the decision tree on slide 29, when you want to "forecast a number (e.g., future sales)," the recommended model type is Linear Regression. Logistic Regression is used for classification (e.g., buy/no-buy).

Answer 586

D As defined on slide 22, features are the input columns of data that the model uses to learn from in order to predict the label. The label is the correct answer or the value you are trying to predict (in this case, is_high_value_customer). An instance is a single row of data.

Answer 587

B According to the workflow on slide 37 and the cheatsheet on slide 41, ML.EVALUATE() is the function used to evaluate a model's performance by comparing its predictions to the actual labels in a dataset. ML.PREDICT() is used to generate predictions on new data where the label is unknown.

Answer 588

B Slide 12 explicitly states that the codebase for hand-coded rules was "getting unwieldy" and "hard to maintain." Machine learning was introduced because it scales much better by learning from examples rather than relying on a massive, ever-growing set of manually coded rules. El problema principal de los sistemas antiguos basados en reglas (como SI ocurre esto, ENTONCES haz aquello) era la escala. El ejemplo de la búsqueda "giants" (gigantes) es perfecto para ilustrarlo. Para que la búsqueda fuera útil, los ingenieros tendrían que escribir reglas a mano para cada posible significado de "giants": SI el usuario está en San Francisco Y es temporada de béisbol, ENTONCES muestra el equipo de béisbol "San Francisco Giants". ⚾ SI el usuario está en Nueva York Y es temporada de fútbol americano, ENTONCES muestra el equipo "New York Giants". 🏈 SI la búsqueda también incluye la palabra "cuentos de hadas", ENTONCES muestra información sobre criaturas míticas. 👹 SI la búsqueda es "imágenes de giants", ¿cuál muestras? Ahora, imagina tener que hacer esto para millones de búsquedas ambiguas en cientos de idiomas. La cantidad de reglas se vuelve astronómica, contradictoria y, en definitiva, imposible de mantener. Los modelos de Machine Learning como RankBrain resolvieron esto al aprender patrones y contexto a partir de los datos, en lugar de depender de reglas explícitas codificadas a mano. Por qué las otras opciones son incorrectas A. Rule-based systems could not process queries from different geographic locations. (Los sistemas basados en reglas no podían procesar consultas de diferentes ubicaciones geográficas). Esto es incorrecto. De hecho, manejar la geografía era una de las cosas más sencillas de hacer con reglas (SI usuario está en X...). C. The old systems required unstructured data, which was difficult to acquire. (Los sistemas antiguos requerían datos no estructurados, que eran difíciles de adquirir). Esto es al revés. Los sistemas de reglas funcionaban mejor con datos estructurados. El Machine Learning es la tecnología que brilla al procesar los matices del lenguaje humano no estructurado. D. The IF-THEN logic was too slow to return results for users. (La lógica SI-ENTONCES era demasiado lenta para devolver resultados a los usuarios). Esto es incorrecto. La lógica SI-ENTONCES es computacionalmente muy rápida. El problema no era la velocidad, sino la incapacidad de crear un conjunto de reglas lo suficientemente bueno y completo para cubrir la inmensa complejidad del lenguaje y la intención del usuario.

Answer 589

A ✅ Respuesta Correcta: A A. Selecciona automáticamente el mejor tipo de modelo (p. ej., regresión lineal vs. logística) basándose en el tipo de datos de la etiqueta. Esta es la característica más destacada y útil de BigQuery ML para un usuario principiante. Cuando ejecutas una sentencia CREATE MODEL simple, BQML inspecciona la columna que has designado como LABEL (la etiqueta o el valor que quieres predecir) y elige el modelo por ti: Si la etiqueta es numérica (un número entero o decimal, como un precio o una temperatura), BQML asume que quieres hacer una predicción numérica y elige automáticamente un modelo de regresión lineal (LINEAR_REG). Si la etiqueta es binaria (contiene solo dos valores distintos, como true/false, 0/1, o 'compró'/'no compró'), BQML entiende que es un problema de clasificación y elige un modelo de regresión logística (LOGISTIC_REG). Es como un asistente que mira tu objetivo y elige la herramienta más lógica para empezar, sin que tengas que especificarla. ❌ Respuestas Incorrectas: B, C y D B. Ajusta automáticamente la tasa de aprendizaje del modelo y divide los datos en conjuntos de entrenamiento y prueba. Aunque BigQuery ML sí divide los datos automáticamente en un conjunto de entrenamiento y otro de evaluación (esto es cierto), la parte de "ajustar" (tunes) la tasa de aprendizaje es imprecisa. BQML utiliza un valor predeterminado o una estrategia por defecto para la tasa de aprendizaje, pero no realiza un "ajuste de hiperparámetros" (probar múltiples valores para encontrar el óptimo) a menos que se lo pidas con opciones avanzadas. Por lo tanto, la afirmación es engañosa. C. Realiza automáticamente regularización L1/L2 para prevenir el sobreajuste (overfitting). Esto también es cierto. Por defecto, BQML aplica regularización L2 para mejorar la calidad del modelo. Sin embargo, la selección del tipo de modelo (respuesta A) es una decisión mucho más fundamental y de más alto nivel que BQML toma por ti. La regularización es un paso técnico que ocurre después de haber elegido el tipo de modelo. Por tanto, la opción A describe mejor la principal tarea automática que beneficia a un nuevo usuario. D. Exporta automáticamente los datos a un entorno de TensorFlow para el entrenamiento distribuido. Esta opción es fundamentalmente incorrecta. De hecho, describe lo contrario del propósito de BigQuery ML. La gran ventaja de BQML es precisamente que evita tener que exportar datos. El entrenamiento del modelo se realiza directamente dentro de BigQuery, utilizando su infraestructura y sin necesidad de gestionar entornos externos como TensorFlow.

Answer 590

B Los datos estructurados son la base de la mayoría de las aplicaciones empresariales y de análisis de datos. Piensa en ellos como cualquier dato que se puede organizar nítidamente en una tabla con filas y columnas, como una hoja de cálculo o una base de datos. ¿Por qué son los más comunes para ML en Google? Fundamento empresarial: La gran mayoría de los datos que generan las empresas son estructurados: registros de ventas, logs de actividad de usuarios, datos financieros, métricas de rendimiento, etc. Herramientas optimizadas: La herramienta principal de Google para el análisis de datos a gran escala es BigQuery, que está diseñada específicamente para manejar datos estructurados. Además, con BigQuery ML, los usuarios pueden crear y ejecutar modelos de machine learning directamente sobre estos datos usando comandos SQL sencillos, lo que lo hace extremadamente accesible y popular. Versatilidad: Este tipo de datos se usa para las tareas de ML más comunes y extendidas: Clasificación: (p. ej., ¿este cliente cancelará su suscripción?). Regresión: (p. ej., ¿cuál será el precio de esta casa?). Pronósticos: (p. ej., predecir las ventas del próximo trimestre). Las Respuestas Incorrectas A) Unstructured data like images and text (Datos no estructurados) ❌ Aunque Google es mundialmente conocido por su trabajo con datos no estructurados (en el Buscador de Google, Google Fotos, YouTube, y ahora con la IA Generativa), los datos estructurados son más omnipresentes en el conjunto de operaciones y análisis de negocio del día a día. El entrenamiento de modelos sobre imágenes o texto a menudo requiere conocimientos y recursos más especializados que los necesarios para trabajar con tablas de datos. C) Time-series data (Datos de series temporales) ❌ Los datos de series temporales son, en realidad, un subtipo de datos estructurados. Son tablas donde una de las columnas es una marca de tiempo (timestamp) y los datos se ordenan cronológicamente. Se usan para pronósticos y detección de anomalías. Como son una categoría específica dentro de los datos estructurados, no pueden ser "más comunes" que la categoría general a la que pertenecen. D) Graph data (Datos de grafos) ❌ Los datos de grafos modelan relaciones entre entidades (p. ej., redes sociales o cómo se conectan los productos en un sistema de recomendación). Aunque son muy potentes para casos de uso específicos como el Knowledge Graph de Google, son mucho menos comunes para las tareas de machine learning de propósito general en comparación con los datos tabulares y estructurados. Su uso es considerado más de nicho.

Answer 591

C The PDF defines the "label" as the target variable, such as customer value or purchase likelihood, derived from historical data, which the model aims to predict.

Answer 592

D The PDF outlines steps like extracting training data, creating the model, evaluating it, and making predictions, but compiling the model into a binary format is not mentioned as part of the BigQuery ML process.

Answer 593

B The PDF highlights that BigQuery ML simplifies building models by allowing SQL-based creation, leveraging BigQuery’s power, making ML accessible without deep expertise, thus reducing time and complexity.

Answer 594

C The material emphasizes that deep learning neural networks learn by being shown "thousands and thousands of photos of cats," eventually figuring out the features themselves, rather than being explicitly programmed with rules like "look for whiskers, ears, fur, and eyes". This process is compared to how children learn new objects.

Answer 595

C Wootric, a customer feedback platform, is highlighted as using the Cloud Natural Language API to automate text processing and sentiment analysis of customer survey responses. The Cloud Natural Language API recognizes parts of speech called entities and sentiment

Answer 596

C When the pre-trained Vision API cannot provide the necessary granularity (like differentiating cloud types), the material suggests using Vertex AI AutoML. AutoML Vision allows users to train a custom model with their own labelled dataset of images for specific classification tasks, often with "no code" required. The Vision API is noted as not being able to be customized in the same way for specific custom requirements.

Answer 597

D Vertex AI is explicitly described as "Google Cloud’s end-to-end ML platform that helps data science teams... fast track ML model development and deployment, from feature engineering to model training to low latency inference all with enterprise class governance and monitoring". It unifies services and supports both predictive and generative AI workflows

Answer 598

C The Cloud Vision API is designed for image analysis, including optical character recognition (OCR) to detect text in images, making it the right choice here.

Answer 599

B Custom models, like those built with Vertex AI AutoML, are ideal for unique, specialized tasks not handled by pre-built models like Cloud Vision API.

Answer 600

C Cloud Storage is the recommended place for storing datasets for Vertex AI AutoML, as it provides scalable and accessible storage for large datasets needed for training.

Answer 601

C ✅ Por qué la opción C (Dialogflow) es la CORRECTA Dialogflow es la plataforma completa de Google diseñada específicamente para crear Interfaces Conversacionales (Chatbots y Voicebots). Imagina que Dialogflow es el "cerebro" del chatbot. Hace todo el trabajo pesado: Entiende la intención: Si el usuario dice "Quiero devolver mis zapatos" o "No me quedaron bien las zapatillas", Dialogflow entiende que ambas frases significan lo mismo: Intención = Devolución. Gestiona el diálogo: Sabe qué preguntar a continuación (ej: "¿Cuál es tu número de pedido?"). Soporta contexto: Recuerda de qué se estaba hablando hace un momento. Es la única opción de la lista que te da una solución "llave en mano" para mantener una conversación de ida y vuelta. ❌ Por qué las otras opciones son INCORRECTAS Aquí es donde mucha gente se confunde, porque todas estas APIs usan "Inteligencia Artificial", pero son piezas sueltas, no el robot completo. A) Cloud Vision API Qué hace: "Ve" cosas. Analiza imágenes para detectar caras, leer texto (OCR) o identificar objetos. Por qué falla: A menos que tu cliente se comunique exclusivamente enviando fotos y señas, esto no sirve para procesar lenguaje natural ni mantener una charla. B) Cloud Natural Language API Qué hace: Es un lingüista analítico. Tú le das un texto y te dice: "Esto es un sustantivo", "El sentimiento es negativo", o "Aquí se menciona a la empresa X". Por qué falla: Analiza una frase aislada, pero no tiene memoria ni gestión de conversación. Te diría que el cliente está enojado, pero no sabría qué responderle. Dialogflow usa tecnología parecida por debajo, pero la Natural Language API por sí sola es solo una herramienta de análisis, no un constructor de bots. D) Cloud Speech API (Speech-to-Text) Qué hace: Es un estenógrafo. Escucha audio y lo transcribe a texto escrito. Por qué falla: Convierte el sonido en letras, pero no entiende el significado. Si le dices "Me quiero dar de baja", la Speech API escribe "Me quiero dar de baja", pero no sabe que eso es una solicitud de cancelación ni qué hacer con ella.

Answer 602

C The Cloud Natural Language API is ideal for text analysis, including sentiment analysis, which is crucial for processing customer feedback from social media.

Answer 603

D PaaS (Platform as a Service).

Answer 604

D Structured tabular data.

Answer 605

A A model previously trained on large datasets and available for reuse.

Answer 606

B Migrate the workloads to a public cloud.

Answer 607

A TensorFlow

Answer 608

D Cloud Composer

Answer 609

A Looker Studio.

Answer 610

C Cloud Dataflow.

Answer 611

C The ability of a cloud service to serve multiple users or clients independently within a single infrastructure.

Answer 612

C Configuration and management of the operating system and applications.

Answer 613

D Private, Public and Hybrid.

Answer 614

C Run a Google Cloud Dataflow batch pipeline to import the data into BigQuery, and push errors to another dead-letter table for analysis.

Answer 615

A Improves global connectivity and network speed for cloud applications.

Answer 616

B A cloud application monitoring and diagnostics service.

Answer 617

C Vertex AI.

Answer 618

A Google Compute Engine.

Answer 619

B Cloud Pub/Sub, Cloud Storage, BigQuery

Answer 620

C El problema clave es que recibes datos en tiempo real que pueden llegar duplicados. Tienes una ID única para cada evento y una marca de tiempo (timestamp). El objetivo es consultar los datos y ver solo la versión más reciente de cada evento, eliminando los duplicados al momento de la consulta. ✅ Por qué la opción (c) es la correcta c) Usar la función de ventana ROW_NUMBER() con PARTITION BY sobre la ID única junto con WHERE row equals 1. Esta es la solución idiomática y más robusta para la deduplicación en SQL. Así es como funciona: PARTITION BY unique_id: Esta parte de la función agrupa todas las filas que tienen la misma unique_id en "particiones" o ventanas separadas. Imagina que crea un montón de cartas por cada ID. ORDER BY timestamp DESC: Dentro de cada uno de esos montones (particiones), ordena las filas desde la más reciente a la más antigua. La fila con el timestamp más alto queda la primera. ROW_NUMBER(): A continuación, asigna un número de fila secuencial a cada fila dentro de su partición, empezando por el 1 para la más reciente (que acabamos de poner arriba). WHERE row = 1: Finalmente, el WHERE filtra los resultados y se queda únicamente con las filas a las que se les asignó el número 1. El resultado es que, para cada unique_id, solo seleccionas la fila que tiene la marca de tiempo más reciente, logrando exactamente el objetivo. Un ejemplo de la consulta sería así: WITH RankedData AS ( SELECT *, ROW_NUMBER() OVER(PARTITION BY unique_id ORDER BY event_timestamp DESC) as row_num FROM YourTable ) SELECT * EXCEPT(row_num) FROM RankedData WHERE row_num = 1; ❌ Por qué las otras opciones son incorrectas a) Incluir ORDER BY DESC en la columna de timestamp y LIMIT a 1. Esto ordenaría toda la tabla por la marca de tiempo y te devolvería solo una fila: la más reciente de todo el conjunto de datos. No te daría la fila más reciente para cada ID única, sino que ignoraría a todos los demás IDs. Perderías casi toda tu información. b) Usar GROUP BY en la columna de ID única y en la columna de timestamp y SUM en los valores. Agrupar por unique_id y timestamp no resuelve el problema. Si tienes dos entradas duplicadas para el mismo ID pero con timestamps ligeramente diferentes (por ejemplo, enviadas con milisegundos de diferencia), GROUP BY las tratará como dos filas completamente distintas, ya que la combinación (unique_id, timestamp) es diferente. Por lo tanto, no eliminaría estos duplicados. d) Usar la función de ventana LAG() con PARTITION BY sobre la ID única junto con WHERE LAG IS NOT NULL. La función LAG() te da el valor de la fila anterior dentro de una partición. Si ordenas por timestamp DESC (de más nuevo a más viejo), la fila más nueva es la primera de su partición. Esta primera fila no tiene una "fila anterior", por lo que su valor LAG() sería NULL. La condición WHERE LAG IS NOT NULL haría justo lo contrario de lo que necesitas: eliminaría la fila más reciente (porque su LAG es NULL) y se quedaría con todos los duplicados más antiguos.

Answer 621

C The integration of digital technologies to improve processes, increase efficiency and offer new value propositions to customers.

Answer 622

C A service to train custom models without programming.

Answer 623

D Convert the applications in the virtual machines to container-based applications.

Answer 624

A Cloud Bigtable

Answer 625

B Send the data to Google Cloud Pub/Sub, stream Cloud Pub/Sub to Google Cloud Dataflow, and store the data in Google BigQuery.

Answer 626

B The ability to increase or decrease computing resources according to the needs of running processes.

Answer 627

D Create a Cloud SQL instance in one zone, and create a failover replica in another zone within the same region.

Answer 628

A Use Cloud Pub/Sub for message ingestion and Cloud Dataflow for streaming analysis.

Answer 629

C `bigquery-public-data.noaa_gsod.gsod*`

Answer 630

B Use Cloud Dataprep to find null values in sample source data. Convert all nulls to 0 using a Cloud Dataprep job.

Answer 631

B Use pre-emptible virtual machines (VMs) for the cluster

Answer 632

C A data engineer's core responsibility is to build data pipelines that get raw data into a usable condition, enabling the business to make data-driven decisions. Options A, B, and D describe roles typically performed by other teams or are not the primary focus of a data engineer's role

Answer 633

C A data lake is defined as bringing together raw data from across the enterprise into a single location, often Cloud Storage. In contrast, a data warehouse (like BigQuery) is a consolidated place to store data that has been cleaned, transformed, and made easily joinable and queryable for analytics, departing from the raw format found in a data lake.

Answer 634

A, C y D BigQuery is described as Google Cloud’s petabyte-scale serverless data warehouse. It eliminates the need for data engineers to manage server and cluster capacity because it's fully managed and serverless. BigQuery ML enables the creation and training of machine learning models directly using SQL. Furthermore, BigQuery utilizes column-based storage, which differs from the record-based storage of transactional databases and is ideal for analytical queries where only specific columns might be needed

Answer 635

C The sources explicitly state that cleaning, formatting, and getting data ready for insights requires building ETL (Extract, Transform, Load) pipelines. The cleaned and transformed data are then typically stored in a data warehouse, not a data lake, to make it efficient for querying and analysis, ensuring data accuracy and quality

Answer 636

C The sources emphasize that ML teams rely on data engineers to help capture new features in stable pipelines. They ask questions about feature availability at production time and the ease of adding more columns. Data engineers can earn trust by making datasets easily discoverable, documented, and available for quick experimentation

Answer 637

C BigQuery is a serverless data warehouse that automatically scales and removes the need to manage infrastructure, allowing engineers to focus on insights rather than hardware.

Answer 638

D sta es la respuesta principal y más crítica en el mundo real. ¿Por qué es la buena? Los ingenieros de datos no son dueños de los sistemas de origen (como bases de datos de ventas, APIs de terceros o logs de servidores). A menudo, obtener permiso para acceder a esos datos implica superar barreras de seguridad, burocracia organizacional y problemas técnicos (como firewalls o protocolos incompatibles). Sin acceso a la materia prima (el dato bruto), no hay pipeline que valga. Las Respuestas Incorrectas (o retos secundarios) Aunque estas opciones representan problemas en el mundo de los datos, no son el "desafío clave" de ingeniería que define la creación de la infraestructura de tuberías en la mayoría de los contextos técnicos: a) Query performance (Rendimiento de las consultas) ¿Por qué es "mala"? El rendimiento de las consultas suele ser una preocupación del Analista de Datos o del Data Scientist una vez que los datos ya están en el almacén (Data Warehouse). Aunque un Data Engineer diseña para la eficiencia, si la consulta va lenta, suele ser un problema de indexación o de cómo se escribió la SQL, no necesariamente un fallo estructural del pipeline de transporte. b) Lack of business use cases (Falta de casos de uso de negocio) ¿Por qué es "mala"? Este es un problema de Gestión de Producto (Product Management) o de estrategia empresarial. Si no hay un caso de uso, el ingeniero simplemente no tiene trabajo que hacer. No es un reto técnico de "construcción", sino una falta de dirección previa a la ingeniería. c) Availability of computational resources (Disponibilidad de recursos computacionales) ¿Por qué es "mala"? En la era moderna de la nube (AWS, Azure, Google Cloud), los recursos son virtualmente infinitos siempre que haya presupuesto. Escalar la potencia de procesamiento ya no es un "desafío técnico" difícil de resolver (es un problema de costes), mientras que conseguir que un sistema legacy te dé acceso a sus datos (opción D) sigue siendo un reto humano y técnico complejo.

Answer 639

C A data lake consolidates raw data from multiple sources into one location, while a data warehouse stores cleaned and transformed data optimized for querying.

Answer 640

C Column-based storage enables BigQuery to scan only the needed columns in a query, which enhances performance and efficiency for analytics.

Answer 641

B Cloud Composer is a managed orchestration service based on Apache Airflow that helps schedule and manage data pipelines efficiently.

Answer 642

C A data engineer is primarily responsible for building data pipelines that move, transform, and manage data so it can be used for analytics, reporting, or machine learning, enabling data-driven decisions within the organization

Answer 643

A, B y D ¿Por qué A, B y D son las correctas? Estas tres opciones definen los pilares fundamentales de lo que diferencia a un Data Lake (lago de datos) moderno de un almacenamiento tradicional. En Google Cloud, esto generalmente se refiere a Cloud Storage. 1. Capacidad para manejar todos los tipos de datos (A) El concepto: A diferencia de un Data Warehouse (donde debes definir tablas y columnas antes de guardar nada), un Data Lake acepta datos "crudos". Por qué es clave: Un buen Data Lake debe permitirte guardar CSVs estructurados, JSONs semi-estructurados, y también imágenes, videos o audios (no estructurados) en el mismo lugar. Google Cloud Storage hace esto por diseño. 2. Soporte para ingesta de alto rendimiento (B) El concepto: Los Data Lakes suelen recibir datos de millones de sensores IoT, logs de servidores o clics de usuarios en tiempo real. Por qué es clave: La solución no debe colapsar si le envías terabytes de datos por segundo. Debe escalar automáticamente para escribir los datos tan rápido como llegan (High-Throughput). 3. Control de acceso granular (D) El concepto: Como en el lago guardas todo (datos confidenciales, datos públicos, datos financieros), la seguridad es crítica. Por qué es clave: No quieres un acceso de "todo o nada". Necesitas poder decir: "El equipo de Marketing puede ver la carpeta A, pero solo el equipo de Finanzas puede ver la carpeta B". En Google Cloud, esto se maneja con IAM (Identity and Access Management) y listas de control de acceso (ACLs). ¿Por qué la C es la "mala"? C) Built-in machine learning algorithms ❌ Incorrecta. La distinción: Un Data Lake es, en esencia, Almacenamiento (Storage). Su trabajo es guardar cosas de forma segura y barata. La trampa: Aunque usas los datos del lago para hacer Machine Learning, el lago en sí mismo (el "disco duro" en la nube) no tiene algoritmos "integrados" ejecutándose dentro de los archivos. Tú conectas herramientas de cómputo (como Vertex AI, Dataproc o Dataflow) al lago para leer los datos y correr los algoritmos, pero el almacenamiento es pasivo en cuanto a lógica de cálculo. Resumen Mental Para elegir una solución de Data Lake (Cloud Storage), piensa en estas tres "V" y una "S": Variedad (Opción A): Acepta cualquier formato. Velocidad/Volumen (Opción B): Acepta mucha data muy rápido. Seguridad (Opción D): Controla quién toca qué. (No Cómputo): El lago no "piensa" (no tiene algoritmos), solo "guarda".

Answer 644

B BigQuery is Google Cloud’s serverless, highly scalable data warehouse designed for large-scale analytics, often handling petabyte-scale datasets efficiently.

Answer 645

B A data lake stores raw data in its original format, making it flexible for various types of data, whereas a data warehouse stores data that has been cleaned and transformed, making it efficient for querying and analytics

Answer 646

A, B-y C A typical real-time streaming pipeline on Google Cloud ingests data using Pub/Sub, processes and transforms it with Dataflow, and stores or analyzes it in BigQuery. Cloud SQL is primarily used for transactional databases, not for streaming analytics

Answer 647

B As shown on slides 9 and 37, a Data Lake is a centralized repository that holds a vast amount of raw data in its native format. Google Cloud Storage is the primary service used to build a data lake due to its high durability, scalability, and cost-effectiveness for storing structured and unstructured data.

Answer 648

C Slide 44 clearly distinguishes these two. A transactional database like Cloud SQL is optimized for writes and uses record-based (or row-based) storage, where all columns for a given record are stored together. This is ideal for quickly reading or writing an entire record. A data warehouse like BigQuery is optimized for large-scale analytical reads and uses columnar storage, where values for each column are stored together. This is highly efficient for queries that only need to access a subset of columns from a very wide table.

Answer 649

B y D Slide 61 presents this solution. Cloud Data Catalog is a fully managed metadata management service that allows organizations to discover and understand their data assets. The Cloud Data Loss Prevention (DLP) API provides powerful tools for inspecting and classifying sensitive data. They are designed to integrate, allowing you to use Data Catalog to manage metadata and DLP to find and protect the sensitive PII within those datasets.

Answer 650

B As detailed on slides 66 and 67, Cloud Composer is Google Cloud's managed workflow orchestration service built on Apache Airflow. It is specifically designed to create, schedule, and monitor complex workflows (DAGs) that span multiple services, making it the perfect choice for orchestrating a pipeline that involves Cloud Storage, Dataflow, and BigQuery.

Answer 651

B Slides 31, 33, and 34 highlight that BigQuery is a serverless data warehouse. This means data engineers do not need to provision or manage any underlying infrastructure. BigQuery abstracts this completely by separating storage and compute, dynamically allocating compute resources (slots) as needed to execute queries and then releasing them. This "on-demand" model eliminates the challenge of capacity planning.

Answer 652

B The document emphasizes that a data engineer builds data pipelines to get data into a usable condition and to a place where it can support business decisions, such as dashboards or machine learning models (Page 8). Options A, C, and D describe roles more aligned with data scientists, UI developers, or cloud architects, respectively.

Answer 653

C The document highlights Cloud Storage as a durable (99.99999999% annual durability) and scalable solution for storing raw data in a data lake (Pages 10-11). BigQuery is a data warehouse, Cloud SQL is for relational databases, and Dataflow is for data processing, not storage.

Answer 654

A, B y D ✅ A) ¿Puede manejar todo tipo de datos? Por qué es una consideración clave: La esencia de un data lake es ser un repositorio centralizado para todos los datos de una organización, sin importar su formato. Esto incluye datos estructurados (como tablas de una base de datos), semiestructurados (JSON, XML) y, muy importante, no estructurados (imágenes, vídeos, audios, logs, etc.). Si la plataforma no puede almacenar cualquier tipo de dato en su formato original, no es un verdadero data lake. En Google Cloud, Google Cloud Storage (GCS) es la base de un data lake precisamente porque es un almacén de objetos que acepta cualquier tipo de fichero. ✅ B) ¿Admite la ingesta de alto rendimiento? Por qué es una consideración clave: Los datos suelen llegar de múltiples fuentes, a gran velocidad y en grandes volúmenes (streaming, lotes masivos, etc.). Un data lake debe ser capaz de "tragarse" todos esos datos de forma rápida y eficiente. Si el proceso de ingesta es lento o se convierte en un cuello de botella, el data lake pierde su utilidad, ya que los datos no estarán disponibles a tiempo para su análisis. Google Cloud ofrece herramientas como Pub/Sub para streaming o Storage Transfer Service para grandes transferencias, garantizando una ingesta de alto rendimiento. ✅ D) ¿Existe un control de acceso detallado a los objetos? Por qué es una consideración clave: 🔐 Almacenar todos los datos de la empresa en un solo lugar crea un riesgo de seguridad enorme si no se gestiona bien. Es absolutamente crucial tener un sistema que permita controlar quién puede ver, modificar o eliminar qué datos. Este control debe ser "de grano fino" (fine-grained), es decir, a nivel de fichero individual (objeto), carpeta o incluso a nivel de columna en una tabla. Sin un control de acceso robusto, el data lake se convierte en un "data swamp" (un pantano de datos) inseguro e inútil. En Google Cloud, IAM (Identity and Access Management) y las ACLs de Cloud Storage proporcionan este control de acceso detallado. ❌ C) ¿Está optimizado para el análisis en tiempo real? Por qué NO es una consideración clave: Esta es la respuesta incorrecta porque confunde el data lake (el almacenamiento) con las herramientas que se usan sobre él. El objetivo principal de un data lake es el almacenamiento masivo, flexible y económico, no la velocidad de consulta ultra-rápida. El almacenamiento base (como Google Cloud Storage) está optimizado para guardar petabytes de datos de forma duradera y barata, no para responder a consultas en milisegundos. El análisis en tiempo real se consigue usando herramientas de cómputo que leen los datos desde el data lake, como BigQuery o Dataproc. Por lo tanto, aunque puedes construir un sistema de análisis en tiempo real sobre un data lake, la optimización para este fin no es una característica intrínseca del data lake en sí, a diferencia de las otras tres opciones que son pilares fundamentales de su definición.

Answer 655

B The document describes Cloud Data Catalog as a fully managed metadata management service that simplifies data discovery by providing a unified view of datasets and supporting governance through tagging and access controls (Page 61). Options A, C, and D refer to functionalities of other tools like Dataflow, Cloud Composer, and Cloud Storage, respectively.

Answer 656

B The document specifies that Cloud Composer, a managed version of Apache Airflow, is used to orchestrate production workflows, such as triggering data processing when new files arrive in Cloud Storage (Pages 66-67). BigQuery BI Engine is for dashboard performance, Dataproc is for batch processing, and Pub/Sub is for streaming data ingestion.

Answer 657

B A data lake is described as a scalable and secure data platform where enterprises can ingest, store, process, and analyze any type or volume of information. A key feature is that data is stored in its natural/raw format, often as object blobs or files, retaining every aspect of business operations and adapting easily to changes. It is used for various workloads including data analytics, data science, and ML, as well as batch and streaming data pipelines

Answer 658

B y D Las Respuestas Correctas Las respuestas correctas son la B y la D. 1. Análisis de la opción B (Correcta): "It offers persistence, durability (with eleven 9s), strong consistency, global availability, and high throughput." Por qué es clave: Esta opción describe las especificaciones técnicas de GCS. 11 nueves (99.999999999%): Es la métrica famosa de Google. Significa que es casi imposible perder un archivo por fallos del sistema. Es vital para un Data Lake donde guardas el "histórico de la verdad". Strong Consistency (Consistencia fuerte): Esto es un diferenciador clave de Google. Si subes un archivo y al segundo siguiente intentas leerlo, Google te garantiza que verás la última versión. Otros proveedores tardaron años en lograr esto (antes ofrecían consistencia eventual). 2. Análisis de la opción D (Correcta): "It functions as an object store that retrieves binary objects without regard to their content, while also providing file system compatibility." Por qué es clave: Esta es la definición de Almacenamiento de Objetos (Object Store). "Sin importar su contenido": A GCS no le importa si guardas un CSV, una foto, un video o un archivo de texto. Para GCS, todo son "blobs" (objetos binarios). Esto es la base de un Data Lake: poder guardar datos no estructurados. Compatibilidad: Aunque es un Object Store, herramientas como Hadoop o Spark pueden interactuar con él como si fuera un sistema de archivos tradicional (gracias a los conectores de Google), lo que facilita mover cargas de trabajo de Big Data a la nube. Por qué las otras opciones son incorrectas Estas opciones describen otros servicios, no un Data Lake en GCS. A. "It primarily supports relational data for high-frequency writes." (Principalmente soporta datos relacionales para escrituras de alta frecuencia). Por qué es mala: Esto describe una Base de Datos Relacional (como Cloud SQL o Spanner). La razón técnica: El almacenamiento de objetos (GCS) es muy lento para estar editando registros individuales constantemente (transacciones). GCS está diseñado para escribir un archivo una vez y leerlo muchas veces (WORM: Write Once, Read Many), no para transacciones bancarias rápidas. C. "It automatically applies a consistent schema to all ingested data." (Aplica automáticamente un esquema consistente a todos los datos ingeridos). Por qué es mala: Esto describe un Data Warehouse (como BigQuery). La razón técnica: Data Warehouse (BigQuery): Schema-on-Write (Necesitas definir la estructura antes de guardar). Data Lake (GCS): Schema-on-Read. Guardas los datos "crudos" sin esquema. Solo te preocupas por la estructura cuando vas a leerlos o procesarlos. GCS nunca te rechazará un archivo porque "no cumple con el formato". Consejo PRO: Si ves "11 nueves de durabilidad" o "Objetos inmutables/binarios", la respuesta casi siempre es Cloud Storage.

Answer 659

C A Data Lake is designed to capture every aspect of business operations by storing data in its natural/raw format, often as object blobs or files, and tends to be application-specific. In contrast, a Data Warehouse is typically loaded only after a use case is defined, contains processed, organized, and transformed data, and tends to have a consistent schema shared across applications, providing faster insights and current/historical data for reporting. Data lakes are portable and can be on-premise or in the cloud.

Answer 660

C The ETL (Extract, Transform, and Load) pattern is typically chosen when significant processing and transformation are required before loading data into the cloud product. This is especially true if the transformation is essential, if it greatly reduces the data size (saving network bandwidth), or if the data is in a binary proprietary format that needs conversion. In ETL, transformation occurs in an intermediate service (like Dataflow) before loading. EL (Extract and Load) is for data that can be imported "as is", and ELT (Extract, Load, and Transform) involves loading raw data directly into the target and then transforming it there

Answer 661

C A data lake stores all data types (structured, semi-structured, unstructured) in their raw form, allowing flexible analytics and ML use cases.

Answer 662

B y D Cloud Storage offers 99.999999999% durability, strong consistency, and is globally accessible with high throughput, making it ideal for storing raw data.

Answer 663

A La respuesta correcta es a) Cuando la transformación reduce significativamente el tamaño de los datos. Se elige el patrón ETL (Extraer, Transformar, Cargar) sobre ELT (Extraer, Cargar, Transformar) principalmente cuando el paso de transformación ofrece un beneficio significativo antes de que los datos lleguen al almacén de datos (data warehouse), como BigQuery. ETL vs. ELT: ¿Dónde ocurre la magia? La diferencia clave entre ambos patrones es dónde se realiza la transformación (T): ETL (Extraer, Transformar, Cargar): La transformación se realiza en un sistema intermedio (como un motor de procesamiento de datos tipo Apache Spark o Cloud Dataflow) antes de cargar los datos limpios y ya agregados en el data warehouse. ELT (Extraer, Cargar, Transformar): Se cargan los datos en bruto directamente en un data warehouse moderno y potente (como BigQuery), y se utiliza la capacidad de cómputo del propio almacén para realizar las transformaciones usando SQL. Analogía: Piensa en preparar una ensalada. ETL es lavar, cortar y mezclar todas las verduras en tu cocina (sistema intermedio) y luego llevar el bol de ensalada ya lista (datos limpios) a la mesa (data warehouse). ELT es llevar todas las verduras en la bolsa de la compra (datos en bruto) directamente a la mesa y prepararla allí mismo usando un juego de cuchillos de última generación (potencia de BigQuery). Explicación de las opciones a) Cuando la transformación reduce significativamente el tamaño de los datos Esta es la razón principal para elegir ETL. Si tienes 1 TB de logs en bruto, pero la transformación consiste en agregar esos datos en un informe final de solo 10 GB, es mucho más eficiente y económico: Extraer el terabyte de logs. Transformarlos en un sistema de procesamiento más barato, reduciéndolos a 10 GB. Cargar únicamente esos 10 GB finales en BigQuery. Esto ahorra costes de almacenamiento y, a veces, de procesamiento en BigQuery. b) Cuando se usan consultas federadas en BigQuery Las consultas federadas son un ejemplo de ELT. Permiten a BigQuery consultar datos que residen en una fuente externa (como Cloud SQL o Google Sheets) sin cargarlos primero. La transformación ocurre en BigQuery sobre datos que están fuera, lo cual es la filosofía de ELT. c) Cuando los datos requieren una limpieza mínima Si la transformación es mínima, el patrón ELT es casi siempre superior. Es más sencillo y rápido cargar los datos en bruto y ejecutar una consulta de limpieza rápida en BigQuery que montar un paso de transformación intermedio. d) Cuando se cargan archivos Avro pre-limpiados en BigQuery Esta opción describe el resultado de un proceso ETL, no la razón para elegirlo. La pregunta es por qué decidirías tener esos archivos "pre-limpiados". La respuesta, muy probablemente, es la opción (a): porque la transformación que los limpió y generó también redujo su tamaño.

Answer 664

D Archive storage is designed for data that is rarely accessed, offering the lowest cost and requiring a 365-day minimum duration.

Answer 665

A y C Cloud SQL is a managed relational database that supports those engines and can be set up with failover replicas. It's designed for OLTP, not OLAP.

Answer 666

C A data lake is designed to store all types of data (structured, semi-structured, unstructured) in its original, raw format, making it flexible and adaptable to changes.

Answer 667

B Cloud Storage is the most common choice for building a data lake in Google Cloud because it is durable, highly available, and supports storing data in various formats.

Answer 668

A, B y C A data engineering ecosystem includes data sources (where data originates), data pipelines (for processing and transforming data), and data warehouses (for analytics and reporting). Mobile applications are not a core component of the data engineering ecosystem.

Answer 669

C Data lakes are designed to store raw, unprocessed data, while data warehouses store data that has been cleaned, processed, and structured for analytics.

Answer 670

A y C ✅ Respuestas Correctas A) Cloud Composer Cloud Composer es la principal herramienta de Google Cloud para la orquestación de flujos de trabajo (workflows). Se trata de un servicio gestionado basado en el popular proyecto de código abierto Apache Airflow. Función principal: Su propósito es programar, monitorizar y gestionar flujos de trabajo complejos que pueden involucrar múltiples pasos y servicios (por ejemplo, iniciar un job en Dataproc, luego cargar los resultados en BigQuery y finalmente enviar una notificación). Por qué es correcto: Es la herramienta diseñada específicamente para esta tarea. Los flujos de trabajo se definen como Grafos Acíclicos Dirigidos (DAGs) en Python, lo que ofrece una enorme flexibilidad. Es la opción ideal para pipelines de datos complejos y dependientes entre sí. C) Cloud Functions Cloud Functions es un servicio de "cómputo sin servidor" (serverless) que te permite ejecutar código en respuesta a eventos. Función principal: Ejecutar pequeñas piezas de código (funciones) de manera aislada cuando ocurre un "disparador" (trigger), como la subida de un archivo a Cloud Storage, la llegada de un mensaje a Pub/Sub o una llamada HTTP. Por qué es correcto: Se puede usar para una orquestación simple y basada en eventos. Por ejemplo, una Cloud Function puede "dispararse" cuando un archivo aterriza en un bucket de Cloud Storage e iniciar un job de BigQuery. Aunque no es tan potente como Cloud Composer para flujos complejos, es una herramienta válida y muy utilizada para orquestar tareas sencillas y reactivas. ❌ Respuestas Incorrectas B) Bigtable Bigtable es una base de datos NoSQL de columna ancha. Función principal: Almacenar y servir grandes cantidades de datos (terabytes o petabytes) con una latencia muy baja, ideal para aplicaciones analíticas o de series temporales a gran escala. Por qué es incorrecto: Es un servicio de almacenamiento de datos, no de orquestación. No tiene ninguna capacidad para definir, programar o ejecutar flujos de trabajo. Simplemente guarda y lee datos. D) Vertex AI Vertex AI es la plataforma unificada de Google Cloud para el aprendizaje automático (Machine Learning). Función principal: Ofrece herramientas para construir, entrenar, desplegar y gestionar modelos de ML. Dentro de Vertex AI, existe un componente llamado Vertex AI Pipelines que sí orquesta flujos de trabajo, pero están específicamente diseñados para el ciclo de vida del ML (preparar datos, entrenar modelo, evaluar, desplegar), no para la orquestación general de pipelines de datos. Por qué es incorrecto: Aunque contiene capacidades de orquestación, su dominio es el MLOps (operaciones de Machine Learning), no la ingeniería de datos general. Para una pregunta sobre orquestación de datos genérica, Cloud Composer es la respuesta más precisa y adecuada.

Answer 671

B As defined on slides 4 and 17, a data lake is designed to ingest and store data in its raw, native format from various sources, supporting all data types. Cloud Storage is presented (slide 12) as the canonical service for building a data lake due to its scalability, durability, and ability to store any type of object/file. A data warehouse (A) is for processed data, an OLTP system (C) is for transactional workloads, and a pipeline (D) is for moving data, not for long-term storage of raw data.

Answer 672

C Object Lifecycle Management (slide 34) is the feature specifically designed to automate the transition of objects between storage classes based on rules, such as age or access patterns. You can create rules to automatically move objects to Coldline Storage after 90 days of inactivity and then to Archive Storage after 365 days, perfectly matching the requirements. The other options are for different use cases: versioning/retention (A) prevents deletion, Requester Pays/Signed URLs (B) are for access control and billing, and Bucket Lock/IAM (D) are for security and permissions.

Answer 673

C According to the definitions on slides 23 and 24, this is a classic ETL pattern. The data is Extracted from the source, Transformed in an intermediate service (Dataflow), and then Loaded into the final destination (BigQuery). The key differentiator is that the transformation happens before the data lands in the target warehouse. The ELT pattern (B) would involve loading the raw data into BigQuery first and then transforming it there using SQL.

Answer 674

C ✅ Por qué la opción C (CMEK) es la correcta Esta opción es un equilibrio perfecto entre control y conveniencia, y cumple exactamente con los dos requisitos de la pregunta: El cliente controla las claves: Con CMEK, tú utilizas el servicio Cloud Key Management Service (KMS) de Google para crear, rotar, y destruir las claves de encriptación. Tienes control total sobre el ciclo de vida y los permisos de la clave. Si deshabilitas o destruyes la clave, nadie (ni siquiera Google) podrá desencriptar los datos asociados a ella. Usa la infraestructura de Google KMS: Las claves que gestionas residen dentro de la infraestructura segura y reforzada de Google (KMS), aprovechando su protección física y lógica, auditorías y alta disponibilidad. En resumen, CMEK te da el control de un director (tú decides sobre la clave) usando el escenario y la seguridad de Google (KMS). ❌ Por qué las otras opciones son incorrectas A) Google-managed encryption keys (GMEK) Esta es la opción por defecto en Cloud Storage. Google gestiona todo de forma automática: la creación, rotación y destrucción de las claves. Es muy fácil de usar, pero no cumple el requisito principal de que la organización debe controlar las claves. B) Customer-supplied encryption keys (CSEK) Con esta opción, tú creas y gestionas la clave completamente fuera de Google Cloud. Cada vez que quieres acceder a los datos, tienes que enviar la clave junto con la solicitud. Si bien esto te da el control sobre la clave (cumple el primer requisito), no utiliza la infraestructura de Google KMS para alojarla (falla el segundo requisito). La responsabilidad de proteger y gestionar la clave recae 100% en ti. D) Client-side encryption Esta es la opción de máximo control. Tú encriptas los datos en tus propios sistemas antes de subirlos a Cloud Storage. Google solo ve un bloque de datos ya encriptado y no tiene ninguna información sobre las claves. Al igual que CSEK, cumple el requisito de control, pero no utiliza para nada la infraestructura de Google KMS, ya que todo el proceso de encriptación y gestión de claves es externo a Google.

Answer 675

B y D Backend de la Aplicación Móvil (Carga Transaccional) Para el backend de una aplicación móvil que necesita leer y escribir registros individuales de usuarios de forma rápida y frecuente, se busca una base de datos transaccional (OLTP). B) Usar Cloud SQL para el backend de la aplicación móvil. ✅ Cloud SQL es un servicio de bases de datos relacionales gestionadas (como MySQL o PostgreSQL). Está diseñado precisamente para este tipo de cargas de trabajo: muchas transacciones pequeñas y rápidas que afectan a filas individuales (por ejemplo, UPDATE user SET ... WHERE user_id = ...). Es la opción predeterminada y más robusta para un backend de aplicación estándar. A) Usar Bigtable para el backend de la aplicación móvil. ❌ Bigtable es una base de datos NoSQL de columna ancha, diseñada para cargas de trabajo masivas a escala de petabytes, como series temporales o grandes análisis operacionales. Aunque ofrece baja latencia, suele ser una solución demasiado compleja y especializada para gestionar simples registros de usuario, una tarea para la que una base de datos relacional es más natural y sencilla. Sistema de Analítica (Carga Analítica) Para el equipo de análisis que necesita ejecutar agregaciones complejas sobre terabytes de datos, se requiere un almacén de datos para analítica (OLAP). D) Usar BigQuery para el sistema del equipo de analítica. ✅ BigQuery es un almacén de datos (data warehouse) sin servidor, masivamente escalable. Su arquitectura está optimizada desde cero para ejecutar consultas analíticas complejas sobre volúmenes de datos enormes (terabytes o petabytes) a una velocidad increíble. Es la herramienta perfecta y por defecto en Google Cloud para este caso de uso. C) Usar Cloud SQL para el sistema del equipo de analítica. ❌ Usar Cloud SQL para este fin sería un error. Las bases de datos relacionales (OLTP) son muy ineficientes para escanear y agregar tablas de terabytes. Una consulta que en BigQuery tardaría segundos o minutos, en Cloud SQL podría tardar horas o simplemente no terminar nunca. Es la herramienta equivocada para el trabajo.

Answer 676

B A data lake is designed to store raw, unprocessed data in its native format, allowing for flexibility in processing and analysis later. It is not primarily for storing processed data (that's more for a data warehouse), nor is it specifically for transactional workloads or real-time analytics, although it can support various use cases.

Answer 677

C The data lake is where raw data is initially stored before any processing or transformation. It's not the final destination for cleaned data (that's the data warehouse), nor is it where transformation happens (that's part of the ETL/ELT process), and it doesn't orchestrate workflows (that's the role of orchestration tools like Apache Airflow).

Answer 678

C Google Cloud Storage is favored for data lakes because it can store any type of data, including unstructured data, at a low cost. It also offers high durability, availability, and scalability, which are crucial for data lakes.

Answer 679

C Google Cloud Storage provides several security features, including encryption at rest and in transit, with options for customer-managed encryption keys (CMEK). Access control is managed through both IAM and ACLs, and there are features like data retention policies for compliance.

Answer 680

B La respuesta correcta es la B: "When the transformation requires significant computational resources that are available in the cloud." (Cuando la transformación requiere recursos computacionales significativos que están disponibles en la nube). ¿Por qué? En un proceso ELT (Extraer, Cargar, Transformar), el orden es fundamental: Extraes los datos de la fuente. Los Cargas inmediatamente en tu destino (Data Lake o Data Warehouse) tal cual están (datos crudos). Los Transformas dentro del propio destino. La razón principal para elegir ELT hoy en día es la potencia de la nube. Los Data Lakes y Warehouses modernos (como Snowflake, BigQuery, Redshift o Databricks) tienen una capacidad de procesamiento masiva y escalable. Si tienes transformaciones complejas (ej. unir tablas gigantes, cálculos pesados), es mucho más eficiente usar la potencia bruta del destino (la nube) para hacer esos cálculos una vez que los datos ya están allí, en lugar de intentar procesarlos en un servidor intermedio más pequeño antes de cargarlos. Por qué las otras opciones son incorrectas Aquí es donde suelen caer las trampas. Analicémoslas: A. "When the data needs to be transformed before being stored to save storage costs." (Cuando los datos necesitan ser transformados antes de ser almacenados para ahorrar costes de almacenamiento). Por qué es mala: Esta es la definición clásica de ETL, no de ELT. Explicación: En el pasado, el almacenamiento era muy caro, por lo que transformábamos y limpiábamos los datos antes (la "T" antes de la "L") para no guardar basura. En un escenario de Data Lake moderno (ELT), el almacenamiento es barato (como Amazon S3 o Azure Blob Storage), por lo que preferimos cargar todo primero y transformar después. C. "When the data is already in a format compatible with the destination system." (Cuando los datos ya están en un formato compatible con el sistema de destino). Por qué es mala: Si los datos ya son compatibles y están listos, apenas necesitas "Transformación". Explicación: Esto describiría una simple copia de datos. No justifica el uso de una arquitectura ELT compleja. ELT se usa precisamente cuando los datos no están listos para el consumo y requieren mucho poder de cómputo para llegar a ese estado. D. "When the data volume is small and can be easily transformed locally." (Cuando el volumen de datos es pequeño y puede ser fácilmente transformado localmente). Por qué es mala: Esto sugiere un proceso manual o un ETL ligero. Explicación: ELT brilla con Big Data. Si los datos son pocos y pequeños, no necesitas la potencia masiva de la nube para transformarlos; podrías hacerlo en tu propio ordenador o en un servidor pequeño (ETL tradicional). Usar una infraestructura de Data Lake en la nube para datos pequeños sería como matar moscas a cañonazos.

Answer 681

C The sources explicitly state, "A data warehouse imposes a schema. A data lake is just raw data". While both can consolidate data from many sources, the key distinction is the schema enforcement. The purpose of a data warehouse is to make data available for querying and processing, unlike a data lake which is primarily for storing raw data

Answer 682

A, B y C BigQuery is ideal because it cost-effectively handles large, petabyte-scale datasets for storage and querying. It is a serverless fully-managed service, meaning Google takes care of updates, maintenance, storage management, and fault recovery. Additionally, BigQuery has features like GIS and machine learning built in, allowing operations without moving data out of the warehouse. Option D is incorrect, as BigQuery is an OLAP system optimized for reading and appending data, and not for updating or OLTP workloads

Answer 683

C A BigQuery slot is defined as a "unit of computational capacity required to execute SQL queries". BigQuery automatically calculates and allocates the necessary slots based on query size and complexity. It's important to note that BigQuery uses a microservice architecture, so there are no virtual machines to configure and maintain by the user

Answer 684

C The sources state that it's "much more efficient to define your schema to use nested, repeated fields instead of joins". This is because BigQuery supports columns with nested and repeated data which helps to work with data from relational databases by preserving relational qualities while enabling columnar and parallel processing. Nested fields (STRUCTs) allow you to have "pre-joined tables within a table," making queries faster as data is conceptually pre-joined. Repeated fields (ARRAYs) allow for multiple granular values within a single field, avoiding data duplication across rows while keeping all data for a single record in one place

Answer 685

A, B y C ✅ Respuestas Correctas A. El particionado ayuda a reducir los costes de las consultas al limitar la cantidad de datos escaneados solo a las particiones relevantes. Explicación: Esta es la función principal del particionado. Cuando filtras una consulta por la columna de partición (normalmente una fecha), BigQuery puede ignorar por completo las demás particiones. Este proceso se llama partition pruning (poda de particiones). Al escanear menos datos, la consulta es más rápida y, lo más importante, más barata. B. El clustering ordena automáticamente los datos dentro de las particiones, mejorando el rendimiento de las consultas de filtrado y agregación. Explicación: Esto es correcto. El clustering funciona como un índice de grano grueso. Ordena físicamente los datos dentro de una partición según las columnas que elijas. Cuando filtras por una columna clusterizada, BigQuery sabe exactamente qué bloques de datos leer y cuáles saltarse, lo que acelera enormemente las consultas, especialmente las que usan filtros (WHERE) y agregaciones (GROUP BY). C. BigQuery se encarga automáticamente del re-clustering de los datos a lo largo del tiempo, eliminando la necesidad de intervención manual. Explicación: Correcto. A medida que se añaden o modifican datos, el clustering puede volverse menos óptimo. BigQuery tiene un proceso automático en segundo plano que reorganiza y re-clusteriza los datos para mantener el buen rendimiento, sin que tengas que hacer nada. Es una de las ventajas de ser un servicio gestionado. ❌ Respuesta Incorrecta D. El clustering proporciona estimaciones de costes precisas antes de que comience una consulta, mientras que el particionado no. Explicación: Esta afirmación es exactamente al revés y por eso es falsa. El particionado SÍ permite a BigQuery darte una estimación de coste muy precisa antes de ejecutar la consulta, porque sabe de antemano qué particiones va a escanear. Con el clustering, la estimación de coste inicial no refleja el ahorro final. BigQuery te dirá que escaneará toda la partición, aunque durante la ejecución termine leyendo mucho menos gracias al orden de los datos. El coste real será menor, pero la estimación previa no es tan precisa.

Answer 686

C A modern data warehouse like BigQuery is serverless, supports ad hoc queries, and scales seamlessly from GBs to PBs.

Answer 687

C BigQuery's columnar storage reads only the columns needed for a query, making it ideal for analytical workloads.

Answer 688

A y C Nested and repeated fields allow more efficient queries and reduce the need for joins, especially when data has 1-to-many relationships.

Answer 689

C BigQuery Data Transfer Service supports scheduled and automated imports from services like YouTube, Google Ads, and Salesforce, helping build the data warehouse without manual ETL coding.

Answer 690

C BigQuery separates storage and query billing. The project that owns the data pays for storage, while the project executing the query incurs the query cost.

Answer 691

B Enterprise data warehouses consolidate data from many sources and impose a schema, making the data available for structured querying. Data lakes store raw data without enforcing a schema.

Answer 692

B BigQuery is serverless and fully managed, meaning Google handles updates, scaling, and maintenance, freeing users from managing infrastructure.

Answer 693

A, C y D Modern data warehouses support machine learning, integrate with visualization/reporting tools, and offer a serverless architecture. Manual index management is not required in BigQuery.

Answer 694

B Column-oriented storage in BigQuery allows for efficient reading of only the necessary columns during analytical queries, improving performance for large-scale data analysis.

Answer 695

B A BigQuery slot is a unit of computational resources, including CPU, memory, and networking, allocated dynamically to execute queries.

Answer 696

C The best practice is to partition by the column with lower cardinality that is most often used for filtering broad time ranges (like a date). This allows BigQuery to prune entire partitions (days/months of data) without scanning them. Clustering should then be used on higher-cardinality columns (like country_code) to sort the data within each partition, allowing BigQuery to efficiently skip blocks of data that don't match the filter. This approach directly follows the optimization principles discussed on slides 85-90.

Answer 697

D Explicación: ¿Por qué la D es la correcta? Esta es la forma recomendada e idiomática de modelar relaciones jerárquicas (como pedidos y sus artículos) en BigQuery. Aprovecha las capacidades nativas de BigQuery para manejar datos complejos, lo que proporciona el mejor rendimiento. ¿Qué es un campo anidado y repetido? Imagina una tabla donde cada fila es un pedido único. La información del pedido (order_id, customer_id, etc.) son columnas normales. Sin embargo, hay una columna especial, llamada line_items, que contiene un ARRAY (una lista). Cada elemento de esa lista es un STRUCT (un objeto) que contiene la información de un artículo de línea (product_id, quantity, price). ¿Por qué es la mejor opción? Elimina los JOINs: Al mantener los datos del pedido y de sus artículos físicamente juntos en la misma fila, se elimina por completo la necesidad de realizar operaciones JOIN, que son computacionalmente muy costosas en un sistema distribuido como BigQuery. Máxima Eficiencia: Este diseño se alinea perfectamente con el motor de almacenamiento columnar de BigQuery. Evita la duplicación masiva de datos que ocurriría en un modelo aplanado y mantiene la relación natural de los datos. Consultas Potentes: Puedes consultar los datos anidados de forma muy eficiente utilizando el operador UNNEST. ¿Por qué las otras opciones son incorrectas? A. Esquema normalizado con tablas separadas: Este es el enfoque tradicional de las bases de datos relacionales (como MySQL o PostgreSQL). En BigQuery, forzar un JOIN entre una tabla masiva de pedidos y una tabla aún más grande de artículos de línea es una receta para consultas lentas y caras. ❌ B. Tabla única y aplanada (desnormalizada): En este diseño, si un pedido tiene 5 artículos, tendrías 5 filas en la tabla, repitiendo la información del pedido en cada una. Aunque evita los JOINs, genera una duplicación masiva de datos, lo que es ineficiente en términos de almacenamiento y puede ralentizar las consultas que solo necesitan información a nivel de pedido. ❌ C. Tabla externa apuntando a archivos JSON: Las tablas externas son para consultar datos "in situ" en Cloud Storage sin cargarlos en BigQuery. El rendimiento de las consultas sobre tablas externas es casi siempre significativamente peor que sobre las tablas nativas de BigQuery. Es una estrategia para la conveniencia, no para el rendimiento. ❌

Answer 698

B, D y E B: The separation of compute and storage (slide 12) is a fundamental design principle that allows each to scale independently. D: BigQuery is described as a serverless, fully-managed, and no-ops service (slide 11), freeing users from maintenance tasks. E: Its columnar storage (slide 15) is what makes analytical queries extremely fast, as the query engine avoids reading unnecessary data from columns not referenced in the query. (A is incorrect because BigQuery is column-oriented. C is incorrect because it is serverless and does not require manual cluster provisioning).

Answer 699

C As shown on slide 25, the cost of a query is always assigned to the project from which the query is executed (Project-A in this case). The cost of storing the data is billed to the project that owns the dataset (Project-B). This model allows for clear separation of costs when sharing data across different teams or departments.

Answer 700

C ✅ Respuesta Correcta C. ELT (Extract, Load, Transform): Realizar una carga por lotes de los datos CSV sin procesar en una tabla de "preparación" (staging) en BigQuery y, a continuación, ejecutar consultas SQL para limpiar y transformar los datos de la tabla de preparación en una tabla "de producción" final. Este es el patrón de diseño más común, eficiente e idiomático en BigQuery para esta tarea. Se conoce como ELT (Extraer, Cargar, Transformar). Cargar (Load): Usas la función de carga nativa de BigQuery, que es extremadamente rápida y económica, para volcar los datos CSV "tal cual" desde Cloud Storage a una tabla de preparación. Transformar (Transform): Una vez que los datos están dentro de BigQuery, usas el poder de SQL para realizar todas las limpiezas y transformaciones. Con una simple consulta CREATE TABLE AS SELECT ... o INSERT INTO ... SELECT ..., lees de la tabla de preparación, aplicas las transformaciones (como CAST() o cálculos matemáticos) y guardas el resultado limpio en una tabla final optimizada. Este método aprovecha al máximo las capacidades nativas de BigQuery, es muy rentable y escalable. ❌ Respuestas Incorrectas A. ETL (Extract, Transform, Load): Usar una herramienta externa como Dataflow para transformar los datos antes de cargarlos en BigQuery es excesivo (overkill) para transformaciones simples. Aunque es un patrón válido para lógica compleja, no es el más eficiente ni común cuando SQL es suficiente. B. Consulta Federada: Crear una tabla externa y transformar los datos en cada consulta es ineficiente. Obliga a BigQuery a leer los archivos CSV y aplicar las transformaciones cada vez que alguien consulta los datos, lo que es más lento y costoso que consultar una tabla nativa ya transformada. D. BigQuery Data Transfer Service: Este servicio está diseñado para mover datos de fuentes externas (como Google Ads, S3, etc.) a BigQuery. No está hecho para realizar transformaciones personalizadas como escalar una columna. Solo se encargaría del paso de "Carga", pero no del de "Transformación".

Answer 701

C A modern data warehouse supports ad hoc queries, allowing users to perform complex queries without prior data preparation, as outlined in the certification material.

Answer 702

B BigQuery is described as a serverless, fully-managed data warehouse solution on Google Cloud, designed for large-scale datasets with features like interactive SQL queries.

Answer 703

B In ETL, data is extracted, transformed, and then loaded into the data warehouse, unlike ELT where transformation happens after loading, as per the certification material.

Answer 704

B Nested and repeated fields allow complex data to be stored in a single table, reducing the need for joins and improving query performance, as highlighted in the material.

Answer 705

B Partitioning divides data into smaller subsets, allowing queries to process only relevant data, improving performance and potentially reducing costs, as per the certification content.

Answer 706

C The ultimate purpose of a data pipeline is to enable stakeholders in an organization to use data to make faster and better decisions. While data lakes store unprocessed data and cloud infrastructure is managed, these are means to an end, not the ultimate purpose of the pipeline itself.

Answer 707

A y C The three primary advantages of doing data engineering in the cloud are the ability to separate compute and storage, the availability of serverless products, and not having to manage infrastructure. This also allows you to spend more time on getting insights from data

Answer 708

C At a high level, a data lake is a place to store unprocessed data, while a data warehouse is a place to store transformed data that you ultimately want to use for analytics, machine learning, and dashboards. Google Cloud Storage is the data lake solution and BigQuery is the data warehouse solution on Google Cloud.

Answer 709

B BigQuery is introduced as the data warehouse solution on Google Cloud. Google Cloud Storage is presented as the data lake solution

Answer 710

A, B, C y D A continuación te explico por qué cada una de estas técnicas es una respuesta correcta. A) Replicación de Datos (Data Replication) La replicación consiste en crear y mantener múltiples copias de los datos en diferentes ubicaciones o servidores. ¿Por qué mejora el rendimiento? 💡 Principalmente, mejora la concurrencia de lectura y la disponibilidad. Si muchas consultas intentan leer los mismos datos al mismo tiempo, el sistema puede dirigirlas a diferentes réplicas. Esto evita cuellos de botella y permite que más consultas se ejecuten en paralelo sin degradar el rendimiento. Es como tener varias cajas en un supermercado en lugar de una sola: se atiende a más gente al mismo tiempo. B) Particionamiento (Partitioning) El particionamiento divide una tabla muy grande en segmentos más pequeños y manejables llamados particiones, basándose en los valores de una columna específica (generalmente una fecha, como la del día de hoy, 9 de agosto de 2025). ¿Por qué mejora el rendimiento? ✂️ Permite la eliminación de particiones (partition pruning). Cuando haces una consulta que filtra por la columna de partición (por ejemplo, WHERE fecha = '2025-08-09'), el sistema es lo suficientemente inteligente como para escanear solo la partición correspondiente a esa fecha, ignorando todas las demás. Esto reduce drásticamente la cantidad de datos que necesita leer y procesar. Analogía: Es como tener un archivador con un cajón para cada año. Si buscas un documento de 2025, solo abres ese cajón en lugar de revisar el archivador entero. C) Fragmentación (Sharding) El sharding va un paso más allá del particionamiento. Divide una base de datos completa horizontalmente y distribuye los fragmentos (shards) en múltiples servidores o nodos. Cada shard es una base de datos independiente que contiene una porción del total de los datos. ¿Por qué mejora el rendimiento? 🚀 Permite la escalabilidad horizontal y el procesamiento en paralelo. Las consultas se pueden ejecutar simultáneamente en todos los shards, y los resultados se agregan al final. Esto distribuye la carga de trabajo computacional entre muchas máquinas, lo que acelera enormemente las consultas sobre conjuntos de datos masivos. Analogía: En lugar de una biblioteca gigante, tienes 10 bibliotecas más pequeñas por toda la ciudad, cada una con una parte de los libros (por ejemplo, por orden alfabético del autor). El trabajo de búsqueda se reparte. D) Clústerin (Clustering) El clústerin organiza físicamente los datos dentro de una partición (o tabla), ordenándolos según los valores de una o más columnas. Las filas con valores similares en las columnas de clúster se almacenan juntas en el disco. ¿Por qué mejora el rendimiento? 📊 Mejora la eficiencia de la lectura de datos (I/O). Cuando una consulta filtra por una columna agrupada, el sistema puede leer un bloque contiguo de datos en lugar de tener que buscar datos dispersos por todo el almacenamiento. Esto reduce la cantidad de datos escaneados dentro de una partición. Analogía: Dentro del cajón de 2025 (la partición), todos los documentos están ordenados alfabéticamente por cliente. Si buscas los documentos de "ClienteX", puedes ir directamente a la sección "X" sin tener que mirar cada papel del cajón.

Answer 711

C One of the key benefits of cloud data engineering is the ability to decouple compute and storage, allowing for greater flexibility and scalability

Answer 712

C Data lakes hold raw or unprocessed data, while data warehouses store data that has been transformed for analysis and decision-making .

Answer 713

D BigQuery is Google Cloud's data warehouse solution, optimized for analytics with features like partitioning and clustering to improve performance

Answer 714

A y C a) No infrastructure management (Sin gestión de infraestructura) - ✅ Correcta Esta es la definición fundamental de serverless y su principal beneficio. ¿Qué significa? No tienes que aprovisionar, configurar, parchear o mantener servidores o clústeres. El proveedor de la nube se encarga de todo. Simplemente usas el servicio. Ejemplo: Con BigQuery (un data warehouse serverless), cargas tus datos y ejecutas consultas SQL. Nunca tienes que decidir cuántos servidores usar o instalar un sistema operativo. Beneficio: Los ingenieros de datos pueden centrarse en construir canalizaciones y analizar datos, en lugar de actuar como administradores de sistemas. c) Faster time to insights (Tiempo más rápido para obtener resultados) - ✅ Correcta Este es un resultado directo del beneficio anterior (opción A). ¿Qué significa? "Time to insight" es el tiempo que tardas desde que tienes una pregunta de negocio hasta que obtienes una respuesta a partir de los datos. ¿Por qué es más rápido con serverless? Al no tener que esperar a que se aprovisione un clúster o se configure la infraestructura (lo que puede llevar días o semanas), un analista puede empezar a escribir consultas y obtener resultados en minutos. Se elimina el cuello de botella de la infraestructura. Beneficio: La empresa puede tomar decisiones basadas en datos mucho más rápido. b) Manual scaling is required (Se requiere escalado manual) - ❌ Incorrecta Esta afirmación es exactamente lo opuesto a un beneficio de serverless. Realidad: Una característica clave de los productos serverless es el escalado automático. El servicio asigna recursos dinámicamente según la demanda de tu carga de trabajo, y los libera cuando ya no se necesitan. Ejemplo: Si lanzas una consulta muy pesada en BigQuery, Google asignará automáticamente miles de recursos para ejecutarla rápidamente sin que tú tengas que hacer nada. No hay un "control deslizante" para escalar manualmente. d) Compute and storage are tightly coupled (El cómputo y el almacenamiento están estrechamente acoplados) - ❌ Incorrecta Esto describe una arquitectura antigua y es lo contrario de cómo funcionan las plataformas de datos serverless modernas como BigQuery. Realidad: Los productos serverless modernos desacoplan (separan) el cómputo del almacenamiento. Almacenamiento: Tus datos se guardan en un sistema de almacenamiento distribuido, persistente y de bajo coste. Cómputo: Los recursos para procesar tus consultas se asignan solo cuando los necesitas y se apagan después. Beneficio: Puedes almacenar petabytes de datos a un coste muy bajo y pagar por la capacidad de cómputo (que es más cara) únicamente durante los segundos o minutos que dura una consulta. Si estuvieran acoplados, tendrías que pagar por mantener el cómputo encendido todo el tiempo solo para tener los datos disponibles.

Answer 715

B In ELT, data is first Extracted and Loaded into the warehouse, and then Transformed using the warehouse's compute capabilities (like BigQuery SQL functions)

Answer 716

C The main responsibility of a data engineer is to build data pipelines that enable stakeholders to use data for faster and better decision-making

Answer 717

A, B y C Cloud data engineering allows separation of compute and storage, offers serverless solutions, and removes the need to manage infrastructure. Zero latency is not guaranteed

Answer 718

B Data lakes are used to store raw, unprocessed data, while data warehouses store processed, transformed data for analytics and reporting

Answer 719

B BigQuery is the data warehouse solution on Google Cloud, designed to store and analyze transformed data

Answer 720

C In the EL process, data is extracted and loaded without transformation. ETL and ELT differ in the order and place of transformation, but EL does not include transformation

Answer 721

C As stated in the summary (slide 3), Google Cloud Storage is the recommended data lake solution on Google Cloud. It is ideal for storing large amounts of unstructured and semi-structured data at a low cost before it is processed and loaded into a data warehouse like BigQuery.

Answer 722

B The scenario describes the ELT pattern, where data is first Loaded (L) and then Transformed (T). As mentioned on slide 3, BigQuery is Google Cloud's data warehouse solution with a powerful engine capable of performing large-scale transformations on data that has already been loaded into it. This is a common and efficient modern data warehousing pattern.

Answer 723

A y C El Problema Clave Tienes una tabla de 50 TB y dos patrones de consulta muy claros: Filtrado frecuente por fecha: WHERE transaction_date = '...' Agrupación frecuente por sucursal: GROUP BY branch_id El objetivo es hacer las consultas más rápidas y baratas. En BigQuery, el coste se basa principalmente en la cantidad de datos leídos (escaneados) por la consulta. Por lo tanto, cualquier técnica que reduzca los datos escaneados es una victoria. Por qué 'a' y 'c' son las respuestas correctas Estas dos técnicas, partición y clusterización, son las herramientas fundamentales de BigQuery para optimizar el escaneo de datos y a menudo se usan juntas. a) Partition the table by transaction_date. (Particionar la tabla por transaction_date) - Correcto ¿Qué hace? La partición divide físicamente una tabla grande en segmentos más pequeños (particiones) basados en los valores de una columna, generalmente una fecha o timestamp. En este caso, BigQuery crearía "mini-tablas" internas, una por cada día (o mes/año) de transaction_date. ¿Por qué funciona aquí? Cuando un analista ejecuta una consulta con un filtro como WHERE transaction_date BETWEEN '2025-01-01' AND '2025-01-31', BigQuery es lo suficientemente inteligente como para escanear únicamente las particiones correspondientes a esos 31 días. Ignora por completo el resto de los 50 TB de datos. Resultado: Se reduce drásticamente la cantidad de datos escaneados, lo que se traduce directamente en consultas más rápidas y mucho más baratas. Es la solución perfecta para el primer patrón de consulta. c) Cluster the table by branch_id. (Clusterizar la tabla por branch_id) - Correcto ¿Qué hace? La clusterización ordena físicamente los datos dentro de cada partición basándose en los valores de una o más columnas. En este caso, todas las transacciones con el mismo branch_id se almacenarían juntas en bloques contiguos. ¿Por qué funciona aquí? Cuando un analista filtra o agrupa por branch_id (por ejemplo, WHERE branch_id = 123 o GROUP BY branch_id), BigQuery sabe que todos los datos para una sucursal específica están co-localizados. Esto le permite escanear de manera mucho más eficiente, evitando tener que leer bloques de datos innecesarios dentro de una partición. Resultado: Mejora el rendimiento para consultas que filtran o agrupan por columnas de alta cardinalidad (columnas con muchos valores distintos, como branch_id). Es la solución perfecta para el segundo patrón de consulta. La combinación de ambas es la estrategia de optimización estándar para tablas grandes con filtros de fecha y de otras categorías. Por qué las otras opciones son incorrectas b) Store the table in a Nearline storage class bucket. (Almacenar la tabla en una clase de almacenamiento Nearline) - Incorrecto ¿Qué es? Nearline es una clase de almacenamiento de bajo coste en Google Cloud Storage para datos a los que se accede con poca frecuencia. ¿Por qué es incorrecto? Este es un error conceptual común. Primero, esta opción aborda el coste de almacenamiento, no el coste y rendimiento de las consultas, que es el problema principal. Segundo, las tablas nativas de BigQuery no usan clases de almacenamiento de Cloud Storage; tienen su propio modelo de precios (almacenamiento activo y a largo plazo). Cambiar el almacenamiento no haría las consultas más rápidas ni baratas. d) Create a materialized view for every possible query. (Crear una vista materializada para cada consulta posible) - Incorrecto ¿Qué es? Una vista materializada pre-calcula y almacena el resultado de una consulta. Cuando se ejecuta una consulta que coincide con la vista, BigQuery lee los resultados pre-calculados en lugar de procesar la tabla original, lo cual es extremadamente rápido. ¿Por qué es incorrecto? Si bien las vistas materializadas son una herramienta de optimización muy potente, la estrategia de "crear una para cada consulta posible" es completamente inviable y una mala práctica. Coste: Generaría costes de almacenamiento masivos, ya que estarías duplicando datos en muchas formas diferentes. Mantenimiento: Sería una pesadilla de gestionar. Las vistas materializadas son para un conjunto pequeño y bien definido de consultas muy frecuentes y costosas, no para cubrir todos los casos de uso posibles. La partición y clusterización son optimizaciones mucho más generales y fundamentales.

Answer 724

B Slide 2 lists the three primary advantages of data engineering in the cloud as the ability to separate compute and storage, the use of serverless products, and not having to manage infrastructure. These benefits directly contribute to reducing operational overhead and allowing teams to focus on higher-value tasks like data analysis and insight generation.

Answer 725

B Slide 2 clearly states, "Data engineers build data pipelines," and "The ultimate purpose of a data pipeline is to enable stakeholders in an organization to use data to make faster and better decisions." This answer choice directly synthesizes these two key points. While a data engineer might interact with dashboarding or ML deployment, their core function is building the pipelines that make it all possible.

Answer 726

B The primary role of a data engineer is to build data pipelines, enabling stakeholders to use data for making faster and better decisions. While other tasks like managing infrastructure or creating dashboards may be part of their responsibilities, building data pipelines is the core function.

Answer 727

C One of the key advantages of cloud data engineering is eliminating the need to manage infrastructure. Instead, it offers benefits like separating compute and storage, using serverless products, and avoiding software management, allowing focus on data insights.

Answer 728

B A data lake is designed to store raw, unprocessed data, often in its original format, while a data warehouse stores transformed data structured for analytics, machine learning, and dashboards.

Answer 729

B BigQuery is Google Cloud's fully managed, serverless data warehouse solution, designed for petabyte-scale analytics, allowing efficient SQL queries on large datasets, making it the primary data warehouse option.

Answer 730

B ELT stands for Extract, Load, Transform, where data is extracted from the source, loaded into the data warehouse, and then transformed within it. This differs from ETL, where transformation occurs before loading.

Answer 731

B Batch pipelines are defined as processing a bounded amount of data and then exiting. For example, a batch pipeline might run once a day to balance books for daily transactions and then conclude its operation

Answer 732

B The sources explicitly state that you should use E-L only if the data is already clean and correct. This method is suitable for simple data import "as is".

Answer 733

B, C y D E-T-L is appropriate when transformations cannot be fully expressed in SQL or are too complex for SQL, such as calling external APIs for translation. It is also recommended when data loading needs to happen continuously (streaming), or when raw data needs quality control and transformations that are difficult to implement in SQL. Conversely, if transformations can be fully expressed in SQL, E-L-T with BigQuery is often sufficient

Answer 734

A, B, C y D BigQuery E-L-T can address duplicate records by counting unique records (e.g., using COUNT DISTINCT). It can handle invalid data by filtering it out using BigQuery views. For missing values, SQL functions like NULLIF, IFNULL, and COALESCE are available. Furthermore, uniformity issues related to data types and formats can be managed using SQL CAST() and FORMAT() functions.

Answer 735

C Data Catalog is described as a fully managed and highly scalable data discovery and metadata management service. It provides a unified view of data assets, supports structured business metadata tagging, and helps simplify data governance by integrating with services like Cloud Data Loss Prevention API

Answer 736

B EL pipelines are suitable when the incoming data is already clean and correct and doesn't require transformation before loading into BigQuery.

Answer 737

C ELT loads data directly into BigQuery, making the raw data immediately available for SQL-based transformations, which is ideal for experimental or flexible workflows.

Answer 738

A, B y D Dimensiones Correctas ✅ a) Accuracy (Exactitud) La exactitud se refiere a qué tan correctamente los datos reflejan el objeto o evento del mundo real que describen. Ejemplo: Si un cliente vive en la Calle Mayor 5, y en tu base de datos figura "Calle Mayor 5", el dato es exacto. Si figura "Calle Menor 8", es inexacto. b) Consistency (Consistencia) La consistencia garantiza que los datos no se contradigan entre sí en diferentes sistemas o bases de datos. Ejemplo: Si la fecha de nacimiento de un cliente es la misma en el sistema de ventas y en el sistema de marketing, los datos son consistentes. Si las fechas son diferentes, hay una inconsistencia. d) Validity (Validez) La validez (o conformidad) se asegura de que los datos sigan las reglas y formatos definidos por el negocio. Ejemplo: Si el campo de correo electrónico requiere un formato nombre@dominio.com, entonces juan@email.com es un dato válido, pero "Juan Pérez" no lo es. Dimensión Incorrecta ❌ c) Velocity (Velocidad) La velocidad no es una dimensión de la calidad de los datos. Es una de las "V's del Big Data" (Volumen, Velocidad y Variedad), que describe la rapidez con la que se generan y procesan los datos. Los datos pueden llegar muy rápido (alta velocidad) pero ser completamente incorrectos (baja calidad). La velocidad es una característica del flujo de datos, no de su fiabilidad intrínseca.

Answer 739

C Cloud Data Fusion allows visual (drag-and-drop) pipeline creation, ideal for non-technical users needing to create pipelines without code.

Answer 740

B ETL is preferred when data transformations are complex, involve external APIs, or require quality control before loading into the data warehouse.

Answer 741

C The EL (Extract and Load) method is appropriate when the data is already clean and correct, as it simply loads the data "as-is" into BigQuery without the need for transformation steps

Answer 742

A y B ELT is ideal when you don't know all the transformations needed upfront or when transformations can be performed using SQL in BigQuery. It is not suitable for complex transformations that cannot be done in SQL or when data is already clean (where EL would suffice)

Answer 743

A, B y C The main data quality dimensions are: - validity (conformance to business rules), - accuracy (conformance to objective truth), - consistency (absence of duplicates and concurrency issues). Redundancy is not listed as a primary data quality dimension in this context. Estas tres son dimensiones fundamentales de la calidad de los datos que se evalúan y corrigen en los pipelines. Dimensiones Correctas A) Validity (Validez) ✅ Se refiere a si los datos se ajustan a un formato, tipo o rango definido. Por ejemplo, un pipeline puede validar que una columna de fecha contenga fechas en formato AAAA-MM-DD y no texto aleatorio, o que un código postal tenga el número correcto de dígitos. B) Accuracy (Exactitud) ✅ Mide si los datos representan correctamente el objeto o evento del mundo real que describen. Por ejemplo, ¿la dirección almacenada para un cliente es realmente donde vive? Un pipeline puede verificar la exactitud cruzando los datos con una fuente de verdad (como un sistema de gestión de datos maestros). C) Consistency (Consistencia) ✅ Asegura que los datos no sean contradictorios entre sí, ya sea dentro del mismo conjunto de datos o a través de diferentes sistemas. Por ejemplo, si la edad de un usuario en una tabla es 30, pero su fecha de nacimiento en otra tabla implica que tiene 35, los datos son inconsistentes. Los pipelines de batch a menudo se encargan de reconciliar estas diferencias. Opción Incorrecta D) Redundancy (Redundancia) ❌ La redundancia se refiere a la duplicación innecesaria de datos en un sistema. Si bien la eliminación de la redundancia (un proceso llamado normalización o deduplicación) es un objetivo común en la ingeniería de datos, la redundancia en sí misma no es una dimensión de la calidad de un dato individual. Es un problema de la arquitectura o del modelo de datos, no una característica que mida si un dato es "bueno" o "malo".

Answer 744

B The COALESCE() function in SQL returns the first non-NULL value in the list, making it useful for replacing missing (NULL) values with a specified default.

Answer 745

A By comparing the result of COUNT(field) and COUNT(DISTINCT field), you can identify if there are duplicate values in the dataset. If the counts differ, duplicates exist

Answer 746

C Explicación: ¿Por qué la C es la correcta? Este enfoque, conocido como ELT (Extraer, Cargar, Transformar), es el patrón más moderno y eficiente para los almacenes de datos en la nube como BigQuery y se ajusta perfectamente a todos los requisitos del escenario. Extract-Load (EL): Primero, se cargan los datos brutos y sin procesar directamente desde Cloud Storage a una tabla de "staging" o "raw" en BigQuery. Este paso es extremadamente rápido y barato. Esto cumple con el requisito clave de mantener los datos brutos inalterados para fines de auditoría. Transform (T): En lugar de procesar los datos antes de cargarlos, la transformación se realiza dentro de BigQuery. Se crea una VIEW (Vista) sobre la tabla de datos brutos. La definición SQL de esta vista contiene toda la lógica de limpieza (filtrar negativos, eliminar duplicados, convertir tipos de datos). Este método es el mejor por varias razones: Cumple todos los requisitos: Los auditores pueden consultar la tabla "raw", mientras que los analistas de negocio consultan la VIEW y siempre ven los datos limpios y listos para usar. Eficiencia y Escalabilidad: Aprovecha la potencia del motor de BigQuery para realizar las transformaciones sobre la marcha. No necesitas un servicio de cómputo externo. Centralización: La lógica de negocio está definida en un solo lugar (la VIEW), garantizando que todos los analistas trabajen con los mismos datos consistentes. Flexibilidad: Si las reglas de limpieza cambian, solo necesitas actualizar la definición de la VIEW, sin tener que recargar o reprocesar los datos brutos. ¿Por qué las otras opciones son incorrectas? A) Usar un pipeline ETL con Dataflow Este es un patrón ETL (Extraer, Transformar, Cargar) clásico. El problema es que solo se carga el resultado transformado en BigQuery. Esto no cumple con el requisito de tener los datos brutos y sin alterar disponibles en BigQuery para la auditoría. ❌ B) Cargar los datos brutos y que los analistas los limpien Esto es ineficiente y propenso a errores. Obliga a cada analista a reescribir la misma lógica de limpieza en cada una de sus consultas. Esto lleva a resultados inconsistentes, duplica el trabajo y no proporciona el "conjunto de datos limpio y transformado" que se solicita. ❌ D) Usar Dataproc para ejecutar un trabajo de Spark Al igual que la opción A, este es un enfoque ETL. Aunque técnicamente es posible, es innecesariamente complejo y costoso para este caso de uso. Las transformaciones requeridas son operaciones SQL sencillas, y no justifican el levantamiento y la gestión de un clúster de Spark. El enfoque ELT nativo de BigQuery (opción C) es mucho más simple y rentable. ❌

Answer 747

C Dataproc is Google Cloud's managed service for Apache Hadoop and Apache Spark. It is specifically designed to allow customers to migrate existing Hadoop and Spark workloads to the cloud with little to no modification. This "lift-and-shift" capability makes it the perfect choice when the goal is to leverage existing Spark code and expertise, as stated in the scenario. Dataflow would require a complete rewrite of the jobs into the Apache Beam model.

Answer 748

B The key requirement is a transformation that involves calling an external API, which is a form of complex programmatic logic that cannot be done with standard SQL. This rules out ELT patterns where the transformation happens inside BigQuery (A). The correct pattern is ETL (Extract-Transform-Load), where the transformation happens in an intermediate service before the data is loaded into the target warehouse. Dataflow is the ideal Google Cloud service for this, as it allows for building custom data processing pipelines in languages like Python or Java, where making an external API call is straightforward.

Answer 749

D Data Catalog is Google Cloud's fully managed metadata management and data discovery service. Its core purpose, as described in the slides (pages 29-30), is to provide a unified view and search experience for data assets across Google Cloud (including BigQuery, Spanner, and Cloud Storage). It automatically ingests technical metadata and allows users to add rich business metadata (tags), creating a centralized, searchable catalog that is essential for data governance and discovery in a large organization. BigQuery Labels (C) are a mechanism for organizing resources and can be a source of metadata for Data Catalog, but they are not the centralized discovery service itself.

Answer 750

B Batch data pipelines handle bounded datasets, meaning they process a specific amount of data (e.g., daily transactions) at scheduled times and then exit until the next run, distinguishing them from streaming pipelines.

Answer 751

C ELT is ideal when transformations can be handled within the target system, such as BigQuery, using SQL, making it suitable for experimental datasets or when transformations are not yet fully defined, allowing for flexibility.

Answer 752

C The key dimensions of data quality are Validity, Accuracy, Completeness, Consistency, and Uniformity. Velocity, while relevant in big data contexts for data speed, is not a data quality dimension.

Answer 753

B Dataflow, a fully managed service for batch and streaming data processing, is ideal for complex ETL pipelines, supporting Apache Beam for non-SQL transformations and integration with various data sources, unlike BigQuery, which is better for SQL-based tasks.

Answer 754

B OJO !!! no caigamos en la trampa, porque aunque el proceso es mas un ETL que un ELT, hay qeu fijarse que la afirmacion para decir que no se puede la C es que es demasiado complejo para hacerlo en SQL, lo cual no es cierto. La respuesta B es el enfoque correcto por las siguientes razones: Aprovecha la potencia de BigQuery: El patrón ELT (Extraer, Cargar, Transformar) consiste en cargar primero los datos en bruto (o casi en bruto) en el data warehouse (en este caso, BigQuery) y luego usar la potencia de procesamiento del propio warehouse para transformarlos. BigQuery es un motor de análisis masivamente paralelo, perfecto para ejecutar transformaciones SQL a gran escala. Transformaciones Sencillas: Las transformaciones requeridas —eliminar duplicados y filtrar valores— son operaciones que se realizan de forma muy sencilla y eficiente con el lenguaje SQL. Por ejemplo: Eliminar duplicados: Se puede hacer con SELECT DISTINCT o con funciones de ventana como ROW_NUMBER(). Asegurar valores positivos: Se logra con una simple cláusula WHERE sales_amount > 0. Eficiencia y Simplicidad: Este enfoque es moderno y eficiente. Evita la necesidad de un sistema de procesamiento intermedio (como Dataflow o Dataproc) para realizar transformaciones sencillas, lo que simplifica la arquitectura y reduce los costes. ¿Por qué las otras opciones son incorrectas? A) EL (Extract, Load): Esta opción es incorrecta porque su justificación ("los datos ya están limpios") contradice directamente los requisitos del problema. El enunciado deja claro que los datos deben ser limpiados, por lo que un simple proceso de extracción y carga (EL) no es suficiente. C) ETL (Extract, Transform, Load): Aunque ETL es un patrón válido, la justificación que se da es incorrecta. Afirma que las transformaciones son "demasiado complejas para SQL", lo cual es falso. Como vimos, las limpiezas requeridas son básicas en SQL. Usar un sistema ETL tradicional para esto sería innecesariamente complejo y costoso en comparación con ELT dentro de BigQuery. D) Streaming: Esta opción es incorrecta porque el caso de uso no lo requiere. El problema habla de "transacciones diarias" para "reporting", lo que indica claramente un proceso batch (por lotes) y no una necesidad de procesamiento en tiempo real. Implementar una arquitectura de streaming sería sobredimensionar la solución, haciéndola más compleja y cara sin aportar valor.

Answer 755

A, B y C En resumen, las respuestas correctas son A, B y C. La clave es entender que Dataproc es un servicio gestionado y en la nube, mientras que una solución local (on-premises) es manual y limitada por el hardware físico que poseas. Opción A: Managed hardware and configuration (Hardware y configuración gestionados) - ✅ Respuesta Correcta Esta opción es correcta porque es una de las ventajas fundamentales de cualquier servicio en la nube como Dataproc. En Dataproc (Nube): No tienes que comprar, instalar ni mantener servidores físicos. Google Cloud se encarga de toda la infraestructura. Simplemente pides un clúster con las especificaciones que necesitas (ej. "quiero 10 máquinas de este tipo") y Dataproc lo crea por ti en minutos. La configuración base del software (Hadoop, Spark) también viene preinstalada y optimizada. En una solución local (On-Premises): Eres tú el responsable de comprar los servidores, montarlos en un centro de datos, instalar el sistema operativo, configurar las redes y luego instalar y configurar manualmente todo el ecosistema Hadoop. Es un proceso largo, costoso y complejo. Opción B: Capacity limits are easily overcome (Los límites de capacidad se superan fácilmente) - ✅ Respuesta Correcta Esta opción es correcta por la elasticidad inherente de la nube. En Dataproc (Nube): Si tu clúster se queda pequeño o necesitas más potencia para un trabajo específico, puedes redimensionarlo o crear uno nuevo más grande en cuestión de minutos. Pagas solo por la capacidad que usas y cuando la usas. Esto te permite adaptarte a picos de demanda sin esfuerzo. En una solución local (On-Premises): Si te quedas sin capacidad, el proceso es muy lento y caro. Tienes que comprar más hardware, esperar a que llegue, instalarlo y configurarlo. Esto puede tardar semanas o meses. Opción C: Simplified version management for open-source tools (Gestión simplificada de versiones de herramientas de código abierto) - ✅ Respuesta Correcta Esta opción es correcta porque Dataproc resuelve uno de los mayores quebraderos de cabeza de Hadoop: la compatibilidad entre herramientas. En Dataproc (Nube): Dataproc ofrece versiones de imagen (ej. Dataproc 2.0, 2.1). Cada imagen es un paquete que contiene versiones de Spark, Hive, etc., que han sido probadas por Google para garantizar que son compatibles entre sí. Tú solo eliges la imagen y todo funciona sin problemas. En una solución local (On-Premises): Eres tú quien debe buscar, descargar e instalar cada herramienta por separado, asegurándote de que la versión de Spark que instalas es compatible con la versión de Hadoop, y esta con la de Hive, etc. Es un problema muy común conocido como "el infierno de las dependencias" (dependency hell). Opción D: Lack of separation between storage and compute resources (Falta de separación entre los recursos de almacenamiento y de cómputo) - ❌ Respuesta Incorrecta Esta opción es incorrecta porque describe justamente lo contrario a la realidad y a una de las mayores ventajas de Dataproc. En Dataproc (Nube): Existe una separación total entre el cómputo y el almacenamiento. El cómputo lo realiza el clúster de Dataproc (que puedes encender y apagar), mientras que los datos se guardan de forma persistente y barata en Google Cloud Storage (GCS). Esto te permite apagar el clúster (que es caro) cuando no lo usas, sin perder tus datos, lo que supone un ahorro de costes gigantesco. En una solución local (On-Premises): Tradicionalmente, el cómputo y el almacenamiento están fuertemente acoplados. Los datos se guardan en el HDFS (Hadoop Distributed File System), que se ejecuta en los mismos nodos que realizan el procesamiento. Esto te obliga a mantener todo el clúster encendido siempre, aunque no estés procesando nada, solo para mantener los datos disponibles. Esta falta de separación es una de las grandes desventajas del modelo tradicional.

Answer 756

B It is a best practice to use storage that is off-cluster by connecting to other Google Cloud products like Cloud Storage, because HDFS storage on the cluster would disappear when clusters are turned down. Cloud Storage is recommended as the persistent data store because it is Hadoop compatible, requires less maintenance, is considerably less expensive, and is often faster than HDFS due to separation of compute and storage. While Bigtable can store large amounts of sparse data and BigQuery is for data warehousing, Cloud Storage is specifically highlighted as the primary way to store unstructured data and a drop-in replacement for HDFS

Answer 757

B The ephemeral model is the recommended approach for Dataproc, where clusters are spun up when needed to run a job and then deleted when the job completes. This ensures that resources are active only when being used, leading to cost reduction and allowing for tailoring cluster configurations to individual jobs. While autoscaling helps with resource utilization, it is not designed to scale a cluster down to zero when idle; for idle clusters, scheduled deletion or recreating the cluster via workflows is recommended. The ephemeral model also requires storage to be decoupled from compute, meaning it generally does not rely solely on local HDFS

Answer 758

C ✅ Escenario NO Recomendado C. Un clúster que depende en gran medida de HDFS en el clúster para los datos persistentes. Este es el principal escenario donde el ajuste de escala automático de Dataproc NO se recomienda y puede ser peligroso. El motivo es simple: el ajuste de escala automático funciona añadiendo y, lo que es más importante, eliminando nodos de trabajo (workers) para ahorrar costes cuando la carga disminuye. Cuando un nodo de trabajo se elimina, todos los datos almacenados en su HDFS local se pierden permanentemente. Si tu trabajo depende de esos datos para persistir entre etapas o para otros trabajos, la eliminación del nodo causará la pérdida de datos y el fallo del trabajo. Por esta razón, la práctica recomendada por Google es usar siempre Google Cloud Storage (GCS) como sistema de archivos persistente en clústeres con ajuste de escala automático, ya que el almacenamiento está desacoplado de los nodos de cómputo. ❌ Escenarios Recomendados Las otras tres opciones describen situaciones en las que el ajuste de escala automático SÍ es útil y recomendado: A) Un clúster que procesa un único trabajo grande: Es útil si el trabajo tiene fases con necesidades de recursos muy diferentes. B) Un clúster que procesa muchos trabajos: Es ideal para clústeres compartidos y de larga duración donde la carga de trabajo es impredecible. D) Un clúster con necesidades de capacidad flexibles: Esta es la definición misma del problema que el ajuste de escala automático está diseñado para resolver.

Answer 759

C Apache Spark is highlighted as an open-source software project that provides a high-performance analytics engine for processing batch and streaming data, and it can be up to 100 times faster than equivalent Hadoop jobs because it leverages in-memory processing. While Hadoop MapReduce might require tuning, Spark is able to mix different applications and adjust resource usage, and it uses a declarative programming model. Spark provides a full SQL implementation but also offers other data handling mechanisms like Resilient Distributed Datasets, Dataframes, and a distributed machine learning library (Spark ML-Lib)

Answer 760

B Cloud Storage allows for separation of storage and compute, reducing disk costs and enabling ephemeral clusters. HDFS, by contrast, requires storage and compute to be coupled.

Answer 761

A y D A. It uses Hadoop YARN metrics to determine when to scale (Usa métricas de Hadoop YARN para determinar cuándo escalar) Esta afirmación es CORRECTA. Por qué es correcta: El servicio de autoescalado de Dataproc está diseñado para funcionar de manera inteligente basándose en la carga de trabajo real del clúster. Para ello, monitoriza las métricas del gestor de recursos del clúster, que es Hadoop YARN (Yet Another Resource Negotiator). YARN es el cerebro que asigna recursos (CPU, memoria) a las tareas que se ejecutan en el clúster (como trabajos de Spark o MapReduce). El autoescalado observa métricas clave de YARN como: $YARNMemoryPendingMB$: La cantidad de memoria que las aplicaciones han solicitado pero que aún no se les ha podido asignar porque el clúster está al máximo de su capacidad. Un valor alto aquí es la señal principal para añadir más nodos (escalar hacia arriba). $YARNMemoryAvailableMB$: La cantidad de memoria que está libre en el clúster. Si hay mucha memoria libre durante un período prolongado, es una señal para quitar nodos (escalar hacia abajo) y ahorrar costos. D. It adjusts the number of worker nodes based on pending memory needs (Ajusta el número de nodos de trabajo basándose en las necesidades de memoria pendientes) Esta afirmación es CORRECTA. Por qué es correcta: Esta opción es una consecuencia directa y más específica de la opción A. El principal indicador que utiliza el autoescalado para decidir si necesita añadir más nodos (escalar hacia arriba o scale-up) es la "memoria pendiente" (pending memory). El flujo es el siguiente: Se envía un trabajo grande al clúster (por ejemplo, un trabajo de Spark). El trabajo solicita más memoria de la que está disponible actualmente en los nodos de trabajo. YARN registra esta demanda insatisfecha como "memoria pendiente" (la métrica $YARNMemoryPendingMB$). La política de autoescalado de Dataproc detecta que hay memoria pendiente y, para satisfacer esa demanda, añade nuevos nodos de trabajo al clúster. B. It supports Spark Structured Streaming (Es compatible con Spark Structured Streaming) Esta afirmación es INCORRECTA. Por qué es incorrecta: El autoescalado está optimizado para cargas de trabajo por lotes (batch workloads), que tienen un principio y un fin claros. Estas cargas suelen tener picos de demanda (necesitan muchos recursos al principio) y valles (liberan los recursos al terminar). Las cargas de trabajo de streaming, como Spark Structured Streaming, son procesos de larga duración que procesan datos continuamente. Estos trabajos suelen ser sensibles a la eliminación de nodos. Si el autoescalado decide quitar un nodo (scale-down) que está procesando activamente datos de un stream, podría provocar la pérdida de estado (state), la interrupción del procesamiento y el fallo del trabajo. Por este motivo, la documentación oficial de Google Cloud desaconseja explícitamente el uso del autoescalado en clústeres que ejecutan trabajos de streaming. C. It can scale clusters to zero nodes (Puede escalar clústeres a cero nodos) Esta afirmación es INCORRECTA. Por qué es incorrecta: Un clúster de Dataproc tiene una arquitectura con nodos maestros (master nodes) y nodos de trabajo (worker nodes). Los nodos maestros coordinan el clúster y ejecutan servicios críticos como HDFS NameNode y YARN ResourceManager. Los nodos de trabajo son los que ejecutan las tareas de procesamiento de datos. El autoescalado de Dataproc solo ajusta el número de nodos de trabajo. Un clúster siempre debe tener al menos un nodo maestro para existir y funcionar. Además, la configuración de autoescalado te obliga a definir un número mínimo de nodos de trabajo primarios (por defecto, minInstances = 2), por lo que ni siquiera los nodos de trabajo pueden escalar a cero. La idea de "escalar a cero" es propia de servicios serverless (como Cloud Functions o Cloud Run), pero no de un servicio de infraestructura de clúster como Dataproc, que necesita mantener una estructura mínima para estar operativo.

Answer 762

C Ephemeral clusters are created and deleted around jobs, ensuring you only pay for what you use, thus minimizing cost and overhead.

Answer 763

C Cloud Storage is optimized for bulk parallel reads and writes but does not support append operations and has higher latency than HDFS for fine-grained I/O. Es la que describe las desventajas fundamentales de un sistema de almacenamiento de objetos (Cloud Storage) frente a un sistema de archivos distribuido (HDFS) para este caso de uso específico. ✅ Opción C: Tiene una latencia alta y no admite operaciones de anexo (append). Esta es la respuesta correcta porque apunta a dos diferencias clave en la arquitectura de ambos sistemas. Para entenderlo, piensa en la diferencia entre el disco duro de tu ordenador (HDFS) y un servicio como Google Drive o Dropbox (Cloud Storage). "Tiene una latencia alta" (High Latency): HDFS está diseñado para ejecutarse en las mismas máquinas que realizan el cómputo. Cuando un proceso de Spark necesita datos intermedios, a menudo los lee desde un disco local, lo cual es muy rápido (baja latencia). Cloud Storage es un servicio desacoplado. Para acceder a los datos, el proceso de Spark debe hacer una petición a través de la red. Aunque la red de Google es rapidísima, siempre hay un pequeño retardo (latencia) en cada operación. Para los datos intermedios, que a menudo implican miles de pequeñas lecturas y escrituras, esta latencia se suma y puede ralentizar el trabajo general. "No admite operaciones de anexo" (Doesn't support append): En HDFS, que funciona como un sistema de archivos tradicional, puedes abrir un fichero y añadir datos al final (append). En Cloud Storage, los objetos son inmutables. Esto significa que no puedes modificar un fichero existente. Para añadir datos, tienes que leer el objeto completo, añadir los datos nuevos en la memoria y luego volver a escribir el objeto entero, sobrescribiendo el original. Esto es muy ineficiente para operaciones que necesitan añadir datos de forma incremental. Estas dos características (mayor latencia y falta de append) son las principales desventajas de usar Cloud Storage para datos intermedios muy volátiles, como los que se generan en un "shuffle" de Spark. ❌ Opciones incorrectas A. No se puede usar con Spark. Esto es totalmente falso. Usar Spark con Cloud Storage es uno de los patrones de diseño más comunes y recomendados en Google Cloud, especialmente a través de servicios como Dataproc. B. No admite operaciones de metadatos. Esto es falso. Cloud Storage sí admite operaciones de metadatos (listar, borrar, etc.). Es cierto que algunas operaciones, como renombrar un directorio, son más lentas en Cloud Storage que en HDFS porque implican copiar y borrar en lugar de ser un simple cambio de puntero, pero la afirmación de que "no las admite" es incorrecta. D. Requiere Hadoop DistCp. Esto es falso. DistCp es una herramienta para copiar grandes cantidades de datos (por ejemplo, para migrar de HDFS a Cloud Storage). No es un requisito para que Spark lea o escriba en Cloud Storage durante la ejecución de un trabajo; para eso, Spark utiliza su propio conector nativo.

Answer 764

A, C y D Jobs can be submitted using the gcloud CLI, Workflow Templates, or orchestration tools like Cloud Composer. Submitting directly to Hadoop is discouraged since it bypasses Dataproc’s metadata and monitoring systems.

Answer 765

C Dataproc provides managed hardware and configuration, which means users do not need to worry about physical hardware or manual setup. This simplifies cluster management compared to on-premises Hadoop solutions

Answer 766

B When using Cloud Storage, data persists independently of the Dataproc cluster lifecycle. If you use HDFS and delete the cluster, the data is lost, but with Cloud Storage, your data remains available

Answer 767

B Por qué la opción B es la correcta BigQuery no es un "componente opcional" que se instala en los nodos de un clúster de Dataproc. BigQuery es un servicio de almacén de datos (data warehouse) totalmente gestionado y serverless (sin servidor) que existe por separado en Google Cloud. Un clúster de Dataproc (que es un servicio de IaaS/PaaS para Spark y Hadoop) interactúa con BigQuery: lee datos de él y escribe datos en él. El software necesario para esta interacción (el "conector de BigQuery") ya viene incluido por defecto en las imágenes estándar de Dataproc, no es un componente opcional que debas añadir. Por qué las otras opciones son incorrectas Las otras tres opciones son ejemplos perfectos de los componentes opcionales que Dataproc te permite instalar en las máquinas virtuales (nodos) del clúster en el momento de la creación: A. Anaconda: Es una distribución popular de Python para ciencia de datos. Puedes añadirla como componente opcional para gestionar tus entornos y paquetes de PySpark. C. Zeppelin: Es un servicio de notebook (cuaderno web) interactivo, similar a Jupyter. Puedes instalarlo como componente opcional para tener una interfaz de análisis directamente en el clúster. D. Cloud SQL Proxy: Es una utilidad que permite al clúster conectarse de forma segura a bases de datos gestionadas en Cloud SQL (MySQL, Postgres, etc.). Se puede añadir como componente opcional.

Answer 768

B Dataproc separates storage and compute resources, allowing for greater scalability and flexibility. On-premises Hadoop clusters typically have storage and compute tightly coupled, limiting scalability

Answer 769

B Apache Spark uses in-memory processing, which can make it up to 100 times faster than equivalent Hadoop MapReduce jobs. It also supports both batch and streaming data processing, and provides a full SQL implementation

Answer 770

C The "ephemeral model" (Slide 45, 47) is the most cost-effective and recommended approach for batch jobs. By decoupling storage from compute (using Cloud Storage instead of HDFS, as per Slide 28), you can create a cluster only for the duration of the job and delete it afterward, ensuring you don't pay for idle compute. Dataproc Workflow Templates (Slide 49) are designed to orchestrate this exact pattern. Autoscaling (B) is not designed to scale to zero, and a persistent cluster (A, D) incurs costs even when idle.

Answer 771

B y E Explanation: B: The standard architecture for mixing compute types on Dataproc involves using standard VMs for primary and some worker nodes, and adding low-cost Secondary Workers that are configured as Preemptible VMs (Slide 14). E: Initialization actions are the standard, repeatable, and scalable method for customizing cluster software at startup, such as installing libraries or modifying configuration files (Slide 13). While a custom image (C) is also a valid method, initialization actions are often more flexible for managing dependencies. Manually installing (A) or using a Spark job (D) are inefficient and not best practices.

Answer 772

C Explicación Principal: La Solución Correcta (C) El problema fundamental es la diferencia de diseño entre HDFS y Cloud Storage (GCS): HDFS es un sistema de archivos distribuido. Operaciones como renombrar un directorio o añadir contenido a un archivo existente (append) son operaciones de metadatos muy rápidas. Cloud Storage es un almacén de objetos. Los objetos son inmutables. Renombrar un "directorio" en GCS no es una operación simple. Implica copiar cada uno de los objetos bajo el prefijo antiguo a un nuevo nombre y luego borrar los originales. Para directorios grandes, esto es extremadamente lento. Hacer "append" a un archivo en GCS implica leer el objeto completo, añadir el nuevo contenido y reescribir el objeto entero como uno nuevo. Esto también es mucho menos eficiente que un append nativo de HDFS. La estrategia C resuelve esto perfectamente: Lee los datos iniciales de GCS, que es ideal para almacenar datos de entrada a gran escala. Usa el HDFS local del clúster de Dataproc para todo el procesamiento intermedio. Como HDFS sí está optimizado para renombrados y appends rápidos, el rendimiento del trabajo será similar al que tenía en el entorno on-premise. Escribe el resultado final de vuelta a GCS, que es el lugar perfecto para el almacenamiento duradero y el acceso por parte de otros servicios en la nube. Este es un patrón de diseño clásico y recomendado para migrar trabajos de Spark/Hadoop a Dataproc que no fueron diseñados originalmente para un almacén de objetos. ¿Por Qué las Otras Opciones No Son las Mejores? A. Aumentar fs.gs.block.size: Esta propiedad optimiza el rendimiento de la lectura de archivos grandes, pero no tiene ningún efecto sobre la lentitud de las operaciones de renombrado o append, que son el verdadero cuello de botella aquí. B. Cambiar a discos SSD: Los SSD aceleran las operaciones de E/S en los nodos locales del clúster (por ejemplo, para shuffling de datos). Sin embargo, el problema de rendimiento no está en los discos locales, sino en las operaciones que el trabajo está intentando realizar contra el servicio de Cloud Storage. Discos locales más rápidos no harán que GCS renombre objetos más deprisa. D. Mover el bucket a la misma multirregión: Aunque tener el clúster y el bucket en la misma región es una buena práctica para reducir la latencia de red, no resuelve el problema fundamental. La lentitud no se debe principalmente a la latencia, sino a la naturaleza de las operaciones mismas. Incluso con latencia cero, copiar y reescribir terabytes de datos para un "renombrado" seguiría siendo un proceso muy lento.

Answer 773

C La opción C es correcta porque describe una característica fundamental y real del autoescalado de Dataproc: el Desmantelamiento Elegante (Graceful Decommissioning). Cuando el autoescalado decide reducir el tamaño del clúster (hacer un scale-down), no apaga los nodos worker de forma abrupta. En su lugar: Le notifica al gestor de recursos YARN que deje de asignar nuevas tareas al nodo que se va a eliminar. Espera un tiempo configurable, definido por el parámetro graceful_decommission_timeout. Durante este período, las tareas que ya estaban en ejecución en ese nodo tienen la oportunidad de terminar su trabajo. Esto es crucial para evitar que los trabajos fallen y se pierda el cómputo realizado, garantizando una reducción de escala suave y sin interrupciones. ❌ Explicación de las Respuestas Incorrectas A. El autoescalado se basa en la utilización de la CPU. Incorrecto. La métrica principal que usa el autoescalado de Dataproc no es la CPU, sino la memoria pendiente de YARN (yarn.nodemanager.pending-memory-mb). Esta métrica indica cuánta memoria han solicitado los trabajos y todavía no se les ha podido asignar. Es un indicador mucho más fiable de la carga real y la demanda de recursos del clúster que el simple uso de CPU. B. La política puede escalar el clúster a cero nodos worker. Incorrecto. Un clúster de Dataproc estándar requiere un mínimo de dos nodos worker para funcionar correctamente, principalmente para garantizar la replicación y disponibilidad de HDFS. No se puede configurar una política de autoescalado para que reduzca el número de workers a cero. Para un modelo de "escalado a cero", la solución adecuada sería usar Dataproc Serverless o crear clústeres efímeros que se eliminan por completo al finalizar los trabajos. D. El autoescalado es más efectivo si los datos están en el HDFS local del clúster. Incorrecto. Esta afirmación es exactamente lo opuesto a la buena práctica. El autoescalado es mucho más efectivo y seguro cuando se desacopla el cómputo del almacenamiento. La arquitectura recomendada es almacenar los datos en Google Cloud Storage (GCS) y usar los nodos de Dataproc solo para procesarlos. De esta manera, los nodos son "desechables": se pueden añadir o quitar sin riesgo de perder datos. Si los datos estuvieran en HDFS, eliminar un nodo durante un scale-down podría causar la pérdida de esos datos, haciendo el proceso lento y peligroso.

Answer 774

B Dataproc is configured by default to aggregate YARN logs and send them to Cloud Logging. This provides a centralized, consolidated, and searchable location to view both the driver output and logs from all Spark executors without needing to SSH into nodes or browse multiple UI tabs (Slide 59). This is far more efficient than manually inspecting individual files on the cluster (A), browsing the UI (C), or implementing custom logging (D).

Answer 775

C Google Cloud Storage is more cost-efficient, scalable, and durable than HDFS, making it ideal for Dataproc data storage, as it separates storage from compute resources for better flexibility.

Answer 776

B Keeping data and clusters in the same region or zone minimizes data transfer, improving performance and reducing costs, which is a key optimization strategy for Dataproc.

Answer 777

C ✅ Respuesta Correcta C) Ofrece un rendimiento hasta 100 veces más rápido que los trabajos de Hadoop 🚀 Explicación: Este es el beneficio fundamental y la principal razón por la que Apache Spark se popularizó y superó al modelo tradicional de Hadoop MapReduce. La gran innovación de Spark fue su capacidad para procesar datos en memoria (in-memory). Mientras que un trabajo de Hadoop MapReduce tradicional escribía los resultados intermedios en el disco (HDFS), lo que es muy lento, Spark mantiene esos datos intermedios en la memoria RAM de los nodos del clúster. Esto reduce drásticamente la latencia y permite un rendimiento muchísimo mayor, especialmente para algoritmos iterativos (como en machine learning) y consultas interactivas. La cifra "100x" proviene de los benchmarks originales que comparaban ambas tecnologías. ❌ Respuestas Incorrectas A) Proporciona una interfaz SQL para la consulta de datos. Por qué es incorrecta: Aunque es cierto que Spark ofrece una potente interfaz SQL a través de su componente Spark SQL, no es su beneficio principal o fundacional. De hecho, la capacidad de ejecutar consultas SQL de forma rápida e interactiva es una consecuencia del gran rendimiento que se consigue con el procesamiento en memoria (opción C). Es un beneficio muy importante, pero secundario al de la velocidad. B) Permite el procesamiento de datos en tiempo real. Por qué es incorrecta: Al igual que la opción A, esto es cierto. Spark, a través de Spark Streaming y Structured Streaming, permite el procesamiento de flujos de datos en "micro-lotes", lo que se aproxima mucho al tiempo real. Sin embargo, esta capacidad también se ve potenciada por el motor de procesamiento rápido en memoria (opción C). Es una funcionalidad clave, pero no el beneficio primario que define la arquitectura de Spark. D) Soporta únicamente el procesamiento por lotes (batch). Por qué es incorrecta: Esta afirmación es rotundamente falsa. Como se mencionó en el punto anterior, Spark tiene componentes específicos (Spark Streaming y Structured Streaming) diseñados explícitamente para el procesamiento de flujos de datos (streaming), que es lo contrario al procesamiento exclusivo por lotes.

Answer 778

D ✅ Explicación de cada método Cada una de las opciones describe una forma válida y común de enviar trabajos a un clúster de Dataproc. A. Google Cloud Console Esta es la interfaz gráfica web de Google Cloud. Es la forma más visual e intuitiva de enviar un trabajo. Es ideal para usuarios que están empezando, para realizar pruebas rápidas o para quienes prefieren no usar la línea de comandos. Simplemente navegas a la sección de Dataproc, seleccionas tu clúster y llenas un formulario para enviar tu trabajo. B. Via the gcloud command-line tool gcloud es la herramienta de línea de comandos de Google Cloud. Es la preferida por desarrolladores y administradores de sistemas para automatizar tareas. Puedes enviar trabajos fácilmente usando comandos en un script, lo que es perfecto para flujos de trabajo de integración continua o procesos programados. El comando típico es gcloud dataproc jobs submit spark .... C. Using the Dataproc REST API Esta es la forma más programática de interactuar con el servicio. Permite a los desarrolladores integrar la funcionalidad de Dataproc directamente en sus propias aplicaciones. Usando librerías cliente en lenguajes como Python, Java o Go, puedes crear, gestionar y enviar trabajos a clústeres de forma completamente automatizada desde tu propio código.

Answer 779

A Cloud Storage does not allow appending to objects, unlike HDFS, which is an important consideration when designing data pipelines for Dataproc.

Answer 780

C Dataflow is recommended for new data processing pipelines and for unified batch and streaming processing, allowing the same code for both. A key advantage is its serverless nature, which means you don't have to manage clusters. Dataproc, on the other hand, is generally suggested for migrating existing Hadoop/Spark applications or when a DevOps approach to cluster management is preferred.

Answer 781

C ✅ Opción C: La Respuesta Correcta C) A distributed data abstraction that holds the data to be processed, which is immutable. (Una abstracción de datos distribuida que contiene los datos a procesar, la cual es inmutable.) Esta es la definición perfecta de una PCollection. Vamos a desglosarla: Abstracción de datos distribuida: En el mundo del Big Data, no trabajas con un simple array en la memoria de un solo ordenador. Tus datos pueden ser enormes (terabytes o petabytes) y estar repartidos en múltiples máquinas. Una PCollection es una abstracción que te permite tratar ese conjunto de datos masivo y distribuido como si fuera una única colección. Apache Beam y su runner (como Dataflow) se encargan por debajo de gestionar la distribución y el paralelismo. Contiene los datos a procesar: Es el objeto fundamental que lleva los datos a través de las distintas etapas de tu pipeline. Cada paso de tu proceso recibe una PCollection como entrada y produce una nueva PCollection como salida. Inmutable: Este es un concepto clave. Nunca modificas una PCollection existente. Cuando aplicas una transformación (por ejemplo, filtrar datos), no cambias la colección original. En su lugar, se crea una nueva PCollection con el resultado de la transformación. Esta inmutabilidad es crucial para que el sistema pueda procesar los datos en paralelo y recuperarse de fallos de forma segura. En resumen, una PCollection es el "qué" de tu pipeline: qué datos estás procesando. ❌ ¿Por Qué las Otras Opciones son Incorrectas? A) An abstraction for the actions or code that transforms data... Esto no describe una PCollection, sino una PTransform (Transformación). Las PTransform son las operaciones o los pasos que aplicas a una PCollection para procesar sus datos. Por ejemplo, Map, Filter, GroupByKey son PTransforms. PCollection: Los datos (el sustantivo). PTransform: La acción sobre los datos (el verbo). B) The backend system or service responsible for executing the pipeline on a given runner. Esto describe al Runner. El Runner es el motor de ejecución que toma tu pipeline de Beam y lo traduce a las APIs del sistema de procesamiento que elijas. Por ejemplo: Dataflow Runner: Ejecuta el pipeline en Google Cloud Dataflow. Spark Runner: Ejecuta el pipeline en un clúster de Apache Spark. Flink Runner: Ejecuta el pipeline en un clúster de Apache Flink. Direct Runner: Ejecuta el pipeline localmente en tu máquina, ideal para pruebas. El Runner es el "dónde" se ejecuta tu pipeline. D) A mutable, in-memory data structure that allows direct element modification... Esta opción es incorrecta por dos razones fundamentales: Es mutable: Como ya hemos visto, las PCollections son inmutables. Es in-memory (en memoria): Una PCollection representa datos que pueden ser demasiado grandes para caber en la memoria de una sola máquina. Están diseñadas para datos out-of-memory (que residen en disco) y distribuidos. Esta descripción se parece más a una estructura de datos estándar como una lista o un array en un lenguaje de programación tradicional, no a una abstracción para Big Data.

Answer 782

C Dataflow is highly valued for its scalability, automatically scaling out to more machines to process more data. Its stream processing capabilities enable low latency. A unique strength is the ability to use the same code for both batch and streaming pipelines. Dataflow also features adaptive auto-scaling (transform-by-transform) and dynamic work rebalancing mid-job to optimize efficiency

Answer 783

C ¿Por qué la opción C es la correcta? ✅ Para entender por qué, veamos cómo funciona cada una. Imagina que quieres contar las visitas a una página web por cada país. Cómo funciona GroupByKey GroupByKey es una operación "ingenua". Para contar las visitas de "España", debe agrupar todas y cada una de las entradas de "España" en un solo worker (un servidor). Para ello, baraja (shuffles) cada una de esas entradas a través de la red hasta llegar a ese único worker, que luego las cuenta una por una. Problema (Data Skew): Si un país ("España") tiene mil millones de visitas (una "hot key" o clave con sesgo) y otro ("Andorra") tiene mil, el worker asignado a "España" se verá abrumado, se convertirá en un cuello de botella y ralentizará toda la canalización, mientras que el worker de "Andorra" terminará rápidamente. Cómo funciona Combine (la forma inteligente) Combine es una optimización para operaciones que son asociativas y conmutativas (como sumar, contar, promediar, etc.). Funciona en varias fases: Pre-agregación local: Cada worker que tiene entradas para "España" las cuenta localmente primero. El Worker A podría contar 50 millones de visitas, el Worker B 120 millones, y el Worker C 80 millones. Barajado (Shuffle): Ahora, en lugar de enviar mil millones de entradas individuales a través de la red, cada worker envía solo un resultado parcial: (España, 50M), (España, 120M), (España, 80M). La cantidad de datos transferidos es drásticamente menor. Agregación final: Un único worker final recibe estos pocos resultados parciales y los combina (los suma) para obtener el total. Este proceso distribuye y paraleliza la agregación, evitando que un solo worker se sobrecargue. Por eso es mucho más eficiente y escalable, especialmente con datos sesgados. Analogía simple: GroupByKey es como si para contar los votos de un país, cada papeleta individual tuviera que ser enviada a la capital. La oficina central se colapsaría. Combine es como si cada ciudad contara sus propios votos primero y luego solo enviara el total a la capital. El trabajo en la capital sería trivial. ¿Por qué las otras opciones son incorrectas? ❌ A) GroupByKey is designed to distribute a single key's values across multiple workers, while Combine processes all values for a key on one worker. Esto es exactamente lo contrario de la realidad. GroupByKey centraliza todos los valores de una clave en un solo worker, mientras que Combine distribuye el trabajo entre muchos. B) Combine forces all values for a given key to be shuffled over the network, increasing overhead. Nuevamente, esto es lo opuesto. Combine reduce drásticamente la cantidad de datos que se barajan en la red al enviar solo resultados parciales. Es GroupByKey la que fuerza el barajado de todos los valores individuales. D) GroupByKey automatically handles late-arriving data, a feature not natively supported by Combine. Esto es incorrecto. El manejo de datos tardíos en Dataflow es una función de la configuración del windowing (ventanas de tiempo) y los triggers, no de la transformación de agregación en sí. Tanto GroupByKey como Combine pueden operar con datos tardíos si la ventana está configurada para permitirlos (withAllowedLateness).

Answer 784

C Dataflow templates facilitate the rapid deployment of standard data transformation jobs, removing the need for users to write pipeline code or manage dependencies. They are crucial for separating developers from users, allowing non-developer users (like analysts, app developers, DB admins) to execute jobs via the UI, command line, or API without needing to recompile or have a development environment setup. This separation also aids in scheduling and automation. Customization is still possible through ValueProviders for runtime parameters.

Answer 785

A, C y D Dataflow is a serverless service that supports both batch and streaming with the same code. It also offers fine-grained, step-by-step auto-scaling. Unlike Dataproc, it does not require manual provisioning of clusters.

Answer 786

B A PCollection is an immutable distributed collection used in Beam to represent data for batch or stream processing.

Answer 787

B El problema principal de GroupByKey en conjuntos de datos con una distribución muy desigual (lo que se conoce como skewed datasets) es que todo el proceso de agrupación para una clave concreta debe realizarse en un único worker (un único nodo de procesamiento). Imagina que tienes millones de registros de ventas y quieres calcular el total por ciudad. Si una ciudad, como "Madrid", tiene muchísimas más ventas que el resto, todos los datos de "Madrid" se enviarán a un solo worker. Este worker se sobrecargará, consumiendo mucha memoria y tiempo, mientras los demás workers que procesan ciudades con menos datos terminan rápido y quedan inactivos. Esto crea un cuello de botella y ralentiza todo el proceso. ✔️ Por qué CombinePerKey es la respuesta correcta CombinePerKey está diseñado específicamente para solucionar este problema. En lugar de enviar todos los valores de una clave a un solo worker para que los agrupe y los procese, CombinePerKey realiza una combinación parcial en cada worker de origen antes de enviar los datos a través de la red. Siguiendo el ejemplo de las ventas: Cada worker recibe un lote de datos de ventas. Para la clave "Madrid", cada worker suma los importes de las ventas que tiene en su lote local. Solo después, estos subtotales (resultados parciales y mucho más pequeños) se envían a un worker final. El worker final simplemente tiene que sumar los pocos subtotales que le han llegado, en lugar de procesar millones de registros individuales. Esta operación de "combinar antes de agrupar" es mucho más eficiente porque reduce drásticamente la cantidad de datos que se mueven por la red y distribuye la carga de trabajo de manera más equitativa. Es ideal para operaciones asociativas y conmutativas (como sumar, contar, buscar el máximo/mínimo o calcular promedios). ❌ Por qué las otras opciones son incorrectas A. FlatMap: Esta transformación no tiene nada que ver con la agrupación. FlatMap se usa para tomar un elemento de entrada y producir cero, uno o múltiples elementos de salida. Por ejemplo, tomar una frase y dividirla en palabras individuales. No agrupa datos, por lo que no es una alternativa a GroupByKey. C. CoGroupByKey: Esta operación se utiliza para agrupar datos de dos o más colecciones que comparten la misma clave. Aunque realiza una agrupación, su propósito es unir diferentes fuentes de datos, no optimizar una agrupación dentro de una única colección. Además, sufre de los mismos problemas de rendimiento que GroupByKey si alguna de las claves tiene una distribución muy desigual en los datos de entrada. D. ParDo: Es la transformación más genérica y fundamental, que significa "Parallel Do" (hacer en paralelo). Se usa para aplicar una función definida por el usuario a cada elemento de una colección. Aunque podrías, en teoría, implementar una lógica de combinación dentro de un ParDo complejo, no es su propósito principal ni la forma idiomática de resolver este problema. CombinePerKey es la herramienta especializada y optimizada para esta tarea. GroupByKey y las demás transformaciones se implementan, de hecho, usando ParDo a un nivel más bajo.

Answer 788

C ParDo es la transformación más fundamental y versátil en Dataflow. Es el "caballo de batalla" para el procesamiento de datos de propósito general. ✅ Respuesta Correcta C) Para ejecutar funciones definidas por el usuario elemento por elemento El nombre ParDo es la abreviatura de "Parallel Do" (Hacer en Paralelo). Su función principal es tomar una función que tú defines (conocida como DoFn) y aplicarla a cada elemento de tu colección de datos (PCollection) de manera distribuida y en paralelo. Es la herramienta que se utiliza para la mayoría de las tareas de procesamiento de datos, como: Filtrar: Revisar cada elemento y decidir si se mantiene o se descarta. Formatear: Cambiar la estructura o el formato de cada elemento (por ejemplo, de JSON a un objeto específico). Extraer: Sacar partes de la información de cada elemento (por ejemplo, extraer el ID de usuario de un registro de log). Transformaciones simples: Aplicar cualquier lógica de negocio a cada elemento de forma individual. ❌ Respuestas Incorrectas A) Para gestionar la lógica de ventanas (windowing): La definición de las ventanas se realiza con la transformación WindowInto. ParDo opera dentro de las ventanas que ya han sido definidas, pero no es la transformación que las crea o gestiona. B) Para realizar agregaciones globales: Para agregaciones (sumas, promedios, etc.) sobre toda una colección de datos, se utilizan transformaciones especializadas y mucho más eficientes como Combine. Combine puede pre-agregar datos localmente en cada trabajador antes de la fase de mezcla (shuffle), lo que ParDo no hace por defecto. D) Para unir múltiples PCollections por clave: La unión de dos o más colecciones de datos basadas en una clave común se realiza con la transformación CoGroupByKey. Esta es la herramienta específica para operaciones de tipo JOIN.

Answer 789

B Templates enable teams to create reusable, parameterized pipelines. They can be deployed by users without needing to modify the pipeline code.

Answer 790

B Dataflow is a serverless data processing tool that offers fine-grained, transform-by-transform autoscaling, making it ideal for new pipelines and unified batch and streaming workloads

Answer 791

C A PCollection is an immutable distributed data abstraction in Apache Beam that can represent both batch (bounded) and streaming (unbounded) data

Answer 792

B y C ✅ Opciones Correctas B) Dataflow can dynamically rebalance work across workers during a job Esta afirmación es correcta. Esta es una de las características más potentes de Dataflow, conocida como reequilibrio de trabajo dinámico. Si un worker (máquina trabajadora) termina su tarea antes que otros o si el autoescalado añade nuevos workers, Dataflow puede redistribuir las tareas pendientes entre todas las máquinas disponibles. Esto evita cuellos de botella y acelera el procesamiento general del trabajo. C) Autoscaling in Dataflow is step-by-step and can adjust mid-job Esto también es correcto. El autoescalado de Dataflow es un proceso continuo y dinámico, no algo que se decide una única vez. Durante toda la ejecución del trabajo, Dataflow monitoriza métricas como el uso de CPU y el trabajo pendiente. Basándose en esto, puede añadir o quitar workers en cualquier momento para optimizar el rendimiento y el coste. ❌ Opciones Incorrectas A) Dataflow autoscaling happens only at the beginning of a job Esto es falso. Como se explica en la opción C, el autoescalado es un proceso que ocurre durante toda la vida del trabajo, no solo al principio. Se ajusta constantemente a las necesidades cambiantes del pipeline. D) Dataflow requires you to manually allocate resources for each stage Esto es falso. De hecho, es todo lo contrario. Dataflow es un servicio totalmente gestionado (fully managed). Uno de sus principales beneficios es que abstrae al usuario de la gestión de recursos. Tú defines la lógica de tu pipeline, y Dataflow se encarga de aprovisionar, gestionar y escalar automáticamente los recursos necesarios para cada etapa.

Answer 793

C Immutability of PCollections means each transformation produces a new collection, simplifying distributed processing by removing the need for complex access control or data sharing mechanisms

Answer 794

A y C Dataproc is recommended for migrating existing Hadoop/Spark workloads and for teams that prefer manual cluster management (DevOps approach). Dataflow is preferred for new, unified, serverless pipelines

Answer 795

C As stated in the "Dataflow versus Dataproc" comparison (page 4), Dataproc is specifically recommended for "Existing Hadoop/Spark applications." It provides a managed environment that allows you to "lift and shift" existing jobs with minimal modifications, making it the ideal choice for this scenario. Dataflow would be a better choice for writing new pipelines or when unifying batch and streaming code, which often requires a rewrite.

Answer 796

C Esta transformación está diseñada específicamente para optimizar agregaciones, especialmente en casos de desequilibrio de datos (data skew) como el problema de la "tecla caliente" (hotkey). ✅ Respuesta Correcta C) CombinePerKey CombinePerKey es una transformación optimizada que realiza una pre-agregación de los datos en cada trabajador antes de barajarlos (shuffle) y enviarlos a través de la red para la agregación final. Función principal: Aplicar una función de combinación (como una suma o un promedio) que sea asociativa y conmutativa. Por qué es correcto: En el escenario de una "tecla caliente", un solo trabajador recibiría una cantidad masiva de valores para esa clave si se usara GroupByKey. CombinePerKey evita esto. Primero, cada trabajador combina localmente los valores que tiene para la tecla caliente, generando un único resultado intermedio mucho más pequeño. Luego, estos resultados intermedios de cada trabajador se envían a través de la red para la combinación final. Esto distribuye la carga de trabajo de manera mucho más uniforme y reduce drásticamente el tráfico de red, solucionando el problema de manera efectiva. ❌ Respuestas Incorrectas A) GroupByKey seguido de un ParDo para sumar los valores. Por qué es incorrecto: Este es el enfoque que causa el problema de la tecla caliente. GroupByKey junta todos los valores para una clave determinada en un solo trabajador. Si una clave tiene mil millones de valores, un trabajador se verá abrumado al intentar procesar esa lista gigantesca, mientras que los demás esperan sin hacer nada. Este es el patrón de anti-rendimiento que se debe evitar. B) Flatten para fusionar los datos, luego GroupByKey. Por qué es incorrecto: Flatten es una transformación que se utiliza para fusionar múltiples PCollections (colecciones de datos) del mismo tipo en una sola PCollection. No tiene ninguna relación con la agregación o la gestión de claves. Aplicar Flatten no haría nada para resolver el desequilibrio de datos causado por la tecla caliente. D) CoGroupByKey para unir los datos consigo mismos. Por qué es incorrecto: CoGroupByKey se utiliza para unir dos o más PCollections que comparten un tipo de clave común, similar a un JOIN en SQL. Unir una colección de datos consigo misma no tiene un propósito lógico para una operación de agregación y, al igual que GroupByKey, también sufriría del problema de la tecla caliente, ya que tendría que agrupar todos los valores de la clave en un solo lugar antes de poder realizar la "unión".

Answer 797

D Page 8 clearly defines the four main concepts of Apache Beam. A PCollection represents the distributed data itself (and is immutable), while a PTransform represents a data processing operation or step that is applied to a PCollection to produce a new PCollection.

Answer 798

B y D Explanation: B is correct: Page 16 explains that "Dataflow doesn't just execute the Apache Beam transforms as-is. It optimizes the graph, fusing operations..." This is a core benefit. D is correct: Page 18 highlights "Dynamic work rebalancing mid-job." This feature allows Dataflow to reassign tasks from busy workers to idle ones, which increases overall job efficiency and speed. A is incorrect: Dataflow is serverless; you do not manually provision a cluster (this describes Dataproc). C is incorrect: Dataflow, via Apache Beam, is designed to unify both batch and streaming processing, often with the same code.

Answer 799

C Pages 59-61 describe how Dataflow Templates are designed to solve this problem. They separate the development environment (where the pipeline is built) from the execution environment. This "supports non-developer users" by allowing them to run a pre-staged, parameterized pipeline via the Cloud Console, gcloud CLI, or REST API, effectively turning a complex pipeline into a reusable tool.

Answer 800

B Dataflow is ideal for new pipelines as it supports both batch and streaming with the same code, is fully managed, and scales automatically, unlike Dataproc, which is better for existing Hadoop/Spark workloads.

Answer 801

B En el ecosistema de Apache Beam (el motor de Dataflow), entender la diferencia entre lo que "hace algo" y lo que "contiene datos" es fundamental. La respuesta correcta es la B) A distributed data set that can be bounded or unbounded. Aquí tienes la explicación detallada de por qué es la correcta y por qué las demás intentan confundirte: ✅ La respuesta correcta: B En Dataflow, una PCollection (Parallel Collection) es un contenedor de datos. Piensa en ella como una "variable" que contiene los datos que fluyen por tu tubería. Distributed (Distribuida): Los datos en una PCollection pueden estar repartidos en cientos de máquinas. No viven en un solo lugar. Bounded (Acotada): Se refiere a datos con un principio y un fin (por ejemplo, un archivo CSV o una tabla de BigQuery). Es el procesamiento por lotes o Batch. Unbounded (No acotada): Se refiere a datos que llegan continuamente y nunca terminan (por ejemplo, mensajes de Pub/Sub). Es el procesamiento en tiempo real o Streaming. Inmutable: Una vez que se crea una PCollection, no se puede cambiar. Solo puedes aplicar una transformación para generar una nueva PCollection. ❌ Las respuestas incorrectas A) A collection of parallel transforms Por qué es falsa: Una PCollection no es una colección de transformaciones; es una colección de datos. Las transformaciones son los pasos lógicos, no el contenedor de la información. C) A pipeline runner that executes the pipeline Por qué es falsa: El Runner es el motor que ejecuta el código (en este caso, el servicio de Dataflow en Google Cloud). La PCollection es solo un objeto de datos dentro de ese código, no el motor que lo mueve. D) A transform that processes data in parallel Por qué es falsa: Esta es la confusión más común. Lo que procesa los datos se llama PTransform. PTransform: Es el "verbo" (la acción de filtrar, sumar o agrupar). PCollection: Es el "sustantivo" (los datos que son filtrados, sumados o agrupados).

Answer 802

D ¿Por qué 'PipelineRunner' es la respuesta correcta? Un PipelineRunner (o "ejecutor de pipeline") no es una operación que transforma los datos, sino el motor que ejecuta todo el pipeline. Es el componente que le dice a Dataflow dónde y cómo debe correr tu código. Piensa en una receta de cocina: Las PTransform son los pasos de la receta: "picar verduras", "mezclar ingredientes", "hornear a 180°C". El PipelineRunner es el chef o la cocina donde se ejecuta la receta. Puedes usar el DirectRunner para "cocinar" en tu propio ordenador (para pruebas) o el DataflowRunner para "cocinar" a gran escala en la infraestructura de Google Cloud. El PipelineRunner no transforma los datos, simplemente orquesta y ejecuta las transformaciones que tú has definido. ¿Por qué las otras opciones son incorrectas? Las otras tres opciones SÍ son PTransforms fundamentales en cualquier pipeline de Dataflow. Son operaciones que se aplican a los PCollections (las colecciones de datos) para modificarlos. A) Map: Es una de las transformaciones más básicas. Aplica una función simple a cada elemento de una PCollection, produciendo una nueva PCollection con exactamente el mismo número de elementos (una transformación 1 a 1). Técnicamente, en el SDK de Apache Beam (la base de Dataflow), esto se implementa con la PTransform llamada ParDo. B) FlatMap: Es muy similar a Map, pero más flexible. Aplica una función a cada elemento que puede devolver cero, uno o múltiples elementos de salida. Es ideal para, por ejemplo, dividir una frase en palabras. También se implementa con ParDo. C) GroupByKey: Es una PTransform esencial para cualquier tipo de agregación. Toma una PCollection de pares clave-valor y agrupa todos los valores que comparten la misma clave. Es el paso previo indispensable para poder sumar, promediar o contar elementos por categoría.

Answer 803

B Combine is more efficient for aggregations, reducing data shuffling, which can be costly, especially with skewed data, compared to GroupByKey.

Answer 804

B Dataflow templates allow non-developers to execute pre-configured pipelines via APIs or the console, separating development from execution for easier deployment.

Answer 805

Dataform es una herramienta para que los equipos de datos desarrollen, prueben y desplieguen flujos de trabajo de transformación de datos (pipelines) en un data warehouse, principalmente en Google BigQuery. Piensa en ello como un "entorno de desarrollo para analistas y ingenieros de datos". En lugar de escribir y ejecutar scripts de SQL sueltos y desordenados, Dataform te permite tratarlos como si fueran código de software: con control de versiones, pruebas automáticas y dependencias claras. Dataform fue una startup que Google adquirió y ahora es un servicio totalmente gestionado dentro de Google Cloud Platform (GCP). Conceptos Clave y Características Principales Para entenderlo mejor, veamos sus características más importantes: 1. Transformación de Datos con SQL (y más) El corazón de Dataform es escribir código para transformar datos. Por ejemplo, pasar de datos brutos (raw data) a tablas limpias, agregadas y listas para el análisis. SQLX: Dataform utiliza un superconjunto de SQL llamado SQLX. Es básicamente SQL estándar al que se le añaden funcionalidades para hacerlo más modular y reutilizable. Por ejemplo, puedes definir "macros" o bloques de código reutilizables. JavaScript: También puedes usar bloques de JavaScript para lógica más compleja, como generar código SQL dinámicamente. 2. Gestión de Dependencias (El orden importa) Imagina que tienes tres tablas: Una tabla A con datos brutos de ventas. Una tabla B que limpia y procesa la tabla A. Una tabla C que resume las ventas por día a partir de la tabla B. Es crucial que se ejecuten en el orden A → B → C. Dataform gestiona esto automáticamente. Usando una simple función como ref("nombre_de_la_tabla"), le dices a Dataform que una tabla depende de otra. Generated sql -- Esto estaría en el archivo de la tabla C SELECT fecha, SUM(venta) FROM ${ref("tabla_B_limpia")} -- Aquí declaras la dependencia GROUP BY 1 Use code with caution. SQL Con estas referencias, Dataform construye un Gráfico Acíclico Dirigido (DAG) que visualiza y ejecuta todo el flujo de trabajo en el orden correcto. 3. Pruebas de Calidad de Datos (Assertions) ¿Cómo sabes si tus transformaciones son correctas? Dataform te permite escribir "pruebas" (assertions) para validar tus datos. Por ejemplo: uniqueKey: Asegurarte de que una columna no tiene valores duplicados (ej. order_id). notNull: Verificar que una columna nunca sea nula (ej. customer_id). Consultas personalizadas: Escribir una consulta SQL que debe devolver cero filas para que la prueba pase (ej. "buscar pedidos con un total negativo"). Si una prueba falla, la ejecución se detiene y te notifica, evitando que datos erróneos lleguen a tus dashboards o informes. 4. Control de Versiones (Integración con Git) Todo tu proyecto de Dataform es una colección de archivos (.sqlx). Este proyecto se conecta a un repositorio de Git (como GitHub, GitLab o Cloud Source Repositories). Esto permite: Colaboración: Varios miembros del equipo pueden trabajar en el mismo proyecto. Historial de Cambios: Ver quién cambió qué y cuándo. Reversión: Volver fácilmente a una versión anterior si algo sale mal. Entornos de Desarrollo y Producción: Trabajar en una rama (develop) y solo fusionar a la rama principal (main) cuando el código esté probado y listo. 5. Documentación Puedes añadir descripciones en formato Markdown directamente en tu código para documentar qué es cada tabla y cada columna. Dataform genera automáticamente una documentación de datos que ayuda a todo el equipo a entender qué significa cada campo. ¿Cómo Funciona en la Práctica (El Flujo de Trabajo)? Desarrollo: Usas la interfaz de Dataform dentro de la consola de Google Cloud para escribir tus archivos .sqlx. Defines tus tablas, vistas y pruebas. Commit y Push: Guardas tus cambios en tu repositorio de Git. Compilación: Dataform compila tu código SQLX y tus dependencias en SQL estándar. Ejecución: Programas una ejecución (ej. "todos los días a las 3 AM") o la lanzas manualmente. Orquestación: Dataform envía las consultas SQL compiladas a BigQuery en el orden correcto (según el DAG). Crea o actualiza las tablas y vistas y luego ejecuta las pruebas. Monitoreo: Puedes ver el historial de ejecuciones, los logs y si alguna prueba falló, todo desde la interfaz de GCP. Dataform vs. dbt (su principal competidor) Si conoces el mundo de los datos, probablemente hayas oído hablar de dbt (data build tool). Dataform y dbt son muy similares y resuelven el mismo problema. Característica Dataform dbt (dbt Core / dbt Cloud) Integración Nativo de GCP y totalmente gestionado. La mejor opción si tu ecosistema es 100% Google Cloud. Multi-nube y agnóstico. Funciona con BigQuery, Snowflake, Redshift, etc. Es un estándar de la industria. Lenguaje SQLX (SQL con helpers tipo JS) SQL + Jinja (un motor de plantillas de Python). Comunidad Más pequeña, centrada en GCP. Enorme comunidad de código abierto, con muchos paquetes y recursos disponibles. Coste Gratis (incluido en GCP). Solo pagas por el uso de BigQuery (procesamiento y almacenamiento). dbt Core es gratis y de código abierto. dbt Cloud tiene un plan gratuito y planes de pago. En resumen: Elige Dataform si estás profundamente integrado en Google Cloud y quieres una solución sencilla y gestionada. Elige dbt si necesitas flexibilidad para trabajar con varias nubes, quieres aprovechar una comunidad más grande o prefieres la sintaxis de Jinja. ¿Para Quién es Dataform? Ingenieros de Analítica (Analytics Engineers): Este es su rol principal. Son el puente entre los ingenieros de datos y los analistas de negocio. Ingenieros de Datos: Para estructurar y formalizar sus pipelines de transformación. Analistas de Datos (con conocimientos de SQL): Para ser más autónomos y construir sus propias tablas de datos fiables y probadas. En definitiva, Dataform es una pieza clave del "Modern Data Stack" que aplica las mejores prácticas de la ingeniería de software a la transformación de datos.

Answer 806

C Cloud Data Fusion is explicitly described as a "fully-managed, cloud native, enterprise data integration service for quickly building and managing data pipelines". It provides a graphical user interface for building data pipelines with no code, making it essentially a "graphical no code tool to build data pipelines". It is designed for "building batch data pipelines visually

Answer 807

C The sources clearly state that "Cloud Composer is managed Apache Airflow". Cloud Composer is a "serverless environment on which an open source workflow tool runs," and that tool is Apache Airflow, which is an "open-source orchestration engine". It is used to "orchestrate work between Google Cloud services".

Answer 808

A y B ✅ A) Wrangler Wrangler es una de las herramientas más potentes y distintivas de Cloud Data Fusion. Es un entorno interactivo y visual que te permite explorar, limpiar y transformar tus datos de forma rápida. Cargas una muestra de tus datos y puedes aplicar una serie de transformaciones (como dividir columnas, filtrar filas, cambiar formatos) desde un menú. Lo más importante es que cada paso que realizas en la interfaz se traduce en código, y el conjunto de transformaciones que diseñas en Wrangler se puede añadir a un pipeline como una etapa de transformación reutilizable. Es el componente clave para la preparación interactiva de datos. 👩‍💻 ✅ B) Data Pipeline El concepto de Data Pipeline (tubería de datos) es el núcleo de Cloud Data Fusion. Un pipeline es un grafo visual que representa el flujo de datos completo, desde las fuentes de origen hasta los destinos finales (sumideros o sinks), pasando por diversas etapas de transformación. Se construye arrastrando y soltando conectores y transformaciones en un lienzo y uniéndolos. Este enfoque visual y de bajo código es lo que define a la herramienta y es el marco principal para construir los flujos de trabajo de ETL/ELT. Las respuestas incorrectas: C, D y E Estas opciones no son componentes o marcos de trabajo dentro de Cloud Data Fusion. ❌ C) Rules Engine Aunque puedes construir lógica de transformación compleja que actúe como un motor de reglas dentro de un pipeline (por ejemplo, usando transformaciones como "Router" o "Filter"), "Rules Engine" no es un componente con nombre o un marco de trabajo específico dentro de la plataforma. La lógica de reglas se implementa utilizando las transformaciones existentes. ❌ D) Cloud Monitoring Cloud Monitoring es un servicio separado dentro de Google Cloud que se usa para la observabilidad (métricas, logs, alertas) de todos los servicios de GCP, incluido Data Fusion. Si bien Data Fusion se integra con Cloud Monitoring para enviar sus métricas y logs, Monitoring no es un componente dentro de Data Fusion, sino una herramienta externa para supervisarlo. ❌ E) Metadata Aggregator Cloud Data Fusion tiene robustas capacidades de gestión de metadatos, linaje de datos y descubrimiento. Sin embargo, no tiene un componente específico llamado "Metadata Aggregator". Estas funcionalidades están integradas en la plataforma como parte de su base, que proviene del proyecto de código abierto CDAP (Cask Data Application Platform).

Answer 809

B y C There are "two different ways your workflow can be run without you sitting there manually clicking 'run DAG'". The first is a "set schedule or periodic run of a workflow," such as "once a day at 6am, or weekly on Saturdays". The second way is "trigger-based," where the workflow runs "whenever new CSV data files were loaded into a Cloud Storage bucket or if new data came in from a Pub/Sub topic you’ve subscribed to". ✅ Respuestas Correctas B) Evento periódico (horario establecido) 🗓️ Esta es la forma más fundamental y común de programar flujos de trabajo (DAGs) en Apache Airflow y, por lo tanto, en Cloud Composer. Explicación: Se define un parámetro llamado schedule (o schedule_interval en versiones más antiguas) dentro del código del DAG. Este parámetro utiliza una expresión cron (ej: '0 5 * * *' para ejecutarlo todos los días a las 5:00 AM) o presets predefinidos (ej: '@daily', '@hourly') para decirle al planificador de Airflow cuándo debe ejecutar el flujo de trabajo de forma automática y recurrente. Es el pilar de los procesos por lotes (batch) programados. C) Basado en eventos (activado por un disparador) TRIGGER ➡️ Esta es la segunda forma principal de ejecución, diseñada para arquitecturas reactivas donde un flujo de trabajo debe iniciarse en respuesta a un suceso externo. Explicación: Un DAG se puede configurar para no tener un horario fijo (schedule=None) y esperar a ser activado por un disparador externo. El mecanismo estándar para esto es a través de la API REST de Airflow. Un evento, como la subida de un nuevo archivo a un bucket de Cloud Storage, puede activar una Cloud Function o un trigger de Eventarc, que a su vez realiza una llamada a la API de Airflow para iniciar la ejecución del DAG correspondiente. Esto permite una orquestación basada en eventos y en tiempo real. ❌ Respuestas Incorrectas A) Ejecución manual únicamente a través de la UI de Airflow. Por qué es incorrecta: La palabra clave que invalida esta opción es "únicamente". Si bien es cierto que puedes activar manualmente cualquier DAG desde la interfaz de usuario de Airflow (lo cual es muy útil para pruebas o para volver a ejecutar tareas fallidas), no es la única forma de hacerlo. El propósito principal de un orquestador como Composer/Airflow es la automatización, no la ejecución manual. D) Activado directamente por pipelines de Cloud Build sin ningún otro intermediario. Por qué es incorrecta: Esta opción es sutilmente incorrecta por las palabras "directamente" y "sin ningún otro intermediario". No existe una integración nativa y directa entre Cloud Build y Cloud Composer. Para que un pipeline de Cloud Build active un DAG, necesita un paso que utilice una herramienta (como curl o el SDK de gcloud) para hacer una llamada a la API REST de Airflow. Esa llamada a la API es, por definición, un intermediario. Por lo tanto, la activación no es directa.

Answer 810

B For Cloud Data Fusion, a pipeline is "represented visually as a series of stages arranged in a graph. These graphs are called DAGs or directed acyclic graphs because they flow from one direction to another and they can not feed into themselves. Acyclic simply means not a circle". Similarly, for Cloud Composer and Apache Airflow, "The heart of any workflow is a DAG" and "DAG = Directed Acyclic Graph"

Answer 811

C Wrangler is the code-free, visual environment used to explore datasets and apply transformation directives. It’s often used to prepare data before operationalizing in a pipeline.

Answer 812

C DAGs define the order and dependencies of tasks in a workflow in Airflow. They are visual graphs without cycles, essential for orchestration.

Answer 813

C While Cloud Data Fusion integrates data pipelines, it does not handle model training — that’s a function typically orchestrated with Vertex AI via Cloud Composer.

Answer 814

B The BigQueryInsertJobOperator allows execution of arbitrary SQL queries in BigQuery, which is key for transforming or loading data in workflows.

Answer 815

B y D Cloud Composer es el servicio gestionado de Google Cloud para Apache Airflow. Por lo tanto, sus estrategias de programación son las de Airflow, junto con las integraciones que ofrece el ecosistema de Google Cloud. El objetivo es identificar los métodos de programación de flujos de trabajo (DAGs) que son soportados. D. Periodic scheduling via schedule_interval (Programación periódica a través de schedule_interval) Esta afirmación es CORRECTA. Por qué es correcta: Esta es la forma más fundamental y común de programar un flujo de trabajo en Airflow/Composer. El parámetro schedule_interval se define directamente en el código del DAG y utiliza una expresión cron (o presets como @daily, @hourly) para especificar cuándo debe ejecutarse el flujo de trabajo de manera recurrente. Es el núcleo de la programación basada en tiempo. B. Event-driven scheduling via Cloud Functions (Programación basada en eventos a través de Cloud Functions) Esta afirmación es CORRECTA. Por qué es correcta: Este es un patrón de diseño muy común y totalmente soportado para la orquestación moderna de datos. El flujo funciona así: Un evento ocurre en Google Cloud (p. ej., un archivo se sube a un bucket de Cloud Storage, llega un mensaje a un tema de Pub/Sub). Este evento dispara una Cloud Function. La Cloud Function ejecuta un comando (gcloud composer dags trigger) o utiliza la API de Composer para iniciar la ejecución de un DAG específico. Esto permite que los flujos de trabajo se ejecuten en respuesta a eventos, en lugar de basarse únicamente en un horario fijo. ¿Por qué las otras opciones son incorrectas? A. Manual-only triggering (Activación exclusivamente manual) Esta afirmación es INCORRECTA (como una de las dos mejores opciones). El matiz: Si bien es cierto que se puede activar un DAG manualmente desde la interfaz de usuario de Airflow, esto no se considera una "estrategia de programación" automatizada, que es el propósito principal de una herramienta como Composer. La activación manual es una función para pruebas, depuración o ejecuciones ad-hoc, no un método para programar ejecuciones recurrentes en producción. Por lo tanto, aunque es una capacidad soportada, B y D son mejores descripciones de las estrategias de programación. C. Real-time streaming from Pub/Sub (Procesamiento en tiempo real desde Pub/Sub) Esta afirmación es INCORRECTA. La diferencia clave: Esta opción describe un paradigma de procesamiento de datos, no una estrategia de programación. Cloud Composer (Airflow) es un orquestador de lotes (batch orchestrator). Organiza tareas que tienen un principio y un fin. No es un motor de procesamiento de flujos en tiempo real (real-time streaming engine) como lo son Cloud Dataflow (en modo streaming) o Apache Flink. Aunque un mensaje en Pub/Sub puede disparar un flujo de trabajo por lotes (como se describe en la opción B), Composer no procesa el flujo de mensajes de manera continua y con baja latencia.

Answer 816

A, B y C Cloud Data Fusion allows integration with a wide variety of data sources, increases productivity through unified data views, and reduces complexity with a visual, code-free interface. Manual coding is not required for all transformations, as it offers no-code and low-code options

Answer 817

B The Wrangler component is designed for data preparation, allowing users to visually explore, clean, and transform datasets before operationalizing them in pipelines

Answer 818

B A DAG in Cloud Data Fusion represents the structure of a data pipeline, where stages (nodes) are arranged in a one-way, non-circular flow

Answer 819

A El Hub funciona como una "biblioteca" o mercado interno dentro de la interfaz de Cloud Data Fusion. Es "la buena" por estas razones: Descubrimiento: Permite buscar y encontrar rápidamente pipelines de ejemplo, complementos (plugins) y soluciones preconfiguradas. Organización: Centraliza recursos reutilizables para que no tengas que empezar desde cero cada vez. Actualizaciones: Desde aquí puedes ver si hay nuevas versiones de los conectores o transformaciones que ya estás usando. Opción,Por qué es incorrecta B (Control Center),"No existe una sección con ese nombre exacto dedicada a la organización de activos. El monitoreo de pipelines se hace desde la sección de Dashboard o la vista de lista de pipelines, pero no se llama ""Control Center""." C (Wrangler),"Wrangler es una herramienta de preparación de datos (limpieza, transformación visual, recetas). Sirve para ""manipular"" los datos, no para organizar o buscar pipelines en el sistema." D (ECA),"Event Condition Action es un paradigma de programación o automatización (si pasa X, haz Y). En Data Fusion, se usa para disparadores (triggers) de pipelines, no es una característica de la UI para organizar o encontrar archivos."

Answer 820

B Preview Mode allows users to run a pipeline with sample data, view results at each node, and identify potential errors before deploying the pipeline to production

Answer 821

C As stated in the presentation (slides 35, 37, 38), Cloud Composer is the managed Apache Airflow service used for orchestrating work across multiple Google Cloud services. While Data Fusion builds a specific data pipeline, Composer acts as the "glue" to chain different tasks (like running that pipeline, a BigQuery job, and a Vertex AI job) together in a defined workflow (DAG).

Answer 822

B The presentation (slides 11, 31, 32) clearly identifies the Wrangler as the code-free, visual environment for exploring, cleaning, and transforming datasets interactively. The Pipeline Studio is where you build the final DAG, but the Wrangler is the tool for the initial exploration and creation of transformation "directives".

Answer 823

B y D ✅ Por qué B y D son las correctas B. Es un servicio totalmente gestionado para el Apache Airflow de código abierto. Esta es la definición principal de Cloud Composer. Google toma el popular proyecto de código abierto Apache Airflow, lo empaqueta y lo ofrece como un servicio gestionado. Esto significa que Google se encarga de la parte difícil (aprovisionar y administrar la infraestructura subyacente, como los clústeres de Kubernetes, los servidores web, las bases de datos, etc.), permitiendo que los desarrolladores se centren únicamente en escribir sus flujos de trabajo (DAGs). D. Los archivos Python que definen los DAG se almacenan en un bucket designado de Cloud Storage. Así es como Cloud Composer carga y ejecuta tus flujos de trabajo. Cuando creas un entorno de Cloud Composer, Google Cloud crea automáticamente un bucket en Cloud Storage asociado a él. Para desplegar un nuevo flujo de trabajo o actualizar uno existente, simplemente subes el archivo de Python (.py) que define el DAG a la carpeta /dags dentro de ese bucket. Airflow monitorea automáticamente esta carpeta y carga los cambios. ❌ Por qué A y C son las incorrectas A. Los flujos de trabajo (DAGs) se definen visualmente mediante una interfaz de arrastrar y soltar. Esto es falso. Una de las características principales de Apache Airflow (y por lo tanto de Cloud Composer) es que los flujos de trabajo se definen como código, específicamente en Python. Esto se conoce como Workflows as Code (Flujos de trabajo como código) y ofrece gran flexibilidad, control de versiones y capacidad de prueba. La interfaz de usuario de Airflow te permite visualizar el DAG una vez definido, pero no crearlo de forma gráfica. C. Toda la lógica del pipeline se almacena y versiona automáticamente en BigQuery. Esto es incorrecto. BigQuery es un almacén de datos (data warehouse) diseñado para analizar grandes volúmenes de datos, no para almacenar código fuente. Como se mencionó, la lógica del pipeline (el código Python) se almacena en Cloud Storage. El versionado del código tampoco es una función de BigQuery; se suele gestionar externamente con herramientas como Git.

Answer 824

D This is the "push" or event-driven architecture pattern described in the presentation (slides 54, 57, 60). A Cloud Function can be configured with a Cloud Storage trigger. When a file is uploaded, the function executes and can be programmed to make a POST request to the Airflow REST API, thereby triggering the desired DAG run.

Answer 825

B Slides 29 and 30 showcase the field-level lineage capability. This feature is designed to provide provenance and impact analysis by showing all the transformation steps a specific field has undergone. This is extremely useful for understanding how a field got its value and for debugging data quality problems.

Answer 826

C ELT is a common pattern when the transformations on the dataset are minor and can be handled after loading the data, such as performing SQL operations on raw data in BigQuery and storing the transformed version as a new table

Answer 827

B, C y D Dataflow is a serverless application that automatically splits datasets into PCollections for parallel processing across worker VMs, which auto-scale based on demand. It is used to overcome BigQuery's limitations for complex or high-volume ETL transformations. Visually designing pipelines is a feature of Cloud Data Fusion.

Answer 828

C Cloud Composer is a managed Apache Airflow service that functions as a workflow orchestrator, allowing users to command Google Cloud services in DAGs for complex operations.

Answer 829

C After lifting and shifting existing Hadoop workloads to Dataproc, an additional optimization is to use Cloud Storage for cluster storage instead of HDFS, which provides greater efficiency and cost savings

Answer 830

B Por qué es la buena: Cloud Data Fusion se destaca no solo por ser una herramienta visual para construir pipelines (ETL), sino por su capacidad de gobernanza de datos. Linaje (Data Lineage): Una de las características estrella de Data Fusion es que te permite ver visualmente la "historia" de tus datos. Puedes rastrear un campo específico desde su destino final hacia atrás hasta su origen, viendo exactamente qué transformaciones se le aplicaron en cada paso. Esto es crucial para auditorías y depuración (debugging). Contexto: Data Fusion está basado en el proyecto open source CDAP, que tiene un enfoque fuerte en la integración y la metadata de los datos, de ahí que el linaje sea una funcionalidad nativa y clave. Por qué las otras son las malas A. Procesamiento en colecciones paralelas (PCollections) De quién es esto: Esto es terminología específica de Apache Beam y, por extensión, de Google Cloud Dataflow. Por qué falla: Aunque Data Fusion usa Dataflow por debajo para ejecutar los trabajos, el concepto de manipular "PCollections" programáticamente pertenece al desarrollo de código en Dataflow, no a la interfaz visual ni a las "features" principales que vende Data Fusion al usuario final. C. Disparadores automatizados por eventos (como subida de archivos) De quién es esto: Esto es la funcionalidad clásica de Cloud Functions o características de automatización de Cloud Storage en combinación con Pub/Sub. Por qué falla: Data Fusion es una herramienta de diseño y ejecución de pipelines. Aunque puedes programar ejecuciones (scheduling), la funcionalidad de "escuchar eventos en tiempo real" como un trigger nativo (ej. "al subir un archivo, lanza esto") se suele orquestar externamente (por ejemplo, usando Cloud Composer o Cloud Functions para llamar a la API de Data Fusion), no es su key feature intrínseca. D. Soporte directo para operaciones SQL complejas en datos crudos (ELT) De quién es esto: Esto describe perfectamente a BigQuery (como vimos en la pregunta anterior). Por qué falla: Data Fusion se enfoca en ETL (Extraer, Transformar, Cargar) visual. Aunque tiene plugins para ejecutar SQL, su fuerte es la transformación visual mediante "wranglers" y plugins gráficos, no actuar como un motor de base de datos SQL para transformaciones ELT puras.

Answer 831

B ELT is preferred when the required transformations are minor and can be handled after loading the data into BigQuery, using SQL to process the raw data

Answer 832

C Cloud Dataproc enables you to lift and shift existing Hadoop workloads to the cloud without code changes, and offers further optimizations such as using Cloud Storage for cluster storage, which improves efficiency and reduces costs

Answer 833

B Por qué la opción B es la correcta B) Cloud Data Fusion ✅ Este servicio está diseñado específicamente para lo que se pide. Es una plataforma de integración de datos totalmente gestionada que destaca por tres características clave mencionadas en la pregunta: Diseño Visual: Su principal atractivo es una interfaz gráfica de usuario (GUI) donde puedes arrastrar y soltar componentes (fuentes, transformaciones, destinos) para construir pipelines de datos complejos sin necesidad de escribir mucho código. Construcción y Ejecución: Es una herramienta ETL/ELT (Extract, Transform, Load) completa, hecha para crear y ejecutar estos flujos de trabajo de procesamiento de datos. Linaje de Datos (Data Lineage): Una de sus funciones más potentes es que captura y visualiza automáticamente el linaje de los datos. Esto te permite rastrear el origen de cualquier dato y ver todas las transformaciones que ha sufrido a lo largo del pipeline, lo cual es crucial para la gobernanza y la depuración. En resumen, Cloud Data Fusion es la única opción que cumple con los tres requisitos: visual, pipeline de datos y linaje integrado. Por qué las otras opciones son incorrectas A) BigQuery ❌ BigQuery es un almacén de datos (data warehouse) serverless, increíblemente potente para almacenar y analizar grandes volúmenes de datos mediante SQL. Aunque sí ofrece seguimiento de linaje a nivel de columna, no es una herramienta para diseñar visualmente pipelines. Es más bien el destino final de un pipeline, no la herramienta con la que se construye de forma gráfica. C) Cloud Composer ❌ Cloud Composer es un servicio de orquestación de flujos de trabajo basado en Apache Airflow. Se utiliza para programar, monitorizar y gestionar pipelines, pero estos pipelines se definen como código Python (en archivos llamados DAGs). No tiene una interfaz visual para diseñar los flujos; la interfaz de Airflow sirve para visualizar los flujos ya definidos en código. Es un orquestador, no un constructor visual. D) Dataflow ❌ Dataflow es un motor de procesamiento de datos para ejecutar pipelines a gran escala, tanto en batch como en streaming. Al igual que Composer, los pipelines de Dataflow se definen mediante código, utilizando el SDK de Apache Beam (en Python o Java). Aunque la consola de Dataflow muestra un grafo visual del pipeline mientras se ejecuta, este no se diseña de forma visual. Dataflow es el "motor", mientras que Cloud Data Fusion sería la "herramienta de diseño visual" que puede usar un motor como Spark o Dataproc por debajo.

Answer 834

A, C y D Análisis de las Respuestas Correctas A) It is a serverless application for processing batch data (Es una aplicación sin servidor para procesar datos por lotes) Esta afirmación es correcta. Sin servidor (Serverless): Dataflow es un servicio totalmente gestionado. Tú defines el pipeline (el flujo de procesamiento), pero Google Cloud se encarga de aprovisionar, gestionar y escalar la infraestructura (los servidores o workers) de forma automática. No tienes que preocuparte por las máquinas virtuales subyacentes. Procesamiento por lotes (Batch): Es uno de los dos casos de uso principales de Dataflow. Puede procesar grandes conjuntos de datos finitos (por ejemplo, analizar todos los logs de un día). Aunque también procesa datos en tiempo real (streaming), su capacidad para el procesamiento batch es fundamental, por lo que la afirmación es cierta. C) It uses PCollections as the fundamental unit of logical data (Utiliza PCollections como la unidad fundamental de datos lógicos) Esta afirmación es correcta. Dataflow es el servicio que ejecuta los pipelines creados con el SDK de Apache Beam. En el modelo de programación de Apache Beam, la PCollection (Colección Paralela) es la abstracción que representa un conjunto de datos distribuido y potencialmente inmenso. Todas las operaciones y transformaciones en un pipeline de Dataflow se aplican sobre PCollections. Es el concepto central para manejar los datos. D) It can automatically scale workers up and down based on demand (Puede escalar automáticamente los workers hacia arriba y hacia abajo según la demanda) Esta afirmación es correcta. Esta es una de las características más potentes de Dataflow. El autoescalado permite al servicio monitorizar la carga de trabajo de tu pipeline y añadir más máquinas (workers) si el trabajo es muy pesado, o quitarlas si hay poca carga. Esto asegura que el trabajo se complete de manera eficiente y optimiza los costes, ya que solo pagas por los recursos que realmente necesitas en cada momento. Por Qué la Opción B es Incorrecta B) It requires manual scaling of worker nodes (Requiere el escalado manual de los nodos de trabajo) Esta afirmación es incorrecta porque contradice directamente la opción D. La palabra clave aquí es "requiere". Aunque Dataflow permite configurar el escalado manual para casos muy específicos, su modo de funcionamiento por defecto y su principal ventaja es el autoescalado. No es un requisito hacerlo manualmente; de hecho, en la mayoría de los casos no es la opción recomendada.

Answer 835

B Cloud Composer is a managed Apache Airflow service that orchestrates complex workflows, allowing you to schedule and automate data pipeline tasks across Google Cloud services

Answer 836

B Por qué es la buena: Esta opción es la ganadora porque el enunciado tiene dos palabras clave fundamentales: "minor" (transformaciones menores) y "simplicity" (simplicidad). Simplicidad y Velocidad: Al usar el patrón ELT, aprovechas la capacidad nativa de BigQuery. Cargas los datos tal cual están (Raw) en una tabla temporal (staging) y luego ejecutas una consulta SQL simple para transformarlos. No necesitas configurar infraestructura extra ni escribir código complejo en Python o Java. Ajuste perfecto a los requisitos: El enunciado dice explícitamente que las transformaciones son "fácilmente expresables en SQL". BigQuery es un motor de SQL superpotente; usarlo para esto es lo más eficiente en términos de tiempo de desarrollo y ejecución. Por qué las otras son las malas A. ETL usando Dataflow Por qué falla: Dataflow es una herramienta increíblemente potente, ideal para procesamientos complejos (como streaming en tiempo real o transformaciones muy pesadas que SQL no puede manejar bien). El problema: Usar Dataflow para "seleccionar unas pocas columnas" es matar moscas a cañonazos. Requiere escribir código (Apache Beam), gestionar el pipeline y añade una complejidad innecesaria (overkill) para algo que un simple SELECT en BigQuery ya hace. C. Dataproc con Spark Por qué falla: Dataproc se utiliza para levantar clústeres de Hadoop y Spark. El problema: Levantar y gestionar un clúster entero solo para una transformación menor añade una carga administrativa y un coste de inicio (tiempo de arranque del clúster) enormes. Va totalmente en contra del requisito de "simplicidad". D. Cloud Data Fusion Por qué falla: Data Fusion es una herramienta visual para construir pipelines de integración de datos (ETL visual). El problema: Aunque es "visual", configurar una instancia de Data Fusion puede tardar bastante (15-20 minutos solo en provisionarse) y suele ser más costoso. Es útil cuando tienes que limpiar datos muy sucios o integrar muchas fuentes distintas, pero para mover datos de GCS a BigQuery con cambios mínimos, es una capa de complejidad que no necesitas.

Answer 837

C The presentation explicitly states, "use Cloud Storage instead of HDFS for greater efficiency and cost savings." Using Cloud Storage decouples storage from compute, allowing you to shut down the Dataproc cluster when it's not in use without losing data, which is a major cost-saving measure. It also provides higher durability and accessibility.

Answer 838

C Cloud Data Fusion is specifically designed for building ETL/ELT pipelines through a visual, code-free interface, which is perfect for data analysts. A key feature mentioned in the text is its ability to provide data lineage for each field, which directly addresses the critical requirement.

Answer 839

C The text provides a direct example of this architecture: "...when a new CSV was uploaded to our Cloud Storage bucket, a Cloud Function was triggered to start a Dataflow pipeline...". Cloud Functions are designed to respond to events, such as a file creation event in a Cloud Storage bucket, making them the perfect "glue" to trigger a process automatically.

Answer 840

B y C Las Respuestas Correctas: B y C B. Cloud Composer Rol: El Director de Orquesta. Por qué es "Glue": Cloud Composer es un servicio gestionado de Apache Airflow. Su trabajo no es procesar los datos en sí (no hace las sumas ni las restas masivas), sino decirle a los demás cuándo empezar y qué hacer. Conecta el paso A con el paso B. Ejemplo: "Oye Dataflow, empieza a procesar. Cuando termines, avísame para que yo le diga a BigQuery que cargue la tabla". C. Cloud Functions Rol: El Mensajero Rápido (Eventos). Por qué es "Glue": Es código ligero "serverless" que reacciona a eventos. Se usa para conectar servicios que no hablan entre sí directamente. Ejemplo: "¡Acaba de caer un archivo en Cloud Storage! Cloud Function se despierta, y lanza una llamada a la API para iniciar el trabajo". Pega el evento de subida con la acción de procesado. Por qué las otras son las malas (Los "Músculos") A. Cloud Dataflow y D. Cloud Dataproc Rol: Los Obreros (Data Processors). Por qué no son "Glue": Estas herramientas están diseñadas para hacer el trabajo pesado. Son los motores que mastican los Terabytes de datos, los limpian y los transforman. El enunciado dice explícitamente "rather than the core data processing itself" (en lugar del procesamiento de datos central). Dataflow y Dataproc SON el procesamiento central.

Answer 841

A The document clarifies that ETL (Extract, Transform, Load) is employed when data requires complex transformations or when handling large volumes, with transformations performed before loading into a target system, such as using Dataflow for batch processing. Conversely, ELT (Extract, Load, Transform) involves loading data into a system like BigQuery first and then applying transformations, typically via SQL, which is suitable for minor transformations. Note that the document contains a typographical error, incorrectly labeling ELT as "ETL of extract, load transform" and ETL as "ETL, or transforming before loading." Standard terminology is applied here for accuracy, aligning with industry conventions where ETL transforms data pre-loading and ELT transforms post-loading. This distinction is critical for data engineers to determine the appropriate processing strategy based on data complexity and volume.

Answer 842

B In Google Cloud Dataflow, the fundamental unit of logical data is the PCollection, which represents a parallel collection. Dataflow automatically distributes the dataset across multiple worker VMs for processing.

Answer 843

B Dataproc enables users to migrate existing Hadoop workloads to Google Cloud without modifying code, simplifying the transition and management of Hadoop-based data processing.

Answer 844

B Cloud Data Fusion provides a visual interface for data analysts and ETL developers to design, build, and manage data processing pipelines, streamlining the creation of data workflows.

Answer 845

B Cloud Composer, based on managed Apache Airflow, is used to orchestrate complex workflows in Google Cloud, enabling scheduling and monitoring of data pipeline tasks.

Answer 846

C c) Nunca está completa (It is never complete) ✅ Esta es la característica fundamental y definitoria de los datos no acotados (streaming). Piénsalo con una analogía: Datos Acotados (Batch): Son como un libro. Tienen un principio y un final claro. Puedes leerlo de principio a fin y decir "he terminado, tengo toda la información". El conjunto de datos está completo. Datos No Acotados (Stream): Son como un río o el feed de una red social. Los datos fluyen continuamente sin un final previsible. Puedes procesar los datos que llegan, pero siempre habrá más en camino. Por su propia naturaleza, el conjunto de datos nunca está completo. Por lo tanto, la afirmación "nunca está completa" es la que mejor describe la naturaleza infinita y continua de una fuente de datos en streaming. ¿Por qué las otras opciones son incorrectas? ❌ a) Suele estar completa (It is usually complete) Esto describe exactamente lo contrario: es la definición de los datos acotados (batch). Un archivo, una tabla en una base de datos o el registro de ventas de ayer son conjuntos de datos completos y finitos. b) El tiempo de sus elementos suele ignorarse (Its time of elements is usually disregarded) Esto es completamente falso. En el procesamiento de streams, el tiempo es un factor crítico. Conceptos como "ventanas de tiempo" (por ejemplo, "calcular el promedio de ventas de los últimos 5 minutos") son esenciales para dar sentido a los datos que fluyen. Ignorar el tiempo haría que el análisis fuera inútil. d) Suele estar en reposo (It is typically at rest) "Datos en reposo" (data at rest) es el término usado para describir datos que están almacenados y no cambian activamente, como un archivo en un disco duro. Esto también es una característica de los datos acotados (batch). Los datos en streaming son el epítome de los "datos en movimiento" (data in motion). En Resumen La diferencia clave es la finitud: Batch (Acotado): Finito, completo, en reposo. Stream (No Acotado): Infinito, nunca completo, en movimiento.

Answer 847

C Velocity is described as the challenge where "Data often needs to be processed in near-real time, as soon as it reaches the system". It also encompasses the need to handle data that "Arrives late," "Has bad data in the message," or "Needs to be transformed". Variety deals with different sources and formats, Volume with scaling for data magnitude, and Veracity with data quality and inconsistencies.

Answer 848

C The sources explicitly state that "Data typically comes in through Pub/Sub" and that for the "Ingest and distribute" step, "You are going to ingest those and distribute those with Pub/Sub. This will ensure that the messages are reliable. This will give you buffering". Dataflow is for aggregation and transformation, BigQuery for warehousing and insights, and Bigtable for higher throughput individual records.

Answer 849

A y D ✅ Respuestas Correctas a) Para permitir a los analistas tomar decisiones precisas y oportunas a partir de datos en tiempo real. Esta es la razón fundamental para usar análisis en streaming. En ciberseguridad, la velocidad es esencial. La capacidad de analizar registros de seguridad, tráfico de red y otros eventos a medida que ocurren permite a los analistas detectar y responder a amenazas en segundos o minutos, en lugar de horas o días. Un sistema resiliente en Google Cloud (usando servicios como Pub/Sub y Dataflow) garantiza que estos datos en tiempo real se procesen de manera confiable para tomar decisiones críticas de forma inmediata. d) Para procesar y analizar datos 10 veces más rápido con la capacidad de escalar. Este punto destaca dos beneficios cruciales de usar la nube para esta tarea: Velocidad: La afirmación "10 veces más rápido" (basada en el caso de estudio real de NYC3) subraya la mejora de rendimiento masiva sobre sistemas heredados, que a menudo son más lentos y se basan en lotes (batch). Escalabilidad: El volumen de datos de ciberseguridad puede tener picos enormes e impredecibles, especialmente durante un ataque. Las plataformas en la nube como Google Cloud pueden escalar sus recursos automáticamente para manejar estos picos sin intervención manual, asegurando que el sistema no se sobrecargue cuando más se necesita. ❌ Respuestas Incorrectas b) Para acelerar la incorporación de agencias de la ciudad. Si bien un sistema de datos centralizado y eficiente puede facilitar que nuevas agencias se integren, este es un beneficio secundario y de carácter organizacional. El objetivo principal de la arquitectura de análisis en streaming no es acelerar procesos administrativos, sino procesar y analizar datos para la ciberdefensa. c) Para almacenar datos en reposo en almacenamiento duradero. Aunque es cierto que los datos se almacenan en un sistema duradero como BigQuery o Cloud Storage, esta es una característica fundamental de casi cualquier sistema de datos moderno, no una razón específica para elegir una arquitectura de streaming. Se podría lograr almacenamiento duradero con un sistema de lotes (batch) simple. La motivación principal para el streaming es el procesamiento y la toma de decisiones en tiempo real (opción a), no simplemente el almacenamiento.

Answer 850

C Pub/Sub is used to ingest and distribute streaming data reliably and at scale, acting as a message broker between producers and consumers.

Answer 851

A, B y D Streaming data is unbounded, requires low latency processing, and often contains late-arriving or malformed data. Structured, fixed datasets are more typical of batch processing.

Answer 852

C "Velocity" in Big Data refers to how fast the data is generated, transmitted, and needs to be processed—often in real time for streaming applications.

Answer 853

C Dataflow is a managed service for processing data (streaming or batch). In streaming pipelines, it's used for aggregating, enriching, and transforming the data before storage or analysis.

Answer 854

A, B y C A typical Google Cloud streaming pipeline involves Pub/Sub for ingestion, Dataflow for processing, and BigQuery for real-time analytics and reporting. Cloud Spanner is more for scalable transactional databases than streaming analytics.

Answer 855

C Pub/Sub is designed to handle changing and variable volumes of streaming data, ensuring reliable message delivery and buffering before further processing.

Answer 856

A The four V's—Variety, Velocity, Volume, and Veracity—represent the key challenges in big data: handling different data types, processing data quickly, managing large amounts of data, and ensuring data quality.

Answer 857

B Dataflow is used for real-time aggregation, enrichment, and detection on streaming data after it is ingested by Pub/Sub

Answer 858

A, C y D Stream analytics is used for real-time applications such as fraud detection, recommendations, and gaming event processing. Batch data archiving is not a typical streaming use case.

Answer 859

B Batch processing deals with finite, completed data sets (bounded), whereas streaming processes unbounded data that continuously arrives and is never fully complete

Answer 860

B Esta secuencia representa la arquitectura de referencia canónica de Google Cloud para el análisis de datos en streaming. ✔️ Por qué la opción B es la correcta Desglosemos el flujo y cómo cada servicio cumple con los requisitos de la pregunta: Ingestión (Pub/Sub): La arquitectura debe ingerir un "alto volumen de eventos de múltiples fuentes". Pub/Sub es el servicio de mensajería global y escalable de Google Cloud, diseñado precisamente para este propósito. Actúa como un buffer o intermediario que recibe eventos en tiempo real de forma fiable, sin importar cuán rápido lleguen o cuántas fuentes los envíen. 📥 Transformación (Dataflow): El requisito es "transformar los datos en caliente" (in-flight). Dataflow es el servicio totalmente gestionado de Google para procesar y transformar flujos de datos a gran escala. Permite realizar operaciones como limpiar, enriquecer, agregar o filtrar los datos a medida que fluyen, antes de que lleguen a su destino final. ⚙️ Carga y Análisis (BigQuery): Finalmente, los datos se deben cargar en un "almacén de datos (data warehouse) para un análisis inmediato y ad-hoc". BigQuery es el almacén de datos sin servidor (serverless) de Google, optimizado para ejecutar consultas SQL sobre petabytes de datos en segundos. Es la herramienta perfecta para el análisis exploratorio y ad-hoc que se pide. 📊 Este patrón Pub/Sub → Dataflow → BigQuery es el más robusto, escalable y comúnmente recomendado por Google para este tipo de casos de uso. ❌ Por qué las otras opciones son incorrectas A. Cloud Storage -> Dataproc -> BigQuery: Esta arquitectura describe un pipeline de procesamiento por lotes (batch), no de streaming. Los datos se acumularían primero como archivos en Cloud Storage y luego se procesarían periódicamente con Dataproc (un servicio de Spark/Hadoop gestionado). Esto no cumple el requisito de transformación "en caliente" y análisis "inmediato". C. Dataflow -> Pub/Sub -> Cloud SQL: El orden de los servicios es incorrecto y el destino es inapropiado. El flujo de datos normalmente va desde Pub/Sub hacia Dataflow, no al revés. Además, Cloud SQL es una base de datos relacional transaccional (OLTP), no un almacén de datos (OLAP) diseñado para análisis ad-hoc a gran escala. No sería eficiente para ese tipo de consultas. D. IoT Core -> Vertex AI -> Looker Studio: Esta secuencia describe un flujo de trabajo muy diferente y específico, centrado en el Machine Learning y la visualización. IoT Core es un servicio de ingestión solo para dispositivos de IoT (Internet de las cosas), no para "múltiples fuentes" genéricas. Vertex AI es una plataforma de IA/ML para entrenar y desplegar modelos, no para la transformación general de datos. Looker Studio es una herramienta de visualización que se conecta a un almacén de datos; no es el almacén en sí.

Answer 861

C Para entender la diferencia, piensa en los datos acotados (bounded) como un periódico diario: llega una vez, está completo y lo procesas (lees) todo de una vez. Los datos no acotados (unbounded) son como el feed de una red social: es un flujo continuo de información que nunca termina. 📰 ✅ Respuesta Correcta C. It is an infinite data set, never complete, and held in temporary storage. (Es un conjunto de datos infinito, nunca completo y se mantiene en un almacenamiento temporal). Infinito y nunca completo: Esta es la naturaleza de un stream. Siempre están llegando nuevos eventos (clics, lecturas de sensores, transacciones), por lo que el conjunto de datos nunca se puede considerar "terminado". Almacenamiento temporal: Antes de ser procesados por una herramienta como Dataflow, los eventos se suelen poner en cola en un servicio de mensajería como Google Cloud Pub/Sub. Este actúa como un búfer o almacenamiento temporal de alta capacidad para absorber el flujo constante de datos antes de su análisis. ❌ Respuestas Incorrectas A. It is a finite data set, usually complete, and the time of elements is disregarded. Esto describe un conjunto de datos acotado (bounded), que es típico del sistema antiguo de procesamiento por lotes (batch) mencionado en la pregunta, no del nuevo sistema de streaming. B. It is typically at rest and held in durable storage before processing begins. Esto también describe un patrón de procesamiento por lotes (batch). Los datos "en reposo" (at rest) se almacenan primero (p. ej., en archivos en Cloud Storage) y luego se procesan. Un stream se considera "en movimiento" (in motion) y se procesa a medida que llega. D. It is always processed with Dataproc and stored in HDFS. Esta afirmación es demasiado restrictiva y a menudo falsa. Aunque Dataproc puede manejar streams, la herramienta principal y nativa de Google Cloud para este tipo de procesamiento es Dataflow. Además, la palabra "siempre" es una señal de alerta; en la nube casi nunca hay una única solución obligatoria.

Answer 862

D The challenge described is handling fluctuating and unpredictable data Volume (pages 11 and 14). Page 18 directly maps Google Cloud products to key challenges, stating that Pub/Sub is the service used to handle "Changing and variable volumes of data" by acting as a scalable, serverless messaging buffer.

Answer 863

C y D Velocity (C) is not just about the speed of data, but also about the complexities of time in a stream. Handling data that "Arrives late" is a core challenge of Velocity, as highlighted on page 16. Veracity (D) refers to the quality, trustworthiness, and accuracy of the data. Data that is corrupt or has inconsistencies directly relates to the challenge of Veracity, as described on page 17.

Answer 864

B The document emphasizes that streaming data processing enables organizations to make "accurate and timely decisions from data points generated in real time" (Page 4). It further defines streaming as processing "unbounded data" as it arrives, in contrast to "bound data" processed at rest (Page 9). This distinguishes streaming from batch processing (option A), which involves scheduled data processing, historical data processing (option C), which deals with stored data, and on-demand processing (option D), which is not a primary characteristic of streaming systems.

Answer 865

A, B, C y D Explanation: The document explicitly identifies the "four Vs" as key challenges in streaming data processing (Page 11). These are: Variety: Data from diverse sources and formats, such as point-of-sale data from multiple stores (Pages 12-13). Volume: The need to handle data scales from gigabytes to petabytes, requiring scalable infrastructure (Page 14). Velocity: The requirement to process data in near-real time as it arrives (Page 15). Veracity: Ensuring the accuracy and trustworthiness of streaming data (Page 17). All four options are correct, as they comprehensively cover the challenges outlined in the document.

Answer 866

A, B y C Explanation: The document highlights three Google Cloud products for streaming analytics (Page 18): Pub/Sub: Handles ingestion and distribution of streaming data, managing variable volumes (Page 18). Dataflow: Processes data without undue delays, enabling aggregation and enrichment (Page 18). BigQuery: Supports storage and ad-hoc reporting on streaming data (Page 18). Compute Engine (option D) is a general-purpose computing service but is not specifically mentioned in the document for streaming analytics, making it an incorrect choice in this context.

Answer 867

C The document describes Pub/Sub’s role in a streaming pipeline as ingesting and distributing data, ensuring reliability and providing buffering (Page 19). It is not used for storing data (option A, which is more suited to BigQuery or Bigtable), processing data (option B, handled by Dataflow), or providing machine learning capabilities (option D, associated with services like Vertex AI).

Answer 868

B The document lists several real-time applications of streaming analytics, including "fraud detection" (Page 10). This involves processing data as it arrives to identify anomalies instantly. Generating monthly sales reports (option A) and scheduling batch jobs (option D) are associated with batch processing, while archiving historical data (option C) pertains to data storage, not real-time analytics.

Answer 869

C Pub/Sub is explicitly stated as a service, not software, meaning nothing needs to be installed to use it. It provides a fully managed data distribution and delivery system. It contributes qualities such as availability, durability, and scalability to data engineering solutions. By default, Pub/Sub ensures "at least once delivery," and exactly-once delivery is only available for pull messages if configured

Answer 870

C The story of Pub/Sub revolves around two data structures: the Topic and the Subscription, which exist independently of workers or subscribers. The Pub/Sub client that creates the Topic is the Publisher, and the client that creates the Subscription is the Subscriber. A Publisher sends messages to a Topic, and to receive messages published to a topic, you must create a subscription to that topic. The subscription connects the topic to a subscriber application. A topic can have multiple subscriptions, but a given subscription belongs to a single topic

Answer 871

B In the Pull model, the client (subscriber) periodically calls for messages and must explicitly acknowledge the message as a separate step, typically after processing to ensure the message isn't lost if the system goes down. In the Push model, the Pub/Sub infrastructure calls the registered webhook, and the subscriber just responds with 'status 200 ok' for the HTTP call to indicate successful message delivery. Messages are stored for up to 7 days in the Pull model if not acknowledged

Answer 872

B By default, Pub/Sub ensures "at least once delivery". It explicitly states that latency can happen, messages can be delivered in any order (especially with a large backlog), and duplication of messages can happen. While message ordering can be enabled under specific conditions (same ordering key and region), it's not a default guarantee across the board and might increase latency. Pub/Sub does not automatically de-duplicate messages; Dataflow can be used in conjunction with Pub/Sub for de-duplication based on message ID

Answer 873

C Pub/Sub helps with streaming resilience by acting as a buffer or backlog. It receives and holds data until the application has resources to handle it, either through processing the existing backlog of work or by autoscaling to meet the demand. This prevents systems from being overloaded by large volumes of transactions, as an intermediary allows applications to feed messages only as fast as they can process them. Sizing an application to handle the highest traffic spike alone is wasteful and can lead to non-deterministic behavior under extreme load

Answer 874

A, B y C Pub/Sub is designed for high availability, durability (messages stored for up to 7 days and replicated), and scalability (handles millions of messages per second). Automatic schema migration is not a feature of Pub/Sub

Answer 875

C In a push subscription, Pub/Sub automatically delivers messages to a subscriber’s HTTP endpoint. In a pull subscription, the subscriber must poll Pub/Sub to retrieve messages

Answer 876

B ✅ Opción B: The message is redelivered to the same or another subscriber. Esta es la respuesta correcta porque es el comportamiento fundamental que garantiza que los mensajes no se pierdan. ¿Qué es el ackDeadline? Es un "plazo de confirmación" o temporizador. Cuando un suscriptor recibe un mensaje, Pub/Sub inicia una cuenta atrás (por defecto, 10 segundos). El suscriptor tiene ese tiempo para procesar el mensaje y enviar una señal de confirmación (ack, de acknowledgment) de vuelta a Pub/Sub. ¿Qué pasa si el plazo expira? Si Pub/Sub no recibe la confirmación (ack) antes de que termine el plazo, asume que el suscriptor falló en procesar el mensaje (quizás se bloqueó, se desconectó o tardó demasiado). La Redeliveración: Para garantizar que el mensaje se procese, Pub/Sub lo vuelve a poner disponible. Otro suscriptor del mismo grupo (o el mismo, si vuelve a estar disponible) podrá recibirlo para intentar procesarlo de nuevo. Este mecanismo se conoce como entrega "al menos una vez" (at-least-once delivery). Analogía: Imagina que prestas un libro a un amigo y le dices "devuélvemelo o avísame que lo tienes en una hora". Si pasa la hora y no sabes nada de él, asumes que algo ha pasado y se lo reclamas de nuevo o se lo ofreces a otro amigo que también quería leerlo. ❌ Opción A: The message is deleted. Esto es incorrecto. El mensaje solo se elimina de la cola de la suscripción después de que Pub/Sub recibe una confirmación (ack) exitosa. Borrarlo sin esa confirmación significaría perder datos, lo cual va en contra del propósito del servicio. ❌ Opción C: The subscription is paused. Esto es incorrecto. Pausar una suscripción es una acción administrativa que un usuario o un sistema de control puede realizar manualmente. No es una respuesta automática a un fallo en el procesamiento de un solo mensaje. Sería una medida demasiado drástica. ❌ Opción D: The message is moved to cold storage. Esto es incorrecto, aunque describe una funcionalidad relacionada llamada "Dead-Letter Queue" (DLQ). El comportamiento inmediato tras expirar el ackDeadline es la redeliveración (Opción B). Si un mensaje se intenta entregar repetidamente (por ejemplo, 10 veces) y nunca se confirma, puedes configurar una cola de mensajes fallidos (DLQ) para que el mensaje se envíe allí en lugar de seguir intentándolo indefinidamente. Por lo tanto, moverlo a otro lugar es un paso secundario y opcional, no la primera acción que ocurre.

Answer 877

A y D Opción A: Un tema puede tener múltiples suscripciones (Correcta) ✅ Esta afirmación es correcta y describe uno de los pilares del modelo Pub/Sub. Explicación: Un tema (topic) es un canal con nombre al que los publicadores (publishers) envían mensajes. Una suscripción (subscription) es un "buzón" que recibe los mensajes de un tema específico. El diseño de Pub/Sub se basa en un patrón de "uno a muchos" (o "fan-out"). Esto significa que un único tema puede enviar copias de cada mensaje a múltiples suscripciones. Cada suscripción recibe los mensajes de forma independiente para que diferentes aplicaciones puedan procesar la misma información de manera distinta y a su propio ritmo. Analogía: Imagina que un tema es una emisora de radio 📻. Múltiples personas (las suscripciones) pueden sintonizar esa misma emisora para escuchar la misma transmisión, pero cada una lo hace con su propia radio y controla su propio volumen. Opción B: Una suscripción puede pertenecer a múltiples temas (Incorrecta) ❌ Esta afirmación es incorrecta. Explicación: Una suscripción está vinculada de forma exclusiva a un único tema. No puedes crear una suscripción que reciba mensajes de varios temas a la vez. Si necesitas recibir mensajes de dos temas diferentes, debes crear dos suscripciones separadas, una para cada tema. La relación es: un tema puede tener muchas suscripciones, pero una suscripción pertenece solo a un tema. Analogía: Siguiendo con el ejemplo anterior, una radio sintonizada (la suscripción) solo puede captar una frecuencia (el tema) a la vez. No puedes escuchar dos emisoras distintas simultáneamente con el mismo sintonizador. Opción C: Cada suscripción entrega mensajes solo a los suscriptores creados después de que se publicó el mensaje (Incorrecta) ❌ Esta afirmación es incorrecta y describe el comportamiento de forma imprecisa. Explicación: Una suscripción recibe y almacena los mensajes publicados en su tema después de que la suscripción ha sido creada. Pub/Sub retiene los mensajes que no han sido confirmados (acknowledged) por un suscriptor durante un período de tiempo configurable (hasta 7 días). Esto significa que si un mensaje se publica en un tema, la suscripción lo guardará. Si una aplicación (un suscriptor) se conecta a esa suscripción más tarde, recibirá ese mensaje pendiente. Por lo tanto, el suscriptor puede procesar mensajes que se publicaron antes de que él se conectara. Además, la función "Seek" permite a una suscripción "rebobinar" y volver a procesar mensajes desde un punto en el tiempo pasado. Opción D: Los suscriptores pueden filtrar mensajes según los atributos (Correcta) ✅ Esta afirmación es correcta y es una funcionalidad muy útil de Pub/Sub. Explicación: Al publicar un mensaje, puedes añadirle metadatos en forma de atributos (pares clave-valor). Luego, al crear una suscripción, puedes definir un filtro usando una sintaxis similar a SQL. La suscripción solo entregará a sus suscriptores los mensajes cuyos atributos cumplan con la condición del filtro. Esto permite que las aplicaciones se suscriban solo a la información que les interesa sin tener que recibir y descartar mensajes irrelevantes, ahorrando así costes y mejorando la eficiencia. Ejemplo: Un tema llamado ventas recibe mensajes de ventas de todo el mundo. Un mensaje podría tener el atributo {"país": "España"}. Un equipo en Madrid podría crear una suscripción con el filtro attributes.país = "España" para recibir y procesar únicamente las ventas ocurridas en España.

Answer 878

B Message filtering allows a subscription to receive only messages that match certain attribute criteria, reducing unnecessary message processing and improving efficiency

Answer 879

C La Arquitectura Correcta: Fan-Out El modelo de Pub/Sub se basa en la separación entre quien envía el mensaje (el publicador) y quien lo recibe (el suscriptor). Un Tema (Topic) es un canal con nombre al que los publicadores envían mensajes. Una Suscripción (Subscription) es un punto de acceso a los mensajes de un tema. La clave es que un único tema puede tener múltiples suscripciones. Cuando se publica un mensaje en el tema, Pub/Sub entrega una copia de ese mensaje a cada una de las suscripciones de forma independiente. C. Crear un tema y dos suscripciones separadas - ✅ Correcta Esta es la solución idiomática y correcta. Un Tema (orders-topic): El sistema de e-commerce publica un único mensaje por cada nuevo pedido a este tema. Suscripción 1 (inventory-sub): El servicio de Inventario se conecta a esta suscripción. Recibirá una copia de todos los mensajes de pedidos. Suscripción 2 (analytics-sub): El servicio de Analítica se conecta a esta otra suscripción. También recibirá su propia copia de todos los mensajes de pedidos. Ventajas: Independencia: Cada servicio procesa los mensajes a su propio ritmo. Si el servicio de Analítica se cae o va lento, no afecta en absoluto al servicio de Inventario. Desacoplamiento: El publicador no sabe (ni le importa) cuántos servicios están escuchando sus mensajes. Escalabilidad: Si en el futuro se necesita un nuevo servicio de "Envíos", simplemente se crea una tercera suscripción al mismo tema, sin tener que modificar el publicador. Por qué las otras opciones son incorrectas A. Un tema y una suscripción para ambos - ❌ Incorrecta Este es un patrón de "consumidores en competencia". Si ambos servicios escuchan de la misma suscripción, competirán por los mensajes. Cuando llegue un mensaje de pedido, solo uno de los dos servicios lo recibirá, no ambos. B. Dos temas - ❌ Incorrecta Aunque técnicamente funcionaría, es un mal diseño. Obliga al publicador a saber quiénes son todos sus consumidores y a enviar el mismo mensaje varias veces. Esto crea un acoplamiento fuerte y va en contra del propósito de Pub/Sub. D. Usar atributos en una única suscripción - ❌ Incorrecta Este planteamiento es erróneo por la misma razón que la opción A: con una sola suscripción, solo un servicio recibirá el mensaje en primer lugar, por lo que el otro nunca tendrá la oportunidad de verlo o filtrarlo.

Answer 880

B The Pull model is designed for scenarios where the subscriber controls the flow of messages. The worker applications will "pull" a message (or a batch of messages) only when they are ready to process them. This prevents Pub/Sub from "pushing" messages to a worker that is already busy, as described in slide 10 and 15. A Push subscription would send messages proactively, potentially overwhelming the workers.

Answer 881

A y C Una aplicación "resiliente" es aquella que está preparada para los fallos y para las características inherentes del sistema que utiliza. En el caso de Pub/Sub, su diseño prioriza la escalabilidad y la durabilidad (asegurarse de que los mensajes no se pierdan) por encima de otras garantías más estrictas. ✅ Respuestas Correctas A) Mensajes que llegan en un orden diferente al que fueron publicados Por qué es correcto: Por defecto, Pub/Sub no garantiza el orden de los mensajes. Es un sistema distribuido a escala global, y forzar que los mensajes se procesen en el mismo orden en que se publicaron crearía un cuello de botella y limitaría enormemente su rendimiento. Un mensaje publicado desde Asia puede llegar a un suscriptor antes que un mensaje publicado unos segundos antes desde Europa. Una aplicación resiliente nunca debe asumir que los mensajes llegarán en orden. Si el orden es crítico para el negocio, la aplicación debe ser diseñada para manejarlo, por ejemplo, revisando una marca de tiempo (timestamp) dentro de los datos del propio mensaje. C) Mensajes que se entregan más de una vez (duplicación) Por qué es correcto: La garantía de entrega por defecto de Pub/Sub es "al menos una vez" (at-least-once). Esto significa que Pub/Sub hará todo lo posible para entregar un mensaje, lo que puede incluir enviarlo de nuevo si no recibe una confirmación (ack) del suscriptor a tiempo. Ejemplo del mecanismo: Pub/Sub envía el mensaje M1 al suscriptor. El suscriptor recibe M1 y lo procesa correctamente. Antes de que el suscriptor pueda enviar la confirmación (ack) a Pub/Sub, hay un fallo de red o el suscriptor se reinicia. Pub/Sub nunca recibe el ack, por lo que asume que el mensaje no se entregó y lo vuelve a enviar. El suscriptor recibe el mensaje M1 por segunda vez. Una aplicación resiliente debe ser idempotente, lo que significa que procesar el mismo mensaje varias veces produce el mismo resultado que procesarlo una sola vez. Por ejemplo, si el mensaje es "insertar usuario con ID 123", la aplicación debería verificar primero si el usuario 123 ya existe antes de intentar insertarlo de nuevo. ❌ Respuestas Incorrectas B) Entrega exactamente una vez (exactly-once) de cada mensaje Por qué es incorrecto: Esto es lo contrario de lo que Pub/Sub garantiza por defecto. Lograr una entrega "exactamente una vez" es un problema complejo en sistemas distribuidos y requiere lógica adicional, a menudo implementada en el lado del suscriptor o usando servicios de más alto nivel como Cloud Dataflow, que pueden usar Pub/Sub como fuente y eliminar duplicados. El suscriptor no puede esperar este comportamiento, sino que debe prepararse para lo contrario (duplicados). D) Una garantía de que los mensajes se entregarán en 100 milisegundos Por qué es incorrecto: Pub/Sub es un servicio de muy baja latencia, pero no ofrece una garantía de tiempo de entrega (SLA) tan estricta. La latencia puede variar debido a la carga de la red, la ubicación geográfica del publicador y el suscriptor, y la carga del propio suscriptor. Una aplicación resiliente no debe diseñarse asumiendo una latencia máxima fija, ya que podría fallar si un mensaje tarda, por ejemplo, 150 ms en llegar. Debe poder tolerar latencias variables.

Answer 882

A Slide 27 explicitly states the conditions for message ordering. The publisher must include an ordering_key with the messages, and the corresponding subscription must be configured to enable message ordering. Messages with the same key are then delivered in order. The other options are incorrect; ordering works with both Push and Pull, requires the same region (not zone), and is fully supported by the client libraries.

Answer 883

B Pub/Sub messages support attributes, which are key-value string pairs intended for exactly this purpose. As shown on slides 12 and 21, you can publish a message with attributes. Subscribers can then create their subscriptions with a filter based on these attributes, allowing Pub/Sub to discard non-matching messages efficiently before they are even delivered to the subscriber, saving on egress and processing costs.

Answer 884

C Google Cloud Pub/Sub is designed to decouple systems, allowing asynchronous communication through messages, which enhances scalability and reliability in data engineering.

Answer 885

B En Pub/Sub, la diferencia fundamental entre los modelos de entrega radica en quién tiene la iniciativa de mover el mensaje. Aquí te explico por qué la B es la que describe esa acción "activa". En el modelo Pull, el suscriptor es el que manda en el flujo. Es "la buena" por estas razones: Iniciativa del cliente: El suscriptor realiza una solicitud HTTPS al servicio de Pub/Sub (el método pull) para pedir mensajes. Si no pide nada, Pub/Sub no le envía nada. Control de flujo: Es ideal para aplicaciones que necesitan procesar mensajes a su propio ritmo (por ejemplo, si el procesamiento es muy pesado y el suscriptor no quiere verse inundado de datos). Acuse de recibo: Una vez que el suscriptor recibe y procesa el mensaje, debe enviar un ACK (acknowledgement) para que Pub/Sub sepa que puede borrarlo. Opción,Por qué es incorrecta A (Push model),"En el modelo Push, Pub/Sub es el que toma la iniciativa. Envía automáticamente el mensaje a una URL (webhook) configurada. El suscriptor no lo ""pide""; el mensaje le ""llega"" sin previo aviso." C (Both),"No puede ser ""ambos"" porque son arquitecturas opuestas. En una tú vas a buscar el pan (Pull), en la otra el repartidor te lo deja en la puerta (Push)." D (Neither),Es incorrecta porque Pub/Sub siempre necesita un mecanismo de entrega definido. Los mensajes no se entregan por arte de magia; o los empujas o los tiras. Comparativa visual: Push vs Pull Para que lo recuerdes fácilmente en el examen: Push: Es como un correo electrónico (te llega la notificación al móvil en cuanto entra al servidor). Pull: Es como ir a un casillero de correos (los mensajes se quedan ahí guardados hasta que tú decides ir físicamente a recogerlos). Resumen para el examen: PULL: El cliente llama a la API. Ideal para procesamientos largos o "batch". PUSH: Pub/Sub llama al cliente (URL). Ideal para microservicios rápidos y arquitecturas serverless como Cloud Run o Cloud Functions.

Answer 886

C The fan-out pattern enables a single topic to distribute the same message to multiple subscriptions, allowing different systems to process the same data concurrently.

Answer 887

A Pub/Sub’s ability to handle massive throughput, as used in Google’s global web indexing, highlights its scalability for large-scale data engineering

Answer 888

C Dataflow integrates with Pub/Sub to provide exactly-once processing and deduplication based on message IDs, ensuring data integrity in real-time pipelines.

Answer 889

A, B, C y D The sources explicitly state that challenges with processing streaming data include scalability, fault tolerance, deciding on the appropriate model (streaming or repeated batch), and the difficulty of aggregating an unbounded set of data, such as taking an average.

Answer 890

C Dataflow is described as providing a serverless service for processing both batch and streaming data. For streaming, it is highlighted for its scalability and low latency processing pipeline for incoming messages

Answer 891

C Session windows are specifically defined by a minimum gap duration, with their timing triggered by another element. They are intended for situations with bursty communication, like a web session, where a user's activity might have a timeout period after which the window flushes

Answer 892

D Explicación del Concepto: ¿Qué es una "Watermark"? Imagina que estás procesando eventos en tiempo real, como clics en un sitio web, y quieres contar cuántos clics hubo en cada minuto. El problema es que, debido a retrasos en la red, un clic que ocurrió a las 10:00:55 podría llegar a tu sistema a las 10:02:10. Esto se conoce como datos tardíos (late data). La pregunta fundamental es: ¿cuándo puede el sistema estar lo suficientemente seguro de que ha recibido todos los datos de la ventana de "10:00 a 10:01" para poder calcular el total y emitir un resultado? Aquí es donde entra la marca de agua (watermark). Es una heurística, una especie de "reloj de eventos" que le dice al sistema: "Creo que todos los eventos que ocurrieron antes de este momento ya han llegado". Es una marca que avanza en el tiempo a medida que el sistema procesa los datos. ✔️ Por qué la opción D es la correcta Esta opción describe perfectamente el comportamiento de la marca de agua: Cálculo continuo: La marca de agua no es un valor estático. El sistema la actualiza constantemente basándose en las marcas de tiempo de los eventos que va procesando. Seguimiento del progreso: Avanza para reflejar hasta qué punto en el "tiempo del evento" ha progresado el sistema. Decisión de cierre de ventana: El sistema utiliza esta marca de agua para decidir cuándo cerrar una ventana de tiempo. Por ejemplo, solo cuando la marca de agua supera las 10:01:00, el sistema activará el cálculo para la ventana de las 10:00, asumiendo que es poco probable que lleguen más datos para ese período. Este mecanismo es un compromiso inteligente entre latencia (esperar demasiado para emitir un resultado) y completitud (emitir un resultado demasiado pronto sin tener todos los datos). ❌ Por qué las otras opciones son incorrectas A. Cierra la ventana inmediatamente y descarta los datos tardíos: Esto sería un sistema muy simple que no maneja datos tardíos en absoluto, lo que llevaría a resultados incorrectos e incompletos. El propósito principal de las marcas de agua es precisamente evitar esto. B. Reprocesa todos los datos históricos cuando llega un mensaje tardío: Sería computacionalmente inviable y extremadamente costoso. Imagine tener que recalcular horas o días de datos cada vez que llega un solo evento con unos segundos de retraso. Los sistemas de streaming están diseñados para evitar este tipo de reprocesamiento masivo. C. Requiere que el usuario ajuste manualmente las marcas de tiempo: Esto es imposible en un sistema automatizado de alto volumen. El cálculo de la marca de agua es un proceso automático fundamental del motor de procesamiento, no una tarea manual.

Answer 893

B When a trigger is set, you must choose between two accumulation modes: "accumulate" or "discarding". These modes dictate how results are processed when additional events arrive or when a trigger fires multiple times within the same window

Answer 894

C In streaming data, since the data is unbounded, windowing helps divide the stream into manageable time-based chunks, enabling operations like aggregations (e.g., averages).

Answer 895

A, B y D Dataflow supports three main types of windows: Fixed (Tumbling), Sliding (Hopping), and Session windows. "Overlapping Windows" is not a separate category; overlapping behavior is a feature of sliding windows.

Answer 896

C The watermark is a threshold that helps Dataflow estimate how far behind the pipeline is and whether all relevant data for a window has arrived.

Answer 897

A, B y C ¿Qué es un Trigger? En Dataflow, cuando agrupas datos en ventanas (por ejemplo, "todos los eventos de 1:00 PM a 1:05 PM"), un trigger (disparador) es la regla que le dice al sistema cuándo debe calcular y emitir el resultado de esa ventana. ✅ Tipos de Triggers Válidos (A, B y C) Estos tres tipos de triggers representan las formas fundamentales de decidir cuándo emitir resultados. A) AfterWatermark (Basado en el tiempo del evento ⏱️): Este es el trigger por defecto. Se activa cuando la "marca de agua" (watermark) de Dataflow supera el final de la ventana. La marca de agua es la estimación del sistema de que ya han llegado todos los datos con una marca de tiempo (timestamp) anterior a ese punto. En resumen, intenta esperar hasta que los datos de la ventana estén "completos" antes de procesarlos. B) AfterCount (Basado en el número de elementos 🔢): Este es un nombre simplificado para un trigger que se activa después de que la ventana haya acumulado un número específico de elementos. Por ejemplo, "emite un resultado cada vez que recolectes 100 elementos", sin importar el tiempo que haya pasado. Es un trigger impulsado por el volumen de datos. C) AfterProcessingTime (Basado en el tiempo de procesamiento ⏰): Este trigger se activa después de que haya transcurrido una cantidad de tiempo real (del reloj) desde que llegó el primer elemento a la ventana. Por ejemplo, "emite un resultado cada 10 segundos". Se enfoca en la puntualidad del resultado, incluso si los datos de la ventana están incompletos. ❌ Tipo de Trigger No Válido (D) D) AfterFixedSize: Este no es un tipo de trigger estándar en Dataflow o Apache Beam. Si bien puedes disparar por el número de elementos (AfterCount), no existe un trigger predefinido que se active basado en el tamaño total en bytes de los datos acumulados en la ventana (por ejemplo, "disparar después de 10 MB de datos").

Answer 898

C El rol de los modos de acumulación En Dataflow (Apache Beam), cuando trabajas con datos en streaming (ilimitados), los agrupas en ventanas (windows). Un disparador (trigger) define cuándo se emite un resultado para una ventana. Un trigger puede dispararse varias veces para la misma ventana, por ejemplo, cada vez que llega un nuevo dato. Cada vez que un trigger se dispara, emite un panel (pane) de datos. El modo de acumulación define la relación entre los paneles nuevos y los paneles que se emitieron previamente para esa misma ventana. Hay dos modos principales: ACCUMULATING (Acumulando): El panel nuevo incluye todos los datos acumulados desde el inicio de la ventana. Es como ver el saldo total de tu cuenta bancaria, que incluye las transacciones anteriores más las nuevas. DISCARDING (Descartando): El panel nuevo solo contiene los datos nuevos que han llegado desde que el trigger se disparó por última vez. Es como ver solo las últimas transacciones, no el saldo total. En resumen, el modo de acumulación controla el estado de los resultados de una ventana a lo largo de sus múltiples disparos. ¿Por qué las otras opciones son incorrectas? A) Para definir la frecuencia con la que se cierra una ventana: Esto lo define la estrategia de ventanas (ej. FixedWindows, SlidingWindows), no el modo de acumulación. ❌ B) Para determinar cómo se manejan los datos tardíos: Esto se controla con la opción withAllowedLateness() en la configuración de la ventana. ❌ D) Para eliminar datos duplicados: La eliminación de duplicados se realiza con transformaciones específicas como Distinct() o lógica personalizada, no es la función del modo de acumulación. ❌

Answer 899

A, B y D The main challenges are scalability (handling growing data volumes), fault tolerance (ensuring reliability as scale increases), and timing/latency (dealing with late-arriving data and processing delays). Data encryption is important but not highlighted as a core streaming challenge in the material

Answer 900

B Windowing divides an unbounded data stream into finite, time-based chunks, which is essential for performing aggregations (like averages) on streaming data

Answer 901

B Fixed (Tumbling) windows are consistent, non-overlapping time intervals. Sliding (Hopping) windows can overlap, as new windows open at regular intervals that may be shorter than the window length.

Answer 902

B A watermark tracks the difference between when data is expected (event time) and when it actually arrives (processing time), helping Dataflow decide when to close a window and handle late data.

Answer 903

C Para entenderlo, usemos una analogía. Imagina que una ventana de tiempo es un tren que sale a una hora programada. El watermark es el reloj de la estación que indica cuándo debe partir el tren. ✅ Respuesta Correcta C. The default is to discard it, but you can configure the pipeline to reprocess the window with late data. (Por defecto se descarta, pero puedes configurar la canalización para reprocesar la ventana con datos tardíos). Comportamiento por defecto (descartar): Si el tren (window) de las 10:00 ya ha partido (el watermark ha pasado de las 10:00), y un pasajero (un mensaje) para ese tren llega a las 10:05, por defecto, el pasajero pierde el tren y su billete es descartado. Comportamiento configurable (reprocesar): Dataflow (basado en Apache Beam) es flexible. Te permite configurar una "tolerancia por retraso" (allowedLateness). Es como anunciar que "el tren de las 10:00 esperará a los pasajeros que lleguen tarde hasta las 10:15". Si el pasajero llega a las 10:05, se le permite subir al tren (el dato se incluye en la ventana y esta se vuelve a procesar). 🚂 ❌ Respuestas Incorrectas A. It is always discarded (Siempre se descarta): Incorrecto por la palabra "siempre". Es solo el comportamiento por defecto, no una regla inquebrantable. B. It is always included in the window (Siempre se incluye en la ventana): Incorrecto también por "siempre". Si no configuras explícitamente la tolerancia por retraso, el dato sí será descartado. D. The message is sent to Pub/Sub for reprocessing (El mensaje se envía a Pub/Sub para ser reprocesado): Esto no es un comportamiento nativo o automático de Dataflow. Aunque un ingeniero podría diseñar un patrón personalizado para enviar datos tardíos a una cola de "mensajes fallidos" en Pub/Sub, no es la forma en que el servicio gestiona los datos tardíos de manera predeterminada.

Answer 904

C Explicación: ¿Por qué la C es la correcta? El requisito clave es agrupar eventos basándose en períodos de actividad de un usuario, separados por pausas o inactividad. Las ventanas de sesión (Session windows) están diseñadas específicamente para este escenario. Así es como funcionan: Agrupan por clave: Las ventanas de sesión operan por clave, en este caso, por player_id. Esto asegura que las acciones de un jugador nunca se mezclen con las de otro. Brecha de inactividad (Gap Duration): Se define una "brecha de duración". La ventana de un jugador permanece abierta siempre que la diferencia de tiempo entre eventos consecutivos sea menor que esta brecha. Cierre de la ventana: Si un jugador está inactivo y pasa más tiempo que la brecha definida (en este caso, 10 minutos) antes de su siguiente acción, la sesión anterior se cierra. La nueva acción iniciará una sesión completamente nueva. Este comportamiento modela exactamente una "sesión de usuario" en el mundo real, que termina tras un período de inactividad. 🎮 ¿Por qué las otras opciones son incorrectas? A) Ventanas fijas (Fixed/Tumbling): Estas ventanas dividen el tiempo en intervalos fijos y no superpuestos (p. ej., 10:00-10:10, 10:10-10:20). El problema es que una única sesión de un jugador podría ser dividida arbitrariamente si cruza el límite de una de estas ventanas. ❌ B) Ventanas deslizantes (Sliding/Hopping): Estas ventanas se superponen y son útiles para calcular agregados móviles (p. ej., una media móvil de 10 minutos). Un solo evento de un jugador aparecería en múltiples ventanas, lo cual no es el objetivo aquí. ❌ D) Ventana global con un trigger AfterCount: Una ventana global trata todos los datos de una clave como un único grupo infinito. El disparador AfterCount emitiría un resultado después de un número determinado de eventos, no basándose en el tiempo de inactividad. Esto no cumple con el requisito de cerrar la ventana tras 10 minutos sin actividad. ❌

Answer 905

C As shown on slides 9, 10, and 11, the pipeline logic itself is responsible for handling event time. The developer must write code (a PTransform like a DoFn) to read the message data, extract the custom timestamp, and explicitly re-assign it to the element. Dataflow does not do this automatically, and it is not a configuration in Pub/Sub or related to allowed_lateness (which deals with data arriving after the watermark).

Answer 906

B A watermark is a concept central to handling out-of-order data and latency in streaming systems. As explained on slides 19 and 20, it is Dataflow's notion of progress in event time. It provides a flexible boundary, allowing the system to wait for a reasonable amount of "lag time" before it decides a window is complete and can be processed (or "fired"). It does not handle exactly-once processing (slide 12, which uses message IDs) or schema validation.

Answer 907

A y B ¿Por qué las opciones A y B son correctas? ✅ Tanto A como B describen de manera precisa los dos modos de acumulación disponibles en Dataflow (y Apache Beam). Piensa en ellos como dos formas de presentar los resultados cada vez que un trigger (disparador) se activa para una misma ventana de tiempo. A) En el modo DISCARDING (Descartando), cada panel contiene solo los elementos nuevos que han llegado desde la última vez que se activó el disparador. Esto es correcto. Como su nombre indica, el estado anterior se "descarta". Cada vez que el trigger se dispara, el resultado (llamado pane o panel) que se emite es un delta, es decir, contiene únicamente los nuevos datos que se han procesado desde la última emisión. Es útil cuando solo te interesan los cambios o incrementos. B) En el modo ACCUMULATING (Acumulando), cada panel contiene todos los elementos del disparador actual más los elementos que se guardaron de disparos anteriores en la misma ventana. Esto también es correcto. En este modo, el estado se "acumula". El panel que se emite contiene no solo los elementos nuevos, sino todo lo que se había visto hasta ese momento en la ventana. Cada panel es una visión completa y actualizada del estado total de la ventana. Imagina que estás contando coches que pasan por una carretera en una ventana de 10 minutos. Modo DISCARDING: A los 2 minutos, el trigger se dispara y te dice: "Han pasado 5 coches". A los 4 minutos, se dispara de nuevo y dice: "Han pasado 3 coches más". Solo te da lo nuevo. Modo ACCUMULATING: A los 2 minutos, te dice: "Han pasado 5 coches". A los 4 minutos, se dispara y dice: "En total, han pasado 8 coches". Te da el acumulado. ¿Por qué las opciones C y D son incorrectas? ❌ C) El modo ACCUMULATING es el predeterminado y debe usarse con ventanas de sesión. Esto es incorrecto por dos razones. Primero, el modo predeterminado en Dataflow es en realidad DISCARDING, no ACCUMULATING. Segundo, no hay ninguna regla que obligue a usar el modo ACCUMULATING con ventanas de sesión (Session windows). Se puede elegir el modo que mejor se adapte al problema. D) El modo DISCARDING descarta todos los datos tardíos que llegan después de la marca de agua (watermark). Esto es incorrecto porque mezcla dos conceptos diferentes: el modo de acumulación y el manejo de datos tardíos. El modo de acumulación (DISCARDING o ACCUMULATING) define el contenido de los paneles cuando un trigger se dispara. El manejo de datos tardíos se configura por separado con la opción .withAllowedLateness(). Si permites datos tardíos, un trigger podría dispararse de nuevo y el modo DISCARDING simplemente emitiría un panel con esos datos tardíos, no los descartaría por sí mismo.

Answer 908

C Para entender por qué, primero repasemos tres conceptos clave en Dataflow: Ventana de tiempo (window): Es un intervalo de tiempo fijo en el que se agrupan los datos para su procesamiento. Por ejemplo, "todos los eventos que ocurrieron entre las 10:00 y las 10:05". Marca de agua (watermark): Es una estimación que hace Dataflow para saber "hasta qué punto en el tiempo han llegado todos los datos". Cuando la marca de agua supera el final de una ventana (pasa de las 10:05), Dataflow asume que ya ha recibido todos los datos de esa ventana y la "cierra" para procesar los resultados (hacer una suma, un conteo, etc.). Datos tardíos (late data): Es cualquier dato cuyo timestamp (la hora en que ocurrió) pertenece a una ventana que ya ha sido cerrada por la marca de agua. Con esto en mente, analicemos las opciones. Opción C: El elemento es considerado "dato tardío" y es descartado por el pipeline (Correcta) ✅ Esta afirmación es correcta. Explicación: Por defecto, el comportamiento de un pipeline de Dataflow es priorizar la consistencia y la finalización de los cálculos. Una vez que la marca de agua (watermark) ha pasado el final de una ventana, el pipeline considera que esa ventana está cerrada y los resultados calculados son finales. Si un elemento que pertenece a esa ventana llega después, se clasifica como "dato tardío" (late data) y, para no alterar los resultados ya emitidos, simplemente se descarta. Aclaración: Aunque este es el comportamiento por defecto, Dataflow permite configurar estrategias para manejar los datos tardíos, como usar allowedLateness para mantener la ventana abierta por un tiempo extra o enviar los datos tardíos a otro lugar para un análisis posterior. Pero la pregunta se refiere al comportamiento predeterminado. Analogía: Imagina que un tren (la ventana) tiene programada su salida a las 10:05 (el fin de la ventana). A las 10:05, el tren cierra sus puertas y se va (la watermark avanza y la ventana se cierra). Si un pasajero (el dato) llega al andén a las 10:06, se considera un pasajero tardío. Por defecto, ha perdido el tren y se queda fuera (el dato es descartado). Opción A: Es procesado inmediatamente en una nueva ventana separada (Incorrecta) ❌ Esta afirmación es incorrecta. Explicación: La ventana a la que pertenece un elemento está determinada por su propio timestamp (su hora de evento). No se le puede asignar arbitrariamente a una ventana nueva o diferente solo porque llegó tarde. Su "sitio" estaba en la ventana que ya se cerró. Opción B: Causa que la marca de agua se mueva hacia atrás y la ventana se reabra (Incorrecta) ❌ Esta afirmación es incorrecta. Explicación: La marca de agua está diseñada para avanzar siempre hacia adelante (monotonically increasing). Moverla hacia atrás rompería la lógica fundamental del procesamiento de flujos de datos y podría causar que resultados ya emitidos se recalculen o invaliden, generando inconsistencias. La watermark es una garantía de progreso, no algo que pueda retroceder. Opción D: El pipeline automáticamente almacena todos los datos tardíos y los procesa en un único lote al final del día (Incorrecta) ❌ Esta afirmación es incorrecta. Explicación: No existe tal comportamiento automático o por defecto en Dataflow. Almacenar datos tardíos de forma indefinida podría consumir una cantidad ilimitada de memoria y recursos. Si bien un desarrollador podría diseñar un sistema para capturar los datos tardíos y procesarlos con otro trabajo por lotes, esto sería una lógica personalizada, no una función predeterminada del pipeline.

Answer 909

C Processing streaming data in Dataflow presents several challenges, including scalability (handling large volumes of data), fault tolerance (ensuring system reliability), model complexity (managing processing logic), timing (synchronizing data streams), and handling late data (managing delayed data arrivals). Batch processing, however, is a separate processing paradigm that involves handling finite datasets in batches, not a challenge specific to streaming data processing. Dataflow’s streaming capabilities are designed to process unbounded data in real time, contrasting with batch processing.

Answer 910

A Dataflow supports three primary window types for streaming data: fixed (tumbling), sliding (hopping), and session windows. Fixed windows, also known as tumbling windows, divide data into non-overlapping time intervals, such as every hour or every day, making them suitable for consistent time-based aggregations. Sliding windows allow overlapping intervals (e.g., a 30-minute window computed every 5 minutes), session windows are defined by gaps in data activity (e.g., for bursty web sessions), and global windows encompass the entire dataset, which is less common in streaming scenarios.

Answer 911

B 🌊 El concepto clave: Marcas de agua (Watermarks) Para entender esto, primero hay que saber qué considera Dataflow (y Apache Beam, el framework en el que se basa) como un "dato tardío". Dataflow procesa datos en streaming basándose en el tiempo del evento (la hora en que el evento ocurrió realmente, no la hora en que el sistema lo procesó). Para saber cuándo una "ventana" de tiempo (ej. "todos los datos de 10:00 a 10:05") está completa, usa una marca de agua (watermark). La marca de agua es la estimación del sistema de que "he recibido todos los datos cuyo tiempo de evento es anterior a X". Cuando la marca de agua supera el final de una ventana (ej. llega a las 10:05), Dataflow considera esa ventana cerrada y calcula el resultado final (ej. la suma de todas las ventas de esa ventana). Un dato tardío es un dato que pertenece a esa ventana (ej. un evento de las 10:03) pero que llega al sistema después de que la marca de agua ya haya superado las 10:05 y la ventana se haya cerrado. ✅ B. Discard the late data (La respuesta correcta) Por defecto, el comportamiento de Dataflow es priorizar la rapidez y la finalización de los resultados. Comportamiento por defecto: La "latencia permitida" (allowedLateness) por defecto es cero. Qué significa: En cuanto la marca de agua pasa el final de la ventana, esta se cierra, los resultados se emiten y el estado de esa ventana se elimina para ahorrar memoria. Consecuencia: Cualquier dato que llegue después de ese momento y que pertenezca a esa ventana ya cerrada, es simplemente descartado y no se procesa. ❌ Las respuestas incorrectas A. Reprocess the window with the late data (Volver a procesar la ventana con los datos tardíos) Por qué es incorrecta: Este no es el comportamiento por defecto. Es un comportamiento que puedes configurar explícitamente usando la opción .withAllowedLateness(). Si configuras, por ejemplo, .withAllowedLateness(Duration.standardMinutes(2)), Dataflow mantendrá el estado de la ventana durante 2 minutos adicionales después de que la marca de agua la cierre. Si llegan datos tardíos dentro de esos 2 minutos, volverá a procesar la ventana y emitirá un resultado actualizado (un nuevo "pane"). Los datos que lleguen después de esos 2 minutos de latencia permitida, serán descartados. C. Wait indefinitely for all data to arrive (Esperar indefinidamente a que lleguen todos los datos) Por qué es incorrecta: Esto es conceptualmente imposible en el procesamiento de streaming. Si el sistema esperara indefinidamente, nunca podría cerrar una ventana ni emitir un resultado final, ya que teóricamente un dato podría llegar con horas o días de retraso. El propósito de las ventanas es, precisamente, poder obtener resultados parciales y oportunos de un flujo infinito de datos. D. Trigger an alert for late data (Disparar una alerta por datos tardíos) Por qué es incorrecta: Esta es una acción de monitoreo, no una acción de procesamiento de datos. El sistema primero tiene que decidir qué hacer con el dato (procesarlo o descartarlo). Aunque puedes configurar métricas y alertas para saber cuántos datos se están descartando por ser tardíos (lo cual es una buena práctica), la acción por defecto que el pipeline aplica al dato en sí es descartarlo.

Answer 912

C El concepto clave aquí es la diferencia entre triggers (disparadores) basados en datos (data-driven) y triggers basados en el tiempo (time-driven) en Dataflow (Apache Beam). Un trigger decide cuándo se debe calcular y emitir el resultado de una ventana de datos (por ejemplo, el resultado de "contar elementos cada 5 minutos"). La respuesta correcta: Basada en Datos C. AfterCount (Después de la cuenta) Por qué es correcta: Este es el ejemplo clásico de un trigger "basado en datos". Se activa (dispara) únicamente cuando se ha acumulado un número específico de elementos (datos) dentro de la ventana. Ejemplo: "Emitir el resultado de la ventana tan pronto como hayan llegado 100 elementos". La decisión de disparar depende directamente de la cantidad de datos recibidos, no de cuánto tiempo ha pasado en ningún reloj. Las respuestas incorrectas: Basadas en el Tiempo Las otras tres opciones son ejemplos de triggers "basados en el tiempo". Miden el progreso del tiempo, aunque de maneras diferentes. A. AfterWatermark (Después de la marca de agua) Por qué es incorrecta: Este trigger se basa en el tiempo de evento (event time). La watermark (marca de agua) es la estimación del sistema de "hasta qué punto en el tiempo del evento creemos que hemos recibido todos los datos". El trigger se dispara cuando la watermark supera el final de la ventana (es decir, el sistema está razonablemente seguro de que ya no llegarán más datos antiguos para esa ventana). Aunque la watermark avanza a medida que llegan datos, el trigger en sí mismo se basa en el concepto de tiempo de evento, no en la cantidad de datos. B. AfterProcessingTime (Después del tiempo de procesamiento) Por qué es incorrecta: Este trigger se basa en el tiempo de procesamiento (processing time). Esto es, simplemente, el tiempo de reloj del sistema (el tiempo real) en las máquinas que ejecutan el pipeline de Dataflow. Ejemplo: "Emitir el resultado 10 segundos (de tiempo real) después de que el primer elemento de la ventana llegó al sistema". Depende del reloj de la pared, no de los datos. D. AfterFixedTime (Después de un tiempo fijo) Por qué es incorrecta: Esta opción es conceptualmente una variante de AfterProcessingTime. Se refiere a disparar la ventana en intervalos fijos de tiempo de procesamiento (tiempo real), independientemente de los datos que lleguen. Al igual que la B, se basa en el reloj del sistema. Resumen AfterCount = Basado en cuántos datos han llegado. (Data-driven) AfterWatermark = Basado en cuándo ocurrieron los datos (tiempo de evento). (Time-driven) AfterProcessingTime / AfterFixedTime = Basado en cuándo se están procesando los datos (tiempo real del sistema). (Time-driven)

Answer 913

C Google Cloud Pub/Sub is the primary service used with Dataflow for ingesting streaming data, as it supports real-time message publishing and subscription, enabling Dataflow to process unbounded data streams efficiently. BigQuery is typically used for storing and analyzing processed data, Cloud Storage is suited for batch data storage, and Cloud SQL manages relational databases, none of which are primarily used for streaming data ingestion. Dataflow’s integration with Pub/Sub also supports features like exactly-once processing through deduplication using custom message IDs.

Answer 914

B y D ✅ Opción B: BigQuery allows for interactive SQL queries over petabyte-scale datasets with near-real-time insights. Esta afirmación es correcta y describe la propuesta de valor central de BigQuery. Petabyte-scale: BigQuery es famoso por su capacidad para manejar y consultar conjuntos de datos masivos, que pueden llegar a los petabytes (miles de terabytes). Interactive SQL queries: Utiliza una sintaxis SQL estándar, lo que lo hace accesible para cualquier analista o desarrollador familiarizado con bases de datos. Las consultas se ejecutan de forma interactiva y devuelven resultados en segundos o minutos, incluso sobre datos enormes. Near-real-time insights: Gracias a la ingesta por streaming, los datos recién llegados están disponibles para ser consultados casi al instante (normalmente en unos pocos segundos). Esto permite obtener información casi en tiempo real sobre lo que está ocurriendo. En esencia, BigQuery combina la capacidad de analizar datos a gran escala con la velocidad de una base de datos tradicional. ✅ Opción D: BigQuery streaming is suitable for analytical applications that are tolerant of late, missing, or duplicated data. Esta afirmación es correcta y toca un punto técnico importante sobre la ingesta en streaming. Garantía "At-least-once": La API de streaming de BigQuery garantiza que cada registro enviado se escribirá al menos una vez (at-least-once delivery). En ciertas situaciones de red o reintentos, es posible que un mismo registro se escriba más de una vez, generando duplicados. Tolerancia de la aplicación: Por este motivo, las aplicaciones que consumen datos ingresados por streaming deben estar preparadas para manejar esta posibilidad. Lo habitual es que las consultas analíticas (por ejemplo, COUNT, SUM, AVG) no se vean muy afectadas por una pequeña cantidad de duplicados, o que se implementen lógicas posteriores para limpiar o deduplicar los datos si la precisión es crítica. ❌ Opción A: Data streaming into BigQuery is primarily added via batch load jobs. Esto es incorrecto porque mezcla dos conceptos opuestos. Streaming: Es la ingesta de datos fila por fila o en micro-lotes, a medida que se generan. Es un flujo continuo y en tiempo real. Batch load jobs (Cargas por lotes): Es el proceso de cargar un gran archivo de datos (CSV, JSON, etc.) de una sola vez. Es una operación planificada y masiva, no un flujo continuo. Son dos métodos de ingesta diferentes y disponibles en BigQuery, pero el streaming no se realiza mediante trabajos de carga por lotes. ❌ Opción C: Streaming inserts into BigQuery are generally not charged, making them ideal for all data ingestion scenarios. Esto es incorrecto. La ingesta por streaming tiene un coste específico. Modelo de precios: Google Cloud cobra por la cantidad de datos que se ingieren a través de la API de streaming. El precio se basa en el volumen (por ejemplo, dólares por Gigabyte). Cargas por lotes (Batch): En contraste, cargar datos desde Cloud Storage u otras fuentes mediante trabajos de carga por lotes es gratuito. Debido a este coste, la ingesta por streaming se reserva para casos de uso que realmente necesitan datos en tiempo real. Si la latencia no es un problema, la carga por lotes suele ser la opción más económica.

Answer 915

B B is the correct choice: Bigtable is suited to high-performance applications requiring data availability in milliseconds or microseconds, and it can deal with higher throughput than BigQuery. It is specifically ideal for time-series data, rapidly changing data, and real-time processing with data volumes greater than 1 TB. It is commonly used for real-time lookups as part of an application where speed and efficiency are desired. * A is incorrect: While BigQuery provides near-real-time insights, its data availability is typically in seconds, which is not sufficient for sub-millisecond requirements. BigQuery is also optimized for SQL queries, whereas Bigtable is a NoSQL database suited for specific, high-throughput key/value data access patterns. * C and D are incorrect: Cloud SQL is a relational database for structured data, and Google Sheets is a spreadsheet application, neither of which are designed for the petabyte-scale, sub-millisecond latency, and high-throughput requirements mentioned [Not in sources, general knowledge].

Answer 916

B y D Las opciones CORRECTAS B) Diseñar el esquema de la tabla para asegurar que las lecturas y escrituras se distribuyan uniformemente a través del clúster de Bigtable, minimizando el sesgo de datos. Por qué: En Bigtable, el rendimiento depende casi por completo del diseño de tu clave de fila (row key). Si en tu pipeline de streaming escribes datos secuenciales (por ejemplo, usando marcas de tiempo consecutivas en la clave), todos los datos nuevos irán a parar a un único nodo del clúster. Esto crea un "cuello de botella" (conocido como hotspotting), dejando al resto de los nodos inactivos. Diseñar un esquema que distribuya las escrituras y lecturas de manera uniforme permite aprovechar el paralelismo y la capacidad máxima de todo el clúster. D) Colocar los clientes de Bigtable en la misma zona geográfica que el clúster de Bigtable para minimizar la latencia de red. Por qué: En el procesamiento de streaming, los datos fluyen a gran velocidad y en tiempo real. Si la aplicación que inyecta o consume los datos (el cliente) está en una zona de disponibilidad diferente a la del clúster de Bigtable, la distancia física añadirá latencia de red a cada operación. Para optimizar el rendimiento, los recursos de cómputo (como Dataflow o Compute Engine) deben estar en la misma zona que la base de datos. Las opciones INCORRECTAS A) Asegurar que el clúster use discos HDD por eficiencia de costos, ya que el tipo de disco tiene un impacto insignificante en el streaming de alto rendimiento. Por qué es falsa: El tipo de disco tiene un impacto gigantesco en el rendimiento. Para cargas de trabajo en tiempo real, de alto rendimiento (high-throughput) y baja latencia como el streaming, Google Cloud recomienda de manera estricta utilizar discos SSD. Los discos HDD (discos duros mecánicos) solo se recomiendan para casos de uso de procesamiento por lotes (batch), almacenamiento de archivos a gran escala o cuando la latencia no es un problema en absoluto. C) Probar con una pequeña cantidad de datos (ej. 50 GB) por un periodo muy corto (ej. unos pocos segundos) para obtener puntos de referencia de rendimiento iniciales rápidos. Por qué es falsa: Bigtable es un sistema altamente distribuido que ajusta y rebalancea los datos dinámicamente en segundo plano. Para observar su verdadero rendimiento, el sistema necesita "calentar" (warm up). Google recomienda explícitamente ejecutar pruebas de rendimiento con al menos 300 GB de datos y dejarlas correr durante al menos 10 a 20 minutos. Una prueba corta con solo 50 GB no le dará a Bigtable el tiempo ni los datos suficientes para equilibrar la carga, resultando en métricas de rendimiento artificialmente bajas y engañosas.

Answer 917

C C is the most important principle: Bigtable has only one index, the Row Key, and data is organized lexicographically by the Row Key. To achieve the best performance, you need to select or construct a Row Key that minimizes sorting and searching and turns your most common queries into scans. This means desired data should appear in adjacent and contiguous rows. * A is incorrect: While distributing writes across nodes is good for write performance, choosing randomly distributed row keys can make reading multiple related rows inefficient. * B is incorrect: Overly complex Row Keys can be difficult to manage, and the goal is simplification for speed. The ability to scan efficiently by Row Key is prioritized over broad search flexibility for optimal performance. * D is incorrect: Row Keys can be strings and often combine multiple data elements (e.g., origin, arrival timestamp) to create a structured key that facilitates scanning

Answer 918

C C is True: Key Visualizer is a tool that helps you analyze your Bigtable usage patterns. It generates visual reports (heatmaps) that show metric values over time, broken down by row key ranges, helping to find/prevent hotspots, find rows with too much data, and see if your key schema is balanced. * A is False: Bigtable replication is primarily used to improve availability and durability of data, isolate serving applications from batch reads, provide near-real-time backup, and ensure a global data presence. Compression is achieved through schema design, like grouping identical values in adjacent rows. * B is False: If a Bigtable cluster becomes unresponsive, replication makes it possible for incoming traffic to failover, and failovers can be either manual or automatic, depending on the app profile configuration. * D is False: Replication enables you to copy data across multiple regions OR multiple zones within the same region, increasing availability and durability

Answer 919

C Streaming inserts are more expensive than batch loading but allow near-real-time data availability, which is ideal when immediate access is required.

Answer 920

A y C Bigtable provides low latency and scales linearly. It does not support SQL, and it simplifies indexing using only the Row Key.

Answer 921

D Reversing the timestamp ensures the most recent rows are stored at the top, which is ideal for retrieving the latest data quickly (e.g., current arrival delays).

Answer 922

B Streaming inserts in BigQuery are recommended when the immediate availability of data is a solution requirement. Batch loading is preferred otherwise, as it is usually not charged, while streaming incurs additional costs

Answer 923

C Bigtable is optimized for high-throughput and real-time processing of large, non-structured key/value datasets, and is not suitable for SQL queries, transactional data, or small data volumes

Answer 924

B Bigtable uses a single index called the Row Key, which is used to organize and access data lexicographically. There are no secondary indexes in Bigtable

Answer 925

C Looker Studio can connect directly to BigQuery, including streaming data, and allows users to create and share real-time dashboards and visualizations

Answer 926

A y C La diferencia clave: Bigtable vs. BigQuery Para entender la respuesta, es vital conocer la diferencia fundamental entre ambos servicios. Bigtable ⚡️: Es una base de datos NoSQL de altísimo rendimiento. Piensa en ella como un índice gigantesco y súper rápido. Es perfecta para escribir enormes cantidades de datos (como eventos de IoT) y para leer una fila específica o un rango pequeño de filas en milisegundos. Su función es servir datos a aplicaciones en tiempo real. BigQuery 🧠: Es un almacén de datos analítico (data warehouse). Piensa en él como un erudito que puede leer un libro entero en segundos para responder una pregunta compleja. No es rápido para buscar una sola palabra (una fila), pero es imbatible para analizar grandes volúmenes de datos, hacer JOINs y agregaciones. Su función es el análisis de datos (Business Intelligence, Data Science). Escenarios correctos para Bigtable (A y C) A) Necesitas procesar datos de series temporales de dispositivos IoT Este es el caso de uso por excelencia para Bigtable. Su diseño de clave de fila (row key) es ideal para estructurar datos de series temporales (ej: sensor_id#timestamp). Esto permite que millones de dispositivos escriban datos simultáneamente de forma muy eficiente y que luego puedas leer la cronología de un sensor específico muy rápidamente. C) Tu aplicación demanda una latencia de sub-segundo para búsquedas en tiempo real Si estás construyendo un panel de control, un sistema de recomendaciones, o cualquier aplicación que necesite mostrar datos al usuario casi instantáneamente, Bigtable es la elección correcta. Está diseñado para devolver datos en milisegundos de un solo dígito, algo que BigQuery, al ser un motor analítico, no puede garantizar (sus consultas suelen tardar de segundos a minutos). Escenarios incorrectos para Bigtable (B y D) B) Requieres JOINs al estilo SQL y consultas complejas ❌ Este es el territorio exclusivo de BigQuery. Bigtable es una base de datos NoSQL y no soporta el lenguaje SQL ni operaciones JOIN. Si necesitas cruzar tablas y realizar análisis complejos, la herramienta es BigQuery. D) Tu conjunto de datos es menor a 1 TB y está muy estructurado ❌ Este escenario no apunta específicamente a Bigtable. Un conjunto de datos pequeño y muy estructurado (con relaciones claras entre tablas) encajaría mucho mejor en una base de datos relacional como Cloud SQL. Bigtable brilla con datos semi-estructurados y a escala de terabytes o petabytes; para datasets más pequeños, suele ser una solución sobredimensionada.

Answer 927

C The primary requirements are extremely low latency (milliseconds) and high throughput for key-based lookups, which are the core strengths of Bigtable. While BigQuery is excellent for analytics (Slide 18), its latency is in seconds, not milliseconds. Cloud SQL would struggle with the required throughput and scale, and Cloud Storage is an object store not optimized for fast, indexed lookups.

Answer 928

C As explained on Slides 28 and 29, the goal is to make the most common query a simple scan. Placing sensor_id first groups all data for a specific sensor together. Using a reverse timestamp (Long.MAX_VALUE - timestamp) ensures that the most recent data is sorted lexicographically at the beginning of that sensor's block. This allows you to satisfy the query by simply reading the first 50 rows for that sensor_id prefix, which is the most efficient operation possible.

Answer 929

A Slides 8, 9, and 13 outline this exact workflow. Looker Studio is Google's integrated visualization tool that can be launched directly from BigQuery. BigQuery BI Engine is the in-memory analysis service designed specifically to provide sub-second query response times for dashboards built on top of BigQuery, making it the perfect tool for accelerating performance. The other options are either inefficient (B), use the wrong tool (C, Key Visualizer is for Bigtable schema analysis), or are overly complex (D).

Answer 930

A, B y D ✅ Respuestas Correctas A. Asegurar que las aplicaciones cliente estén en la misma zona que el clúster de Bigtable. ¿Por qué es correcta? La latencia de red es un factor crucial en el rendimiento de cualquier base de datos en la nube. Cada operación de lectura o escritura implica un viaje de ida y vuelta a través de la red entre tu aplicación y la base de datos. Si tu aplicación está en una zona geográfica (ej: europe-west1-b) y tu clúster de Bigtable está en otra (ej: us-central1-a), cada una de esas operaciones tendrá un retraso de varios milisegundos. Al ejecutar la aplicación en la misma zona que el clúster, esta latencia se minimiza drásticamente, lo que resulta en un rendimiento mucho más rápido. B. Rediseñar la clave de fila (row key) para evitar claves secuenciales. ¿Por qué es correcta? Esta es la causa más común de hotspotting en Bigtable. Bigtable almacena los datos ordenados lexicográficamente por la clave de fila (row key). Si usas claves secuenciales (como un timestamp normal: 2025-10-17T15:30:00, 2025-10-17T15:30:01...), todas las escrituras nuevas se dirigirán al final de la tabla. Como la tabla está distribuida entre varios servidores (nodos), esto provoca que un solo nodo reciba toda la carga de escritura, mientras los demás permanecen inactivos. Para solucionarlo, se debe diseñar una row key que distribuya las escrituras por toda la tabla, como por ejemplo: Añadir un hash al principio: hash(userId)#timestamp Invertir el timestamp: 00:30:51T71-01-5202 Así, las escrituras se reparten entre todos los nodos, eliminando el "punto caliente". D. Asegurar que el clúster use almacenamiento SSD en lugar de HDD. ¿Por qué es correcta? Bigtable ofrece dos tipos de almacenamiento: SSD (Solid-State Drive) y HDD (Hard Disk Drive). SSD: Ofrece una latencia mucho más baja y es ideal para cargas de trabajo sensibles al rendimiento en tiempo real, como las de una data pipeline que necesita escribir y leer datos rápidamente. HDD: Es más económico y ofrece un alto rendimiento para cargas de trabajo de análisis masivo (throughput), pero tiene una latencia mucho mayor. Si el pipeline experimenta lentitud, verificar que se esté usando SSD es un paso fundamental, ya que el uso de HDD sería una causa directa de bajo rendimiento para este tipo de aplicación. ❌ Respuestas Incorrectas C. Añadir índices secundarios a las columnas que se usan con frecuencia. ¿Por qué es incorrecta? Esta opción es incorrecta porque Bigtable no soporta índices secundarios como lo hacen las bases de datos relacionales (MySQL, PostgreSQL) o incluso otras NoSQL. En Bigtable, la única forma de buscar datos eficientemente es a través de su row key. Si necesitas buscar por el valor de una columna, la práctica recomendada es crear una tabla de índice separada donde la row key de esa nueva tabla sea el valor de la columna por la que quieres buscar. Proponer "añadir un índice secundario" sugiere una funcionalidad que simplemente no existe en Bigtable. E. Reducir el número de nodos en el clúster para consolidar datos y mejorar la eficiencia de la caché. ¿Por qué es incorrecta? Esta recomendación es contraproducente y empeoraría el problema. Los nodos en un clúster de Bigtable son los que proporcionan la capacidad de procesamiento (CPU) y memoria. Reducir nodos significa menos potencia para gestionar las solicitudes. Esto concentraría aún más la carga en los nodos restantes, agravando los problemas de rendimiento y los hotspots. Para solucionar problemas de sobrecarga o bajo rendimiento, la estrategia correcta es aumentar el número de nodos para distribuir mejor la carga de trabajo.

Answer 931

B Aquí tienes la explicación detallada. La respuesta correcta es la B. La elección entre ingesta por streaming o por lotes (batch) se reduce casi siempre a una pregunta: ¿con qué urgencia necesitas los datos? ✅ Por qué la opción B es la correcta B. When the immediate availability of the data for real-time analysis is a critical business requirement. (Cuando la disponibilidad inmediata de los datos para el análisis en tiempo real es un requisito empresarial crítico.) Esta es la razón de ser de la ingesta por streaming. Este método está diseñado para escenarios donde los datos deben estar disponibles para ser consultados segundos después de ser generados. Piensa en casos de uso como: Detección de fraude: Analizar transacciones al instante para bloquear actividades sospechosas. Paneles de control en vivo (Live Dashboards): Monitorizar el rendimiento de una campaña de marketing o el estado de un sistema en tiempo real. Videojuegos: Registrar eventos de jugadores para analizar el comportamiento y el balance del juego sobre la marcha. En todos estos casos, esperar a que un trabajo por lotes se ejecute cada hora o cada día es demasiado tarde. El streaming te da esa inmediatez. ⚡ ❌ Por qué las otras opciones son incorrectas A. When the source data is already in structured files like Avro or Parquet in Cloud Storage. (Cuando los datos de origen ya están en archivos estructurados como Avro o Parquet en Cloud Storage.) Este escenario es el caso de uso perfecto para un trabajo de carga por lotes (batch load), no para streaming. BigQuery está optimizado para cargar archivos completos desde Cloud Storage de manera muy eficiente y económica. Intentar leer esos archivos fila por fila para enviarlos por streaming sería innecesariamente complejo, lento y costoso. C. When you need to load over 15 TB of data in a single day, as streaming has higher daily limits. (Cuando necesitas cargar más de 15 TB de datos en un solo día, ya que el streaming tiene límites diarios más altos.) Esta afirmación es incorrecta. El límite de 15 TB por día se aplica a los trabajos de carga por lotes (batch) por tabla. Aunque el streaming no tiene un límite diario "duro" de este tipo (se basa en el rendimiento en MB/s), los trabajos por lotes son generalmente el método preferido y más eficiente para volúmenes de datos masivos como este, siempre que no se requiera inmediatez. La elección no se basa en cuál tiene un límite superior, sino en la necesidad de latencia. D. When you want to minimize ingestion costs, as streaming is a free service. (Cuando quieres minimizar los costes de ingesta, ya que el streaming es un servicio gratuito.) Esta afirmación es totalmente falsa y, de hecho, es al revés. Los trabajos de carga por lotes (batch) desde Cloud Storage son gratuitos. No pagas nada por el proceso de ingesta en sí. 💰 La ingesta por streaming tiene un coste asociado. Se te cobra por cada gigabyte de datos que envías a BigQuery. Por lo tanto, si el objetivo principal es minimizar el coste, la carga por lotes es siempre la mejor opción.

Answer 932

B The sources state that BigQuery analytic window functions are categorized into Standard aggregations, Navigation functions, and Ranking and Numbering functions. String manipulation functions are not mentioned as one of these specific categories of analytic window functions.

Answer 933

D The ST_DWithin function is specifically used to check if the distance between two points is within the distance parameter. ST_GeogPoint is used to create a geospatial object from latitude and longitude, while ST_Intersects and ST_Contains are predicate functions for reporting on the overlay or co-location of geospatial objects

Answer 934

C WITH clauses are instances of a named subquery (or Common Table Expression). They act as temporary tables and are an easy way to isolate SQL operations and make complex queries more manageable. They also allow chaining together multiple subqueries and referencing other subqueries. They do not permanently store results (unless explicitly materialized into a destination table), modify source data, or bypass slot allocation.

Answer 935

D To optimize BigQuery queries, it is recommended to avoid using SELECT * and instead select only the necessary columns. Data should be filtered early and often using the WHERE clause. ORDER BY should only be applied as the last operation on the outermost query. For large datasets, using approximate aggregation functions such as APPROX_COUNT_DISTINCT is faster and more efficient than regular ones

Answer 936

C The LEAD() function returns the value of a specified column from a subsequent row relative to the current row within a partition.

Answer 937

B y C Opciones Correctas (Mejores Prácticas) ✅ B. Usar funciones de agregación aproximadas como APPROX_COUNT_DISTINCT Calcular el número exacto de valores únicos con COUNT(DISTINCT ...) es una operación muy costosa en grandes volúmenes de datos. BigQuery tiene que mover y comparar enormes cantidades de información. La función APPROX_COUNT_DISTINCT, en cambio, utiliza un algoritmo (HyperLogLog++) que es mucho más rápido y consume muchos menos recursos. A cambio, ofrece un resultado aproximado con un margen de error estadísticamente muy pequeño. Para muchos casos de uso, como análisis de tendencias o dashboards, esta aproximación es más que suficiente y el ahorro en rendimiento es enorme. C. Aplicar filtros temprano usando WHERE BigQuery es una base de datos columnar. Su rendimiento y coste dependen directamente de la cantidad de datos leídos del disco. La cláusula WHERE es la herramienta más poderosa para reducir esa cantidad. Al filtrar los datos lo antes posible en tu consulta, le dices a BigQuery que ignore una gran cantidad de filas desde el principio. Esto significa que las operaciones posteriores (como uniones (JOIN), agregaciones (GROUP BY), etc.) trabajarán con un conjunto de datos mucho más pequeño, acelerando drásticamente la consulta. Si además filtras por una columna de partición (ej. WHERE fecha = '2025-08-19'), BigQuery puede ignorar particiones enteras sin siquiera leerlas, lo que se conoce como partition pruning y es una de las optimizaciones más efectivas. Opciones Incorrectas (Anti-Patrones) ❌ A. Usar SELECT * para simplificar las consultas Este es uno de los peores anti-patrones en BigQuery. Al ser una base de datos columnar, usar SELECT * obliga al motor a leer todas las columnas de la tabla, incluso si solo necesitas dos o tres. Esto maximiza la cantidad de datos procesados, lo que hace que la consulta sea más lenta y más cara. La mejor práctica es siempre especificar únicamente las columnas que necesitas. D. Almacenar resultados intermedios en tablas temporales En las bases de datos tradicionales, esto a veces era una buena práctica. En BigQuery, generalmente es un anti-patrón de rendimiento. BigQuery está optimizado para transmitir (stream) los datos entre las diferentes etapas de una consulta de forma muy eficiente en memoria. Forzar la escritura de un resultado intermedio a una tabla temporal introduce un paso de I/O (escritura a disco y posterior lectura) que es significativamente más lento que el streaming en memoria. Para organizar consultas complejas, la mejor práctica es usar Expresiones de Tabla Comunes (CTEs) con la cláusula WITH, que permiten una lógica clara sin penalizar el rendimiento.

Answer 938

C La respuesta correcta: C. Devuelve TRUE si dos geografías están dentro de una distancia especificada. La función ST_DWithin en BigQuery GIS se utiliza para determinar si dos objetos geoespaciales se encuentran a una cierta distancia uno del otro.[1][2][3] Si la distancia entre las geografías es menor o igual a la distancia que tú especificas, la función devuelve TRUE (verdadero).[3] En caso contrario, devuelve FALSE (falso). Por ejemplo, podrías usar ST_DWithin para encontrar todas las tiendas que están a menos de 5 kilómetros de la ubicación de un cliente.[2] Por qué las otras respuestas son incorrectas: A. Calcula la distancia exacta entre dos geografías: Esta función no devuelve la distancia en sí. Para calcular la distancia exacta entre dos puntos geográficos, se utilizaría la función ST_Distance. La función ST_DWithin es más eficiente cuando solo necesitas saber si los objetos están dentro de un radio determinado, sin necesidad de conocer la distancia precisa. B. Comprueba si dos geometrías se cruzan: Aunque dos geografías que están a una distancia de 0 se cruzarían, la función específica para comprobar la intersección es ST_Intersects.[1][4] ST_DWithin es una consulta de proximidad, no de intersección directa. D. Convierte un punto de JSON a geografía: Para convertir datos de formato JSON (específicamente GeoJSON) a un tipo de dato geográfico en BigQuery, se utiliza la función ST_GeogFromGeoJSON.[1][4] ST_DWithin no realiza conversiones de formato.

Answer 939

C WITH clauses (Common Table Expressions) simplify complex SQL queries by defining reusable subqueries.

Answer 940

C Por qué la opción C es la correcta C) Usar tablas particionadas (Using partitioned tables) ✅ Esta es una de las técnicas de optimización más importantes y efectivas en BigQuery. ¿Qué es particionar? Consiste en dividir una tabla grande en segmentos más pequeños (particiones) basándose en una columna, generalmente una fecha, una hora o un número entero. ¿Por qué optimiza el rendimiento? Cuando ejecutas una consulta que filtra por la columna de partición (por ejemplo, WHERE fecha = '2025-09-24'), BigQuery aplica una técnica llamada "poda de particiones" (partition pruning). Esto significa que solo lee los datos de las particiones relevantes e ignora por completo el resto de la tabla. Analogía: Es como buscar un documento de septiembre en un archivador que tiene un cajón para cada mes del año. En lugar de revisar los 12 cajones, vas directamente al cajón de "Septiembre". Al escanear muchos menos datos, la consulta es drásticamente más rápida y más barata. ⚡ Por qué las otras opciones son incorrectas A) Poner la tabla más grande a la izquierda en un JOIN ❌ Aunque la documentación de BigQuery recomienda ordenar las tablas en un JOIN de la más grande a la más pequeña, esta es más una sugerencia de micro-optimización. El optimizador de consultas de BigQuery es muy avanzado y, en la mayoría de los casos, determina automáticamente el plan de ejecución más eficiente sin importar el orden en que pongas las tablas. Su impacto es mucho menor en comparación con la poda de particiones, que puede reducir el volumen de datos escaneados en órdenes de magnitud. B) Usar ORDER BY al principio de las subconsultas ❌ Esto es un anti-patrón que empeora el rendimiento. La cláusula ORDER BY fuerza una ordenación global de los datos, una operación muy costosa en un sistema distribuido como BigQuery. Usarla dentro de una subconsulta significa que estás ordenando un conjunto de datos intermedio, un trabajo que probablemente sea inútil porque esos datos se volverán a procesar, filtrar o agregar más adelante. ORDER BY solo debe usarse, si es estrictamente necesario, en la consulta final. D) Agrupar por columnas de alta cardinalidad como los UUIDs ❌ Esto también es un anti-patrón. Una columna de "alta cardinalidad" es aquella que tiene muchísimos valores únicos (como un ID de transacción o un UUID, donde casi cada fila tiene un valor diferente). Agrupar (GROUP BY) por una columna así es muy ineficiente porque obliga a BigQuery a crear una cantidad masiva de grupos, lo que genera una gran sobrecarga de procesamiento y comunicación entre nodos (shuffle), y a menudo no reduce la cantidad de datos en absoluto.

Answer 941

D ST_GEOGPOINT is used to convert longitude and latitude values into a GEOGRAPHY data type that BigQuery can work with. The ST_DWITHIN function is specifically optimized to test if the distance between two geography objects is within a certain radius (in meters), making it the most efficient and direct way to solve this problem, as shown in slides 14 and 15.

Answer 942

B As mentioned in slides 28 and 32, approximate aggregation functions are a great way to improve performance on very large datasets. APPROX_COUNT_DISTINCT provides a fast, approximate result, which is perfect for scenarios where absolute precision is not required. While adding more slots (C) can help, optimizing the query itself (B) is a more direct and efficient solution that addresses the computational complexity of the operation.

Answer 943

C This scenario requires grouping the calculation by a specific column (department) and then ordering within that group. The PARTITION BY department clause creates a separate "window" for each department. The ORDER BY startdate clause then sorts the employees within that window by their start date (oldest first by default). Finally, the RANK() function assigns a rank based on that order. This is illustrated in the examples on slides 9 and 10.

Answer 944

B y D Prácticas Correctas para Optimizar la Consulta B) Descomponer la consulta en pasos modulares usando cláusulas WITH (CTEs) - ✅ Correcta Esta práctica ataca directamente el problema de la complejidad y el mantenimiento. Qué es: Una WITH clause, también conocida como Expresión Común de Tabla (CTE - Common Table Expression), te permite crear subconsultas temporales con un nombre. En lugar de tener una consulta gigante con subconsultas anidadas, la divides en una serie de pasos lógicos y legibles. Analogía: Es como resolver un problema matemático complejo. En lugar de escribir una única fórmula larguísima, lo divides en pasos: "Paso 1: Calcular A", "Paso 2: Usar A para calcular B", etc. Esto hace que sea muchísimo más fácil de leer, depurar y modificar en el futuro. -- Mal (difícil de leer) SELECT ... FROM (SELECT ... FROM ... WHERE ...) AS t1 JOIN (SELECT ... FROM ... WHERE ...) AS t2 ON ... -- Bien (fácil de leer con CTEs) WITH t1 AS ( SELECT ... FROM ... WHERE ... ), t2 AS ( SELECT ... FROM ... WHERE ... ) SELECT ... FROM t1 JOIN t2 ON ...; D) Aplicar filtros (WHERE) lo antes posible para reducir los datos procesados - ✅ Correcta Esta práctica ataca directamente el problema del rendimiento y el alto coste. Qué es: Es uno de los principios más importantes de la optimización de SQL. Consiste en reducir el volumen de datos en la etapa más temprana posible. Si filtras las filas que no necesitas antes de hacer JOINs o agregaciones pesadas, el motor de la base de datos tendrá que trabajar con un conjunto de datos mucho más pequeño en los pasos siguientes. Analogía: Imagina que buscas un libro específico en una biblioteca de 3 plantas. En lugar de llevarte todos los libros de las 3 plantas a una mesa para empezar a buscar, primero vas a la planta, sección y estantería correctas (el WHERE temprano) y solo te llevas el puñado de libros relevante. Ahorras un esfuerzo y tiempo enormes. Por qué las otras opciones son incorrectas A) Colocar la cláusula ORDER BY en la subconsulta más interna - ❌ Incorrecta Esto es un anti-patrón. Ordenar datos es una operación muy costosa. Hacerlo en una etapa temprana es inútil, ya que las operaciones posteriores como los JOINs probablemente desordenarán los datos de nuevo. El ORDER BY casi siempre debe ser la última cláusula de la consulta final, aplicada solo al resultado que se va a mostrar. C) Reemplazar nombres de columnas por SELECT * - ❌ Incorrecta Esto es otro anti-patrón grave. Rendimiento: Obliga a la base de datos a leer todas las columnas de la tabla, incluso las que no necesitas, lo que aumenta el consumo de recursos y el coste. Es lo contrario de lo que se busca. Mantenimiento: Hace que la consulta sea frágil. Si alguien añade una columna a la tabla, tu consulta la incluirá automáticamente, lo que puede romper el código que consume esos datos. Siempre se deben especificar explícitamente las columnas necesarias.

Answer 945

B As illustrated on slide 43, BigQuery employs a fair scheduler. When a new query is submitted while another is running, BigQuery does not block it. Instead, it subdivides the available compute resources (slots) among all concurrently running queries. In this case, each query would receive approximately 1,000 slots, ensuring both can make progress simultaneously.

Answer 946

B The sources state that BigQuery analytic window functions are categorized into Standard aggregations, Navigation functions, and Ranking and Numbering functions. String manipulation functions are not mentioned as one of these specific categories of analytic window functions.

Answer 947

D The ST_DWithin function is specifically used to check if the distance between two points is within the distance parameter. ST_GeogPoint is used to create a geospatial object from latitude and longitude, while ST_Intersects and ST_Contains are predicate functions for reporting on the overlay or co-location of geospatial objects.

Answer 948

C WITH clauses are instances of a named subquery (or Common Table Expression). They act as temporary tables and are an easy way to isolate SQL operations and make complex queries more manageable. They also allow chaining together multiple subqueries and referencing other subqueries. They do not permanently store results (unless explicitly materialized into a destination table), modify source data, or bypass slot allocation.

Answer 949

D To optimize BigQuery queries, it is recommended to avoid using SELECT * and instead select only the necessary columns. Data should be filtered early and often using the WHERE clause. ORDER BY should only be applied as the last operation on the outermost query. For large datasets, using approximate aggregation functions such as APPROX_COUNT_DISTINCT is faster and more efficient than regular ones.

Answer 950

C AVG is a standard aggregation function used to compute averages over groups of rows. LEAD and ROW_NUMBER are window functions, and ST_DWithin is a geospatial function.

Answer 951

A y C LAG and RANK are analytic window functions used to navigate and rank data within partitions. ST_GeogPoint and ST_Intersects are geospatial functions.

Answer 952

B The WITH clause defines temporary named subqueries (also known as Common Table Expressions or CTEs) to modularize and simplify complex SQL queries.

Answer 953

B, C y D Efficient queries avoid selecting unnecessary columns, use filtering early, benefit from table partitioning, and may use approximate functions for better performance. SELECT * is generally discouraged for performance reasons.

Answer 954

C ✅ Por qué la opción C es la correcta La función ST_DWithin está diseñada específicamente para responder a una pregunta de proximidad: "¿Están estas dos formas geográficas lo suficientemente cerca?". ST: Es un prefijo estándar en bases de datos espaciales que significa "Spatial Type" (Tipo Espacial). DWithin: Es una abreviatura de "Distance Within" (Dentro de una Distancia). La función toma tres argumentos: dos objetos geográficos (geography_1, geography_2) y una distancia en metros (distance). Devuelve: TRUE (verdadero) si la distancia más corta entre los dos objetos es menor o igual a la distancia que especificaste. FALSE (falso) en caso contrario. Ejemplo simple: Imagina que tienes un punto para tu casa y otro para una cafetería. La pregunta ST_DWithin(casa, cafeteria, 500) se traduciría como: "¿Está la cafetería a 500 metros o menos de mi casa?". La respuesta sería TRUE o FALSE. ❌ Por qué las otras opciones son incorrectas A) True if geography_1 fully contains geography_2 Esto describe la función ST_Contains. Esta función comprueba una relación topológica de contenencia, no de proximidad. Por ejemplo, ST_Contains(provincia_de_madrid, ciudad_de_madrid) devolvería TRUE. B) A list of zip codes that intersect with a given geometry Esto no es lo que devuelve la función en sí. ST_DWithin solo devuelve TRUE o FALSE. Para obtener una lista de códigos postales, usarías ST_DWithin (o más comúnmente ST_Intersects) como condición en la cláusula WHERE de una consulta más grande, pero el resultado final (la lista) es producto de la consulta completa, no de la función aislada. D) The exact distance between the two points Esto describe la función ST_Distance. Esta función es la que calcula y devuelve un número (la distancia mínima en metros) entre dos geografías. ST_DWithin es, en esencia, una forma optimizada de hacer ST_Distance(geo1, geo2) <= distancia, pero mucho más eficiente porque no necesita calcular la distancia exacta si puede determinar rápidamente que los objetos están demasiado lejos.

Answer 955

B LEAD is a navigation function that returns the value of a row a specified number of rows ahead of the current row within a window frame. SUM, COUNTIF, and LOGICAL_AND are aggregate functions, not navigation functions

Answer 956

B The WITH clause allows you to define named subqueries, making complex queries more manageable by acting as temporary tables within the query

Answer 957

B ST_DWithin checks if the distance between two geographical objects is within a specified distance parameter, making it ideal for proximity queries

Answer 958

B y C Filtering data early with WHERE clauses and using approximate aggregation functions can significantly improve query performance. Using SELECT * and applying ORDER BY early are discouraged as they can increase resource usage and slow down queries

Answer 959

A ST_GeogPoint creates a geospatial object in Well Known Text (WKT) from longitude and latitude values, enabling spatial analysis in BigQuery

Answer 960

D This is a classic use case for an analytic window function. PARTITION BY start_station_name divides the data into groups for each starting station. ORDER BY duration DESC sorts the trips within each of those partitions from longest to shortest. RANK() then assigns a rank to each row within its partition. A GROUP BY clause (Option A) would aggregate and collapse the rows for each station, which is not the desired outcome. Option C is incorrect because it would rank trips across the entire dataset, not within each starting station.

Answer 961

A y B The provided slides highlight several key optimization techniques: A is correct: Slide 28 explicitly advises to "Avoid using unnecessary columns" and warns against SELECT *. This reduces the amount of data that BigQuery has to read and process through the query stages. B is correct: Slide 28 also shows that APPROX_COUNT_DISTINCT is faster than COUNT(DISTINCT). This is a recommended practice for large datasets where an approximate count is acceptable, as it reduces computational overhead. C is incorrect: The best practice (slide 28) is to put the largest table on the left side of the join. D is incorrect: The best practice is to "Filter early and often" (slide 28). Placing the WHERE clause as early as possible reduces the number of rows that need to be processed in later stages like JOINs.

Answer 962

C As shown on slide 15, ST_DWithin is the specific GIS function designed to check if the distance between two geography objects is within a specified number of meters. ST_GeogPoint is used to convert the store's latitude and longitude into a GEOGRAPHY point. ST_DWithin then compares this point to the zip code's boundary geography and returns true if the distance is less than or equal to 10,000 meters (10 km). ST_Intersects or ST_Contains (Options A & B) would only find points exactly on the boundary or inside the polygon, not within a surrounding radius.

Answer 963

C ✅ ¿Por qué la C es la respuesta correcta? La pregunta se centra en la palabra clave trade-off (que se puede traducir como contrapartida, inconveniente o el "coste" que asumes a cambio de un beneficio). El equipo de finanzas quiere ahorrar dinero 💰, y para ello, BigQuery ofrece un tipo de almacenamiento más económico. Sin embargo, este ahorro no es gratuito; implica ceder una funcionalidad. ¿Qué es el "Time Travel"? Es una función de seguridad de BigQuery que te permite recuperar datos que han sido modificados o eliminados accidentalmente. Por defecto, en el almacenamiento estándar (llamado "activo"), BigQuery guarda un historial de 7 días de los cambios en tus tablas. El Trade-off: Cuando los datos no se modifican durante 90 días consecutivos, BigQuery los mueve automáticamente a un almacenamiento a largo plazo (long-term storage), que es significativamente más barato. El término "Compressed Storage" de la pregunta se refiere a este almacenamiento más económico. La contrapartida principal de este ahorro es que la ventana de Time Travel se reduce. Aunque el número exacto de días puede variar según las políticas de Google, el concepto es que sacrificas tiempo de recuperación a cambio de un menor coste de almacenamiento. La opción C describe perfectamente esta relación de coste-beneficio. ❌ ¿Por qué las otras opciones son incorrectas? A. The cost per GB of physical storage is lower than for uncompressed storage. Esta afirmación es cierta, el coste es menor. Sin embargo, no es un trade-off, es precisamente el beneficio que el equipo de finanzas está buscando. La pregunta pide el inconveniente, no la ventaja. B. Autoscaling of compute slots is disabled for datasets with compressed storage. Esto es falso. Una de las grandes ventajas de la arquitectura de BigQuery es la separación total entre el almacenamiento y la computación. El cómo almacenas tus datos (sea en almacenamiento activo o a largo plazo/comprimido) no afecta en absoluto a cómo se ejecutan las consultas ni a la capacidad de escalar los recursos de cómputo (slots). Son dos sistemas independientes. D. Queries on compressed data cannot be accelerated by the BigQuery engine. Esto no solo es falso, sino que es lo contrario de cómo funciona BigQuery. El motor de BigQuery está diseñado desde su núcleo para operar sobre datos comprimidos. BigQuery utiliza un formato de almacenamiento columnar (llamado Capacitor) que comprime los datos de manera muy eficiente. El motor de consultas (Dremel) está optimizado para escanear estos datos comprimidos a velocidades extremadamente altas. Por lo tanto, la compresión es una parte fundamental de su rendimiento, no un obstáculo.

Answer 964

C Slide 43 illustrates the concept of the BigQuery Fair Scheduler. When a new query arrives, BigQuery does not queue it or preempt the running query. Instead, it subdivides the available compute resources (slots) among all active queries. In this case, the 2,000 slots would be split between the two queries (e.g., 1,000 slots each), ensuring that both can make progress simultaneously. This prevents a single resource-heavy query from monopolizing resources and starving other tasks.

Answer 965

D ¿Por qué la D es la respuesta correcta? La pregunta busca identificar cuál NO es un tipo de función analítica (window function). Naturaleza Escalar: Las funciones de manipulación de cadenas (como CONCAT, SUBSTR, LOWER, REPLACE) son funciones escalares. Esto significa que operan sobre una sola fila a la vez y devuelven un solo resultado basado únicamente en el valor de entrada de esa fila específica. No necesitan "mirar" a las filas vecinas ni realizar cálculos sobre un grupo de filas. Sin cláusula OVER: Aunque puedes usar el resultado de una función de cadena dentro de una función de ventana, la función de cadena en sí misma no define una ventana ni usa la cláusula OVER() para su lógica principal. Resumen: Las funciones de texto modifican datos, no analizan conjuntos de filas relacionados, por lo tanto, no son funciones analíticas de ventana. ¿Por qué A, B y C son las opciones "malas" (son funciones analíticas)? Estas opciones son categorías legítimas de funciones analíticas en BigQuery. Todas ellas utilizan la cláusula OVER() para definir un grupo de filas (la ventana) sobre las cuales operar. A. Standard Aggregations (Agregaciones Estándar) Por qué es una función analítica: Las funciones de agregación comunes como SUM(), AVG(), MIN(), MAX() y COUNT() se transforman en funciones analíticas cuando se les añade la cláusula OVER(). Qué hacen: En lugar de colapsar las filas en un solo resultado (como hace un GROUP BY), calculan un valor agregado (como un total acumulado o un promedio móvil) manteniendo visibles todas las filas originales. B. Navigation Functions (Funciones de Navegación) Por qué es una función analítica: Estas funciones están diseñadas específicamente para "navegar" entre filas dentro de la ventana definida. Qué hacen: Permiten acceder a datos de una fila anterior o posterior a la fila actual sin necesidad de hacer uniones (joins) complejas. Ejemplos: LEAD() (mira la fila siguiente), LAG() (mira la fila anterior), FIRST_VALUE(), LAST_VALUE(). C. Ranking and Numbering Functions (Funciones de Ranking y Numeración) Por qué es una función analítica: Estas funciones asignan un número o rango a cada fila basándose en su orden dentro de la ventana. Qué hacen: Son esenciales para crear rankings (top 10) o para paginación. Ejemplos: RANK(), DENSE_RANK(), ROW_NUMBER(), NTILE().

Answer 966

C ST_DWithin is used to determine if two geospatial objects are within a specified distance of each other. ST_GeogPoint creates a geospatial point, ST_GeogFromGeoJSON converts JSON to a geospatial object, and ST_Intersects checks if two geospatial objects intersect.

Answer 967

C Using WHERE clauses early helps reduce the amount of data processed, improving performance. SELECT * should be avoided; instead, specify only the needed columns. ORDER BY should be applied last, and for joins, it's better to place the larger table on the left to optimize performance.

Answer 968

B Slots in BigQuery are used to manage compute resources allocated to queries. They determine how much processing power is available for running queries concurrently.

Answer 969

B Compressed storage in BigQuery reduces storage costs by compressing data, although it shortens the time travel window. It does not directly affect query execution speed or the number of supported data types.

Answer 970

C The sources state that "Pub/Sub is a messaging service used as a starting point to process streaming data". It is also mentioned as "ingesting the data with Pub/Sub" within the typical architecture

Answer 971

D The sources explicitly state that "Dataflow provides a serverless service for processing batch and streaming data". It is also described as "processing the data in stream using Dataflow" in the overall architecture

Answer 972

D The sources indicate that "Bigtable can handle NoSQL queries over large datasets (petabytes) in milliseconds". It is also noted that "Bigtable is a better solution when a much higher throughput is desired"

Answer 973

A, B y C The sources emphasize several challenges and considerations for streaming data: it's important "to be able to ingest varying amounts of data because you could have spikes in your data". It is also crucial "to be able to deal with unexpected delays because latency is a fact of life". Furthermore, the goal is to "be able to derive real-time insights from the data even as the data is streaming in". Option d) describes a BigQuery capability, not a general challenge of streaming data processing itself.

Answer 974

A, B y C Capacidades de Análisis Avanzado de BigQuery (a, b, c) BigQuery ofrece un conjunto de herramientas muy potente que va mucho más allá de las consultas SQL básicas. Estas son las capacidades correctas de la lista: a) Proporcionar un servicio serverless para procesar datos batch y streaming Esta es una característica fundamental y avanzada. Serverless: No tienes que gestionar ninguna infraestructura. BigQuery escala automáticamente para manejar la carga de tu consulta, ya sea pequeña o masiva. Batch y Streaming: BigQuery puede analizar datos cargados en grandes lotes (batch), como archivos históricos, pero también puede ingerir y analizar datos en tiempo real (streaming) a medida que se generan, lo que permite un análisis casi instantáneo de eventos actuales. b) Funciones analíticas de ventana (Analytic window functions) Esta es una capacidad clásica del SQL avanzado, y BigQuery tiene un soporte excelente para ellas. Las funciones de ventana te permiten realizar cálculos sobre un conjunto de filas relacionadas con la fila actual. Son esenciales para análisis complejos como: Calcular totales acumulados o medias móviles. Clasificar resultados dentro de categorías (ej. RANK(), ROW_NUMBER()). Acceder a datos de filas anteriores o posteriores (ej. LAG(), LEAD()). c) Funcionalidad GIS integrada BigQuery tiene capacidades nativas para manejar Sistemas de Información Geográfica (GIS). Esto significa que puedes almacenar datos geoespaciales (coordenadas, puntos, polígonos, etc.) y ejecutar consultas complejas directamente en SQL. Por ejemplo, puedes responder preguntas como: "¿Cuántos clientes se encuentran a menos de 5 kilómetros de una tienda específica?" (ST_DISTANCE) 🗺️ "¿Qué rutas de reparto se cruzan con esta área de construcción?" (ST_INTERSECTS) ¿Por qué la opción D es incorrecta? d) Ser un punto de partida para la ingesta de datos en streaming ❌ Esta afirmación describe incorrectamente el rol de BigQuery en una arquitectura de streaming. BigQuery no es el "punto de partida" o la puerta de entrada para los datos en tiempo real. BigQuery es el destino final, el almacén donde los datos se guardan para su posterior análisis. El punto de partida para la ingesta de streaming en Google Cloud es típicamente un servicio como Pub/Sub, que está diseñado para recibir millones de eventos por segundo de forma fiable. La arquitectura correcta es: Fuente de datos → Pub/Sub (ingesta) → Dataflow (procesamiento) → BigQuery (almacenamiento y análisis).

Answer 975

D ✅ Por qué la opción D es la correcta Google Cloud Pub/Sub es un servicio de mensajería asíncrono y escalable. Su función principal en una arquitectura de datos en streaming es actuar como un intermediario o un "buzón" global. Piénsalo de esta manera: Ingesta (Ingest): Diferentes fuentes de datos (aplicaciones, sensores, etc.) "publican" o envían mensajes a un "tema" (topic) de Pub/Sub. Este es el punto de entrada de los datos al sistema. Entrega (Deliver): Otros servicios (como Cloud Dataflow o Cloud Functions) se "suscriben" a ese tema. Pub/Sub se encarga de entregarles los mensajes de forma fiable para que puedan ser procesados. Su gran ventaja es que desacopla a los productores de datos de los consumidores. El productor no necesita saber quién va a procesar los datos, solo tiene que enviarlos a Pub/Sub. Esto hace que el sistema sea muy flexible y robusto. En resumen, el papel fundamental de Pub/Sub es recibir datos (ingesta) y distribuirlos (entrega) a los componentes que se encargarán de analizarlos o transformarlos. ❌ Por qué las otras opciones son incorrectas A) Consultar grandes conjuntos de datos con SQL (To query large datasets with SQL): Esta es la función principal de BigQuery. BigQuery es el almacén de datos (data warehouse) de Google Cloud diseñado para ejecutar consultas SQL sobre petabytes de datos. Pub/Sub no almacena datos a largo plazo ni tiene una interfaz SQL. B) Visualizar datos en streaming en paneles de control (To visualize streaming data in dashboards): Para visualizar datos, ya sean en streaming o por lotes, se utilizan herramientas como Looker Studio (antes Data Studio) o Looker. Estas herramientas se conectan a una fuente de datos (como BigQuery) para crear gráficos y dashboards. Pub/Sub no tiene ninguna capacidad de visualización. C) Procesar datos en streaming en tiempo real (To process streaming data in real-time): Este es el rol de servicios como Cloud Dataflow o Cloud Functions. Estos servicios se suscriben a Pub/Sub, reciben los mensajes que Pub/Sub les entrega y aplican transformaciones, cálculos o análisis sobre ellos en tiempo real. Pub/Sub es el mensajero, mientras que Dataflow es el que hace el trabajo con el mensaje.

Answer 976

B Dataflow is a serverless data processing service that handles both batch and streaming workloads.

Answer 977

B y C Bigtable is designed for NoSQL data, offering low-latency, high-throughput performance even at massive scale. It does not support traditional SQL or data warehousing use cases.

Answer 978

C BigQuery allows real-time streaming of records into a table, making it ideal for fast, interactive analysis.

Answer 979

C Pub/Sub is designed as a messaging service to ingest and distribute streaming data, serving as the entry point for processing unbounded data sets

Answer 980

B Dataflow provides a fully managed, serverless service for processing both batch and streaming data pipelines on Google Cloud

Answer 981

A y D La elección entre Bigtable y BigQuery depende fundamentalmente del tipo de trabajo que necesites realizar: Bigtable es para cargas de trabajo operativas y de aplicaciones (OLTP), mientras que BigQuery es para análisis de datos a gran escala (OLAP). Casos de Uso para Bigtable ✅ A) Cuando necesitas una latencia ultra baja para consultas NoSQL. Esta es la razón principal para elegir Bigtable. Está diseñado para ofrecer respuestas en milisegundos de un solo dígito, lo cual es esencial para aplicaciones que necesitan leer o escribir datos rápidamente, como perfiles de usuario, paneles de control en tiempo real o datos de series temporales. BigQuery, en cambio, tarda segundos o más en responder, ya que está optimizado para analizar grandes volúmenes de datos, no para consultas rápidas. D) Cuando necesitas un alto rendimiento para datos a gran escala. Bigtable está construido para manejar un rendimiento (throughput) muy alto, soportando millones de lecturas y escrituras por segundo. Es ideal para la ingesta masiva de datos provenientes de fuentes como el Internet de las Cosas (IoT) o para servir datos a aplicaciones con muchos usuarios concurrentes. Casos de Uso para BigQuery ❌ B) Cuando necesitas almacenar petabytes de datos. Si bien es cierto que Bigtable puede manejar esta cantidad de datos, BigQuery también puede hacerlo. Por lo tanto, el volumen de datos por sí solo no es un factor decisivo para elegir uno sobre el otro. Ambos servicios escalan a nivel de petabytes. C) Cuando requieres análisis SQL avanzado. Este es el dominio exclusivo de BigQuery. BigQuery es un almacén de datos analítico cuyo lenguaje principal es SQL, permitiendo realizar consultas complejas, uniones (joins) y agregaciones sobre conjuntos de datos masivos. Bigtable es una base de datos NoSQL y no soporta consultas SQL.

Answer 982

B BigQuery’s analytic window functions enable advanced analytical operations like running totals and moving averages within specified partitions of data

Answer 983

B Streaming systems must be resilient to data spikes and unexpected delays, as latency and varying data volumes are common challenges in real-time analytics

Answer 984

B The slides describe a standard, resilient architecture where Pub/Sub acts as the initial ingestion point and scalable buffer for streaming data. Dataflow is the serverless processing engine used to transform and analyze the stream in real-time. Finally, BigQuery serves as the durable storage layer (data warehouse) for the processed data, allowing for powerful interactive analysis.

Answer 985

D The summary explicitly states that "Bigtable can handle NoSQL queries over large datasets (petabytes) in milliseconds." This perfectly matches the requirement for high-throughput writes and low-latency NoSQL-style reads, which is Bigtable's primary use case, distinguishing it from BigQuery's focus on analytical SQL queries.

Answer 986

B y D The slides define streaming as "data processing for unbounded data sets," making option A incorrect. The text on page 2 highlights two main challenges: "ingest varying amounts of data because you could have spikes" (D) and the need "to be able to deal with unexpected delays because latency is a fact of life" (B). Option C is a description of a storage service like BigQuery or Bigtable, not the process of streaming itself.

Answer 987

B The summary on page 3 specifically calls out "BigQuery's analytic window functions for advanced analysis" (ideal for moving averages) and that "BigQuery has built in GIS functionality" (for geographic analysis). The other options describe features of different services: Pub/Sub (A), Bigtable (C), and Dataflow (D).

Answer 988

C Page 2 identifies Pub/Sub as a "messaging service used as a starting point to process streaming data." Its core function in a resilient architecture is to act as a highly scalable buffer that can absorb data spikes and reliably hold messages, thus decoupling the services that produce the data from the services (like Dataflow) that consume and process it. This prevents data loss if downstream systems are slow or unavailable.

Answer 989

B Streaming data is continuously generated and processed in real-time, as per the course summary, contrasting with batch processing.

Answer 990

C Pub/Sub is a messaging service for sending and receiving messages, commonly used to ingest streaming data, as noted in the attachment.

Answer 991

B Dataflow is a serverless service for processing both batch and streaming data, using Apache Beam, as per the course summary.

Answer 992

C BigQuery supports streaming data into tables for durable storage and SQL-based analysis, aligning with its role in the attachment.

Answer 993

B BigTable is optimized for NoSQL queries with high throughput and low latency, making it suitable for petabyte-scale datasets, as per the attachment.

Answer 994

B La Relación: Círculos Concéntricos 🎯 La mejor manera de entender la relación entre Inteligencia Artificial (IA), Machine Learning (ML) y Deep Learning (DL) es imaginarlos como círculos concéntricos o muñecas rusas, donde uno contiene al otro. Inteligencia Artificial (IA) - El Círculo Exterior: Es el campo más amplio y antiguo. Su objetivo es crear máquinas capaces de simular la inteligencia humana: razonar, aprender, percibir y resolver problemas. La IA incluye muchísimas técnicas, desde sistemas basados en reglas lógicas hasta los métodos de aprendizaje modernos. Machine Learning (ML) - El Círculo Intermedio: Es un subcampo de la IA. En lugar de programar explícitamente las reglas, el ML se basa en algoritmos que "aprenden" patrones directamente de los datos. Le das al sistema muchos ejemplos y él deduce las reglas por sí mismo. La gran mayoría de las aplicaciones de "IA" que vemos hoy en día son, en realidad, aplicaciones de Machine Learning. Deep Learning (DL) - El Círculo Interior: Es un subcampo especializado del Machine Learning. Utiliza una arquitectura específica llamada "redes neuronales artificiales profundas" (con muchas capas). El Deep Learning es especialmente bueno para encontrar patrones muy complejos en enormes cantidades de datos, lo que lo ha convertido en la tecnología detrás de los grandes avances en reconocimiento de imágenes, traducción automática y vehículos autónomos. Por lo tanto, la afirmación correcta es: El Deep Learning es un tipo de Machine Learning, que a su vez es un tipo de Inteligencia Artificial. Por qué las otras opciones son incorrectas ❌ A) La IA es un tipo de Machine Learning, y el Deep Learning es un tipo de IA. Esto es incorrecto porque invierte la relación principal. El Machine Learning es un tipo de IA, no al revés. C) El Machine Learning y el Deep Learning son dos formas distintas de Inteligencia Artificial, pero no son subconjuntos el uno del otro. Esto es incorrecto porque, aunque ambas son formas de IA, el Deep Learning es decididamente un subconjunto del Machine Learning. No son campos paralelos e independientes. D) La Inteligencia Artificial se ocupa principalmente del análisis de datos retrospectivo, mientras que el ML y el DL se centran en conocimientos predictivos. Esto crea una distinción falsa. El objetivo de la IA moderna es, en gran medida, la predicción y la toma de decisiones. El ML y el DL son precisamente las herramientas más potentes dentro de la IA para lograr esas capacidades predictivas.

Answer 995

C Explicación: Pasado vs. Futuro La diferencia fundamental entre Business Intelligence (BI) y Machine Learning (ML) radica en la pregunta que intentan responder, lo que define cómo utilizan los datos. Business Intelligence (BI) - Mira hacia atrás (Descriptivo) BI se enfoca en analizar datos históricos para entender lo que ha sucedido. Su objetivo es presentar el pasado y el presente de una manera comprensible a través de informes, cuadros de mando y visualizaciones. Responde a preguntas como: "¿Cuáles fueron nuestras ventas totales el trimestre pasado?" "¿Qué región tuvo el mejor rendimiento este año?" Piensa en BI como el espejo retrovisor y el salpicadero de un coche: te dicen a qué velocidad vas ahora y por dónde has pasado. Machine Learning (ML) - Mira hacia adelante (Predictivo) ML utiliza datos históricos para aprender patrones y luego usar esos patrones para hacer predicciones sobre el futuro o tomar decisiones automatizadas. Responde a preguntas como: "¿Qué clientes tienen más probabilidades de abandonar nuestro servicio el próximo mes?" "¿Cuál será la demanda de este producto la semana que viene?" Piensa en ML como el GPS de un coche: utiliza datos actuales e históricos para predecir la mejor ruta, el tiempo de llegada y los posibles atascos. ¿Por qué las otras opciones son incorrectas? A: Esta opción invierte los roles. Es ML, no BI, quien usa algoritmos para obtener información predictiva. ❌ B: Esta afirmación es incorrecta. Las herramientas de BI modernas están diseñadas para reducir la necesidad de código personalizado para análisis, mientras que muchos proyectos de ML requieren una cantidad significativa de código. ❌ D: Esta opción también invierte los roles. Es ML el que se utiliza para tomar decisiones escalables y automatizadas (como la detección de fraudes), mientras que BI proporciona información para decisiones humanas. ❌

Answer 996

B, C y D Machine Learning is exciting because it allows problems to be solved scalably using data examples, "without the need for any custom code". Deep Learning is noted for its ability to work effectively even with unstructured data such as images, speech, video, and natural language text. A fundamental difference highlighted is that in Machine Learning, machines "learn" and "become intelligent," rather than starting with pre-programmed intelligence. Option A is incorrect as ML is about solving problems without custom code.

Answer 997

B Keller Williams, a U.S. real estate company, leverages AutoML Vision to "automatically recognize specific features of houses like built-in bookcases". This application allows them to "automatically search home listing photos for specific features like granite countertops" by training a custom model. This helps agents list houses faster and helps buyers find homes that meet their needs. The process involves feeding existing images and videos into a pre-built AutoML Vision model and customizing it "without writing a line of code

Answer 998

C Google Cloud offers different options for leveraging machine learning. For users with "limited knowledge of machine learning," AutoML is presented as a suitable choice. AutoML allows users to "build on Google's machine learning capabilities, to create your own custom machine learning models that are tailored to your specific business needs," and integrate them into applications "All without running a line of TensorFlow code". While options A and B are valid ways to leverage ML on Google Cloud, A (custom models with TensorFlow) is for "Advanced users who want more control" and "data scientists with the skills", and B (pre-trained models) are "ready for immediate use" without needing to bring your own data, rather than for creating custom models tailored to specific business needs using the user's data. Option D is a general infrastructure option but not the primary or easiest way to build ML models for someone with limited ML knowledge.

Answer 999

B y D Deep Learning is a type of Machine Learning, and it excels at processing unstructured data such as images, text, and audio.

Answer 1000

B ¿Por qué la opción B es la correcta? ✅ B) AutoML AutoML (ahora parte de la suite de Vertex AI) es un servicio de Google Cloud diseñado específicamente para automatizar el proceso de creación de modelos de machine learning. Su principal característica y propuesta de valor es que permite a los usuarios con poca o ninguna experiencia en programación entrenar modelos personalizados de alta calidad. El proceso se realiza a través de una interfaz gráfica de usuario (GUI) muy intuitiva: Subes tus datos ya etiquetados (por ejemplo, imágenes de gatos y perros, o textos con análisis de sentimiento). Seleccionas el tipo de modelo que quieres (clasificación de imágenes, de texto, etc.). Haces clic en "Entrenar". AutoML se encarga automáticamente de todo lo demás: la ingeniería de características, la búsqueda de la mejor arquitectura de modelo (Neural Architecture Search), el entrenamiento y el ajuste de hiperparámetros. Es la definición perfecta de una solución para entrenar modelos sin escribir código. Analogía: AutoML es como un chef experto en machine learning. Tú solo le das los ingredientes (tus datos) y le dices qué plato quieres (un modelo de clasificación), y él se encarga de crear la mejor receta (el modelo) posible para ti. ¿Por qué las otras opciones son incorrectas? ❌ A) TensorFlow TensorFlow es una biblioteca de software de código abierto, no un servicio gestionado que funciona sin código. Es una caja de herramientas increíblemente potente para que los programadores e investigadores construyan modelos de ML desde cero. Requiere escribir código, generalmente en Python. Es lo opuesto a una solución "sin código". C) BigQuery ML BigQuery ML permite crear modelos de machine learning directamente dentro de BigQuery usando consultas SQL. Aunque simplifica enormemente el proceso y no requiere Python, sí requiere escribir código SQL (por ejemplo, CREATE MODEL ...). Por lo tanto, se considera una solución de "bajo código" (low-code), no una de "sin código" (no-code), que es lo que pide la pregunta. D) Cloud TPUs Las Cloud TPUs (Tensor Processing Units) son hardware especializado. Son aceleradores de hardware (como las GPUs) diseñados por Google para acelerar el entrenamiento de modelos de ML. Son la infraestructura sobre la que se ejecuta el código de entrenamiento (escrito en TensorFlow, PyTorch, etc.). No son un servicio para crear modelos, sino el "motor" que hace que el entrenamiento sea mucho más rápido.

Answer 1001

B ML enables forward-looking insights and helps scale decision-making using historical data, unlike traditional BI which is often descriptive and backward-looking.

Answer 1002

B BigQuery ML lets users train and use ML models directly using SQL, making ML more accessible for analysts.

Answer 1003

A, B y D Vision API and Natural Language API are pre-trained models used for image and text analysis respectively. Dialogflow is used for conversational AI. Compute Engine is for general-purpose VM hosting, not ML-specific.

Answer 1004

C Machine Learning is a subset of Artificial Intelligence, and Deep Learning is a subset of Machine Learning.

Answer 1005

B ML models automate the extraction of predictive insights from data, making analysis scalable and less reliant on manual, repetitive work

Answer 1006

A y C Por qué las respuestas A y C son correctas A) AutoML: Este es el servicio de Google Cloud que está diseñado específicamente para que desarrolladores y científicos de datos sin experiencia en aprendizaje automático (ML) puedan entrenar modelos de alta calidad con un mínimo esfuerzo y sin escribir código. AutoML automatiza el proceso de construir modelos, desde la preparación de los datos hasta el despliegue del modelo final. C) Vertex AI (con opciones sin código): Vertex AI es la plataforma unificada de Google Cloud para el desarrollo de ML. Combina los servicios de AutoML y otros servicios de ML, permitiendo la creación de modelos tanto con código como sin él. Las opciones sin código de Vertex AI son, de hecho, los servicios de AutoML. Esto significa que Vertex AI incluye la funcionalidad de AutoML como parte de su suite, lo que la convierte en una respuesta válida. Por qué las respuestas B y D son incorrectas B) Vision API: Esta no es una herramienta para crear modelos personalizados. En cambio, es un servicio de ML pre-entrenado que permite a los desarrolladores analizar imágenes y obtener información como la detección de objetos, el reconocimiento de texto y la detección de rostros, sin necesidad de entrenar un modelo propio. Es una solución lista para usar, no una herramienta de creación de modelos. D) BigQuery ML: Si bien BigQuery ML permite a los usuarios crear modelos de ML directamente en BigQuery utilizando sentencias SQL, requiere escribir código (aunque sea SQL, que es un lenguaje declarativo). La pregunta especifica "sin escribir código". Por lo tanto, BigQuery ML no cumple con ese requisito.

Answer 1007

B ✅ Opción Correcta B) They are ready for immediate use and do not require custom training (Están listos para su uso inmediato y no requieren entrenamiento personalizado) Esta es la respuesta correcta y describe el principal valor de estas APIs. Google ya ha hecho el trabajo pesado de entrenar estos modelos con conjuntos de datos masivos y de alta calidad. Como resultado, los modelos ya son "expertos" en sus tareas (reconocer objetos, entender texto, traducir idiomas, etc.). Un desarrollador puede simplemente enviar sus datos (una imagen, un párrafo) a la API y recibir una respuesta inteligente al instante, sin necesidad de tener conocimientos de aprendizaje automático ni de pasar por un largo y costoso proceso de entrenamiento. ❌ Opciones Incorrectas A) They require users to provide large amounts of custom training data (Requieren que los usuarios proporcionen grandes cantidades de datos de entrenamiento personalizados) Esto es falso. Es precisamente lo contrario a su propósito. Los servicios que sí requieren datos de entrenamiento personalizados son herramientas como AutoML o Vertex AI, que sirven para crear un modelo a tu medida. Los modelos pre-entrenados ya vienen listos. C) They can only process numerical data (Solo pueden procesar datos numéricos) Esto es falso. Los ejemplos dados en la propia pregunta lo desmienten. La Vision API procesa datos de imagen, y la Natural Language API procesa datos de texto. Ambas son formas de datos no estructurados. D) They are only available to advanced data scientists (Solo están disponibles para científicos de datos avanzados) Esto también es falso. De hecho, uno de sus objetivos es democratizar el acceso a la Inteligencia Artificial. Están diseñados para que cualquier desarrollador, incluso sin ser un experto en Machine Learning, pueda integrar estas potentes capacidades en sus aplicaciones mediante una simple llamada a una API.

Answer 1008

A y C ML models can make real-time predictions and automate the analysis of multiple variables, leading to better, data-driven inventory decisions. Traditional BI dashboards are typically limited to historical summaries and require more manual analysis

Answer 1009

C La Respuesta Correcta: Opción C AutoML Vision (Actualmente parte de Vertex AI). ¿Por qué encaja perfectamente? Requisito de "Custom" (Personalizado): La empresa necesita detectar sus defectos específicos en sus productos. La Vision API genérica sabe qué es un "zapato", pero no sabe si ese zapato tiene una costura rota. AutoML entrena un modelo nuevo basándose en tus imágenes etiquetadas. Requisito de "Limited experience" (Poca experiencia en código): El equipo no sabe usar TensorFlow. AutoML está diseñado específicamente para esto: subes las fotos, pulsas un botón, y Google busca el mejor modelo por ti sin que escribas una sola línea de código de redes neuronales. Por qué las otras son "malas" para este caso Opción A: The pre-trained Vision API El problema: Es demasiado genérica. Por qué falla: Esta API ya viene entrenada por Google para reconocer cosas comunes (un gato, la Torre Eiffel, una cara feliz). El fallo lógico: No puedes enseñarle cosas nuevas. Si le pasas una pieza de metal de tu fábrica, te dirá "Esto es metal", pero no te dirá "Esto es metal defectuoso", porque Google no entrenó la API con los defectos de tu fábrica. Opción B: BigQuery ML El problema: El tipo de datos. Por qué falla: BigQuery ML es fantástico para hacer Machine Learning usando SQL sobre datos estructurados (tablas, números, ventas, categorías). Aunque BQML ha avanzado y ahora tiene integraciones para "llamar" a modelos de imágenes, no es la herramienta nativa ni el flujo de trabajo estándar para entrenar desde cero un modelo de clasificación de imágenes visuales píxel a píxel. Opción D: Vertex AI with a custom-trained model El problema: La curva de aprendizaje (Skills gap). Por qué falla: La pregunta dice explícitamente: "limited experience in writing complex machine learning code like TensorFlow". La opción D requiere que un científico de datos escriba el código de la red neuronal en Python/TensorFlow, lo empaquete en un contenedor Docker y lo suba. Es la opción más potente, pero el equipo no tiene las habilidades para usarla.

Answer 1010

B The key requirements are making predictions on structured data that already resides in BigQuery and empowering a team that uses SQL. A) Dataproc is a managed service for running Apache Spark and Hadoop clusters, which is not what's needed for SQL-based ML. B) BigQuery ML is the correct answer. As shown in the bicycle rental example (slide 19), it allows users to create, train, and run ML models (like linear regression or logistic regression for churn) directly within BigQuery using familiar SQL syntax. C) Cloud Spanner is a globally distributed relational database, not a tool for machine learning. D) The Natural Language API is used for analyzing unstructured text, not for building a predictive churn model on tabular data.

Answer 1011

C The Venn diagram on slide 4 and the explanation on slide 7 clearly define the relationship between these terms. A) is incorrect. The presentation distinguishes between AI and ML, with ML being a subset of AI. B) is incorrect. The hierarchy is the other way around: AI is the broad field, and Deep Learning is a very specific subfield within it. C) is correct. This statement accurately reflects the definitions provided. AI is the overall concept ("computers think/act like humans"), and ML is a practical approach within AI to "scalably solve those problems using data examples." D) is incorrect. This reverses the roles. Deep Learning is particularly powerful for unstructured data, while standard Machine Learning techniques are often applied to structured data.

Answer 1012

D ✅ Opción D: Call the pre-trained Cloud Natural Language API. Esta es la respuesta correcta porque cumple todos los requisitos clave de la pregunta: Sin entrenar un modelo propio: La Cloud Natural Language API es un modelo pre-entrenado por Google con una cantidad masiva de texto. Ya "sabe" identificar temas generales. Temas generales: Una de sus funciones principales es la clasificación de contenido (Content Classification), que hace exactamente lo que se pide: analiza un texto y lo etiqueta con categorías como /Sports, /Technology, /Arts & Entertainment, etc. Rápido y con mínimo esfuerzo: Al ser una API, la implementación es muy sencilla. Solo necesitas enviar el texto del artículo en una llamada a la API y recibirás las etiquetas como respuesta en formato JSON. No hay que gestionar infraestructura, entrenar modelos ni ser un experto en machine learning. Es la forma más rápida de obtener resultados. ❌ Opción A: Build a custom model using Vertex AI and TensorFlow. Esto es incorrecto porque es la opción que requiere más esfuerzo y experiencia. Construir un modelo personalizado con TensorFlow en Vertex AI te da un control total, pero implica diseñar la arquitectura del modelo, prepararle los datos de entrenamiento, entrenarlo y desplegarlo. Es un proceso largo y complejo, justo lo contrario de "rápido" y "mínimo esfuerzo". ❌ Opción B: Use AutoML Natural Language to train a custom classification model. Esto también es incorrecto porque requiere entrenamiento. AutoML simplifica el proceso de crear un modelo personalizado (no tienes que escribir el código del modelo), pero aún necesitas proporcionarle tus propios datos etiquetados para entrenarlo. La pregunta especifica claramente que la solución no debe requerir entrenamiento con datos propios. ❌ Opción C: Use BigQuery ML to analyze the text of the articles. Esta opción es ineficiente y no es la herramienta principal para esta tarea. BigQuery ML (BQML) permite crear y ejecutar modelos de machine learning directamente dentro de BigQuery usando SQL. Si bien podrías usar un modelo de BQML para clasificar texto, primero tendrías que cargar todos los artículos en BigQuery. Es un paso innecesario y mucho menos directo que simplemente llamar a una API para cada artículo nuevo que llega. La Natural Language API está diseñada precisamente para este tipo de interacciones en tiempo real o casi real.

Answer 1013

C The presentation (slides 5, 6, and 17) emphasizes that the limitation of manual, ad-hoc analysis is its lack of scalability and its reliance on hunches. ML is introduced as the solution to automate and scale decision-making. A) is incorrect. ML typically requires large amounts of historical data for training; it doesn't reduce storage needs. B) is incorrect. While dashboards can be augmented with ML predictions (slide 18), the core benefit of ML is the prediction itself, not just the visualization. C) is correct. This captures the essence of the transition: moving from a manual process ("ad-hoc analysis") to an automated, predictive, and scalable one ("make repeated decisions," "scaling up BI and decision-making"). D) is incorrect. ML models automate specific tasks, but they don't eliminate the need for data analysts who are still required to interpret results, ask new questions, and manage the overall data strategy.

Answer 1014

B Research suggests that AI is the broader field encompassing techniques that mimic human intelligence, with ML as a subset focusing on algorithms that learn from data, and Deep Learning as a further subset using neural networks for complex pattern modeling.

Answer 1015

B The evidence leans toward Machine Learning automating data analysis, reducing manual effort and minimizing errors, thus enhancing efficiency in decision-making processes.

Answer 1016

B Research suggests that AutoML is designed to democratize ML, enabling users without extensive expertise to create custom models, enhancing accessibility.

Answer 1017

C The sources consistently define unstructured data as information that comes in forms like audio, video, images, and freeform text. It is characterized by being free from strict formatting rules and lacking a predefined data model, unlike structured data found in databases or spreadsheets

Answer 1018

B Unstructured data is "hard" because there's "a lot going on" and it's challenging to extract useful information due to its lack of a predefined data model. Despite this, it holds "tremendous potential". The solution discussed is to "process unstructured data by labeling it with AI" to extract its intrinsic value.

Answer 1019

A, C y D 🧐 Análisis de las Opciones ✅ A) Eliminan la necesidad de que las organizaciones entrenen modelos de aprendizaje automático con sus propios datos. ¿Por qué es CORRECTA? Este es el beneficio principal de los modelos pre-entrenados. Google (o cualquier proveedor de nube) ya ha entrenado estos modelos con enormes conjuntos de datos genéricos (millones de imágenes, textos, etc.). Esto permite a los usuarios implementar funcionalidades de ML (como detección de objetos o análisis de sentimientos) de forma inmediata sin tener que invertir tiempo y recursos en la recolección de datos y el proceso de entrenamiento. ❌ B) Están garantizados para proporcionar buenos resultados para cualquier tipo de dato no estructurado, independientemente de sus características. ¿Por qué es INCORRECTA? En el aprendizaje automático, no existe tal garantía. El rendimiento de un modelo pre-entrenado siempre depende de qué tan bien los datos de entrada del usuario (su dato no estructurado) se alinean con los datos que se utilizaron para entrenar el modelo. Si los datos del usuario son muy específicos, especializados o raros (por ejemplo, imágenes médicas raras o jerga de un nicho industrial), el modelo pre-entrenado probablemente tendrá un rendimiento deficiente. ✅ C) Los usuarios simplemente pasan sus datos a través de una API, y los productos devuelven predicciones. ¿Por qué es CORRECTA? Esta es la definición operativa de una API de ML pre-entrenada. El usuario envía los datos (una imagen, un fragmento de texto) mediante una llamada a la API (por ejemplo, enviando el JSON), y el modelo pre-entrenado que reside en la nube de Google procesa la solicitud y devuelve la predicción (por ejemplo, la etiqueta de la imagen, la puntuación de sentimiento). ✅ D) Una desventaja principal es que si sus datos no estructurados quedan fuera del alcance de los datos utilizados para entrenar los modelos pre-entrenados de Google, los resultados pueden ser deficientes. ¿Por qué es CORRECTA? Esta afirmación captura la limitación clave de los modelos pre-entrenados. Si el modelo fue entrenado con perros y gatos, pero se le da la imagen de una especie rara de pez, es probable que el resultado sea malo o incorrecto. Si un usuario tiene datos muy especializados, deberá considerar opciones más avanzadas, como AutoML o entrenamiento de modelos personalizados, en lugar de depender únicamente de la API pre-entrenada. 📝 Conclusión Las APIs de Modelos de ML pre-entrenados ofrecen beneficios de velocidad y facilidad de uso (A y C), pero vienen con la limitación (D) de que su rendimiento está sujeto a si los datos del usuario coinciden con los datos de entrenamiento originales. Nunca hay una garantía universal de buenos resultados (B).

Answer 1020

A, B y C The Cloud Natural Language API provides syntactic analysis for linguistic information, entity analysis for recognizing various useful items, and sentiment analysis to label feelings in text. The Video Intelligence API, while mentioned as an equivalent for video data, is a separate API and not a feature of the Cloud Natural Language API

Answer 1021

A, B, C y D El concepto clave: Datos no estructurados 🖼️ Antes de analizar cada opción, es importante entender qué son los datos no estructurados. Datos estructurados: Son datos organizados en un formato predefinido, como una tabla en una base de datos o una hoja de cálculo con filas y columnas claras (ej: una lista de clientes con nombre, email y fecha de compra). Datos no estructurados: Son datos que no tienen un modelo interno definido. El ejemplo más claro son las imágenes, pero también incluye texto libre, vídeos o archivos de audio. Para un ordenador, una imagen es solo una matriz de píxeles; el machine learning es la técnica que permite extraer significado de esa matriz. La pregunta busca casos donde se aplique machine learning a este tipo de datos. Como verás, todas las opciones usan imágenes como su materia prima. Análisis de cada opción Todas las opciones describen un escenario donde un modelo de machine learning analiza imágenes (datos no estructurados) para realizar una tarea específica. A) Usar un modelo de imagen personalizado para determinar los precios de los coches. ✅ Dato no estructurado: Las imágenes de los coches. Tarea de ML: El modelo analiza la imagen para identificar la marca, el modelo, el estado de conservación, extras visibles, etc., y con esa información predice un valor numérico (el precio). Es un caso de uso clásico de visión por ordenador (computer vision). B) Diferenciar entre nubes y cubierta de nieve en imágenes de satélite. ✅ Dato no estructurado: Las imágenes de satélite. Tarea de ML: Es un problema de clasificación de imágenes. El modelo aprende a reconocer los patrones visuales, texturas y formas que distinguen a las nubes de la nieve, algo que puede ser difícil de programar con reglas fijas. C) Rastrear la flota mundial de portacontenedores a través de imágenes satelitales para la previsión económica. ✅ Dato no estructurado: Las imágenes satelitales de océanos y puertos. Tarea de ML: Aquí se usa la detección de objetos. El modelo está entrenado para identificar y contar barcos en las imágenes. El número de barcos en tránsito o en puerto es un indicador de la actividad económica, por lo que estos datos se usan luego para modelos de previsión. D) Diagnosticar condiciones médicas como la Retinopatía Diabética a partir de imágenes médicas de alta resolución. ✅ Dato no estructurado: Las imágenes médicas (escaneos de retina). Tarea de ML: Es un caso de clasificación de imágenes de alto impacto. El modelo de deep learning se entrena con miles de imágenes previamente diagnosticadas por médicos para aprender a detectar microaneurismas u otras señales de la enfermedad, a menudo con una precisión igual o superior a la de un especialista. En resumen, dado que las imágenes son una forma primordial de datos no estructurados y todas las opciones se basan en analizarlas con machine learning, todas son correctas.

Answer 1022

C Google’s prebuilt ML APIs (like Vision, Natural Language, Speech-to-Text) allow you to send unstructured data (e.g., text, images, audio) and receive predictions without training a model yourself.

Answer 1023

A, B y D The Cloud Natural Language API supports sentiment analysis, syntactic analysis, and entity analysis. Image labeling is handled by the Vision API.

Answer 1024

B Unstructured data (e.g., text, images, audio) does not follow a consistent format or schema, making it hard to process with traditional tools.

Answer 1025

D Por qué la opción D es la correcta En el análisis de sentimiento, generalmente se devuelven dos valores clave: Puntuación (Score): Es la dirección del sentimiento. Te dice si el texto es positivo, negativo o neutro. Generalmente se mide en una escala (ej. de -1.0 a +1.0). Magnitud (Magnitude): Es la intensidad o la cantidad total de emoción expresada en el texto, independientemente de si es positiva o negativa. Es un valor que (generalmente) va de 0 en adelante. Ejemplos para entenderlo: Texto: "El coche es funcional." Puntuación: Neutral (cercano a 0) Magnitud: Muy baja (cercano a 0). Es una declaración objetiva. Texto: "Me gusta la película." Puntuación: Positiva (ej. +0.5) Magnitud: Baja (ej. 0.5). Es un sentimiento positivo, pero débil. Texto: "¡¡¡Absolutamente odio este producto, es horrible!!!" Puntuación: Negativa (ej. -0.9) Magnitud: Alta (ej. 1.8). El sentimiento es muy fuerte. Texto: "¡¡¡Amo esta película, es la mejor que he visto en mi vida!!!" Puntuación: Positiva (ej. +0.9) Magnitud: Alta (ej. 1.8). El sentimiento también es muy fuerte. La magnitud mide el "volumen" de la emoción; la puntuación mide su "dirección" (positiva o negativa). Por qué las otras opciones son incorrectas A. La categoría emocional (ej. feliz, triste): Esto se refiere a la clasificación de emociones, que es un tipo de análisis diferente (y más complejo) que el simple análisis de sentimiento (positivo/negativo). Además, si algo describe la diretiva de la emoción, sería la Puntuación (Score), no la Magnitud. B. La frecuencia de palabras positivas: Esto es incorrecto. La magnitud no solo cuenta palabras, sino que también incluye la intensidad de las palabras negativas. Un texto 100% negativo y muy intenso tendrá una magnitud alta. C. La longitud del texto: Es incorrecto. Un texto muy largo puede ser completamente neutral (como un artículo técnico o un informe legal) y tendrá una magnitud muy baja. Un texto muy corto (ej. "¡Te odio!") puede tener una magnitud muy alta. La longitud no es el factor determinante.

Answer 1026

B Prebuilt APIs work best when your input data is within the scope of the data used to train the model. Otherwise, the results may be inaccurate or irrelevant.

Answer 1027

B ✅ La respuesta correcta: B Customer emails (Correos electrónicos de clientes) Por qué es "Unstructured" (No estructurado): Los correos electrónicos no tienen un formato predefinido ni una longitud fija. El contenido es texto libre: cada cliente escribe de forma distinta, usa diferentes idiomas, incluye imágenes o firmas variadas. Procesamiento: Para que un ordenador "entienda" un correo, no basta con leer una columna; se necesitan técnicas avanzadas como NLP (Procesamiento de Lenguaje Natural) para extraer sentimientos o intenciones. Dato curioso: Se estima que el 80-90% de los datos generados en las empresas hoy en día son no estructurados. ❌ Las respuestas incorrectas (Structured Data) Todas las demás opciones son ejemplos clásicos de Datos Estructurados, ya que tienen un formato rígido, etiquetas claras y caben perfectamente en filas y columnas: A) Inventory tables in a relational database Por qué es estructurado: Una tabla de inventario tiene columnas fijas (Nombre, Cantidad, Precio). Sabes exactamente qué tipo de dato hay en cada celda y puedes hacer operaciones matemáticas con ellos fácilmente. C) Sales figures in a spreadsheet Por qué es estructurado: Las cifras de ventas en una hoja de cálculo están organizadas por fechas, montos y regiones. Están listas para ser sumadas, promediadas o filtradas sin necesidad de interpretarlas. D) Product IDs in an ERP system Por qué es estructurado: Un ID de producto sigue un patrón (por ejemplo, 10 dígitos numéricos). Es un dato atómico y preciso diseñado específicamente para que los sistemas informáticos lo procesen de forma inequívoca.

Answer 1028

C Prebuilt ML APIs are designed to handle common tasks (like image recognition or text analysis) without the need for users to train their own models, making them accessible and efficient for many organizations.

Answer 1029

B The Cloud Natural Language API is specifically designed for text analysis, including sentiment analysis, entity recognition, and content classification.

Answer 1030

A, B y D ✅ A) Sentiment Correcto. El análisis de sentimiento es una de las funciones más populares de la API. Puede analizar un bloque de texto y determinar si la opinión expresada es positiva, negativa o neutra. También proporciona una puntuación de magnitud para indicar la fuerza de esa emoción. Ejemplo: Para la frase "¡Me encantó la película, pero el final fue un poco decepcionante!", la API podría identificar un sentimiento general mixto, con una parte positiva fuerte y una negativa más débil. ✅ B) Entities (like people, locations, dates) Correcto. El reconocimiento de entidades permite a la API leer el texto e identificar y clasificar "cosas" con nombre propio. Esto incluye: Personas: "Juan Pérez", "CEO de Google" Lugares: "Madrid", "Monte Everest", "Torre Eiffel" Organizaciones: "Google", "Naciones Unidas" Fechas y Eventos: "1492", "ayer", "Juegos Olímpicos" Bienes de consumo: "iPhone 15", "Coca-Cola" ✅ D) Syntactic structure Correcto. El análisis sintáctico es una función avanzada que descompone cada oración en sus componentes gramaticales. Puede identificar el sujeto, el verbo, el objeto y las relaciones entre las palabras (por ejemplo, qué adjetivo modifica a qué sustantivo). Esto se representa en un árbol de dependencias. ❌ C) Image labels Incorrecto. Esta función pertenece a una API completamente diferente: la Cloud Vision API. La Natural Language API trabaja exclusivamente con texto. La Vision API, en cambio, toma una imagen como entrada y puede generar etiquetas ("labels") que describen lo que hay en ella, como "coche", "perro", "montaña", "atardecer", etc.

Answer 1031

B Prebuilt ML APIs are trained on large, general datasets. If your data is outside the scope of what the API was trained on, the results may not be accurate or useful

Answer 1032

C Page 5 explicitly mentions that Uniqlo used Dialogflow to "create a new shopping experience." Dialogflow is described as a natural language understanding platform for building conversational user interfaces like chatbots and interactive voice response systems.

Answer 1033

B y D Page 9 explains the trade-offs of using pretrained APIs. The primary advantage (D) is that you don't have to train your own models; you just pass your data via an API. The primary downside (which implies its corollary B) is that performance suffers if your data is not within the scope of the data used to train Google's models. Statement A is incorrect because the models are "pre-trained." Statement C is incorrect because these are managed services, and Google handles the underlying infrastructure.

Answer 1034

C Page 14, "Entity analysis recognizes many useful items," explicitly lists "People," "Locations and landmarks," and by extension, organizations as items that can be recognized. This is the definition of entity analysis.

Answer 1035

A Page 15, "Sentiment analysis labels feelings in text," describes this exact function. It identifies the emotional opinion of a writer's attitude and presents it as a numerical score (sentiment) and a magnitude, grouping emotions into positive, negative, or neutral categories.

Answer 1036

C age 11 defines unstructured data as "Data outside of a database without a predefined data model" and gives examples such as email, audio, video, images, and texts. This perfectly matches the description in the question.

Answer 1037

B Unstructured data, such as audio, video, images, and freeform text, does not have a predefined format or organization, making it challenging to process and analyze compared to structured data. This is a key concept in the module, as most business data is unstructured, with a significant portion being text.

Answer 1038

C The lack of structure in unstructured data means that traditional data processing methods are not applicable, and specialized techniques, often involving machine learning, are required to derive value from it. The module highlights this challenge, noting that extracting useful information from unstructured data is inherently difficult.

Answer 1039

B These APIs, such as the Vision API and Natural Language API, allow users to leverage Google's pre-trained models to extract insights from unstructured data, such as images, text, and audio, by making API calls. This saves time and resources that would otherwise be spent on model training, as emphasized in the module.

Answer 1040

C he Vision API is used for image processing and analysis, such as detecting objects, faces, and text within images. This is crucial for applications dealing with visual data, and the module mentions the Vision API as a key tool for handling unstructured image data, such as in medical image analysis for conditions like Diabetic Retinopathy.

Answer 1041

B For the APIs to provide accurate results, the user's unstructured data should be similar to the data on which Google's models were trained. If the data is too different, the results may not be reliable, as noted in the module when discussing the limitations of prebuilt ML APIs.

Answer 1042

B Standard software development tools are not very efficient for data analysis and machine learning coding because it often involves looking at plots, repeatedly executing small chunks of code, and frequently printing output [1]. Notebook environments seamlessly integrate commentary, plots, and code, organizing individually executable pieces of code into cells, which addresses these issues [2].

Answer 1043

B **Explanation:** When your Notebooks are hosted in the cloud, you can develop together quite easily, and they are available even when your computer isn’t on, similar to Google Docs [3]. Traditional notebooks suffer from issues like the host machine going to sleep, preventing collaboration [4].

Answer 1044

B **Explanation:** The BigQuery "magic" function is useful for checking query format, accuracy, and viewing output, but you "can’t use query output for anything" [5]. In contrast, the BigQuery API in Notebooks allows you to return query results as a Pandas DataFrame, enabling you to manipulate the data further [6].

Answer 1045

C Por qué la C es correcta ✅ C) Puedes usar cualquier tipo de instancia de Compute Engine y ajustar fácilmente el hardware subyacente, incluso añadiendo o eliminando GPUs, incluso después de la creación de la VM. Esta afirmación es verdadera. Los Notebooks en Google Cloud, ya sea a través de Vertex AI Workbench o Deep Learning VMs, se ejecutan sobre instancias de Compute Engine. Esto significa que puedes aprovechar la flexibilidad de Compute Engine para personalizar el hardware. Puedes modificar la CPU, la RAM, el disco duro, y, lo que es más importante, añadir o quitar GPUs incluso después de que la instancia ya esté en funcionamiento, lo cual es ideal para ajustar los recursos según las necesidades del proyecto. Por qué las otras opciones son incorrectas ❌ A) Una vez que se crea una instancia de Notebook, su hardware subyacente no se puede cambiar. Esto es falso. Como se mencionó anteriormente, los Notebooks se basan en Compute Engine, lo que permite modificar el hardware subyacente en cualquier momento. Puedes detener la instancia para cambiar la configuración de la máquina y luego reiniciarla. B) Las GPUs solo se pueden conectar a las instancias de Notebook durante su creación inicial y no se pueden agregar o eliminar posteriormente. Esto es falso. La flexibilidad de Compute Engine te permite añadir o eliminar GPUs de una instancia de VM en cualquier momento después de su creación, siempre y cuando detengas la instancia primero para realizar los cambios. D) Las instancias de Notebook son distintas de las instancias estándar de Compute Engine y no aparecen en la sección de Compute Engine en la Consola de Cloud. Esto es falso. Las instancias de Notebooks, aunque tienen una interfaz de usuario especializada para ciencia de datos, son, en esencia, instancias de Compute Engine. Por lo tanto, aparecen y son gestionables desde la sección de Compute Engine de la Consola de Google Cloud, al igual que cualquier otra máquina virtual.

Answer 1046

B **Explanation:** When working in a notebook, there will be a limited amount of memory. Therefore, it is not advisable to pull large, multi-terabyte or larger datasets from BigQuery directly into a Pandas DataFrame. Instead, it is recommended to use a sampling technique to pull a subset of the data [9].

Answer 1047

C Notebooks are ideal for data analysis and ML because they allow users to write and execute code in small chunks (cells), view outputs immediately, and document findings using markdown—all within the same environment.

Answer 1048

B The BigQuery magic function (%%bigquery) allows users to run queries directly within a Notebook cell and visualize or save the output.

Answer 1049

C Since notebooks run in environments with limited RAM, pulling large datasets (multi-terabyte or more) may crash the session. Instead, use sampling or query filtering.

Answer 1050

C Notebooks in Google Cloud are hosted on Compute Engine instances using JupyterLab, with pre-installed ML libraries and scalable hardware options.

Answer 1051

B y C ✅ Respuestas Correctas B. Los Notebooks alojados en la nube pueden ser accedidos simultáneamente por los miembros del equipo Esta es una característica clave de la colaboración moderna. Cuando un Notebook (como un Google Colab, un Databricks Notebook o un JupyterHub) está en la nube, varias personas pueden verlo y, en muchas plataformas, incluso editarlo al mismo tiempo. ¿Por qué es bueno? 🤝 Es como trabajar en un Google Doc. Todos ven la versión más reciente del código, los datos y los resultados. Esto evita la confusión de tener múltiples versiones del mismo archivo y facilita que el equipo discuta y trabaje sobre el mismo análisis en tiempo real. C. La integración con Git permite el control de versiones Git es el sistema de control de versiones más utilizado en el mundo del software. Integrar los Notebooks con Git es fundamental para una colaboración seria y organizada. ¿Por qué es bueno? ️ Permite: Rastrear cambios: Saber quién modificó qué y cuándo. Trabajar en paralelo: Cada miembro del equipo puede trabajar en una "rama" (una copia separada) sin afectar el trabajo de los demás. Fusionar cambios: Combinar el trabajo de todos de forma ordenada. Revertir errores: Si algo sale mal, es fácil volver a una versión anterior que funcionaba. Sin Git, coordinar el trabajo de varias personas en un proyecto de código sería un caos. ❌ Respuestas Incorrectas A. Los Notebooks requieren adjuntar archivos por email para colaborar Esta afirmación describe una forma muy anticuada e ineficiente de colaborar. De hecho, es un problema que las herramientas modernas (como las descritas en B y C) intentan solucionar. ¿Por qué es malo? 📧 Enviar archivos por email crea un caos de versiones (por ejemplo, analisis_final.ipynb, analisis_final_v2.ipynb, analisis_final_AHORA_SI.ipynb). Es muy difícil saber cuál es la última versión y casi imposible combinar los cambios hechos por distintas personas. D. Los archivos de Notebook están encriptados y no se pueden compartir Esta afirmación es la definición opuesta a la colaboración. El objetivo de colaborar es precisamente poder compartir el trabajo. ¿Por qué es malo? 🔒 La encriptación es una medida de seguridad, no de colaboración. Si un archivo no se puede compartir, es imposible que varias personas trabajen en él. Esta característica impediría directamente la colaboración.

Answer 1052

B Jupyter Notebooks enable users to write, execute, and share code in an iterative and collaborative way, integrating code, output, and commentary in one place

Answer 1053

A y C Cloud-hosted notebooks enable real-time collaboration and can be integrated with version control systems. They do not require the user's local machine to be on and can access Google Cloud services

Answer 1054

A The BigQuery magic function lets users execute SQL queries and view the results directly in the notebook, which is useful for validating queries and inspecting outputs

Answer 1055

B Since notebooks have limited memory, it is best to use sampling techniques to avoid loading very large datasets directly into memory

Answer 1056

A, B y C ✅ Por qué A, B y C son correctas Cuando creas una instancia de Jupyter Notebook en Google Cloud (por ejemplo, en Vertex AI Workbench), en realidad estás configurando una máquina virtual (VM) en la nube que ejecutará tu notebook. Por lo tanto, puedes personalizar el hardware de esa máquina virtual según tus necesidades. A) Machine type (Tipo de máquina): Se refiere a la combinación de CPU y memoria RAM que tendrá la máquina virtual. Puedes elegir tipos de máquina más potentes (con más núcleos de CPU y más RAM) si necesitas realizar cálculos intensivos, o tipos más modestos para ahorrar costes. Es una de las configuraciones de hardware más básicas y fundamentales. B) Number of GPUs (Número de GPUs): Las GPUs (Unidades de Procesamiento Gráfico) son aceleradores de hardware esenciales para tareas de machine learning y deep learning. Google Cloud te permite añadir una o varias GPUs a tu instancia y elegir el modelo específico (como NVIDIA Tesla T4, V100, etc.) para acelerar el entrenamiento de tus modelos. C) Amount of local disk storage (Cantidad de almacenamiento en disco local): Se refiere al tamaño del disco duro de la máquina virtual. Aquí se instalará el sistema operativo, tus librerías, tus scripts y los datos con los que trabajes. Puedes especificar el tamaño en Gigabytes (GB) o Terabytes (TB) que necesites al crear la instancia. En resumen, estas tres opciones son componentes de hardware del servidor en la nube que tú controlas y pagas. ❌ Por qué D es incorrecta D) Operating system of the user's laptop (Sistema operativo del portátil del usuario): Esta opción es incorrecta porque el hardware que se configura es el de la máquina virtual en Google Cloud, no el de tu ordenador personal. Tú accedes al Jupyter Notebook a través de un navegador web. La instancia en la nube no sabe ni le importa si tu portátil personal usa Windows, macOS o Linux. Tu portátil es simplemente un cliente que se conecta a un servidor remoto. La configuración del hardware del servidor es completamente independiente del cliente que lo utiliza.

Answer 1057

C As shown on slide 4, a typical notebook is described as being self-descriptive and containing "code, charts, and explanations." This combination of executable code, markdown for commentary, and the ability to render output (like plots or data frames) directly within the document is the key feature that makes notebooks so effective for iterative data analysis.

Answer 1058

B ✅ La Respuesta Correcta: Opción B La opción B) Puedes detener la instancia del notebook, cambiar su tipo de máquina a uno más potente y adjuntar una GPU, todo desde la Google Cloud Console es la correcta. Esta es una de las grandes ventajas de usar servicios gestionados en la nube como Vertex AI. El procedimiento está diseñado para ser flexible y no destructivo. ⚙️ El proceso es simple: Detener (Stop): Primero, debes detener la instancia. Esto es como apagar tu ordenador antes de cambiarle los componentes físicos. La máquina virtual se desvincula del hardware físico subyacente. Editar (Edit): Una vez detenida, se habilita la opción de editar la configuración de hardware en la consola de Google Cloud. Aquí puedes seleccionar un nuevo tipo de máquina (con más CPU y RAM) y añadir o cambiar las GPUs. Iniciar (Start): Al iniciarla de nuevo, Google Cloud provisiona la instancia con los nuevos recursos que has solicitado. Lo más importante es que tus datos, archivos y entorno en el disco de la instancia permanecen intactos. No necesitas migrar nada manualmente. ❌ Por Qué las Otras son Incorrectas A) Debes borrar la instancia actual y crear una nueva [...], migrando manualmente tus archivos. Esto es el método "a la fuerza". Aunque técnicamente funcionaría, es ineficiente, lento y propenso a errores. No es el procedimiento recomendado precisamente porque existe una forma mucho más sencilla y segura (la opción B). C) Solo puedes añadir una GPU, pero la CPU y la RAM [...] están fijas. Esto es falso. La plataforma te permite cambiar tanto los aceleradores (GPU) como el tipo de máquina (CPU y RAM) para adaptar la instancia a tus necesidades de cómputo. D) Debes exportar el notebook a un archivo local, y luego re-importarlo [...]. Esta es una mala práctica porque un proyecto de ciencia de datos es mucho más que el archivo .ipynb. Este método ignora otras dependencias, archivos de datos, librerías instaladas y configuraciones del entorno que residen en el disco de la instancia. Perderías todo ese contexto.

Answer 1059

B Slide 16 highlights the power of using the %%bigquery df magic to load query results directly into a Pandas DataFrame. However, it also includes a critical warning: "you wouldn't want to go to BigQuery and pull up a big, multi-terabyte or larger dataset." The correct approach is to leverage BigQuery's power to process the large dataset and return only a smaller, manageable subset (through aggregation, filtering, or sampling) to the notebook for further analysis and visualization.

Answer 1060

B ✅ B. Una instancia de VM de Compute Engine dedicada y gestionada (La respuesta correcta) Cuando creas una instancia de notebook en Vertex AI (ya sea "Gestionada por el usuario" o "Gestionada"), le estás pidiendo a Google Cloud que te proporcione un entorno de desarrollo. ¿Por qué Compute Engine? Para ejecutar JupyterLab, necesitas un sistema operativo, poder de cómputo (CPU), memoria (RAM) y, a menudo, hardware especializado como GPUs (por ejemplo, una NVIDIA A100). El servicio de Google Cloud que proporciona estos bloques de construcción fundamentales (máquinas virtuales) es Compute Engine (GCE). ¿Por qué "dedicada"? Al crear la instancia, seleccionas un tipo de máquina específico (ej. n1-standard-4 o a2-highgpu-1g). Esa máquina virtual se aprovisiona para ti y sus recursos (CPU, RAM, GPU) están dedicados a tu instancia de notebook. No los estás compartiendo con otros usuarios en un modelo multi-inquilino. ¿Por qué "gestionada"? Aunque es una VM de GCE, es "gestionada" por el servicio de Vertex AI. Esto significa que Vertex AI se encarga de instalar el sistema operativo, preconfigurar el entorno de JupyterLab, gestionar las bibliotecas de IA, y manejar el inicio y la detención de la VM a través de la interfaz de Vertex AI. ❌ Las respuestas incorrectas A. Una instancia serverless de Cloud Run Qué hace: Cloud Run es un servicio serverless (sin servidor) diseñado para ejecutar contenedores stateless (sin estado) que escalan con las solicitudes, incluso hasta cero. Por qué es incorrecta: Un notebook de JupyterLab es exactamente lo contrario: es stateful (mantiene en memoria tus variables, estado del kernel y archivos en disco) y de larga duración (necesitas que esté encendido mientras trabajas, no que se apague entre celdas). El modelo de Cloud Run no es el adecuado para este caso de uso. C. Un entorno flexible de App Engine compartido Qué hace: App Engine es una plataforma como servicio (PaaS) diseñada para alojar aplicaciones web y APIs, no entornos de desarrollo interactivos. Por qué es incorrecta: Similar a Cloud Run, App Engine está optimizado para servir aplicaciones, no para proporcionar una máquina dedicada con hardware específico (como GPUs) para una sesión de un solo usuario. Además, el modelo "compartido" contradice la naturaleza "dedicada" de la instancia de notebook que solicitas. D. Un Pod de Kubernetes dentro de un clúster de GKE gestionado por Google Qué hace: GKE (Google Kubernetes Engine) gestiona clústeres de Kubernetes, que ejecutan aplicaciones en contenedores (Pods). Por qué es incorrecta: Esta es la opción incorrecta más "creíble", porque Vertex AI sí utiliza GKE de forma interna para otros servicios (como Vertex AI Pipelines o Custom Training Jobs). Sin embargo, la instancia de notebook en sí (el entorno donde escribes el código) no es un Pod efímero; es una VM completa y persistente de Compute Engine. Esta VM proporciona la base estable y el hardware dedicado (la GPU está conectada a la VM, no a un Pod) que necesitas para tu sesión de JupyterLab.

Answer 1061

B As discussed on slides 5 and 6, a major benefit of cloud-hosted notebooks over running them locally is for collaboration. Because the notebook server runs on a persistent VM in the cloud, a collaborator can access and execute code on the same instance as long as it's running, regardless of the status of the original user's computer. This solves the "my machine goes to sleep" problem and eliminates the need to email static files back and forth.

Answer 1062

B Notebooks allow for real-time collaboration, similar to Google Docs, enabling multiple users to work on the same document simultaneously, which enhances productivity and teamwork.

Answer 1063

C BigQuery allows users to execute SQL queries directly from notebook cells using magic functions, and the results can be processed as Pandas DataFrames.

Answer 1064

C Notebooks are designed to be self-descriptive and executable, containing a mix of code, output visualizations (charts), and explanatory text, making them versatile for data analysis and presentation.

Answer 1065

B The syllabus includes labs where users instantiate a Jupyter notebook on Vertex AI, execute BigQuery queries, and process the output using Pandas, which is a crucial skill for data engineers.

Answer 1066

B When notebooks are hosted on Google Cloud, they are accessible via the cloud, meaning users can work on them from any device with internet access, even if their local machine is offline, enhancing flexibility and collaboration.

Answer 1067

A, B y C The sources clearly state that you can do machine learning on Google Cloud by leveraging pre-trained ML APIs (like Translation API, Vision API, etc.), using AutoML Cloud (which uses Google's models with your data), or by building custom models trained on your own data, often facilitated by services like Vertex AI. While Compute Engine is a Google Cloud service, the context of "ways to do ML" specifically points to the options that simplify or manage the ML process directly, rather than just raw infrastructure.

Answer 1068

A, B y D ✅ Características Correctas (A, B y D) Estas tres afirmaciones describen con precisión algunas de las ventajas clave de usar Vertex AI para desarrollar y desplegar modelos de machine learning personalizados. A) Es un servicio totalmente gestionado para el entrenamiento y el servicio de predicciones. Esta es la esencia de Vertex AI. "Totalmente gestionado" (fully managed) significa que Google se encarga de toda la infraestructura subyacente (servidores, redes, etc.). Tú te concentras en tu código y tus datos, y Vertex AI te proporciona las herramientas para entrenar el modelo y luego desplegarlo para que pueda hacer predicciones (ya sea en tiempo real o por lotes). B) Gestiona el procesamiento por lotes y la distribución del entrenamiento del modelo. Cuando entrenas modelos complejos con grandes volúmenes de datos, a menudo necesitas usar múltiples máquinas a la vez. Vertex AI facilita el entrenamiento distribuido. Tú defines la arquitectura de tu clúster de entrenamiento (por ejemplo, una máquina principal y varios "trabajadores"), y Vertex AI se encarga de distribuir los datos y la carga de trabajo entre ellas, optimizando el proceso. 🚀 D) Proporciona capacidades de ajuste de hiperparámetros. Encontrar la combinación perfecta de hiperparámetros (como la tasa de aprendizaje o el número de capas de una red neuronal) puede ser tedioso. Vertex AI tiene un servicio de ajuste de hiperparámetros automatizado. Tú defines los parámetros que quieres probar y un rango de valores, y Vertex AI ejecuta múltiples "experimentos" de entrenamiento para encontrar la combinación que maximiza el rendimiento de tu modelo. ❌ Característica Incorrecta (C) C) Requiere que los usuarios gestionen manualmente los clústeres de Kubernetes para ejecutar los pipelines. Esta afirmación es incorrecta y describe justo lo contrario a lo que hace Vertex AI. Uno de sus mayores beneficios es abstraer la gestión de la infraestructura. Aunque internamente Vertex AI Pipelines utiliza tecnología como Kubernetes, lo hace de forma transparente para el usuario. Es Google quien gestiona ese clúster por ti. El objetivo es que no tengas que ser un experto en Kubernetes para poder orquestar tus flujos de trabajo de MLOps.

Answer 1069

A ML Pipelines are designed to model workflows as a set of connected steps to manage and execute complex multi-step machine learning processes, ensuring they are reproducible, auditable, cost-effective, and scalable. They form the backbone of production ML systems. Option B describes TensorFlow Hub, while options C and D contradict the benefits of automation and comprehensive workflow management that pipelines offer

Answer 1070

C Kubeflow Pipelines is an open-source, Kubernetes-native solution and the industry standard for ML Pipelines. In contrast, Vertex AI Pipelines is fully managed and serverless, which means it handles resource management like Kubernetes clusters behind the scenes, allowing users to focus more on building their pipelines and paying only for consumed resources. Therefore, option B is incorrect as Vertex AI Pipelines removes the requirement for users to create dedicated Kubernetes clusters.

Answer 1071

B B) Es un repositorio de recursos preconstruidos de IA y ML, como incrustaciones de texto (text embeddings) y modelos de clasificación de imágenes. ¿Por qué es la correcta? ✅ Esta es la definición exacta de TensorFlow Hub. Es una plataforma donde la comunidad (incluyendo a Google) publica y comparte piezas reutilizables de modelos de machine learning. El objetivo principal es facilitar el aprendizaje por transferencia (transfer learning), permitiéndote tomar un componente pre-entrenado (como un modelo experto en entender imágenes) y adaptarlo a tu problema específico sin tener que empezar desde cero. Piensa en ello como una biblioteca de funciones pre-hechas para programar, pero en este caso, son modelos y componentes de modelos pre-entrenados. 🧠 A) Es un servicio utilizado principalmente para desplegar modelos de ML personalizados en producción. ¿Por qué es incorrecta? ❌ El despliegue de modelos en producción en Google Cloud se realiza con servicios como Vertex AI Prediction. TensorFlow Hub es para obtener los modelos, no para servirlos en producción. C) Es una herramienta para el ajuste de hiperparámetros de modelos personalizados. ¿Por qué es incorrecta? ❌ El ajuste de hiperparámetros (encontrar la mejor configuración para un modelo) se realiza con herramientas específicas como Vertex AI Vizier. TensorFlow Hub no realiza esta función. D) Es una alternativa a Vertex AI para construir modelos personalizados desde cero. ¿Por qué es incorrecta? ❌ TensorFlow Hub es un complemento de plataformas como Vertex AI, no una alternativa. De hecho, su propósito es justamente lo contrario a construir "desde cero": su filosofía es reutilizar el trabajo ya hecho por otros para acelerar el desarrollo.

Answer 1072

C Vertex AI Pipelines automate the end-to-end machine learning lifecycle, including training and deployment, in a scalable and cost-effective way. You don’t need to manage infrastructure manually.

Answer 1073

B y C Managed Vertex AI Pipelines include pre-built components for ML tasks and support enterprise-grade security like IAM and CMEK. Manual metadata management and cluster setup are not required.

Answer 1074

C TensorFlow Hub is a repository of reusable ML components, such as models for text, image, video, and more. It is designed to prevent “reinventing the wheel.”

Answer 1075

C After training a model, the next logical step is to evaluate it using a validation or test dataset. This helps assess its performance before deployment.

Answer 1076

A y B Kubeflow Pipelines are open source and Kubernetes-native, making them flexible for various environments. In contrast, Vertex Pipelines are fully managed and serverless, simplifying infrastructure concerns.

Answer 1077

B Vertex AI Pipelines offer a fully managed, serverless environment that automates resource management, making it scalable and easy to use for production ML workflows.

Answer 1078

A, C y D Managed pipelines provide easy-to-use SDKs, automatically track metadata and lineage, and are cost-effective since you only pay for the resources used. Manual resource allocation is not required.

Answer 1079

B TensorFlow Hub is a repository where you can find and share pre-built AI and ML components, such as models and embeddings, to avoid reinventing the wheel.

Answer 1080

B An ML pipeline is a sequence of connected steps, each taking inputs from previous steps and producing outputs for subsequent steps, covering the entire ML workflow.

Answer 1081

A, B y C ✅ Explicación de las Respuestas Correctas: A, B y C Estas tres opciones describen el ciclo de vida completo y estándar de un modelo de ML en un entorno real. Se pueden ver como las fases lógicas de un proyecto. A) Extracción y preparación de datos: Es el punto de partida y uno de los más importantes. No puedes construir un buen modelo con malos datos. 🚧 Extracción: Se obtienen los datos de diferentes fuentes (bases de datos, APIs, archivos, etc.). Preparación: Se limpian, transforman y organizan los datos para que el modelo pueda "entenderlos". Esto incluye manejar valores nulos, convertir texto a números, crear nuevas variables, etc. B) Entrenamiento y evaluación del modelo: Esta es la fase central del "machine learning". 🧠 Entrenamiento: Se utiliza el conjunto de datos ya preparado para "enseñar" al algoritmo a encontrar patrones y relaciones. Evaluación: Una vez entrenado, se pone a prueba el modelo con datos que nunca ha visto para medir su rendimiento y asegurarse de que es preciso y fiable antes de usarlo en el mundo real. Es como pasarle un examen final. C) Despliegue y monitoreo del modelo: Esta fase es lo que diferencia un proyecto experimental de un sistema en producción. 🚀 Despliegue (Deployment): El modelo aprobado se pone en un entorno real (como una app o una web) para que pueda empezar a hacer predicciones con datos nuevos y en tiempo real. Monitoreo (Monitoring): Se vigila constantemente el rendimiento del modelo para detectar si empieza a fallar o si su precisión disminuye con el tiempo (lo que se conoce como "model drift"). Si esto ocurre, el pipeline se puede re-ejecutar para reentrenar el modelo con datos nuevos. ❌ Por qué la opción D es incorrecta D) Manual data labeling only (Etiquetado manual de datos únicamente): Esta opción es incorrecta por dos motivos clave: La palabra "únicamente" (only): Un pipeline de ML es un proceso complejo con múltiples etapas (como acabamos de ver). Nunca consistiría solamente en etiquetar datos. El rol del etiquetado: El etiquetado manual de datos (asignar una categoría a una imagen, por ejemplo) es una tarea que a menudo se realiza antes de que el pipeline automatizado comience. Además, no todos los modelos de ML lo requieren (por ejemplo, el aprendizaje no supervisado). Por lo tanto, no se considera un componente central del pipeline en sí mismo, sino más bien una parte de la preparación de datos que puede o no ser necesaria.

Answer 1082

C The presentation (specifically pages 4 and 5) describes Vertex AI as a fully managed service for custom machine learning models. It allows data scientists to use frameworks like TensorFlow and XGBoost while abstracting away the underlying infrastructure, handling scaling, hyper-parameter tuning, and serverless predictions. AutoML (A) is for building models without writing code, and Pre-trained APIs (D) are for using Google's models, not custom ones. BigQuery ML (B) is for building models within BigQuery using SQL, which is not the primary requirement here.

Answer 1083

C Page 10 explicitly contrasts Kubeflow Pipelines with Vertex AI Pipelines. It highlights that with Vertex AI Pipelines, "the Kubernetes clusters and the Pods running on them are managed behind the scenes by Vertex AI." This serverless, fully managed nature is its key benefit over the self-managed approach, allowing teams to focus on building pipelines rather than managing infrastructure.

Answer 1084

A, C y D The "Key capabilities" slide (page 12) lists several benefits. A is correct, as "Metadata and lineage" is listed as a key capability. C is correct, under "Cost-effective," it states, "Only pay for the pipelines you run and the resources they use." D is correct, as "Python SDKs" is the first capability mentioned, described as "Data scientist friendly." B is incorrect because Vertex AI Pipelines are serverless and managed, which is the opposite of requiring a dedicated, manually configured cluster.

Answer 1085

B ¿Por qué la opción B es la correcta? ✅ B) TensorFlow Hub TensorFlow Hub es una biblioteca centralizada y un repositorio público mantenido por Google, diseñado específicamente para compartir y descubrir modelos de machine learning pre-entrenados y reutilizables. Propósito Específico: Su misión es exactamente la que se describe en la pregunta: proporcionar "componentes de ML reutilizables" para evitar "reinventar la rueda". Rico en Modelos de NLP: Contiene una vasta colección de modelos de última generación para procesamiento de lenguaje natural (NLP), incluyendo decenas de modelos de text embedding como BERT, Universal Sentence Encoder, NNLM, etc. Fácil Integración: Los modelos en TensorFlow Hub están diseñados para ser fácilmente integrados en pipelines de Keras y TensorFlow, lo cual es ideal para un ingeniero de datos que construye una solución de ML. Analogía: Piensa en TensorFlow Hub como una biblioteca pública o una "App Store" para modelos de ML. Es el primer lugar al que vas para buscar y encontrar un componente ya construido que resuelva una tarea estándar. ¿Por qué las otras opciones son incorrectas? ❌ A) Vertex AI Model Registry El Vertex AI Model Registry es un registro centralizado dentro de tu proyecto de Google Cloud para gestionar, versionar y gobernar tus propios modelos de ML. Es el lugar donde pones un modelo después de que lo has entrenado o después de que lo has encontrado en otro lugar (como TensorFlow Hub) y decidido usarlo en producción. No es un lugar para descubrir modelos públicos, sino para organizar los modelos privados de tu organización. Analogía: Si TensorFlow Hub es la biblioteca pública, el Model Registry es tu estantería personal donde organizas los libros que ya has decidido quedarte. C) Google Cloud Storage Google Cloud Storage (GCS) es un servicio de almacenamiento de objetos, similar a un disco duro en la nube. Puedes almacenar cualquier tipo de archivo, incluyendo archivos de modelos. Sin embargo, no es un "repositorio" en el sentido de una biblioteca con funciones de búsqueda y descubrimiento. Simplemente almacena los archivos. Para encontrar un modelo en GCS, necesitarías saber de antemano la URL exacta del archivo. Analogía: GCS es el almacén o el garaje donde guardas tus cosas en cajas. No te ayuda a descubrir qué hay dentro de las cajas de otros. D) Artifact Registry Artifact Registry es un servicio para almacenar y gestionar artefactos de software, como imágenes de Docker, paquetes de Maven (Java) o paquetes de npm (Node.js). Aunque técnicamente podrías almacenar un archivo de modelo como un artefacto genérico, su propósito principal es la gestión de dependencias en un ciclo de vida de desarrollo de software (CI/CD), no el descubrimiento de modelos de ML. Analogía: Artifact Registry es un almacén de piezas de construcción de software, no una biblioteca de soluciones de IA listas para usar.

Answer 1086

B Page 8 defines a pipeline as "a way of modeling a workflow as a set of connected steps." It further explains, "Each step takes as inputs the outputs of previous steps... and produces outputs that can be utilized by future components." The diagram on the same page visually represents this flow from one step to the next.

Answer 1087

B ML pipelines are essential for automating workflows such as data cleaning, feature creation, model training, and evaluation. This automation ensures that the processes are reproducible, cost-effective, and scalable, which is critical in production environments.

Answer 1088

C Vertex AI is a fully managed service on Google Cloud that provides tools for the entire ML lifecycle, from experimentation to production. It supports custom model development, data transformations, hyperparameter tuning, and autoscaling of prediction services.

Answer 1089

B Data Engineers are responsible for building and maintaining data pipelines, which include ML pipelines. They ensure the flexibility and efficiency of ML workflows by collaborating with Data Scientists and ML Engineers.

Answer 1090

B Kubeflow Pipelines are Kubernetes-native, open-source tools designed for building and deploying ML pipelines. They integrate seamlessly with Google Cloud services, such as Vertex AI, and offer pre-built components for common ML tasks.

Answer 1091

B TensorFlow Hub is a repository that offers pre-built AI and ML assets, including pre-trained models, embeddings, and processing models. It encourages reuse of these assets to avoid redundant development and speed up ML workflows.

Answer 1092

B BigQuery ML is a really powerful feature that allows anyone who knows only SQL to build ML models, which is a step further in democratizing Machine Learning and AI. A key takeaway is that you can train and evaluate machine learning models directly in BigQuery, meaning you don't have to worry about moving your data elsewhere to train your model if it already resides in BigQuery

Answer 1093

A, B y C Las respuestas correctas: A, B y C BigQuery ML (BQML) permite crear y ejecutar modelos de machine learning directamente en BigQuery usando consultas SQL. Para las tareas de clasificación (predecir una categoría, como "spam/no spam" o "gato/perro/pájaro"), BQML soporta explícitamente varios tipos de modelos. ✅ A. Regresión Logística (Logistic Regression) Es uno de los modelos más fundamentales para la clasificación. Se utiliza para predecir una categoría binaria (dos opciones) o múltiple. BigQuery ML lo soporta de forma nativa. Al crear el modelo, se especifica MODEL_TYPE='LOGISTIC_REG'. ✅ B. Clasificador con Red Neuronal Profunda (Deep Neural Network Classifier) Para problemas de clasificación más complejos, BQML permite entrenar redes neuronales profundas. Este tipo de modelo puede capturar patrones y relaciones no lineales en los datos. Se utiliza con la opción MODEL_TYPE='DNN_CLASSIFIER'. ✅ C. Clasificador de Árbol Potenciado (Boosted Tree Classifier - XGBoost) Este es un modelo muy potente y popular basado en ensambles de árboles de decisión, que utiliza la famosa librería XGBoost. Es excelente para datos tabulares y a menudo ofrece un alto rendimiento. BQML lo integra con la opción MODEL_TYPE='BOOSTED_TREE_CLASSIFIER'. La respuesta incorrecta: D ❌ D. K-Means Clustering Aquí está la clave: la pregunta se refiere a tareas de clasificación. La clasificación es un tipo de aprendizaje supervisado. Esto significa que entrenas el modelo con datos que ya tienen etiquetas (por ejemplo, un dataset de correos electrónicos donde cada uno está etiquetado como "spam" o "no spam"). El objetivo es predecir la etiqueta para datos nuevos. El clustering (como K-Means) es un tipo de aprendizaje no supervisado. Aquí, los datos no tienen etiquetas. El objetivo del algoritmo es encontrar agrupaciones o "clusters" naturales en los datos basándose en su similitud. Aunque BigQuery ML sí soporta el algoritmo K-Means (con MODEL_TYPE='KMEANS'), se utiliza para tareas de clustering, no de clasificación. Por lo tanto, no es una respuesta válida para la pregunta formulada.

Answer 1094

B To work with BigQuery ML, there are only a few steps from beginning to inference. First, you must write a query on data stored in BigQuery to extract your training data. Then, you can create a model. After the model is trained, you can evaluate the model. Finally, you can make predictions using your model on data extracted from BigQuery

Answer 1095

C To get the metrics for your trained model, you simply call ML.EVALUATE on your trained model. This function provides evaluation statistics like precision, recall, accuracy, f1_score, log_loss, and roc_auc, often on a held-out set of the training data. Other options serve different purposes: ML.TRAINING_INFO shows training progress, ML.PREDICT is for generating predictions, and ML.WEIGHTS is for inspecting model weights.

Answer 1096

A Well, unlike the ML APIs, you are able to create your own custom models with BigQuery ML. BigQuery ML is a way to build custom models, whereas services like Translation API, Vision API, and others are used to call pre-trained models. Furthermore, BigQuery ML allows building ML models using SQL syntax, democratizing ML and AI for those who know SQL.

Answer 1097

C Logistic regression models in BigQuery ML use model_type='logistic_reg', and the correct full syntax includes CREATE OR REPLACE MODEL.

Answer 1098

C ML.EVALUATE() returns performance metrics such as precision, recall, accuracy, and log loss for classification models.

Answer 1099

A, B, C y D A) dnn_regressor (Red Neuronal Profunda para Regresión) ¿Por qué es correcta? BigQuery ML permite crear modelos de redes neuronales profundas (DNN) para tareas de regresión, es decir, para predecir un valor numérico continuo. Por ejemplo, se podría usar para predecir el precio de una vivienda o la cantidad de ventas del próximo mes. Modelo: DNN_REGRESSOR B) kmeans ¿Por qué es correcta? Este es uno de los modelos de clustering (o agrupamiento) más conocidos, y está totalmente soportado. El algoritmo k-means se utiliza para segmentar datos en grupos distintos basados en sus similitudes. Un caso de uso típico sería la segmentación de clientes en diferentes perfiles de compra. Modelo: KMEANS C) random_forest_classifier (Bosque Aleatorio para Clasificación) ¿Por qué es correcta? BigQuery ML soporta modelos de tipo "bosque aleatorio" (Random Forest) para problemas de clasificación. Este tipo de modelo se usa para predecir una categoría o etiqueta. Por ejemplo, se podría utilizar para determinar si un correo electrónico es spam o no, o para clasificar a un cliente como "probable que abandone" o "fiel". Modelo: RANDOM_FOREST_CLASSIFIER D) matrix_factorization (Factorización de Matrices) ¿Por qué es correcta? La factorización de matrices es un modelo muy popular para crear sistemas de recomendación. Por ejemplo, plataformas como Netflix o Amazon la usan para sugerir películas o productos basándose en las valoraciones anteriores de los usuarios. BigQuery ML lo soporta nativamente para este fin. Modelo: MATRIX_FACTORIZATION

Answer 1100

A ML.PREDICT() is used to generate predictions for new data using a trained model in BigQuery ML.

Answer 1101

B BigQuery ML enables users to build and train machine learning models directly in BigQuery using SQL syntax, without needing to export data or use Python

Answer 1102

A, B, C y D Modelos Soportados por BigQuery ML BigQuery ML integra la capacidad de crear y ejecutar modelos de machine learning directamente en BigQuery usando sintaxis de SQL. Esto democratiza el acceso al ML, permitiendo a los analistas de datos entrenar modelos sin necesidad de mover datos o usar frameworks complejos. A) Logistic Regression (Regresión Logística) - Correcto ✅ ¿Qué es? Es un modelo de clasificación. Se utiliza para predecir un resultado binario (dos opciones), como por ejemplo: ¿un cliente abandonará la empresa (churn) o no? ¿Un correo electrónico es spam o no? ¿Una transacción es fraudulenta o no? Soporte en BQML: Sí, la regresión logística (tanto binaria como multiclase) es uno de los modelos fundamentales y más utilizados en BQML. Se crea con MODEL_TYPE='LOGISTIC_REG'. B) K-Means Clustering (Agrupamiento K-Means) - Correcto ✅ ¿Qué es? Es un modelo de clustering (agrupamiento), que es un tipo de aprendizaje no supervisado. Su objetivo es agrupar datos similares en "clústeres" o segmentos sin que se le diga de antemano cuáles son las categorías. Por ejemplo, se puede usar para segmentar clientes en diferentes grupos según su comportamiento de compra. Soporte en BQML: Sí, K-Means es el principal algoritmo de clustering soportado por BQML. Se crea con MODEL_TYPE='KMEANS'. C) Matrix Factorization (Factorización de Matrices) - Correcto ✅ ¿Qué es? Es una técnica comúnmente utilizada para crear sistemas de recomendación. Funciona descomponiendo una matriz de interacciones usuario-producto para descubrir características latentes y así poder predecir qué productos le podrían gustar a un usuario. Es la tecnología detrás de recomendaciones como "los usuarios que compraron X también compraron Y". Soporte en BQML: Sí, la factorización de matrices está disponible en BQML específicamente para casos de uso de recomendación. Se crea con MODEL_TYPE='MATRIX_FACTORIZATION'. D) Random Forest (Bosque Aleatorio) - Correcto ✅ ¿Qué es? Es un modelo versátil que se puede usar tanto para clasificación como para regresión. Es un método de "ensemble" (conjunto) que construye múltiples árboles de decisión y combina sus resultados para mejorar la precisión y evitar el sobreajuste. Por ejemplo, se puede usar para predecir el precio de una vivienda (regresión) o clasificar el riesgo crediticio de un cliente (clasificación). Soporte en BQML: Sí, Random Forest es uno de los varios modelos basados en árboles de decisión soportados en BQML. Se crea con MODEL_TYPE='RANDOM_FOREST_CLASSIFIER' o MODEL_TYPE='RANDOM_FOREST_REGRESSOR'.

Answer 1103

C The ML.EVALUATE function is used to assess the performance of a trained model by providing metrics such as accuracy, precision, recall, and more

Answer 1104

B ✅ La Respuesta Correcta: matrix_factorization (B) Para construir un motor de recomendación en BigQuery ML, el tipo de modelo que debes usar es matrix_factorization (Factorización de Matrices). Este modelo está diseñado específicamente para sistemas de recomendación, especialmente para una técnica llamada filtrado colaborativo. La idea es la siguiente: Se parte de una matriz gigante con los datos de interacción entre usuarios y productos (por ejemplo, qué películas ha valorado cada usuario). El algoritmo "factoriza" o descompone esta matriz en dos matrices más pequeñas: una que representa las características latentes (ocultas) de los usuarios (sus gustos) y otra que representa las características latentes de los productos. Al multiplicar estas dos matrices, el modelo puede "predecir" las interacciones que faltan en la matriz original, es decir, puede recomendar productos a un usuario que probablemente le gustarán. 🎯 En resumen, es la herramienta perfecta y estándar dentro de BigQuery ML para crear este tipo de sistemas. ❌ Por Qué las Otras Opciones son Incorrectas Los otros tipos de modelos sirven para tareas de machine learning completamente diferentes: A) dnn_classifier: Es un clasificador basado en redes neuronales. Se usa para problemas de clasificación, es decir, para predecir una categoría (ej: "¿Este correo es spam o no?"). C) linear_reg: Es un modelo de regresión lineal. Se usa para problemas de regresión, es decir, para predecir un valor numérico continuo (ej: "¿Cuál será el precio de esta casa?"). D) kmeans: Es un algoritmo de clustering no supervisado. Se usa para agrupar datos similares en segmentos (ej: "Agrupar a los clientes en 5 tipos diferentes según su comportamiento de compra"). Aunque podrías usar los resultados de k-means como una característica para un motor de recomendación, el algoritmo en sí no genera las recomendaciones.

Answer 1105

A y B A) Escribir una consulta SQL para extraer los datos de entrenamiento (Respuesta Correcta ✅) Por qué es correcta: La sentencia CREATE MODEL necesita saber con qué datos debe entrenarse. Esta información se la proporcionas a través de una consulta SELECT estándar de SQL. Esta consulta define exactamente qué filas y columnas de tu tabla se usarán para que el modelo aprenda. En resumen, la estructura siempre es: CREATE MODEL ... AS SELECT columna1, columna2 FROM ... Sin la consulta SELECT, el comando CREATE MODEL no tendría datos para trabajar. Por lo tanto, es un paso obligatorio. B) Usar la sentencia CREATE MODEL con las opciones apropiadas (Respuesta Correcta ✅) Por qué es correcta: Este es el comando central de todo el proceso en BigQuery ML. La sentencia CREATE OR REPLACE MODEL es la que le dice a BigQuery: "Oye, quiero que crees y entrenes un modelo de machine learning". Dentro de esta sentencia, usas la cláusula OPTIONS para especificar detalles cruciales como: model_type: Qué tipo de modelo quieres (ej. 'LOGISTIC_REGRESSION', 'BOOSTED_TREE_CLASSIFIER', 'KMEANS'). input_label_cols: Cuál es la columna que quieres predecir (el objetivo). Sin este comando, simplemente no hay creación de modelo. Es el paso fundamental e indispensable. C) Evaluar el modelo usando ML.EVALUATE (Respuesta Incorrecta ❌) Por qué es incorrecta: Aunque evaluar un modelo es una práctica recomendada y crucial en cualquier proyecto serio de machine learning, no es un paso técnicamente obligatorio para poder usarlo. La función ML.EVALUATE te da métricas (como la precisión o el F1-score) para saber qué tan bueno es tu modelo. Sin embargo, tú puedes entrenar un modelo con CREATE MODEL y empezar a hacer predicciones con ML.PREDICT inmediatamente, sin haberlo evaluado antes. Por lo tanto, no es un paso requerido en el flujo técnico, sino un paso de control de calidad. D) Desplegar el modelo fuera de BigQuery para las predicciones (Respuesta Incorrecta ❌) Por qué es incorrecta: Una de las mayores ventajas de BigQuery ML es precisamente que no necesitas sacar el modelo de BigQuery para usarlo. Puedes hacer predicciones directamente dentro de tu almacén de datos usando la función ML.PREDICT en una consulta SQL. Si bien es posible exportar un modelo de BigQuery ML para usarlo en otras plataformas (como Vertex AI), este es un paso opcional y avanzado. El flujo de trabajo estándar y requerido implica entrenar y usar el modelo dentro de BigQuery. Resumen Clave 🧠 Para entrenar y usar un modelo en BigQuery ML, los dos pasos mínimos y obligatorios son: Definir tus datos de entrenamiento con una consulta SELECT (Opción A). Ejecutar el comando de entrenamiento CREATE MODEL sobre esos datos, especificando el tipo de modelo y otras opciones (Opción B).

Answer 1106

B, C y D The standard end-to-end workflow in BigQuery ML, as shown on slide 6, involves three main steps performed via SQL functions: CREATE MODEL: This statement is used to train and create the model object within a BigQuery dataset. ML.EVALUATE: After training, this function is used to assess the model's performance metrics against a held-out portion of the data. ML.PREDICT: Once the model is evaluated and deemed satisfactory, this function is used to generate predictions on new, unseen data. ML.TRAIN and ML.DEPLOY are not standard BigQuery ML functions for this workflow.

Answer 1107

D As shown on slide 22, matrix_factorization is the model type specifically designed for building recommendation systems (a form of collaborative filtering) in BigQuery ML. It requires specifying user, item, and rating columns. The other options are for different tasks: kmeans for unsupervised clustering, boosted_tree_classifier for classification, and linear_reg for regression.

Answer 1108

A Slide 21 explicitly demonstrates this capability. BigQuery ML can import existing TensorFlow models. The process involves using the CREATE OR REPLACE MODEL statement, specifying model_type='tensorflow', and providing the GCS path to the saved model in the OPTIONS clause. This allows you to call ML.PREDICT directly on the imported model within BigQuery.

Answer 1109

C As shown on slides 9 and 10, all feature engineering and data transformation logic is defined directly in the standard SQL SELECT query that provides the training data. This query follows the AS clause of the CREATE MODEL statement. BigQuery ML executes this query to get the training data, allowing any valid SQL function to be used for feature preparation on the fly. There is no ML.PREPARE_DATA function.

Answer 1110

B Por qué la opción B es la correcta ✅ La opción B: "Automáticamente divide los datos proporcionados en la consulta de entrada en conjuntos de entrenamiento y de holdout (evaluación), y reporta métricas sobre el conjunto de holdout" es la correcta porque describe el comportamiento predeterminado y fundamental de la sentencia CREATE MODEL en BigQuery ML para modelos supervisados. El objetivo de un buen modelo de machine learning no es solo memorizar los datos de entrenamiento, sino generalizar para hacer predicciones precisas sobre datos nuevos que no ha visto antes. Para medir esta capacidad, es esencial separar los datos: Conjunto de Entrenamiento (Training Set): La mayor parte de los datos, usada para que el modelo "aprenda" los patrones. Conjunto de Evaluación (Holdout/Evaluation Set): Una porción más pequeña de los datos que se mantiene "oculta" durante el entrenamiento. Se usa para evaluar el rendimiento del modelo en datos que no ha visto, dando una medida realista de su eficacia. BigQuery ML está diseñado para seguir esta buena práctica de forma automática. Cuando ejecutas CREATE MODEL, BigQuery ML realiza esta división por ti sin que tengas que especificarlo. Luego, las métricas de rendimiento que ves en la pestaña "Evaluación" del modelo (como accuracy, precision, recall, etc.) se calculan sobre este conjunto de evaluación, no sobre los datos con los que entrenó. Esto te da una estimación honesta de cómo funcionará tu modelo en el mundo real. Por qué las otras opciones son incorrectas ❌ Opción A: Entrena con el 100% de los datos y requiere que llames a ML.EVALUATE en un conjunto de prueba separado. Esta opción es incorrecta porque, si bien puedes usar la función ML.EVALUATE en un conjunto de datos de prueba completamente separado, no es un requisito. La propia sentencia CREATE MODEL ya genera métricas de evaluación gracias a la división automática que realiza. Entrenar por defecto con el 100% de los datos no permitiría una evaluación inmediata y fiable. Opción C: Evalúa el modelo con los mismos datos con los que fue entrenado, proporcionando métricas de rendimiento potencialmente demasiado optimistas. Esta opción describe una mala práctica fundamental en machine learning. Si evalúas un modelo con los mismos datos que usaste para entrenarlo, las métricas serán casi siempre excelentes, pero engañosas. Es como darle a un estudiante las respuestas del examen antes de la prueba; sacará una nota perfecta, pero no sabrás si realmente aprendió algo. BigQuery ML está diseñado precisamente para evitar este error de forma automática. Opción D: Requiere que especifiques explícitamente un porcentaje de división (por ejemplo, TRAIN_TEST_SPLIT = 0.8) en la cláusula OPTIONS. Esta opción es incorrecta por la palabra clave "requiere". Si bien BigQuery ML te permite controlar la división de datos a través de opciones como DATA_SPLIT_METHOD, DATA_SPLIT_EVAL_FRACTION o DATA_SPLIT_COL, no es obligatorio. Si no incluyes ninguna de estas opciones, BigQuery ML simplemente aplica su división automática predeterminada. Por lo tanto, es una funcionalidad opcional para tener más control, no un requisito. En resumen, BigQuery ML automatiza el proceso de división de datos para garantizar que obtengas una evaluación de modelo robusta y fiable desde el primer momento, lo que hace que la opción B sea la descripción perfecta de su comportamiento estándar.

Answer 1111

B B) Regresión con Árbol de Decisión (Decision Tree Regression) ¿Por qué es la respuesta correcta? ✅ Aunque pueda parecer sorprendente, BigQuery ML no tiene un tipo de modelo para crear un único y simple árbol de decisión. Sin embargo, sí utiliza los árboles de decisión como componentes básicos en sus modelos de conjunto (ensemble models), que son mucho más potentes y precisos: Boosted Tree: Combina muchos árboles de decisión débiles para crear un modelo fuerte. Random Forest: Construye múltiples árboles de decisión y promedia sus resultados. Por lo tanto, aunque BQML usa la tecnología de los árboles de decisión, no puedes crear uno de forma individual con un MODEL_TYPE='DECISION_TREE_REGRESSOR'. Modelos que SÍ están soportados Las otras opciones son incorrectas porque sí son tipos de modelos válidos en BigQuery ML: A) Regresión Lineal (Linear Regression) ❌ Este es uno de los modelos más básicos y está totalmente soportado con MODEL_TYPE='LINEAR_REG'. Se usa para predecir un valor numérico basándose en una relación lineal. C) Clustering K-Means ❌ Este es el principal algoritmo de clustering (agrupamiento) no supervisado en BigQuery ML, soportado con MODEL_TYPE='KMEANS'. Se usa para segmentar datos en grupos. D) Factorización de Matrices (Matrix Factorization) ❌ Este modelo es fundamental para construir sistemas de recomendación y está soportado con MODEL_TYPE='MATRIX_FACTORIZATION'.

Answer 1112

C The ML.EVALUATE function provides metrics like precision and recall to evaluate model performance, which is essential for data engineers.

Answer 1113

B The input_label_cols option specifies the target column for prediction, crucial for supervised learning models.

Answer 1114

C C) Matrix Factorization (Factorización de Matrices) - ✅ Correcta Este es el modelo de BigQuery ML diseñado específicamente para crear sistemas de recomendación, especialmente los basados en filtrado colaborativo (collaborative filtering). ¿Cómo funciona? Imagina una tabla gigante donde las filas son usuarios y las columnas son productos (o películas, canciones, etc.). Las celdas contienen la calificación que un usuario le ha dado a un producto. La mayoría de esta tabla estará vacía, porque un usuario solo ha interactu-ado con unos pocos productos. La factorización de matrices "descompone" esta tabla en dos más pequeñas: una que representa las preferencias latentes de cada usuario y otra que representa las características latentes de cada producto. Al multiplicar estas dos tablas más pequeñas, el modelo puede "rellenar los huecos" de la tabla original, prediciendo la calificación que un usuario le daría a un producto que nunca ha visto. Estas predicciones se usan para generar recomendaciones. En resumen, es la técnica por excelencia para responder a la pregunta: "A los usuarios que les gustó X, también les gustó Y, por lo tanto, a ti también te podría gustar Y". Por qué las otras opciones son incorrectas A) Linear Regression (Regresión Lineal): ❌ Es un modelo para predecir un valor numérico continuo. Por ejemplo, predecir el precio de una casa basándose en su tamaño y ubicación, o estimar las ventas del próximo mes. No sirve para recomendar productos. B) DNN Classifier (Clasificador de Red Neuronal Profunda): ❌ Se usa para clasificar elementos en categorías predefinidas. Por ejemplo, determinar si un correo electrónico es spam o no es spam, o predecir si un cliente abandonará el servicio (churn o no churn). Aunque podría usarse en un sistema de recomendación complejo, no es su propósito principal. D) K-Means Clustering (Agrupamiento K-Means): ❌ Es un modelo de aprendizaje no supervisado que sirve para agrupar datos similares en clústeres o segmentos. Por ejemplo, podrías usar K-Means para agrupar a tus clientes en segmentos como "grandes compradores", "compradores ocasionales" y "nuevos clientes". Podrías recomendar el producto más popular de un clúster a sus miembros, pero el modelo en sí no genera recomendaciones personalizadas; solo agrupa.

Answer 1115

B The correct syntax uses CREATE OR REPLACE MODEL with OPTIONS to specify the model type and includes the training data query.

Answer 1116

C AutoML is a service on Google Cloud that enables the building of powerful machine learning models with minimal effort and machine learning expertise. It is ideal for quickly getting a machine learning model off the ground. Unlike building custom models which require machine learning expertise and coding experience, AutoML trains a model specific to your data without requiring any code.

Answer 1117

B AutoML Natural Language specializes in training models for text data, such as classifying newspaper articles or customer support emails. AutoML Vision is designed for image data, useful for identifying objects in user-uploaded images. AutoML Tables is for tabular or structured data, which is suitable for predicting sales based on historical structured data

Answer 1118

A During the training phase, after the dataset is prepared and validated, it's used to train the model. Part of this process involves using the VALIDATION group data to verify how well the model classifies and predicts. This helps in correcting the algorithm during supervised learning to minimize total error across multiple epochs. The TEST group, on the other hand, is used for final evaluation and bias removal.

Answer 1119

B The first column in the CSV file is optional; it assigns data in each row into one of the three groups: TRAIN, VALIDATION, or TEST. If this column is omitted, the rows will automatically be assigned with 80% going to TRAIN, and 10% each to VALIDATION and TEST. The CSV file must be UTF-8 encoded, located in the same Cloud Storage bucket as the source files, and should not contain duplicate lines, blank lines, or Unicode characters

Answer 1120

A Online prediction is synchronous, meaning it quickly returns a prediction but accepts only one prediction request per API call. This is useful if parts of your system are dependent on a quick prediction turnaround, such such as real-time mobile application features. Batch prediction, conversely, is asynchronous and suited for making many prediction requests at once, typically returning results in a CSV file or BigQuery table

Answer 1121

C AutoML enables users to train models without coding or ML knowledge, offering a fast and easy way to build models customized to your data.

Answer 1122

A, B y D ✅ Opciones Correctas A. AutoML Vision – Image data Esta afirmación es correcta. AutoML Vision es el producto de Google Cloud diseñado específicamente para trabajar con datos de imagen. Permite a los usuarios sin gran experiencia en aprendizaje automático entrenar modelos personalizados para tareas como: Clasificación de imágenes: Etiquetar una imagen completa (ej. "gato", "perro"). Detección de objetos: Identificar y localizar objetos dentro de una imagen (ej. dibujar un cuadro alrededor de cada coche en una foto). B. AutoML Tables – Structured/tabular data Esta afirmación también es correcta. AutoML Tables se especializa en datos estructurados o tabulares, que son los datos que normalmente encuentras en una hoja de cálculo o una base de datos con filas y columnas bien definidas. Su principal función es predecir un valor en una columna a partir de la información de las otras columnas, lo que es útil para problemas de negocio como la predicción de la demanda o la detección de fraudes. Getty Images D. AutoML Natural Language – Text data Esta afirmación es correcta. AutoML Natural Language está diseñado para procesar y entender datos de texto no estructurado. Permite crear modelos para: Clasificación de texto: Asignar etiquetas a un bloque de texto (ej. "noticia deportiva", "reseña negativa"). Extracción de entidades: Identificar información clave como nombres de personas, lugares u organizaciones. Análisis de sentimiento: Determinar si un texto expresa una opinión positiva, negativa o neutra. ❌ Opción Incorrecta C. AutoML Natural Language – Audio data Esta afirmación es incorrecta. Aunque el habla es una forma de "lenguaje natural", la herramienta AutoML Natural Language trabaja exclusivamente con datos en formato de texto. El procesamiento de datos de audio, como transcribir voz a texto, es manejado por otros servicios de Google Cloud, principalmente la API de Speech-to-Text. Por lo tanto, asociar AutoML Natural Language con datos de audio es un error.

Answer 1123

C The TEST group is used to evaluate the model on unseen data to remove bias from the evaluation and assess generalization.

Answer 1124

A, C y D Estas opciones describen prácticas estándar recomendadas para entrenar cualquier modelo de visión de alta calidad, incluyendo los de AutoML Vision. ✅ A. Incrementar la variedad en las imágenes de entrenamiento (Increase variety in training images) Esta es una de las prácticas más importantes. Un modelo robusto es aquel que puede generalizar a partir de los datos de entrenamiento para hacer predicciones precisas sobre datos nuevos y nunca antes vistos. Para lograrlo, el dataset de entrenamiento debe reflejar la realidad tanto como sea posible. Esto implica incluir imágenes del mismo objeto con: Diferentes ángulos y orientaciones. Distintas condiciones de iluminación (luz de día, noche, sombras). Fondos variados. Oclusiones parciales (objetos que están parcialmente tapados). Una alta variedad ayuda al modelo a aprender las características esenciales del objeto en lugar de memorizar detalles irrelevantes como el fondo o la iluminación. ✅ C. Eliminar las etiquetas de uso poco frecuente (Remove infrequently used labels) Si una etiqueta (o clase) tiene muy pocas imágenes de ejemplo (por ejemplo, menos de 50), el modelo no tendrá suficiente información para aprender a identificarla correctamente. Estas clases con pocos datos pueden confundir al modelo e incluso perjudicar el rendimiento de las otras clases mejor representadas. La recomendación es conseguir más imágenes para esa etiqueta o, si no es posible, eliminarla del conjunto de entrenamiento. ✅ D. Asegurar una distribución equilibrada de etiquetas (Ensure balanced label distribution) Un dataset desequilibrado (o desbalanceado) es aquel en el que algunas etiquetas tienen muchísimas más imágenes que otras. Por ejemplo, 1000 imágenes de "perros" y solo 50 de "gatos". Esto provoca que el modelo se vuelva sesgado (biased), ya que tenderá a predecir la clase mayoritaria ("perro") con más frecuencia porque así acierta más veces durante el entrenamiento. Para un rendimiento justo y preciso en todas las clases, es crucial que cada etiqueta tenga un número de ejemplos similar. La respuesta incorrecta: B ❌ B. Usar puntuaciones de precisión perfectas como indicio de un rendimiento excelente (Use perfect precision scores as an indication of excellent performance) Esta es una trampa muy común. Una puntuación perfecta (1.0 o 100%) en métricas como la precisión casi nunca es señal de un modelo excelente. Por el contrario, es un fuerte indicio de un problema grave llamado sobreajuste (overfitting). El sobreajuste ocurre cuando el modelo, en lugar de aprender los patrones generales de los datos, se "memoriza" los ejemplos de entrenamiento. Este modelo será perfecto para predecir los datos que ya ha visto, pero fallará estrepitosamente cuando se le presenten datos nuevos del mundo real. Por lo tanto, una puntuación perfecta debe ser investigada, no celebrada.

Answer 1125

C BigQuery supports complex data types like arrays and structs, making it a convenient source for structured input data.

Answer 1126

B ertex AI AutoML enables users to build powerful custom machine learning models without requiring coding or deep ML expertise

Answer 1127

A, B y C The AutoML workflow is divided into three main phases: Train (preparing and training the model), Deploy (making the model available), and Serve (using the model for predictions). "Archive" is not a standard phase

Answer 1128

C The recommended strategy is to first try pre-built AI services. If they do not meet your needs, then use AutoML for custom models, and only build a custom model from scratch if necessary

Answer 1129

C AutoML Tables is designed specifically for structured or tabular data, such as spreadsheets or database tables

Answer 1130

A, B y D Improving model quality involves removing labels with very few examples, ensuring training images are similar to those you want to classify, and increasing the variety of images to avoid overfitting. Using too many infrequent labels can harm model performance

Answer 1131

C The key factors are the team's skillset (SQL proficiency), the data location (BigQuery), and the need for speed ("within a few hours"). As highlighted on page 39, BigQuery ML is designed for data analysts who can use SQL to create models directly within BigQuery, often in about an hour. While AutoML Tables (B) also works with structured data, it's generally a longer process ("about a day") and is geared more towards developers. A custom model (A) requires ML engineering expertise, and the Natural Language API (D) is for unstructured text, not a structured dataset.

Answer 1132

C Estructura correcta del archivo CSV Antes de ver las opciones, recordemos la estructura que Google Cloud requiere para un archivo CSV de entrenamiento en AutoML Vision: Cada fila debe contener, como mínimo, dos columnas, y opcionalmente una primera columna para el set de datos: [SET], RUTA_GCS_A_LA_IMAGEN, ETIQUETA SET (Opcional): Indica a qué conjunto de datos pertenece la imagen. Los valores válidos son TRAIN, VALIDATION o TEST. Si se omite, AutoML divide los datos automáticamente. RUTA_GCS_A_LA_IMAGEN (Obligatorio): Debe ser la ruta completa (URI) a la imagen en Cloud Storage. Siempre debe empezar con gs://. ETIQUETA (Obligatorio para entrenamiento): El nombre de la clase que quieres que el modelo aprenda para esa imagen. Por qué la opción C es la correcta C. VALIDATION,gs://my-project-images/bird01.jpg,bird ✅ Esta fila es perfecta porque cumple con todos los requisitos: Set: VALIDATION es un valor válido. Ruta GCS: gs://my-project-images/bird01.jpg es la URI completa, y lo más importante, utiliza el bucket correcto (my-project-images) que se especifica en la pregunta. Etiqueta: bird es la etiqueta que se le asigna a la imagen. Por qué las otras opciones son incorrectas A. TRAIN,gs://another-bucket/images/cat01.jpg,cat ❌ El error aquí es sutil pero clave: la ruta de la imagen apunta a un bucket incorrecto (gs://another-bucket/...). La pregunta establece claramente que las imágenes están en gs://my-project-images/. Aunque la estructura general es correcta, los datos no son consistentes con el enunciado. B. TEST,images/dog01.jpg,dog ❌ El error es la ruta de la imagen: images/dog01.jpg. Es una ruta relativa, no una URI completa. AutoML necesita la ruta absoluta que siempre debe comenzar con el prefijo gs:// seguido del nombre del bucket. D. TRAIN,gs://my-project-images/fish01.jpg ❌ El error es muy simple: falta la etiqueta. Para entrenar un modelo de clasificación, cada imagen en el set de entrenamiento debe tener al menos una etiqueta que le indique al modelo qué es lo que contiene. Sin una etiqueta, AutoML no sabría qué aprender de esa imagen.

Answer 1133

B As shown on pages 13 and 15, the TRAIN set is used for learning (C), and the VALIDATION set is used to verify and tune the model during the training process (A). The TEST set is held back until after the model is fully trained. Its purpose is to evaluate the final model's effectiveness on completely new data, providing an unbiased measure of how well it will generalize to real-world instances.

Answer 1134

B y C ✅ Respuestas Correctas B. Usar AutoML Tables para este problema de datos estructurados. ¿Por qué es correcta? El problema describe un dataset en un archivo CSV con 1.5 millones de filas para predecir precios. Esto es un ejemplo clásico de datos estructurados (organizados en filas y columnas) y la tarea es de regresión (predecir un valor numérico, el precio). AutoML Tables es la herramienta de Google Cloud diseñada específicamente para este tipo de problemas. Analiza tus datos tabulares, prueba automáticamente diferentes modelos de machine learning y configuraciones (lo que se conoce como ajuste de hiperparámetros) para encontrar el que ofrece el mejor rendimiento. Esto cumple perfectamente con el objetivo de "lograr el mejor rendimiento posible" de una forma automatizada. C. Al configurar el trabajo de entrenamiento, establecer un presupuesto de horas de nodo para limitar los costes. ¿Por qué es correcta? Esta opción aborda directamente la restricción de que tienes un "presupuesto estricto" y no puedes "dejar que los costes de entrenamiento se ejecuten indefinidamente". Al entrenar un modelo en AutoML, el coste se basa en el tiempo de computación utilizado, medido en horas de nodo (node hours). Establecer un presupuesto de horas de nodo es la forma práctica de poner un límite máximo al entrenamiento. Una vez que se alcanza ese límite, el entrenamiento se detiene, incluso si no ha terminado de explorar todos los modelos posibles. Esto te garantiza que nunca gastarás más de lo presupuestado, cumpliendo así con una de las restricciones clave del problema. ❌ Respuestas Incorrectas A. Usar AutoML Natural Language para analizar las descripciones de los artículos. ¿Por qué es incorrecta? AutoML Natural Language está diseñado para trabajar con texto no estructurado, como analizar el sentimiento de una reseña o clasificar un documento. Si bien el dataset de productos seguramente contiene una columna con descripciones en texto, usar esta herramienta sería un error por dos motivos: Ignora el resto de los datos: El precio de un producto no depende solo de su descripción. Depende de la marca, categoría, estado, etc. (datos que están en otras columnas). Esta opción ignoraría toda esa información estructurada, que es crucial para predecir el precio. Es la herramienta equivocada: El problema principal es de regresión sobre datos tabulares, no de análisis de texto. D. Desplegar el modelo para predicción en línea para manejar el gran conjunto de datos. ¿Por qué es incorrecta? Esta opción confunde la fase de entrenamiento del modelo con la fase de uso (o inferencia). Entrenamiento: Es el proceso de enseñar al modelo usando tu dataset de 1.5 millones de filas. Despliegue/Predicción: Es lo que haces después de que el modelo ya está entrenado, para usarlo y hacer predicciones sobre nuevos datos. La predicción en línea (online prediction) se usa cuando necesitas predicciones rápidas y en tiempo real para una sola solicitud (por ejemplo, predecir el precio de un solo producto que un usuario acaba de publicar). El gran tamaño del dataset de entrenamiento no tiene nada que ver con la necesidad de tener predicciones en línea. Podrías necesitar predicciones para un millón de productos nuevos de una sola vez, para lo cual usarías la predicción por lotes (batch prediction). Por lo tanto, esta opción no resuelve ninguno de los problemas planteados (rendimiento del entrenamiento o control de costes).

Answer 1135

C Page 23 warns that "Perfect is the enemy of good." It states that perfect or very high scores can indicate the data is too easy and not varied enough. This means the model learned the specific test data perfectly but did not learn the underlying patterns needed to generalize to new, unseen images. The recommended solution is to increase the variety of images in the dataset (e.g., different lighting, angles, backgrounds). While (A) and (B) are potential issues for poor models, they don't explain the "perfect score" paradox. (D) relates to the lifecycle of a Natural Language model, not a Vision model's performance.

Answer 1136

B Vertex AI AutoML is designed to enable users to create custom machine learning models tailored to their specific data without requiring extensive coding or deep ML expertise, making it accessible for quick development of high-quality, data-specific ML solutions.

Answer 1137

D Vertex AI AutoML offers products for different data types, including AutoML Vision (for images), AutoML Natural Language (for text), and AutoML Tables (for structured data). AutoML Speech is not a type of AutoML product; Google Cloud provides a separate Speech-to-Text API for speech-related tasks.

Answer 1138

A A) Preparación de datos, entrenamiento del modelo y evaluación del modelo ✅ Esta opción describe perfectamente el flujo de trabajo de extremo a extremo que automatiza una plataforma de AutoML. Estas son las tres etapas lógicas y fundamentales para pasar de datos brutos a un modelo de machine learning listo para ser usado. Preparación de datos (Data preparation): En esta primera fase, la herramienta AutoML ingiere tus datos. Realiza tareas esenciales como limpiarlos de errores, detectar los tipos de datos de cada columna (numérico, categórico, etc.), y lo más importante, divide el conjunto de datos en subconjuntos de entrenamiento, validación y prueba. Es el paso de "preparar los ingredientes". Entrenamiento del modelo (Model training): Este es el corazón del proceso. AutoML prueba automáticamente diferentes tipos de modelos (redes neuronales, árboles de decisión, etc.) y ajusta sus configuraciones (hiperparámetros) para encontrar la mejor combinación para tus datos. También realiza ingeniería de características de forma automática para mejorar el rendimiento. Es el paso de "cocinar usando varias recetas". Evaluación del modelo (Model evaluation): Una vez entrenados varios modelos, AutoML los califica utilizando el conjunto de datos de prueba (que el modelo nunca ha visto antes). Proporciona métricas claras (como precisión, recall, F1-score, etc.) para que puedas ver objetivamente qué modelo funcionó mejor y por qué. Es el paso de "probar la comida y elegir el plato más delicioso". ¿Por qué las otras opciones son incorrectas? ❌ B) Entrenar, desplegar, servir (Train, deploy, serve) Esto describe el ciclo de vida de MLOps, que es más amplio. El trabajo de AutoML se centra en producir un modelo entrenado y evaluado. Las fases de desplegar (deploy) y servir (serve) son los pasos que se toman después de que AutoML ha terminado su trabajo y te ha entregado el mejor modelo. C) Ingesta de datos, ingeniería de características, despliegue del modelo (Data ingestion, feature engineering, model deployment) Esta opción mezcla partes de diferentes fases. La "ingeniería de características" es una tarea específica que ocurre dentro de la fase de entrenamiento, no es una fase principal por sí misma. Además, vuelve a incluir el "despliegue", que es un paso posterior, y omite la fase crítica de evaluación. D) Selección del modelo, ajuste de hiperparámetros, predicción (Model selection, hyperparameter tuning, prediction) Al igual que la anterior, esta opción enumera tareas muy específicas en lugar de las fases generales. El "ajuste de hiperparámetros" es parte del entrenamiento. La "selección del modelo" es el resultado de la evaluación. Y la "predicción" es lo que haces con el modelo una vez que ya está desplegado, no una fase de su creación. En Resumen Piensa en AutoML como un chef automático: Prepara los ingredientes (preparación de datos). Cocina varios platos con distintas técnicas (entrenamiento del modelo). Prueba todos los platos y te dice cuál es el mejor (evaluación del modelo). Las otras opciones hablan de tareas que ocurren antes o después de la cocina, o se centran en detalles muy específicos de la receta en lugar de en el proceso completo.

Answer 1139

B The recommended strategy is to begin with pre-built AI services (like Vision API or Speech-to-Text API) for common tasks, then use AutoML for building custom models when needed, and finally escalate to advanced ML/AI services for more complex requirements, optimizing efficiency and resource use.

Answer 1140

C Formato de Datos para AutoML C) CSV (Valores Separados por Comas) - ✅ Correcta Este es el estándar de facto para datos tabulares o estructurados. Un archivo CSV representa una tabla de manera muy simple: cada línea es una fila y los valores de cada columna están separados por una coma. Por qué es el más usado: Su simplicidad y compatibilidad universal lo hacen ideal. Casi cualquier base de datos, hoja de cálculo (como Excel o Google Sheets) o herramienta de datos puede exportar a CSV fácilmente. AutoML está optimizado para ingerir este formato de manera directa. Por qué las otras opciones son incorrectas A) JSON - ❌ Incorrecta Aunque AutoML Tables sí soporta el formato JSONL (JSON Lines), donde cada línea es un objeto JSON, no es el formato más típico para datos estructurados simples. El formato CSV es mucho más común y directo para este tipo de datos. JSONL es más útil cuando los datos tienen una estructura anidada o más compleja. B) XML - ❌ Incorrecta XML no es un formato de entrada soportado para el entrenamiento de modelos de AutoML Tables. Su estructura jerárquica y verbosa no se adapta bien al formato de tabla plano que requieren los modelos de aprendizaje automático. D) Parquet - ❌ Incorrecta Aunque Parquet es un formato columnar muy eficiente utilizado en ecosistemas de big data como BigQuery y Spark, no es un formato de archivo que se pueda subir directamente a AutoML para entrenar un modelo. La forma de usar datos de este tipo sería a través de una tabla de BigQuery, pero no subiendo un archivo .parquet.

Answer 1141

B Análisis de la descripción de Looker B. Una plataforma de datos a escala empresarial para usuarios de negocio - ✅ Correcta Esta es la descripción más acertada porque abarca los tres pilares de Looker: Plataforma de datos: Es más que una simple herramienta. Looker se conecta a tus bases de datos, te permite crear un modelo de datos centralizado y gobernado (usando LookML), y sobre ese modelo ofrece exploración, visualización, dashboards e integración con otras aplicaciones. Es una solución completa. A escala empresarial (Enterprise-scale): Está diseñado para grandes organizaciones, con un fuerte enfoque en la seguridad, la gobernanza, la escalabilidad y la creación de una "única fuente de la verdad" para las métricas de negocio. Para usuarios de negocio: Aunque los desarrolladores construyen el modelo de datos, el objetivo final de Looker es empoderar a los usuarios no técnicos (de ventas, marketing, operaciones, etc.) para que puedan explorar los datos y responder a sus propias preguntas sin necesidad de escribir SQL. Por qué las otras opciones son incorrectas Las otras tres opciones son incorrectas porque describen a Looker de una forma demasiado limitada o reduccionista, usando palabras como "exclusivamente", "solo" o "únicamente". A. Una herramienta exclusivamente para la visualización de datos - ❌ Incorrecta Aunque Looker tiene potentes capacidades de visualización, no es exclusivamente para eso. Su principal diferenciador y su núcleo es la capa de modelado semántico (LookML), que garantiza que todas las visualizaciones se basen en métricas consistentes y fiables. C. Una aplicación en la nube usada solo por desarrolladores de LookML - ❌ Incorrecta Esto es fundamentalmente falso. Los desarrolladores de LookML son quienes construyen y mantienen el modelo de datos, pero el público objetivo que usa y consume los informes y exploraciones es mucho más grande: los usuarios de negocio. El propósito de los desarrolladores es precisamente habilitar a este público más amplio. D. Una plataforma diseñada únicamente para organizar contenido en carpetas - ❌ Incorrecta La capacidad de organizar dashboards y "Looks" en carpetas es una función menor de gestión de contenidos. Describir Looker de esta manera sería como describir un coche como "una máquina diseñada únicamente para sujetar un volante". Es una parte trivial de su funcionalidad total.

Answer 1142

B The sources explicitly state that only the data explorer end user can create their own Looks and dashboards. Data viewers are noted as users who need to find existing information quickly and easily but "do not create their own reports and visualizations". LookML developers are responsible for curating Explores, and Looker administrators configure instance settings and permissions.

Answer 1143

B The sources clarify that the primary data analysis and visualization content types in Looker are Explores, Looks, and dashboards. Boards are described as a useful way of organizing content, but not as primary content types themselves. Recently Viewed and Favorites are sections for accessing content, while folders are for organizing content storage. Dimensions, Measures, and Views are components used within Explores to define data attributes and aggregations.

Answer 1144

D Por qué D ("Recently Viewed") es la respuesta correcta ✅ "Recently Viewed" (Visto recientemente) no es una carpeta en el sentido estricto de la plataforma Looker. No es un lugar donde puedas guardar informes, mover contenido o crear subcarpetas. En realidad, es una lista dinámica generada automáticamente que te muestra los últimos "Looks" (informes) y "Dashboards" (paneles) que has abierto. Su función es ser un atajo o un historial para acceder rápidamente a lo que has estado trabajando, pero no forma parte de la estructura jerárquica de carpetas donde se organiza el contenido. Analogía: Piensa en el menú "Archivos recientes" de un programa como Microsoft Word. Te muestra una lista de documentos que has abierto últimamente, pero no es una carpeta real de tu ordenador donde se guardan esos archivos. Por qué las otras opciones son incorrectas ❌ Las opciones A, B y C son carpetas o secciones fundamentales y estructurales de la interfaz de Looker para organizar y encontrar contenido. 📂 A. "Shared folders" (Carpetas compartidas): Esta es una carpeta de nivel superior y es esencial para el trabajo colaborativo. Es el lugar donde los equipos o toda la organización guardan el contenido que necesita ser accesible para más de una persona. B. "My folder" (Mi carpeta): Esta es la carpeta personal y privada de cada usuario. Por defecto, todo lo que guardas aquí solo lo puedes ver tú. Es tu espacio de trabajo individual antes de compartir algo con los demás. C. "The 'People' folder" (Personas): Esta es una sección principal que funciona como un directorio. Dentro de "People", puedes ver una lista de todos los usuarios de la plataforma y, si tienes los permisos necesarios, acceder a sus carpetas personales ("My folder"). Es clave para encontrar contenido creado por otros compañeros. En resumen, "My folder", "Shared folders" y "People" son lugares donde el contenido se organiza y reside, mientras que "Recently Viewed" es solo una lista de accesos directos que cambia constantemente según tu actividad.

Answer 1145

B Data explorers have permissions to create and share their own visualizations, unlike data viewers who can only access existing content.

Answer 1146

B y C ✅ Opciones Correctas B. To ask questions about the data (Para hacer preguntas sobre los datos) Esta es la función esencial de la sección "Explore". Es una interfaz interactiva diseñada para que los usuarios de negocio puedan "preguntar" cosas a los datos sin necesidad de escribir código SQL. Lo haces seleccionando: Dimensiones: Atributos o categorías por las que quieres agrupar los datos (ej: País, Fecha, Categoría de producto). Medidas: Valores numéricos que quieres calcular o agregar (ej: Suma de ventas, Número de usuarios, Promedio de compra). Cada combinación de dimensiones y medidas que seleccionas es, en efecto, una pregunta que se traduce a una consulta en la base de datos. C. To create visualizations and reports (Para crear visualizaciones e informes) Esta opción también es correcta. Una vez que has "preguntado" algo y obtienes una tabla con datos como resultado, el siguiente paso en la misma interfaz de "Explore" es visualizar esa información. Puedes convertir la tabla en todo tipo de gráficos (barras, líneas, mapas, etc.). Estas visualizaciones son los bloques de construcción que luego puedes guardar como informes individuales (llamados Looks) o agrupar en paneles de control más complejos (Dashboards). ❌ Opciones Incorrectas A. To configure user permissions (Para configurar permisos de usuario) Esto es incorrecto. La configuración de permisos, roles y acceso de los usuarios es una tarea puramente administrativa. En Looker, esto se gestiona en la sección de Administración (Admin), que está separada de las herramientas de análisis de datos. D. To manage LookML code (Para gestionar el código LookML) Esto es incorrecto. LookML es el lenguaje que los desarrolladores y analistas de datos utilizan para modelar los datos y definir las dimensiones y medidas que estarán disponibles en la sección "Explore". La gestión de este código se realiza en la sección de Desarrollo (Develop) de Looker, que es un entorno específico para los perfiles técnicos. En resumen, Explore es el espacio de juego para el usuario final (preguntar y visualizar), mientras que Develop (código) y Admin (permisos) son para los roles técnicos y de gestión.

Answer 1147

A These are the main content types in Looker used for data exploration, reporting, and visualization.

Answer 1148

C “Recently Viewed” is a page or a section, not a folder.

Answer 1149

C Clicking on a visualization allows users to explore the underlying data further, known as "drill-down" functionality.

Answer 1150

A Cloud Dataflow is designed for both batch and streaming data processing, making it ideal for building scalable data pipelines

Answer 1151

A y C Partitioned and clustered tables in BigQuery help improve query performance and reduce costs by limiting the amount of data scanned

Answer 1152

B IAM allows you to define who (users) has what access (roles) to which resources, ensuring secure and compliant data management

Answer 1153

A Cloud Pub/Sub ingests real-time data, Cloud Dataflow processes the data, and BigQuery stores it for analytics

Answer 1154

A, C y D The main content types in Looker are Explores, Dashboards, and Looks. Boards are used for organizing content but are not primary analysis types.

Answer 1155

B The presentation distinguishes between user roles. A Data Viewer consumes existing reports and dashboards. A Data Explorer (as per slides 11 and 12) is the user who accesses the "Explore" section to ask questions of the data, create new visualizations, and build new reports. Administrators manage the instance, and LookML Developers create the data models that power the Explores.

Answer 1156

C As described in the presentation (slides 21 and 22), a Dashboard is a collection of multiple visualizations, which are referred to as tiles. A Look is a single, standalone report or visualization. An Explore is the interface used to build reports, not the final collection itself. A Board is used to organize existing Looks and Dashboards, not to compose them from individual tiles.

Answer 1157

C Por qué la opción C es la correcta ✅ La opción C: "Una interfaz para construir informes donde los usuarios pueden hacer preguntas a los datos seleccionando dimensiones y medidas" es la definición perfecta de un "Explore". En plataformas como Looker, el Explore es el punto de partida para el usuario de negocio. Es un entorno interactivo y de autoservicio diseñado para que cualquier persona, incluso sin conocimientos de SQL, pueda "explorar" los datos. Piénsalo como un taller o un lienzo en blanco para el análisis de datos. Funciona así: Interfaz Gráfica: Presenta una lista de campos de datos disponibles. Dimensiones: Son los atributos o características de tus datos, como Nombre del Cliente, Fecha de la Compra o Categoría del Producto. Responden a las preguntas "quién", "qué", "dónde", "cuándo". Medidas: Son los cálculos o agregaciones numéricas, como Suma de Ventas, Promedio de Pedido o Recuento de Usuarios. Responden a las preguntas "cuánto" o "cuántos". El usuario simplemente selecciona las dimensiones y medidas que le interesan, añade filtros y la plataforma escribe el código SQL por detrás para generar una tabla de datos y una visualización. Es, literalmente, una interfaz para hacer preguntas a los datos. Por qué las otras opciones son incorrectas ❌ Opción A: Un espacio dedicado para escribir y probar el código LookML que define el modelo de datos. Esto es incorrecto. Este espacio es el entorno de desarrollo (IDE) de Looker. Es donde los desarrolladores de datos escriben el código LookML para definir qué dimensiones y medidas estarán disponibles en los Explores. Es el "detrás de cámaras", no la herramienta que usa el usuario final. Opción B: Un panel de configuración utilizado por los administradores para configurar los permisos de usuario y las conexiones a la base de datos. Esto es incorrecto. Esta descripción corresponde al panel de Administración (Admin). Es una sección de la plataforma a la que solo acceden los administradores para gestionar la instancia, como crear usuarios, conectar bases de datos y ajustar la configuración de seguridad. Opción D: Un artefacto estático y compartible que contiene una única visualización y sus datos subyacentes. Esto es incorrecto. Esto describe lo que en Looker se conoce como un "Look" (un informe guardado) o un "tile" dentro de un "Dashboard". Un Explore es el entorno dinámico e interactivo donde se crean estos artefactos. Un Look es el resultado guardado de una exploración. La diferencia clave es que el Explore es la herramienta de construcción, mientras que el Look es el producto final.

Answer 1158

B The presentation (slides 18 and 40) describes the "My folder" as a user's "own scratch space for works in progress" and for content that is only meaningful to that user. "Shared folders" are for polished, finalized content intended for collaboration. "LookML dashboards" is for dashboards defined in code, and "People" is for viewing other users' folders.

Answer 1159

B En las herramientas de análisis de datos como Looker (a la que se refiere la pregunta con "Explore interface"), los campos se dividen fundamentalmente en dos tipos: Dimensiones y Medidas. Dimensión (Dimension): Es un campo que describe los datos. Son atributos, categorías o cualquier cosa que puedas usar para agrupar, segmentar o filtrar tu información. Piensa en ellas como las respuestas a preguntas como "¿Quién?", "¿Qué?", "¿Dónde?" o "¿Cuándo?". En tu caso, 'User State' (Estado del Usuario) es una dimensión porque la usas para agrupar los resultados. Quieres ver los datos por cada estado (California, Texas, Nueva York, etc.). Medida (Measure): Es un campo que cuantifica los datos. Es un valor numérico sobre el que puedes realizar operaciones matemáticas (sumar, promediar, contar, etc.). Piensa en ellas como la respuesta a la pregunta "¿Cuánto?" o "¿Cuántos?". En tu caso, 'Average Order Value' (Valor Promedio del Pedido) es una medida porque es un cálculo que realizas para cada una de las dimensiones (para cada estado). La lógica siempre es: agrupas por una dimensión para calcular una medida. ❌ Por qué las otras opciones son incorrectas A. Measure, Dimension: Esta opción invierte los conceptos. No calculas un "estado de usuario" y no agrupas por un "valor promedio de pedido". Es justo al revés. C. View, Filter y D. Filter, View: Estas opciones usan términos que existen en la interfaz, pero no describen el tipo de campo, sino otras cosas: View (Vista): En este contexto, una "vista" es simplemente un conjunto de campos (dimensiones y medidas) que suelen estar relacionados con una tabla de la base de datos. Es como la "carpeta" que contiene los campos, no un tipo de campo en sí mismo. Filter (Filtro): Un "filtro" es una acción que aplicas a un campo (sea una dimensión o una medida) para limitar los resultados. Por ejemplo, podrías filtrar la dimensión 'User State' para que solo muestre 'California'. Pero el campo 'User State' sigue siendo una dimensión, no un filtro.

Answer 1160

B Looker is described as a platform that enables business users to access and analyze data to make data-based decisions, focusing on visualization and analysis, not storage, collection, or modeling.

Answer 1161

D Looker includes Looks, Dashboards, and Explores as content types, but Data Pipelines are not part of Looker's content, as they relate to data engineering processes outside the platform.

Answer 1162

B Data Explorers can create and share visualizations and reports, distinguishing them from Data Viewers, who only view content, and other roles like LookML Developers or Administrators.

Answer 1163

B Looker uses a folder structure, including shared and personal folders, to organize and secure content, making it discoverable and manageable, unlike tags, data warehouses, or scheduling.

Answer 1164

C Por qué la opción C es la correcta La sección Develop (Desarrollar) en la interfaz de Looker es el entorno de trabajo principal y específico para los desarrolladores de LookML. Es aquí donde se encuentran todas las herramientas necesarias para crear y gestionar el modelo de datos. IDE de LookML: Contiene el editor de código donde los desarrolladores escriben y modifican los archivos LookML (.view, .model, etc.). Definir Campos: Dentro de los archivos de vista (.view), los desarrolladores definen las dimensiones y medidas (los campos). Curar Explores: Dentro de los archivos de modelo (.model), los desarrolladores definen los "Explores", especifican las uniones (joins) entre vistas y organizan cómo los usuarios de negocio podrán consultar los datos. En resumen, la sección Develop es el "taller" del desarrollador; es el único lugar donde se realizan las tareas de codificación de LookML descritas en la pregunta. ✅ Por qué las otras opciones son incorrectas A) Shared Folders (Carpetas Compartidas) ❌ Esta sección es para usuarios finales y analistas. Se utiliza para guardar, organizar y compartir el contenido que ya ha sido creado, como Looks (consultas guardadas) y Dashboards (paneles de visualizaciones). Se trata de consumir y compartir información, no de definir el modelo de datos subyacente. B) Explore (Explorar) ❌ Esta es la interfaz para los usuarios de negocio. Ellos utilizan los "Explores" que los desarrolladores han creado en la sección Develop para hacer sus propias consultas, seleccionar campos, aplicar filtros y crear visualizaciones. Es el área de consumo y descubrimiento de datos, no de desarrollo del modelo. D) Admin (Administración) ❌ Esta sección es para los administradores de la plataforma Looker. Aquí se gestionan aspectos como: Conexiones a las bases de datos. Usuarios, grupos y permisos. Configuración general de la instancia. Monitorización del sistema. Aunque un desarrollador puede necesitar acceso a ciertas partes, no es el lugar donde se escribe el código LookML. Se enfoca en la gestión de la plataforma, no en el modelado de datos.

Answer 1165

C Dimensions are defined as attributes or characteristics of your data, and specifically, each column in a database table is considered a dimension in Looker. They help identify and select data attributes needed to answer questions

Answer 1166

C El porqué: El Orden Lógico de SQL Para entenderlo, piensa en el proceso que sigue la base de datos, que se basa en el lenguaje SQL. Looker traduce tus clics en un código SQL que sigue este orden estricto: Filtro de Dimensión (WHERE): Primero, la base de datos aplica los filtros de dimensión. Estos filtros actúan sobre los datos brutos, fila por fila. Es el paso más eficiente porque reduce drásticamente la cantidad de datos que necesitan ser procesados en los siguientes pasos. Analogía: Imagina que tienes una caja gigante con ladrillos de LEGO de todos los colores. Si solo quieres construir algo con ladrillos rojos, lo primero que haces es sacar todos los ladrillos rojos y dejar el resto en la caja. Este es tu filtro de dimensión. Agregación (GROUP BY): Con el conjunto de datos ya reducido (solo los ladrillos rojos), la base de datos realiza los cálculos. Agrupa los datos por las dimensiones que has seleccionado y calcula las medidas (sumas, promedios, etc.). Analogía: Ahora agrupas tus ladrillos rojos por forma (cuadrados, rectangulares, etc.) y cuentas cuántos tienes de cada forma. Filtro de Medida (HAVING): Finalmente, una vez que los cálculos están hechos y tienes los resultados agregados, se aplica el filtro de medida. Este filtro actúa sobre los resultados de la agregación, no sobre las filas individuales. Analogía: Después de contar, decides que solo te interesan los grupos de formas que tengan más de 50 ladrillos. Así que descartas los grupos que no cumplen esa condición. No podías hacer este paso hasta haberlos contado todos. Este orden WHERE -> GROUP BY -> HAVING es el estándar. Por lo tanto, los filtros de dimensión (que usan WHERE) siempre van antes que los filtros de medida (que usan HAVING). Por qué las otras no son correctas A. Los filtros de medida se aplican primero: Esto es imposible. No puedes filtrar por un total (medida) antes de haberlo calculado. B. Se aplican simultáneamente: Tampoco es posible, ya que operan en diferentes momentos del proceso: uno antes de la agregación y otro después. D. El orden depende del usuario: El orden de procesamiento está integrado en la lógica de SQL para garantizar la eficiencia y la corrección de los resultados. No es una opción que el usuario pueda cambiar.

Answer 1167

C When a measure filter is used, Looker first computes all potential aggregations (like the average price for all fruit types in this case). Only then does it discard the results that do not meet the specified filter criteria (e.g., average price less than $0.50) before presenting the final output. Filters do not alter the underlying data

Answer 1168

B Selecting two or more dimensions in Looker returns all unique combinations of the values from those fields. For example, selecting "Fruit Type" and "Color" would show "apple red" and "apple green" as distinct rows if both exist

Answer 1169

C In Looker, a dimension represents an attribute or characteristic of your data—typically a column in your database (e.g., "Fruit Type" or "Color").

Answer 1170

A, C y D Measures are aggregations (like COUNT, SUM, or AVERAGE) performed across rows. City names (B) are dimensions, not measures.

Answer 1171

B A dimension filter is applied before any aggregation. It narrows down the dataset by including only rows that meet the filter criteria.

Answer 1172

B To get the total cost per type of fruit, you must use the Fruit Type dimension and the Total Price measure.

Answer 1173

C Looker applies the dimension filter first, which limits the dataset, and then applies the measure filter on the aggregated results.

Answer 1174

C In Looker, a dimension represents an attribute or characteristic of your data, typically corresponding to a column in a database table.

Answer 1175

B A measure in Looker is an aggregate calculation performed over multiple rows, often using SQL functions like COUNT, SUM, or AVG

Answer 1176

A y C Por qué las opciones A y C son correctas A. Los filtros de dimensión se aplican antes que los filtros de medida ✅ Esta afirmación es verdadera y se debe a cómo funcionan las bases de datos y el lenguaje SQL que Looker genera. Filtro de Dimensión: Una dimensión es un atributo descriptivo (ej: País, Fecha, Nombre del producto). Cuando filtras por una dimensión, Looker añade una condición WHERE a la consulta SQL. La cláusula WHERE filtra las filas de datos antes de que se realice cualquier cálculo o agregación. Filtro de Medida: Una medida es un cálculo o agregación (ej: SUMA(Ventas), CONTEO(Usuarios)). Cuando filtras por una medida, Looker añade una condición HAVING a la consulta SQL. La cláusula HAVING se aplica después de que los datos han sido agrupados y las medidas calculadas. El orden de ejecución en SQL es siempre: WHERE -> GROUP BY -> HAVING. Por lo tanto, los filtros de dimensión (WHERE) siempre se aplican antes que los filtros de medida (HAVING). Analogía: Imagina que tienes una caja de fruta. Un filtro de dimensión sería como sacar todas las manzanas que no son rojas (WHERE color = 'rojo'). Un filtro de medida sería como, una vez agrupadas las frutas por tipo, quedarte solo con los grupos que pesan más de 1 kg (HAVING SUMA(peso) > 1). Primero quitas las frutas individuales y luego evalúas los grupos. C. Puedes usar múltiples filtros de dimensión al mismo tiempo ✅ Esta afirmación es verdadera. Es una de las funcionalidades más básicas y esenciales de Looker (y de cualquier herramienta de análisis de datos). Puedes combinar tantos filtros de dimensión como necesites para acotar tu búsqueda. Ejemplo: Puedes filtrar para ver los Usuarios (dimensión) que son de España (filtro 1) Y que se registraron durante el año 2024 (filtro 2) Y cuyo Estado es Activo (filtro 3). Looker simplemente unirá estas condiciones en la cláusula WHERE de la consulta SQL. Por qué las otras opciones son incorrectas B. Los filtros de medida se aplican antes que los filtros de dimensión ❌ Esta afirmación es falsa. Es la contradicción directa de la opción A. Como se explicó anteriormente, el orden de operaciones en SQL dicta que la cláusula WHERE (dimensiones) se procesa antes que la cláusula HAVING (medidas). D. Los filtros eliminan datos de la base de datos de forma permanente ❌ Esta afirmación es totalmente falsa y peligrosa. Los filtros en Looker (y en las consultas SELECT de SQL en general) nunca modifican ni eliminan los datos originales. Un filtro es simplemente una condición para una consulta de lectura; solo restringe los datos que se muestran en los resultados de esa consulta específica. La base de datos subyacente permanece intacta. Para eliminar datos de una base de datos se necesitarían comandos específicos como DELETE o TRUNCATE, que Looker, como herramienta de visualización y análisis, no ejecuta al aplicar un simple filtro.

Answer 1177

B Selecting multiple dimensions returns all unique combinations of those dimension values, which can result in more granular groupings in your results

Answer 1178

B Filtering on a measure means applying a condition to an aggregated value (such as count or sum), rather than a raw data attribute

Answer 1179

B As explained on pages 4 and 11, Fruit Type and Color are attributes or characteristics of the data. They are non-aggregated fields and are therefore considered dimensions. To see the unique combinations of these attributes, the analyst must select both as dimensions.

Answer 1180

D ✅ Explicación de la Respuesta Correcta: D D. Looker primero filtra los datos brutos para incluir solo las filas donde el País es "USA", luego agrega para calcular el Total de Unidades Vendidas por categoría y, finalmente, elimina las categorías donde el total no es superior a 1000. Este es el proceso correcto y más eficiente, y se corresponde directamente con cómo funciona una consulta SQL estándar (WHERE -> GROUP BY -> HAVING). Pensemos en ello como si fueras un cocinero preparando una receta: Seleccionas tus ingredientes (Filtrar por Dimensión - WHERE): Primero, vas a la despensa y coges solamente las ventas de "USA". Ignoras todo lo demás. Esto es muy rápido y reduce enormemente la cantidad de "ingredientes" con los que tienes que trabajar. Este es el filtro de dimensión (Country = "USA"). Preparas y combinas (Agregar - GROUP BY): Ahora, con solo las ventas de USA, las agrupas por categoría de producto y sumas las unidades de cada una para obtener el "Total de Unidades Vendidas". Haces el control de calidad final (Filtrar por Medida - HAVING): Una vez que tienes el total de cada categoría (ya cocinado), revisas cuáles cumplen tu requisito final: que el total sea mayor que 1000. Descartas las que no llegan. Este es el filtro de medida (Total Units Sold > 1000). Este orden asegura que la base de datos haga los cálculos pesados (la agregación) sobre la menor cantidad de datos posible. ❌ Por qué las otras opciones son incorrectas A. Looker primero calcula el Total de Unidades Vendidas para todas las categorías en todos los países... Esto es extremadamente ineficiente. Sería como contar las ventas de todo el mundo solo para al final quedarte con las de un solo país. Las bases de datos están diseñadas para evitar este trabajo innecesario. B. Looker primero encuentra todas las categorías con Total de Unidades Vendidas > 1000, y luego... solo muestra las de "USA". Esto es lógicamente incorrecto y daría un resultado erróneo. Podría haber una categoría que vendió 1200 unidades a nivel mundial, pero solo 50 en USA. Según esta lógica, esa categoría pasaría el primer filtro (1200 > 1000) pero luego sería incorrectamente asociada solo a USA. C. Looker aplica los filtros de País y Total de Unidades Vendidas simultáneamente en las filas de la base de datos sin procesar... Esto es imposible. No se puede aplicar un filtro de "Total de Unidades Vendidas > 1000" a una fila individual, porque el "total" es un valor agregado (una suma de muchas filas). Es como intentar saber si una cesta de manzanas pesa más de 5 kg antes de haber puesto todas las manzanas en ella. Primero tienes que sumar (agregar), luego puedes filtrar por el total.

Answer 1181

A, B, C y D To solve this business problem, all four elements are necessary: A. Traffic Source is the dimension to group the data by. B. Count of Users is the measure (aggregation) to quantify the users for each source. C. The Row Limit is used to restrict the results to only the "top 5" sources after sorting. (This is demonstrated on page 42). D. A column chart is the specified output format for the visualization. (This is demonstrated on page 44).

Answer 1182

B This is a fundamental definition question. As stated on page 13, "Measures are calculations performed across multiple rows of data. As such, measures are aggregates of data attributes, or dimensions." Common examples are SQL aggregation functions like COUNT(), SUM(), and AVG().

Answer 1183

B Dimensions are used to categorize and describe data, such as time periods, geographic locations, or product categories. They are not aggregations (which are measures) or filtered data (which is a result of applying filters).

Answer 1184

B Measures are used to perform calculations on numerical data, such as summing sales, counting orders, or calculating averages, to provide meaningful insights for analysis.

Answer 1185

B Filters are applied during the transformation phase of ETL to clean, refine, and prepare the data before it is loaded into the data warehouse. This ensures only relevant data is processed.

Answer 1186

B El "Cerebro" de Looker: La Capa de Modelado Lógico (LookML) A diferencia de otras herramientas que requieren que muevas los datos a su propio sistema, Looker trabaja directamente sobre tu base de datos existente ("in-database"). No crea nuevas tablas físicas, sino que construye una capa de traducción inteligente por encima de tus datos brutos. Esta capa, escrita en LookML, hace dos cosas clave: Define Vistas Lógicas: Un desarrollador de Looker crea "vistas" que actúan como un diccionario para los datos. Una vista define todas las dimensiones (atributos como 'Nombre de Cliente' o 'Fecha de Pedido') y medidas (cálculos como 'Total de Ventas' o 'Promedio de Compra') para una tabla de la base de datos. Esto traduce el lenguaje técnico de la base de datos a un lenguaje de negocio fácil de entender. Define Relaciones: El modelo también establece las relaciones (JOINs) entre estas diferentes vistas. De esta forma, un usuario de negocio puede combinar datos de clientes, pedidos y productos sin tener que saber cómo se conectan técnicamente en la base de datos. Analogía del Menú: Piensa que tu base de datos es la cocina de un restaurante, llena de ingredientes crudos y complejos. LookML es el menú que el chef (el analista) ha creado. Describe los platos disponibles (las vistas lógicas) y qué ingredientes llevan (las dimensiones y medidas). El usuario de negocio es el cliente. No necesita saber cómo cocinar; simplemente elige los platos del menú. Looker es el camarero. Toma el pedido del cliente y lo traduce en instrucciones precisas para que la cocina prepare el plato (escribe y ejecuta la consulta SQL optimizada). Por qué las otras opciones son incorrectas A. Creando tablas físicas en la base de datos: El enfoque principal de Looker es consultar los datos donde viven. Aunque tiene una función para crear tablas físicas para optimización (PDTs), no es su método fundamental de modelado. C. Escribiendo consultas SQL complejas directamente: El objetivo de LookML es precisamente lo contrario: crear un modelo reutilizable para que los usuarios de negocio puedan generar sus propias consultas complejas simplemente seleccionando campos, sin escribir una sola línea de SQL. D. Usando lenguajes de modelado de datos propietarios: Si bien es técnicamente cierto que LookML es un lenguaje "propietario" de Looker, esta respuesta es demasiado genérica. La opción B es mucho mejor porque describe qué hace ese lenguaje: define vistas lógicas y relaciones.

Answer 1187

C By structuring data into dimensions (categorical attributes) and measures (numerical aggregations), analysts can perform ad-hoc queries and create visualizations that provide valuable business insights.

Answer 1188

B Boards serve to centralize relevant content by merely linking to existing Looks and dashboards, which continue to reside in their original folders. This means boards do not store the actual content, nor do they affect its original location or permissions

Answer 1189

B Roles y Permisos en Looker En Looker, lo que un usuario puede hacer está definido por sus permisos. Un "data explorer" (explorador de datos) o un usuario con permisos de edición sobre un dashboard tiene la capacidad de modificar su contenido y presentación, pero no de alterar los fundamentos del modelo de datos ni la seguridad. Por qué la Opción B es la correcta ✅ La función principal del modo de edición de un dashboard es permitir a los usuarios como los "exploradores de datos" personalizarlo para que se ajuste mejor a sus necesidades. Esto incluye: Añadir nuevos mosaicos: Pueden crear nuevas visualizaciones desde un "Explore" y añadirlas al dashboard. Añadir mosaicos de texto: Pueden incluir títulos, descripciones, o explicaciones para dar más contexto al dashboard. Reorganizar y redimensionar: Pueden mover y cambiar el tamaño de los mosaicos existentes. Editar la configuración de los mosaicos: Pueden cambiar el tipo de visualización, los colores, los ejes, etc. Estas acciones modifican el dashboard en sí, no el código subyacente ni los permisos. Por qué las otras opciones son incorrectas ❌ A. Exportar mosaicos individuales desde el modo de edición: Si bien puedes descargar los datos de un mosaico, no es una acción que se realice específicamente desde el modo de edición. La exportación de datos es una función disponible directamente desde el modo de visualización del dashboard. Entrar en modo edición para descargar algo sería un paso innecesario e ilógico. C. Cambiar el modelo de datos subyacente: Esto es una acción mucho más avanzada que requiere permisos de desarrollador (developer). Cambiar el modelo de datos (el archivo .model en LookML) afectaría a todos los "Looks" y dashboards que dependen de él. Es una tarea de administración de datos, no de personalización de un dashboard. D. Concederse a sí mismos acceso sin restricciones: La gestión de permisos y acceso a los datos es una función puramente administrativa, controlada por los administradores de Looker. Un usuario no puede escalar sus propios permisos. Permitir esto sería un fallo de seguridad grave en cualquier plataforma de datos.

Answer 1190

C To apply filters or make any modifications to an existing Look, the first step is always to enter "Edit mode" by clicking the Edit button in the top right of the screen.

Answer 1191

C Por qué 'C' es la respuesta correcta Al crear o editar un filtro en un dashboard de Looker, te aparece una ventana de configuración. Dentro de esa ventana, hay una pestaña específica llamada "Tiles To Update". Esta pestaña es la que te da el control granular para decidir cómo interactúa el filtro con cada uno de los mosaicos (gráficos o informes) del dashboard. Específicamente, te permite: Elegir qué mosaicos escucharán el filtro: Verás una lista de todos los mosaicos del dashboard. Vincular el filtro a un campo específico en cada mosaico: Para cada mosaico que quieras que se vea afectado, debes seleccionar el campo del modelo de datos de ese mosaico que corresponde al filtro. Por ejemplo, tu filtro global puede ser "Fecha de Pedido", y en un mosaico de "Usuarios" lo vincularás al campo "Fecha de Creación de Usuario". Excluir mosaicos: Si no seleccionas un campo para un mosaico determinado, ese mosaico no se verá afectado por el filtro, que es una parte clave de la pregunta. Por qué las otras opciones son incorrectas A. Settings tab (Pestaña de Configuración): Esta pestaña se usa para configurar el comportamiento general del filtro, como el tipo de control que verá el usuario (por ejemplo, un menú desplegable, un campo de texto), qué valores puede seleccionar y si es obligatorio rellenarlo. No se usa para vincular el filtro a los mosaicos. B. Additional options within the filter settings (Opciones adicionales dentro de la configuración del filtro): Este es un término demasiado genérico. Si bien técnicamente la pestaña "Tiles To Update" está dentro de la configuración del filtro, no es una opción llamada "Additional options". Es una pestaña con un nombre y una función muy específicos. D. Choose filter criteria tab (Pestaña de Elegir criterio de filtro): Esta descripción no corresponde a una pestaña real en la configuración de filtros de un dashboard. Se parece más a lo que hace un usuario final cuando utiliza el filtro (elige un valor), no a lo que hace un desarrollador cuando lo configura.

Answer 1192

C Boards do not override the existing permissions for the content they link to. Even if a user has access to a board, they must still have pre-existing access to the original folder where the content item (Look or dashboard) is stored in order to view it through the board. Boards can be shared by clicking the share icon, and access levels (view or edit) can be specified for individuals or groups.

Answer 1193

C Both dimensions and measures can be used as filter criteria in Looks, just like in Explores and dashboards. This allows for flexible filtering based on different data types

Answer 1194

A To add or edit filters in a Look, users must enter the Look’s edit mode. Changes are only possible in this mode and must be saved to take effect

Answer 1195

B ✅ Opción Correcta (La acción que PODRÍA NO poder hacer) B. Export individual tiles (Exportar paneles individuales) Esta es la respuesta correcta porque la capacidad de exportar o descargar datos es un permiso independiente de la capacidad de editar la apariencia de un dashboard. Una organización puede configurar los permisos de un usuario para que pueda explorar datos, crear visualizaciones y editar dashboards (es decir, puede hacer A, C y D), pero restringirle explícitamente la capacidad de descargar los datos a un archivo local (como CSV o Excel). Esto se hace por razones de seguridad y gobernanza de datos, para evitar fugas de información sensible. Por lo tanto, es la única acción de la lista que un "data explorer" podría tener prohibido hacer. ❌ Opciones Incorrectas (Acciones que SÍ puede hacer) Las siguientes tres opciones son cambios fundamentales en la edición de un dashboard. Si un usuario tiene permisos para editar un dashboard, podrá realizar estas acciones. A. Add or remove tiles (Añadir o quitar paneles) Esta es una de las funciones más básicas de la edición de un dashboard. Un usuario con permisos de edición puede añadir nuevos "paneles" (tiles) basados en Looks o quitar los que ya no necesita. C. Rename tiles (Renombrar paneles) Cambiar el título de un panel para que sea más claro o descriptivo es una función de edición estándar. Si puedes editar el dashboard, puedes cambiar los nombres de sus componentes. D. Resize tiles (Cambiar el tamaño de los paneles) Ajustar el tamaño y la posición de los paneles es esencial para organizar la disposición visual del dashboard. Esta es una capacidad de edición fundamental.

Answer 1196

A, C y D Boards can include dashboards, Looks, and URLs, but Explores cannot be added because they are not user-generated content

Answer 1197

C Boards only link to content; the original content remains in its original location and is not moved or duplicated

Answer 1198

B As stated on slide 11, a Look focuses on a single visualization to answer a single question. In contrast, a dashboard is designed to contain multiple visualizations (tiles) to provide a broader view and answer multiple questions at once.

Answer 1199

C According to slide 4, to apply filters or make any other modifications to a Look, the user must first enter Edit mode by clicking the "Edit" button. Only then can they access the field picker to add new filters.

Answer 1200

B As shown on slide 26, the "Tiles to Update" tab is a critical step in adding a dashboard filter. It allows the creator to specify exactly which tiles should react to the filter, which is important because a dashboard can contain tiles from different Explores.

Answer 1201

B Este escenario es un caso clásico de cómo funcionan los permisos en la mayoría de las plataformas de datos y Business Intelligence (como Looker, Tableau, Power BI, etc.). El principio fundamental es que los permisos se basan en el objeto original, no en los accesos directos o enlaces a él. Piensa en ello como un enlace a un documento privado de Google Drive. Aunque pegues ese enlace en un chat grupal al que todo el mundo tiene acceso, si alguien hace clic en él pero no tiene permiso para ver el documento original, recibirá un mensaje de "Acceso Denegado". El sistema funciona igual aquí. ¿Por qué la Opción B es la Correcta? ✅ El usuario tiene acceso al "tablero" (board): El usuario puede abrir y ver el tablero "General-KPIs". Por lo tanto, verá la estructura del tablero, incluyendo el "espacio" o "widget" donde el dashboard de ventas debería cargarse. El usuario NO tiene acceso al "dashboard" original: El dashboard reside en la carpeta "Sales-Private". Para poder mostrar los datos de ese dashboard, el sistema debe verificar si el usuario actual tiene permisos para acceder a esa carpeta. La comprobación de permisos falla: Como el usuario no tiene los permisos necesarios sobre la carpeta de origen, el sistema no puede cargar el contenido del dashboard. Se muestra un error: La interfaz de usuario mostrará un recuadro vacío, un mensaje de error o una notificación de "permiso denegado" en lugar del dashboard. Este comportamiento es una característica de seguridad esencial. Garantiza que los datos sensibles permanezcan protegidos sin importar dónde se comparta o enlace un informe, aplicando el principio de privilegios mínimos. ¿Por qué las Otras Opciones son Incorrectas? ❌ Opción A: Es una brecha de seguridad grave Si se concediera acceso automáticamente, cualquier persona podría obtener acceso a informes confidenciales simplemente añadiéndolos a un tablero público. Esto se conoce como "escalada de privilegios" y es algo que los sistemas seguros están diseñados específicamente para evitar. Opción C: Es una acción diferente "Añadir" un dashboard a un tablero es como crear un acceso directo. "Mover" el dashboard es una acción completamente diferente que cambiaría su ubicación original. La pregunta especifica que el dashboard fue "añadido", no "movido". Opción D: Los permisos no funcionan así Los permisos del contenedor (el tablero) no anulan los permisos del contenido (el dashboard). La regla general en los sistemas de gobierno de datos es que siempre se aplica el conjunto de permisos más restrictivo. El hecho de que el tablero sea público no hace público el contenido privado que se enlaza en él.

Answer 1202

B As seen in the quiz on slide 63, Explores are interfaces for data exploration, not user-generated content themselves. You can add the content created from an Explore (Looks and Dashboards) to a board, as well as URL links (slide 33), but you cannot add the Explore interface itself.

Answer 1203

C In Looker, filters can be applied to both dimensions and measures when editing a Look, allowing users to limit data based on specific criteria, such as filtering by a dimension like "brand" or a measure like "total revenue."

Answer 1204

C ¿Por qué la opción C es la correcta? ✅ C) Only data explorers Looker tiene un sistema de permisos y roles muy granular, pero se puede simplificar en tres arquetipos de usuario principales: Viewer (Espectador): Puede ver e interactuar con dashboards y "Looks" (informes guardados) existentes, pero no puede crear ni editar contenido nuevo, ni explorar los datos por su cuenta. Explorer/Creator (Explorador/Creador): Este es el usuario estándar o "power user". Tiene permisos para explorar los datos, hacer nuevas preguntas, guardar sus propios "Looks" y, lo más importante, crear y editar dashboards. Este rol está diseñado para analistas de negocio y cualquier persona que necesite construir sus propios informes. Developer/Admin (Desarrollador/Administrador): Tienen todos los permisos de un "Explorer" y además pueden modificar el modelo de datos (LookML) o administrar la instancia de Looker (usuarios, conexiones, etc.). La pregunta se refiere a la capacidad de crear y editar dashboards, que es la función principal que define al rol de "Explorer". Aunque los administradores y desarrolladores también pueden hacerlo, esta no es una tarea exclusiva de ellos. La opción C es la que mejor describe al grupo de usuarios designados para esta tarea. ¿Por qué las otras opciones son incorrectas? ❌ A) Anyone with access to Looker Esto es incorrecto. Los usuarios con el rol de "Viewer" tienen acceso a Looker, pero solo en modo de solo lectura. No pueden crear ni editar dashboards, lo que invalida esta opción. B) Only data engineers Esto es incorrecto. "Data engineer" (ingeniero de datos) es un título de trabajo, no un rol específico dentro de Looker. De hecho, los ingenieros de datos suelen estar más enfocados en preparar los datos antes de que lleguen a Looker. Los principales creadores de dashboards suelen ser analistas de datos o de negocio, no necesariamente ingenieros. D) Only administrators Esto es incorrecto y va en contra del propósito de una herramienta de BI de autoservicio como Looker. Uno de los mayores beneficios de Looker es capacitar a los usuarios de negocio (Explorers) para que respondan sus propias preguntas y construyan sus informes sin depender de un administrador. Limitar esta función solo a los administradores crearía un cuello de botella y desaprovecharía el potencial de la herramienta.

Answer 1205

A ¿Por qué la opción A es la correcta? La opción A es la correcta porque Looker ofrece un control granular sobre cómo interactúan los filtros con cada uno de los elementos (llamados tiles o fichas) de un dashboard. Cuando creas o editas un filtro en un dashboard, hay una pestaña específica llamada "Tiles to Update" (Fichas para actualizar). En esta sección, Looker te muestra una lista de todas las fichas del dashboard y te permite seleccionar manualmente a cuáles quieres que se aplique el filtro. Esto es extremadamente útil para casos como: Tener una ficha con un KPI global (ej: "Ventas Totales Históricas") que no quieres que cambie, mientras que el resto de las gráficas sí se filtran por fecha o región. Mostrar una comparación entre un dato filtrado y un dato total en el mismo dashboard. Por lo tanto, puedes excluir cualquier ficha de ser afectada por un filtro simplemente desmarcándola en la configuración de ese filtro. ⚙️ ¿Por qué las otras opciones son incorrectas? B) No, global filters apply to all tiles on the dashboard: Esto es falso. Es una de las características más potentes de Looker el poder decidir a qué afecta cada filtro. Si los filtros se aplicaran obligatoriamente a todo, la herramienta sería mucho menos flexible. C) Only if the tile is based on a different Explore: Esto es incorrecto. Aunque la relación entre el campo del filtro y los campos de una ficha es importante (normalmente deben venir del mismo Explore para que se conecten automáticamente), tú tienes el control final. Puedes perfectamente tener dos fichas basadas en el mismo Explore y hacer que el filtro se aplique solo a una de ellas. La exclusión no depende del Explore, sino de la configuración manual del filtro. D) Only for tiles that are not visualizations: Esto es incorrecto y no tiene mucha lógica. El principal objetivo de los filtros es, precisamente, actualizar las visualizaciones (gráficas, tablas, mapas, etc.). Se puede excluir cualquier tipo de ficha, ya sea una visualización, un dato numérico o un simple texto.

Answer 1206

C Looker boards are used to centralize and organize content such as Looks, dashboards, and external URLs, but they cannot include Explorers, as they link to existing content without duplication.

Answer 1207

B In Looker, to modify filters in a Look or dashboard, users must enter Edit mode, where they can select and configure filters using the field picker, ensuring changes can be made to the displayed data.

Answer 1208

B Pivoting data in Looker enables you to turn a selected dimension into several columns, which in turn creates a matrix of your data, similar to a pivot table in spreadsheet software. This functionality is highly useful for analyzing metrics across different data groupings and allows dimensions to be displayed horizontally. Pivots are applied only to the visual display of your results, leaving your underlying data unaffected

Answer 1209

C Las Table Calculations (Cálculos de Tabla) son herramientas que se ejecutan en el navegador, después de que la base de datos ha devuelto los resultados de la consulta. Son "la buena" por estas razones: Agilidad: Te permiten crear métricas (como variaciones porcentuales o acumulados) sin tener que escribir LookML ni esperar a que un desarrollador actualice el modelo. Flexibilidad: Son ideales para preguntas de una sola vez ("one-off") que no necesitan estar guardadas para siempre en el sistema. Visualización: Muchos gráficos complejos en Looker requieren cálculos intermedios que solo se pueden hacer sobre los datos ya resumidos en la tabla de resultados. Por qué las otras son "las malas" Para entender por qué fallan, hay que recordar que en Looker existe una separación clara entre el Modelado (LookML) y el Análisis (Front-end). Opción,Por qué es incorrecta A,"Los Table Calculations no son permanentes. Solo existen en el informe o Explore donde los creas. Si quieres algo ""universally available"", debes usar LookML." B,"Las Table Calculations actúan después de que la consulta se ejecuta, sobre el subconjunto de datos que ves en pantalla. No pueden manipular toda la base de datos antes de la ejecución." D,"Nunca sustituirán al LookML. LookML es la ""verdad única"" y la base de la gobernanza de datos. Las Table Calculations son solo una capa cosmética y de análisis rápido por encima."

Answer 1210

B La pregunta se refiere a las categorías de funciones que puedes usar para crear "Table Calculations" (cálculos de tabla) en Looker. Estas son operaciones que se realizan sobre los datos que ya han sido devueltos por una consulta en una tabla de "Explore". B) String, Numerical, Conditional, and Date (Respuesta Correcta ✅) Por qué es correcta: Esta opción agrupa las funciones de cálculo de tabla de Looker en sus cuatro categorías fundamentales, según el tipo de datos que manipulan o la lógica que aplican: String (Texto): Funciones para manipular texto. Por ejemplo, concat() para unir textos, contains() para verificar si un texto contiene una subcadena, o substr() para extraer parte de un texto. Numerical (Numéricas): Funciones para realizar operaciones matemáticas. Incluyen agregaciones como sum(), mean() (promedio), y otras como round() (redondear) o cálculos de diferencia como offset(). Conditional (Condicionales): Funciones para aplicar lógica. La más común es if(condición, valor_si_verdadero, valor_si_falso), que permite crear reglas y devolver diferentes resultados según si se cumple una condición. También incluye funciones lógicas como is_null() o coalesce(). Date (Fecha): Funciones diseñadas específicamente para trabajar con fechas y tiempos. Por ejemplo, now() para obtener la fecha y hora actual, diff_days(fecha1, fecha2) para calcular la diferencia de días entre dos fechas, o extract_months() para obtener el mes de una fecha. Estas cuatro categorías cubren prácticamente todas las funciones disponibles para los cálculos de tabla en la documentación oficial de Looker. A) Aggregate, Row-level, Column-level, and Custom (Respuesta Incorrecta ❌) Por qué es incorrecta: Aunque estos términos se relacionan con el análisis de datos, no son las categorías de funciones de Looker. Aggregate (Agregado): Es un tipo de operación (como sumar o promediar), no una categoría de función. Las funciones de agregación pertenecen principalmente a la categoría Numerical. Row-level (Nivel de fila) y Column-level (Nivel de columna): Describen el ámbito de una operación (si opera en una sola fila o en toda la columna), no el tipo de función en sí. Por ejemplo, sum() opera a nivel de columna, mientras que if() opera a nivel de fila. Custom (Personalizado): Es un término demasiado genérico. Todos los cálculos de tabla son, por definición, personalizados. C) String, Mathematical, Logical, and Date & Time (Respuesta Incorrecta ❌) Por qué es incorrecta: Esta opción es muy similar a la correcta y conceptualmente no está mal, pero no usa la terminología exacta de Looker. Looker se refiere a las funciones matemáticas como "Numerical" (Numéricas) y a las funciones lógicas como "Conditional" (Condicionales). Aunque el significado es parecido, la opción B usa los nombres precisos de las categorías en la plataforma. D) Transform, Filter, Sort, and Visualize (Respuesta Incorrecta ❌) Por qué es incorrecta: Estos son nombres de acciones generales que se pueden realizar en una plataforma de Business Intelligence, pero no son las categorías de las funciones de cálculo de tabla. Transform (Transformar): Los cálculos de tabla son una forma de transformar datos, pero no es una categoría en sí. Filter (Filtrar) y Sort (Ordenar): Son funcionalidades distintas en Looker para limitar o reordenar los datos antes de que se apliquen los cálculos. Visualize (Visualizar): Se refiere a la creación de gráficos, que es el paso final después de que los datos han sido procesados.

Answer 1211

B Offset functions are explicitly stated to be a subset of table calculation functions. Their purpose is to "programmatically reference values from other rows or columns in your query results to calculate new values". This allows for calculations like comparing current values to previous or subsequent values

Answer 1212

B La Lógica Clave: El Orden de los Datos lo es Todo 🤔 Las funciones de offset en Looker (offset(), pivot_offset(), etc.) son "ciegas". No entienden de fechas, meses o categorías; solo entienden de posición física en la tabla de resultados. offset(campo, -1) significa "dame el valor del campo en la fila de arriba". offset(campo, 1) significa "dame el valor del campo en la fila de abajo". Si no sabes cómo están ordenadas las filas, ¡es imposible saber qué valor vas a obtener! Analogía: Imagina que tienes una lista de ventas mensuales y quieres calcular la diferencia con el mes anterior. Si los datos están ordenados cronológicamente (Enero, Febrero, Marzo), para la fila de Marzo, la "fila de arriba" es Febrero. Usarías offset(ventas, -1). Pero si los datos están ordenados alfabéticamente (Enero, Febrero, Julio, Junio, Marzo), para la fila de Marzo, la "fila de arriba" es Junio. Tu cálculo sería completamente incorrecto. Por qué la Opción B es la Práctica Recomendada ✅ El flujo de trabajo correcto y seguro es: Selecciona tus dimensiones y medidas (por ejemplo, "Mes de Creación" y "Recuento de Usuarios"). Pulsa el botón "Run". Observa la tabla de resultados. Presta mucha atención a la columna por la que quieres hacer el cálculo (en este caso, el mes). ¿Está ordenada como esperas (cronológicamente)? Ahora, y solo ahora, puedes escribir con seguridad tu función de tabla. Si los meses están ordenados de más antiguo a más nuevo, usarás offset(..., -1) para obtener el mes anterior. Si estuvieran al revés, necesitarías usar offset(..., 1). Este método de "verificar primero" te asegura que tu cálculo será correcto desde el principio y te ahorra tiempo de depuración. Por qué las Otras Opciones son Incorrectas ❌ A. Deberías pulsar "Run" después de escribir la función: Esto es arriesgado. Estás escribiendo la función "a ciegas", asumiendo un orden que podría no ser el correcto. Es muy probable que obtengas resultados erróneos. C. El botón "Run" no es aplicable: Esto es falso. Los cálculos de tabla se ejecutan en el cliente (en tu navegador) después de que la consulta principal se haya ejecutado y devuelto un conjunto de datos. Sin pulsar "Run", no hay datos sobre los que realizar el cálculo. D. Solo necesitas pulsar "Run" si el cálculo usa pivot_offset(): Esto es incorrecto. La dependencia del orden se aplica a todas las funciones de offset. offset() depende del orden de las filas, y pivot_offset() depende del orden de las columnas pivotadas. En ambos casos, necesitas ver el resultado primero para saber cuál es ese orden.

Answer 1213

B Pivoting in Looker allows you to display the aggregation of your data broken out by the unique values of a selected dimension, creating a matrix similar to a pivot table in spreadsheets

Answer 1214

A, B y C The four primary types of table calculations in Looker are string, mathematical, logical, and date & time. Network is not a function type in this context

Answer 1215

D ¿Por qué la opción D es la correcta? La opción D es la correcta porque engloba los dos casos de uso más importantes y comunes para los cálculos de tabla (table calculations) en Looker. A. Prototipar una nueva dimensión o medida Esta es una de las grandes ventajas de los cálculos de tabla. Imagina que un analista de negocio quiere crear un nuevo indicador (KPI), como por ejemplo, el "beneficio por cliente" (ingresos−costes). Sin cálculos de tabla: Tendría que pedirle a un desarrollador de Looker que modifique el código LookML, añada la nueva medida, la pruebe y la ponga en producción. Este proceso puede tardar horas o días. Con cálculos de tabla: El propio analista puede crear esta nueva métrica directamente en su informe (en la sección "Explore") en cuestión de segundos. Esto le permite validar si el nuevo cálculo es útil y aporta valor antes de solicitar que se incorpore de forma permanente al modelo de datos. Es, por tanto, una herramienta perfecta para prototipar y experimentar. B. Dar soporte a un conjunto de resultados Esta afirmación, aunque un poco abstracta, se refiere a que los cálculos de tabla operan sobre los datos que ya han sido devueltos por la consulta a la base de datos. Es decir, trabajan con el "conjunto de resultados" que ves en la tabla de tu informe. Esto permite hacer cálculos que serían muy difíciles o imposibles de realizar a nivel de fila en la base de datos, ya que necesitan el contexto de las otras filas. Ejemplos clásicos incluyen: Porcentaje del total: Calcular qué porcentaje representa cada fila del total de una columna. Acumulados (Running Total): Sumar el valor de una fila con todas las anteriores. Diferencia con la fila anterior: Calcular el crecimiento o decrecimiento entre un periodo y el anterior. Todos estos cálculos necesitan ver la tabla completa de resultados para poder funcionar. ¿Por qué las otras opciones son incorrectas? A y B (por separado): Aunque ambas son correctas, son incompletas por sí solas. La pregunta pide los "casos de uso comunes" (en plural), y tanto el prototipado como los cálculos sobre el conjunto de resultados lo son. Por lo tanto, la opción que incluye ambas (D) es la más completa y correcta. C. Para modificar permanentemente el esquema de la base de datos subyacente: Esta opción es fundamentalmente incorrecta. Looker es una plataforma de Business Intelligence que, en su operativa normal, solo lee datos de la base de datos. Los cálculos de tabla se ejecutan después de que Looker haya recibido los datos de la consulta. Viven y mueren dentro del informe de Looker y no tienen absolutamente ningún efecto sobre la estructura (esquema) o los datos almacenados en la base de datos original. Alterar la base de datos desde Looker es conceptualmente erróneo y va en contra de sus principios de funcionamiento.

Answer 1216

C The pivot_offset() function is specifically designed to reference values from adjacent columns in a pivoted table, making it ideal for calculations like year-over-year comparisons

Answer 1217

B Table calculations are “on-the-fly” metrics that run only on your query results and do not affect the underlying database. They can be saved to Looks or dashboards if needed

Answer 1218

D Pivoting in Looker transforms the unique values of a dimension into their own columns. To get a column for each quarter, you must pivot on the dimension that contains the quarter values, which is "Order Quarter." You can only pivot on dimensions, not measures.

Answer 1219

B As stated in the presentation (e.g., slide 18), table calculations are "on-the-fly" metrics. Their key characteristic is that they run after the initial SQL query is complete and operate exclusively on the results present in the data table of the Explore. They are not saved to the LookML model unless a developer explicitly adds them, and they support a wide range of functions, including logical, date, and string manipulations.

Answer 1220

C 🎯 Objetivo Queremos, para cada fila (cada mes), obtener el valor del mes anterior, es decir, el valor que está una posición antes en el orden temporal. En Looker / LookML, la función offset() permite acceder a valores de otras filas relativas a la fila actual, lo cual es exactamente lo que se necesita para calcular cambios mes a mes (MoM). 🔹 ¿Cómo funciona offset()? offset(${campo}, N) N = 1 → Devuelve el valor de la fila anterior N = -1 → Devuelve el valor de la fila siguiente 👉 Por tanto, offset(${users.count}, 1) devuelve el recuento de usuarios del mes anterior (una fila antes), lo que te permite hacer cálculos como: (${users.count} - offset(${users.count}, 1)) / offset(${users.count}, 1) = crecimiento porcentual mes a mes. ❌ POR QUÉ LAS OTRAS SON INCORRECTAS: A. pivot_offset(${users.count}, -1) ❌ Esta función solo se usa en tablas dinámicas (pivots), no en tablas normales. pivot_offset sirve para obtener valores de una columna pivoteada adyacente, no de una fila anterior. Aquí, la tabla no está pivoteada por mes, solo tiene una columna "Created Month". Por tanto, no hay pivote, y esta función no aplicaría. ✅ Se usaría si tuvieras los meses como columnas (pivot), pero no es el caso aquí. B. offset_list(${users.count}, -1, 1) ❌ offset_list() devuelve una lista de valores (por ejemplo, una ventana o rango de filas), no un único valor. En este caso, quieres solo el valor del mes anterior, no una lista. Además, el orden de los argumentos es distinto: offset_list(${campo}, offset, length) devuelve una lista de valores, empezando en offset y con longitud length. Si luego quisieras usarlo en un cálculo, necesitarías agregar esa lista (por ejemplo, con mean o sum), lo cual no tiene sentido aquí. Por tanto, no es apropiado para un cálculo fila a fila. D. mean(${users.count}) ❌ Esto calcula la media (promedio) de todos los valores de ${users.count}. No está relacionada con el desplazamiento (offset). No devuelve el valor del mes anterior, sino una única media global o por partición. No puedes calcular el cambio mes a mes usando una media. Por tanto, no sirve para el objetivo.

Answer 1221

C The presentation emphasizes this best practice (e.g., slide 81, 122). The sort order of the results table directly impacts the logic of an offset. For example, if data is sorted descending by date, a positive offset (+1) is needed to look at the previous time period. If sorted ascending, a negative offset (-1) would be required. Running the query first allows the user to see this sort order and write the correct formula.

Answer 1222

B As shown on slides 36 and 37, the correct method is to use the gear icon in the column header of the results table. This provides an option to "Hide from Visualization," which removes the field from the chart but keeps it available in the underlying data table, ensuring that any table calculations dependent on it continue to function correctly. Deleting the fields from the picker would remove them from the SQL query entirely.

Answer 1223

B Pivoting in Looker transforms a selected dimension into multiple columns, creating a matrix for analyzing metrics by different groupings, such as counts by category.

Answer 1224

C Looker’s table calculations include string, mathematical, logical, and date/time functions, but not a "database" type, as they operate on query results, not database operations.

Answer 1225

C Para calcular una media móvil (rolling average), necesitas tomar los valores de varias filas a la vez (la fila actual y un número de filas anteriores) y promediarlos. offset_list() es la función diseñada específicamente para este propósito en las "Table Calculations" de Looker. ¿Por qué la Opción C es la Correcta? ✅ La función offset_list() devuelve una lista (un conjunto) de valores de un campo, tomados de un rango de filas relativas a la fila actual. Una vez que tienes esa lista, puedes pasarla a otra función, como mean() o average(), para calcular el promedio. Así es como se vería el cálculo de una media móvil de 3 periodos: mean(offset_list(${sales}, -2, 3)) ${sales}: Es la medida que quieres promediar. -2: Es el "offset" de inicio. Indica que la lista debe empezar a recoger valores 2 filas antes de la actual. 3: Es la "longitud". Indica que la lista debe contener 3 valores en total (la de 2 filas antes, la de 1 fila antes y la de la fila actual). La función offset_list() te da la lista [valor_fila-2, valor_fila-1, valor_fila_actual], y mean() calcula el promedio de esa lista. Es la forma estándar y eficiente de hacerlo. ¿Por qué las Otras Opciones son Incorrectas? ❌ A) offset() Esta función devuelve un único valor de una única fila, no una lista. Por ejemplo, offset(${sales}, -1) te daría solo el valor de la fila anterior. Podrías, en teoría, construir una media móvil sumando múltiples llamadas a offset() (ej: (${sales} + offset(${sales}, -1) + offset(${sales}, -2)) / 3), pero es un método manual, ineficiente y difícil de mantener si quieres cambiar el período de la media. No es la herramienta adecuada para el trabajo. B) pivot_offset() Esta función trabaja en horizontal, a través de columnas dinámicas (pivots), no en vertical a través de las filas. Sirve para comparar el valor de una fila con el valor de la misma fila pero en una columna diferente. La pregunta pide explícitamente un cálculo que se mueva a través de múltiples filas.

Answer 1226

B This calculation analyzes proportions, such as the percentage of orders by traffic source relative to the total, aiding in business insights.

Answer 1227

B Hiding unnecessary fields ensures visualizations focus on key metrics, improving clarity and usability for stakeholders.

Answer 1228

B A Look is defined as a single visualization designed to answer one specific data-related question, differentiating it from a dashboard which generally contains multiple visualizations.

Answer 1229

C Only end users with data explorer permissions may create new dashboards in Looker. These permissions are assigned by your Looker administrator

Answer 1230

C Looks are built from the results of a query in an Explore by data explorers. Understanding the components of an Explore is key to assembling a Look

Answer 1231

C Por qué la opción C es la correcta La opción C es la correcta porque representa la base fundamental de cualquier análisis de datos útil, no solo en Looker, sino en cualquier herramienta de Business Intelligence (BI). Proporciona un propósito y dirección: Antes de empezar a arrastrar y soltar campos, necesitas saber qué estás tratando de descubrir. Sin una pregunta clara, es muy fácil perderse en los datos, crear visualizaciones que no tienen sentido o llegar a conclusiones irrelevantes. La pregunta actúa como tu "estrella polar". Ejemplo de una buena pregunta: "¿Cuáles fueron nuestras 5 categorías de productos más vendidas en Europa durante el último trimestre?" Ejemplo de un mal punto de partida (sin pregunta): "Voy a ver qué encuentro en los datos de ventas." Hace el proceso más eficiente: Sabiendo lo que buscas, puedes ir directamente al "Explore" correcto, y seleccionar las dimensiones (ej: Categoría de Producto, Región, Fecha) y las medidas (ej: Total de Ventas) necesarias para responder a tu pregunta. Ahorras tiempo y esfuerzo. Asegura que el resultado sea valioso: Un "Look" (un informe o visualización guardado en Looker) solo es útil si responde a una necesidad del negocio. Empezar con la pregunta garantiza que el resultado final ayudará a alguien a tomar una mejor decisión. Por qué las otras opciones son incorrectas Las otras opciones describen pasos que sí se realizan al crear un Look, pero no son el primer paso recomendado. Ocurren más tarde en el proceso. A. Customize the visualization. (Personalizar la visualización) ¿Por qué es incorrecto? Este es uno de los pasos finales. No puedes personalizar una visualización (elegir si será un gráfico de barras, una línea de tiempo, un mapa, etc.) si todavía no has seleccionado los datos que quieres mostrar. Primero necesitas los datos, y para eso, primero necesitas la pregunta. Orden correcto: Pregunta → Selección de datos → Visualización. B. Select dimensions and measures in an Explore. (Seleccionar dimensiones y medidas en un Explore) ¿Por qué es incorrecto? Esta es, técnicamente, la primera acción que realizas dentro de la interfaz de Looker, pero no es el primer paso conceptual del proceso de análisis. La elección de qué dimensiones y medidas seleccionar depende directamente de la pregunta que te has planteado en el paso C. Si no tienes una pregunta, ¿cómo sabrías qué campos elegir entre las docenas o cientos disponibles? Estarías seleccionando a ciegas. Orden correcto: La pregunta (Paso C) te dice qué dimensiones y medidas seleccionar (Paso B). D. Save the Look to a shared folder. (Guardar el Look en una carpeta compartida) ¿Por qué es incorrecto? Este es claramente el último paso del proceso. Guardas y compartes el "Look" una vez que lo has construido, visualizado y estás satisfecho con el resultado porque responde a tu pregunta inicial. No puedes guardar algo que aún no has creado. Orden correcto: Pregunta → Selección de datos → Visualización → Guardar y compartir. Resumen El flujo de trabajo recomendado para un análisis de datos efectivo en Looker es el siguiente: C. Formula una pregunta de negocio clara y medible. B. Entra en el "Explore" adecuado y selecciona las dimensiones y medidas que necesitas para responder a esa pregunta. A. Elige y personaliza el tipo de visualización que mejor represente la respuesta. D. Guarda el "Look" en una carpeta para poder consultarlo más tarde o compartirlo. Por lo tanto, empezar con una pregunta es el cimiento sobre el que se construye todo lo demás.

Answer 1232

A y B ✅ Opciones Correctas A. By using the "Save fanout menu" option from the top right-hand gear menu of a Look. Esta afirmación es correcta. Este es el método más común cuando estás viendo o editando un Look. Abres el Look que quieres añadir. Haces clic en el icono de engranaje (⚙️) en la esquina superior derecha. En el menú que se despliega, seleccionas "Guardar" (Save). Aparecerá una ventana emergente que te permite guardar los cambios en el Look y, muy importante, te da la opción de añadirlo a uno o varios dashboards, ya sean nuevos o existentes. B. By clicking the "Add to dashboard" link at the extreme right of a Look in the Details panel. Esta afirmación también es correcta, aunque se refiere a un contexto diferente. Cuando estás navegando por las carpetas (Spaces) donde se guardan los Looks, no necesitas abrir cada uno para añadirlo a un dashboard. En la lista de Looks de una carpeta, si pasas el ratón por encima de uno de ellos, aparecen opciones a la derecha. Al hacer clic en el menú de tres puntos (⋮), se despliega una lista de acciones. Una de esas acciones es "Add to Dashboards" (Añadir a Dashboards), que te permite añadir ese Look directamente sin tener que abrirlo primero. El término "Details panel" en la pregunta se refiere de forma un poco imprecisa a esta área de acciones contextuales. ❌ Opciones Incorrectas C. By direct drag-and-drop from the Look list to a dashboard. Esto es incorrecto. La interfaz de Looker no tiene la funcionalidad de "arrastrar y soltar" (drag-and-drop) para mover un Look desde una lista de carpetas y soltarlo en un dashboard. Es una acción que, aunque intuitiva, no está implementada en la plataforma. D. By exporting the Look as a CSV and importing it into a dashboard. Esto es totalmente incorrecto y confunde dos conceptos diferentes. Exportar un Look como CSV te da un archivo estático con los datos de ese momento. Es una simple tabla de datos, sin interactividad ni conexión con la base de datos. Un dashboard de Looker contiene "paneles" o "tarjetas" (tiles) que son dinámicos e interactivos, ejecutando consultas en tiempo real. No puedes "importar" un archivo CSV para crear uno de estos paneles dinámicos.

Answer 1233

C A Look is a single visualization meant to answer one specific data-related question.

Answer 1234

A, B y D La explicación correcta Un "Look" es el resultado de una consulta ("Explore") que ha sido guardada. Para "ensamblar" la consulta que vas a guardar como un Look, interactúas con tres componentes principales en la interfaz de "Explore": A) Dimensiones: Los campos por los que agrupas. (Obligatorio) B) Medidas: Los campos que agregas (sumas, cuentas, etc.). (Obligatorio) D) Filtros: La sección donde acotas los datos (por ejemplo, por fecha, región, etc.). Aunque técnicamente podrías guardar un Look sin filtros explícitos, la sección de Filtros es un componente fundamental y requerido de la propia consulta. De hecho, Looker casi siempre añade un filtro de fecha por defecto. La consulta que se guarda como un "Look" está compuesta por las dimensiones, medidas y filtros seleccionados. Por lo tanto, los tres son componentes que "ensamblas" para crear el Look. Por qué C es incorrecta C) User roles (Roles de usuario): Sigue siendo incorrecto. Los roles son parte de la administración y control de acceso (quién puede ver el Look), pero no son un ingrediente que usas para construir la consulta del Look.

Answer 1235

A y C ¿Por qué la A y la C son las "buenas"? A. From the Explore page using the Save fanout menu (Desde la página de Exploración usando el menú de Guardar): Cuando estás visualizando un Look o explorando datos, en la esquina superior derecha encuentras el ícono del engranaje (o el botón "Save/Guardar"). Al hacer clic, se despliega un menú ("fanout menu") que te da la opción "Save to Dashboard" (Guardar en panel). Esta es la forma más común de enviar lo que estás viendo directamente a un dashboard existente o a uno nuevo. C. By using the “Add to dashboard” link in the Look's Details panel (Usando el enlace "Add to dashboard" en el panel de detalles del Look): Cuando navegas por tus carpetas y seleccionas un Look, a la derecha suele aparecer un panel de información o "Detalles" (si no lo ves, a veces es un ícono de "i"). En este panel existe un enlace directo o botón que dice "Add to Dashboard". Es un atajo muy útil para añadir un reporte guardado sin tener que abrirlo completamente o editar el dashboard primero. ¿Por qué las demás son las "malas"? B. By modifying user access in the Admin panel (Modificando el acceso de usuario en el panel de Administración): El panel de administración es para gestionar permisos, roles y conexiones a bases de datos. No tiene ninguna funcionalidad para mover contenido o añadir gráficos a un dashboard. D. From the Folder settings menu (Desde el menú de configuración de la Carpeta): El menú de configuración de una carpeta te permite renombrarla, moverla o cambiar quién tiene acceso a ella. No sirve para tomar un Look específico que está dentro y "enviarlo" a un dashboard.

Answer 1236

A Looks are designed for one visualization; dashboards can contain multiple to answer broader questions.

Answer 1237

C Only users with data explorer permissions can create dashboards in Looker.

Answer 1238

C Looks are created from an Explore, where users select dimensions, measures, filters, and pivots to answer a specific data question

Answer 1239

B A Look is a stand-alone report designed to answer one specific data question, unlike dashboards that combine multiple visualizations

Answer 1240

A Only users with data explorer permissions can create new dashboards in Looker. These permissions are assigned by the Looker administrator

Answer 1241

A y C Por qué las Opciones A y C son CORRECTAS A. Usando el menú "Save" (Guardar) desde el ícono de engranaje Por qué es buena: Esta es la forma más común de añadir contenido a un dashboard. Cómo funciona: Cuando estás en un "Explore" y acabas de crear una visualización, o cuando estás viendo un "Look" (una visualización ya guardada), hay un ícono de engranaje (⚙️) en la esquina superior derecha. Al hacer clic allí, se despliega un menú (el "fanout menu") que incluye la opción "Save..." (Guardar...) o "Add to dashboard" (Añadir a dashboard). Si eliges "Save...", una de las opciones que te da es guardarlo directamente en un dashboard nuevo o existente. C. Haciendo clic en "Add to dashboard" (Añadir a dashboard) en el panel de Detalles Por qué es buena: Esta es la otra forma principal de hacerlo, que se utiliza cuando no estás viendo el Look, sino que estás navegando por las carpetas donde se guardan los Looks. Cómo funciona: Vas a la carpeta (Folder) que contiene el Look que quieres añadir. Al lado del nombre del Look, hay un menú (normalmente un ícono de tres puntos ⋮) que abre las opciones o un panel de "Details" (Detalles) para ese Look. En ese menú, encontrarás la opción "Add to dashboard", que te permite añadir ese Look a cualquier dashboard que elijas sin tener que abrir el Look primero. Por qué las Opciones B y D son INCORRECTAS B. Arrastrando y soltando desde la carpeta Por qué es mala: Esto es incorrecto porque la interfaz de usuario de Looker (la plataforma principal) no admite esta funcionalidad. Aunque "arrastrar y soltar" (drag and drop) es muy común en otras herramientas de BI (como Looker Studio o Tableau), no es una forma válida de añadir un Look desde una carpeta a un lienzo de dashboard en Looker. D. Exportando a CSV y re-importando Por qué es mala: Esta opción no tiene ningún sentido en este contexto. Exportar a CSV te da un archivo de datos sin formato (texto plano). No hay ninguna función en Looker para "re-importar" un archivo CSV y que se convierta en una visualización o un mosaico (tile) dentro de un dashboard. Este proceso es para extraer datos, no para construir dashboards.

Answer 1242

B A Look answers one specific question with a single visualization, while a dashboard combines several visualizations to answer multiple questions

Answer 1243

B Pivoting is the standard Looker feature used to turn a dimension's values (in this case, the years) into columns. This creates a matrix where rows are the months and columns are the years, which is the perfect structure for a year-over-year comparison in a single chart, as shown on slide 8 of the presentation.

Answer 1244

B As defined in the presentation (slides 3, 4, and 14), a Look is a single, stand-alone report designed to answer one specific question. A Dashboard is used to combine multiple visualizations (tiles) to provide a comprehensive overview of various metrics, which aligns perfectly with the two requests.

Answer 1245

A y C The gear icon in the top right of an Explore provides options to save the query and its visualization. As shown on slide 11 and 15, an explorer can choose to save the results as a new Look (a single report) or as the first tile on a new dashboard. Sending and sharing a URL are ways to distribute the content, but not to save it as a permanent, named object within Looker's folder structure.

Answer 1246

D Slide 10 explicitly shows this action. The Edit menu, which is part of the visualization's own settings bar (not the main gear icon for the whole page), contains options for customizing the plot, series, and values. This is where formatting options like line interpolation, colors, and labels are configured.

Answer 1247

B The presentation (slide 4) and quiz (slides 21 and 25) clarify that Looks and dashboards are created from an Explore. The ability to use an Explore to build queries, select fields, and save the results is a core capability of the "data explorer" role. Data viewers can consume and interact with existing content but cannot create new Looks or dashboards from the Explore interface.

Answer 1248

B A Look is defined as a single visualization that answers one specific question about the data, distinguishing it from dashboards, which contain multiple visualizations.

Answer 1249

B Data explorers have the necessary permissions to create Looks by working with data in Explores, while data viewers can only view existing content.

Answer 1250

D Dashboards can be created by saving a single Look to a new dashboard or by adding multiple Looks, making both options A and B valid methods.

Answer 1251

B ✅ Respuesta Correcta B. Para crear una matriz para la visualización La función de "pivot" (o pivotar) en Looker, y en muchas otras herramientas de análisis de datos, consiste en tomar los valores de una columna y convertirlos en nuevas columnas. El objetivo principal es reorganizar la tabla de datos para crear una matriz o tabla de doble entrada. ¿Por qué es bueno? 📈 Esto es especialmente útil para comparar valores entre diferentes categorías de una manera más visual y compacta. Imagina que tienes datos de ventas por mes y por categoría de producto. Sin pivotar: | Mes | Categoría | Ventas | |---|---|---| | Enero | Ropa | 1000 | | Enero | Electrónica | 1500 | | Febrero | Ropa | 1200 | | Febrero | Electrónica | 1300 | Pivotando por "Categoría": | Mes | Ropa (Ventas) | Electrónica (Ventas) | |---|---|---| | Enero | 1000 | 1500 | | Febrero| 1200 | 1300 | Como ves, se ha creado una matriz que es mucho más fácil de leer y de usar para crear gráficos de barras apiladas, mapas de calor u otras visualizaciones comparativas. ❌ Respuestas Incorrectas A. Para filtrar los datos Filtrar es el proceso de seleccionar un subconjunto de datos que cumple con ciertos criterios (por ejemplo, mostrar solo las ventas del mes de enero o solo de la categoría "Ropa"). Aunque es una acción fundamental en el análisis, no tiene que ver con la reorganización estructural que hace el pivotaje. Diferencia clave: Filtrar reduce el número de filas; pivotar reorganiza las filas en columnas. C. Para ordenar los datos Ordenar (sort) consiste en organizar las filas de la tabla según un criterio, como por orden alfabético, de mayor a menor valor o por fecha. Es simplemente cambiar el orden de presentación de los datos existentes. Diferencia clave: Ordenar cambia la secuencia de las filas; pivotar cambia la estructura de la tabla. D. Para agregar los datos Agregar (aggregate) es el proceso de calcular un valor único a partir de un conjunto de valores, como una suma (SUM), un promedio (AVERAGE), un conteo (COUNT), etc. Aunque el pivotaje utiliza una agregación para saber qué valor numérico poner en las nuevas celdas (por ejemplo, la suma de ventas), el propósito principal del pivotaje no es la agregación en sí, sino la transformación de la estructura de la tabla. Diferencia clave: La agregación resume datos dentro de una columna; el pivotaje usa esa agregación para rellenar una nueva estructura de columnas.

Answer 1252

D A Look can be saved as a personal Look, in a shared folder, or added to a dashboard, but it cannot be saved as an Explore, as an Explore is the starting point for building a Look.

Answer 1253

B In Looker, the process of sharing or exporting content with others is explicitly referred to as "data delivery". This encompasses various methods for getting data out of Looker, whether it's a Look, an Explore, or a dashboard

Answer 1254

A Looks can be downloaded in several file formats for one-time export, including CSV, a ZIP file containing one or more CSVs, PDF, or PNG. The PDF and PNG options behave like a screenshot image. This functionality is available for end-users, though a Looker administrator may have it disabled

Answer 1255

C Respuesta Correcta: C. Looks have a dedicated "Send" menu command, while dashboards achieve one-time sending functionality through the "Schedule delivery" dialog (Los Looks tienen un comando de menú "Enviar" dedicado, mientras que los dashboards logran la funcionalidad de envío único a través del diálogo "Programar entrega"). Esta es la respuesta correcta porque describe con precisión una sutil pero importante diferencia en la interfaz de usuario de Looker. En un Look (una sola visualización o tabla guardada): Si vas al menú de configuración (el ícono del engranaje ⚙️), verás tres opciones distintas y claras: "Descargar", "Enviar" y "Programar". La opción "Enviar" está diseñada específicamente para una entrega única e inmediata. En un Dashboard (un conjunto de visualizaciones): Si vas al menú de configuración (el ícono de tres puntos ⋮), no encontrarás una opción directa de "Enviar". Para hacer un envío único, debes seleccionar "Programar entrega". Dentro de la ventana de programación, puedes configurar todos los detalles y luego usar el botón "Enviar prueba" para realizar ese envío único e inmediato. La funcionalidad existe, pero se accede a ella a través del flujo de trabajo de programación. Por lo tanto, la distinción clave es el punto de entrada en el menú: los Looks tienen un botón directo para enviar, mientras que los Dashboards "esconden" esa función dentro del diálogo de programación. Respuestas Incorrectas A. Looks can only be sent via email, while dashboards can be sent to Google Drive or Amazon S3 (Los Looks solo se pueden enviar por correo electrónico, mientras que los dashboards se pueden enviar a Google Drive o Amazon S3). Esto es incorrecto. Tanto los Looks como los Dashboards se pueden enviar a los mismos destinos (email, webhooks, Amazon S3, Google Drive, etc.), siempre que el administrador de Looker los haya habilitado. El tipo de destino no es una diferencia entre ellos. B. Dashboards have a dedicated "Send" menu command, whereas Looks use "Schedule" for one-time sending (Los dashboards tienen un comando "Enviar", mientras que los Looks usan "Programar" para un envío único). Esto es incorrecto porque es exactamente al revés de la realidad. Los Looks tienen el comando "Enviar" dedicado, y los Dashboards utilizan el diálogo de "Programar". D. Sending is not an option for Looks; it's exclusively available for dashboards (Enviar no es una opción para los Looks; está disponible exclusivamente para los dashboards). Esto es completamente falso. La capacidad de enviar y programar entregas de datos es una característica fundamental tanto para los Looks como para los Dashboards.

Answer 1256

C Alerts in Looker are created on dashboard tiles that include at least one numeric measure or table calculation within their visualization. Only one such element is required in most cases to create a tile-level dashboard alert.

Answer 1257

A, B y D Por qué A, B y D son correctas ✅ Un correo de alerta de Looker está diseñado para ser una notificación rápida, informativa y accionable. Su objetivo es darte toda la información clave de un vistazo para que decidas si necesitas investigar más a fondo. Por eso incluye: A. Un enlace al dashboard... (A link to the dashboard...): Esto es fundamental. Si la alerta te notifica un problema o un hito importante, lo primero que querrás hacer es ir al dashboard para ver el contexto completo. El enlace te permite navegar directamente al lugar relevante con un solo clic. B. El valor que disparó la alerta (The value that triggered the alert): Esta es la información más importante. La alerta no solo te dice que "las ventas bajaron", sino que te dice "las ventas bajaron a $8,500", que es el valor que cruzó el umbral que tú definiste. Sin este valor, la alerta sería muy poco útil. D. La visualización del tile... (The visualization for the tile...): Una imagen vale más que mil palabras. El correo incluye una captura de pantalla del gráfico o la tabla del tile. Esto te da un contexto visual inmediato. Puedes ver la tendencia, el pico o la caída sin siquiera tener que hacer clic en el enlace. Por qué C es incorrecta ❌ C. La tabla de datos subyacente completa (The full underlying data table...): Incluir la tabla de datos completa es totalmente inviable y contrario al propósito de una alerta. Tamaño: La tabla subyacente podría tener miles o millones de filas. Adjuntar o incrustar esa cantidad de datos en un correo electrónico lo haría gigantesco y poco práctico. Seguridad: Enviar tablas de datos completas, que pueden contener información sensible, por correo electrónico es una mala práctica de seguridad. Utilidad: Una alerta debe ser un resumen conciso, no un volcado de datos (data dump). Si necesitas los datos subyacentes, para eso está el enlace del punto A, que te lleva a Looker donde puedes explorar los datos de forma segura e interactiva.

Answer 1258

A, B y D Looks can be downloaded in formats such as CSV, ZIP (with multiple CSVs), PDF, and PNG. HTML is not supported for downloads.

Answer 1259

D Pinning to a board is a way to organize content, but not a method for sharing or scheduling data delivery.

Answer 1260

C Sending a link ensures the recipient views the dashboard in Looker with the most up-to-date data, as opposed to static file formats like PDF or CSV.

Answer 1261

B Alerts require at least one numeric measure or table calculation in the tile's visualization to evaluate thresholds.

Answer 1262

C Scheduled deliveries allow customization of file format (e.g., PDF, PNG, ZIP), filter values, and delivery timezone, and optionally allow a custom message.

Answer 1263

B o C, ambas darlas por buenas La opción más directa para que un analista de negocios envíe una instantánea estática de un Looker Dashboard a un stakeholder externo que no tiene una cuenta de Looker, y que la entrega ocurra solo una vez, es la Opción C. From the dashboard's menu, select the "Send" option to open the one-time delivery dialog. o, de manera equivalente si se utiliza la opción de programación para un envío inmediato: Opción B. From the dashboard's menu, select "Schedule delivery", and in the Recurrence section, choose "Send now". Análisis de las opciones: La entrega de datos (data delivery) es el proceso de compartir o exportar contenido desde Looker. * Opción B y C (Entrega programada / Envío): Para los dashboards, la función de entrega se gestiona a través del menú "Schedule delivery" (Programar entrega). Al seleccionar esta opción, se abre una ventana de configuración. ◦ Para enviar el dashboard una sola vez (un "one-time delivery" o una "snapshot"), se utiliza la opción dentro de la configuración de la programación. ◦ La opción "Schedule delivery" (Opción B) permite configurar la frecuencia ("Recurrence"). Si se elige "Send now" (Enviar ahora) o se define una frecuencia con una hora de inicio inmediata y sin repetición, se logra la entrega única. ◦ La Opción C, que menciona seleccionar la opción "Send" (Enviar) para abrir el diálogo de entrega única, describe la funcionalidad de enviar datos una sola vez que está disponible en Looker. Aunque la interfaz del dashboard para la entrega se suele denominar "Schedule delivery", este flujo es el camino directo para configurar una entrega puntual de un archivo estático (como PDF o CSV), que funciona como una instantánea. ◦ Dado que el stakeholder es externo y no tiene cuenta, se necesita enviar un archivo de datos exportado (una instantánea) a través de un destino como el correo electrónico, en lugar de un enlace en vivo. * Opción A (Usar el "Get link"): Usar la opción "Get link" proporciona la URL del dashboard. Al enviar solo el enlace, el destinatario accede a la plataforma de Looker. Aunque en Looker se puede compartir un informe con permiso de vista sin requerir un inicio de sesión, el envío de una URL es la forma de compartir el dashboard en vivo con los números más actualizados, no de proporcionar una instantánea estática de forma directa. * Opción D (Añadir como usuario): Añadir al stakeholder como usuario de Looker y otorgarle acceso de solo lectura no es la forma más directa, ya que implica tareas administrativas (gestionar el acceso de usuarios a la cuenta). La Opción B ("Schedule delivery" y elegir "Send now") es el mecanismo operativo para lograr el objetivo directamente dentro de las funciones de entrega de Looker para dashboards. La Opción C describe de forma conceptual la acción de "Enviar" una vez que se accede a este diálogo, pero es menos precisa sobre la navegación del menú del dashboard. Sin embargo, en el contexto de las opciones ofrecidas, ambas B y C apuntan a la funcionalidad correcta. Siendo estrictos, la acción de programar la entrega para que se envíe inmediatamente (Opción B) es el procedimiento más directo.

Answer 1264

D Por qué la D es la respuesta correcta El propósito fundamental de una alerta es monitorizar un número y notificarte cuando ese número cruza un umbral específico (por ejemplo, "alertarme si las ventas son mayores que 1000" o "si el porcentaje de error es menor que 5%"). Para que el sistema de alertas pueda funcionar, necesita un valor numérico que "vigilar". Este valor numérico es lo que la pregunta llama: Medida numérica (numeric measure): Un campo agregado de tu consulta, como SUM(ventas), COUNT(usuarios), AVG(precio), etc. Cálculo de tabla (table calculation): Un cálculo personalizado que realizas sobre los resultados de la consulta, como un percent_change() (cambio porcentual) o running_total() (total acumulado). Si tu mosaico (tile) solo contiene dimensiones de texto (como una lista de nombres de clientes), el sistema de alertas no tiene ningún número que pueda comprobar contra un umbral. Por lo tanto, tener al menos un valor numérico es el requisito previo mandatorio. Por qué las otras respuestas son incorrectas A) El mosaico debe contener al menos una dimensión y un pivote (pivot): Incorrecto. Un "pivote" (pivotar datos, similar a una tabla dinámica) es una forma específica de mostrar datos, pero no es en absoluto necesario para una alerta. Puedes crear una alerta en un gráfico de valor único (que no tiene dimensiones ni pivotes) o en un gráfico de líneas simple (que tiene una dimensión y una medida, pero no pivotes). B) El tipo de visualización del mosaico debe ser un Valor Único (Single Value): Incorrecto. Aunque es extremadamente común poner alertas en mosaicos de "Valor Único" (porque muestran KPIs clave como "Ventas Totales"), no es el único tipo. También puedes crear alertas en gráficos de líneas, gráficos de área y tablas (generalmente para monitorizar el valor más reciente o un total). C) El mosaico debe basarse en una consulta que incluya una dimensión de fecha o tiempo: Incorrecto (y el distractor más común). Es cierto que muchas alertas, especialmente en gráficos de series temporales (como un gráfico de líneas), requieren una dimensión de tiempo. Esto se debe a que la alerta necesita saber qué punto de datos comprobar (casi siempre, el más reciente). Sin embargo, no es un requisito universal. Si tienes un mosaico de "Valor Único" que muestra "Inventario Total Actual", la consulta se ejecuta en un horario (ej. cada hora) y comprueba ese número. La consulta en sí no necesita incluir una dimensión de fecha para que la alerta funcione; solo necesita producir el número que se va a monitorizar (la opción D).

Answer 1265

C Por qué la Opción C es la Correcta C. Alerta Categórica (Categorical alert) Esta es la respuesta correcta porque el tipo de alerta coincide con la estructura de los datos en el "tile" (la visualización). Estructura de Datos: El tile muestra una métrica ("Count of Products") dividida por una dimensión ("Product Category"). Esto significa que el tile no muestra un solo número, sino una lista de números, uno por cada categoría. Electrónica: 500 Ropa: 700 Hogar: 1001 Lógica de la Alerta: El objetivo es que la alerta se dispare si alguna de esas categorías supera las 1.000. Un sistema de alertas como el de Looker necesita saber cómo evaluar los datos. En este caso, debe aplicar la condición (> 1000) a cada fila (cada categoría) de los resultados. Este tipo de alerta, que itera sobre una dimensión o categoría, se conoce como alerta categórica. Se dispara si alguna de las categorías cumple la condición. Por qué las Otras Opciones son Incorrectas A. Alerta de Valor Único (Single Value alert) Incorrecto: Este tipo de alerta se usa cuando el tile muestra un solo número (un KPI), por ejemplo, el "Conteo Total de Productos" (sumando todas las categorías). En ese caso, la alerta vigilaría si ese único número supera el umbral. El tile del problema muestra múltiples valores, no uno solo. B. Alerta de Serie Temporal (Time Series alert) Incorrecto: Este tipo de alerta se usa para rastrear una métrica a lo largo del tiempo. Por ejemplo, si el tile mostrara el "Conteo de Productos por Día". La pregunta no menciona ninguna dimensión de tiempo; solo muestra categorías en un momento dado. D. Alerta Condicional (Conditional alert) Incorrecto: Este término es demasiado genérico. Todas las alertas (de valor único, de serie temporal, y categóricas) son "condicionales" por naturaleza. Se disparan basadas en una condición (ej. si valor > 1000). Este término no describe el tipo específico de datos que la alerta está evaluando, que es lo que la distingue de las otras (categórica vs. serie temporal vs. valor único).

Answer 1266

B As explained on slides 5 and 12-13, "Download" extracts the data as a static file (like a CSV, PNG, or PDF) to your computer. In contrast, "Share" provides a URL. When a user with the correct permissions opens this URL, they see the most recent data by running the query live. "Schedule" is used for recurring deliveries, not "Share".

Answer 1267

B y C ✅ Las Respuestas Correctas (B y C) La pregunta establece dos hechos clave: 1) La alerta es pública y 2) el usuario quiere "seguir" la alerta (es decir, suscribirse él mismo). Para que un usuario pueda suscribirse a una alerta pública, debe cumplir estas dos condiciones fundamentales: B. El usuario debe tener acceso al dashboard donde la alerta está ubicada. Por qué es correcta: Una alerta está asociada a un tile (un gráfico o tarjeta) dentro de un dashboard específico. Si un usuario no tiene permiso para ver el dashboard, no puede ver ninguno de los elementos que contiene. Es imposible "seguir" una alerta si ni siquiera puedes navegar al lugar donde vive. El acceso al contenedor (el dashboard) es el primer requisito indispensable. C. El usuario debe tener el permiso específico de Looker para ver y seguir alertas. Por qué es correcta: Las plataformas de Business Intelligence como Looker funcionan con un sistema de permisos muy granular. Un usuario podría tener permiso para ver un dashboard, pero no tener permiso para interactuar con las funciones de alerta. Si el administrador de Looker no le ha concedido al usuario el rol o permiso específico (como follow_alerts), el botón para "Seguir" la alerta simplemente no le aparecerá o estará desactivado. Un usuario necesita ambas: poder llegar al dashboard (B) y tener el derecho de interactuar con la función de alertas (C). ❌ Las Respuestas Incorrectas (A y D) A. El usuario debe ser el propietario del dashboard. Por qué es incorrecta: Ser propietario (owner) es un permiso mucho más elevado, generalmente necesario para editar, configurar o eliminar el dashboard. La propia pregunta dice que la alerta fue creada por "un colega" y es "pública", lo que implica que está diseñada para que otros usuarios (no propietarios) puedan consumirla y seguirla. No necesitas ser el dueño de un dashboard para seguir una alerta pública en él. D. El usuario debe tener su dirección de email añadida a la lista de receptores por el propietario. Por qué es incorrecta: Esta opción confunde dos acciones diferentes: Seguir (Follow): Es una acción pull (el usuario se suscribe a sí mismo). Ser añadido (Added): Es una acción push (el creador de la alerta añade el email de alguien a la lista de distribución). La pregunta trata sobre lo que necesita el usuario para "seguir" la alerta (acción 1). Si el propietario ya hubiera añadido su email (acción 2), el usuario recibiría la alerta automáticamente y no necesitaría "seguirla". Por lo tanto, esto no es un requisito para poder seguirla.

Answer 1268

A Looks can be downloaded in CSV, ZIP (containing multiple CSVs), PDF, or PNG formats, as outlined in the module.

Answer 1269

A Tile-level alerts require a numeric measure or table calculation to define alert conditions, as specified in the module.

Answer 1270

D Scheduling a Look allows specification of frequency, time, and destination, ensuring flexible delivery options.

Answer 1271

A Users can follow public alerts created by others, provided they have access to the dashboard, as noted in the module.

Answer 1272

B Looker is described as a Business Intelligence (BI) software and big data analytics platform that helps business users explore, analyze, and share real-time data analytics easily. It operates as a browser-based, Software as a Service (SaaS) platform that connects directly to SQL databases, including other SaaS applications, transactional databases, business planning tools, and web analytics products.

Answer 1273

C LookML is described as an abstraction layer for SQL that developers use to tell Looker what data to use from the connected database and how it should interpret that data. This agile modeling layer allows developers to define the database structure and relationships between tables and columns. As users explore data, Looker automatically generates SQL SELECT queries based on the defined LookML models.

Answer 1274

B y D El Concepto Clave: Modo de Producción vs. Modo de Desarrollo En Looker, todo el modelo de datos (el código LookML) existe en dos "estados" principales: Modo de Producción (Production Mode): Esta es la versión "en vivo", estable y revisada del código. Es la que ven todos los usuarios finales (de negocio) cuando exploran datos, ven dashboards o reciben informes. En este modo, no puedes editar nada. Solo puedes consumir. Modo de Desarrollo (Development Mode): Este es un "sandbox" o un espacio de trabajo personal y aislado que solo los desarrolladores de LookML pueden activar. Cuando entras en "Dev Mode", Looker crea una copia personal (técnicamente, una rama de Git) del modelo de producción para que puedas hacer cambios de forma segura sin afectar a ningún usuario final. Sabiendo esto, analicemos las opciones: Las Respuestas Correctas B) Hacer y probar cambios en el código LookML, como modificar dimensiones existentes o crear nuevos Explores. Por qué es correcta: Esta es la razón principal por la que existe el Modo de Desarrollo. Es el único lugar donde puedes editar archivos .lkml (para añadir una dimensión, cambiar un cálculo, crear una nueva vista, etc.) y luego usar la función "Explorar" para probar inmediatamente si tus cambios funcionan antes de que alguien más los vea. D) Enviar un 'pull request' para revisión de código antes de desplegar los cambios a producción. Por qué es correcta: Este es el paso final del flujo de trabajo en el Modo de Desarrollo. Una vez que has hecho y probado tus cambios (opción B), usas la interfaz de Git integrada en Looker (que solo es visible en Modo de Desarrollo) para hacer "commit" de tus cambios, "push" a tu rama, y finalmente "crear un Pull Request" (PR). Este PR es la solicitud formal para que tus cambios se fusionen con la versión de Producción. Las Respuestas Incorrectas A) Explorar datos y ver dashboards como un usuario de negocio. Por qué es incorrecta: Esta es la definición de usar el Modo de Producción. Los usuarios de negocio (y los desarrolladores cuando no están editando código) operan en este modo para ver la versión estable y final de los datos. C) Acceder a la última versión de producción del modelo de datos. Por qué es incorrecta: Esto también es el Modo de Producción. Cuando inicias sesión en Looker, por defecto siempre estás en el Modo de Producción, viendo la última versión "en vivo" del código que ha sido aprobada.

Answer 1275

D En el flujo de trabajo de Looker (que utiliza Git por debajo), es fundamental entender la diferencia entre "guardar" el trabajo y "publicarlo" para que otros lo vean. La respuesta correcta es la D) Deploying to Production. Aquí tienes la explicación detallada de por qué esta es la respuesta final y por qué las otras son pasos previos o insuficientes: La Respuesta Correcta: D) Deploying to Production Este es el paso definitivo. En Looker, existe una separación estricta entre el Modo de Desarrollo (donde tú trabajas) y el Modo de Producción (donde los usuarios de negocio ven los datos). ¿Por qué es la buena? Aunque hayas guardado y subido tus cambios al repositorio (Git), estos no se aplican al entorno que ven los usuarios finales hasta que pulsas el botón "Deploy to Production". Este paso mueve el código desde tu rama de desarrollo a la rama principal (master/main) que alimenta los dashboards reales de la empresa. ¿Por qué las otras opciones son incorrectas? El flujo de Looker sigue un orden lógico, y las opciones A, B y C son pasos anteriores al final: A) Pulling changes from Production Por qué no: Este suele ser el primer paso (o uno intermedio). Se hace para asegurarte de que no tienes conflictos con el trabajo de otros compañeros antes de empezar o de terminar, pero no publica nada. B) Saving the changes in the LookML file Por qué no: Guardar solo salva el archivo en el editor de texto de tu navegador. Si cierras la sesión sin hacer nada más, nadie más verá esos cambios, ni siquiera Git. Es un paso puramente local y temporal. C) Committing Changes & Pushing Por qué no: Este es el paso que "empaqueta" tus cambios y los envía al servidor de Git (como GitHub o GitLab). Es necesario, pero en Looker, hacer push no significa publicar. Puedes hacer commit y push y que los usuarios de negocio sigan viendo la versión antigua hasta que no ejecutes el "Deploy". El Flujo de Trabajo Completo (Git Workflow en Looker) Para que lo visualices mejor, este es el orden que sigue un desarrollador de LookML: Edit: Modificas el código en Development Mode. Save: Guardas el archivo (Opción B). Validate: Validas que no haya errores de sintaxis. Commit & Push: Creas una "foto" de tus cambios y la envías al repositorio (Opción C). Deploy to Production: El paso final que hace que el cambio sea oficial para todo el mundo (Opción D). Nota clave: Looker simplifica la interfaz. A menudo verás un botón que dice "Commit Changes & Push", y una vez hecho esto, el botón cambia de color y dice "Deploy to Production". Es el último clic necesario.

Answer 1276

C In a Looker-generated SQL query, dimensions selected by business users are listed in the SELECT statement, while measures appear as aggregating functions (like count, sum) in the SELECT statement. The FROM clause identifies the base view of the Explore, and Looker then joins only other views that are needed based on the selected dimensions and measures. Unnecessary views are not joined in the query.

Answer 1277

B The agile modeling layer allows developers to define data models in LookML, enabling users to explore and visualize data through a user-friendly interface without writing SQL code

Answer 1278

A, B y C Looker can connect to a wide range of platforms, including SaaS applications, transactional databases, business planning tools, and web analytics solutions. It is not limited to only SaaS applications.

Answer 1279

B The Looker IDE is an integrated development environment where developers can write, test, and manage LookML code, enabling them to model data and build Explores for business users.

Answer 1280

B Developers must be in Development Mode to write and commit LookML code. Production Mode is read-only for LookML files.

Answer 1281

C The presentation clearly distinguishes between Production Mode (for business users, read-only, main branch) and Development Mode (for developers, editable, separate branch). Enabling "dev mode" is the fundamental first step for a developer to edit LookML code in a safe, isolated environment.

Answer 1282

D or qué la opción D es la correcta D. The query will SELECT from the Order Items table and LEFT JOIN the Users table, with a HAVING clause for the revenue filter. Vamos a desglosar por qué esta es la respuesta exacta: FROM / JOIN: La consulta del usuario incluye una medida (Total Revenue) de la vista Order Items. En Looker, el "Explore" (la consulta) se construye casi siempre partiendo de la vista que contiene las medidas. Por lo tanto, la consulta SQL pondrá FROM Order Items como la tabla base y luego hará un LEFT JOIN a la tabla Users para obtener las dimensiones State y City. WHERE vs. HAVING (El punto clave): Esta es la parte más importante. Total Revenue es una Medida (Measure). En SQL, las medidas se calculan usando funciones de agregación (como SUM(), COUNT(), AVG()). La cláusula WHERE se usa para filtrar filas antes de que se realice la agregación (antes del GROUP BY). La cláusula HAVING se usa para filtrar grupos después de que se haya calculado la agregación. Como el filtro (Total Revenue > 1000) se aplica sobre el resultado de la medida (un SUM()), Looker debe usar una cláusula HAVING. La consulta SQL generada se vería así: SELECT users.state, users.city, SUM(order_items.sale_price) AS total_revenue FROM order_items LEFT JOIN users ON order_items.user_id = users.id GROUP BY 1, 2 HAVING SUM(order_items.sale_price) > 1000 -- <- HAVING, no WHERE Por qué las otras opciones son incorrectas A y B (WHERE clause): Son incorrectas porque ambas afirman que se usará una cláusula WHERE. Esto fallaría en SQL, ya que no se puede usar WHERE para filtrar el resultado de una función de agregación (medida). C (FROM Users table): Es incorrecta porque identifica la tabla Users como la tabla base (FROM). Esto es ineficiente y no es la forma en que Looker construye las consultas. Looker parte de la vista que define el "Explore", que es la que contiene los hechos y las medidas (en este caso, Order Items).

Answer 1283

C The presentation outlines a multi-step Git workflow (slides 65-74). "Commit & Push" sends the validated code from the developer's personal branch to the remote repository (e.g., on GitHub), making it available for collaboration or review. However, it is the final "Deploy to Production" step that actually merges these changes into the main branch that all business users access, making the changes live.

Answer 1284

B The core of Looker's "single source of truth" is the LookML model. By defining metrics (like what constitutes "revenue" or a "new user") a single time in the LookML code, developers ensure that every user across the entire platform who uses that metric is using the exact same calculation. This prevents the inconsistency that arises when different people write their own slightly different queries for the same concept.

Answer 1285

D Respuesta Correcta: D. The Find and Replace tool (La herramienta de Buscar y Reemplazar) Esta es la respuesta correcta porque la herramienta de Buscar y Reemplazar está diseñada específicamente para hacer justo lo que pide la pregunta: buscar una cadena de texto (como el nombre de una dimensión, por ejemplo, dimension: user_id) en todos los archivos del proyecto a la vez. Piensa en ello como usar "Ctrl + F" o "Cmd + F" en un navegador web, pero a lo grande. En lugar de buscar solo en la página que estás viendo, esta herramienta del IDE de Looker busca en absolutamente todos los archivos del proyecto. Te mostrará una lista de cada lugar donde se menciona esa dimensión, permitiéndote ver su uso en diferentes vistas, explores, o modelos. Es la forma más directa y eficiente de rastrear dónde se utiliza un campo. 🕵️‍♂️ Respuestas Incorrectas A. The Object Browser (El Explorador de Objetos) El Explorador de Objetos es útil para ver la estructura de tu proyecto. Te muestra una lista de todos los modelos, explores, vistas y campos que existen. Puedes usarlo para encontrar rápidamente la definición de una dimensión y saltar al archivo donde está declarada, pero no te muestra todos los demás lugares donde se usa o se hace referencia a esa dimensión. Es como un índice de un libro (te dice en qué página empieza un capítulo), pero no te dice en qué otras páginas se menciona ese capítulo. B. The Git Actions panel (El panel de Acciones de Git) El Panel de Acciones de Git se utiliza exclusivamente para el control de versiones. Su función es permitirte guardar tus cambios (hacer "commit"), subir tus cambios al repositorio remoto ("push"), descargar los cambios de otros desarrolladores ("pull") y gestionar ramas de código. No tiene ninguna funcionalidad para buscar texto dentro de los archivos del proyecto; su propósito es gestionar el historial y la colaboración en el código, no analizar el contenido del código en sí. C. The Project Settings page (La página de Configuración del Proyecto) La página de Configuración del Proyecto es para administrar los ajustes generales del proyecto. Aquí configuras cosas como el nombre del proyecto, las dependencias con otros proyectos, o las reglas de calidad del código. Es un panel de control administrativo para el proyecto en su conjunto y no tiene herramientas para buscar o editar el código LookML directamente.

Answer 1286

B La respuesta correcta es la B. LookML es el lenguaje que utiliza Looker para describir la estructura de tu base de datos y las relaciones entre las tablas. Piénsalo como el "cerebro" 🧠 o el "mapa" que le dice a Looker cómo interpretar tus datos. ✅ Por qué la opción B es la correcta B. Para definir cómo se estructuran y se relacionan los datos. El propósito principal de LookML (Looker Modeling Language) es crear un modelo semántico sobre tu base de datos. Esto significa que los desarrolladores usan LookML para: Definir "Dimensiones" y "Medidas": Traducen las columnas de la base de datos (ej. fecha_de_compra, precio_unitario) a conceptos de negocio fáciles de entender para los usuarios (ej. "Fecha de Compra", "Total de Ventas"). Crear relaciones (joins): Explican cómo se conectan las diferentes tablas de datos entre sí (por ejemplo, cómo la tabla de usuarios se relaciona con la tabla de pedidos). Establecer la lógica de negocio: Se escriben cálculos y transformaciones reutilizables para que todos en la empresa usen las mismas definiciones. En resumen, LookML crea una capa de abstracción entre la base de datos SQL compleja y el usuario final, permitiendo que cualquiera pueda explorar los datos sin necesidad de saber SQL. ❌ Por qué las otras opciones son incorrectas A. Para crear visualizaciones y dashboards. Esto es incorrecto porque las visualizaciones y dashboards (gráficos, tablas, etc.) se crean en la interfaz gráfica de Looker, conocida como la sección "Explore". Los usuarios de negocio arrastran y sueltan las dimensiones y medidas que previamente fueron definidas en LookML. Por lo tanto, LookML es el fundamento que permite la creación de visualizaciones, pero no la herramienta con la que se crean directamente. C. Para gestionar el acceso y los permisos de los usuarios. Esto es incorrecto. La gestión de usuarios, roles y permisos generales (quién puede ver qué dashboard, quién puede crear contenido, etc.) se realiza principalmente desde el panel de Administración de Looker. Aunque LookML puede usarse para aplicar seguridad a nivel de fila (por ejemplo, hacer que un vendedor solo vea los datos de sus propias ventas), su propósito principal no es la administración de usuarios, sino el modelado de datos. D. Para conectar Looker a bases de datos externas. Esto también es incorrecto. La conexión a una base de datos (como BigQuery, Snowflake, Redshift, etc.) es un paso de configuración que se realiza en el panel de Administración. Un administrador introduce las credenciales (host, usuario, contraseña) para establecer el vínculo. Una vez que la conexión está establecida, entonces se utiliza LookML para modelar los datos que provienen de esa conexión. La conexión es un requisito previo, no la función de LookML.

Answer 1287

C Por qué la opción C es la correcta El componente central y diferenciador de la arquitectura de Looker es su capa de modelado, escrita en un lenguaje llamado LookML. Abstracción de SQL: Esta "capa de modelado" es donde los analistas de datos definen la lógica de negocio una sola vez. Definen qué son las "dimensiones" (ej. fecha_de_pedido), qué son las "medidas" (ej. suma_de_ventas) y cómo se relacionan las tablas (los joins). Autogeneración de SQL: Una vez que este modelo está construido, los usuarios de negocio (que no saben SQL) pueden usar la interfaz gráfica de "Explorar" de Looker para seleccionar las dimensiones y medidas que necesitan. Looker toma esas selecciones y escribe automáticamente una consulta SQL optimizada para la base de datos en tiempo real. Reducción de SQL manual: Por lo tanto, esta capa de modelado es la característica exacta que reduce (casi elimina para el usuario final) la necesidad de escribir SQL manualmente para cada nuevo informe o pregunta. Por qué las otras opciones son incorrectas A. Data Governance (Gobernanza de Datos): Esto es un resultado o un beneficio de tener una capa de modelado centralizada, no la característica arquitectónica en sí. Como toda la lógica de negocio vive en el modelo LookML, se logra una "única fuente de verdad" (Single Source of Truth), lo cual es la base de una buena gobernanza. Pero la gobernanza es el "qué" logras, no el "cómo" (que es la capa de modelado). B. Rich Development Framework (Marco de Desarrollo Enriquecido): Esto se refiere a las herramientas que Looker proporciona para construir la capa de modelado, como un IDE (entorno de desarrollo), validación de código, y, muy importante, la integración con Git para el control de versiones. Este framework ayuda a gestionar el modelo, pero el modelo en sí (opción C) es lo que reduce la escritura de SQL. D. Browser-based SaaS platform (Plataforma SaaS basada en navegador): Esto describe el modelo de despliegue de Looker (cómo se entrega y se accede a él), no la característica funcional que genera SQL. El hecho de que se ejecute en un navegador es una característica de conveniencia y arquitectura, pero no es la razón por la que no tienes que escribir SQL.

Answer 1288

B In Looker, a "Look" is a standalone report or visualization that users can create, save, and share, distinct from dashboards, which are collections of multiple visualizations.

Answer 1289

C The Looker IDE (Integrated Development Environment) is where LookML developers create and modify data models, dimensions, measures, and Explorers, providing tools like the File Browser and Object Browser to organize and manage LookML files.

Answer 1290

C Production Mode is used by business users to access the latest stable version of data models and is read-only, tied to the main Git branch. Development Mode allows LookML developers to test changes in a separate branch without affecting production.

Answer 1291

B LookML is Looker’s proprietary language that establishes an abstraction layer for SQL. Developers use it to tell Looker what data to use from the connected database and how that data should be interpreted, acting as the modeling layer between the connected SQL database and business users. It allows developers to define dimensions, measures, data relationships (like joins), and custom tables and fields.

Answer 1292

B The LookML project hierarchy starts with the Project as the highest level, which is a library of self-contained LookML code often mapping one-to-one with a Git repository. Projects contain Model files, which define database connections and the Explores to be packaged. Explores are sets of pre-joined views organized by business area defined within model files, enabling self-serve data exploration. Views represent underlying database tables and are the building blocks of Explores. Finally, Dimensions (data attributes) and Measures (aggregations of attributes) are defined within view files.

Answer 1293

D ✅ La respuesta correcta D. The string dimension type is the default in Looker and is used for text values like names. (El tipo de dimensión string es el predeterminado en Looker y se usa para valores de texto como nombres.) Por qué es correcta: Esta afirmación tiene dos partes y ambas son verdaderas. Es el predeterminado: Si creas una dimensión en LookML y no especificas ningún type:, Looker automáticamente asume que es de tipo string. Se usa para valores de texto: Su propósito es manejar datos alfanuméricos o de texto, como nombres de clientes, categorías de productos, ID de pedidos, etc. ❌ Las respuestas incorrectas A. The number dimension type is the default dimension type assigned by Looker to a newly created dimension. (El tipo de dimensión number es el tipo predeterminado...) Por qué es incorrecta: Es simple: el tipo predeterminado es string, no number. Debes especificar explícitamente type: number si quieres que Looker trate un campo como una dimensión numérica (por ejemplo, para formatearlo o filtrarlo como un número, pero sin agregarlo como una medida). B. The yesno dimension type is used for bucketing values into ranges, such as 0-29 or 30-89. (El tipo yesno se usa para agrupar valores en rangos...) Por qué es incorrecta: Esto confunde dos tipos diferentes. yesno: Se usa para valores booleanos (verdadero/falso, 1/0, t/f). Muestra "Yes" o "No" en la interfaz de usuario, lo cual es útil para filtrar. tier (nivel): Este es el tipo que realmente se usa para crear "cubetas" o rangos (como 0-29, 30-89, etc.). C. Dimension groups of type time automatically create a single dimension field, regardless of the specified timeframes. (Los grupos de dimensiones de tipo time crean automáticamente un solo campo de dimensión, independientemente de los plazos especificados.) Por qué es incorrecta: Esta afirmación es exactamente lo contrario de la realidad. La gran ventaja de un dimension_group de tipo time es que crea múltiples campos de dimensión a partir de una sola columna de marca de tiempo. Por ejemplo, si especificas timeframes: [date, week, month], Looker generará automáticamente tres dimensiones: nombre_del_grupo_date, nombre_del_grupo_week y nombre_del_grupo_month. No crea un "solo campo".

Answer 1294

C The count_distinct measure type is specifically used to calculate the count of unique values for a dimension by requiring a sql parameter pointing to that dimension. Unlike sum and average measures, count measures do not require the sql parameter by default; they typically use the view's primary key. Measures are aggregates of dimensions and do not live explicitly in database tables; they must be created using LookML. Measures do not appear in the GROUP BY statement of the SQL generated by Looker; instead, they appear as aggregate functions in the SELECT statement.

Answer 1295

B LookML dashboards are modeled by LookML developers and live in a code storage with a version control system like Git. They are stored as version-controlled files associated with the project in a Git repository. In contrast, user-defined dashboards are typically created and edited by business users and data explorers, and are stored in a user's personal or shared folder locally in the Looker instance. Both types of dashboards can be converted to one another, and dashboards generally support filters.

Answer 1296

B The string dimension type is the default in Looker, suitable for general alphanumeric data. Other types like number, yesno, and tier must be specified explicitly

Answer 1297

A, B y C LookML supports sum, average, and count as measure types. "Tier" is a dimension type, not a measure type

Answer 1298

B Looker recommends the .dashboard.lookml extension for LookML dashboard files, making them easily identifiable in the IDE

Answer 1299

A y C Por qué A y C son correctas A. You can reference a field from another view if the views are joined in an Explore. Correcto. Esta es una funcionalidad central de LookML. Si una vista orders está unida (joined) a una vista users en una Exploración (Explore), puedes crear un campo en la vista orders que haga referencia a un campo en users usando la sintaxis ${view_name.field_name}. Ejemplo: En la vista orders, podrías crear una dimensión user_full_name así: sql: ${users.first_name} || ' ' || ${users.last_name} ;; C. You can use ${field_name} to reference a dimension in the same view. Correcto. Esta es la sintaxis para hacer referencia a otro campo de LookML (dimensión o medida) dentro de la misma vista. Es muy común usar esto para construir dimensiones sobre otras dimensiones o medidas sobre dimensiones. Ejemplo: dimension: profit { sql: ${TABLE}.sale_price - ${TABLE}.cost ;; } measure: total_profit { type: sum; sql: ${profit} ;; } (Aquí ${profit} hace referencia a la dimensión de arriba). Por qué B y D son incorrectas B. You must always use the ${TABLE} syntax to reference fields. Incorrecto. La sintaxis ${TABLE} no se usa para referenciar campos de LookML. Se usa para referenciar la tabla SQL subyacente de la vista actual en la base de datos (ej. sql: ${TABLE}.column_name ;;). Como vimos en A y C, se usan ${field_name} y ${view_name.field_name} para referenciar otros campos de LookML. D. You cannot reference measures from other views. Incorrecto. Sí se puede, pero de una manera específica. No puedes referenciar una medida de otra vista en el parámetro sql de una dimensión (porque las dimensiones son a nivel de fila y las medidas son agregadas). Sin embargo, puedes perfectamente referenciar una medida de otra vista dentro de una medida de type: number. Esto se usa para crear cálculos y ratios entre agregaciones. Ejemplo: En una vista users, podrías crear una medida revenue_per_user así: measure: revenue_per_user { type: number; sql: ${orders.total_revenue} / ${count} ;; } (Aquí se referencia la medida total_revenue de la vista orders).

Answer 1300

B As shown on slide 11, a model file's primary responsibilities are to specify the database connection for the model, define the Explores (the starting points for queries), and declare the join logic that stitches different views together within those Explores. Dimensions and measures are defined in view files (A), visualizations are created in the UI (C), and while a project maps to a Git repo, the connection itself is configured in Looker's admin settings, not the model file (D)

Answer 1301

C La Respuesta Correcta: Opción C sql: CONCAT(${first_name}, " ", ${last_name}) ;; Esta es la mejor práctica por una razón fundamental en programación: Reutilización y Abstracción (DRY - Don't Repeat Yourself). Sintaxis de Sustitución (${...}): En LookML, cuando usas ${nombre_de_dimension}, le estás diciendo a Looker: "Ve a buscar el SQL que definí para esa dimensión e insértalo aquí". Por qué es bueno: Mantenibilidad: Si mañana decides cambiar la lógica de first_name (por ejemplo, para que siempre esté en mayúsculas UPPER(), o para limpiar espacios con TRIM()), ese cambio se propagará automáticamente a full_name. No tienes que editar el código en dos lugares. Consistencia: Aseguras que la definición de "nombre" sea idéntica en todas partes. Por qué las otras son "malas" Opción A: Referencia a la Columna Física sql: ${TABLE}.first_name || ' ' || ${TABLE}.last_name ;; El problema: Estás haciendo referencia directa a la columna de la base de datos (${TABLE}.columna) en lugar de a la dimensión lógica de Looker. Por qué es malo: Si la dimensión first_name tenía alguna lógica especial (como COALESCE(first_name, 'Desconocido')), la opción A ignora esa lógica y va directo al dato crudo. Estás duplicando código y perdiendo la ventaja de la capa semántica de Looker. Opción B: Alias "Hardcodeado" (Código rígido) sql: CONCAT(users.first_name, " ", users.last_name) ;; El problema: Escribir explícitamente el nombre de la tabla (users.) es un error grave en LookML. Por qué es malo: Looker genera los alias de las tablas dinámicamente cuando hace JOINS (por ejemplo, puede llamar a la tabla t1, t2, etc.). Si escribes users., el SQL fallará en cuanto intentes unir esta vista con otra, porque la base de datos no sabrá a qué se refiere users dentro de la consulta generada. Siempre se debe usar ${TABLE} o referencias a campos ${campo}. Opción D: Sintaxis SQL Incorrecta (Generalmente) sql: ${first_name} + " " + ${last_name} ;; El problema: Aunque usa la sustitución correcta (${...}), el operador + para concatenar texto no es estándar en la mayoría de los dialectos SQL (se usa en SQL Server, pero no en BigQuery, Snowflake, PostgreSQL, etc., que usan || o CONCAT). Por qué es malo: Es arriesgado y menos portable. La opción C (CONCAT) es una función más segura y universalmente aceptada en las preguntas de certificación de Looker para ilustrar la lógica.

Answer 1302

B As stated on slide 84, whenever you define a new measure that performs a calculation based on other measures, you must use type: number. Looker does not have type: ratio or type: percent_of_total. While the output is a percentage, the type parameter itself must be number to allow for arithmetic operations on other aggregate fields in the sql parameter. The final percentage formatting would be handled by a separate parameter like value_format_name.

Answer 1303

C The table on slide 90 clearly outlines the differences. The most fundamental distinction is their storage and creation method. LookML dashboards are code (.dashboard.lookml files) that live in a Git repository, making them version-controlled. User-defined dashboards are created interactively in the UI and saved to personal or shared folders within the Looker platform's internal database. Both types can be interactive (A), and conversion is possible in both directions (D). Option B has the storage methods reversed.

Answer 1304

B Respuesta Correcta: B. It generates a CASE statement inside the aggregate function to count only the relevant rows (Genera una sentencia CASE dentro de la función de agregación para contar solo las filas relevantes). Esta es la forma correcta y más eficiente en que Looker traduce este LookML a SQL. En lugar de filtrar toda la consulta, crea una lógica dentro de la propia medida. El SQL generado se parecería a esto: COUNT(CASE WHEN orders.order_country = 'USA' THEN orders.id ELSE NULL END) ¿Por qué es esto? El objetivo es que esta medida (count_usa_orders) pueda coexistir en una misma consulta con otras medidas que no están filtradas (por ejemplo, una medida que cuente el total de todas las órdenes, sin importar el país). Usando una sentencia CASE, la base de datos revisa cada fila: Si el país es "USA", le asigna un valor para contar (como el ID del pedido). Si el país no es "USA", le asigna NULL. La función COUNT() solo cuenta los valores que no son NULL, logrando así el conteo condicional sin afectar al resto de la consulta. Es como decirle al sistema: "Revisa todas las filas, pero solo levanta la mano y cuenta si la fila es de USA". ✋ Respuestas Incorrectas A. It adds a WHERE order_country = 'USA' clause to the overall SQL query (Añade una cláusula WHERE a la consulta SQL general). Esto es incorrecto porque una cláusula WHERE filtra el conjunto de datos antes de que se realice cualquier cálculo. Si Looker hiciera esto, afectaría a todas las medidas de la consulta. No podrías, por ejemplo, comparar el total de órdenes de USA con el total de órdenes a nivel mundial en la misma tabla, porque la cláusula WHERE ya habría eliminado todas las filas que no son de USA. C. It creates a temporary derived table in the background that is pre-filtered for "USA" (Crea una tabla derivada temporal que está pre-filtrada). Esto es incorrecto porque sería extremadamente ineficiente. Crear una tabla derivada solo para una medida filtrada es un proceso muy pesado y lento que no es necesario. La sentencia CASE es la forma nativa y optimizada en SQL para realizar agregaciones condicionales, y es mucho más rápida. D. It retrieves all data and then applies the filter within the Looker application after the query is complete (Recupera todos los datos y luego aplica el filtro en la aplicación de Looker). Esto es incorrecto y va en contra de la filosofía fundamental de Looker. Looker está diseñado para delegar todo el trabajo pesado a la base de datos SQL. Traer todos los datos sin filtrar a la aplicación de Looker para luego filtrarlos allí sería muy lento, consumiría mucha memoria y no sería escalable para grandes volúmenes de datos. El objetivo es siempre que la base de datos devuelva solo el resultado ya calculado.

Answer 1305

B LookML acts as a modeling layer between the SQL database and business users, allowing developers to define data attributes and relationships, making it easier for non-technical users to analyze data without writing SQL.

Answer 1306

B The hierarchy is Project (largest) > Model > Explorer > View, reflecting how LookML organizes data models for development and analysis.

Answer 1307

D Sum is a measure, not a dimension. Dimensions include types like String, Number, and Yesno, while measures are aggregates like Sum or Count.

Answer 1308

B The 'type' parameter is required to specify the aggregation method (e.g., sum, average) when defining a measure in LookML.

Answer 1309

B LookML dashboards are part of the project and version-controlled with Git, while user-defined dashboards are personal and stored in user folders.

Answer 1310

C In Looker, Explores are conceived as a set of tables with predefined join logic. As a LookML developer, you define and curate Explores, and the name of an Explore must be the name of an actual view file, which also establishes it as the base view for analysis

Answer 1311

B If a type is not explicitly provided for a join in LookML, the default type applied is left_outer. This join type ensures that all records from the left-side view of the join are retained, even if no corresponding records are found in the right-side view

Answer 1312

C Both sql_always_where (for dimensions) and sql_always_having (for measures) are used to add filters to an Explore that cannot be changed by business users. Additionally, these filters do not display in the user interface, meaning business users are unaware of the filtering unless they have permissions to view the generated SQL

Answer 1313

B For symmetric aggregation to be automatically implemented by Looker (provided the underlying database supports it), two key conditions must be met: every view file involved in the join must have a primary_key defined, and the relationship parameter for every Explore join must be specified accurately.

Answer 1314

B Symmetric aggregation in Looker specifically addresses the "fanout problem," a common issue arising from one-to-many data joins. This problem occurs when joining tables (e.g., customers to orders, where one customer has many orders) duplicates rows from the "one" side (customers), leading to inaccurate aggregate calculations (like sums or counts) for fields from that fanned-out table.

Answer 1315

B ✅ La Respuesta Correcta: B) from: airports La clave está en la diferencia entre el nombre del join y la vista que utiliza el join. En LookML, el nombre del join (el alias que usarás en tu sql_on y en los explore) se define con la etiqueta join:. En el ejemplo, estos son aircraft_origin y aircraft_destination. Por defecto, Looker asume que join: mi_vista usará la vista llamada mi_vista. El problema es que nuestros joins se llaman aircraft_origin y aircraft_destination, ¡no airports! Looker no sabe a qué vista apuntan. El parámetro from: se usa dentro de un bloque de join para decirle explícitamente a Looker: "Aunque este join se llama X, la vista de LookML que realmente debes usar es Y". El código LookML se vería así: explore: flights { ... join: aircraft_origin { from: airports // <-- La respuesta: le dice que use la vista 'airports' type: left_outer sql_on: ${flights.origin_id} = ${aircraft_origin.airport_id} ;; } join: aircraft_destination { from: airports // <-- La respuesta: usa la *misma* vista otra vez type: left_outer sql_on: ${flights.destination_id} = ${aircraft_destination.airport_id} ;; } } ❌ Por Qué las Otras Opciones Son Incorrectas A) view_name: airports Este parámetro se usa dentro de un bloque explore:, no de un join:. Se utiliza si quieres que tu Explore tenga un nombre diferente al de su vista base. (Ej: explore: mis_vuelos { view_name: flights }). No es para joins. C) sql_table_name: project.dataset.airports Este parámetro se usa dentro de un bloque view:, (es decir, dentro del archivo airports.view.lookml). Le dice a la vista qué tabla física debe consultar en la base de datos. El join se hace a la vista de LookML, no directamente a la tabla de SQL, por lo que este parámetro no va en el join. D) alias: airports Esta opción confunde el concepto. En este escenario, aircraft_origin es el alias. No existe un parámetro alias: que se use de esta manera dentro de un join. El parámetro from: es el que indica de qué vista proviene ese alias.

Answer 1316

D Por qué D) sql_always_where es la respuesta correcta sql_always_where es un parámetro que se añade a la definición de un explore. Su función es inyectar código SQL directamente en la cláusula WHERE de la consulta final que genera Looker. Cumple con los tres requisitos de la pregunta: Se aplica automáticamente: Cualquier consulta que se ejecute contra el Explore "Orders" tendrá esta condición (WHERE status != 'Cancelled') añadida al SQL, sin excepción. No es visible para los usuarios: Es una regla de backend. El usuario de negocio que utiliza la interfaz de "Explore" no ve ningún filtro aplicado en la sección de filtros. Simplemente, los datos "Cancelados" nunca aparecen, como si no existieran. No es modificable por los usuarios: Como el usuario no puede verlo, no puede cambiarlo ni eliminarlo. Es una regla de gobernanza forzada. Ejemplo de implementación: explore: orders { ... sql_always_where: ${orders.status} != 'Cancelled' ;; } Por qué las otras respuestas son incorrectas A) always_filter: Este es el distractor más común. always_filter aplica un filtro por defecto, pero este filtro es visible para el usuario en la interfaz y puede ser modificado o eliminado por él. Se usa para sugerir un punto de partida (ej. "últimos 7 días"), no para imponer una regla de seguridad/gobernanza. C) conditionally_filter: Este parámetro hace lo contrario. Obliga al usuario a seleccionar un valor para un filtro específico antes de poder ejecutar la consulta. No oculta el filtro, sino que lo hace obligatorio y visible. B) hidden_fields: Este parámetro no tiene nada que ver con filtrar datos. Simplemente oculta campos para que no aparezcan en el selector de campos de la izquierda en la interfaz del Explore. No aplica ninguna condición WHERE.

Answer 1317

B Explicación del Problema "Fanout" El problema que describes es un clásico "fanout" (abanico), que ocurre cuando unes una tabla de "uno" (en este caso, customers, donde cada fila es un cliente único con su total de visitas) con una tabla de "muchos" (en este caso, orders, donde un cliente puede tener múltiples pedidos). Al unir la tabla customers con la tabla orders, las filas de customers se duplican para coincidir con cada pedido que haya. Por lo tanto, cuando Looker suma la medida "Total Visits" (que es una simple SUM de la tabla customers), está sumando el total de visitas de un cliente múltiples veces (una vez por cada pedido), inflando el resultado. Las medidas de la tabla orders (como "Order Count") son correctas porque el recuento de pedidos sigue siendo exacto a pesar de la duplicación de las filas del cliente. Agregación Simétrica de Looker La característica de Agregación Simétrica de Looker está diseñada para resolver este problema de inflación (fanout) automáticamente. Lo hace envolviendo la medida inflada (como "Total Visits") en una fórmula que divide la suma por la clave primaria para evitar la duplicación. Para que Looker sepa qué medida está inflada y cómo corregirla, necesita dos piezas clave de información en el LookML: Saber qué fila es única en la tabla de "uno" (la que se está inflando): Esto se define mediante el parámetro primary_key en la vista (view) de esa tabla (la vista customers). Saber que la unión es de "uno a muchos": Esto se define mediante el parámetro relationship en la cláusula de la unión (join), especificando que la relación es one_to_many (uno a muchos) o one_to_one (uno a uno). En este caso, debe ser one_to_many desde customers a orders. Análisis de las Opciones B. Correcta ✅ primary_key debe estar definido en la vista de customers: Correcto. Esto le dice a Looker qué campo representa el identificador único del cliente, lo que es crucial para que la Agregación Simétrica calcule la suma correcta. El parámetro relationship debe estar correctamente definido para la unión: Correcto. El valor de relationship debe ser one_to_many (desde customers a orders) para que Looker detecte el patrón de fanout y aplique la corrección. A. Incorrecta ❌ El tipo de unión debe ser left_outer: El tipo de unión (join_type) no es un requisito para que funcione la Agregación Simétrica. Looker puede corregir la inflación independientemente de si la unión es left_outer, inner, etc. La condición sql_on debe ser correcta: Aunque la condición de unión siempre debe ser correcta para que la unión funcione en primer lugar, esto no es lo que habilita la Agregación Simétrica. C. Incorrecta ❌ La relación de la unión debe ser many_to_many: El problema de fanout se produce típicamente en relaciones uno-a-muchos. Aunque Looker también tiene un manejo especial para many_to_many, en este escenario clásico de cliente-pedido, la relación esperada es one_to_many. Se debe usar sql_always_where: Este parámetro se usa para aplicar filtros a nivel de modelo para la seguridad de los datos (acceso por grupo o usuario) y no tiene nada que ver con la corrección de la inflación de medidas. D. Incorrecta ❌ Un primary_key debe estar definido en la vista de orders: Incorrecto. La medida inflada ("Total Visits") viene de la vista customers. La clave primaria debe estar definida en la vista customers (la tabla del lado "uno" cuya medida se está inflando), no en la vista orders. El tipo de unión debe ser inner: Al igual que en la opción A, el tipo de unión no es el factor que habilita la corrección.

Answer 1318

C Slide 12 defines this exact scenario. An indirect join is a join to a view that is not the base view of the Explore. The slide warns that this can impact performance because Looker must join through the intermediary view (aircraft) to get to the indirectly joined view (aircraft_maintenance_logs), creating an extra join in the SQL query that might otherwise be unnecessary.

Answer 1319

C This scenario is the exact use case for conditionally_filter, as explained on slide 24. This parameter applies a default filter (filters: [event_date: "7 days"]) that users can see and modify, but it can only be removed entirely if the user filters on a field specified in the unless list (unless: [user_id, session_id]). This provides a balance between guided analysis and user flexibility.

Answer 1320

B In Looker, an Explore is a curated set of tables with predefined join logic, designed by LookML developers to allow business users to analyze data without writing SQL queries, providing a user-friendly way to explore data.

Answer 1321

B ✅ B. always_filter (La respuesta correcta) Este parámetro hace exactamente lo que describe la pregunta. Cuando un desarrollador de LookML añade always_filter a una vista (Explore), obliga a que ese filtro siempre esté presente en la interfaz de usuario. Permite modificar: El usuario puede (y de hecho, a menudo debe) cambiar el valor de ese filtro. Por ejemplo, si el filtro es "Fecha", el usuario puede cambiar el valor de "últimos 7 días" a "último mes". No permite eliminar: El usuario no puede quitar el filtro de la consulta. El icono "X" para eliminar el filtro no aparecerá o estará desactivado. Esto es muy útil para obligar a los usuarios a limitar sus consultas y evitar que ejecuten accidentalmente consultas muy pesadas (por ejemplo, "traer todos los datos de ventas de los últimos 10 años" sin querer). ❌ Las respuestas incorrectas Aquí te explico por qué las otras opciones no encajan con la descripción: A. sql_always_where Qué hace: Este parámetro añade una condición SQL fija directamente en la cláusula WHERE de la consulta generada. Por qué es incorrecta: El usuario no ve este filtro en la interfaz de usuario. Es una regla que se aplica "detrás de escena". Como el usuario no puede verlo, no puede modificarlo en absoluto. C. conditionally_filter Qué hace: Este es un parámetro más complejo. Aplica un conjunto de filtros a menos que el usuario ya esté filtrando por un campo específico. Por qué es incorrecta: Su propósito no es hacer un filtro "inamovible". Su propósito es aplicar un filtro condicionalmente, dependiendo de las otras acciones del usuario. No encaja con la descripción de "modificar pero no eliminar". D. sql_always_having Qué hace: Funciona exactamente igual que sql_always_where, pero añade la condición SQL fija en la cláusula HAVING. (La cláusula HAVING se usa para filtrar sobre resultados agregados o medidas, mientras que WHERE filtra filas individuales). Por qué es incorrecta: Al igual que sql_always_where, el usuario no ve este filtro en la interfaz y, por lo tanto, no puede modificarlo.

Answer 1322

A Symmetric aggregation in Looker requires every view file to have a primary_key defined to uniquely identify rows, and the relationship parameter for joins must be correctly specified, ensuring accurate aggregations like COUNT(DISTINCT) for one-to-many relationships.

Answer 1323

B ✅ Opción B: La Respuesta Correcta (left_outer) B. left_outer (Externa izquierda) Esta es la respuesta correcta porque Looker, por diseño, utiliza LEFT JOIN (expresado en LookML como left_outer) como el tipo de unión por defecto. ¿Por qué esta decisión? La filosofía de Looker se centra en permitir que los usuarios de negocio exploren los datos de forma segura. La elección de left_outer es fundamental para este propósito: Conserva todos los datos del punto de partida: Cuando empiezas a explorar en Looker, partes de una vista principal (definida en el explore). Un left_outer join asegura que todas las filas de esa vista principal se mantengan en el resultado, sin importar si encuentran una coincidencia en la vista que estás uniendo. Evita la pérdida accidental de datos: Si el valor por defecto fuera inner, un analista podría unir una nueva vista y ver cómo desaparecen filas de su análisis sin entender por qué. Esto podría llevar a conclusiones erróneas (por ejemplo, pensar que hay menos clientes de los que realmente existen). Comportamiento intuitivo para el análisis: Generalmente, cuando exploras datos, quieres empezar con un conjunto base (ej: "todos mis clientes") y añadirle información adicional (ej: "sus pedidos"). Quieres ver a todos los clientes, incluso a los que no han hecho ningún pedido. Un left_outer join logra exactamente esto. En LookML, si escribes un join sin especificar el tipo, Looker asume que es left_outer: explore: customers { join: orders { // Esto por defecto es un type: left_outer sql_on: ${customers.id} = ${orders.customer_id} ;; relationship: one_to_many } } ❌ ¿Por Qué las Otras Opciones son Incorrectas? Para entender esto, usemos una analogía simple: Tabla Izquierda: Clientes (con todos tus clientes). Tabla Derecha: Pedidos (con los pedidos que han hecho). A. inner Un INNER JOIN (unión interna) solo devuelve las filas donde hay una coincidencia en AMBAS tablas. En nuestra analogía: Solo te mostraría los clientes que han realizado al menos un pedido. Cualquier cliente que nunca haya comprado nada desaparecería de tu resultado. Por qué no es el defecto: Es demasiado restrictivo. Limitaría los datos desde el principio y podría confundir a los usuarios que esperan ver el universo completo de su tabla inicial. C. full_outer Un FULL OUTER JOIN (unión externa completa) devuelve todas las filas de AMBAS tablas, haya o no una coincidencia. Si no hay coincidencia, rellena los campos faltantes con NULL. En nuestra analogía: Te mostraría todos los clientes (incluso los sin pedidos) Y todos los pedidos (incluso si, por un error en los datos, un pedido no tuviera un cliente asociado). Por qué no es el defecto: Aunque es útil para tareas de conciliación de datos, suele generar resultados muy grandes y con muchos valores nulos, lo que complica el análisis exploratorio estándar. No es una necesidad común para la mayoría de las consultas de negocio. D. cross Un CROSS JOIN (unión cruzada) devuelve el producto cartesiano de las tablas. Es decir, une cada fila de la primera tabla con cada fila de la segunda. En nuestra analogía: Si tienes 100 clientes y 1.000 pedidos, un CROSS JOIN produciría 100 * 1.000 = 100.000 filas. El resultado no tendría sentido analítico. Por qué no es el defecto: Este tipo de unión casi nunca se usa en el análisis de datos de negocio porque genera conjuntos de datos masivos y generalmente incorrectos. Es extremadamente peligroso tenerlo como valor por defecto.

Answer 1324

B When Looker generates a SQL query based on an Explore, the base view (central table for analysis) is placed in the FROM clause, with joins added via sql_on logic and filters incorporated into the WHERE clause.

Answer 1325

B Derived tables are a great feature of Looker that allows you to create new custom tables that do not yet exist in your underlying database. They are used to define new custom tables to address complex business questions or structure data in specific ways

Answer 1326

C El Concepto Clave: Dos Tipos de Tablas Derivadas en Looker En Looker, una "tabla derivada" (Derived Table) es una consulta cuyos resultados se utilizan como si fueran una tabla física en tu base de datos. Existen dos formas de crear una: Tablas Derivadas de SQL (SQL Derived Tables): Aquí es donde escribes la consulta SQL manualmente, usando sql: .... Eres 100% responsable de escribir el código SQL. Tablas Derivadas Nativas (Native Derived Tables - NDTs): Aquí usas LookML (el lenguaje de Looker) para definir la tabla. En lugar de escribir SQL, usas explore_source: ... y haces referencia a un "Explore" existente, junto con las dimensiones y medidas que quieres incluir. Sabiendo esto, analicemos las opciones: La Respuesta Correcta C) NDTs are expressed entirely in LookML and promote code reusability by leveraging existing dimensions and measures. Por qué es correcta: Esta es la definición perfecta de una NDT. "Se expresan enteramente en LookML": Correcto. Usas la sintaxis explore_source de LookML, no escribes SQL. "Promueven la reutilización de código": Correcto. Esta es su mayor ventaja. Si ya definiste una dimensión (ej. revenue con una fórmula compleja) en tu modelo, simplemente la incluyes en tu NDT por su nombre. No tienes que reescribir la fórmula SQL. "Aprovechando dimensiones y medidas existentes": Correcto. Así es cómo logran la reutilización. Las Respuestas Incorrectas A) NDTs are primarily for SQL experts and often involve more hard-coded database references. Por qué es incorrecta: Esta afirmación es exactamente lo opuesto a la realidad. Las NDTs están diseñadas para abstraer el SQL, permitiendo que personas menos expertas en SQL puedan construir tablas complejas. Las que son para expertos en SQL y usan referencias "hard-coded" (codificadas a fuego) son las tablas derivadas de SQL. B) NDTs require manual construction of complex SQL queries, similar to traditional SQL views. Por qué es incorrecta: Esto, de nuevo, describe a las tablas derivadas de SQL, no a las NDTs. El propósito de una NDT es evitar la construcción manual de SQL. D) NDTs are always ephemeral, meaning they cannot be stored persistently in the database. Por qué es incorrecta: Esta es una trampa común. "Efímero" (que solo existe durante la consulta) es el comportamiento por defecto de una NDT si no se especifica nada más. Sin embargo, cualquier tabla derivada (sea NDT o de SQL) puede hacerse persistente (convirtiéndose en una PDT - Persistent Derived Table) añadiendo una estrategia de persistencia (como datagroup_trigger o persist_for). Por lo tanto, la palabra "siempre" hace que esta afirmación sea falsa.

Answer 1327

C Persistent Derived Tables (PDTs) are written back to and stored as physical tables in the underlying database. In contrast, ephemeral tables compile at runtime and are generated as Common Table Expressions (CTEs) or temporary tables

Answer 1328

C Datagroups are named caching policies within Looker that LookML developers can set up to manage the frequency and conditions for caching on a Looker instance. They can be applied to models, individual Explores, or specific PDTs in your LookML projects to ensure a refreshed cache. While max_cache_age and sql_trigger are parameters used to define a datagroup, and persist_with is used to apply a datagroup, the datagroup itself is the LookML object that defines the caching policy.

Answer 1329

D Por qué la respuesta D es la correcta D) Remove or hide auto-generated count measures if they are redundant with existing measures. (Eliminar u ocultar las medidas de conteo (count) autogeneradas si son redundantes con medidas existentes.) Esta es la respuesta correcta porque se enfoca en la "finalización" y en la experiencia del usuario final. ¿Qué pasa? Cuando usas la función "Add to Project" (Añadir al Proyecto) desde SQL Runner para crear una tabla derivada, Looker es "servicial" y, además de crear las dimensiones para cada columna SQL, a menudo añade automáticamente una medida por defecto, que suele ser measure: count { type: count }. ¿Cuál es el problema? En un modelo de datos bien construido, esta medida genérica de count casi siempre es redundante. Seguramente ya tienes una medida de conteo principal en otra vista (por ejemplo, count en la vista orders o users). ¿Por qué es una "mejor práctica"? Dejar esta medida redundante "ensucia" la interfaz (el "Explore") para los usuarios de negocio. Verán dos o más medidas llamadas "Count" y no sabrán cuál usar. La mejor práctica al finalizar un fichero de vista es limpiarlo, eliminar el código autogenerado innecesario y asegurarse de que el modelo sea claro y fácil de usar (siguiendo el principio DRY: Don't Repeat Yourself). Por qué las otras respuestas son incorrectas A) Keep the LIMIT clause from the testing query to optimize performance for business users. (Mantener la cláusula LIMIT de la consulta de prueba para optimizar el rendimiento para los usuarios de negocio.) Incorrecto. Esto es un error grave. La cláusula LIMIT (como LIMIT 100) se usa en SQL Runner solo para probar la consulta rápidamente sin tener que procesar todos los datos. Si dejas ese LIMIT en la tabla derivada final, la tabla estará incompleta (solo tendrá 100 filas) y todos los informes y análisis de los usuarios de negocio serán incorrectos. B) Ensure the auto-generated view name matches the view file name. (Asegurarse de que el nombre de la vista autogenerado coincida con el nombre del archivo de la vista.) Incorrecto (aunque es algo que debe ser cierto). Que el nombre de la vista (ej. view: my_table) coincida con el nombre del fichero (ej. my_table.view.lkml) no es tanto una "mejor práctica" sino un requisito funcional de LookML para que las inclusiones (include) funcionen. Además, cuando Looker autogenera el fichero desde SQL Runner, él mismo se encarga de que coincidan. La acción de la opción D (limpiar medidas) es un paso de "finalización" y refinamiento que el desarrollador debe hacer activamente. C) Move the view file outside of the views folder for better organization. (Mover el archivo de la vista fuera de la carpeta 'views' para una mejor organización.) Incorrecto. Esto es lo opuesto a una mejor práctica. La estructura de carpetas de LookML es convencional. Los archivos de vista (.view.lkml) deben estar dentro de la carpeta views. Moverlos a otro lugar rompe esta convención, desorganiza el proyecto y puede hacer que otras partes del modelo fallen.

Answer 1330

B As explained in slides 7 and 8, the primary use case for derived tables is to handle multi-step aggregations. Calculating the average of a sum (AVG(SUM(sales))) requires two levels of aggregation. A derived table creates an intermediate, pre-aggregated table (like a Common Table Expression or CTE), which Looker can then query to perform the second aggregation.

Answer 1331

D The explore_source parameter is the foundation of a Native Derived Table, as detailed on slide 71. It points to an existing Explore in your model, and Looker uses that Explore's definition (including its joins) as the basis for the FROM part of the NDT's SQL query.

Answer 1332

C Slide 81 introduces persistence parameters, and slide 98 reinforces the best practice. Using datagroup_trigger allows you to align the PDT's refresh schedule with the rest of your model's caching policies. It centralizes the triggering logic, making the model more maintainable and robust, which is especially important for cascading PDTs (slide 84).

Answer 1333

B Cuando no defines una estrategia de persistencia, Looker crea lo que se llama una Ephemeral Derived Table (Tabla Derivada Efímera). ¿Cómo funciona? En lugar de crear una tabla física en tu base de datos, Looker mete el código de esa tabla directamente dentro de la consulta SQL que estás ejecutando en ese momento, usualmente usando un WITH (una CTE). ¿Qué significa? Que la tabla "nace y muere" con cada clic que haces en el Explore. No ocupa espacio en el disco de tu base de datos, pero hace que la base de datos tenga que recalcular todo cada vez que lanzas la consulta. Opción,Por qué es incorrecta A,"El scratch schema solo se usa para las PDT (Persistent Derived Tables). Si no hay estrategia de persistencia, Looker no tiene permiso (ni motivo) para escribir nada en la base de datos." C,"Looker es automatización pura. Nunca te pedirá que ""corras un proceso manual"" para que una tabla funcione en el Explore; o la construye al vuelo (efímera) o la construye el Regenerator (persitente)." D,"No es un error. Es perfectamente válido tener tablas derivadas efímeras. De hecho, es la mejor práctica para tablas pequeñas o que cambian constantemente y no justifican el coste de almacenamiento."

Answer 1334

B The presentation walks through this exact process from slide 28 to 41. SQL Runner is the ideal place to write, test, and debug the raw SQL for the derived table. Once the query is correct, the "Add to Project" functionality streamlines the process by creating the view file with the necessary derived_table and sql parameter structure, which the developer can then clean up and integrate.

Answer 1335

B Derived tables in Looker are used to create new tables based on existing data sources using LookML, enabling complex data transformations and combinations not directly supported by the underlying database schema.

Answer 1336

B Por qué la B (SQL y Nativa) es CORRECTA La pregunta se refiere a las dos formas principales en que un desarrollador puede definir o crear una tabla derivada en el código LookML. SQL-based (Basada en SQL): Es la forma tradicional. El desarrollador escribe la consulta SQL exacta, palabra por palabra, que creará la tabla virtual. Se define en LookML usando el parámetro sql: SELECT ... FROM .... Da control total, pero es menos mantenible y reutilizable. Native (Nativa o NDT): Es la forma moderna y preferida. En lugar de escribir SQL, el desarrollador usa la sintaxis de LookML para "construir" la tabla a partir de un "Explore" ya existente. Se define en LookML usando el parámetro explore_source: .... Es mucho más fácil de mantener, reutilizable y se integra mejor con el resto del modelo LookML. Estas son las dos metodologías fundamentales de creación de la tabla. Por qué las otras opciones son INCORRECTAS A. Ephemeral (Efímeras) y Persistent (Persistentes) Esta es la trampa más común, porque estos términos sí existen en Looker y son cruciales. Sin embargo, no describen el tipo de definición, sino la estrategia de almacenamiento o persistencia. Ephemeral (Efímera): Es el comportamiento por defecto. La tabla derivada no se guarda físicamente en la base de datos. Se ejecuta como una subconsulta o una "Common Table Expression" (CTE) cada vez que un usuario la consulta. Es temporal. Persistent (Persistente o PDT): Es una optimización de rendimiento. Se le dice a Looker que ejecute la consulta y guarde los resultados en una tabla física real en tu base de datos (en un esquema temporal). Las consultas futuras van a esa tabla (que es rápida) en lugar de ejecutar la consulta compleja otra vez. (Esto se relaciona con tu pregunta anterior sobre las tablas de informes). El punto clave es que esta clasificación es independiente de la Opción B. Puedes tener una tabla Nativa que sea Persistente. Puedes tener una tabla Nativa que sea Efímera. Puedes tener una tabla SQL que sea Persistente. Puedes tener una tabla SQL que sea Efímera. Por lo tanto, "Efímera" y "Persistente" describen la estrategia de guardado, no el tipo de definición. C. Cached (Cacheadas) y Non-cached (No cacheadas) Incorrecto. Esto se refiere al almacenamiento en caché de los resultados de una consulta, no al tipo de tabla. El cacheo se aplica a todas las consultas de Looker (sean de tablas derivadas o no) para mejorar el rendimiento. D. Static (Estáticas) y Dynamic (Dinámicas) Incorrecto. Estos son términos informáticos generales. "Efímera" se podría parecer a "dinámica" y "Persistente" a "estática", pero no son la terminología oficial que usa Looker para esta clasificación.

Answer 1337

B Native Derived Tables are written in LookML and reuse existing dimensions and measures, making them more maintainable and easier to update compared to SQL-derived tables.

Answer 1338

B Persistent Derived Tables are stored as physical tables in the database, improving query performance by reducing the need for complex computations at runtime, and are rebuilt based on defined triggers or schedules.

Answer 1339

B Por qué la B es CORRECTA Un datagroup (grupo de datos) es la herramienta principal de Looker para gestionar la frescura de los datos y el rendimiento. Es, en esencia, una regla centralizada que define cuándo se considera que los datos están "frescos". Tiene dos propósitos principales que están directamente relacionados con la gestión de la caché: Disparador para Tablas Derivadas Persistentes (PDTs): Es su función más importante. En lugar de decirle a una PDT "reconstrúyete cada 4 horas" (lo cual es ineficiente), le dices que use un datagroup. El datagroup a su vez tiene una regla (ej. sql_trigger: SELECT MAX(updated_at) FROM orders). Cuando el resultado de esa consulta cambia (es decir, llega un nuevo pedido), el datagroup se activa y le dice a todas las PDTs que dependen de él que se reconstruyan. Política de Caché para los Explores: El mismo datagroup se usa para decirle a los "Explores" (la interfaz de usuario) cuánto tiempo deben guardar los resultados de una consulta en la caché. Al vincular estos dos, un datagroup sincroniza perfectamente el rendimiento: los usuarios obtienen resultados rápidos de la caché hasta el momento exacto en que los datos subyacentes (las PDTs) se actualizan. Por qué las otras opciones son INCORRECTAS A. Para agrupar dimensiones y medidas relacionadas: Incorrecto. Esto se hace en LookML usando el parámetro group_label. Es una función puramente visual para organizar los campos en la interfaz del "Explore" y no tiene nada que ver con la caché o la actualización de datos. C. Para definir el esquema de una tabla derivada: Incorrecto. El "esquema" (es decir, las columnas y tipos de datos) de una tabla derivada se define mediante su consulta. Ya sea con el parámetro sql (en una PDT basada en SQL) o con el parámetro explore_source (en una PDT Nativa). D. Para crear relaciones entre diferentes explores: Incorrecto. Las relaciones (JOINs) no se crean entre "Explores". Se crean entre "Views" (vistas) y se definen dentro de un "Explore" en el archivo de modelo (.model.lkml).

Temario Flashcards

(1365 cards)