Multiple-choice
Question type with one correct answer.
Getting Started: Exam Overview
Free knowledge base
Everything from the course in one searchable place: 212 entries. Use it to review before a practice test or look up a word you forgot.
212 results
Question type with one correct answer.
Getting Started: Exam Overview
Question type with two or more correct answers.
Getting Started: Exam Overview
Experimental questions not counting towards final score.
Getting Started: Exam Overview
Minimum score required to pass the exam (750).
Getting Started: Exam Overview
Extra time granted for specific needs (e.g., ESL).
Getting Started: Exam Overview
Pearson VUE's online proctoring service.
Getting Started: Exam Overview
Categories of topics covered on the exam.
Getting Started: Exam Overview
To remember the exam structure: '65 Questions, 50 Scored, 130 Minutes, 750 Passed!' (Q-S-M-P).
Getting Started: Exam Overview
The DVA-C02 exam has 65 questions, but only 50 are scored. The passing score is 750 out of 1000. Remember the 130-minute time limit.
Getting Started: Exam Overview
Not reading questions carefully to distinguish between single-choice and multiple-response questions.
Getting Started: Exam Overview
Spending too much time on a single difficult question and running out of time for easier ones.
Getting Started: Exam Overview
Not requesting accommodations (like extra time for non-native English speakers) in advance.
Getting Started: Exam Overview
Official AWS document outlining exam domains and topics.
Getting Started: Exam Overview
Engaging with material through practice, building, and explaining.
Getting Started: Exam Overview
Absorbing information without direct engagement, e.g., reading.
Getting Started: Exam Overview
Limited free usage of AWS services for new accounts.
Getting Started: Exam Overview
Official, comprehensive information on all AWS services.
Getting Started: Exam Overview
A structured schedule for learning and practicing exam topics.
Getting Started: Exam Overview
Detailed AWS technical papers on specific topics or best practices.
Getting Started: Exam Overview
To remember the study cycle: U.A.H.R.A. - 'Understand, Actively learn, Hands-on, Review, Adjust.'
Getting Started: Exam Overview
The DVA-C02 exam expects you to understand not just what a service does, but when and how to use it effectively. Pay close attention to scenario-based questions that describe a problem and ask for the best AWS solution. Keywords like 'least operational overhead,' 'most cost-effective,' or 'highly available' are crucial.
Getting Started: Exam Overview
Only memorizing facts without understanding how services interact or when to use them.
Getting Started: Exam Overview
Neglecting hands-on practice, which is crucial for scenario-based questions.
Getting Started: Exam Overview
Not using official AWS documentation as the primary source of truth.
Getting Started: Exam Overview
Cramming at the last minute instead of consistent, spaced repetition.
Getting Started: Exam Overview
Software Development Kit for interacting with AWS services programmatically.
Developing with AWS Services
AWS identity with specific permissions, assumed by AWS services/resources.
Developing with AWS Services
Information (e.g., access keys) used to authenticate with AWS.
Developing with AWS Services
An API call that blocks execution until a response is received.
Developing with AWS Services
An API call that doesn't block, allowing continued processing.
Developing with AWS Services
A retry strategy that increases wait time between retries after failures.
Developing with AWS Services
A queue for messages that could not be processed successfully.
Developing with AWS Services
SDK for Software, Roles for Rights, Sync for Same-time, Async for After-time.
Developing with AWS Services
The exam often tests your understanding of secure credential management. Always prioritize IAM roles for AWS resources over hardcoding access keys in application code.
Developing with AWS Services
Hardcoding AWS access keys directly into application code or committing them to version control.
Developing with AWS Services
Not implementing proper error handling and retry logic for AWS service calls, leading to brittle applications.
Developing with AWS Services
Using synchronous calls for long-running or non-critical tasks, impacting application responsiveness and scalability.
Developing with AWS Services
Application Programming Interface; rules for how software components interact.
Developing with AWS Services
Software Development Kit; language-specific libraries simplifying AWS API interaction.
Developing with AWS Services
Command Line Interface; unified tool for managing AWS services via terminal.
Developing with AWS Services
The AWS SDK for Python, widely used for scripting and applications.
Developing with AWS Services
API using HTTP methods and standard data formats like JSON/XML.
Developing with AWS Services
SDKs are like 'Super Developers Kits' – they give you all the tools to build easily. CLI is for 'Command Line Interactions' – quick and direct.
Developing with AWS Services
The exam often tests your understanding of when to use an SDK versus the CLI. Remember that SDKs are for integrating AWS into application code, while the CLI is for scripting and interactive management. Also, be aware of best practices for credential management, especially IAM Roles for EC2/Lambda.
Developing with AWS Services
Hardcoding AWS access keys directly into application code instead of using IAM roles or environment variables.
Developing with AWS Services
Attempting to parse raw API responses and handle low-level HTTP details when an SDK is available and would simplify the task.
Developing with AWS Services
Using the AWS CLI for deep application integration instead of an SDK, leading to less maintainability and error handling.
Developing with AWS Services
Cloud execution model where providers manage servers, developers focus on code.
Developing with AWS Services
Runs code without provisioning or managing servers; event-driven compute.
Developing with AWS Services
Fully managed service to create, publish, maintain, monitor, and secure APIs.
Developing with AWS Services
Orchestrates complex workflows with visual state machines for distributed apps.
Developing with AWS Services
System design where components communicate by producing and consuming events.
Developing with AWS Services
Initial latency when a serverless function is invoked after a period of inactivity.
Developing with AWS Services
Number of simultaneous executions of a serverless function at any given time.
Developing with AWS Services
L.A.S.T. for Serverless: Lambda for code, API Gateway for access, Step Functions for orchestration, Triggers for events.
Developing with AWS Services
The exam frequently tests your understanding of when to use Lambda versus other compute options (EC2, ECS) and how to integrate Lambda with other services like API Gateway, SQS, SNS, and DynamoDB. Look for keywords like 'event-driven', 'auto-scaling', 'pay-per-execution', and 'no server management'.
Developing with AWS Services
Overlooking 'cold start' implications for latency-sensitive applications, especially with infrequent invocations.
Developing with AWS Services
Not designing for idempotency when using event-driven Lambda functions, which can lead to duplicate processing if events are re-delivered.
Developing with AWS Services
Ignoring the maximum execution duration (timeout) of Lambda functions, which can lead to failures for long-running tasks.
Developing with AWS Services
Fully managed message queuing service for decoupling application components.
Developing with AWS Services
Fully managed messaging service for application-to-application and A2P communication.
Developing with AWS Services
Serverless compute service that runs code in response to events.
Developing with AWS Services
Sending a single message to multiple subscribers simultaneously.
Developing with AWS Services
A buffer that stores messages as they travel between application components.
Developing with AWS Services
Operations that do not block the main program flow, allowing parallel execution.
Developing with AWS Services
Reducing dependencies between components for greater flexibility and resilience.
Developing with AWS Services
Think 'SNS = Send N' Subscribe' for broadcasting, and 'SQS = Stored Queue System' for reliable buffering.
Developing with AWS Services
For the DVA-C02 exam, understand that SQS provides message durability and buffering for single or shared consumers, while SNS is for broadcasting messages to multiple, diverse subscribers (fan-out). Lambda can consume from both, but the invocation model (push from SNS, pull from SQS) differs.
Developing with AWS Services
Confusing SQS for fan-out: SQS is for one or a group of consumers processing messages from a queue, not for broadcasting to many distinct endpoints.
Developing with AWS Services
Not considering dead-letter queues (DLQs): For both SQS and Lambda (when processing SQS), DLQs are crucial for handling messages that fail processing, preventing data loss.
Developing with AWS Services
Underestimating message batching: Lambda processes SQS messages in batches. Your function code needs to handle multiple messages per invocation, not just one.
Developing with AWS Services
Verifying the identity of a user or service.
Security Best Practices for Developers
Determining what an authenticated user can do.
Security Best Practices for Developers
Service managing and verifying user identities.
Security Best Practices for Developers
Authorization framework for delegated access.
Security Best Practices for Developers
Identity layer built on top of OAuth 2.0.
Security Best Practices for Developers
Service for securely storing and rotating secrets.
Security Best Practices for Developers
Secure storage for configuration data and secrets.
Security Best Practices for Developers
AuthN (Authentication) is 'N' for Name (who you are). AuthZ (Authorization) is 'Z' for Zealous (what you can zealously do).
Security Best Practices for Developers
The exam frequently tests the distinction between authentication and authorization. Remember that authentication is 'who you are' and authorization is 'what you can do'. Also, know the purpose of AWS Secrets Manager and Parameter Store for credential management.
Security Best Practices for Developers
Confusing authentication with authorization, or using the terms interchangeably.
Security Best Practices for Developers
Hardcoding sensitive credentials directly into application code or configuration files.
Security Best Practices for Developers
Not understanding the difference between OAuth 2.0 (authorization) and OpenID Connect (authentication).
Security Best Practices for Developers
Short-lived security credentials (keys + token) provided by AWS when assuming a role.
Security Best Practices for Developers
A service on EC2 instances providing data about the instance, including temporary role credentials.
Security Best Practices for Developers
Granting only the minimum necessary permissions for a user or application to perform its task.
Security Best Practices for Developers
A policy attached to an IAM role that defines which entities are allowed to assume that role.
Security Best Practices for Developers
A unique identifier for an access key, part of the credentials.
Security Best Practices for Developers
The secret portion of an access key, used for cryptographic signing.
Security Best Practices for Developers
Remember 'R' for Role and 'R' for Resource Access. Roles are the best way for your Resources (like EC2 instances or Lambda functions) to get permissions.
Security Best Practices for Developers
The exam frequently tests the distinction between IAM users and roles. Remember: roles for applications/services (temporary credentials), users for humans (long-lived credentials). Know that EC2 instances retrieve role credentials from the instance metadata service.
Security Best Practices for Developers
Hardcoding AWS access keys directly into application code or configuration files.
Security Best Practices for Developers
Granting overly broad permissions (e.g., using '*' for all actions or resources) to application roles.
Security Best Practices for Developers
Confusing IAM users (for humans) with IAM roles (for applications/services) when designing access.
Security Best Practices for Developers
Not rotating credentials for IAM users that are used programmatically (though roles are preferred).
Security Best Practices for Developers
Encrypting data when it is stored on persistent storage.
Security Best Practices for Developers
Encrypting data as it moves between different locations.
Security Best Practices for Developers
Cryptographic protocol for secure communication over networks.
Security Best Practices for Developers
Managed service to create and control encryption keys.
Security Best Practices for Developers
Primary key in KMS used to encrypt/decrypt data keys.
Security Best Practices for Developers
Encrypting data with a data key, then encrypting the data key itself.
Security Best Practices for Developers
Server-Side Encryption using AWS KMS managed keys for S3.
Security Best Practices for Developers
R.I.P. D.A.T.A. - **R**est is **I**n **P**lace, **D**ata **A**lways **T**ravels **A**cross. Remember 'Rest' means stored, 'Transit' means moving.
Security Best Practices for Developers
The exam frequently tests your understanding of which AWS services support encryption at rest vs. in transit, and how KMS integrates with them. Pay close attention to the different S3 encryption options (SSE-S3, SSE-KMS, SSE-C) and when to use each.
Security Best Practices for Developers
Forgetting to enable encryption for new resources, assuming it's always on by default.
Security Best Practices for Developers
Not understanding the difference between AWS-managed keys and customer-managed keys in KMS, leading to improper key management.
Security Best Practices for Developers
Using HTTP instead of HTTPS for API calls or web traffic, leaving data vulnerable during transit.
Security Best Practices for Developers
Web Application Firewall protecting against common web exploits.
Security Best Practices for Developers
Attack inserting malicious SQL code into input fields.
Security Best Practices for Developers
Attack injecting client-side scripts into web pages.
Security Best Practices for Developers
List of the most critical web application security risks.
Security Best Practices for Developers
API Gateway feature using a Lambda function for custom authorization.
Security Best Practices for Developers
Controlling the rate of requests to prevent service overload.
Security Best Practices for Developers
Secure version of HTTP, encrypting communication.
Security Best Practices for Developers
WAF protects your Web Apps from Attacks and Flaws. Think of a 'WAFFLE' that blocks bad ingredients from getting into your delicious app!
Security Best Practices for Developers
For the DVA-C02 exam, remember that AWS WAF integrates with CloudFront, ALB, API Gateway, and AppSync. Be prepared to identify which service protects against which type of attack (e.g., WAF for SQL injection, Shield for DDoS).
Security Best Practices for Developers
Forgetting to enable logging for WAF or API Gateway, hindering incident response.
Security Best Practices for Developers
Relying solely on client-side input validation, which can be easily bypassed.
Security Best Practices for Developers
Not using HTTPS for all communication, leaving data vulnerable in transit.
Security Best Practices for Developers
Packaging an application and its dependencies into a portable unit.
Deployment Strategies on AWS
Modifying application code to improve structure or use cloud-native services.
Deployment Strategies on AWS
Migrating an application to the cloud without significant changes.
Deployment Strategies on AWS
AWS identity that grants temporary permissions to AWS services and resources.
Deployment Strategies on AWS
Architectural style where applications are built as a collection of small services.
Deployment Strategies on AWS
To remember configuration services: 'Parameters' are for everyday settings, 'Secrets' are for things you absolutely must keep hidden, like your diary.
Deployment Strategies on AWS
The exam often tests your understanding of best practices for managing secrets and configurations. Memorize that AWS Secrets Manager is for sensitive data like credentials, while AWS Systems Manager Parameter Store is for general configuration parameters. Both are secure, but their primary use cases differ.
Deployment Strategies on AWS
Hardcoding credentials directly into application code or configuration files.
Deployment Strategies on AWS
Not containerizing applications when deploying to services like ECS or EKS, leading to inconsistent environments.
Deployment Strategies on AWS
Failing to externalize configuration, making it difficult to manage different environments (dev, staging, prod).
Deployment Strategies on AWS
PaaS for deploying and scaling web apps with automatic infrastructure provisioning.
Deployment Strategies on AWS
Container orchestration service for running Docker containers at scale.
Deployment Strategies on AWS
Serverless compute engine for containers, removing the need to manage EC2 instances.
Deployment Strategies on AWS
Blueprint specifying Docker image, resources, and parameters for one or more containers in ECS.
Deployment Strategies on AWS
Maintains a desired number of tasks, ensuring application availability and scalability.
Deployment Strategies on AWS
An EC2 instance that is part of an ECS cluster and runs Docker containers.
Deployment Strategies on AWS
A collection of AWS resources running your application in Elastic Beanstalk.
Deployment Strategies on AWS
EB for 'Easy Button' (Elastic Beanstalk) and ECS for 'Container Scale' (Elastic Container Service).
Deployment Strategies on AWS
The exam often tests your understanding of when to use Elastic Beanstalk versus ECS. Look for keywords like 'rapid deployment,' 'minimal ops,' or 'traditional web app' for Beanstalk. For ECS, keywords like 'microservices,' 'Docker containers,' 'fine-grained control,' or 'custom orchestration' are common.
Deployment Strategies on AWS
Confusing Elastic Beanstalk's managed platform with ECS's container orchestration. Beanstalk is higher-level abstraction.
Deployment Strategies on AWS
Using ECS for a simple web app when Elastic Beanstalk would be much simpler and quicker to deploy.
Deployment Strategies on AWS
Not understanding the difference between EC2 launch type and Fargate launch type in ECS; Fargate removes server management.
Deployment Strategies on AWS
AWS service for orchestrating CI/CD workflows.
Deployment Strategies on AWS
Automates application deployments to various compute services.
Deployment Strategies on AWS
YAML file defining deployment actions for CodeDeploy.
Deployment Strategies on AWS
Updates application on existing instances, potential downtime.
Deployment Strategies on AWS
Deploys to new environment, then shifts traffic, zero downtime.
Deployment Strategies on AWS
Set of instances or Lambda functions targeted by CodeDeploy.
Deployment Strategies on AWS
Software on target instances for CodeDeploy communication.
Deployment Strategies on AWS
Specific version of application code and AppSpec file.
Deployment Strategies on AWS
Pipes DEPLOY code. CodePipeline orchestrates the entire Pipelined process, and CodeDeploy handles the actual DEPLOYment.
Deployment Strategies on AWS
For the DVA-C02 exam, understand that CodePipeline orchestrates the entire CI/CD process, while CodeDeploy specifically handles the deployment action. Memorize the difference between in-place (updates existing, downtime risk) and blue/green (new environment, zero downtime) deployment strategies for CodeDeploy.
Deployment Strategies on AWS
Forgetting to install or properly configure the CodeDeploy agent on target EC2 instances.
Deployment Strategies on AWS
Incorrectly structuring the appspec.yml file, leading to deployment failures.
Deployment Strategies on AWS
Confusing CodePipeline's role (orchestration) with CodeDeploy's role (actual deployment).
Deployment Strategies on AWS
Not configuring proper IAM permissions for CodeDeploy to access resources or for the agent to run.
Deployment Strategies on AWS
Cloud execution model where providers manage servers.
Deployment Strategies on AWS
Serverless Application Model; framework extending CloudFormation for serverless apps.
Deployment Strategies on AWS
Command Line Interface for developing and deploying SAM applications.
Deployment Strategies on AWS
AWS service for provisioning and managing infrastructure as code.
Deployment Strategies on AWS
YAML/JSON file defining serverless application resources for SAM.
Deployment Strategies on AWS
SAM is like a 'Simplified Architect's Manual' for building serverless apps, letting CloudFormation do the heavy lifting.
Deployment Strategies on AWS
The exam often tests your understanding of how SAM simplifies CloudFormation for serverless deployments. Look for keywords like 'serverless application definition', 'shorthand syntax', and 'CloudFormation stack' when discussing SAM.
Deployment Strategies on AWS
Forgetting that SAM templates are ultimately transformed into CloudFormation templates.
Deployment Strategies on AWS
Trying to manage serverless resources directly with CloudFormation when SAM offers a simpler alternative.
Deployment Strategies on AWS
Not understanding the difference between `sam build` (compiles code) and `sam deploy` (deploys to AWS).
Deployment Strategies on AWS
AWS monitoring and observability service for applications and resources.
Monitoring and Troubleshooting AWS Apps
Time-ordered data points representing a variable to monitor.
Monitoring and Troubleshooting AWS Apps
Event records from applications and services, centralized for analysis.
Monitoring and Troubleshooting AWS Apps
Collection of log streams sharing settings like retention and access.
Monitoring and Troubleshooting AWS Apps
Sequence of log events from a single source within a log group.
Monitoring and Troubleshooting AWS Apps
Monitors metrics and triggers actions when thresholds are breached.
Monitoring and Troubleshooting AWS Apps
Customizable visual displays of metrics and logs for monitoring.
Monitoring and Troubleshooting AWS Apps
Remember 'MLAD': Metrics, Logs, Alarms, Dashboards – the core components of CloudWatch that help you Monitor, Learn, Act, and Display.
Monitoring and Troubleshooting AWS Apps
The exam often tests your understanding of the different components of CloudWatch: Metrics for performance data, Logs for detailed event data, and Alarms for automated responses. Look for keywords like 'performance data', 'resource utilization' (metrics), 'troubleshooting application errors', 'centralized log storage' (logs), and 'automated notifications' or 'scaling actions' (alarms).
Monitoring and Troubleshooting AWS Apps
Confusing CloudWatch Logs with S3 for long-term archival; CloudWatch Logs is for operational monitoring and analysis, S3 for archival.
Monitoring and Troubleshooting AWS Apps
Not understanding the difference between a CloudWatch Metric (a number) and a CloudWatch Log (a text event).
Monitoring and Troubleshooting AWS Apps
Failing to set appropriate alarm thresholds, leading to either alarm fatigue (too many false positives) or missed critical events.
Monitoring and Troubleshooting AWS Apps
A powerful query language for analyzing log data.
Monitoring and Troubleshooting AWS Apps
Service for tracing requests through distributed applications.
Monitoring and Troubleshooting AWS Apps
AI service for code reviews and performance profiling.
Monitoring and Troubleshooting AWS Apps
When an application lacks sufficient compute resources.
Monitoring and Troubleshooting AWS Apps
An issue with an external service or component.
Monitoring and Troubleshooting AWS Apps
Reverting to a previous, stable version of an application.
Monitoring and Troubleshooting AWS Apps
Application-specific data published to CloudWatch.
Monitoring and Troubleshooting AWS Apps
To fix app issues, remember the 'L.A.S.T.' strategy: Logs (CloudWatch Logs), Alarms (CloudWatch Alarms), X-ray (AWS X-Ray), and Trace (CodeGuru Trace/Profiler).
Monitoring and Troubleshooting AWS Apps
The exam often tests your ability to choose the correct AWS service for a given troubleshooting scenario. Keywords like 'distributed tracing' point to X-Ray, 'code quality' or 'performance bottlenecks in code' point to CodeGuru, and 'log analysis' or 'metric alarms' point to CloudWatch.
Monitoring and Troubleshooting AWS Apps
Not checking CloudWatch Logs first for error messages or exceptions.
Monitoring and Troubleshooting AWS Apps
Jumping to conclusions without systematically gathering data or isolating the problem.
Monitoring and Troubleshooting AWS Apps
Neglecting to consider recent changes (code deployments, configuration updates) as the primary cause.
Monitoring and Troubleshooting AWS Apps
Public page showing global AWS service status.
Monitoring and Troubleshooting AWS Apps
Personalized health info for your AWS accounts.
Monitoring and Troubleshooting AWS Apps
Operates within a specific AWS region.
Monitoring and Troubleshooting AWS Apps
Operates across all AWS regions (e.g., IAM).
Monitoring and Troubleshooting AWS Apps
Isolated location within an AWS region.
Monitoring and Troubleshooting AWS Apps
Period when a service is unavailable.
Monitoring and Troubleshooting AWS Apps
Process for responding to and resolving service issues.
Monitoring and Troubleshooting AWS Apps
Think 'Public Status' for Service Health Dashboard (SHD) and 'Personalized Health' for AWS Health Dashboard (AHD). SHD is like a public news channel; AHD is like your doctor's report.
Monitoring and Troubleshooting AWS Apps
The exam expects you to know the difference between the AWS Service Health Dashboard (public, global view) and the AWS Health Dashboard (personalized, account-specific view). You should also understand that IAM, Route 53, and CloudFront are global services.
Monitoring and Troubleshooting AWS Apps
Mistaking an AWS service issue for an application bug and wasting time debugging your code.
Monitoring and Troubleshooting AWS Apps
Not checking the AWS Health Dashboards early enough when an issue arises.
Monitoring and Troubleshooting AWS Apps
Making reactive, uncoordinated changes to your infrastructure during an AWS outage, potentially worsening the problem.
Monitoring and Troubleshooting AWS Apps
Time delay before a transfer of data begins.
Monitoring and Troubleshooting AWS Apps
Rate at which data is processed or transferred.
Monitoring and Troubleshooting AWS Apps
Matching compute resources to workload needs.
Monitoring and Troubleshooting AWS Apps
Storing copies of data for faster access.
Monitoring and Troubleshooting AWS Apps
Monitors endpoints and APIs using canaries.
Monitoring and Troubleshooting AWS Apps
A global Content Delivery Network (CDN).
Monitoring and Troubleshooting AWS Apps
P-O-W-E-R: Performance Optimization With Every Resource. Think about optimizing every resource you use.
Monitoring and Troubleshooting AWS Apps
The exam often tests your knowledge of which AWS service to use for specific monitoring or optimization tasks. Memorize the primary function of CloudWatch (metrics, logs, alarms), X-Ray (distributed tracing), CloudFront (CDN), and ElastiCache (caching).
Monitoring and Troubleshooting AWS Apps
Ignoring custom application metrics: Relying only on default AWS service metrics might miss critical insights into your application's internal health.
Monitoring and Troubleshooting AWS Apps
Not setting up alarms: Monitoring without alarms means you'll only find out about issues after they've impacted users, rather than proactively.
Monitoring and Troubleshooting AWS Apps
Over-optimizing prematurely: Focus on identifying actual bottlenecks before investing heavily in optimization, using data from monitoring tools.
Monitoring and Troubleshooting AWS Apps