Everything the adaptive question bank can teach and test in AWS Cloud, from foundations through advanced practice. Work through it in order, or start practising and let the questions find your level.
a Region is a self-contained geographic failure domain; nothing replicates across Regions unless you configure it
•
an AZ is one or more discrete data centers with independent power and cooling, joined to sibling AZs by low-latency private fiber
•
spreading across AZs survives a data-center loss; only a multi-Region design survives losing a whole Region
•
us-east-1a maps to different physical hardware in different accounts, so AZ IDs, not AZ names, are what you compare
•
IAM, Route 53, CloudFront and Organizations are global; nearly everything else is scoped to one Region and invisible from another
•
edge locations cache content and terminate connections near users; they are points of presence, not Regions you can launch instances in
B. Accounts, Organizations and shared responsibility
•
AWS secures the cloud itself (facilities, hardware, hypervisor, managed-service internals); you secure what you put in it
•
on EC2 you patch the guest OS; on a managed database AWS does — but data classification, encryption choice and access control are always yours
•
the account is the hard isolation boundary, which is why prod and dev get separate accounts rather than separate tags
•
the root user cannot be restricted by any IAM policy, so it gets MFA, no access keys, and no day-to-day use
•
accounts nest into organizational units so one policy attached high in the tree governs everything beneath it
•
a service control policy sets the ceiling on what an account may do; it never grants a permission, so an IAM Allow is still required
C. IAM identities: users, groups and roles
•
a user is a long-lived identity holding static credentials; a role has no credentials of its own and hands out temporary ones when assumed
•
a group attaches policies to a set of users; it is not a principal, so nothing can assume a group or name one in a trust policy
•
the trust policy answers *who may assume this role*; the attached permissions policy answers *what they can do once they have*
•
an EC2 instance receives a role through an instance profile, which is how an application gets credentials without a key ever being written to disk
•
an identity policy hangs off a principal and needs no Principal element; a resource policy hangs off the object and must name one
•
cross-account access is a role in the target account whose trust policy names the source account, not a copied set of access keys
D. Policy language and the evaluation logic
•
with no statement matching the request the answer is deny; permissions are strictly additive on top of that baseline
•
one explicit Deny anywhere in the evaluation — identity policy, resource policy, boundary or SCP — overrides every Allow
•
Effect, Action, Resource, Principal and Condition, and the rule that Principal belongs in a resource policy and not an identity policy
•
* and ? match within an ARN, and "Resource": "*" is the over-grant that turns a scoped role into an administrator
•
a Condition gates the statement on request context such as source IP, MFA presence, requested Region, resource tag or encryption header
•
a boundary caps what an identity's own policies can grant, so effective permission is the intersection of the two, never the union
•
a cross-account request must be allowed in both accounts; the resource policy alone is not enough when the caller is in another account
E. Temporary credentials and STS
•
AssumeRole hands back an access key, a secret and a session token, and all three must be sent or the call is unsigned
•
session credentials die at a duration you choose, which is the whole point: there is no long-lived secret to rotate or leak
•
a policy passed at assume time can only subtract from the role's permissions; it can never add one the role does not already have
•
a third party assuming your role must present an agreed ExternalId, so another of their customers cannot trick them into using your role
•
role credentials arrive from the instance metadata service and rotate on their own; IMDSv2 requires a session token first, which is what defeats SSRF
F. VPC fundamentals: addressing and routing
•
a VPC's primary CIDR is chosen at creation and cannot shrink, so overlapping ranges are the mistake that blocks a future peering
•
a subnet never spans AZs, which is why an AZ-resilient design needs one subnet per AZ behind the same load balancer
•
AWS reserves five addresses in every subnet, so a /28 yields eleven usable hosts, not sixteen
•
a subnet is "public" only because its route table sends 0.0.0.0/0 to an internet gateway; nothing else marks it
•
a NAT gateway lets private instances reach out and accepts no inbound connections, and it must itself sit in a public subnet
•
the most specific matching route wins, and the implicit local route covering the VPC CIDR cannot be overridden or removed
G. VPC security controls and connectivity
•
the reply to an allowed inbound flow is permitted automatically, no matter what the outbound rules say
•
a network ACL judges each direction independently, so return traffic needs its own rule covering the ephemeral port range
•
security groups have no deny rule; you block something by not allowing it, which is why a NACL is the tool for an explicit block
•
NACL rules are evaluated in ascending rule number and the first match decides, so a later, more specific rule never gets read
•
naming another security group as the source lets "the web tier may reach the database tier" survive every IP change
•
a gateway or interface endpoint reaches S3, DynamoDB or a service API over the AWS network, with no internet gateway, NAT or public IP involved
•
a VPC peering connection carries no transitive routes, which is exactly why a hub-and-spoke topology uses Transit Gateway
H. EC2: instances, images and purchase models
•
pending, running, stopping, stopped and terminated, and the fact that terminated is the one state you cannot come back from
•
stopping preserves the instance ID and its EBS root volume; terminating releases both and, by default, deletes that root volume
•
instance-store data is gone on stop or host failure; only EBS survives the instance, which is why databases never sit on it
•
an AMI pins the OS, packages and volume layout and exists in one Region until you copy it, which is what a cross-Region DR plan must include
•
user data executes on first boot by default, so it is a bootstrap mechanism, not a configuration-management system
•
On-Demand for unpredictable work, Savings Plans or Reserved commitments for a steady baseline, Spot for anything that tolerates interruption
•
Spot capacity is reclaimed on short notice, so a Spot workload checkpoints its progress and drains rather than assuming it will finish
I. Load balancing and auto scaling
•
the group holds desired capacity between the min and max and replaces any instance that fails its health check
•
an ASG can trust the EC2 status check or the load balancer's check; only the second notices an instance that boots fine but serves errors
•
target tracking holds one metric at a set point with no thresholds to tune; step scaling reacts in graded jumps off an alarm
•
the Application Load Balancer routes at layer 7 on host, path or header; the Network Load Balancer forwards at layer 4 and preserves the source IP
•
connection draining holds a target in service until in-flight requests finish, which is what makes a scale-in invisible to users
•
adding instances is elastic and needs no downtime; resizing one instance is vertical, capped by the largest size, and requires a restart
J. Lambda and the serverless execution model
•
an execution environment handles exactly one event at a time, so concurrency means more environments, never threads inside one
•
the first request into a new environment pays initialization cost; provisioned concurrency pre-initializes environments to remove it
•
code outside the handler runs once per environment, so connection pools and SDK clients belong there and per-request state must not
•
reserved concurrency partitions the account limit and caps a function; provisioned concurrency keeps environments warm
•
a synchronous caller sees the error immediately; an asynchronous invoke returns accepted, retries out of band, then routes to a DLQ
•
memory also allocates CPU, so raising memory often lowers total cost by finishing sooner rather than raising it
K. Containers: ECS, EKS and Fargate
•
a task definition pins image, CPU, memory, ports and roles; a task is one running instantiation of that revision
•
Fargate removes host patching and capacity planning and bills per task; the EC2 launch type keeps host control and bin-packing
•
ECS is the AWS-native scheduler with the least operational surface; EKS runs conformant Kubernetes for portability and ecosystem, at more overhead
•
the task role gives the application its AWS permissions; the execution role lets the agent pull the image and ship logs
•
an ECS service continuously reconciles running tasks toward the desired count, replacing unhealthy ones behind the load balancer
L. S3 object storage
•
S3 stores keys, not directories; the slashes in a key are just characters that the console renders as folders
•
reads are strongly consistent for writes, overwrites and deletes, so the old "wait for eventual consistency" workarounds are obsolete
•
the classes trade retrieval latency and per-request cost against storage price, and the archive tiers add a minimum storage duration charge
•
a lifecycle rule transitions or expires objects by age and prefix, which is how tiering and cleanup happen without any application code
•
deleting in a versioned bucket writes a delete marker and hides the object; the data is only gone when the version itself is deleted
•
bucket policies are the supported access mechanism; object ACLs are legacy and are disabled by default under bucket-owner-enforced ownership
•
the account- and bucket-level Block Public Access settings override any policy that would otherwise expose objects to anonymous readers
•
a presigned URL carries the signer's permissions for a bounded time, so anyone who obtains the link has that access until it expires
•
SSE-S3, SSE-KMS and SSE-C differ in who holds the key material, who is audited for its use, and who pays the per-request key charge
•
cross-Region replication is asynchronous and requires versioning on both buckets, so it is a copy, not a synchronous write
M. Block and file storage
•
a volume attaches to an instance in its own AZ only; moving data to another AZ means taking a snapshot and restoring from it
•
general-purpose SSD for most workloads, provisioned-IOPS SSD when latency is contractual, throughput-optimized HDD for large sequential reads
•
a snapshot stores only changed blocks, yet each one restores a complete volume, so deleting an older snapshot does not break a newer one
•
EFS is an elastic NFS file system many instances mount concurrently across AZs; an EBS volume is one volume attached to one instance
•
S3 for whole objects fetched over HTTP, EBS for a boot or database volume, EFS for POSIX semantics several hosts need at once
N. Relational databases: RDS and Aurora
•
the Multi-AZ standby is a synchronous replica kept for automatic failover; you cannot read from it, so it adds no read capacity
•
read replicas are asynchronous, readable and promotable, but they do not fail over automatically and may serve slightly stale rows
•
a failover repoints the DNS endpoint at the standby, so an application that caches the resolved IP stays broken after the database recovers
•
automated backups give point-in-time recovery inside a retention window and are deleted with the instance; a manual snapshot persists until you remove it
•
Aurora separates compute from a replicated storage layer shared by all replicas, which is why adding a reader copies no data and failover is fast
•
AWS patches, backs up and monitors the engine; schema design, index choice, query cost and connection limits remain entirely your problem
O. DynamoDB and caching
•
the partition key is hashed to pick a partition, so a low-cardinality key concentrates traffic and throttles one partition while the table idles
•
a composite key lets one Query return an ordered slice of items sharing a partition key, which is how a time series is read cheaply
•
a Query reads by key within one partition; a Scan reads every item in the table and should be the deliberate exception, not the default
•
a global secondary index has its own key and capacity and is eventually consistent; a local one shares the partition key and must exist from table creation
•
provisioned capacity is cheaper for predictable load and can autoscale; on-demand absorbs unpredictable spikes with no planning and no throttle tuning
•
the default eventually consistent read can return a stale item and costs half of a strongly consistent one
•
a stream emits ordered item-level change records per key, which is the hook that drives replication, aggregation and Lambda triggers
•
lazy loading fills the cache on a miss and can serve stale data; write-through keeps it fresh but pays on every write and caches unread data
P. Messaging, events and orchestration
•
a received message is hidden rather than removed; if the consumer does not delete it before the timeout, another consumer receives it again
•
nothing leaves a queue until an explicit delete, which is why a consumer that crashes mid-work loses no message
•
after the configured receive count a repeatedly failing message moves to a DLQ instead of blocking the queue and burning retries forever
•
standard queues are at-least-once with best-effort ordering and huge throughput; FIFO queues guarantee order and deduplication per message group
•
long polling waits for a message to arrive instead of returning empty immediately, cutting both request cost and spurious "queue is empty" results
•
one publish to a topic reaches every subscriber, and subscribing SQS queues gives each consumer its own durable buffered copy
•
EventBridge matches rules against the event payload itself and can target many services, which is how producers stay ignorant of consumers
•
a state machine keeps workflow state, retries, branching and waits outside your code, so a long process is not one oversized function
Q. Observability and auditing
•
a metric is identified by namespace, name and dimensions, so adding a dimension value creates a new metric rather than a new slice of an old one
•
memory and disk utilization are inside the instance and require the CloudWatch agent; the hypervisor-level metrics cannot see them
•
an alarm sits in OK, ALARM or INSUFFICIENT_DATA, and the period plus datapoints-to-alarm decide how fast and how noisily it flips
•
who called which API, how the system is performing, and whether resource configuration drifted from a rule are three different questions
•
X-Ray stitches per-service segments into one trace, so latency is attributed to a specific hop instead of inferred from separate dashboards
R. Encryption, secrets and threat detection
•
KMS encrypts a data key and the data key encrypts the data, so bulk plaintext never travels to KMS and only the small key does
•
every KMS key carries its own resource policy, and an IAM policy alone cannot grant use of a key whose key policy does not permit it
•
a customer-managed key gives you the policy, the rotation schedule, cross-account grants and deletion control; an AWS-managed key gives none of those
•
TLS protects the wire and KMS protects the disk; they are configured separately and neither one implies the other
•
Secrets Manager adds managed rotation, cross-account sharing and a per-secret charge; Parameter Store is the cheaper home for plain configuration
•
WAF inspects and filters layer-7 requests against rules you choose; Shield absorbs volumetric network-layer floods before they reach the application
•
GuardDuty analyzes logs and telemetry to raise findings about suspicious behavior; it produces evidence and blocks nothing on its own
S. Content delivery and DNS
•
a distribution answers from the nearest point of presence and only reaches the origin on a cache miss, which cuts both latency and origin load
•
whatever you include in the cache key fragments the cache, so forwarding every header, cookie and query string turns a CDN into a slow proxy
•
an invalidation is slow and metered; publishing the new object under a new path is the cheap, instant way to retire cached content
•
OAC lets only the distribution read a private S3 origin, so the bucket never needs to be public for CloudFront to serve it
•
an alias record can live at the zone apex and resolve to an AWS resource, which a CNAME cannot do at the apex
•
simple, weighted, latency, failover, geolocation and multivalue answer different questions: split traffic, pick the fastest Region, or route away from a failure
•
resolvers cache a record for its TTL, so DNS-based failover is never faster than the TTL you published before the incident
T. Infrastructure as code and deployment
•
a stack creates, updates and deletes its resources as one unit, and a failed update rolls the whole stack back rather than leaving it half-applied
•
a change set shows which resources an update will modify or *replace* before anything happens, which is where an accidental data-losing replacement is caught
•
a resource edited by hand no longer matches its template; drift detection reports the difference, and the next stack update may silently revert it
•
a stateful resource needs an explicit retain policy, or deleting the stack deletes the database and its data with it
•
CDK is a program that emits CloudFormation, so the deployed artifact, its limits and its failure modes are still CloudFormation's
U. Well-Architected design heuristics
•
operational excellence, security, reliability, performance efficiency, cost optimization and sustainability, each with its own trade-off questions
•
assume every component eventually fails; the design question is whether the system degrades gracefully or stops
•
putting a queue or load balancer between tiers lets one side scale, deploy or fail without the other noticing
•
moving session and uploaded-file state off the instance is what makes any instance able to serve any request, and makes scale-in safe
•
backup-and-restore, pilot light, warm standby and multi-site active-active trade steady-state cost against recovery time and data loss
•
the largest cloud saving comes from turning idle capacity off and right-sizing, not from buying the same idle capacity more cheaply
•
service quotas apply per account and per Region, and hitting one under load presents exactly like an outage
Keentune is not affiliated with or endorsed by the organizations whose documentation informs these maps.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.