Microsoft AZ-400: Gerenciamento de Pacotes e Gerenciamento de Artefatos — Guia de estudos

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O gerenciamento de pacotes é a espinha dorsal para builds reprodutíveis, implantações confiáveis e cadeias de suprimentos seguras no Azure DevOps. O Azure Artifacts centraliza o armazenamento e a governança de pacotes em todos os ecossistemas — NuGet, npm, Maven, Gradle e pacotes Universais — ao mesmo tempo que permite o cache de fontes upstream de registros públicos e controles granulares para promoção, retenção e permissões. Combinado com a automação de versionamento semântico e ferramentas de segurança/conformidade, ele permite que você padronize como as dependências internas e externas são produzidas, descobertas, aprovadas e consumidas em escala.

Conceitos Essenciais do Azure Artifacts

Um feed é a unidade de armazenamento e controle de acesso para pacotes. As equipes geralmente organizam os feeds por produto, plataforma ou limite de confiança (por exemplo, um feed para todas as dependências de OSS públicas via upstream, um para bibliotecas internas compartilhadas e um por produto). Os feeds suportam múltiplos tipos de pacotes, cada um com suas próprias ferramentas de cliente.

As Views implementam um modelo de promoção controlada dentro de um único feed:

local: todos os pacotes recém-publicados aparecem aqui
prerelease: usado para expor builds beta/noturnos para early adopters e pipelines de integração
release: apenas pacotes aprovados para produção são promovidos para cá para consumo amplo Os consumidores apontam para uma view específica para evitar automaticamente conteúdo instável. Promova ou rebaixe versões como parte do seu processo de lançamento para controlar o raio de impacto.

Fontes upstream (Upstream sources) conectam um feed a registros públicos (NuGet.org, npmjs.com, Maven Central). Quando habilitado, os desenvolvedores resolvem dependências públicas através do seu feed. O Azure Artifacts atua como proxy e armazena em cache de forma transparente as versões exatas que são usadas, melhorando a confiabilidade, permitindo cenários isolados (air-gapped) e permitindo que você posteriormente “congele” o fornecimento, desativando novos downloads de fontes upstream. Você pode definir o escopo de quais fontes upstream estão habilitadas por feed para atender às políticas.

A retenção é aplicada para reduzir os custos de armazenamento, preservando o que é importante. Defina políticas para manter as N versões mais recentes por pacote, reter apenas as versões promovidas para a view de release e excluir automaticamente pré-lançamentos antigos. Fixe (pin) versões específicas para isentá-las da limpeza (por exemplo, aquelas incorporadas em um branch de produto de longa duração). Alinhe as janelas de retenção com os requisitos de auditoria e reversão para equilibrar a rastreabilidade com o custo de armazenamento.

As permissões do feed seguem o princípio do menor privilégio:

Owner: gerencia configurações do feed, permissões, views e políticas de retenção
Contributor: publica, remove da lista, deprecia e promove pacotes; não pode alterar as configurações no nível do feed
Reader: apenas restaura/consome; não pode modificar pacotes Nota: “Collaborator” não é uma função de feed do Azure Artifacts. Se você encontrar esse termo, mapeie sua capacidade pretendida (geralmente “pode publicar”) para a função de Contributor no Azure Artifacts.

Gerenciando Ecossistemas de Pacotes

