46.5 Domains, S3, RDS and Live-Project Security Questions

Q43. What DNS records do you use for a simple site on EC2?

An A record points the apex or host to the Elastic IP. CNAME often points www to the apex or to another hostname. I wait for TTL to expire when testing changes and I never leave zone transfers open to the world.

Q44. How do you enable HTTPS with Certbot in a lab story?

On a machine I control with a real domain pointing to my EIP, I install Certbot for Nginx or Apache, obtain a certificate, and reload the web server after config test. UI steps vary; I stress auto-renew and TLS version hygiene.

Q45. What is S3 Block Public Access and why does it matter?

It is an account/bucket-level set of switches that prevent accidental public ACLs and policies. Many leaks are misconfigured public buckets. For Sahyadri video uploads I keep BPA on and use presigned URLs or CloudFront patterns instead of public-read objects.

Q46. When would you use a presigned URL?

When the object should stay private but a browser needs short-term access, such as playing a reel video. The URL expires. I never embed long-lived credentials in mobile apps.

Q47. How should EC2 reach S3 and RDS without access keys in code?

I attach an IAM role to the instance with least-privilege policies for the specific bucket and actions. RDS stays in private subnets; the app security group is allowed on 3306. Access keys in PHP files are a student favourite mistake.

Q48. What belongs on a live-project security checklist?

HTTPS on, security groups tight, RDS not public, S3 BPA on, IAM role not root keys, prepared statements, cookie flags, OS patches, backups tested, CloudTrail on, and secrets not in git. I can walk that list for the Instagram-reel style lab project.

Q49. What is the risk of a public RDS snapshot or open 3306?

Data exposure of customer tables, ransomware, or dump-and-leak. Defence: private subnet, SG from app only, encryption at rest, least-privilege DB users, and no public snapshot sharing.

Q50. How do you explain subdomain takeover at a conceptual level?

If a DNS CNAME points to an abandoned cloud resource someone else can claim, attackers may host content on your hostname. Defence: inventory DNS, remove stale records, and monitor. I discuss the idea; I do not hunt third-party domains.