Exam question-and-answer sweep

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.

8 topics, 25 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. EC2 / EBS / ECS

When an EC2 instance behind a load balancer uses AWS STS (Security Token Service) to obtain temporary credentials for calling AWS APIs, the application must handle credential expiration. STS temporary credentials have a configurable lifetime ranging from 15 minutes to 12 hours (the exact maximum depends on the role’s session duration setting). The application should proactively renew credentials before they expire — the AWS SDK handles this automatically when using IAM roles assigned to EC2 instances. If you hardcode STS credentials instead of using the SDK credential chain, you must implement manual refresh logic. The exam often presents scenarios where credentials expire unexpectedly — the root cause is typically hardcoded STS credentials rather than role-based credential retrieval.

When website visitors receive timeout errors on an EC2-hosted application, the most common network-level cause is a missing or incorrect Security Group inbound rule. By default, all inbound traffic to an EC2 instance is blocked unless you explicitly add allow rules. The Security Group must have an inbound rule permitting the protocol and port your application listens on (TCP 80 for HTTP, TCP 443 for HTTPS) from the appropriate source (0.0.0.0/0 for public access, or the ALB’s Security Group for private instances behind a load balancer). Common mistakes: using the wrong port, specifying IPv4 CIDR but forgetting IPv6 (::/0), or attaching the rule to the wrong Security Group.

When ECS is running behind an Application Load Balancer, you should configure the ECS task’s Security Group to only accept inbound traffic from the ALB’s Security Group — not directly from the internet. This ensures all traffic flows through the ALB (where you can apply WAF rules, SSL termination, and access logging) and prevents users from bypassing the load balancer to reach your containers directly. To grant an ECS task permission to call AWS services like DynamoDB, never use IAM user credentials hardcoded in the task environment. Instead, create an IAM role with the necessary permissions and assign it as the ECS Task Role in the task definition — the ECS service automatically provides temporary credentials to the task via the metadata endpoint, with no code changes required.

If ECS tasks are not running the latest version of a Docker image despite updating the image in ECR, the likely cause is that the task definition references a specific image tag (or uses “latest” but the previous image with that tag is cached). Force a new deployment on the ECS service, which causes ECS to pull the latest image from ECR for each new task placement. Tagging images with immutable, version-specific tags (e.g., build commit SHA or semantic version) rather than “latest” is a best practice — it makes deployments predictable and avoids cache confusion. EBS volumes are AZ-scoped: you cannot attach an EBS volume to an EC2 instance in a different Availability Zone. If you need to move a volume to a different AZ, create a snapshot and then create a new volume from that snapshot in the target AZ. Instance Store volumes are ephemeral — data is permanently lost when an instance is stopped, terminated, or experiences a hardware failure. Never use Instance Store for any data that must survive beyond the instance’s runtime.

2. RDS

When an application performs heavy read operations (millions of CRUD operations against a relational database), the primary architectural solution is RDS Read Replicas. A Read Replica is an asynchronously replicated copy of your primary RDS instance that handles read traffic, relieving pressure on the primary database so it can focus on writes. You route read queries (SELECT statements) to the read replica endpoint and write queries (INSERT, UPDATE, DELETE) to the primary endpoint — this typically requires application-level routing logic, often implemented using separate connection pool configurations. Read Replicas can be in a different AZ within the same region or in an entirely different region (cross-region Read Replicas), the latter being useful for disaster recovery and serving read traffic closer to geographically distributed users.

RDS Multi-AZ is fundamentally different from Read Replicas in both purpose and mechanism. Multi-AZ creates a synchronous standby replica in a different AZ — every write to the primary is synchronously replicated to the standby before the write is acknowledged. Multi-AZ is purely a high availability feature: the standby is not readable and does not serve any traffic during normal operation. Its sole purpose is automatic failover — if the primary instance fails, RDS automatically promotes the standby and updates the DNS endpoint to point to the new primary. Multi-AZ failover typically completes within 1–2 minutes. When the exam asks about high availability and automatic failover for RDS, the answer is Multi-AZ; when it asks about read scaling, the answer is Read Replicas.

RDS Proxy is a fully managed database proxy that sits between your application (particularly Lambda functions and ECS tasks) and your RDS database. Lambda functions can create thousands of concurrent database connections during traffic spikes, which can overwhelm RDS (databases have a finite connection limit). RDS Proxy maintains a persistent pool of connections to the database and multiplexes application connections onto that pool — thousands of Lambda invocations share a much smaller number of actual database connections. RDS Proxy also improves failover time: because it maintains the connection pool, it can reconnect to the new primary instance during a Multi-AZ failover without the application experiencing connection errors. RDS Proxy supports IAM authentication and Secrets Manager integration for secure, credential-free database access from Lambda functions.

