Drag and Drop Matching Questions

Amazon RDS (MySQL engine): 3306

When you provision an Amazon RDS instance running the MySQL engine, the DB engine listens on TCP port 3306 by default, matching the standard MySQL community server port. This means your connection string, client tool, and VPC security group inbound rule must all reference port 3306 to reach the database. The RDS service deliberately preserves the familiar MySQL port to make connections feel like a native on-prem MySQL deployment.

Amazon Redshift: 5439

Amazon Redshift uses 5439 as its default port for JDBC, ODBC, and psql-style connections, not the 5432 you might expect from its PostgreSQL lineage. When you create a Redshift cluster, the endpoint is provided as a hostname with this port, and you must open inbound TCP 5439 in the cluster's security group. Even though Redshift is built on a fork of PostgreSQL 8.x, AWS assigned a distinct port to avoid conflicts and signal its unique mass-parallel-processing architecture.

Amazon RDS (PostgreSQL engine): 5432

Amazon RDS for PostgreSQL adheres to the IANA-registered default port 5432, which is the same port used by a standard PostgreSQL server. When connecting with pgAdmin, psql, or any application driver, you specify the endpoint plus 5432, and the RDS security group must allow traffic on that port. This consistency reduces friction for developers moving from a self-managed PostgreSQL database to RDS.

IAM: Controls access to AWS services and resources for users and roles.

IAM provides fine-grained access control by letting you create users, groups, and roles and attach JSON policies that explicitly allow or deny actions on AWS resources. It manages both authentication, through credentials, MFA, or federated identities, and authorization, including temporary credentials via AWS STS. This capability is what makes IAM the core service for securely controlling access across an AWS account.

Security Groups: Acts as a virtual firewall for EC2 instances.

A security group is a stateful virtual firewall that operates at the elastic network interface (ENI) level of an EC2 instance. It contains inbound and outbound rules that allow specific traffic based on protocol, port, and source or destination CIDRs or security group IDs, and it evaluates all rules before allowing traffic—unmatched traffic is implicitly denied. Because it is stateful, returning traffic is automatically allowed regardless of outbound rules.

KMS: Creates and manages encryption keys.

AWS Key Management Service (KMS) is a managed service that creates, stores, rotates, and deletes cryptographic keys used to encrypt data across AWS services. It uses KMS keys and supports envelope encryption, where a data key encrypts your data and the KMS key encrypts that data key, enabling centralized key management and integration with CloudTrail for audit. KMS also integrates with IAM for key usage permissions.

CloudTrail: Records API activity in your AWS account.

AWS CloudTrail is a governance and auditing service that continuously logs all API activity in your AWS account, recording details such as who made the call, the source IP, service, resource, and timestamp. These event logs help with security analysis, operational troubleshooting, and compliance reporting, and they can be delivered to S3 or CloudWatch Logs. Recording API activity is therefore the function of CloudTrail, not IAM.

200: OK

200 OK is the standard success response in HTTP, indicating that the server fully processed the request and is returning the expected content in the response body. It is used for successful requests such as GET, where the resource is retrieved, and it can also accompany responses to POST or PUT that include the result of an action. Unlike 201 Created, 200 does not imply that a new resource was created; it simply confirms that the request completed without error.

404: Not Found

404 Not Found is a client-error status returned when the server cannot find a resource matching the request URI, commonly caused by a typo in the URL, a deleted resource, or an undefined route. This status tells the client that the request itself is well-formed but the target resource is absent. It is distinct from 403 Forbidden, because the server is not making an authorization decision; it simply has nothing to serve.

500: Internal Server Error

500 Internal Server Error is a generic server-error response, raised when an unexpected condition prevents the server from fulfilling the request. It typically signals an unhandled exception, a configuration problem, or a failure in a downstream backend service, and the server does not expose specific details about the root cause. Unlike 4xx errors, which implicate the client, 500 makes it clear that the fault lies with the server infrastructure.

AWS Lambda: Serverless compute service that runs code in response to events.

AWS Lambda is a serverless compute service that executes code in response to triggers such as API Gateway requests, S3 object uploads, or DynamoDB table updates, automatically managing the underlying infrastructure. You write functions in languages like Python, Node.js, or Java, and Lambda scales horizontally by running concurrent instances for each event, with billing based on execution time and requests. It is purpose-built for event-driven, short-lived workloads, not as a persistent data store.

Amazon DynamoDB: Fully managed NoSQL database service for key-value and document data.

