Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der DVA-C02-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs haben Sie mit einfachem Terraform den kanonischen AWS Serverless-Microservice bereitgestellt – eine DynamoDB-Tabelle, eine Lambda-Funktion mit einer IAM-Rolle mit geringsten Rechten, ein HTTP API Gateway davor und CloudWatch Logs + einen Lambda-Fehleralarm, damit Sie wissen, wann der Dienst ausfällt. Dies ist die Architektur, die DVA-C02 in jeder zweiten Frage testet.
Jede Ressource ist einfaches Terraform – derselbe Code funktioniert ohne Änderungen mit OpenTofu. Keine Variablen, keine Module, kein Remote State. Fügen Sie die Snippets in eine einzelne main.tf ein, führen Sie einmal terraform init aus und dann terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.us-east-1.archive_file in eine .zip-Datei eingefügt – kein separater Build-Schritt erforderlich.Alle hier verwendeten Ressourcen werden pay-per-use abgerechnet, keine Abrechnung bei Inaktivität:
Der gesamte Stack verursacht im Ruhezustand 0 $ Kosten. Zerstören Sie ihn aus Gewohnheit, nicht aus Kostenangst.
Standard-Eröffnung: aws ~> 5.60 festlegen, us-east-1 als Standard verwenden, alles mit dem Projektnamen taggen, damit der Cost Explorer später berichten kann, was dieses Lab gekostet hat (erwartet werden ~0 $, aber die Gewohnheit ist der prüfungsrelevante Punkt).
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 ist der NoSQL-Speicher, den DVA-C02 von Ihnen erwartet, wenn es um Szenarien mit „einstelliger Millisekunden-Latenz bei Skalierung“ geht. Wir erstellen eine Tabelle mit On-Demand-Abrechnung (keine Kapazitätsplanung), einem Partition Key und aktivierter TTL für die automatische Ablaufsteuerung von Datensätzen – ein wiederkehrendes DVA-C02-Muster für Caching, Session-Speicher und jede Arbeitslast mit natürlich ablaufenden Daten.
In diesem Lab gibt es keinen Sort Key; wir werden nur auf Schlüssel-Wert-Basis zugreifen. Point-in-time Recovery ist standardmäßig für jede Produktionstabelle aktiviert, die Sie laut Prüfung bereitstellen sollen; wir aktivieren es hier ebenfalls. Sowohl billing_mode = PAY_PER_REQUEST und point_in_time_recovery sind häufig abgefragte Prüfungsattribute.
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
}
}Die Lambda-Funktion ist der Ort, an dem unsere Anwendungslogik lebt. Wir weisen ihr eine Rolle mit minimalen Rechten zu: Sie kann in ihre CloudWatch-Protokollgruppe schreiben (die verwaltete Richtlinie AWSLambdaBasicExecutionRole) und genau vier DynamoDB-Aktionen (GetItem, PutItem, UpdateItem, Query) gegen genau eine Tabelle ausführen – die, die wir in Schritt 2 erstellt haben.
Die Datenquelle archive_file bündelt den inline Python-Handler zur Planungszeit in eine .zip-Datei, sodass kein separater Build-Schritt erforderlich ist. Der Handler ist absichtlich sehr klein (gibt den Pfad + Tabellennamen als JSON zurück) – DVA-C02 testet die Lambda-Konfiguration viel mehr als den Lambda-Code, und die prüfungsrelevanten Attribute sind hier zu finden: runtime, handler, timeout, memory_size, Umgebungsvariablen und die Rolle.
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 macht unsere Lambda-Funktion zu etwas, das die Welt aufrufen kann. DVA-C02 testet in den meisten modernen Fragen speziell HTTP APIs (die günstigere, schnellere, neuere API Gateway-Variante) gegenüber REST APIs (der älteren Variante) – HTTP APIs sind ~70% günstiger und haben ~60% geringere Latenz, und sie unterstützen die gleiche Lambda-Integration, die wir benötigen.
Drei Ressourcen verbinden dies miteinander: die API selbst, eine Integration, die auf unsere Lambda-Funktion zeigt, und eine Route, die eingehende ANY /-Anfragen dieser Integration zuordnet. Die automatische Bereitstellungsphase bedeutet, dass Änderungen an der API sofort nach terraform apply wirksam werden.
Die aws_lambda_permission ist der Teil, den Anfänger vergessen: API Gateway ruft unsere Lambda-Funktion von außerhalb der eigenen Ressourcenrichtlinie der Funktion auf, daher müssen wir die Berechtigung dazu erteilen. Ohne diese Ressource akzeptiert die API die Anfrage und gibt dann einen 500er-Fehler zurück, wenn sie versucht, eine Lambda-Funktion aufzurufen, die sie nicht aufrufen darf.
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
}Jede Lambda-Funktion sendet eine Errors-Metrik an CloudWatch – die Anzahl der Aufrufe, die einen Fehler ausgelöst haben. Der DVA-C02-Bereich Monitoring, Logging, and Troubleshooting (~12% der Prüfung) testet, ob Sie dies von Anfang an instrumentieren. Wir erstellen einen CloudWatch-Alarm für die Fehlerrate der Lambda-Funktion und leiten Benachrichtigungen über SNS an eine E-Mail-Adresse weiter.
Nach terraform apply sendet AWS eine Bestätigungs-E-Mail an die Adresse in email_endpoint – klicken Sie einmal auf Abonnement bestätigen, und der Alarm wird Sie dann tatsächlich erreichen, wenn Fehler stark ansteigen.
Die Kombination aus den Schritten 2 bis 5 ist der gesamte Microservice: ein zustandsbehafteter Speicher (DynamoDB), zustandslose Berechnung (Lambda), ein HTTPS-Edge (API Gateway HTTP API) und operative Sichtbarkeit (CloudWatch Logs + Alarme). Das ist die DVA-C02-Architektur in fünf Blöcken.
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 entfernt alles in diesem Lab sauber. Zwei Anmerkungen:
DVA-C02 deckt mehr entwicklerorientierte Dienste ab, als dieses Lab fassen kann – Step Functions für Orchestrierung, SQS + SNS für asynchrone Nachrichtenübermittlung, EventBridge für geplante Aufgaben, Kinesis Data Streams für Echtzeit-Pipelines, X-Ray für verteiltes Tracing, Secrets Manager + Parameter Store, Cognito für Benutzerauthentifizierung, AppSync für GraphQL, ECS / EKS / Fargate für Container, CodeCommit + CodeBuild + CodeDeploy + CodePipeline für CI/CD, S3 für statische Assets und CloudFront für das Edge.
Wir konzentrieren uns auf das einzelne am häufigsten getestete Serverless-Microservice-Muster – Lambda + API Gateway HTTP API + DynamoDB + CloudWatch – weil es die eine Architektur ist, die jeder DVA-C02-Kandidat aus dem Gedächtnis zeichnen und erklären können muss. Die anderen Muster bauen auf diesen Grundlagen auf (Step Functions komponiert Lambdas; SQS triggert Lambdas; EventBridge plant sie) und lassen sich am besten lernen, indem man Stück für Stück zu dieser Basis hinzufügt.
Für eine konzeptionelle Abdeckung der restlichen Dienste, siehe die Abschnitte Durchsuchen, Handbuch und Editorial dieser Zertifizierungsseite.