Amazon Q: Console-First Developer Workshop for ACM Certificate Auto Renewal

Duration: 2 hours
Audience: Professional developers, DevOps engineers, platform engineers, cloud platform builders
Primary AWS AI service: Amazon Q Developer in the AWS Management Console
Execution style: The user starts from the AWS Console, opens Amazon Q from the console side panel, and uses Amazon Q to guide diagnosis, remediation, verification, code generation, and runbook creation.
Target AWS task: Restore and harden automatic renewal for an AWS Certificate Manager (ACM) public certificate by validating DNS records and preserving the renewal prerequisites.

1. Workshop Scenario

A production-facing SSL/TLS certificate in ACM is approaching expiration. ACM attempted managed renewal, but the renewal is blocked because DNS validation is incomplete. The developer is already in the AWS Console, viewing the ACM certificate details page. Instead of switching to external documentation first, the developer opens Amazon Q Developer in the AWS Console and uses it as the primary AI assistant to:

1. Understand the certificate renewal state.
2. Identify whether the certificate is eligible for ACM managed renewal.
3. Find the missing DNS CNAME validation records.
4. Add or repair records in Route 53.
5. Verify that ACM can renew automatically.
6. Convert the console-driven fix into repeatable developer automation and a runbook.

This is a technical workshop. It assumes developers are comfortable with AWS services, JSON, AWS CLI, DNS, access control, and basic scripting.

2. What Developers Will Build

Developers will complete a console-first workflow supported by Amazon Q Developer:

AWS Console user
  |
  | opens Amazon Q Developer panel from AWS Console
  v
Amazon Q Developer in AWS Console
  |
  | explains ACM renewal status, resource context, CLI commands, and remediation plan
  v
ACM certificate details page
  |
  | shows certificate status, validation method, renewal eligibility, and CNAME records
  v
Route 53 hosted zone
  |
  | stores ACM DNS validation CNAME records permanently
  v
CloudShell / AWS Console actions
  |
  | executes Q-generated sanitized verification and remediation commands
  v
Amazon Q follow-up
  |
  | reviews result, generates tests, hardening checklist, and runbook

3. Amazon Q Developer Capabilities Covered

This workshop intentionally focuses on one AWS AI service: Amazon Q Developer. ACM and Route 53 are target services, but Amazon Q is the single AI backbone.

4. Timeboxed 2-Hour Agenda

5. Prerequisites

5.1 AWS Console access

Developers need access to:

• AWS Certificate Manager console.
• Route 53 hosted zones console.
• AWS CloudShell from the same console session.
• Amazon Q Developer chat panel in the AWS Console.

5.2 Access permissions for workshop execution

Use least-privilege access. The workshop role should be able to inspect ACM certificate state, list the relevant DNS records, submit reviewed DNS validation record changes for the authoritative hosted zone, and poll DNS change status.
Business logic: The workshop requires ACM inspection and DNS validation repair. Developers do not need administrator access, certificate private key access, permission-management rights, or application deployment permissions. ACM is used to discover validation requirements; Route 53 is used to make the DNS state match ACM’s required proof of control.
Code logic: Access is separated between read-only ACM inspection and controlled Route 53 DNS record operations. The certificate inspection step retrieves renewal metadata and validation records. The DNS change step performs the reviewed CNAME UPSERT. The change polling step lets developers wait until Route 53 reports the DNS change as synchronized.
Expected result: Developers can complete the lab from the AWS Console and CloudShell without broad account privileges. In a production rollout, narrow DNS write access to the authoritative hosted zone and enforce peer review for DNS writes.

System design decision — Least privilege from the beginning

• Security boundary: Certificate renewal repair touches DNS ownership proof, so access should be limited to ACM read operations and the specific DNS zone update path. Broad administrator permissions hide permission design problems and increase blast radius.
• Operational clarity: A narrow access model helps developers understand the exact system dependencies: ACM metadata, Route 53 records, and change polling. That clarity makes failures easier to troubleshoot because denied actions map directly to missing workflow permissions.
• Production migration: Workshop code often becomes real automation. Starting with least privilege prevents demo shortcuts from becoming persistent security debt when the workflow is moved into CI, platform tooling, or incident runbooks.

6. Placeholder Lab Variables

Use placeholder values in documentation, screenshots, and shared notes.

export AWS_REGION="<certificate-region>"
export CERTIFICATE_ARN="arn:aws:acm:<region>:<redacted-account>:certificate/<certificate-id>"
export HOSTED_ZONE_ID="<hosted-zone-id>"
export PRIMARY_DOMAIN="<workshop-domain>"
export AWS_PROFILE="default"

