Laura Bolaños for AWS Community Builders

Posted on Sep 7 Originally published at builder.aws.com

Camino a AWS Certified Developer — Associate (DVA-C03): qué cambia y por qué

#aws #certification #developerassociate

El 1 de septiembre de 2026, AWS anunció oficialmente cambios de versión en varios de sus exámenes. Entre ellos, AWS Certified Developer — Associate. En este artículo te comparto mi experiencia con la versión actual que rendí y los cambios de lo que se viene.

🎯 Hasta el 30 de noviembre de 2026 se puede rendir la versión actual DVA-C02. El registro para DVA-C03 abre el 27 de octubre de 2026, con disponibilidad general (GA) a partir del 1 de diciembre de 2026.*

Hace unos meses escribí sobre mi experiencia rindiendo el examen DVA-C02, con los temas clave que profundicé y algunos tips de estudio. AWS acaba de anunciar la actualización a DVA-C03, y me pareció importante escribir esta continuación: no para reemplazar ese artículo, sino para sumarle lo nuevo. Si estás por empezar a estudiar hoy, mi recomendación es leer ambos: la base técnica de servicios (Lambda, DynamoDB, API Gateway, Cognito, etc.) sigue totalmente vigente, y acá vas a encontrar el "qué se agrega" y el "por qué" de esta actualización.

El calendario a tener en cuenta según el anuncio:

Por qué actualizan el examen

El blog oficial de AWS Training and Certification plantea que el rol de developer ya no es solamente escribir código de aplicación. Hoy un developer usa herramientas de AI-assisted development para generar, revisar y optimizar código; integra servicios de AI administrados dentro de sus aplicaciones; y tiene que asegurar las interacciones de agentes de AI. Es decir, AI-assisted development pasa a ser una competencia central del rol, no un "extra".

Esto no significa que el examen se convierta en una certificación de AI. De hecho, el anuncio oficial aclara qué queda fuera de alcance: prompt engineering, diseño de RAG, selección de modelos de AI, Amazon SageMaker AI y diseño de frameworks de gobernanza de AI. Es decir, no van a pedirte que diseñes soluciones de AI desde cero, sino que sepas cómo un developer integra y asegura estas capacidades dentro del ciclo de vida de una aplicación en AWS.

Datos generales de la nueva versión de examen

Según el anuncio, son los mismos parámetros generales que ya conocemos de DVA-C02:

Duración: 130 minutos
Preguntas: 65 (50 puntuadas, 15 no puntuadas)
Puntaje de aprobación: 720 sobre 1000
Precio: 150 USD
Idiomas: todos los actualmente soportados, disponibles desde el lanzamiento
Modalidad: Pearson VUE (centro de examen u online proctoring)

Lo estructural: los 4 dominios se mantienen

Buena noticia para quien ya venía estudiando: los dominios y sus porcentajes no cambian:

Development with AWS Services — 30%
Security — 26%
Testing and Deployment — 22%
Troubleshooting and Optimization — 22%

Lo que cambia es el contenido dentro de cada dominio: se consolidan skills que estaban demasiado fragmentadas, y se agregan skills nuevas relacionadas a AI y a Containers.

⭐ Tip: si ya armaste tu planilla de "brechas de conocimiento" como sugería en mi artículo anterior, no la tires. Vas a poder reusar casi todo el contenido de Lambda, DynamoDB, API Gateway, Cognito, SQS/SNS, EventBridge, Step Functions, CI/CD, CloudFormation/CDK, seguridad de datos y STS. Lo que necesitás es agregar una columna nueva para lo que sigue.

Incorporación 1: una Task completa de seguridad de AI (Task 2.3)

Esta es, para mí, la adición más relevante de todo el cambio. Dentro del dominio de Security se agrega la Task 2.3 — AI security, con 5 skills nuevas:

