Platform notes for developers

Developer notes for AWS Certified Developer – Associate (DVA-C02). The first page builds the platform model a developer needs; the second is the question-and-answer sweep that mirrors how the exam actually asks.

9 topics, 27 study points. Everything here is exam-oriented: each point is a fact or a distinction that DVA-C02 items are built on. Test yourself against the practice exam once you can explain a section without re-reading it.

1. VPC (Virtual Private Cloud)

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you have complete control over your virtual networking environment. You define the IP address space using CIDR notation, create subnets to segment that space, configure route tables to control traffic flow, and attach gateways to connect to the internet or your on-premises network. Think of a VPC as your own private data center inside AWS — isolated from all other customers by default, with connectivity added only where you explicitly configure it.

By default, each AWS account can have up to 5 VPCs per region (this limit can be increased via a support request). Every region comes with a default VPC pre-configured for convenience: all of its subnets have internet access, and every EC2 instance launched into the default VPC automatically receives both a public IP address and a private IP address. If you delete the default VPC, it cannot be self-restored — you must submit an AWS support ticket to have it recreated. For production workloads, always build custom VPCs tailored to your security and network requirements rather than relying on the default.

When you create a VPC, AWS automatically creates a main route table for it. Every subnet you create is associated with this main route table unless you explicitly associate it with a custom route table. A key architectural principle: the main route table should remain restrictive (no internet gateway route) so that new subnets are private by default. Only subnets that need public internet access should be associated with a route table containing an internet gateway route (0.0.0.0/0 → IGW). Subnets are always confined to a single Availability Zone — a subnet cannot span multiple AZs. The largest CIDR block you can assign to a VPC is /16, giving you up to 65,536 IP addresses.

2. IP Addressing & Subnets

AWS reserves 5 IP addresses in every subnet, which are unavailable for use by your EC2 instances or other resources. Understanding which addresses are reserved helps you correctly calculate the usable IP count. For a /24 subnet (256 total addresses), only 251 are actually usable. The five reserved addresses follow a consistent pattern: the first address (x.x.x.0) is the network address that identifies the subnet itself; x.x.x.1 is reserved for the VPC router, which handles inter-subnet routing; x.x.x.2 is reserved for the Amazon-provided DNS server for that subnet; x.x.x.3 is reserved for future use by AWS; and the last address (x.x.x.255) is the network broadcast address. AWS does not support broadcast in a VPC, but the address is reserved nonetheless.

The Amazon DNS server is always accessible at the base CIDR block of the VPC plus two — for example, in a 10.0.0.0/16 VPC, the DNS server is at 10.0.0.2. It is also reachable from any instance at the link-local address 169.254.169.253. This DNS server resolves AWS-internal hostnames (like ec2-instance.us-east-1.compute.internal) to private IP addresses, enabling seamless private hostname resolution within your VPC. By default, all traffic between subnets within the same VPC is allowed — subnets can communicate freely unless you explicitly add NACL deny rules or Security Group restrictions to block inter-subnet traffic.

Private subnets have no route to the internet gateway, which means instances in private subnets cannot initiate or receive internet traffic directly. To allow instances in private subnets to make outbound requests (for software updates, API calls, or downloading packages) without being reachable from the internet, you place a NAT Gateway in a public subnet and add a default route in the private subnet’s route table pointing to the NAT Gateway. This gives private instances outbound-only internet access. Only one Internet Gateway can be attached to a VPC at a time — the IGW is already highly available by design, so there is no need for multiple IGWs.

3. Security Groups & NACLs

Security Groups are stateful firewalls that operate at the instance level (specifically at the Elastic Network Interface). “Stateful” means that when a connection is established — regardless of direction — the return traffic is automatically permitted without needing an explicit rule. Security Groups evaluate all rules before making a decision (there is no rule ordering or priority — if any rule matches and allows the traffic, it is permitted). Security Groups support allow rules only; you cannot create an explicit deny rule in a Security Group. By default, all inbound traffic is denied and all outbound traffic is allowed, and you selectively open inbound ports for specific protocols and sources.