Business logic: The same workshop must work across multiple accounts and domains without exposing customer data. Placeholders let developers understand where values belong while keeping the written artifact safe for sharing.

Code logic: Environment variables make CloudShell commands copyable and parameterized. Commands later in the workshop consume these variables instead of hardcoding account-specific identifiers.

Expected result: Workshop notes remain reusable. Developers can replace placeholder values in their own private console session, but the final Markdown, screenshots, or pull requests should not contain real account identifiers.

System design decision — Placeholder-first workflow

1. Data minimization: Certificate ARNs, hosted zone IDs, domains, and DNS validation tokens can reveal architecture or ownership information. Placeholders reduce leakage through documentation, meeting chat, tickets, and generated code.
2. Reusability: Parameterized commands can be reused across environments. A developer can run the same command pattern in sandbox, staging, or production by changing variables instead of editing command bodies.
3. Reviewability: Reviewers can inspect logic without being distracted by customer-specific data. This improves code review quality and prevents accidental copy/paste of sensitive identifiers into public repositories or support channels.

7. AWS Health Email Notices Mail

Action required: certificate renewal Mail

Notification source: Amazon Web Services Health notification
Notification type: Action required
Subject: Action Required — Your certificate renewal

AWS Health Event

Action Required — Your certificate renewal

Greetings from Amazon Web Services,

You have an SSL/TLS certificate from AWS Certificate Manager in your AWS environment that expires on <current-certificate-expiration-utc>. This certificate includes the primary DNS name <workshop-domain> and a total of <domain-count> DNS names.

AWS environment: <redacted-account>
AWS Region name: <certificate-region>
Certificate identifier: <certificate-arn>

AWS Certificate Manager (ACM) was unable to renew the certificate automatically using DNS validation. You must take action to ensure that the renewal can be completed before <current-certificate-expiration-utc>. If the certificate is not renewed and the current certificate expires, your website or application may become unreachable.

To renew this certificate, ensure that the required CNAME records are present in the authoritative DNS configuration for each DNS name listed below. You can find the CNAME records by expanding the certificate and its DNS-name entries in the ACM console. You can also use the DescribeCertificate operation in the ACM API or the describe-certificate operation in the AWS CLI to find the certificate's CNAME records.

The following <domain-count> DNS names require validation:
<workshop-domain>, <additional-workshop-domain>

If you have questions about this process, contact AWS Support through the Support Center. If you do not have an AWS support plan, post a new thread in the AWS Certificate Manager discussion forum.

7. Module 1 — Open ACM and Ask Amazon Q for Context

Goal

Start from the AWS Console and use Amazon Q to understand the current certificate page before making changes.

Console steps

1. Open the AWS Management Console.
2. Go to AWS Certificate Manager.
3. Select the affected public certificate.
4. Open the Amazon Q panel from the console navigation.
5. Ask Amazon Q to explain the current page and the renewal problem.

Amazon Q prompt sample

I am on an AWS Certificate Manager certificate details page.
Explain what I should check to confirm whether this certificate can renew automatically.
Focus on certificate status, renewal eligibility, validation method, in-use services, and DNS validation CNAME records.

Expected Amazon Q guidance

Amazon Q should guide developers to inspect:

• Certificate status: ISSUED, EXPIRED, or another state.
• Certificate type: Amazon-issued versus imported.
• Validation method: DNS validation versus email validation.
• Renewal eligibility.
• Renewal status or renewal summary.
• Domain validation options.
• Whether the certificate is associated with an AWS service such as CloudFront, Elastic Load Balancing, or API Gateway.

System design decision — Start with console context instead of scripts

1. Context-rich diagnosis: The AWS Console already displays certificate state, validation method, and related metadata. Asking Amazon Q from that context helps developers form an accurate mental model before running commands or changing DNS.
2. Lower operational risk: DNS changes should not be the first action. The system may be blocked by import status, expiration, wrong region, or missing service association. Console diagnosis narrows the cause before remediation.
3. Developer learning: Professional developers need to understand the control plane, not just copy commands. Amazon Q’s explanation turns the console page into a guided systems-design walkthrough of ACM, Route 53, and consuming services.

8. Module 2 — Ask Amazon Q to Explain ACM Managed Renewal Rules

Goal

Understand the contract ACM requires for automatic renewal.

Amazon Q prompt sample

Explain ACM managed renewal for a DNS-validated public certificate.
Include when ACM can renew, when it cannot renew, why CNAME records must remain in DNS, and how Route 53 fits into the process.

Key developer notes

