COMP5349 — 2025 真题答案（简单英文版）

AWS Nitro is the system that runs EC2 today. It replaced the old Xen hypervisor. It moves most of the virtualization work onto special hardware. So almost all of the CPU and memory go to the customer's instance. This gives near bare-metal speed and a small attack surface.

Two key features:

• Nitro Hypervisor: a very thin and light hypervisor. It only handles CPU and memory. Everything else is moved off it, so it is fast and hard to attack.
• Nitro Cards: special hardware that takes over networking, storage and security from the main CPU.

Redundancy: S3 keeps several copies of each object in different AZs (Standard uses 3 or more). It is free and always on. It protects against hardware or AZ failure. The user does not set it up.

Versioning: you must turn it on, and it costs extra. Every change makes a new version. A delete only adds a delete marker; it does not really remove the data, so you can get old versions back. It protects against human mistakes (overwrite or delete).

Key difference: redundancy protects against hardware failure (free, automatic). Versioning protects against user mistakes by keeping old versions (paid, optional).

Multi-AZ: keeps a standby copy in another AZ. It copies data synchronously (at the same time). It is for high availability and automatic failover. If the main one fails, AWS switches to the standby automatically. The standby cannot be read.

Read Replica: copies data asynchronously (a bit later). It is for read scaling — it takes read queries off the main database. It can be read, and you can promote it to a main database. RDS allows up to 5; Aurora up to 15.

Short: Multi-AZ = HA, synchronous, not readable, auto failover. Read Replica = read scaling, asynchronous, readable, no auto failover.

Containers (ECS/EKS): the unit is a container (a Task in ECS, a Pod in EKS). A long-running service keeps a set number of copies. You manage the machines under it (or auto scale them). Good: full control, no time limit, can install anything; good for steady or long jobs. Bad: you manage images and capacity, and you pay while it runs.
Use case: a long-running API, or a video/PDF job that takes minutes and needs special libraries.

Serverless (Lambda): the unit is a function. It scales automatically per request. You manage no servers. Good: near-zero cost when idle, auto scaling, less work. Bad: 15-minute limit, limited memory, cold start, must be stateless.
Use case: a spiky, low-frequency, event task — like making a thumbnail when an image is uploaded to S3.

Only ec2:StartInstances and ec2:StopInstances. Nothing else is allowed or denied.只有 StartInstances 和 StopInstances;其它都不涉及。

Denied. 203.0.113.17 is inside 203.0.113.0/24, so the Deny matches. An explicit Deny always beats an Allow.拒绝。203.0.113.17在该网段内,Deny命中;显式Deny永远赢过Allow。

Yes. 198.51.100.10 is not in 203.0.113.0/24, so the Deny does not match. Only the Allow applies.可以。该IP不在网段内,Deny不命中,只有Allow生效。

Change the condition from IpAddress to NotIpAddress:

"Effect": "Deny",
"Action": ["ec2:StartInstances","ec2:StopInstances"],
"Resource": "*",
"Condition": {
  "NotIpAddress": { "aws:SourceIp": "198.73.100.0/24" }
}

Now the Deny hits every IP that is not in 198.73.100.0/24. So only that range can start/stop instances.

3 things: Version A, Version B, and a delete marker (added on Day 3, now the current version). The two real versions are still there.3个:Version A、Version B、一个删除标记(第3天加的,现在是当前版本);两个真实版本还在。

Yes. Delete the delete marker (delete that version by its version ID). Then Version B becomes the current version again, and a normal GET returns Version B.能。删掉那个删除标记(按它的版本ID删),Version B就重新成为当前版本,普通GET能取回B。

2 versions: Version A and Version B (both copied by replication). Version B is current. By default, delete markers are not copied, so the backup bucket has no delete marker.2个:Version A 和 Version B(复制过来),当前是B。默认删除标记不复制,所以备份桶没有删除标记。

404 Not Found. A normal GET reads the current version, which is the delete marker. So S3 returns 404. To get the file, you must give Version B's version ID.返回404。普通GET取当前版本=删除标记,所以404;要取文件必须指定Version B的版本ID。

A delete without a version ID only adds another delete marker; it does not remove data. To really delete, you must delete every version by its version ID: in project delete A, B and the delete marker; in project-backup delete A and B. (Version-by-version deletes are not copied, so you must do both buckets. You can also use a lifecycle rule to remove old versions.)