Network Access Control Lists (NACLs) are stateless firewalls that operate at the subnet level, applying to all traffic entering or leaving the subnet. “Stateless” means that return traffic must be explicitly allowed — if you allow inbound TCP on port 443, you must also allow outbound traffic on the ephemeral response ports (1024–65535) for the response packets to reach the client. NACLs process rules in ascending numerical order — the first matching rule is applied immediately and no further rules are evaluated. This ordering is critical: a deny rule at number 100 will override an allow rule at number 200 for the same traffic, because 100 is evaluated first.

The default NACL (attached to the default VPC) allows all inbound and outbound traffic by default — it has permissive allow-all rules so the default VPC works out of the box. Custom NACLs that you create start with everything denied by default — you must explicitly add allow rules for the traffic you want to permit. A subnet can have exactly one NACL associated with it, but one NACL can be associated with multiple subnets. A key capability that Security Groups lack: NACLs can explicitly deny traffic from specific IP addresses or CIDR ranges, making them the right tool for blocking known malicious IP addresses at the network perimeter.

4. NAT & Internet Gateway

Network Address Translation (NAT) enables instances in private subnets to initiate outbound connections to the internet while remaining unreachable from inbound internet traffic. There are two NAT options in AWS, and understanding the operational differences between them is important. NAT Instances are the older, legacy approach — you launch a standard EC2 instance from a special NAT AMI in a public subnet and configure it to forward packets for private instances. Because the NAT instance forwards traffic on behalf of other instances (not just for itself), you must disable the Source/Destination Check attribute — by default, EC2 drops packets whose source or destination IP does not match the instance’s own IP, which would break NAT forwarding.

NAT Instances have significant operational drawbacks: they are a single point of failure (if the instance fails, all private subnet internet connectivity is lost), they are limited in bandwidth by the EC2 instance type you choose, and they require manual patching and management. You can associate Security Groups with NAT Instances to control what traffic they forward. NAT Gateways are the modern, fully managed alternative — AWS manages the underlying infrastructure, they automatically scale up to 45 Gbps, and they are highly available within a single AZ. For cross-AZ HA, deploy one NAT Gateway per AZ and update each AZ’s private route table to use its local NAT Gateway. NAT Gateways do not support Security Groups and cannot be associated with an Elastic IP you manage — AWS assigns a public IP automatically.

Bastion hosts (also called jump boxes) are EC2 instances deliberately placed in a public subnet to serve as a secure, controlled entry point into your private subnets for administrative access. Administrators connect to the bastion host via SSH (Linux) or RDP (Windows) from the internet, and from there can connect to private instances using their private IP addresses. Bastion hosts should be hardened — minimal installed software, restricted inbound access limited to known administrator IP addresses, and all session activity logged. AWS Systems Manager Session Manager is increasingly preferred over bastion hosts because it provides browser-based shell access to private instances without any open inbound ports, eliminating the attack surface entirely.

5. VPC Endpoints & Peering

VPC Endpoints allow your instances to communicate with AWS services privately, without their traffic ever leaving the Amazon network or traversing the internet. This is particularly important for sensitive data (you do not want DynamoDB queries or S3 uploads traversing the public internet) and for private subnet instances that do not have internet access via a NAT Gateway. There are two types of VPC Endpoints. Interface Endpoints create an Elastic Network Interface (ENI) with a private IP address inside your subnet for the target AWS service — powered by AWS PrivateLink, they work with a wide range of services including SQS, SNS, KMS, Secrets Manager, CloudWatch, and hundreds of others. Interface Endpoints are billed per hour and per GB of data processed.

Gateway Endpoints are a different mechanism, exclusively available for Amazon S3 and Amazon DynamoDB. Instead of creating an ENI, a Gateway Endpoint adds an entry to your route table that redirects traffic destined for S3 or DynamoDB through the endpoint rather than through the internet. Gateway Endpoints are free of charge and do not require changes to your Security Groups. A common exam scenario: a private subnet instance needs to write to S3 without internet access — the answer is a Gateway Endpoint for S3, not a NAT Gateway, because Gateway Endpoints are free and keep traffic private.

VPC Peering establishes a private, direct networking connection between two VPCs, allowing instances in each VPC to communicate using private IP addresses as if they were in the same network. You can peer VPCs in the same account, across different accounts, or across different regions (inter-region VPC peering). VPC Peering is non-transitive: if VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic cannot flow from A to C through B — you must establish a direct peering connection between A and C. Additionally, peered VPCs cannot have overlapping CIDR blocks. For connecting many VPCs in a hub-and-spoke or full-mesh topology, AWS Transit Gateway is the scalable alternative to managing many individual peering connections.