• DNS validation uses ACM-generated CNAME records to prove domain control.
• The CNAME record should remain in DNS after issuance because ACM reuses it for future renewal validation.
• Managed renewal applies to eligible Amazon-issued certificates, but not to expired or imported certificates.
• Certificates associated with supported AWS services can be renewed and deployed without application code changes.
• The renewed certificate can keep the same ARN, reducing application integration work.

System design decision — Treat DNS validation as desired state

1. Long-lived invariant: The ACM validation CNAME is not a one-time setup artifact. It is a persistent invariant of the certificate lifecycle. The platform should protect it like any other critical DNS record.
2. Separation of responsibilities: ACM owns certificate lifecycle management, Route 53 owns DNS state, and consuming services terminate TLS. The developer’s job is to keep those systems connected through stable validation records.
3. Automation-friendly model: Once DNS validation is correct and the certificate is eligible, renewal becomes a managed control-plane operation. That reduces the need for application deployments, custom certificate rotation code, or emergency manual certificate replacement.

9. Module 3 — Use Amazon Q to Generate a Safe ACM Inspection Command

Goal

Use CloudShell inside the AWS Console to extract only the fields needed for renewal diagnosis.

Amazon Q prompt sample

Generate an AWS CLI command for CloudShell that describes one ACM certificate and returns only renewal-relevant fields.
Use CERTIFICATE_ARN and AWS_REGION environment variables.
Show status, type, renewal eligibility, renewal summary, in-use count, and domain validation resource records.

Code sample

aws acm describe-certificate \
  --region "$AWS_REGION" \
  --certificate-arn "$CERTIFICATE_ARN" \
  --query '{
    DomainName: Certificate.DomainName,
    Status: Certificate.Status,
    Type: Certificate.Type,
    RenewalEligibility: Certificate.RenewalEligibility,
    RenewalSummary: Certificate.RenewalSummary,
    InUseByCount: length(Certificate.InUseBy),
    DomainValidationOptions: Certificate.DomainValidationOptions[].{
      DomainName: DomainName,
      ValidationStatus: ValidationStatus,
      ResourceRecord: ResourceRecord
    }
  }' \
  --output json

Detailed code explanation

Business logic: The command retrieves the minimum certificate state required to decide whether DNS records must be repaired. It avoids dumping unrelated metadata and reduces the chance of exposing sensitive identifiers in terminal output.

Code logic: describe-certificate calls ACM for one certificate. The --query expression projects the response into renewal-focused fields. InUseByCount confirms whether the certificate is attached to one or more services without printing each full service identifier.

Expected result: Developers receive a compact JSON document. If ResourceRecord values exist and validation status is not successful, those CNAME records are candidates for Route 53 verification. If the certificate is imported, expired, or not eligible, the team should resolve that design issue before expecting managed renewal.

System design decision — Query projection over raw JSON

1. Noise control: Raw ACM responses can be large and include identifiers that are unnecessary for a renewal decision. Query projection creates a small operational view optimized for diagnosis.
2. Sensitive output reduction: Developers often paste CLI output into tickets or chat. A compact query reduces the chance that account-specific data or unrelated resource identifiers are copied into shared systems.
3. Repeatable reasoning: The same projected shape can be used by humans, Amazon Q follow-up questions, and scripts. This makes the workflow deterministic and easier to teach during a two-hour workshop.

10. Module 4 — Ask Amazon Q to Identify the Required Route 53 Records

Goal

Map ACM validation records to Route 53 console fields without exposing real values in shared notes.

Amazon Q prompt sample

I have ACM DomainValidationOptions output with ResourceRecord name, type, and value.
Explain how to add these as Route 53 records from the AWS Console.
Describe which part goes into Record name, Record type, and Value.

Placeholder example

ACM ResourceRecord example:
Name:  _validation-token.<workshop-domain>.
Type:  CNAME
Value: _validation-target.acm-validations.aws.

Route 53 record fields:
Record name: _validation-token
Record type: CNAME
Value:       _validation-target.acm-validations.aws
Routing:     Simple routing
TTL:         300

Detailed explanation

Business logic: ACM renews DNS-validated certificates by checking whether the required CNAME records exist in authoritative DNS. Route 53 stores those records when it is the DNS provider. Developers must preserve the exact ACM-provided value, because it proves domain ownership.

Code logic: There is no code execution in this step. The mapping is a field transformation from ACM’s fully qualified DNS record to Route 53’s console form. Route 53 often lets developers enter only the left-side record label inside the selected hosted zone.

Expected result: Developers know exactly how ACM’s ResourceRecord maps to Route 53 fields. They should not create A records, TXT records, or CNAMEs in the wrong hosted zone. They should not delete these records after renewal succeeds.

System design decision — Use the authoritative hosted zone only

1. DNS authority matters: ACM validates against public DNS, not against whichever hosted zone happens to exist in the account. If multiple hosted zones share a name, only the authoritative zone’s records will be visible to ACM.
2. Avoid false success: Creating a record in the wrong hosted zone can make the console look correct while public DNS remains unchanged. This causes ongoing PENDING_VALIDATION even though a developer believes remediation is complete.
3. Operational ownership: Identifying the authoritative zone clarifies which team owns the fix. If the authoritative DNS provider is external or in another AWS account, the local developer must coordinate rather than force changes in a non-authoritative local zone.

11. Module 5 — Use Amazon Q to Perform Route 53 Console Remediation

Goal

Add or repair ACM DNS validation records using AWS Console actions guided by Amazon Q.

Console steps

1. In the AWS Console, open Route 53.
2. Open Hosted zones.
3. Select the authoritative public hosted zone for the certificate domain.
4. Choose Create record.
5. Enter the ACM-provided CNAME record name.
6. Select CNAME as the record type.
7. Enter the ACM-provided validation target as the value.
8. Use simple routing and a TTL such as 300 seconds.
9. Create the record.
10. Repeat for each required validation record.

Amazon Q prompt sample

Guide me through creating ACM DNS validation CNAME records in Route 53 from the console.
Before I submit, give me a checklist to verify hosted zone authority, record type, record name, value, TTL, and whether the record should remain permanently.

Optional CloudShell change batch generated with Amazon Q

Ask Amazon Q to generate the following only after console remediation is understood.

cat > acm-validation-change-batch.json <<'JSON'
{
  "Comment": "UPSERT ACM DNS validation records for managed renewal readiness",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_validation-token.<workshop-domain>.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": "_validation-target.acm-validations.aws."
          }
        ]
      }
    }
  ]
}
JSON

aws route53 change-resource-record-sets \
  --hosted-zone-id "$HOSTED_ZONE_ID" \
  --change-batch file://acm-validation-change-batch.json

Detailed code explanation

Business logic: The change batch expresses the desired DNS state for ACM validation. UPSERT is used because this operation should be safe if the record already exists but needs correction. The CNAME record is the durable proof that lets ACM complete renewal.

Code logic: The JSON file defines one Route 53 change. Action is UPSERT, so Route 53 creates the record if missing or updates it if it exists. ResourceRecordSet contains the DNS name, record type, TTL, and validation target. The AWS CLI submits that change to the hosted zone.

Expected result: Route 53 accepts the change and returns a change ID. After the change reaches INSYNC, ACM can eventually detect the CNAME through DNS and continue certificate validation or renewal. ACM status may not update instantly.

System design decision — Prefer console learning, then command automation

1. Human comprehension first: Developers should know what record they are creating before automating the operation. Console-guided remediation makes the DNS object visible and easier to reason about.
2. Command repeatability second: Once the mapping is understood, a change batch becomes useful for repeatable fixes, peer review, and CI/CD. Amazon Q can help convert human console actions into safe automation.
3. Idempotent DNS repair: UPSERT reduces failure during repeated execution and incident recovery. DNS remediation should converge the system toward the desired state instead of failing when a partial fix already exists.

12. Module 6 — Verify Route 53 Change Status from CloudShell

Goal

Confirm Route 53 accepted and synchronized the DNS record change.

Amazon Q prompt sample

Generate a CloudShell command to poll a Route 53 change ID until it reaches INSYNC.
Use CHANGE_ID as an environment variable.
Explain why INSYNC does not always mean ACM validation is already complete.

Code sample

export CHANGE_ID="<route53-change-id>"

while true; do
  STATUS=$(aws route53 get-change \
    --id "$CHANGE_ID" \
    --query 'ChangeInfo.Status' \
    --output text)

  echo "Route 53 change status: $STATUS"

  if [ "$STATUS" = "INSYNC" ]; then
    break
  fi

  sleep 15
done

Detailed code explanation

Business logic: Route 53 changes are asynchronous. Developers should wait until Route 53 reports that the change is synchronized before expecting ACM to observe the new DNS records.

Code logic: The loop calls route53 get-change using the submitted change ID. It extracts only ChangeInfo.Status. The loop exits when the status equals INSYNC; otherwise, it waits 15 seconds and checks again.

Expected result: The command eventually prints INSYNC. This confirms that Route 53 has processed the change. It does not guarantee that ACM has already completed validation, because ACM must independently query DNS and update its own certificate state.

System design decision — Separate Route 53 synchronization from ACM validation

1. Different control planes: Route 53 and ACM are separate services with independent state transitions. Route 53 INSYNC means the DNS provider accepted the change, while ACM validation requires a later certificate-control-plane check.
2. Better troubleshooting: Separating these states prevents developers from assuming a failed ACM status means the Route 53 change failed. It may simply be propagation or ACM polling delay.
3. Reliable observability: Each service should be verified with its own API and status field. This creates a clean diagnostic chain: DNS write submitted, DNS write synchronized, ACM validation observed, certificate renewal completed.

13. Module 7 — Ask Amazon Q to Verify ACM Renewal Readiness

Goal

Return to ACM and confirm the certificate is now ready for managed renewal.

Amazon Q prompt sample

I added the ACM DNS validation CNAME records to Route 53.
Tell me how to verify from the ACM certificate page and from CloudShell that automatic renewal is now unblocked.
Explain the meaning of ISSUED, PENDING_VALIDATION, SUCCESS, FAILED, and RenewalEligibility.

Code sample

aws acm describe-certificate \
  --region "$AWS_REGION" \
  --certificate-arn "$CERTIFICATE_ARN" \
  --query '{
    Status: Certificate.Status,
    RenewalEligibility: Certificate.RenewalEligibility,
    RenewalStatus: Certificate.RenewalSummary.RenewalStatus,
    DomainStatuses: Certificate.DomainValidationOptions[].{
      DomainName: DomainName,
      ValidationStatus: ValidationStatus
    },
    NotAfter: Certificate.NotAfter
  }' \
  --output json

Detailed code explanation

Business logic: Developers need a final ACM-focused check after DNS remediation. This command confirms whether ACM still sees validation as pending, whether the certificate remains issued, and whether the certificate is eligible for managed renewal.

Code logic: The CLI calls describe-certificate and projects only the renewal-related fields. Status shows certificate lifecycle state, RenewalEligibility indicates whether ACM can manage renewal, RenewalStatus shows renewal progress when present, and DomainStatuses shows validation state per domain name.

Expected result: A healthy path shows an issued certificate, renewal eligibility enabled, and domain validation status progressing toward success. If validation remains pending after DNS propagation, developers should verify authoritative DNS, record spelling, CNAME value, and whether the correct certificate region is being inspected.

System design decision — Verify per-domain, not just certificate-level status

1. Multi-name certificates fail as a unit: A certificate can include multiple names. If any one domain validation record is missing or wrong, the renewal can remain blocked even if other names are valid.
2. Precise remediation: Per-domain validation status points developers to the exact record that needs repair. This is faster than rechecking every record or replacing the certificate.
3. Safer incident communication: Reporting per-domain status gives platform and DNS teams actionable information without exposing account identifiers. It also supports a clean escalation path when DNS ownership belongs to another team.

14. Module 8 — Ask Amazon Q to Generate a Reusable Verification Script

Goal

Convert the console fix into reusable developer automation.

Amazon Q prompt sample

Write a Bash script for CloudShell that verifies ACM DNS validation records exist in Route 53.
Requirements:
- Read CERTIFICATE_ARN, AWS_REGION, and HOSTED_ZONE_ID from environment variables.
- Compare ACM ResourceRecord entries with Route 53 CNAME records.
- Exit 0 if all records exist, exit 2 if records are missing, exit 1 on command failure.
- Explain the script after generating it.

Code sample

#!/usr/bin/env bash
set -euo pipefail

: "${CERTIFICATE_ARN:?CERTIFICATE_ARN is required}"
: "${AWS_REGION:?AWS_REGION is required}"
: "${HOSTED_ZONE_ID:?HOSTED_ZONE_ID is required}"

ACM_FILE="/tmp/acm-certificate-renewal-check.json"
R53_FILE="/tmp/route53-cname-records.json"
REQUIRED_FILE="/tmp/acm-required-validation-records.json"
MISSING_FILE="/tmp/acm-missing-validation-records.json"

aws acm describe-certificate \
  --region "$AWS_REGION" \
  --certificate-arn "$CERTIFICATE_ARN" \
  --output json > "$ACM_FILE"

aws route53 list-resource-record-sets \
  --hosted-zone-id "$HOSTED_ZONE_ID" \
  --query "ResourceRecordSets[?Type == 'CNAME']" \
  --output json > "$R53_FILE"

jq '[
  .Certificate.DomainValidationOptions[]
  | select(.ResourceRecord != null)
  | .ResourceRecord
  | {
      Name: .Name,
      Type: .Type,
      Value: .Value
    }
] | unique_by(.Name)' "$ACM_FILE" > "$REQUIRED_FILE"

