Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der SOA-C03-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 eine vollständige Überwachungs- und automatische Wiederherstellungsschleife bereitgestellt – eine CloudWatch-Protokollgruppe mit einem Metrikfilter, ein SNS-Topic, das einen Menschen benachrichtigt, ein Systems Manager-Runbook, das die automatisierte Korrektur durchführt, und eine EventBridge-Regel, die Ereignisse mit hoher Schwere mit dem Runbook verbindet, sodass häufige Vorfälle behoben werden, bevor jemand aufwacht.
Jede Ressource ist reines Terraform – derselbe Code funktioniert ohne Änderungen mit OpenTofu. Keine Variablen, keine Module. Fügen Sie die Snippets in eine einzige main.tf ein, führen Sie terraform init aus und anschließend terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.us-east-1.Alles in diesem Lab kostet nichts, solange es im Ruhezustand ist:
Wenn die automatische Wiederherstellung tatsächlich ausgelöst wird (Schritt 5 triggert ein SSM-Dokument), entstehen keine zusätzlichen Kosten – Systems Manager Automation ist für die hier verwendeten Aktionen kostenlos.
Standard-Einstieg. default_tags gelten für den gesamten Stack, damit das Operationsteam später Cost Explorer, AWS Config und Tag Editor nach Project = certlabpro-soa-c03 filtern kann, um alles zu sehen, was dieses Lab erstellt hat. Der Bereich Zuverlässigkeit und Geschäftskontinuität des SOA-C03-Zertifikats prüft dies explizit – Tagging ist die Grundlage jeder übergreifenden Betriebsfrage.
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-soa-c03"
ManagedBy = "terraform"
}
}
}Jede operative Geschichte auf AWS beginnt in CloudWatch Logs. Wir erstellen eine Protokollgruppe mit einer expliziten 30-tägigen Aufbewahrungsfrist (der Standard von nie ablaufen ist das SOA-C03-Kosten-Antimuster, das in jeder Kostenoptimierungsfrage auftaucht) und einen Metrikfilter, der den Protokollstream nach dem Wort ERROR überwacht und einen Zähler an CloudWatch Metrics veröffentlicht.
Metrikfilter wandeln unstrukturierte Protokolldaten in verwertbare Metriken um. Das ist das SOA-C03-Denkmodell für die Überwachung: Protokolle → Filter → Metrik → Alarm → SNS → Mensch (oder Automatisierung). Wir bauen diese Kette Schritt für Schritt von diesem Punkt an auf.
resource "aws_cloudwatch_log_group" "app" {
name = "/certlabpro/soa-c03/app"
retention_in_days = 30
}
resource "aws_cloudwatch_log_metric_filter" "app_errors" {
name = "certlabpro-soa-c03-app-errors"
log_group_name = aws_cloudwatch_log_group.app.name
pattern = "ERROR"
metric_transformation {
name = "AppErrorCount"
namespace = "CertLabPro/SOA-C03"
value = "1"
default_value = "0"
}
}Jetzt verbinden wir die Metrik aus Schritt 2 mit einem Menschen. Wir erstellen ein SNS-Topic, abonnieren eine E-Mail-Adresse und richten einen CloudWatch-Alarm ein, der ausgelöst wird, wenn die Fehleranzahl unseren Schwellenwert überschreitet. SOA-C03 testet genau diese Kette — Metrik → Alarm → SNS → E-Mail — im Bereich Überwachung, Protokollierung und Wiederherstellung (~20 % der Prüfung).
Nach terraform apply sendet AWS eine Bestätigungs-E-Mail an die Adresse in endpoint – klicken Sie einmal auf Confirm subscription, und der Alarm wird Sie dann tatsächlich erreichen, wenn er auslöst.
treat_missing_data = "notBreaching" ist ein kleines, aber prüfungsrelevantes Detail: Standardmäßig zählt ein fehlender Datenpunkt als Verletzung, was bedeutet, dass ein brandneuer Alarm ohne Daten sofort ausgelöst wird. Die Einstellung auf notBreaching entspricht der SOA-C03-Konvention für Metriken mit geringem Volumen.
resource "aws_sns_topic" "ops_alerts" {
name = "certlabpro-soa-c03-ops-alerts"
}
resource "aws_sns_topic_subscription" "ops_email" {
topic_arn = aws_sns_topic.ops_alerts.arn
protocol = "email"
endpoint = "ops@example.com" # replace with your real email
}
resource "aws_cloudwatch_metric_alarm" "app_errors_spike" {
alarm_name = "certlabpro-soa-c03-app-errors-spike"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 1
metric_name = "AppErrorCount"
namespace = "CertLabPro/SOA-C03"
period = 300
statistic = "Sum"
threshold = 10
alarm_description = "More than 10 ERROR log lines in 5 minutes."
alarm_actions = [aws_sns_topic.ops_alerts.arn]
treat_missing_data = "notBreaching"
}Einen Menschen zu benachrichtigen ist für neue Vorfälle in Ordnung, aber teuer für bekannte, wiederkehrende Vorfälle. SOA-C03 setzt stark auf AWS Systems Manager Automation als Antwort auf die Frage „Wie behebe ich die Dinge automatisch, die ich bereits beheben kann?“ — einen fehlerhaften Dienst neu starten, Anmeldeinformationen rotieren, Festplattenspeicher bereinigen.
Wir erstellen ein minimales SSM-Dokument, das einen aws:sleep-Schritt ausführt (einer der AWS-verwalteten Schritttypen) – in der Produktion wäre dies aws:executeAutomation gegen ein bekanntes Wiederherstellungs-Runbook oder aws:runCommand gegen eine Flotte von Instanzen. Die Form ist dieselbe: eine Abfolge von Schritten deklarieren, dem Dokument eine Ausführungsrolle geben, es als wiederverwendbare Automatisierung registrieren.
Die von uns angehängte IAM-Rolle gibt SSM Automation die Berechtigung, sich selbst anzunehmen und die Aktionen innerhalb des Dokuments aufzurufen. Der Bereich Zuverlässigkeit und Geschäftskontinuität des SOA-C03-Zertifikats testet genau dieses Muster: Ein benanntes, versionskontrolliertes Runbook ist auditierbar; eine Slack-Nachricht wie „Hey, kannst du das Ding neu starten?“ ist es nicht.
resource "aws_iam_role" "ssm_automation" {
name = "certlabpro-soa-c03-ssm-automation"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "ssm.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy_attachment" "ssm_automation" {
role = aws_iam_role.ssm_automation.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole"
}
resource "aws_ssm_document" "remediate_app_errors" {
name = "certlabpro-soa-c03-remediate-app-errors"
document_type = "Automation"
document_format = "YAML"
content = <<-EOT
schemaVersion: "0.3"
description: "Lab-only runbook — auto-acknowledges app-error spikes."
assumeRole: "${aws_iam_role.ssm_automation.arn}"
mainSteps:
- name: pause
action: aws:sleep
inputs:
Duration: PT5S
EOT
}Das letzte Stück der Schleife. CloudWatch-Alarme senden Ereignisse an den EventBridge-Standardbus, wenn sie ihren Status ändern – wir filtern nach dem Alarm, den wir in Schritt 3 erstellt haben, der in den Zustand ALARM übergeht, und richten das SSM-Dokument aus Schritt 4 als Antwort ein.
Die EventBridge-Regel benötigt eine eigene IAM-Rolle, um SSM Automation in unserem Namen aufzurufen – das ist ein subtiles, aber wiederkehrendes SOA-C03-Detail. Die Prüfung testet, ob Sie sich daran erinnern, dass EventBridge, das ein Ziel in Ihrem Namen aufruft, eine Service-zu-Service-Aktion ist, die eine dedizierte Ausführungsrolle benötigt, die sich von der eigenen Assume-Role des SSM-Dokuments unterscheidet.
Die vollständige Kette ist nun: Protokollzeile mit ERROR → Metrikfilter veröffentlicht an CloudWatch Metrics → Alarm wird ausgelöst, wenn Anzahl > 10 in 5 Minuten → Alarm veröffentlicht Statusänderungsereignis an EventBridge UND benachrichtigt das Operations-Team per E-Mail über SNS → EventBridge-Regel stimmt mit der Statusänderung überein → SSM Automation führt das Wiederherstellungs-Runbook aus. Der Pager löst aus und die Behebung wird parallel gestartet. Das ist das SOA-C03-Operationsideal.
resource "aws_iam_role" "eventbridge_invoke_ssm" {
name = "certlabpro-soa-c03-eventbridge-invoke-ssm"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "events.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy" "eventbridge_invoke_ssm" {
name = "start-automation"
role = aws_iam_role.eventbridge_invoke_ssm.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "ssm:StartAutomationExecution"
Resource = "*"
}]
})
}
resource "aws_cloudwatch_event_rule" "app_errors_alarm" {
name = "certlabpro-soa-c03-app-errors-alarm-fired"
description = "Fires the auto-remediation runbook when the app-errors alarm trips."
event_pattern = jsonencode({
source = ["aws.cloudwatch"]
"detail-type" = ["CloudWatch Alarm State Change"]
detail = {
alarmName = [aws_cloudwatch_metric_alarm.app_errors_spike.alarm_name]
state = { value = ["ALARM"] }
}
})
}
resource "aws_cloudwatch_event_target" "run_ssm_doc" {
rule = aws_cloudwatch_event_rule.app_errors_alarm.name
arn = "arn:aws:ssm:us-east-1::automation-definition/${aws_ssm_document.remediate_app_errors.name}"
role_arn = aws_iam_role.eventbridge_invoke_ssm.arn
}terraform destroy reißt alles in diesem Lab ab. Ein Vorbehalt: Das SNS E-Mail-Abonnement bleibt nach dem Destroy in Ihrer Kontohistorie bestehen (AWS speichert den Abmeldeverlauf zur Compliance). Keine Kosten, nur eine Dokumentation. Alles andere wird innerhalb einer Minute sauber beendet.
SOA-C03 deckt betriebliche Bereiche ab, die dieses Lab nicht unterbringen kann — AWS Config-Regeln und Konformitätspakete für Compliance-Drift, CloudTrail für API-Audit, Trusted Advisor-Prüfungen, CloudFormation Drift-Erkennung und StackSets für Multi-Account-Operationen, AWS Backup, AWS Health-Ereignisse, Resource Explorer, License Manager und Service Quotas.
Wir konzentrieren uns auf die Alarm-zu-automatisierte-Wiederherstellung-Schleife, da dies das am häufigsten getestete Betriebsmuster in der Prüfung ist und dasjenige, das die vier am häufigsten verwendeten Dienste (CloudWatch, SNS, SSM, EventBridge) miteinander verbindet. Die anderen operativen Tools sind konzeptionelle Abdeckungen — siehe die Abschnitte Durchsuchen und Editorial dieser Zertifikatsseite.