🤖 $250 Community Challenge – Agent Mode Prompts | 5 days

[dotaadarsh (Aadarsh)]

Prompt used:

“Generate a Terraform module that provisions an S3 bucket and aligns it with the API defined in the spec.”

---

What I ran it on

I started with a small OpenAPI definition in Postman for a Media Storage API that wraps S3, not just a generic bucket:

• PUT /upload/{key} to upload media objects, with Content-Type restricted to image/jpeg, image/png, or video/mp4.

• GET /{key} and DELETE /{key} to read and delete objects from a given bucket.

• The server URL and bucket parameter encode a naming convention like media-[a-z0-9]+-(dev|staging|prod), so the bucket name pattern is part of the contract, not a comment.

This gave Agent Mode a clear description of how the bucket should behave and how it would be used by clients.

---

What the agent built for me

From that API spec and a single prompt, Agent Mode produced a production-ready S3 Terraform module, not just a single resource:

• main.tf

  • aws_s3_bucket with force_destroy, standard tags (Name, ManagedBy = "Terraform") plus custom tags.

  • aws_s3_bucket_versioning controlled by a versioning_enabled variable.

  • aws_s3_bucket_server_side_encryption_configuration that supports AES256 by default and optionally KMS with kms_master_key_id and bucket_key_enabled.

  • aws_s3_bucket_public_access_block and aws_s3_bucket_ownership_controls wired to variables and defaulting to secure settings.

  • aws_s3_bucket_lifecycle_configuration built from a high-level lifecycle_rules variable using nested dynamic blocks for transitions, expirations, and noncurrent versions.

  • Optional aws_s3_bucket_logging driven by logging_enabled, logging_target_bucket, and logging_target_prefix.

    

• variables.tf

  • A bucket_name variable with length and regex validation that matches AWS naming rules, turning my spec’s naming convention into real guardrails.

  • Switches for versioning, force destroy, encryption mode, KMS key, public access flags, ownership mode, lifecycle rules, and logging, so teams can tune behavior without touching HCL

    

• outputs.tf

  • All the identifiers other stacks need: bucket ID, ARN, domain names, region, hosted zone ID.

  • Outputs for versioning_enabled, encryption_algorithm, and kms_key_id, plus helper ARN patterns for bucket‑ and object‑level IAM policies.

    

• README.md

  • A clear module description, input/output tables, and a copy‑pasteable example:

    module "s3_bucket" {
      source             = "./terraform-aws-s3-bucket"
      bucket_name        = "my-unique-bucket-name"
      versioning_enabled = true
    
      tags = {
        Environment = "production"
      }
    }
    

    

---

How I tested it with Terraform

As a follow-up, I asked Agent Mode to “Test the module with terraform init and terraform plan?”, and it generated a test.tf file to exercise the module in isolation:

• It configured the AWS provider with skip_credentials_validation, skip_metadata_api_check, and skip_requesting_account_id, plus mock access keys, so I could run plan locally without real AWS credentials.

• It added a random_string resource to generate a unique suffix for the bucket name.

• It instantiated my module as module "test_s3_bucket" with:

  bucket_name = “test-bucket-${random_string.bucket_suffix.result}”
  
  tags = {
  Environment = “test”
  Project     = “terraform-module-test”
  ManagedBy   = “terraform”
  }
  

• It exposed test_bucket_id and test_bucket_arn outputs for quick verification.

With that file in place, I ran: terraform init and terraform plan and was able to validate that the generated module plans cleanly end‑to‑end without needing to hand-write any test harness.

---

What changed in my workflow

Normally, taking an API spec for S3-backed media storage all the way to a reusable, tested Terraform module means hours of work: designing the bucket config, encoding encryption and public access best practices, wiring lifecycle rules and logging, exposing useful outputs, writing documentation, and then building a separate test configuration to run plan.

With Agent Mode in Postman, I stayed in a single workspace: I defined the API once, used one prompt to get a production-grade S3 module, and a follow-up prompt to get a ready-to-run test.tf for terraform init and terraform plan. My role shifted from writing Terraform and test harnesses to reviewing them - which is exactly the kind of workflow upgrade I want from an AI agent.