jq -n \
  --slurpfile required "$REQUIRED_FILE" \
  --slurpfile actual "$R53_FILE" '
  $required[0]
  | map(select(
      . as $req
      | ($actual[0]
        | any(
            .Name == $req.Name
            and .Type == $req.Type
            and (.ResourceRecords[]?.Value == $req.Value)
          )
        | not
      )
    ))' > "$MISSING_FILE"

MISSING_COUNT=$(jq 'length' "$MISSING_FILE")
REQUIRED_COUNT=$(jq 'length' "$REQUIRED_FILE")

if [ "$REQUIRED_COUNT" -eq 0 ]; then
  echo "No ACM DNS validation records were found for this certificate."
  exit 2
fi

if [ "$MISSING_COUNT" -gt 0 ]; then
  echo "Missing or mismatched ACM DNS validation record count: $MISSING_COUNT"
  jq '[.[] | {Type, Name}]' "$MISSING_FILE"
  exit 2
fi

echo "All required ACM DNS validation records exist in Route 53. Record count: $REQUIRED_COUNT"
exit 0

Detailed code explanation

Business logic: This script gives developers a repeatable verification mechanism after the console remediation. Its purpose is not to renew a certificate directly; rather, it validates that the DNS state required by ACM managed renewal exists in Route 53.

Code logic: The script exports ACM certificate metadata and Route 53 CNAME records into temporary JSON files. It extracts ACM-required validation records, compares them with actual Route 53 records, counts missing items, and returns an exit code that automation can consume.

Expected result: Exit code 0 means all required ACM validation CNAME records are present. Exit code 2 means records are missing or unavailable. Exit code 1 is reserved for shell or AWS CLI failures due to strict mode. The script prints record type and name only for missing entries.

System design decision — Verification automation without mutation

1. Safe repeatability: A read-only verifier can be run on demand, after incidents, or on a schedule without risking DNS changes. This makes it suitable for developers who need confidence but should not mutate production records repeatedly.
2. Automation signal: Exit codes convert a console troubleshooting workflow into a machine-readable result. CI jobs, scheduled checks, or deployment gates can take action based on success or failure.
3. Minimal disclosure: The script avoids printing full certificate ARNs or account-specific identifiers. It prints only enough DNS information for remediation, reducing the risk of sensitive data appearing in shared logs.

15. Module 9 — Ask Amazon Q to Review the Script Like a Senior Developer

Goal

Use Amazon Q to harden operational code before reuse.

Amazon Q prompt sample

Review this Bash verification script as a senior cloud platform developer.
Focus on correctness, idempotency, error handling, DNS edge cases, sensitive logging, and production-readiness.
Return prioritized recommendations and explain tradeoffs.

Expected review themes

• Use strict mode: set -euo pipefail.
• Validate all required environment variables.
• Avoid logging account identifiers and full certificate ARNs.
• Avoid changing DNS in verification code.
• Normalize trailing dots if comparing outputs from mixed DNS providers.
• Handle multiple domain validation options.
• Deduplicate records.
• Keep remediation and verification as separate commands.

System design decision — AI-assisted review, human-owned correctness

1. Amazon Q accelerates review: Amazon Q can quickly identify common scripting risks, unsafe logging, missing input validation, and AWS CLI failure handling. This helps developers improve quality during a short workshop.
2. Humans keep accountability: AI-generated review is advisory. Professional developers still decide which changes belong in production and validate behavior against their environment, permissions, and operational constraints.
3. Review before reuse: Console incident fixes often become shared scripts. Reviewing now prevents fragile one-off commands from becoming embedded in build systems, runbooks, or scheduled jobs without proper safety checks.

16. Module 10 — Ask Amazon Q for Security and Operational Guardrails

Goal

Use Amazon Q to turn the fix into a production-safe practice.

Amazon Q prompt sample

Review this ACM DNS validation renewal workflow for production safety.
Focus on sensitive data exposure, access control least privilege, DNS ownership, rollback, auditability, and monitoring.
Give concise engineering recommendations.

Recommended guardrails

• Do not log real domains, account-specific identifiers, certificate ARNs, hosted zone IDs, or validation tokens in shared workshop output.
• Require peer review before production DNS changes.
• Keep validation CNAME records permanently unless the certificate is intentionally decommissioned.
• Monitor certificate expiration and validation record drift.
• Use read-only verifiers for scheduled checks.
• Separate remediation permissions from monitoring permissions.
• Store scripts in version control.
• Preserve CloudTrail and Route 53 change history for audit.
• Escalate when authoritative DNS is outside the current account.

System design decision — Separate remediation from monitoring