NuGet (dotnet/C#)

Versionamento: Prefira SemVer 2.0.0 (ex: 1.4.0, 1.4.1-alpha.3+build.45). Rótulos de pré-lançamento (pre-release) controlam a distribuição por meio de views; os consumidores da view de release nunca encontram variantes -alpha/-beta.
Publicação:

undefined

, depois

undefined

para o endpoint do seu feed. Use as tarefas NuGet do Azure Pipelines e promova para as views prerelease/release em portões de qualidade (quality gates).

Consumo: configure o

undefined

com o URI de origem do feed (opcionalmente com escopo para uma view). Restaure via

undefined

ou a tarefa NuGet Restore.

Feeds autenticados: use o Azure Artifacts Credential Provider (integrado em SDKs dotnet recentes) ou a tarefa de pipeline NuGet Authenticate. Para desenvolvedores, faça login via Visual Studio/Azure CLI; para CI, conceda à service principal do build as permissões de Reader/Contributor conforme necessário.

npm (JavaScript/TypeScript)

Pacotes com escopo (Scoped packages): publique pacotes internos sob um escopo de organização, ex: @fabrikam/button. Escopos mapeiam naturalmente para as permissões do feed e permitem restringir o consumo entre projetos.
.npmrc: defina

undefined

e, opcionalmente, defina

undefined

para configurações com múltiplos registros. Em CI, use a tarefa npm Authenticate para injetar um token de autenticação temporário. Para desenvolvimento local,

undefined

com um PAT.

Registro privado: O Azure Artifacts atua como um registro npm privado com upstream para o npmjs.com. Consuma apenas da view de release para bloquear pré-lançamentos não aprovados.

Maven e Gradle (Java/Kotlin)

Publicação (Maven): defina

undefined

apontando para o seu feed e uma entrada de servidor no

undefined

com credenciais (PAT ou service connection). Use

undefined

ou a tarefa Maven no Azure Pipelines.

Publicação (Gradle): aplique o plugin

undefined

e configure

undefined

e depois publique com

undefined

Resolução de dependências: adicione o endpoint do seu feed (opcionalmente com o sufixo da view) a

undefined

no Gradle ou

undefined

para o Maven. Adote

undefined

para builds de desenvolvimento e promova as versões de lançamento para a view de release para consumidores estáveis.

Pacotes Universais (Universal packages - blobs binários, scripts, modelos)

Versionamento: siga o estilo SemVer ou versões inteiras; cada publicação é imutável. Use isso para artefatos que não se encaixam em ecossistemas específicos de linguagem.
Tarefas de publicação/download: use as tarefas do Azure DevOps Universal Publish e Universal Download em pipelines, ou a Azure CLI (

undefined

). Autentique-se via service connection do Azure DevOps ou identidade conectada.

Casos de uso: CLIs compartilhados, módulos de IaC, dados de teste, modelos de ML ou ativos multilíngue onde você precisa de RBAC, retenção e promoção, mas sem ferramentas específicas de linguagem.

Controles de Segurança e Conformidade

A varredura de vulnerabilidades deve ser imposta no momento do commit e do build. Integre ferramentas que identificam dependências com vulnerabilidades conhecidas e fornecem orientação para atualização. Em muitos ambientes do Azure DevOps, o SonarQube é usado como parte da estratégia de quality gate para sinalizar problemas, incluindo regras que expõem riscos de dependência; você pode complementá-lo com ferramentas de SCA dedicadas (ex: Snyk, Mend/WhiteSource ou Black Duck) para uma cobertura mais exaustiva de CVEs entre ecossistemas. Para .NET, dotnet list package --vulnerable e para npm, npm audit podem fornecer sinais adicionais; para Java, o OWASP Dependency-Check pode ser adicionado como um passo do build.

A conformidade de licenças é garantida pela varredura de SBOMs ou manifestos em comparação com uma lista de permissões (allowlist) de licenças aprovadas. O Black Duck é comumente adicionado aos Azure Pipelines para bloquear builds quando licenças restritas são detectadas. Armazene os relatórios de varredura como artefatos do pipeline e anexe-os às releases para fins de auditoria.

Pacotes permitidos/bloqueados são melhor implementados como política em vez de exceções ad hoc:

Restrinja os consumidores à visualização (view) de release; promova apenas versões verificadas.
Desabilite novos downloads do upstream quando precisar de um congelamento (freeze), garantindo que apenas as versões em cache estejam disponíveis.
Use escopos do npm e permissões por feed para restringir namespaces.
Adicione verificações no pipeline para falhar builds que usem pacotes ou licenças não permitidos e use a promoção de artefatos como o fluxo de trabalho de aprovação.

Auditoria e governança se beneficiam de feeds centralizados com cache de upstream: você obtém um ponto único de estrangulamento para a entrada de pacotes, históricos imutáveis e procedência consistente para a geração de SBOM.

Automação de Versionamento e Economia de Retenção

O versionamento semântico é mais fácil de manter com automação:

O GitVersion lê seu histórico do Git e as convenções de nomenclatura de branches para calcular versões de forma previsível (ex: main produz 1.4.0, feature/* produz 1.5.0-feature.3). Configure o modo (Mainline ou Continuous Delivery), os rótulos (labels) de pré-release e as fontes de tags. Injete a versão calculada no csproj, package.json ou na propriedade de versão do Gradle antes de empacotar.
O incremento automático de versão pode seguir a semântica do commit ou os rótulos do PR. Por exemplo, chore não incrementa, feat incrementa a versão minor, fix incrementa a patch; breaking-change incrementa a major. Use um passo do pipeline para definir o buildNumber e passar a versão para as tarefas de pack/publish.
Os rótulos de pré-release devem refletir a intenção da branch (ex: -alpha em branches de feature, -rc em branches de release). Publique pré-releases na visualização (view) de pré-release e promova para a de release após uma homologação bem-sucedida.

A retenção e o gerenciamento de custos de armazenamento exigem uma política proativa:

Limpeza automática: configure a retenção por feed para excluir versões mais antigas e não promovidas após N dias/versões. Estenda os períodos para bibliotecas críticas com longos horizontes de suporte.
Fixação (Pinning): fixe explicitamente as versões que estão incorporadas em produtos de longa duração ou em snapshots de conformidade para excluí-las da exclusão.
Otimização de armazenamento: prefira o cache de upstream em vez de publicar localmente duplicatas de pacotes públicos e consolide os feeds sempre que prático para reduzir a sobrecarga (overhead). Monitore o crescimento do armazenamento do feed e ajuste os limites da política periodicamente.

Especificidades das fontes upstream:

NuGet: conecte-se a https://api.nuget.org/v3/index.json como upstream para usar como proxy e cachear pacotes do NuGet.org.
npm: conecte-se a https://registry.npmjs.com para cachear dependências do npmjs.com por trás do seu feed autenticado.
Maven: conecte-se ao Maven Central (ex: https://repo.maven.apache.org/maven2) para que os consumidores da empresa busquem pacotes através do seu feed com uma única URL.

### Cenário de Problema Prático

A Adobe precisa padronizar a governança de pacotes em múltiplas nuvens e linguagens, ao mesmo tempo em que reduz interrupções causadas pela instabilidade de registros públicos e impõe políticas de licenciamento. As equipes publicam artefatos internos NuGet, npm e Maven e compartilham grandes ferramentas de CLI (cross-language).

Estabelecer feeds centralizados e upstreams

Ação: Criar três feeds no Azure Artifacts: “oss-upstream” (com upstreams para NuGet.org, npmjs.com, Maven Central), “shared-libs” (bibliotecas internas) e “productA” (pacotes de nível de aplicação). Habilitar views (local, prerelease, release) em todos os feeds.
Justificativa: O feed “oss-upstream” torna-se o ponto único de entrada e cache; os feeds “shared-libs” e “productA” separam os limites de confiança e os fluxos de trabalho de promoção.

Configurar o consumo do cliente através de views

Ação: Apontar os repositórios nos arquivos nuget.config, .npmrc e settings.xml/Gradle para a view release de cada feed para consumidores de tempo de execução (runtime), e para a view prerelease para os pipelines de teste de integração.
Justificativa: As views garantem que apenas pacotes promovidos e verificados cheguem aos consumidores de produção, sem a necessidade de alterar as configurações do cliente.

Implementar a publicação com versionamento semântico

Ação: Adicionar o GitVersion ao CI para bibliotecas e aplicações. Conduzir a injeção de versão nos comandos dotnet pack, npm version (sem a criação de tags no Git, que é controlada pelo pipeline) e nos campos de versão do Gradle/Maven. Publicar na view local; promover para prerelease após o sucesso do CI; promover automaticamente para release após os testes de staging.
Justificativa: O versionamento determinístico alinhado ao fluxo do Git garante rótulos de pré-lançamento (pre-release) coerentes e promoções prontas para automação.

Proteger feeds autenticados e a experiência do desenvolvedor

Ação: Usar as tarefas NuGet Authenticate e npm Authenticate nos pipelines; habilitar o Azure Artifacts Credential Provider nas máquinas dos desenvolvedores; configurar os servidores no settings.xml do Maven com PATs rotacionados através de grupos de variáveis do Azure DevOps.
Justificativa: A autenticação transparente baseada em token evita a proliferação de credenciais e suporta restaurações não interativas no CI.

Aplicar políticas de vulnerabilidade e licença

Ação: Adicionar quality gates do SonarQube aos builds; integrar o Black Duck para impor listas de permissão (allowlists) de licenças e bloquear builds com licenças não permitidas ou CVEs de alta severidade. Para npm e .NET, executar npm audit e dotnet list package --vulnerable; publicar SBOMs como artefatos de build.
Justificativa: Múltiplos scanners complementares reduzem os pontos cegos; o Black Duck oferece conformidade de licenças em escala, enquanto o SonarQube e as ferramentas do ecossistema detectam regressões de segurança precocemente.

Controlar a entrada e congelar quando necessário

Ação: Permitir downloads de upstream apenas a partir do feed “oss-upstream”; desabilitar novas entradas de upstream durante a resposta a incidentes para congelar o fornecimento. Confiar nos pacotes em cache para manter os builds.
Justificativa: Um ponto de estrangulamento (choke point) permite a contenção rápida caso um registro público esteja comprometido ou instável.

Aplicar retenção e fixação (pinning)

Ação: Reter as últimas 5 versões para os feeds “shared-libs” e “productA”; excluir versões não promovidas com mais de 30 dias; fixar (pin) versões vinculadas a branches LTS e a baselines regulatórios.
Justificativa: A limpeza automatizada reduz o custo de armazenamento, enquanto a fixação (pins) preserva a auditabilidade e a capacidade de rollback.

Delegar acesso com privilégio mínimo

Ação: Atribuir a permissão de Owners (Proprietários) à equipe de engenharia de plataforma; Contributors (Colaboradores) aos mantenedores de bibliotecas que precisam publicar/depreciar; Readers (Leitores) às equipes de produto que apenas consomem artefatos da view release.
Justificativa: Alinha as capacidades às responsabilidades; os desenvolvedores podem remover da lista (unlist) ou depreciar pacotes sem precisar de direitos administrativos amplos.

Pacotes universais (Universal packages) para ferramentas multilinguagem

Ação: Publicar CLIs internas e módulos de IaC como Universal packages através das tarefas Universal Publish/Download; versioná-los semanticamente e promovê-los através de views.
Justificativa: Fornece RBAC, retenção e promoção para ativos não específicos de uma linguagem com um modelo de consumo consistente.

Medir e iterar

Ação: Monitorar o armazenamento do feed, as taxas de acerto do cache (cache hit rates) e os tempos de lead para promoção; ajustar os limites de retenção, as políticas de upstream e os critérios de promoção conforme necessário.
Justificativa: O ajuste contínuo mantém a confiabilidade, a eficiência de custos e a conformidade à medida que a escala do portfólio evolui.

← Monitoramento · Todos os domínios · Planejamento Ágil e Gerenciamento de Trabalho →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →