Pular para o conteúdo principal

Questão de Banco de Dados — ETL (Extract Transform Load) — FGV 2025

Banco de DadosETL (Extract Transform Load)
Código
fg106574
Banca
FGV
Órgão
CGE-SP
Ano
2025
Nível
Superior
Cargo
Auditor Estadual de Controle - Tecnologia da Informação - tarde
A Controladoria possui vários pipelines críticos que transportam dados de regulamentação fiscal. Uma mudança no schema da tabela de origem exigiu alterações no código SQL de transformação e nos metadados associados. A prática de DataOps exige que todas as alterações sejam rastreáveis e que seja possível reverter o pipeline para uma versão anterior de forma atômica.No contexto do DataOps, assinale a opção que apresenta a combinação de práticas e ferramentas que garante a rastreabilidade deI. código de transformação (SQL/ETL);II. alterações no schema do DW; eIII. rollback, coordenação automatizada, em caso de falha de deployment.
  1. AUtilização de GIT para versionar o código do pipeline; aplicação de ferramentas de Versionamento de Banco de Dados para o schema; e orquestração CI/CD com estratégias de rollback automático.
  2. BAdoção de um Catálogo de Metadados para registrar o código de transformação; uso do Modelo Star Schema para o versionamento do schema; e restore do ambiente de Data Warehouse em caso de falha.
  3. CImplementação do Data Fabric e da técnica de Virtualização de Dados para evitar alterações no código de transformação; registro manual do schema no Glossário; e delegação da reversão ao Data Protection Officer.
  4. DUso de Kubernetes para orquestrar os containers do pipeline; dependência do Modelo Entity-Relationship para rastrear o schema do DW; e execução de Subconsultas Correlacionadas para validar a transformação dos dados.
  5. EAplicação de Self-Service Analytics para validar o código de transformação; utilização de TDD para o versionamento de schema do DW; e dependência de Triggers do SGBD para gerenciar a reversão atômica do deployment.
Revelar gabarito e comentário

GabaritoA — Utilização de GIT para versionar o código do pipeline; aplicação de ferramentas de Versionamento de Banco de Dados para o schema; e orquestração CI/CD com estratégias de rollback automático.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

DataOps e rastreabilidade de pipelines

Gabarito: letra A. A alternativa A combina corretamente as práticas essenciais de DataOps para garantir rastreabilidade e rollback: Git para versionar o código de transformação, ferramentas de versionamento de banco de dados para o schema do DW, e orquestração CI/CD com rollback automático para falhas de deployment. Essa tríade atende aos requisitos de código, schema e coordenação automatizada exigidos pelo DataOps.

A questão testa o conhecimento de quais ferramentas e práticas são adequadas para cada aspecto do pipeline de dados no contexto DataOps. As alternativas incorretas misturam conceitos ou utilizam ferramentas inadequadas para a finalidade proposta.

Prática / Ferramenta

Código de Transformação (SQL/ETL)

Alterações no Schema do DW

Rollback / Coordenação Automatizada

Alternativa A (Gabarito)

Git (versionamento de código)

Ferramentas de versionamento de BD (Liquibase, Flyway)

Orquestração CI/CD com rollback automático

Alternativa B

Catálogo de Metadados (não versiona)

Modelo Star Schema (não versiona)

Restore do ambiente DW (não automatizado)

Alternativa C

Data Fabric / Virtualização (não versiona)

Registro manual no Glossário (não automatizado)

Delegação ao DPO (inadequado)

Alternativa D

Kubernetes (orquestração, não versiona)

Modelo ER (não versiona)

Subconsultas Correlacionadas (não gerenciam rollback)

Alternativa E

Self-Service Analytics (não versiona)

TDD (não versiona schema)

Triggers do SGBD (não gerenciam deployment)

Alternativa A — ✅ Correta ⟵ GABARITO

Git é o sistema de controle de versão padrão para código, permitindo rastrear todas as alterações no SQL/ETL e reverter para versões anteriores. Ferramentas de versionamento de banco de dados (como Liquibase, Flyway) gerenciam esquemas do DW, registrando cada mudança de schema de forma atômica. A orquestração CI/CD com rollback automático (ex.: Jenkins, GitLab CI, Airflow) coordena deployments e reverte o pipeline automaticamente em caso de falha, garantindo atomicidade e rastreabilidade.

Alternativa B — ❌ Incorreta

Catálogo de Metadados é útil para documentação, mas não versiona o código de transformação. Modelo Star Schema é um design dimensional, não uma ferramenta de versionamento de schema. Restore do ambiente de DW é uma abordagem brutal e não automatizada para rollback, além de não ser atômico para cada deployment.

Alternativa C — ❌ Incorreta

Data Fabric e Virtualização de Dados abstraem fontes, mas não substituem versionamento de código. Registro manual de schema no Glossário não é automatizado nem rastreável. Delegar reversão ao Data Protection Officer (DPO) é inadequado – DPO é responsável por proteção de dados, não por rollback técnico de pipelines.

Alternativa D — ❌ Incorreta

Kubernetes orquestra containers, mas não versiona código de transformação nem schema. Modelo Entity-Relationship é conceito de modelagem, não ferramenta de versionamento. Subconsultas Correlacionadas são construções SQL, não validam transformações.

Alternativa E — ❌ Incorreta

Self-Service Analytics permite que usuários finais analisem dados, não valida código de transformação. TDD (Test-Driven Development) é método de desenvolvimento, não versionamento de schema. Triggers do SGBD executam ações no banco, mas não gerenciam reversão atômica de deployments.

PEGA ESSA DICA!

Para decorar a tríade do DataOps: versionamento de código (Git), versionamento de schema (ferramentas como Liquibase/Flyway) e CI/CD com rollback automático são os pilares. Em questões, elimine opções que misturam papéis (ex.: DPO) ou usam ferramentas de análise (Star Schema, TDD) para versionamento.

Gabarito: letra A

Link permanente: /questoes/fg106574