6. EBS & Storage

Amazon EBS volumes are persistent, network-attached block storage devices for EC2 instances. They behave like raw, unformatted physical hard drives — you format them with a file system and mount them to your instance. EBS volumes persist independently of the EC2 instance lifecycle: when you stop an instance, its EBS root volume is preserved, and you can restart the instance later with all data intact. The four main EBS volume types serve different workloads: gp2 and gp3 (General Purpose SSD) deliver balanced performance for most applications; io1 and io2 (Provisioned IOPS SSD) are designed for I/O-intensive databases requiring consistent, high IOPS; st1 (Throughput Optimized HDD) offers high sequential throughput for data warehousing and log processing; sc1 (Cold HDD) provides the lowest cost per GB for infrequently accessed workloads.

EBS volumes can be resized and their type changed on the fly without detaching them or stopping the instance — a feature called Elastic Volumes. You can increase the size of a volume or change from gp2 to io2 while it is actively in use. However, a critical constraint: an EBS volume can only be attached to an EC2 instance in the same Availability Zone. To move data to a different AZ, you must take a snapshot of the volume and create a new volume from that snapshot in the target AZ. To move data to a different region, you take a snapshot, copy the snapshot to the target region using the Copy Snapshot feature, and create a new volume from the copied snapshot. From a snapshot you can also create an AMI, which can be used to launch instances in any AZ within the region.

EBS encryption protects data at rest, in transit between the instance and the volume, and in all snapshots. When you enable encryption on a volume at creation time, all of these are automatically encrypted using a KMS key (either the default AWS-managed key or a customer-managed key). Encrypted snapshots of encrypted volumes are also encrypted. New volumes created from encrypted snapshots inherit the encryption. An important sharing limitation: you cannot share an encrypted snapshot with another AWS account because the KMS key used for encryption is tied to your account — the receiving account would not be able to decrypt it. To share data across accounts, you must use unencrypted snapshots or explicitly share the KMS key and the snapshot with the target account.

7. Lambda & Serverless

AWS Lambda is a serverless compute service that runs your code in response to events without requiring you to provision or manage servers. You upload your code (or a container image), configure memory and timeout, and Lambda handles everything else — scaling, patching, availability, and execution infrastructure. Lambda scales automatically from zero to thousands of concurrent executions in response to demand, and you are billed only for the actual compute time your function consumes (rounded to the nearest millisecond) plus a small per-invocation charge. Lambda natively supports Node.js, Python, Java, C# (.NET), Go, PowerShell, and Ruby. For languages not natively supported, you can bring any runtime using a custom runtime or package your function as a container image.

Lambda functions are triggered by events from dozens of AWS services and external sources. Common triggers include API Gateway (HTTP requests), S3 (object create/delete events), DynamoDB Streams (table change events), SQS (message queue processing), SNS (pub/sub notifications), CloudWatch Events/EventBridge (scheduled or rule-based triggers), and Kinesis Streams (real-time data processing). Lambda functions can run inside your VPC, giving them access to private resources like RDS databases and ElastiCache clusters — but VPC-connected Lambda functions consume ENI capacity in your subnets, so you must ensure your subnets have sufficient IP addresses available. Lambda@Edge extends Lambda to CloudFront edge locations, enabling you to run lightweight code closer to users to customize request and response handling — for example, rewriting URLs, adding security headers, or performing A/B testing without an origin round-trip.

Amazon API Gateway is a fully managed service for creating, publishing, securing, and monitoring RESTful and WebSocket APIs at any scale. It handles traffic management, authorization (via IAM, Lambda authorizers, or Cognito User Pools), throttling (rate limiting per API key or stage), request and response transformation, caching (TTL-configurable response caching per stage), and CORS configuration. API Gateway supports multiple deployment stages (development, staging, production) and stage variables that let you parameterize backend integrations per stage. Stage variables are commonly used to point different stages to different Lambda function aliases or backend URLs without changing API configuration. Canary deployments on API Gateway let you shift a percentage of traffic to a new stage configuration before fully deploying it.

8. DynamoDB