3. S3

S3 bucket policies are JSON-based resource policies attached directly to a bucket that define who can perform which actions on the bucket and its objects. To make a bucket publicly readable (for static website hosting), you add a bucket policy with Principal set to ”*” (any anonymous user) and Action set to s3

. Importantly, since AWS introduced the S3 Block Public Access feature, bucket policies granting public access only take effect if Block Public Access settings are disabled at both the account level and the bucket level — a common source of confusion when a public bucket policy does not seem to work.

S3 Server-Side Encryption (SSE) comes in three variants with different key management responsibilities. SSE-S3 (also called SSE with Amazon S3-managed keys) is the simplest option: AWS automatically manages all encryption keys using AES-256, and there is no additional cost or configuration required. SSE-KMS uses AWS Key Management Service to manage the encryption keys, giving you control over key rotation policies, the ability to audit every key usage via CloudTrail, and the ability to restrict who can decrypt data using KMS key policies — required for compliance scenarios where you need an audit trail of data access. SSE-C (Customer-Provided Keys) lets you supply your own encryption key with each API request; AWS performs the encryption and decryption but never stores your key — you are fully responsible for key management and must provide the key on every request. Client-side encryption means you encrypt data in your application before uploading to S3, so AWS never sees plaintext. To enforce that all uploads use a specific encryption method, add a bucket policy that denies PUT requests that do not include the correct x-amz-server-side-encryption header.

S3 Event Notifications trigger automated workflows in response to object-level events. You can configure a notification on a bucket to invoke a Lambda function, send a message to an SQS queue, or publish to an SNS topic whenever an object is created (PutObject, PostObject, CopyObject, CompleteMultipartUpload), deleted, or restored from Glacier. A common serverless pattern: S3 event → Lambda function → DynamoDB or RDS (process the uploaded file and persist results). S3 Cross-Region Replication (CRR) automatically replicates objects from a source bucket in one region to a destination bucket in another region. CRR requires versioning to be enabled on both the source and destination buckets. It replicates new objects only — existing objects before CRR was configured are not replicated unless you manually copy them. CRR is commonly used for disaster recovery, geographic data distribution, and compliance requirements that mandate data copies in specific regions.

4. CloudFormation

CloudFormation templates are declarative documents (JSON or YAML) that describe the AWS infrastructure you want to create. The template structure has eight possible sections. The only required section is Resources — every other section is optional. AWSTemplateFormatVersion specifies the template format version (currently always “2010-09-09”). Description provides a human-readable description. Metadata contains arbitrary data used by tools like the CloudFormation Designer. Parameters allow runtime inputs that customize the template without modifying it directly. Mappings define static lookup tables (for example, mapping region names to AMI IDs). Conditions allow conditional resource creation based on parameter values. Resources defines all the AWS resources to create. Outputs declare values to export from the stack (like an S3 bucket name or load balancer DNS name) that can be consumed by other stacks or displayed in the console.