Amazon DynamoDB is a fully managed NoSQL key-value and document database that delivers single-digit millisecond latency at any scale, using tables, items, and attributes rather than SQL relational schemas. It supports on-demand and provisioned capacity modes, global tables for multi-Region replication, and features like DynamoDB Streams and TTL for time-based data expiration. Its design makes it ideal for high-traffic web apps, gaming, and IoT telemetry, but it does not execute arbitrary code.

Amazon S3: Scalable object storage service for storing and retrieving any amount of data.

Amazon S3 is a scalable object storage service that stores data as objects in buckets, offering 99.999999999% (11 nines) durability through redundant replication across multiple Availability Zones. It supports versioning, lifecycle policies, server-side encryption, and static website hosting, and you can retrieve any amount of data from anywhere via REST APIs or SDKs. S3 is not a database or a compute runtime, but a highly durable, cost-effective storage tier for backups, data lakes, and media.

AWS Elastic Beanstalk: PaaS for deploying and scaling web applications.

AWS Elastic Beanstalk is a platform-as-a-service that automates the deployment, capacity provisioning, load balancing, and auto-scaling of web applications, letting developers upload code and have AWS handle the operational stack. It supports common platforms like Java, .NET, PHP, Node.js, Python, Ruby, and Docker, while giving optional access to the underlying EC2 instances. Unlike Lambda, it runs long-lived web servers rather than event-driven functions, and you still pay for the underlying compute resources.

S3 Standard: Designed for frequently accessed data with low latency and high throughput.

S3 Standard is the default storage class optimized for frequently accessed data, offering low latency and high throughput for active workloads. It stores data redundantly across multiple Availability Zones (AZs) within a region, providing 99.99% availability and 99.999999999% durability. This class suits dynamic content, big data analytics, and mobile applications where retrieval consistency and speed are critical.

S3 Intelligent-Tiering: Automatically moves data between access tiers to optimize costs.

S3 Intelligent-Tiering is the only storage class that automatically monitors access patterns and shifts objects between frequent, infrequent, and optional archive-access tiers without retrieval fees or lifecycle rules. It charges a small monthly monitoring/automation fee per object but no retrieval charge when data moves between active tiers. Cost optimization happens because you benefit from lower storage costs for long-lived, unpredictable workloads without sacrificing performance.

S3 Glacier Instant Retrieval: Archive storage with milliseconds retrieval time.

S3 Glacier Instant Retrieval is designed for archive data that still requires millisecond access, such as medical images or active archival footage. It offers the lowest storage cost among archive classes with immediate retrieval, storing data redundantly across multiple AZs. This contrasts with Glacier Flexible or Deep Archive, which trade retrieval time (minutes to hours) for even lower storage price.

S3 One Zone-IA: Infrequent access data stored in a single Availability Zone.

S3 One Zone-IA is intended for infrequently accessed data that can be recreated if the AZ fails, storing it in only a single Availability Zone. It delivers the same durable 99.999999999% object-level durability as other classes but with 99.5% availability and no multi-AZ resilience. Common use cases include secondary backup copies, on-premises data replication, or scratch data where cost savings outweigh the need for high availability.

Rolling deployment: Incrementally replaces instances of the previous version with new version instances.

Rolling deployment replaces a small, fixed batch of running instances at a time, leaving the remaining instances in service to continue handling traffic. As each batch passes health checks, the next batch is updated, so the application never experiences a complete outage and the change can be paused or rolled back incrementally. This approach is distinct from a full simultaneous replacement because it carefully manages capacity and risk over multiple steps.

Blue/Green deployment: Deploys new version to a separate environment and shifts all traffic after validation.

Blue/Green deployment runs two completely separate environments: the current 'blue' environment and the new 'green' environment. After the green environment is fully deployed and passes validation tests, a router or load balancer switches all production traffic from blue to green in a single cutover. This allows an instant rollback by flipping traffic back to blue, but it requires hosting and maintaining twice the infrastructure during the transition.

Canary deployment: Releases new version to a small subset of users before rolling out to all.

Canary deployment exposes the new version to only a small, controlled subset of users or servers, typically 5-10% of traffic, while the rest continue on the old version. The team monitors key performance indicators and error rates for the canary group, and only if metrics remain healthy does the rollout gradually increase traffic to the new version. This early-warning technique limits blast radius but does not involve a separate full environment or a single all-at-once traffic switch.