Amazon DynamoDB is a fully managed, serverless NoSQL database designed for single-digit millisecond performance at any scale. Data is stored on SSD storage and automatically replicated across three geographically distinct data centers within the same AWS Region, providing built-in high availability and durability. DynamoDB uses a flat data model based on tables, items (equivalent to rows), and attributes (equivalent to columns). Each item is uniquely identified by a primary key, which is either a single partition key (a hash key) or a composite key consisting of a partition key plus a sort key. DynamoDB distributes data across partitions based on the partition key hash, so choosing a partition key with high cardinality and even distribution is critical to avoid hot partitions that throttle performance.

DynamoDB offers two read consistency models. Eventually consistent reads (the default) may return slightly stale data because DynamoDB might serve the read from a replica that has not yet received the latest write — consistency is typically achieved within one second. Strongly consistent reads always return the most up-to-date data, reflecting all writes that received a successful response, but they consume twice the read capacity units (RCUs) and are not available from Global Secondary Indexes. Choose eventually consistent reads for the majority of read traffic to maximize throughput and reduce cost, and use strongly consistent reads only where your application requires guaranteed freshness.

DynamoDB Streams captures a time-ordered sequence of item-level changes in a DynamoDB table — inserts, updates, and deletes — and retains them for up to 24 hours. Each stream record contains the item key, the new image (after modification), the old image (before modification), or both, depending on your configuration. DynamoDB Streams are commonly used with Lambda triggers for event-driven processing: replicating changes to other services, maintaining search indexes in Elasticsearch, sending notifications, or computing aggregations. DynamoDB Accelerator (DAX) is a fully managed, in-memory cache built specifically for DynamoDB. It sits between your application and DynamoDB and reduces read latency from single-digit milliseconds to microseconds for eventually consistent reads — ideal for read-heavy workloads like gaming leaderboards, real-time bidding, or social media feeds. Global Tables extend DynamoDB to multiple regions with multi-active (multi-master) replication, enabling low-latency reads and writes from any region with automatic conflict resolution.

9. SQS, SNS & Kinesis

Amazon SQS (Simple Queue Service) is a fully managed message queuing service that decouples application components so they can scale and operate independently. Producers write messages to the queue; consumers poll the queue and process messages at their own pace. The queue acts as a buffer — if the consumer is slower than the producer, messages accumulate in the queue rather than being dropped or causing the producer to block. SQS Standard queues offer virtually unlimited throughput, at-least-once delivery (a message may be delivered more than once), and best-effort ordering. SQS FIFO queues guarantee exactly-once processing and strict first-in, first-out ordering, but have a throughput limit of 300 messages per second (3,000 with batching). The visibility timeout (default 30 seconds, maximum 12 hours) defines how long a message is hidden from other consumers after being received — during this window, the consumer must process and delete the message; if it fails to do so, the message reappears for reprocessing.

Long polling is a SQS feature that reduces cost and unnecessary API calls. With short polling (the default), SQS immediately returns a response — even if the queue is empty — requiring your consumer to repeatedly call ReceiveMessage in a tight loop. With long polling, SQS waits up to 20 seconds for a message to arrive before returning an empty response, dramatically reducing the number of API calls and associated costs for queues with infrequent messages. Always enable long polling for production consumers unless you have a specific requirement for short polling.

Amazon SNS (Simple Notification Service) implements the publish-subscribe (pub/sub) messaging pattern. A publisher sends a single message to an SNS Topic, and SNS fans out that message to all subscribed endpoints simultaneously — without the publisher needing to know about or manage individual subscribers. SNS supports pushing to SQS queues, Lambda functions, HTTP/HTTPS endpoints, email addresses, and SMS. The SNS-to-SQS fan-out pattern is extremely common: publish to one SNS topic to simultaneously trigger multiple independent processing pipelines, each consuming from their own SQS queue. Amazon Kinesis Data Streams is designed for real-time, high-throughput data streaming where multiple consumers need to process the same data stream independently and in order. Unlike SQS (where a message is consumed and deleted), Kinesis retains records for 24 hours by default (up to 365 days), enabling replay and independent consumption by different consumer applications. Kinesis Data Firehose is a fully managed delivery service that automatically loads streaming data into S3, Redshift, OpenSearch, or Splunk without requiring any consumer code.

Where to go next

Back to the AWS Developer Associate overview.
Look up any service you could not name in the AWS services glossary.
Sit the 80-item practice exam once two or three note pages are solid.