1. Blast-radius control: Monitoring should detect missing records, not modify DNS automatically by default. This prevents a low-confidence detector from making high-impact DNS changes.
2. Clear ownership: DNS writes should remain with a role, team, or workflow that owns production DNS. Verification can be broader because it is read-only and low risk.
3. Auditability: Separating read checks from write actions makes it easier to review who changed DNS, why the change was made, and what evidence triggered it.

17. Final 10-Minute Console Runbook Generated with Amazon Q

Amazon Q prompt sample

Create a concise developer runbook for ACM automatic renewal readiness from the AWS Console.
Include symptoms, console diagnosis, Amazon Q questions to ask, Route 53 remediation, CloudShell verification, rollback notes, and escalation criteria.

Runbook output template

# ACM Automatic Renewal Readiness Runbook

## Symptoms
- ACM certificate renewal status is pending or blocked.
- ACM reports DNS validation is incomplete.
- A certificate is approaching expiration.

## Console diagnosis
1. Open ACM in the AWS Console.
2. Select the certificate.
3. Open Amazon Q Developer from the console panel.
4. Ask Amazon Q to explain renewal eligibility, validation method, and required DNS records.
5. Confirm the certificate is Amazon-issued, not expired, and associated with the expected AWS service.

## DNS remediation
1. Open Route 53 hosted zones.
2. Select the authoritative public hosted zone.
3. Add or repair ACM-provided CNAME validation records.
4. Keep the records permanently.

## Verification
1. Wait for Route 53 change status to become INSYNC.
2. Return to ACM certificate details.
3. Ask Amazon Q what status fields should change.
4. Run the CloudShell ACM status command.
5. Run the DNS validation verifier if available.

## Rollback
- Do not delete correct ACM validation records.
- If an incorrect CNAME was created, replace it with the ACM-provided value.
- If the wrong hosted zone was changed, apply the correct record to the authoritative zone.

## Escalation
- Escalate if authoritative DNS is managed by another account or provider.
- Escalate if validation remains pending after DNS propagation.
- Escalate if the certificate is imported, expired, or not eligible for managed renewal.

System design decision — Runbook as final artifact

1. Knowledge capture: The workshop should not end with only a fixed certificate. It should produce a repeatable operating procedure that other developers can follow later.
2. Consistency: A runbook standardizes terminology, verification commands, rollback behavior, and escalation criteria. This reduces confusion during future renewal events.
3. AI-assisted documentation: Amazon Q can convert the conversational troubleshooting path into structured documentation while the context is fresh. Developers then review and store the runbook as owned engineering knowledge.

18. End-to-End Developer Checklist

• Open ACM certificate details in AWS Console.
• Open Amazon Q Developer from the console.
• Ask Amazon Q to explain certificate renewal state.
• Confirm certificate is Amazon-issued and not expired.
• Confirm DNS validation is the validation method.
• Confirm certificate is eligible for managed renewal.
• Confirm the expected AWS service uses the certificate.
• Ask Amazon Q to identify required DNS validation records.
• Open the authoritative Route 53 hosted zone.
• Add or repair CNAME validation records.
• Wait for Route 53 change status to become INSYNC.
• Recheck ACM domain validation status.
• Ask Amazon Q to explain any remaining pending status.
• Generate a verifier script with Amazon Q.
• Ask Amazon Q to review the verifier for safe logging and correctness.
• Generate tests for verifier logic.
• Generate the final runbook.

19. Completion Criteria

The workshop is complete when the developer can demonstrate:

1. Amazon Q Developer was used from the AWS Console as the primary guide.
2. The ACM renewal problem was diagnosed without exposing account-specific identifiers.
3. Required DNS validation CNAME records were identified and mapped to Route 53 fields.
4. Route 53 remediation was completed through console steps or reviewed CloudShell commands.
5. ACM and Route 53 states were verified independently.
6. Reusable verification automation was generated and reviewed.
7. Unit tests were generated for core comparison logic.
8. Security and operational guardrails were documented.
9. A sanitized developer runbook was produced.

20. References

• Amazon Q Developer in the AWS Management Console: https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/ask-q.html
• Amazon Q resource troubleshooting: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-actions-troubleshooting.html
• Amazon Q Developer documentation overview: https://aws.amazon.com/documentation-overview/q-developer/
• ACM DNS validation: https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html
• ACM managed certificate renewal: https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html
• Route 53 validation guidance for ACM certificates: https://www.repost.aws/knowledge-center/route-53-validate-acm-certificates

21. Sanitized Console Conversation Added to Workshop

Goal

Show how the workshop conversation can unfold when a developer asks Amazon Q Developer to help restore ACM automatic renewal from the AWS Console. This transcript is sanitized: it contains no real DNS name, account-specific identifier, hosted zone identifier, validation token, or production certificate identifier.

conversation walkthrough