6 copies. Aurora always keeps 6 copies of each segment. This does not depend on how many readers you have.6份。Aurora对每个数据段总是存6份,和有几个读副本无关。

3 AZs, with 2 copies in each AZ (6 / 3). Using 3 AZs means it can lose one whole AZ and still keep a write quorum.3个AZ,每个AZ放2份(共6份)。跨3个AZ→丢一整个AZ仍能维持写仲裁。

Only the writer takes writes. It sends just the redo log (not full pages) to the 6 storage nodes. The write is durable once 4 of the 6 confirm (write quorum 4/6). The redo log is also sent to the 2 readers so they update their cache. Readers read from the same shared storage. The storage nodes build the pages from the log later in the background.

One protection group covers one 10 GB segment, kept as 6 copies across 3 AZs. When the volume grows past 10 GB, Aurora adds more protection groups — more storage nodes/segments, each with its own 6 copies across the 3 AZs. The volume is just a set of protection groups. The compute (writer/readers) does not change; only the storage grows.

No. The DB subnet uses the default route table, which has only the local route. There is no route to an IGW or a NAT, so it cannot reach the internet either way.不能。DB子网用默认路由表,只有local路由,没有指向IGW或NAT的路由,双向都上不了网。

User → Internet Gateway → (RT-Public sends it to the public subnet) → ALB (ALB-SG allows port 80 from anywhere) → ALB sends it to a web server in the App subnet over the local route (WebServer-SG allows 80 from ALB-SG) → if needed the web server reads RDS (RDS-SG allows 3306 from WebServer-SG). The reply goes back the same way (SGs are stateful).
Route tables: RT-Public + local route. SGs: ALB-SG → WebServer-SG → RDS-SG.

Not useful yet. You can reach the bastion (it allows 22 from anywhere and is in the public subnet). But you cannot use it to manage the web/DB servers, because no SG allows SSH from the bastion: WebServer-SG only allows 80 from ALB-SG. Fix: add TCP 22 from Bastion-SG to WebServer-SG (and 3306 from Bastion-SG to RDS-SG if you want to manage the DB).

Reason 1: the DB subnet has no 0.0.0.0/0 → IGW route, so even with a public IP there is no internet path. Reason 2: no SG rule allows port 22 from the laptop (RDS-SG only allows 3306). Either one alone blocks SSH.

Put it in the App subnet (it has a route to the NAT; the DB subnet has no internet path and cannot reach S3). Configs:

• Put the function in the VPC with the App subnet and its own Lambda-SG.
• For RDS: add RDS-SG: 3306 from Lambda-SG, and give it the DB login.
• For S3: use the NAT, or better add a free S3 Gateway VPC endpoint.
• Give the execution role S3 permissions (s3:GetObject / s3:PutObject).

Put the temp EC2 in the App subnet (it can reach RDS over the local route). The subnet is private, so connect through the bastion: SSH to the bastion, then SSH from the bastion to the temp EC2. New SG: make a new SG for the temp EC2 that allows 22 from Bastion-SG, and add that SG to RDS-SG's 3306 rule (or attach WebServer-SG, which RDS already trusts).

(a) 10.0.2.15 → App subnet. Route to NAT, so it can go out to the internet but cannot be reached from the internet.
(b) 10.0.3.10 → DB subnet. Only the local route, so no internet either way; it only talks inside the VPC.
(c) 10.0.5.55 → inside the VPC range but in NO subnet (subnets are .1/.2/.3). It cannot be given to any resource here; you would need a new subnet.

The ALB uses round-robin by default. It sends requests evenly across the healthy targets — all 3, as long as they pass the port-80 health check. Unhealthy targets get no traffic.ALB默认轮询,只发给通过80健康检查的健康目标,3台均分;不健康的不发。

New instances start, but the web server never runs on port 80. So they fail the health check and are marked unhealthy. The ASG terminates them and launches new ones from the same bad template. This makes an endless launch–terminate loop. The old healthy instances keep serving.
Observation: in the ASG history, instances are launched and terminated again and again; the target group never gets healthy new targets and capacity never settles. That loop tells you to check the startup script.

No. The ASG looks at the group average CPU: (90 + 10) / 2 = 50%, which is below 70%. So it does not scale out — even though one instance is at 90%.