Arquitetura de Software · FCC · 2026 | Questão sqc-fc077593

Arquitetura de SoftwareArquitetura de Software

Código: fc077593
Banca: FCC
Órgão: SEFAZ-SP
Ano: 2026
Nível: Superior

Cargo: Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)

A área de Analytics de uma Secretaria da Fazenda mantém múltiplos modelos em produção (inadimplência, fraude em NF-e, seleção para auditoria, previsão de arrecadação) e precisa garantir um ponto Único de verdade sobre qual versão de cada modelo está em produção, permitir a promoção controlada de modelos de staging para produção com critérios formais e aprovações, e manter histérico versionado com metadados (métricas, features, autor, datas) disponível para auditorias. O componente de uma arquitetura de MLOps que atende diretamente a esses requisitos é um

Afeature store corporativo, responsável por armazenar e servir variáveis derivadas reutilizáveis para treinamento e inferência pelos diferentes modelos.
Bmodel registry central, integrado ao pipeline de CI/CD, que armazena artefatos de modelo, metadados, histérico de versões e estágios como staging, production e archived.
Csistema de monitoramento e logging de inferências, com foco em métricas de latência, taxa de erro e disponibilidade das APIs de modelos em produção.
Drepositório Git único, com branches separados por modelo (fraude, inadimplência, auditoria, arrecadação), versionando o código-fonte das soluções analíticas
Ecatálogo de dados corporativo que descreve e documenta as tabelas tributárias do data/lake usadas como fonte para o treinamento dos modelos.

Revelar gabarito e comentário

GabaritoB — model registry central, integrado ao pipeline de CI/CD, que armazena artefatos de modelo, metadados, histérico de versões e estágios como staging, production e archived.

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”.

Componentes de MLOps: Model Registry

Gabarito: letra B. O model registry é o componente responsável por centralizar artefatos de modelos, seus metadados (métricas, features, autor, datas), versionamento e controle de estágios (staging, production, archived), atendendo diretamente aos requisitos de ponto único de verdade, promoção controlada e histórico auditável. As demais alternativas, embora relevantes no ecossistema de MLOps, não cumprem esse papel específico.

Alternativa A — ❌ Incorreta

Um feature store armazena e serve variáveis derivadas (features) reutilizáveis para treinamento e inferência. Ele não gerencia versões de modelos nem promove estágios; foca na consistência de dados entre ambientes, não na governança de artefatos de modelo.

Alternativa B — ✅ Correta ⟵ GABARITO

O model registry é exatamente o componente que provê um catálogo centralizado de modelos, com suporte a versionamento, metadados (datas, autor, métricas, hiperparâmetros) e transições entre estágios (staging, production, archived). Integrado a pipelines de CI/CD, ele possibilita promoção controlada com critérios formais e aprovações, mantendo um histórico imutável para auditoria. É o ponto único de verdade para qual versão de cada modelo está ativa.

Alternativa C — ❌ Incorreta

Sistemas de monitoramento e logging (como Prometheus, Grafana ou MLflow Tracking) focam em métricas operacionais de inferência (latência, taxa de erro, throughput). Não controlam versões nem estágios de modelos; são complementares ao model registry para observabilidade, mas não atendem aos requisitos de versionamento e promoção.

Alternativa D — ❌ Incorreta

Um repositório Git versiona código-fonte, mas modelos são artefatos binários (ou serializados) que exigem metadados específicos (métricas, features, autor) e gestão de estágios. Git não oferece promoção controlada com critérios formais out-of-the-box nem rastreabilidade de metadados de modelo de forma nativa – a prática de versionar modelos no Git é desaconselhada por esse motivo. A afirmação confunde controle de versão de código com governança de modelos.

Alternativa E — ❌ Incorreta

Um catálogo de dados (ex.: Apache Atlas, AWS Glue Catalog) descreve e documenta as fontes de dados (tabelas, arquivos) usadas para treinar modelos. Ele não gerencia artefatos de modelo nem seu ciclo de vida; é útil para linhagem de dados, mas não atende aos requisitos de ponto único de verdade sobre versões e promoção de modelos.

Gabarito: letra B – Model Registry central, integrado ao pipeline de CI/CD.

Link permanente: /questoes/fc077593