Microsoft AZ-400: Gestión de paquetes y gestión de artefactos — Guía de estudio

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

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

La gestión de paquetes es la columna vertebral de las compilaciones reproducibles, las implementaciones fiables y las cadenas de suministro seguras en Azure DevOps. Azure Artifacts centraliza el almacenamiento y la gobernanza de paquetes en todos los ecosistemas (NuGet, npm, Maven, Gradle y paquetes universales), a la vez que permite el almacenamiento en caché ascendente desde registros públicos y controles detallados para la promoción, retención y permisos. Combinado con la automatización del versionado semántico y las herramientas de seguridad/cumplimiento, le permite estandarizar cómo se producen, descubren, aprueban y consumen las dependencias internas y externas a escala.

Conceptos básicos de Azure Artifacts

Una fuente (feed) es la unidad de almacenamiento y control de acceso para los paquetes. Los equipos suelen organizar las fuentes por producto, plataforma o límite de confianza (p. ej., una fuente para todas las dependencias públicas de código abierto a través de orígenes ascendentes, una para bibliotecas internas compartidas y una por producto). Las fuentes admiten múltiples tipos de paquetes, cada uno con sus propias herramientas de cliente.

Las vistas (views) implementan un modelo de promoción controlado por fases dentro de una única fuente:

local: todos los paquetes recién publicados aparecen aquí.
prerelease: se utiliza para exponer compilaciones beta/nocturnas a los primeros adoptantes y a las canalizaciones de integración.
release: solo los paquetes aprobados para producción se promueven aquí para un consumo general. Los consumidores apuntan a una vista específica para evitar automáticamente el contenido inestable. Promueva o degrade versiones como parte de su proceso de lanzamiento para controlar el radio de impacto.

Los orígenes ascendentes (upstream sources) conectan una fuente a registros públicos (NuGet.org, npmjs.com, Maven Central). Cuando están habilitados, los desarrolladores resuelven las dependencias públicas a través de su fuente. Azure Artifacts actúa como proxy y almacena en caché de forma transparente las versiones exactas que se utilizan, mejorando la fiabilidad, permitiendo escenarios sin conexión a internet (air-gapped) y permitiéndole más tarde “congelar” el suministro deshabilitando nuevas descargas ascendentes. Puede definir qué orígenes ascendentes están habilitados por fuente para cumplir con las políticas.

La retención se aplica para reducir los costos de almacenamiento mientras se preserva lo que es importante. Defina políticas para mantener las últimas N versiones por paquete, retener solo las versiones promovidas a la vista de lanzamiento (release) y eliminar automáticamente los prelanzamientos (prereleases) antiguos. Ancle (pin) versiones específicas para eximirlas de la limpieza (p. ej., aquellas integradas en una rama de producto de larga duración). Alinee las ventanas de retención con los requisitos de auditoría y reversión (rollback) para equilibrar la trazabilidad con el costo de almacenamiento.

Los permisos de la fuente siguen el principio de mínimo privilegio:

Propietario (Owner): gestiona la configuración de la fuente, los permisos, las vistas y las políticas de retención.
Colaborador (Contributor): publica, retira de la lista, desaprueba y promueve paquetes; no puede cambiar la configuración a nivel de fuente.
Lector (Reader): solo puede restaurar/consumir; no puede modificar paquetes. Nota: “Collaborator” no es un rol de fuente en Azure Artifacts. Si encuentra ese término, asigne su capacidad prevista (a menudo “puede publicar”) al rol de Colaborador (Contributor) en Azure Artifacts.

Gestión de ecosistemas de paquetes

