Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen SOA-C03 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 labo, vous aurez provisionné, avec du Terraform simple, une boucle complète de surveillance et d'auto-remédiation — un groupe de logs CloudWatch avec un filtre de métriques, un sujet SNS qui alerte une personne, un runbook Systems Manager qui effectue la correction automatisée, et une règle EventBridge qui connecte les événements de haute gravité au runbook afin que les incidents courants se résolvent d'eux-mêmes avant que quiconque ne se réveille.
Chaque ressource est du Terraform simple — le même code fonctionne sans modification sur OpenTofu. Pas de variables, pas de modules. Déposez les extraits dans un seul fichier main.tf, exécutez terraform init, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.us-east-1.Tout dans ce labo ne coûte rien au repos:
Si l'auto-remédiation se déclenche réellement (l'étape 5 déclenche un document SSM), cela ne coûte rien de plus — Systems Manager Automation est gratuit pour les actions utilisées ici.
Ouverture standard. Les default_tags s'appliquent à l'ensemble de la pile afin que l'équipe des opérations puisse ensuite filtrer Cost Explorer, AWS Config et Tag Editor par Project = certlabpro-soa-c03 pour voir tout ce que ce labo a créé. Le domaine Fiabilité et Continuité des activités du SOA-C03 teste explicitement cela — le marquage est le fondement de chaque requête opérationnelle transversale.
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"
}
}
}Chaque histoire opérationnelle sur AWS commence dans CloudWatch Logs. Nous créons un groupe de logs avec une rétention explicite de 30 jours (la valeur par défaut « ne jamais expirer » est l'anti-pattern de coût du SOA-C03 qui apparaît dans chaque question d'optimisation des coûts) et un filtre de métriques qui surveille le flux de logs pour le mot ERROR et publie un compte vers CloudWatch Metrics.
Les filtres de métriques transforment les données de logs non structurées en métriques exploitables. C'est le modèle mental du SOA-C03 pour la surveillance : logs → filtre → métrique → alarme → SNS → humain (ou automatisation). Nous construisons la chaîne pièce par pièce à partir de cette étape.
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"
}
}Maintenant, nous connectons la métrique de l'étape 2 à une personne. Nous créons un sujet SNS, y abonnons une adresse e-mail et configurons une alarme CloudWatch qui se déclenche lorsque le nombre d'erreurs dépasse notre seuil. Le SOA-C03 teste cette chaîne exacte — métrique → alarme → SNS → e-mail — sous le domaine Surveillance, journalisation et remédiation (environ 20 % de l'examen).
Après terraform apply, AWS envoie un e-mail de confirmation à l'adresse dans endpoint — cliquez une fois sur Confirmer l'abonnement, et l'alarme vous parviendra réellement lorsqu'elle se déclenchera.
treat_missing_data = "notBreaching" est un détail mineur mais pertinent pour l'examen : par défaut, un point de données manquant est considéré comme une violation, ce qui signifie qu'une toute nouvelle alarme sans données se déclenche immédiatement. Le réglage sur notBreaching correspond à la convention du SOA-C03 pour les métriques à faible volume.
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"
}Alerter une personne est acceptable pour les incidents nouveaux, mais coûteux pour ceux qui se répètent. Le SOA-C03 s'appuie fortement sur l'automatisation d'AWS Systems Manager comme réponse à la question « comment puis-je corriger automatiquement les choses que je sais déjà réparer ? » — redémarrer un service défaillant, faire pivoter une accréditation, libérer de l'espace disque.
Nous rédigeons un document SSM minimal qui exécute une étape aws:sleep (l'un des types d'étapes gérés par AWS) — en production, il s'agirait de aws:executeAutomation contre un runbook de récupération connu, ou de aws:runCommand contre un parc d'instances. La forme est la même : déclarer une séquence d'étapes, donner un rôle d'exécution au document, l'enregistrer comme une automatisation réutilisable.
Le rôle IAM que nous attachons donne à SSM Automation la permission de s'assumer lui-même et d'appeler les actions à l'intérieur du document. Le domaine Fiabilité et Continuité des activités du SOA-C03 teste ce modèle exact : un runbook nommé et versionné est auditable ; un message Slack disant « hey, peux-tu redémarrer ce truc » ne l'est pas.
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
}La dernière pièce de la boucle. Les alarmes CloudWatch émettent des événements vers le bus par défaut EventBridge lorsqu'elles changent d'état — nous filtrons l'alarme que nous avons créée à l'étape 3 passant à ALARM, et ciblons le document SSM de l'étape 4 comme réponse.
La règle EventBridge a besoin de son propre rôle IAM pour appeler SSM Automation en notre nom — c'est un détail subtil mais récurrent du SOA-C03. L'examen teste si vous vous souvenez qu'EventBridge invoquant une cible en votre nom est une action de service à service qui nécessite un rôle d'exécution dédié, distinct du rôle d'assumation du document SSM.
La chaîne complète est maintenant : ligne de log contenant ERROR → le filtre de métriques publie sur CloudWatch Metrics → l'alarme se déclenche lorsque le nombre > 10 en 5 minutes → l'alarme publie un événement de changement d'état sur EventBridge ET envoie un e-mail à l'équipe d'exploitation via SNS → la règle EventBridge correspond au changement d'état → SSM Automation exécute le runbook de remédiation. Le pager se déclenche et la correction démarre en parallèle. C'est l'idéal opérationnel du SOA-C03.
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 supprime tout dans ce labo. Une mise en garde : l'abonnement e-mail SNS reste dans l'historique de votre compte après la suppression (AWS conserve l'enregistrement de désabonnement pour la conformité). Pas de frais, juste une trace. Tout le reste est supprimé proprement en une minute.
Le SOA-C03 couvre des aspects opérationnels que ce labo ne peut pas inclure — les règles AWS Config et les packs de conformité pour la dérive de conformité, CloudTrail pour l'audit d'API, les vérifications Trusted Advisor, la détection de dérive CloudFormation et les StackSets pour les opérations multi-comptes, AWS Backup, les événements AWS Health, Resource Explorer, License Manager et Service Quotas.
Nous nous en tenons à la boucle alarme-à-auto-remédiation car c'est le modèle opérationnel le plus testé à l'examen et celui qui relie les quatre services les plus fréquemment utilisés (CloudWatch, SNS, SSM, EventBridge). Les autres outils opérationnels sont une couverture conceptuelle — consultez les sections Parcourir et Editorial de cette page de certification.