Gestión de accesos para servicios de AI. Aplica el mismo principio de mínimo privilegio que ya se usa para Lambda o DynamoDB, pero ahora sobre quién puede invocar un modelo, un agente o una Knowledge Base. Por ejemplo, se puede restringir con una política de recursos qué rol de IAM puede ejecutar bedrock:InvokeModel sobre un modelo específico.
Controles de privacidad de datos, principalmente vía VPC endpoints (AWS PrivateLink) y la garantía de que los inputs/outputs no se usen para entrenar modelos. Este punto no es solo teórico: el servicio nunca comparte tus datos con los proveedores de modelos ni los usa para entrenar foundation models, y todas las invocaciones se mantienen dentro de la red de AWS. Para reforzar el aislamiento de red, la guía de VPC interface endpoints de Bedrock explica que se puede crear un endpoint de interfaz (AWS PrivateLink) usando nombres de servicio como com.amazonaws.region.bedrock-runtime o com.amazonaws.region.bedrock-agent-runtime, evitando así exponer el tráfico a internet.
Content filtering y protección contra prompt injection. Acá entra Amazon Bedrock Guardrails como mecanismo central. Los content filters detectan categorías de contenido dañino (odio, insultos, contenido inapropiado, violencia, mala conducta) y, dentro de esa misma categoría, un filtro específico de prompt attacks detecta jailbreaks, prompt injections y prompt leakages. Hay que entender la diferencia entre prompt injection directo (el usuario intenta manipular el prompt) e indirecto (la instrucción maliciosa viene escondida en un dato externo, como un documento o una página web, que el agente procesa sin que el usuario lo note).
Seguridad en interacciones de agentes de AI: autorización de uso de tools, aislamiento de sesión (session isolation) y flujos de aprobación humana (human-in-the-loop). Esto conecta directo con Amazon Bedrock AgentCore Identity: este servicio provee autenticación, autorización y gestión de credenciales diseñada específicamente para agentes de AI y workloads automatizados, con identidades de workload que tienen atributos especializados para habilitar capacidades específicas de agentes, manteniendo compatibilidad con patrones estándar de identidad de workload de la industria.
Protección de contenido sensible en logs de monitoreo. Amazon Bedrock permite habilitar model invocation logging hacia CloudWatch Logs o S3, pero por defecto esos logs pueden incluir el input/output completo de cada invocación. El mecanismo para proteger datos sensibles ahí es Amazon Bedrock Guardrails (vía la API ApplyGuardrail), que permite enmascarar esa información antes de que quede registrada — mismo espíritu que ya aplicabas con StreamViewType: KEYS_ONLY en DynamoDB Streams para no exponer información sensible.

⭐ Tip de estudio: si en DVA-C02 profundizaste STS, IAM trust relationships y KMS, ya tenés el 70% del razonamiento necesario para esta Task nueva. Lo que hay que sumar es el vocabulario y los mecanismos específicos de AI (Guardrails, AgentCore Identity, PrivateLink hacia Bedrock).

Incorporación 2: AI-assisted development transversal a los 4 dominios

Esto se distribuye en los cuatro dominios:

Domain 1 (Development): generación de código y revisión automatizada.
Domain 3 (Testing and Deployment): automatización de pruebas y pruebas de regresión, y soporte para workflows de CI/CD incluyendo aprobaciones automatizadas de despliegue.
Domain 4 (Troubleshooting and Optimization): análisis de errores, sugerencias de troubleshooting y recomendaciones de optimización de performance.

Un dato importante para no confundirse en el estudio: según la documentación oficial sobre el fin de soporte de los plugins IDE de Amazon Q Developer, AWS discontinuará el soporte de estos plugins el 30 de abril de 2027, y como alternativa para capacidades similares (coding agéntico, chat, soporte MCP) recomienda explorar Kiro.
Kiro es el IDE agéntico que propone spec-driven development: convierte un prompt en requerimientos, diseño de sistema y lista de tareas antes de generar código, en lugar de saltar directo a la implementación. Como developer, puede que el examen busca que entiendas el concepto de spec-driven development como enfoque de AI-assisted development.

⭐ Tip: una lectura valida es entender en qué punto del ciclo de vida de desarrollo entra cada práctica de AI-assisted development, que es como está formulada la skill en cada dominio.

Incorporación 3: Gestión de contenedores

Construcción y gestión de imágenes de contenedor con Amazon ECR.
Despliegue de aplicaciones containerizadas con Amazon ECS, Amazon EKS y AWS Fargate.

En mi artículo anterior ya mencionaba ECS/EKS dentro de "Contenedores ECS, EKS" enfocado en monitoreo y observabilidad (CloudWatch, X-Ray) ya que no se me presentaron otro tipo de preguntas. Pero la diferencia es que en la nueva versión del examen amplía el foco: no solo observar un contenedor en ejecución, sino todo el ciclo — construir la imagen, subirla a ECR, y decidir entre ECS, EKS o Fargate según el caso de uso (gestión de clúster propia vs. serverless de contenedores).

⭐ Tip de laboratorio: armá una imagen simple, subila a ECR, y desplegarla primero en ECS con Fargate y después evaluá qué cambiaría si migraras esa misma imagen a EKS. La diferencia conceptual entre "quién administra el plano de control y los nodos" es justamente lo que suelen evaluar en preguntas de este estilo.