CloudFormation intrinsic functions are built-in functions used within templates to assign dynamic values that are not known until deployment time. The most important functions are: !Ref, which returns the value of a parameter or the physical ID of a resource; !GetAtt, which retrieves an attribute of a resource (for example, !GetAtt MyLoadBalancer.DNSName retrieves the DNS name of a created load balancer); !Sub, which substitutes variables into a string (for example, !Sub “arn:aws:s3:::${BucketName}/*”); and !FindInMap, which looks up a value in a Mappings section by specifying the map name and two lookup keys. StackSets extend CloudFormation across multiple AWS accounts and regions from a single management account — you define the template once and deploy it to dozens of accounts simultaneously, which is the standard approach for applying baseline security and compliance configurations across an entire AWS Organization.

CloudFormation ChangeSets are a safety mechanism that previews what will happen before you execute a stack update. When you submit a template change, CloudFormation calculates the diff between the current stack state and the new template and presents the results — which resources will be added, modified in-place, or replaced (deleted and recreated). Resource replacement is particularly important to understand: some property changes (like changing an RDS engine version or a VPC CIDR) require AWS to delete and recreate the resource, which may cause data loss or downtime. Reviewing ChangeSets before execution allows you to catch these dangerous changes. The DependsOn attribute explicitly controls the order in which CloudFormation creates resources when implicit dependency detection is insufficient — for example, ensuring a database is fully available before creating the application server that connects to it.

5. CI/CD & CodePipeline

AWS provides a suite of fully managed developer tools that together form a complete CI/CD pipeline. CodeCommit is a secure, scalable Git repository hosting service — a private alternative to GitHub or Bitbucket, integrated with IAM for access control and supporting all standard Git workflows. CodeBuild is a fully managed build service that compiles source code, runs unit and integration tests, produces deployable artifacts, and publishes build reports. It scales automatically with your build load (no build servers to manage), and each build runs in a fresh, isolated Docker container. Build instructions are defined in a buildspec.yml file at the root of your repository, specifying install commands, build commands, and artifacts to export.

CodeDeploy automates application deployments to EC2 instances, on-premises servers, Lambda functions, and ECS services. For EC2 deployments, CodeDeploy supports two deployment types. In-place (rolling) deployments stop the application on existing instances, deploy the new version, and restart — instances are unavailable during deployment. Blue/Green deployments provision a new set of instances (“green”) with the new application version, shift traffic to them (via ELB), and then terminate the old instances (“blue”) — this enables instant rollback by shifting traffic back to the old instances if issues are detected. The AppSpec file (appspec.yml) defines the deployment lifecycle events and the hook scripts to run at each stage (BeforeInstall, AfterInstall, ApplicationStart, ValidateService). For Lambda deployments, AppSpec specifies the function version and traffic-shifting configuration.

CodePipeline orchestrates the full CI/CD workflow by connecting source, build, test, and deploy stages into an automated pipeline. Each stage consists of one or more actions (source provider, CodeBuild project, CodeDeploy deployment group, manual approval, etc.), and the pipeline triggers automatically when a change is pushed to the source repository. Manual approval actions pause pipeline execution and wait for an authorized IAM user to approve before proceeding — commonly used before production deployments. CodePipeline integrates with third-party tools: GitHub and Bitbucket as source providers, Jenkins as a build provider, and many others. A complete pipeline typically looks like: CodeCommit (source) → CodeBuild (build + test) → Manual Approval → CodeDeploy (deploy to staging) → Manual Approval → CodeDeploy (deploy to production).

6. Elastic Beanstalk

AWS Elastic Beanstalk is a Platform-as-a-Service (PaaS) that abstracts away infrastructure management. You upload your application code (as a ZIP file or WAR file) and specify the platform (Node.js, Python, Java, Ruby, PHP, .NET, Go, or Docker), and Beanstalk automatically provisions the EC2 instances, load balancer, Auto Scaling group, security groups, and monitoring — all using CloudFormation under the hood. You retain access to the underlying EC2 instances for debugging and customization, and you can configure environment settings through the console, CLI, or configuration files. Beanstalk is ideal for developers who want to deploy quickly without becoming AWS infrastructure experts.

Elastic Beanstalk supports five deployment policies with different trade-offs between deployment speed, capacity impact, and downtime risk. All at once is the fastest option: Beanstalk deploys the new version to all instances simultaneously. The entire environment is briefly unavailable during deployment, making it unsuitable for production but fast for development environments. Rolling deploys the new version to a batch of instances at a time, keeping most instances available, but the environment runs at reduced capacity during deployment. Rolling with additional batch maintains full capacity by launching new instances with the new version before taking old ones out of service. Immutable creates an entirely new set of instances in a new Auto Scaling group with the new version, then swaps them in — zero downtime and easy rollback by terminating the new Auto Scaling group. Traffic splitting (Canary testing) routes a configurable percentage of traffic to new instances, gradually increasing it while monitoring metrics before completing the deployment.

The .ebextensions folder is a powerful mechanism for customizing your Elastic Beanstalk environment beyond what the console exposes. You place YAML or JSON configuration files (with a .config extension) in the .ebextensions directory at the root of your application source bundle. These files can install additional software packages, configure environment variables, create files and directories, run shell commands during deployment, modify Elastic Beanstalk platform settings, and define additional AWS resources (like SQS queues or DynamoDB tables) that Beanstalk will manage alongside your environment. The .ebextensions approach allows you to version-control your environment configuration alongside your application code, ensuring that your application and its infrastructure configuration are always deployed together.

7. Monitoring & Logging

Amazon CloudWatch is the unified monitoring and observability platform for AWS. CloudWatch Alarms evaluate metrics against defined thresholds over a specified evaluation period and take action when the threshold is breached — triggering Auto Scaling policies to add or remove instances, sending SNS notifications to alert operations teams, or taking direct EC2 actions (stop, terminate, reboot, recover). Composite Alarms combine multiple individual alarms using Boolean logic (AND/OR) to create higher-level alarms that reduce alert noise — for example, “alert only if CPU is above 90% AND error rate is above 5%”, avoiding false alarms when only one metric is elevated.

AWS X-Ray is a distributed tracing service that helps you analyze and debug production, distributed applications built with microservices. X-Ray collects data about the requests that your application serves and provides tools to view, filter, and understand the entire request flow from entry point through every downstream service call. X-Ray generates a service map showing all services your application calls, the latency between them, and any errors. Trace data is collected by the X-Ray SDK (instrumented in your application code) and the X-Ray daemon (a background process that buffers and transmits trace data). For Lambda functions, X-Ray tracing is enabled with a single checkbox in the function configuration. X-Ray is particularly valuable for identifying performance bottlenecks (which service is adding latency), error sources (which downstream call is failing), and latency outliers (which requests are slow and why).

AWS CloudTrail provides a complete audit log of every API call made in your AWS account — who made the call, from which IP address, using which credentials, at what time, and what parameters were passed. CloudTrail is the answer to “who changed what in my AWS account?” questions. It covers console actions, CLI commands, SDK calls, and automated service actions. CloudTrail events are delivered to S3 within approximately 15 minutes and can be streamed to CloudWatch Logs for real-time alerting on specific API activity (for example, alerting when someone calls DeleteSecurityGroup or PutBucketPolicy). VPC Flow Logs complement CloudTrail at the network layer — they capture packet-level metadata (source IP, destination IP, port, protocol, bytes, and accept/reject status) for all traffic flowing through your VPC, providing network forensics capabilities that CloudTrail (which only captures AWS API calls) cannot provide.

8. Auto Scaling & High Availability

Auto Scaling Groups maintain a fleet of EC2 instances by automatically replacing unhealthy instances and adjusting capacity to match demand. Launch Templates are the modern, recommended way to define instance configuration for an ASG — they support versioning, allow you to mix instance types and purchase options (On-Demand + Spot), and expose all current EC2 features. Launch Configurations are the older mechanism that only support a single instance type and lack versioning. AWS recommends migrating all ASGs from Launch Configurations to Launch Templates. Auto Scaling supports four scaling policy types: Target Tracking (maintain a specific metric value, like 50% CPU — AWS automatically manages alarms and actions); Step Scaling (define multiple scaling steps based on alarm thresholds — large breach triggers large scale-out); Simple Scaling (a single scaling action triggered by a single alarm, with a cooldown period); and Scheduled Scaling (scale based on predictable, time-based patterns like scaling up at 8 AM and down at 6 PM for business hours workloads).

The cooldown period is a configurable pause after a scaling activity during which Auto Scaling suspends further scaling actions. This prevents Auto Scaling from reacting to short-lived metric spikes that are already stabilizing — for example, launching 5 new instances and then immediately launching 5 more because the new instances have not yet started handling traffic. The default cooldown is 300 seconds. Target Tracking policies have built-in warm-up periods and do not use the cooldown period the same way — they are designed to react more intelligently to metric trends. Instance warm-up defines how long a new instance takes to contribute to CloudWatch metrics after launch, preventing Auto Scaling from treating a just-launched instance that has not yet received traffic as evidence that scaling should continue.

Load balancers are the entry point for distributing traffic across multiple targets. The Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and makes routing decisions based on URL path, hostname, HTTP headers, query parameters, and source IP. Path-based routing (/api/* → API servers, /static/* → S3 origin) and host-based routing (api.example.com → API servers, www.example.com → web servers) make the ALB ideal for microservices architectures where multiple services share a single load balancer. The Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP) and is designed for extreme performance — it handles millions of requests per second with sub-millisecond latency and supports static Elastic IP addresses per AZ, which is required when clients need to whitelist a fixed IP. Connection draining (also called deregistration delay) allows in-flight requests to complete on instances being deregistered from a load balancer — the default is 300 seconds, during which the load balancer stops sending new requests to the deregistering instance but allows existing connections to finish. Sticky sessions (session affinity) bind a user’s requests to a specific target using a load balancer-generated cookie, useful for applications that store session state locally — though the recommended pattern is to externalize session state to DynamoDB or ElastiCache instead.

---

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.