TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
kconnect - A CLI utility that can be used to discover and securely access Kubernetes clusters across multiple operating environments.
🧠 USE CASE
Using cross origin resource sharing (CORS) in Amazon S3
In modern cloud apps, the frontend and backend rarely sit on the same domain. Your UI may be on your-domain.com, while files, APIs, or services could live on other-domain.com. This split architecture improves scalability but also triggers browser security checks that block requests across domains.
What is CORS?
Cross Origin Resource Sharing (CORS) is the mechanism that lets a browser safely fetch resources from a different origin. It’s essentially a contract: the server explicitly states which external origins are trusted and which request methods are allowed. Without it, cross domain calls fail by default.
Key terms you should know:
Origin → The domain where your app runs (e.g., your-domain.com).
Cross Origin Server → The domain hosting the resource (e.g., other-domain.com).
Access-Control-Allow-Origin → The server response header that decides if the browser can use the resource.
How a Typical CORS Flow Works
Preflight Request
The browser first sends an OPTIONS request to the cross-origin server (other-domain.com).
This request checks whether the origin (your-domain.com) is allowed to access the resource.
Preflight Response
The cross origin server responds with its CORS policy.
It specifies which origins and HTTP methods (GET, PUT, POST, etc.) are permitted.
Actual Request
If the preflight check passes, the browser makes the real request to the cross origin server.
Response
The cross origin server responds with the resource.
Since the origin was allowed, the browser accepts the response and delivers it to the app
Without the preflight negotiation, browsers would block the request entirely. This handshake ensures only trusted origins can access sensitive data, keeping cross domain interactions both functional and secure.
Here’s how to enable CORS the right way in S3:
1. Identify the access pattern
Frontend reads only → allow GET.
File uploads from browser → add PUT or POST.
APIs behind S3 static hosting → may require HEAD for checks.
2. Add a CORS configuration to your bucket
Go to your S3 bucket → Permissions → CORS configuration and apply JSON like:
[
{
"AllowedHeaders": ["*"],
"AllowedMethods": ["GET", "PUT"],
"AllowedOrigins": ["https://app.your-company.com"],
"ExposeHeaders": ["ETag"],
"MaxAgeSeconds": 3000
}
]AllowedOrigins → Don’t use "*" in production. Always specify your real domain.
AllowedMethods → Keep it minimal. Avoid DELETE unless absolutely required.
ExposeHeaders → Add only headers your frontend really needs (e.g., ETag).
In S3, CORS is not a “set and forget.” It’s is matching the browser’s handshake with the minimal rules your app actually needs. Start with the smallest surface area and expand only if you hit real use cases.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 50,000+ DevOps and Cloud Professionals? Let's work together.
