Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen DVA-C02 avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce laboratoire, vous aurez provisionné, avec du Terraform simple, le microservice serverless AWS canonique — une table DynamoDB, une fonction Lambda avec un rôle IAM à moindre privilège, une passerelle d'API HTTP devant, ainsi que des journaux CloudWatch et une alarme d'erreur Lambda pour savoir quand le service tombe en panne. C'est l'architecture testée par le DVA-C02 dans une question sur deux.
Chaque ressource est en Terraform simple — le même code fonctionne sans modification sur OpenTofu. Pas de variables, pas de modules, pas d'état distant. Copiez les extraits dans un unique fichier main.tf, exécutez terraform init une fois, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.us-east-1..zip au moment de la planification via archive_file — aucune étape de construction séparée n'est nécessaire.Toutes les ressources ici sont payantes à l'usage, pas de facturation à l'arrêt :
L'ensemble de la pile ne coûte rien à l'arrêt. Détruisez-la par habitude lorsque vous avez terminé, et non par panique liée aux coûts.
Introduction standard : bloquer aws ~> 5.60, utiliser us-east-1 par défaut, et étiqueter toutes les ressources avec le nom du projet afin que Cost Explorer puisse ultérieurement rendre compte des dépenses de ce laboratoire (environ 0 $ attendu, mais l'habitude est le point pertinent pour l'examen).
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
archive = {
source = "hashicorp/archive"
version = "~> 2.4"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-dva-c02"
ManagedBy = "terraform"
}
}
}DynamoDB est le magasin NoSQL vers lequel le DVA-C02 s'attend à ce que vous vous tourniez dans tout scénario de "latence de l'ordre de la milliseconde à l'échelle". Nous créons une table avec une facturation à la demande (pas de planification de capacité), une clé de partition et le TTL activé pour l'expiration automatique des enregistrements — un modèle récurrent du DVA-C02 pour le cache, le stockage de sessions et toute charge de travail avec des données expirant naturellement.
Pas de clé de tri dans ce laboratoire ; nous n'effectuerons que des accès par clé-valeur. La récupération ponctuelle est activée par défaut pour toute table de production que l'examen s'attend à ce que vous provisionniez ; nous l'activons également ici. billing_mode = PAY_PER_REQUEST et point_in_time_recovery sont tous deux des attributs fréquemment testés à l'examen.
resource "aws_dynamodb_table" "items" {
name = "certlabpro-dva-c02-items"
billing_mode = "PAY_PER_REQUEST"
hash_key = "id"
attribute {
name = "id"
type = "S"
}
ttl {
attribute_name = "expires_at"
enabled = true
}
point_in_time_recovery {
enabled = true
}
}La fonction Lambda est l'endroit où réside la logique de notre application. Nous lui attribuons un rôle à moindre privilège : elle peut écrire dans son groupe de journaux CloudWatch (la politique gérée AWSLambdaBasicExecutionRole) et appeler exactement quatre actions DynamoDB (GetItem, PutItem, UpdateItem, Query) sur une seule table — celle que nous avons créée à l'Étape 2.
La source de données archive_file regroupe le gestionnaire Python intégré dans un fichier .zip au moment de la planification, il n'y a donc pas d'étape de construction séparée. Le gestionnaire est intentionnellement minuscule (il renvoie le chemin + le nom de la table sous forme de JSON) — le DVA-C02 teste bien plus la configuration de Lambda que le code de Lambda, et les attributs pertinents pour l'examen sont ici : runtime, handler, timeout, memory_size, les variables d'environnement et le rôle.
data "archive_file" "lambda_src" {
type = "zip"
output_path = "${path.module}/build/handler.zip"
source {
filename = "index.py"
content = <<-EOT
import json, os
def handler(event, context):
return {
"statusCode": 200,
"headers": {"Content-Type": "application/json"},
"body": json.dumps({
"table": os.environ["TABLE_NAME"],
"path": event.get("rawPath", "/"),
}),
}
EOT
}
}
resource "aws_iam_role" "lambda" {
name = "certlabpro-dva-c02-lambda"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "lambda.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy_attachment" "lambda_logs" {
role = aws_iam_role.lambda.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}
resource "aws_iam_role_policy" "lambda_ddb" {
name = "ddb-table-access"
role = aws_iam_role.lambda.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:Query"]
Resource = aws_dynamodb_table.items.arn
}]
})
}
resource "aws_lambda_function" "api" {
function_name = "certlabpro-dva-c02-api"
role = aws_iam_role.lambda.arn
runtime = "python3.12"
handler = "index.handler"
filename = data.archive_file.lambda_src.output_path
source_code_hash = data.archive_file.lambda_src.output_base64sha256
timeout = 10
memory_size = 256
environment {
variables = {
TABLE_NAME = aws_dynamodb_table.items.name
}
}
}
resource "aws_cloudwatch_log_group" "lambda" {
name = "/aws/lambda/${aws_lambda_function.api.function_name}"
retention_in_days = 7
}API Gateway transforme notre Lambda en un service que le monde peut appeler. Le DVA-C02 teste spécifiquement les API HTTP (la version plus économique, plus rapide et plus récente d'API Gateway) par rapport aux API REST (l'ancienne version) dans la plupart des questions modernes — les API HTTP sont environ 70 % moins chères et ont une latence environ 60 % plus faible, et elles prennent en charge la même intégration Lambda dont nous avons besoin.
Trois ressources lient tout cela : l'API elle-même, une intégration qui pointe vers notre Lambda, et une route qui mappe les requêtes entrantes ANY / à cette intégration. L'étape de déploiement automatique signifie que les modifications apportées à l'API prennent effet immédiatement après un terraform apply.
La ressource aws_lambda_permission est l'élément que les débutants oublient : API Gateway invoque notre Lambda depuis l'extérieur de la propre politique de ressources de la fonction, nous devons donc lui accorder la permission de le faire. Sans cette ressource, l'API acceptera la requête et renverra ensuite une erreur 500 en essayant d'invoquer une Lambda qu'elle n'est pas autorisée à invoquer.
resource "aws_apigatewayv2_api" "main" {
name = "certlabpro-dva-c02"
protocol_type = "HTTP"
}
resource "aws_apigatewayv2_integration" "lambda" {
api_id = aws_apigatewayv2_api.main.id
integration_type = "AWS_PROXY"
integration_uri = aws_lambda_function.api.invoke_arn
payload_format_version = "2.0"
}
resource "aws_apigatewayv2_route" "root" {
api_id = aws_apigatewayv2_api.main.id
route_key = "ANY /"
target = "integrations/${aws_apigatewayv2_integration.lambda.id}"
}
resource "aws_apigatewayv2_stage" "default" {
api_id = aws_apigatewayv2_api.main.id
name = "$default"
auto_deploy = true
}
resource "aws_lambda_permission" "apigw" {
statement_id = "AllowAPIGatewayInvoke"
action = "lambda:InvokeFunction"
function_name = aws_lambda_function.api.function_name
principal = "apigateway.amazonaws.com"
source_arn = "${aws_apigatewayv2_api.main.execution_arn}/*/*"
}
output "api_url" {
value = aws_apigatewayv2_api.main.api_endpoint
}Chaque Lambda émet une métrique Errors vers CloudWatch — le nombre d'invocations qui ont échoué. Le domaine Monitoring, Logging, and Troubleshooting du DVA-C02 (environ 12 % de l'examen) teste si vous instrumentez cela dès le premier jour. Nous créons une alarme CloudWatch sur le taux d'erreur de la fonction Lambda et acheminons les notifications via SNS vers une adresse e-mail.
Après terraform apply, AWS envoie un e-mail de confirmation à l'adresse spécifiée dans email_endpoint — cliquez sur Confirmer l'abonnement une fois, et l'alarme vous parviendra alors réellement lorsque les erreurs augmenteront.
La combinaison des Étapes 2 à 5 constitue l'intégralité du microservice : un magasin d'état (DynamoDB), un calcul sans état (Lambda), une périphérie HTTPS (API Gateway HTTP API) et une visibilité opérationnelle (Journaux CloudWatch + alarmes). C'est l'architecture DVA-C02 en cinq blocs.
resource "aws_sns_topic" "alerts" {
name = "certlabpro-dva-c02-alerts"
}
resource "aws_sns_topic_subscription" "alerts_email" {
topic_arn = aws_sns_topic.alerts.arn
protocol = "email"
endpoint = "you@example.com" # replace with your real email
}
resource "aws_cloudwatch_metric_alarm" "lambda_errors" {
alarm_name = "certlabpro-dva-c02-lambda-errors"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 1
metric_name = "Errors"
namespace = "AWS/Lambda"
period = 300
statistic = "Sum"
threshold = 5
alarm_description = "Lambda errored more than 5 times in 5 minutes."
alarm_actions = [aws_sns_topic.alerts.arn]
treat_missing_data = "notBreaching"
dimensions = {
FunctionName = aws_lambda_function.api.function_name
}
}terraform destroy supprime proprement toutes les ressources de ce laboratoire. Deux remarques :
Le DVA-C02 couvre plus de services destinés aux développeurs que ce laboratoire ne peut en contenir — Step Functions pour l'orchestration, SQS + SNS pour la messagerie asynchrone, EventBridge pour les tâches planifiées, Kinesis Data Streams pour les pipelines en temps réel, X-Ray pour le traçage distribué, Secrets Manager + Parameter Store, Cognito pour l'authentification utilisateur, AppSync pour GraphQL, ECS / EKS / Fargate pour les conteneurs, CodeCommit + CodeBuild + CodeDeploy + CodePipeline pour le CI/CD, S3 pour les actifs statiques, et CloudFront pour la périphérie.
Nous nous en tenons au modèle de microservice serverless le plus testé — Lambda + API Gateway HTTP API + DynamoDB + CloudWatch — car c'est l'architecture que tout candidat DVA-C02 doit pouvoir dessiner et expliquer de mémoire. Les autres modèles s'appuient sur ces primitives (Step Functions compose des Lambdas ; SQS déclenche des Lambdas ; EventBridge les planifie) et s'apprennent mieux en ajoutant une pièce à la fois à cette base.
Pour une couverture conceptuelle service par service du reste, consultez les sections Parcourir, Guide et Editorial de cette page de certification.