Developer:

Renew certificate <certificate-id> for <workshop-domain>.

Amazon Q Developer:

I'll help you renew the certificate with ID <certificate-id> for <workshop-domain>. I can see you are viewing the AWS Certificate Manager certificate details page in the certificate region. I will check the current console context and provide guidance for certificate renewal.

Amazon Q Developer page-context guidance:

You are currently viewing the ACM certificate details page for certificate <certificate-id>. Certificate renewal can be handled in two ways:

Option 1: Force manual renewal
Use the AWS CLI command pattern:

aws acm renew-certificate \
  --certificate-arn arn:aws:acm:<region>:<redacted-account>:certificate/<certificate-id>

Option 2: Automatic renewal
For future renewals, keep the certificate eligible for managed renewal by ensuring it is associated with a supported AWS service and by preserving DNS validation CNAME records.

For DNS validation, ACM checks the required CNAME records in authoritative DNS. If those records are present, ACM can complete renewal automatically. If validation uses email, renewal depends on approval through the renewal email workflow.

Developer:

Set up automatic renewal.

Amazon Q Developer:

I will check the certificate configuration and renewal state.

Amazon Q Developer observed state:

The certificate is already configured for automatic renewal, and the renewal process has been initiated.

Current findings:
- Certificate is eligible for managed renewal.
- Certificate is associated with a supported AWS service.
- Certificate uses DNS validation.
- Renewal is currently pending validation.

Issue:
The required DNS validation CNAME records are missing from the authoritative DNS zone.

Amazon Q Developer remediation guidance:

Add the ACM-provided CNAME validation records to the authoritative Route 53 hosted zone.

Record 1:
Name:  <validation-record-name-1>.<workshop-domain>
Type:  CNAME
Value: <validation-target-1>.acm-validations.aws

Record 2:
Name:  <validation-record-name-2>.<workshop-domain>
Type:  CNAME
Value: <validation-target-2>.acm-validations.aws

Console steps:
1. Open Route 53 hosted zones.
2. Select the authoritative public hosted zone for <workshop-domain>.
3. Choose Create record.
4. Enter the CNAME record name exactly as provided by ACM.
5. Select CNAME as the record type.
6. Enter the ACM validation target as the value.
7. Use simple routing and an appropriate TTL, such as 300 seconds.
8. Repeat for every ACM validation record.
9. Keep these DNS validation records permanently so future managed renewals are not blocked.

Developer:

Records added. Check it.

Amazon Q Developer:

I will verify that the Route 53 records exist and then recheck the ACM certificate renewal status.

Amazon Q Developer verification result:

The required DNS validation CNAME records are present in the authoritative hosted zone.

DNS record status:
- Record 1 is present.
- Record 2 is present.

Certificate status:
- Certificate status is ISSUED.
- Managed renewal is enabled.
- Renewal validation may still show pending while DNS propagates and ACM polls DNS.
- The certificate remains associated with the supported service, so deployment can proceed automatically after renewal completes.

Expected next steps:
1. Wait for DNS propagation and ACM validation polling.
2. Recheck ACM renewal status from the certificate details page.
3. Confirm per-domain validation status moves to success.
4. Keep the CNAME records in DNS permanently.

How this conversation maps to workshop modules

• Module 1: The developer starts from the ACM certificate details page and asks Amazon Q for page-context guidance.
• Module 2: Amazon Q explains ACM managed renewal prerequisites and why DNS validation records must remain in place.
• Module 4: Amazon Q maps ACM validation records to Route 53 CNAME fields.
• Module 5: Amazon Q guides DNS remediation through the Route 53 console.
• Module 7: Amazon Q verifies both Route 53 record presence and ACM renewal readiness.
• Module 10: Amazon Q reinforces the operational guardrail that validation records should remain permanently.

22. Certificate renewal completed Mail

Notification source: Amazon Web Services Health notification
Notification type: Informational
Subject: Your certificate is renewed

AWS Health Event

Your certificate is renewed

Greetings from Amazon Web Services,

This is to notify you that AWS Certificate Manager (ACM) has completed the renewal of an SSL/TLS certificate that includes the primary DNS name <workshop-domain> and a total of <domain-count> DNS names.

AWS environment: <redacted-account>
AWS Region name: <certificate-region>
Certificate identifier: <certificate-arn>

Your new certificate expires on <renewed-certificate-expiration-utc>.

If you have questions about this process, contact AWS Support through the Support Center. If you do not have an AWS support plan, post a new thread in the AWS Certificate Manager discussion forum.

This notification is intended solely for authorized individuals responsible for <workshop-domain>. If this notification reached you in error, follow your organization's notification-handling process.