Incorporación 4: Nuevos servicios que entran en el alcance del examen

Amazon Bedrock → el servicio administrado para trabajar con modelos fundacionales.
Amazon Bedrock AgentCore → la plataforma para construir, desplegar y operar agentes de AI de forma segura y a escala, sin gestionar infraestructura. Se compone de Runtime (entorno serverless para correr agentes), Memory (memoria de corto y largo plazo), Gateway, Identity, herramientas built-in (ejecución de código en sandbox, browser tool) y Observability (monitoreo vía CloudWatch). Para un developer, dos piezas son especialmente relevantes:
- Gateway, porque permite convertir APIs existentes (OpenAPI, Smithy) y funciones AWS Lambda en tools compatibles con el protocolo MCP (Model Context Protocol), sin tener que gestionar esa infraestructura — reutiliza directo el conocimiento de Lambda/API Gateway que ya tenés de DVA-C02.
- Identity, porque conecta directo con la Task 2.3 de seguridad que nombré más arriba.
Amazon Q → el asistente conversacional generativo para entender, construir, extender y operar aplicaciones y recursos de AWS.
Kiro → como comenté arriba, el IDE agéntico de spec-driven development.
Amazon Data Firehose → para entrega de streams de datos a destinos como S3, Redshift o servicios de terceros; relevante si tu arquitectura de eventos (la que ya veías con EventBridge y Kinesis Data Streams) necesita alimentar pipelines de AI o analítica.
AWS PrivateLink → ya mencionado en la Task de AI security, pero también entra como servicio in-scope de forma general, para conexiones privadas VPC-a-servicio sin pasar por internet.

Lo que se consolida (menos memorizar features aislados, más criterio)

Se aclara que varias skills fragmentadas se agrupan en unidades más grandes:

Área	Antes (DVA-C02)	Ahora (DVA-C03)
DynamoDB	4 skills separadas	1 skill integral
Seguridad (cifrado y datos sensibles)	13 skills en 2 tasks	7 skills en 1 task
Testing	11 skills en 2 tasks	5 skills en 1 task
Observability	8 skills	5 skills
Optimization	9 skills	6 skills

En la práctica, significa que el examen deja de preguntar detalles muy puntuales y aislados, y empieza a evaluar más el razonamiento integrado sobre un tema (por ejemplo, DynamoDB completo como una sola competencia, en vez de partir claves, índices, capacidad y TTL en preguntas separadas). Si con la guía actual DVA-C02 ya estudiaste estos temas a fondo como yo, no vas a tener que aprender contenido nuevo acá. El cambio es más de "cómo te lo preguntan".

Cómo armaría el plan de estudio hoy hasta esperar el detalle de la nueva guía de examen

Base técnica: seguí usando mi artículo de DVA-C02 como guía de los servicios core (Lambda, DynamoDB, API Gateway, Cognito, SQS/SNS, EventBridge, Step Functions, S3, CI/CD, CDK/CloudFormation, CloudWatch/X-Ray, seguridad de datos y STS). Ahí no cambió la profundidad requerida.
Sumá una capa de AI aplicada al developer: entendé conceptualmente Amazon Bedrock, AgentCore (sobre todo Gateway e Identity), Amazon Q Developer y Kiro — no como usuario experto, sino como developer que decide cuándo y cómo integrarlos, y qué controles de seguridad aplicar (Guardrails, PrivateLink, aislamiento de sesión, human-in-the-loop).
Profundizá contenedores end-to-end: ECR para las imágenes, y el criterio de decisión entre ECS, EKS y Fargate.
Repasá la guía de examen oficial completa apenas se publique (disponible cuando abra el registro, el 27 de octubre de 2026), porque ahí van a estar los task statements detallados de cada skill.
Mantené la costumbre que ya recomendaba antes: hacé laboratorios chicos de todo lo anterior y practicar muchas preguntas de examen, más que memorizar teoría aislada.

⭐ Y el mismo disclaimer que hice en el artículo anterior sigue más vigente que nunca: cuidado con usar AI para el estudio profundo de servicios sin chequear contra documentación oficial — pueden aparecer alucinaciones si se utiliza el conocimiento del modelo que uses. Contrastá contra la documentación oficial via los MCP oficiales de AWS:
"awslabs.aws-documentation-mcp-server" y "aws-knowledge-mcp-server"

Conclusión: Si estás arrancando de cero con esta certificación, te recomiendo leer primero mi artículo sobre DVA-C02 para la base de servicios, y usar este como complemento de lo nuevo que trae DVA-C03.

DEV Community