NuGet (dotnet/C#)

Versionado: Prefiera SemVer 2.0.0 (p. ej., 1.4.0, 1.4.1-alpha.3+build.45). Las etiquetas de prelanzamiento (pre-release) controlan la distribución a través de las vistas; los consumidores de la vista de lanzamiento (release) nunca encontrarán variantes -alpha/-beta.
Publicación: dotnet pack o nuget pack, y luego dotnet nuget push o nuget push a su punto de conexión (endpoint) de la fuente. Utilice las tareas NuGet de Azure Pipelines y promueva a las vistas de prelanzamiento (prerelease) o lanzamiento (release) en las puertas de calidad (quality gates).
Consumo: configure nuget.config con el URI de origen de la fuente (opcionalmente acotado a una vista). Restaure mediante dotnet restore o la tarea NuGet Restore.
Fuentes autenticadas: utilice el Azure Artifacts Credential Provider (integrado en los SDK de dotnet recientes) o la tarea de canalización NuGet Authenticate. Para los desarrolladores, inicie sesión a través de Visual Studio/Azure CLI; para la CI, otorgue los permisos de Lector (Reader) o Colaborador (Contributor) a la entidad de servicio de compilación (build service principal) según sea necesario.

npm (JavaScript/TypeScript)

Paquetes con ámbito (scoped): publique paquetes internos bajo un ámbito (scope) de organización, p. ej., @fabrikam/button. Los ámbitos se asignan de forma natural a los permisos de la fuente y permiten restringir el consumo entre proyectos.
.npmrc: establezca registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/, always-auth=true, y opcionalmente establezca @scope:registry=... para configuraciones con múltiples registros. En la CI, utilice la tarea npm Authenticate para inyectar un token de autenticación temporal. Para el desarrollo local, use npm login con un PAT (Token de Acceso Personal).
Registro privado: Azure Artifacts actúa como un registro npm privado con un origen ascendente a npmjs.com. Consuma solo desde la vista de lanzamiento (release) para bloquear los prelanzamientos (prereleases) no aprobados.

Maven y Gradle (Java/Kotlin)

Publicación (Maven): defina distributionManagement en pom.xml apuntando a su fuente y una entrada de servidor en settings.xml con las credenciales (PAT o conexión de servicio). Utilice mvn deploy o la tarea Maven en Azure Pipelines.
Publicación (Gradle): aplique el plugin maven-publish y configure repositories { maven { url = "https://pkgs.dev.azure.com/..." credentials { } } }, luego publique con gradle publish.
Resolución de dependencias: agregue el punto de conexión (endpoint) de su fuente (opcionalmente con el sufijo de la vista) a repositories en Gradle o a <repositories> en pom.xml para Maven. Adopte SNAPSHOT para las compilaciones de desarrollo y promueva las versiones de lanzamiento a la vista de lanzamiento (release) para los consumidores estables.

Paquetes universales (blobs binarios, scripts, modelos)

Versionado: siga un estilo SemVer o versiones enteras; cada publicación es inmutable. Utilice esto para artefactos que no encajan en los ecosistemas específicos de un lenguaje.
Tareas de publicación/descarga: utilice las tareas de Azure DevOps Universal Publish y Universal Download en las canalizaciones, o la CLI de Azure (az artifacts universal publish/download). Autentíquese mediante una conexión de servicio de Azure DevOps o una identidad con sesión iniciada.
Casos de uso: CLIs compartidos, módulos de IaC, datos de prueba, modelos de ML o activos multilingües donde necesite RBAC, retención y promoción, pero no herramientas específicas del lenguaje.

Controles de Seguridad y Cumplimiento

El escaneo de vulnerabilidades debe aplicarse en el momento del commit y de la compilación. Integre herramientas que identifiquen dependencias con vulnerabilidades conocidas y proporcionen orientación para su actualización. En muchos entornos de Azure DevOps, SonarQube se utiliza como parte de la estrategia de quality gate para señalar problemas, incluyendo reglas que exponen riesgos en las dependencias; puede complementarlo con herramientas SCA dedicadas (p. ej., Snyk, Mend/WhiteSource o Black Duck) para una cobertura de CVE más exhaustiva entre ecosistemas. Para .NET, dotnet list package --vulnerable y para npm, npm audit pueden proporcionar señales adicionales; para Java, OWASP Dependency-Check puede añadirse como un paso de compilación.

El cumplimiento de licencias se garantiza escaneando SBOMs o manifiestos contra una lista blanca (allowlist) de licencias aprobadas. Black Duck se añade comúnmente a Azure Pipelines para bloquear compilaciones cuando se detectan licencias restringidas. Almacene los informes de escaneo como artefactos del pipeline y adjúntelos a las releases para facilitar la auditoría.

La gestión de paquetes permitidos/bloqueados se implementa mejor como una política en lugar de excepciones ad hoc:

Restrinja a los consumidores a la vista de release; promueva únicamente las versiones verificadas.
Deshabilite las descargas nuevas de upstreams cuando necesite una congelación, asegurando que solo estén disponibles las versiones en caché.
Utilice scopes de npm y permisos por feed para restringir los espacios de nombres.
Añada verificaciones en el pipeline para que fallen las compilaciones con paquetes o licencias no permitidos, y utilice la promoción de artefactos como flujo de trabajo de aprobación.

La auditoría y la gobernanza se benefician de los feeds centralizados con almacenamiento en caché de upstreams: se obtiene un único punto de control para la entrada de paquetes, historiales inmutables y una procedencia consistente para la generación de SBOM.

Automatización del Versionado y Economía de la Retención

El versionado semántico es más fácil de mantener con automatización:

GitVersion lee su historial de Git y las convenciones de nomenclatura de ramas para calcular versiones de forma predecible (p. ej., main produce 1.4.0, feature/* produce 1.5.0-feature.3). Configure el modo (Mainline o Continuous Delivery), las etiquetas de pre-lanzamiento (pre-release) y el origen de los tags. Inyecte la versión calculada en la propiedad version de csproj, package.json o Gradle antes de empaquetar.
El incremento automático de versión puede seguir la semántica de los commits o las etiquetas de los PR. Por ejemplo, chore no incrementa, feat incrementa la versión menor, fix incrementa el parche; breaking-change incrementa la versión mayor. Utilice un paso del pipeline para establecer el buildNumber y pasar la versión a las tareas de empaquetado/publicación (pack/publish).
Las etiquetas de pre-lanzamiento (pre-release) deben reflejar la intención de la rama (p. ej., -alpha en ramas feature, -rc en ramas release). Publique las prereleases en la vista de pre-lanzamiento y promuévalas a la vista de release tras una puesta en escena (staging) exitosa.

La retención y la gestión de costos de almacenamiento requieren una política proactiva:

Limpieza automática: configure la retención por feed para eliminar versiones más antiguas y no promovidas después de N días/versiones. Extienda los períodos para bibliotecas críticas con horizontes de soporte largos.
Fijación (Pinning): fije explícitamente las versiones que están integradas en productos de larga duración o en instantáneas de cumplimiento para excluirlas de la eliminación.
Optimización del almacenamiento: prefiera el almacenamiento en caché de upstreams en lugar de publicar localmente duplicados de paquetes públicos, y consolide los feeds donde sea práctico para reducir la sobrecarga. Supervise el crecimiento del almacenamiento del feed y ajuste los umbrales de la política periódicamente.

Detalles de los orígenes upstream

NuGet: conéctese a https://api.nuget.org/v3/index.json como upstream para usar como proxy y caché de los paquetes de NuGet.org.
npm: conéctese a https://registry.npmjs.com para almacenar en caché las dependencias de npmjs.com detrás de su feed autenticado.
Maven: conéctese a Maven Central (p. ej., https://repo.maven.apache.org/maven2) para que los consumidores empresariales obtengan los paquetes a través de su feed con una única URL.

### Caso práctico

Adobe necesita estandarizar la gobernanza de paquetes en múltiples nubes e idiomas, al mismo tiempo que reduce las interrupciones causadas por la inestabilidad de los registros públicos y aplica políticas de licencias. Los equipos publican artefactos internos de NuGet, npm y Maven y comparten grandes herramientas de CLI que funcionan entre lenguajes.

Establecer feeds centralizados y upstreams

Acción: Crear tres feeds de Azure Artifacts: “oss-upstream” (con upstreams a NuGet.org, npmjs.com, Maven Central), “shared-libs” (bibliotecas internas) y “productA” (paquetes a nivel de aplicación). Habilitar vistas (local, prerelease, release) en todos los feeds.
Justificación: “oss-upstream” se convierte en el único punto de entrada y caché; “shared-libs” y “productA” separan los límites de confianza y los flujos de trabajo de promoción.

Configurar el consumo de clientes a través de vistas

Acción: Apuntar los repositorios de nuget.config, .npmrc, settings.xml/Gradle a la vista release de cada feed para los consumidores en tiempo de ejecución, y a la vista prerelease para los pipelines de pruebas de integración.
Justificación: Las vistas garantizan que solo los paquetes promocionados y verificados lleguen a los consumidores de producción sin necesidad de cambiar las configuraciones del cliente.

Implementar la publicación con versionado semántico

Acción: Añadir GitVersion a la CI para bibliotecas y aplicaciones. Impulsar la inyección de la versión en los campos de versión de dotnet pack, npm version (sin etiquetado de Git, controlado por el pipeline) y Gradle/Maven. Publicar en la vista local; promover a prerelease tras una CI exitosa; promover automáticamente a release después de las pruebas de staging.
Justificación: El versionado determinista alineado con el flujo de Git asegura etiquetas de pre-lanzamiento coherentes y promociones listas para la automatización.

Asegurar los feeds autenticados y la experiencia del desarrollador

Acción: Usar las tareas NuGet Authenticate y npm Authenticate en los pipelines; habilitar el Azure Artifacts Credential Provider para las máquinas de los desarrolladores; configurar los servidores de settings.xml de Maven con PATs rotados a través de grupos de variables de Azure DevOps.
Justificación: La autenticación transparente y basada en tokens evita la proliferación de credenciales y soporta restauraciones no interactivas en la CI.

Aplicar políticas de vulnerabilidades y licencias

Acción: Añadir quality gates de SonarQube a las compilaciones; integrar Black Duck para aplicar listas blancas de licencias y bloquear compilaciones con licencias no permitidas o CVEs de alta severidad. Para npm y .NET, ejecutar npm audit y dotnet list package --vulnerable; publicar los SBOMs como artefactos de compilación.
Justificación: Múltiples escáneres complementarios reducen los puntos ciegos; Black Duck proporciona cumplimiento de licencias a escala, mientras que SonarQube y las herramientas del ecosistema detectan regresiones de seguridad de forma temprana.

Controlar la entrada y congelar cuando sea necesario

Acción: Permitir descargas de upstream solo desde “oss-upstream”; deshabilitar nuevas entradas de upstream durante la respuesta a incidentes para congelar el suministro. Confiar en los paquetes en caché para mantener las compilaciones.
Justificación: Un punto de estrangulamiento (choke point) permite una contención rápida si un registro público está comprometido o es inestable.

Aplicar retención y anclaje (pinning)

Acción: Retener las últimas 5 versiones para shared-libs y productA; eliminar las versiones no promocionadas con más de 30 días de antigüedad; anclar las versiones vinculadas a ramas LTS y a bases de referencia regulatorias.
Justificación: La limpieza automatizada reduce los costos de almacenamiento, mientras que el anclaje preserva la auditabilidad y la capacidad de reversión (rollback).

Delegar acceso con el mínimo privilegio

Acción: Asignar el rol de Owners (propietarios) a ingeniería de plataforma; Contributors (colaboradores) a los mantenedores de bibliotecas que deben publicar/declarar obsoletas; Readers (lectores) a los equipos de producto que solo consumen artefactos de release.
Justificación: Alinea las capacidades con las responsabilidades; los desarrolladores pueden deslistar/declarar obsoletos (unlist/deprecate) paquetes sin necesidad de amplios derechos administrativos.

Paquetes universales para herramientas multi-lenguaje

Acción: Publicar CLIs internas y módulos de IaC como paquetes universales (Universal packages) a través de las tareas Universal Publish/Download; versionarlos semánticamente y promoverlos a través de vistas.
Justificación: Proporciona RBAC, retención y promoción para activos no específicos de un lenguaje con un modelo de consumo consistente.

Medir e iterar

Acción: Monitorear el almacenamiento de los feeds, las tasas de acierto de la caché (cache hit rates) y los tiempos de entrega para la promoción (promotion lead times); ajustar los umbrales de retención, las políticas de upstream y los criterios de promoción en consecuencia.
Justificación: El ajuste continuo mantiene la fiabilidad, la eficiencia de costos y el cumplimiento a medida que la escala del portafolio evoluciona.

← Monitorización · Todos los dominios · Planificación ágil y gestión del trabajo →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →